ГОСТ Р ИСО/МЭК МФС 10609-10-98

Группа П85

ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

Функциональный стандарт

ПРОФИЛИ ТВ, ТС, TD И ТЕ. УСЛУГИ ТРАНСПОРТНОГО УРОВНЯ В РЕЖИМЕ
С УСТАНОВЛЕНИЕМ СОЕДИНЕНИЯ С ИСПОЛЬЗОВАНИЕМ УСЛУГ СЕТЕВОГО
УРОВНЯ В РЕЖИМЕ С УСТАНОВЛЕНИЕМ СОЕДИНЕНИЯ

Часть 10. Требования, зависимые от подсети "Локальная вычислительная сеть"
и независимые от физической среды

Information technology. International standardized profiles ТВ, ТС, TD and ТЕ.
Connection-mode transport service over connection-mode network service
Part 10. LAN subnetwork-dependent, media-independent requirements

     
     
ОКС 35.100
ОКСТУ 400

 _________________
     * В Указателе "Государственные стандарты" 2003 г. указан
код ОКС 35.100.05. - Примечание .

Дата введения 1999-01-01

Предисловие

     
     1 РАЗРАБОТАН Московским научно-исследовательским центром (МНИЦ) Государственного комитета Российской Федерации по связи и информатизации
     
     ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"
     
     2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 14 июля 1998 г. N 293
     
     3 Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК МФС 10609-10-94 "Информационная технология. Международный функциональный стандарт. Профили ТВ, ТС, TD и ТЕ. Услуги транспортного уровня в режиме с установлением соединения с использованием услуг сетевого уровня в режиме с установлением соединения. Часть 10. Требования, зависимые от подсети "локальная вычислительная сеть" и независимые от физической среды"
     
     4 ВВЕДЕН ВПЕРВЫЕ
     
     

Введение

     
     Настоящий стандарт определен в контексте функциональной стандартизации в соответствии с принципами, определенными в ГОСТ Р ИСО/МЭК ТО 10000-1 и ГОСТ Р ИСО/МЭК ТО 10000-2.
     
     Контекст функциональной стандартизации - это одна из частей общей сферы деятельности в области информационной технологии (ИТ), охватывающей базовые стандарты, профили и механизмы регистрации. Профиль определяет комбинацию базовых стандартов, которые в совокупности выполняют конкретную четко определенную функцию ИТ. Профили стандартизуют использование факультативных возможностей и других вариантов в базовых стандартах и обеспечивают основу для разработки унифицированных международно признанных системных тестов.
     
     Функциональные стандарты разрабатывают не просто для "узаконивания" конкретного набора базовых стандартов и факультативных возможностей, но и для того, чтобы способствовать взаимодействию открытых систем. Одна из наиболее важных задач функционального стандарта (ФС) состоит в том, чтобы стать основой для разработки (организациями, кроме ИСО и МЭК) международно признанных тестов и центров аттестационного тестирования. Для успешного достижения этой цели очень важны разработка и широкая приемлемость тестов, основанных на настоящем и других ФС.
     
     ГОСТ Р ИСО/МЭК МФС 10609 состоит из нескольких частей, из которых настоящий стандарт является частью 10. Части 1-4 определяют независимые от особенностей подсети требования к каждой группе транспортных профилей ТВ, ТС, TD и ТЕ соответственно. В других частях определены зависимые от подсети и физической среды требования к профилям. Кроме того, для каждого отдельного профиля предусмотрена отдельная часть ФС, в которой установлены конкретные требования к данному профилю со ссылками на соответствующий материал из других частей, определяющих зависимые и независимые от подсети требования.
     
     Настоящий стандарт содержит четыре приложения. Приложения А и В являются обязательными, приложения С и D - информационными.
     
     

     1 ОБЛАСТЬ ПРИМЕНЕНИЯ

     
     Настоящий стандарт распространяется на оконечные системы, работающие в функциональной среде взаимосвязи открытых систем (ВОС), и определяет комбинацию тех стандартов ВОС, которые в совокупности обеспечивают услуги транспортного уровня в режиме с установлением соединения при использовании услуг сетевого уровня в режиме с установлением соединения.
     
     Настоящий стандарт определяет зависимые от типа подсети требования к оконечным системам, которые подсоединены к подсети "локальная вычислительная сеть" (ЛВС), работающей по протоколу управления логическим звеном (УЛЗ) типа 2 по ГОСТ 28907, безотносительно к типу физической среды.
     
     

     2 НОРМАТИВНЫЕ ССЫЛКИ

     
     Настоящий стандарт содержит ссылки на следующие стандарты:
     
     ГОСТ 34.954-91 (ИСО 8878-87) Информационная технология. Взаимосвязь открытых систем. Использование протокола пакетного уровня Х.25 для обеспечения услуг сетевого уровня взаимосвязи открытых систем в режиме с установлением соединения
     
     ГОСТ 28907-91 (ИСО 8802-2-89) Системы обработки информации. Локальные вычислительные сети. Протокол и услуги уровня управления логическим звеном данных
     
     ГОСТ Р 34.950-92 (ИСО 8208-87) Информационная технология. Взаимосвязь открытых систем. Передача данных. Протокол пакетного уровня Х.25 для оконечного оборудования данных
     
     ГОСТ Р ИСО/МЭК 8881-98 Информационная технология. Передача данных. Использование протокола пакетного уровня Х.25 в локальных вычислительных сетях
     
     ГОСТ Р ИСО/МЭК ТО 10000-1-93 Информационная технология. Основы и таксономия функциональных стандартов. Часть 1. Основы
     
     ГОСТ Р ИСО/МЭК ТО 10000-2-93 Информационная технология. Основы и таксономия функциональных стандартов. Часть 2. Таксономия профилей
     
     ИСО/МЭК 8208-87/Изм.3-91* Информационная технология. Передача данных. Протокол пакетного уровня Х.25 для оконечного оборудования данных. Дополнение 3. Аттестованные требования
_______________
    * Оригиналы стандартов и проектов ИСО/МЭК - во ВНИИКИ Госстандарта России.
          
     ИСО/МЭК 8348-93* Системы обработки информации. Передача данных. Определение услуг сетевого уровня
_______________
    * Оригиналы стандартов и проектов ИСО/МЭК - во ВНИИКИ Госстандарта России.
          
     ИСО 8802-2-89/Изм.1* Системы обработки информации. Локальные вычислительные сети. Протокол и услуги уровня управления логическим звеном данных. Изменение 1. Методы управления потоком для мостовых ЛВС
_______________
    * Оригиналы стандартов и проектов ИСО/МЭК - во ВНИИКИ Госстандарта России.
          
     ИСО 8802-2-89/Изм.2* Системы обработки информации. Локальные вычислительные сети. Протокол и услуги уровня управления логическим звеном данных. Изменение 2. Услуги и протокол в режиме без установления соединений с подтверждением. Операции типа 3
_______________
    * Оригиналы стандартов и проектов ИСО/МЭК - во ВНИИКИ Госстандарта России.
          
     ИСО 8802-2-89/Изм.3* Системы обработки информации. Локальные вычислительные сети. Протокол и услуги уровня управления логическим звеном данных. Изменение 3. Требования к соответствию
_______________
    * Оригиналы стандартов и проектов ИСО/МЭК - во ВНИИКИ Госстандарта России.
          
     ИСО 8802-2-89/ИЗМ.4* Системы обработки информации. Локальные вычислительные сети. Протокол и услуги уровня управления логическим звеном данных. Изменение 4. Редакционные изменения и технические поправки
_______________
    * Оригиналы стандартов и проектов ИСО/МЭК - во ВНИИКИ Госстандарта России.
          
     ИСО 8802-2-89/Изм.5* Системы обработки информации. Локальные вычислительные сети. Протокол и услуги уровня управления логическим звеном данных. Изменение 5. Маршрутизация со стороны отправителя в мостовых ЛВС, выполняемая оконечными системами
_______________
    * Оригиналы стандартов и проектов ИСО/МЭК - во ВНИИКИ Госстандарта России.
     
     

     3 ОПРЕДЕЛЕНИЯ

     
     Все термины, использованные в настоящем стандарте, определены в базовых стандартах, на которые даны ссылки (см. раздел 2).
     
     

     4 СОКРАЩЕНИЯ

     
     Сокращения, использованные в настоящем стандарте, определены в базовых стандартах, на которые даны ссылки (см. раздел 2).
     
     

     5 ТРЕБОВАНИЯ

     
     5.1 Введение
     
     В данном разделе установлены зависимые от типа подсети и независимые от физической среды требования к операциям оконечной системы в случае подключения оконечной системы к ЛВС.
     
     5.2 Требования статического соответствия
     
     5.2.1 Общие требования
     
     Реализация, претендующая на соответствие настоящей части настоящего ФС, должна:
     
     a) удовлетворять требованиям ГОСТ 34.954, приведенным в 5.2.2;
     
     b) удовлетворять требованиям ГОСТ Р 34.950, модифицированным в ГОСТ Р ИСО/МЭК 8881 в части операции типа 2 УЛЗ и приведенным в 5.2.3;
     
     c) удовлетворять требованиям ГОСТ 28907, приведенным в 5.2.4;
     
     d) реализовать все функциональные возможности, идентифицированные как требования в списке требований к заявке о соответствии реализации функциональному стандарту (ЗСРФС), приведенному в приложении А.
     
     5.2.2 Требования ГОСТ 34.954
     
     Реализация должна:
     
     a) удовлетворять требованиям к обеспечению услуг сетевого уровня ВОС, определенных в ГОСТ 34.954, за исключением услуг "подтверждение приема" (раздел 9), "передача срочных данных" (раздел 10) и приложения А;
     
     b) быть способной использовать адреса отправителя и получателя на сетевом уровне ВОС любого формата и с любыми значениями, определенными в ИСО/МЭК 8348.
     
     5.2.3 Требования ГОСТ Р 34.950
     
     5.2.3.1 Общие требования
     
     Реализация должна:
     
     a) удовлетворять требованиям статического соответствия, установленным в разделе 17 ИСО 8208/Изм.3;
     
     b) реализовать службу виртуальных соединений;
     
     c) реализовать следующие возможности, определенные в таблице 37 ИСО 8208/Изм.3:
     
     - устанавливать виртуальное соединение (ВС); инициировать исходящее ВС с последующим принятием или отклонением либо принимать входящее ВС и отвечать принятием, либо принимать входящее ВС и отвечать отклонением.
     
     Примечание - Реализация может выполнять любую из перечисленных возможностей либо все эти возможности;
     
     

     - прерывать попытки установления исходящего ВС путем освобождения соединения,
     
     - освобождать установленное ВС в роли как инициатора, так и ответчика,
     
     - сбрасывать логический канал в роли ответчика;
     
     d) реализовать следующие факультативные возможности, определенные в 21.1.2 ИСО 8208/Изм.3:
     
     - обеспечивать передачу данных пользователя в пакетах "установление соединения" при их приеме и передаче,
     
     - обеспечивать передачу пакетов ДАННЫЕ,
     
     - обеспечивать пакеты ДАННЫЕ с битом М, установленным в 1 при приеме,
     
     - передавать обновленную информацию поворота окна,
     
     - передавать пакеты ГПР;
     
     e) принимать входящие ВС как вызовы с быстрой выборкой;
     
     f) обеспечивать следующие факультативные возможности:
     
     - согласование класса пропускной способности,
     
     - быстрая выборка,
     
     - приемлемость быстрой выборки,
     
     - выбор и индикация транзитной задержки,
     
     - расширение адреса вызывающего,
     
     - расширение адреса вызываемого,
     
     - согласование класса минимальной пропускной способности,
     
     - согласование межконцевой транзитной задержки,
     
     - согласование срочных данных;
     
     g) удовлетворять требованиям к адресации на сетевом уровне, изложенным в 5.2.3.2.
     
     5.2.3.2 Адреса на сетевом уровне
     
     Система, претендующая на соответствие настоящему стандарту, должна быть способна использовать адреса отправителя и получателя на сетевом уровне ВОС любого формата и с любыми значениями, определенными в ИСО/МЭК 8348.
     
     Адреса вызывающего, вызываемого и отвечающего ПДУСУ должны передаваться полностью с использованием предпочтительного двоичного кодирования в поле "параметр услуги" услуги "расширение адресов вызывающего и вызываемого".
     
     Примечание - Если аттестуемая реализация получает пакет ВХОДЯЩИЙ ВЫЗОВ, который не соответствует настоящему стандарту, рекомендуется передать пакет ЗАПРОС ОСВОБОЖДЕНИЯ с кодом причины "по инициативе ООД" и кодом диагностики либо 235, либо 232.
     
     

     5.2.4 Требования ГОСТ 28907
     
     Реализация должна:
     
     a) реализовать функции, требуемые ГОСТ 28907 для обеспечения протокола "управление логическим звеном, тип 2";
     
     b) для обеспечения взаимосвязи согласовывать значения N1 и тайм-аута подтверждения, общие для всей ЛВС;
     
     c) обеспечивать для тайм-аута подтверждения значение (5±1) с, при этом рекомендуется предусмотреть возможность изменения этого значения во время эксплуатации.
     
     5.3 Требования динамического соответствия
     
     5.3.1 Общие требования
     
     Реализация, претендующая на соответствие настоящему стандарту, должна:
     
     a) удовлетворять требованиям ГОСТ Р 34.950, приведенным в 5.3.2;
     
     b) удовлетворять требованиям ГОСТ 28907, приведенным в 5.3.3;
     
     c) функционировать в соответствии с требованиями списка требований к ЗСРФС приложения А.
     
     5.3.2 Требования ГОСТ Р 34.950
     
     5.3.2.1 Общие требования
     
     Реализация должна:
     
     a) выполнять обеспечиваемые в ГОСТ Р 34.950 функции в соответствии с процедурами протокола пакетного уровня Х.25 по ГОСТ Р 34.950, модифицированными в разделах 1 и 2 ГОСТ Р ИСО/МЭК 8881 для работы в функциональной среде ЛВС с использованием процедур УЛЗ типа 2;
     
     b) не использовать процедуры для работы протокола ГОСТ Р 34.950 с УЛЗ типа 1, приведенными в разделе 3 ГОСТ Р ИСО/МЭК 8881, поскольку они запрещены настоящим стандартом.
     
     Примечание - Это не относится к использованию протокола маршрутизации по ГОСТ Р ИСО/МЭК 10030, который может использовать процедуры УЛЗ типа 1 в функциональной среде ЛВС;
     
     
     c) удовлетворять требованиям к передаче срочных данных, определенным в 5.3.2.2;
     
     d) удовлетворять требованиям к подтверждению приема, определенным в 5.3.2.3;
     
     e) обеспечивать метод определения диапазона логических каналов, установленный в 5.3.2.4.
     
     Реализация может:
     
     а) игнорировать адреса вызываемого ООД и вызывающего ООД ППУ Х.25, поскольку настоящий стандарт не требует их использования.
     
     5.3.2.2 Срочные данные
     

     Услуга "срочные данные" не обеспечивается.
     
     Функция "согласование срочных данных" (ССД) ППУ по ГОСТ Р 34.950 используется для согласования неиспользования услуги срочных данных.
     
     i) Если логический объект сетевого уровня получает от удаленного пользователя УСУ примитив С-СОЕДИНЕНИЕ запрос, передаваемый пакет ЗАПРОС ВЫЗОВА может содержать функцию ССД, установленную в значение "неиспользование срочных данных" или как вариант функция ССД может быть опущена, что предполагает неиспользование этой возможности.
     
     ii) Если логический объект сетевого уровня получает от удаленного пользователя УСУ примитив С-СОЕДИНЕНИЕ ответ, передаваемый пакет ВЫЗОВ ПРИНЯТ может содержать функцию ССД, установленную в значение "неиспользование срочных данных" или как вариант функция ССД может быть опущена, что предполагает неиспользование этой возможности.
     
     Примечания
     
     1 Если реализация, действующая в соответствии с настоящим стандартом, в фазе передачи данных получает пакет ПРЕРЫВАНИЕ, рекомендуется, чтобы освобождение виртуального соединения проходило с использованием пакета ЗАПРОС ОСВОБОЖДЕНИЯ (и соответствующих процедур, определенных в ГОСТ Р 34.950), кода причины "по инициативе ООД" и кода диагностики 44.
     
     2 При работе по некоторым другим профилям, например обеспечивающим терминальный доступ к Х.29, может потребоваться обеспечение однооктетных пакетов ПРЕРЫВАНИЕ.
     
     
     5.3.2.3 Подтверждение приема
     
     Услуга "подтверждение приема" не обеспечивается.
     
     Бит 7 октета 1 (бит Д) в поле ИОФ пакета установления соединения ППУ Х.25-1984 используется для согласования неиспользования услуги подтверждения приема.
     
     i) В пакетах ЗАПРОС ВЫЗОВА, передаваемых ООД, бит Д должен быть установлен в значение 0.
     
     ii) Если логический объект сетевого уровня получает примитив С-СОЕДИНЕНИЕ ответ, параметр "выбор подтверждения приема" должен быть установлен в значение "неиспользование подтверждения приема" и, следовательно, бит 7 поля ИОФ пакета ВЫЗОВ ПРИНЯТ устанавливается в 0.
     
     Примечание - Если аттестуемая реализация получает пакет ДАННЫЕ с битом Д в значении 1, рекомендуется, чтобы освобождение виртуального соединения проходило с использованием пакета ЗАПРОС ОСВОБОЖДЕНИЯ (и соответствующих процедур, определенных в ГОСТ Р 34.950), кода причины "по инициативе ООД" и кода диагностики 255 или 166.
     

     
     5.3.2.4 Метод определения диапазона логических каналов
     
     Диапазон подлежащих использованию логических каналов (НВК, ВВК, НДК, ВДК, НИК и ВИК) определяется на основании локальных сведений. Если локальных сведений нет, то по умолчанию может быть использован только один двунаправленный логический канал (т.е. НДК и ВДК будут установлены в 1, а НВК, ВВК, НИК и ВИК - в 0). При наличии более одного канала старшее значение ВДК может быть согласовано с использованием услуги "динамическая регистрация услуги".
     
     Если ООД способно инициировать пакет ЗАПРОС РЕГИСТРАЦИИ, то поле параметра регистрации должно устанавливаться следующим образом:
     
     i) Параметры НВК, ВВК, НИК и ВИК должны устанавливаться в нуль, а НДК должен устанавливаться в значение 1. Значение поля параметра "общее число логических каналов" должно устанавливаться равным значению поля параметра ВДК.
     
     ii) Никакие другие факультативные возможности пользователя не должны идентифицироваться в пакете ЗАПРОС РЕГИСТРАЦИИ, и при их наличии они должны игнорироваться принимающей стороной.
     
     Если ООД способно выдавать в ответ пакет ЗАПРОС РЕГИСТРАЦИИ, то в поле параметра ВДК должно указываться максимально допустимое число двунаправленных логических каналов между двумя ООД. Значение поля параметра ВДК должно быть меньше или равно значению, запрошенному в поле параметра ВДК пакета ЗАПРОС РЕГИСТРАЦИИ.
     
     Регистрация функциональных возможностей обычно используется только в одном направлении конфигурации ООД/АКД (т.е. регистрация функциональных возможностей выполняется независимо в каждом направлении), однако согласование диапазона логических каналов осуществляется в обоих направлениях.
     
     Примечание - Ответчик может проигнорировать пакет ЗАПРОС РЕГИСТРАЦИИ. Рекомендуется, однако, чтобы ООД было способно выдавать в ответ пакет ЗАПРОС РЕГИСТРАЦИИ, даже если оно обеспечивает только один двунаправленный логический канал. Это предотвратит ненужные задержки у инициатора при передаче пакета ЗАПРОС ВЫЗОВА. Такие задержки определяются инициатором по значениям тайм-аута Т28 и счетчика повторных передач R28.
     
     

     5.3.3 Требования ГОСТ 28907
     
     5.3.3.1 Общие требования
     
     Реализация должна:
     
     a) выполнять обеспечиваемые ГОСТ 28907 функции в соответствии с процедурами, определенными в ГОСТ 28907;
     
     b) использовать фактическое значение адреса '111 1110'. В таблице 1 показано кодирование полей адресов ПДУП и ПДУО;
     
Таблица 1 - Значения адреса УЛЗ
     

     
     
     с) если должно использоваться значение k, не равное 7, согласовать значение, подлежащее использованию в кадрах ИДС в соответствии с излагаемыми в 5.3.3.2 процедурами.
     
     5.3.3.2 Использование ИДС
     
     Настоящий стандарт не требует от реализации передавать командные кадры ИДС, за исключением случаев согласования значений k, отличных от 7.
     
     Примечание - ГОСТ 28907 требует, чтобы на получение командного кадра ИДС выдавался ответный кадр ИДС.
     
     
     Реализация, получающая командный кадр ИДС, адресованный по отдельному значению фактического адреса, определенному в 5.3.3.1 b), должна выдавать ответный кадр ИДС с использованием отдельного фактического адреса. Реализация должна действовать следующим образом:
     
     i) Воспринимать размер окна приема инициатора, если его используемое значение по умолчанию равно 7. Однако если это значение иное, реализация не должна использовать размер окна передачи больший, чем указано в полученной команде ИДС. Если используемый размер окна передачи больше размера окна приема, это может привести к сбросу соединения УЛЗ. Требования к фактическому использованию полного размера окна, указанного в получаемой команде ИДС, отсутствуют.
     
     ii) Поле информации в ответе ИДС должно содержать размер окна приема ответчика. Размер окна по умолчанию (определенный в ГОСТ Р ИСО/МЭК 8881) равен 7.
     
     iii) Инициатор, получивший ответ ИДС, должен зафиксировать его и действовать с размером окна приема, как указано в i).
     
     Реализация, получившая командный кадр ИДС, который адресован по нулевому адресу, должна выдать в ответ кадр ИДС, используя нулевой адрес в обоих полях ПДУП и ПДУО. Реализация должна действовать следующим образом:
     
     i) Значение полученного размера окна должно игнорироваться.
     
     ii) Рекомендуется, чтобы поле информации в ответе ИДС содержало тип/класс УЛЗ, установленный в значение "класс II", и размер окна приема, установленный в значение '000 0000'.
     
     Примечания
     
     1 Значение класса II определено в ГОСТ 28907 и равно '11000'.
     
     2 Размер окна приема в кадре ИДС, относящегося к нулевому адресу, не имеет значения. Следовательно, его значение должно игнорироваться. Если никакое другое значение не может быть использовано для этого поля, предлагается значение '000 0000'.
     
     

ПРИЛОЖЕНИЕ А
(обязательное)

     
СПИСОК ТРЕБОВАНИЙ К ЗАЯВКЕ О СООТВЕТСТВИИ РЕАЛИЗАЦИИ ФУНКЦИОНАЛЬНОМУ СТАНДАРТУ

     
     А.1 Введение
     
     ГОСТ Р ИСО/МЭК ТО 10000-1 определяет три позиции для включения в список требований к ЗСРФС. К ним относятся:
     
     - общие факультативные возможности профиля;
     
     - список стандартов, выбранных в профиле;
     
     - ограничения на допустимые ответы в форме ЗСРП каждого такого стандарта.
     
     Две первые позиции относятся к профилю в целом и поэтому входят только в те части ГОСТ Р ИСО/МЭК МФС 10609, которые специфичны для отдельных профилей. Однако в каждой части указанного стандарта содержится идентификация тех ограничений профиля, которые входят в предмет ее рассмотрения.
     
     ГОСТ Р ИСО/МЭК ТО 10000-1 указывает, что форма ЗСРФС может содержать либо простой список ограничений, либо измененные копии форм ЗСРП базовых стандартов. В настоящем стандарте используется первая из указанных возможностей.
     
     А.2 Нотация и соглашения
     
     А.2.1 Введение
     
     Во многих случаях ограничения, налагаемые СТЗФС, выражаются в виде символов, указывающих статус в контексте настоящего стандарта тех позиций форм ЗСРП базовых стандартов, к которым относятся эти ограничения. Используемые символы определены в следующих двух подразделах.
     
     А.2.2 Нотация для статического соответствия
     
     Для идентификации ограничений, налагаемых на возможности аттестуемых реализаций, используются следующие символы:
     

a) Статус, определяющий непосредственно символы
     

     
     Следует заметить, что в контексте принимаемых ПБД либо полей, либо параметров полученных ПБД возможности их обеспечения рассматриваются как возможность интерпретации значимости ПБД или его поля и выполнения над ним действий в соответствии с требованиями к динамическому соответствию протоколу (что в некоторых случаях может означать выработку отчета об ошибках). К необеспечиваемым ПБД или их полям не относятся те, которые игнорируются на приеме и не влияют на протокольные операции.
     

b) Прочая необходимая нотация

     Символы в виде у<n> используются в тех случаях, когда статус данной позиции зависит от обеспечения других позиций. В этом случае <n> - это номер, который ссылается на определение окончания раздела, в котором он используется. Это определение устанавливает специальный статус, который может быть выражен, например, в форме типа "если ABC, то о, иначе з", что должно означать статус "обязательно", если позиция в форме ЗСРП с указателем ABC обеспечивается, и статус "запрещено" в противном случае.
     
     Символы в форме <позиция>:<статус> используются как сокращенный способ выражения условий, при которых статус определен, если заданная позиция обеспечивается, в противном случае статус будет иметь значение "не используется". Таким образом, например, "АВС:о" будет эквивалентом условному статусу "если ABC, то о, иначе -".
     
     А.2.3 Нотация при описании динамического соответствия
     
     В некоторых случаях необходимо определить ограничения, налагаемые не только на реализацию возможностей, но и на их использование. При наличии такой необходимости за символом статуса статического соответствия, определенным в А.2.2 а), следует дополнительный символ, предназначенный для создания определения двухзнакового статуса. Второй символ определяет динамические ограничения и имеет следующие значения:
     

     
     Таким образом, например, статус "оо" должен означать обязательное обеспечение возможности, указанной в форме ЗСРП, и обязательность ее использования в применимых случаях.
     
     Там, где используется только однознаковый статус, он определяет статическое требование и означает, что на динамическое использование данной возможности не налагается динамических ограничений.
     
     А.2.4 Идентификация позиций формы ЗСРП
     
     Позиции формы ЗСРП идентифицируются путем использования номера подраздела, за которым следует знак двоеточия и за ним указатель позиции соответствующей строки формы ЗСРП. При идентификации из одного и того же подраздела обязательно указание номера подраздела и знака двоеточия.
     
     А.3 СТЗФС для ГОСТ Р 34.950
     
     Соответствующая форма ЗСРП базового стандарта приведена в приложении В к ИСО 8208/Изм.3. Настоящий стандарт налагает на нее следующие ограничения:
     

     
     А.4 СТЗФС для ГОСТ 28907
     
     Соответствующая форма ЗСРП базового стандарта приведена в приложении В. Настоящий стандарт налагает на нее следующие ограничения:
     
     

     
     
     Определение условных позиций статуса:
     
     y1 - если обеспечиваемое значение k не равно 7, тогда о, иначе ф;
     
     у2 - если обеспечиваемое значение k не равно 7 И НЕ ИДПд/17, то о, иначе з;
     
     у3 - если обеспечиваемое значение k не равно 7 И НЕ ИДПд/18, то о, иначе з.
     
     

ПРИЛОЖЕНИЕ В
(обязательное)

    
ПРЕДПОЛАГАЕМАЯ ФОРМА ЗСРП БАЗОВЫХ СТАНДАРТОВ
ДЛЯ УПРАВЛЕНИЯ ЛОГИЧЕСКИМ ЗВЕНОМ ПО ГОСТ 28907

     
     В.1 Введение
     
     Поставщик реализации протокола, заявляющий о ее соответствии ГОСТ 28907 и изменениям 1-4 к ИСО 8802-2, должен заполнить приведенную ниже форму заявки о соответствии реализации протоколу (ЗСРП).
     
     Заполненная форма ЗСРП представляет собой ЗСРП для рассматриваемой реализации. ЗСРП представляет собой констатацию тех функций и факультативных возможностей, которые обеспечивает данная реализация. ЗСРП может быть использована многими, в том числе:
     
     - разработчиком протокола в качестве проверочного списка с целью уменьшить риск ошибиться в оценке соответствия стандарту из-за возможного недосмотра;
     
     - поставщиком и покупателем или потенциальным покупателем реализации в виде подробного описания ее возможностей, которое изложено на общевоспринимаемой основе, предусмотренной стандартной формой ЗСРП;
     
     - пользователем или потенциальным пользователем реализации в качестве основы для начальной проверки возможностей взаимодействия с другими реализациями. (Заметим, что если взаимодействие никогда нельзя гарантировать, то ошибки взаимодействия часто можно предсказать, исходя из несовместимых ЗСРП.);
     
     - исполнителем протокольного теста в качестве основы для выбора соответствующих тестов, по которым оценивают заявку на соответствие реализации.
     
     В.2 Сокращения и специальные символы
     
     В.2.1 Символы состояний:
     

     
     8.2.2 Общие сокращения
     

     
     8.2.3 Указатели позиции
     
     Ниже приведен перечень указателей позиций, используемых в форме ЗСРП:
     
     Основные возможности:
     

     
     В.3 Инструкции по заполнению формы ЗСРП
     
     В.3.1 Общая структура формы ЗСРП
     
     Первая часть формы ЗСРП "Идентификация реализации и сводные сведения о протоколе" должна быть заполнена, как указано, информацией, необходимой для полной идентификации как поставщика, так и реализации.
     
     Основная часть формы ЗСРП представляет собой вопросник фиксированного формата, имеющий шесть основных подразделов; последние могут быть разделены на более мелкие подразделы, каждый из которых содержит множество отдельных позиций. Ответы на вопросы каждой позиции, которые записывают в правой колонке, представляют собой либо простую пометку для указания ограниченного выбора (обычно "Да" или "Нет"), либо указание конкретного значения либо набора, либо диапазона значений.
     
     Примечание - Имеются такие позиции, где применимы два или более вариантов из набора возможных ответов. Все соответствующие варианты должны быть отмечены.
     
     
     Каждая позиция идентифицируется ее обозначением в первой колонке; во второй колонке содержится вопрос, на который требуется ответить; в третьей колонке содержится ссылка (или ссылки) на материал, который определяет позицию в ГОСТ 28907 и в изменениях 1-5 ИСО 8802-2. В остальных колонках зарегистрирован статус позиции: является ли обеспечение обязательным, факультативным или условным, - и предусмотрено место для записи ответов; см. также В.3.4.
     
     Поставщик может также записать или потребовать записи другой информации, классифицируемой как "дополнительная информация" или "особая информация". Каждый из этих видов информации при ее наличии должен быть представлен в последующих подразделах позиций, отмеченных как Д <i> или О <i> соответственно для ссылок на нее, где <i> - любая недвусмысленная идентификация позиции (например, обычный номер); никаких других ограничений на ее формат и представление не налагается.
     
     Заполненная форма ЗСРП, включая любую дополнительную информацию и особую информацию, представляет собой "Заявку о соответствии реализации протоколу" для соответствующей реализации.
     
     Примечание - Если какая-либо реализация может быть представлена в нескольких конфигурациях, то в одной ЗСРП можно описать все такие конфигурации. Однако чтобы облегчить представление информации и сделать ее более понятной, поставщик может составить несколько ЗСРП, каждая из которых охватывает некоторое подмножество возможных конфигураций реализации.
     
     
     В.3.2 Дополнительная информация
     
     Позиции раздела ЗСРП "Дополнительная информация" позволяют поставщику представить дополнительную информацию, которая поможет в интерпретации ЗСРП. Не ставится целью и не предполагается обеспечить большой объем такой информации, и вся ЗСРП может рассматриваться без любой такой информации. Примерами дополнительной информации могут служить описания способов установки реализации (одной) для работы в различных условиях и в разных конфигурациях либо краткое обоснование, возможно, специфических требований применения, причин исключения тех возможностей, которые, хотя и являются факультативными, но, тем не менее, повсеместно представлены в реализациях протокола ГОСТ 28907.
     
     Ссылки на позиции раздела "Дополнительная информация" могут быть даны вслед за любым ответом в вопроснике и могут быть включены в позиции раздела "Особая информация".
     
     В.3.3 Особая информация
     
     Может случиться, что поставщик пожелает ответить в позиции с обязательным или факультативным статусом (на основе любых применимых условий) способом, противоречащим указанным требованиям. В колонке "Обеспечение" он не найдет никакого заготовленного ответа на этот случай; вместо этого поставщик должен записать в эту колонку отсутствующий ответ вместе со ссылкой О <i> на позицию особой информации и должен дать соответствующее обоснование позиции особой информации.
     
     Реализация, для которой необходима такая особая позиция, не соответствует ГОСТ 28907 и изменениям 1-5 ИСО 8802-2.
     
     Примечание - Причиной описанной выше ситуации может оказаться извещение об ошибке в ГОСТ 28907 или в изменениях 1-5 ИСО 8802-2; ожидаемое исправление должно изменить требование, которому реализация не соответствует.
     
     
     В.3.4 Условные состояния
     
     В.3.4.1 Условные позиции
     
     Форма ЗСРП содержит большое число условных позиций. Это такие позиции, в которых применимый статус - обязательный, факультативный или запрещенный - зависит от обеспечения некоторых других позиций.
     
     Во многих случаях общая применимость позиции условна в таком же смысле, в каком условна применимость статуса при применимости позиции.
     
     В тех случаях, когда объектом одного и того же условия применимости является группа позиций, в заголовке этой группы ставится отдельный предварительный вопрос относительно этого условия с указанием пропустить последний пункт вопросника при выборе ответа "не используется". В противном случае отдельные условные позиции указываются одним или несколькими условными символами (в отдельных строках) в колонке "Статус".
     
     Условный символ имеет форму "<пред><х>", где "<пред>" означает предикат согласно В.3.4.2, а "<х>" - один из символов статуса О, Ф, Ф.<n> или И.
     
     Если предикат в любой строке условной позиции имеет значение "истинно" (см. В.3.4.2), то условная позиция применима и ее статус соответствует символу статуса, следующему за предикатом; колонка ответов должна быть заполнена необычным образом. Если предикат имеет значение "ложно", то в соответствующей строке должен быть указан ответ "не используется" (Н/И). (Каждая строка в многострочной условной позиции должна быть заполнена: максимум одна строка потребует ответа, отличного от Н/И.)
     
     Условный символ вида "<пред><х>", где "<пред>" означает предикат согласно В.3.4.2, может предшествовать таблице или группе таблиц в разделе или подразделе. Если значение предиката - "истинно", в таблице или группе таблиц должен быть указан ответ. В противном случае таблица или группа таблиц должны быть опущены.
     
     В.3.4.2 Предикаты
     
     Предикатом считается одно из следующих:
     
     a) ссылка в позиции на какую-либо позицию в форме ЗСРП: предикат имеет значение "истинно", если позиция указана как обеспечиваемая, и "ложно" в противном случае;
     
     b) имя предиката, определенного в каком-либо месте формы ЗСРП (обычно в разделе "Основные возможности" или в конце раздела, содержащего условную позицию) (см. ниже) или
     
     c) символ логического отрицания "-", предшествующий ссылке в позиции или имени предиката: предикат имеет значение "истинно", если предикат, сформированный в отсутствие символа "-", имеет значение "ложно", и наоборот.
     
     Определение имени предиката представляет собой одно из следующих:
     
     i) ссылка в позиции, интерпретируемая как в подпункте а);
     
     ii) соотношение, содержащее оператор сравнения (=, < и т.п.), где по меньшей мере один из операндов является ссылкой в позиции, имеющей в качестве ответа числовое значение; такой предикат имеет значение "истинно", если соотношение выполняется, когда каждая ссылка в позиции заменяется значением в колонке "Обеспечение" в качестве ответа на указанную позицию или
     
     iii) булево выражение, составленное из простых предикатов, как в подпунктах i) и ii), с обычным использованием булевых операторов И, ИЛИ и НЕ и скобок; значение такого предиката оценивается как "истинно", если булево выражение оценивается как истинное при интерпретации ссылки на позицию, как указано выше.
     
     Каждая позиция, на которую в предикате или в определении предиката используется ссылка, отмечается знаком "звездочка" в колонке "Позиция".
     
     В.3.5 Идентификация требований
     
     Информация в форме ЗСРП не заменяет и не добавляет никаких требований к соответствию, изложенных в основной части ГОСТ 28907 и в изменениях 1, 2, 4 и 5 ИСО 8802-2.
     
     В.4 Форма ЗСРП. Идентификация
     
     В.4.1 Идентификация реализации
     
     

     
     
     В.4.2 Сводные сведения о протоколе
     
     

     
     
     В.5 Основные возможности
     
     

     
     
     В.6 Операции УЛЗ типа 1. Режим без установления соединения и без подтверждений
     
     КЛС1а ИЛИ КЛС2а ИЛИ КЛС3а ИЛИ КЛС4а::
     
     Все таблицы в разделе В.6 должны быть заполнены, если перечисленные выше предикаты оценены как "истинные".
     
     В.6.1 УЛЗ, тип 1. Обеспечиваемые типы ПБД
     
     

     
     
     В.6.2 УЛЗ, тип 1. Обеспечиваемые параметры в ПБД при передаче
     
     

     
     
     В.6.3 УЛЗ, тип 1. Обеспечиваемые параметры в ПБД при приеме
     
     

     
     
     В.6.4 УЛЗ, тип 1. Прочие возможности протокола
     
     

     
     
     В.7 Операции УЛЗ типа 2. Режим с установлением соединения
     
     КЛС2а ИЛИ КЛС4а::
     
     Все таблицы в разделе В.7 должны быть заполнены, если перечисленные выше предикаты оценены как "истинные".
     
     В.7.1 УЛЗ, тип 2. Обеспечиваемые типы ПБД
     
     

     
     
     В.7.2 УЛЗ, тип 2. Обеспечиваемые параметры в ПБД
     
     

     
     
     В.7.3 УЛЗ, тип 2. Обеспечиваемые процедуры
     
     

     
     
     В.7.4 УЛЗ, тип 2. Прочие возможности протокола
     
     

     
     
     В.7.5 УЛЗ, тип 2. Параметры протокола
     
     

     
     
     В.8 Операции УЛЗ типа 3. Режим без установления соединения с подтверждениями
     
     КЛСЗа ИЛИ КЛС4а::
     
     Все таблицы в разделе В.8 должны быть заполнены, если перечисленные выше предикаты оценены как "истинные".
     
     В.8.1 УЛЗ, тип 3. Обеспечиваемые типы ПБД
     
     

     
     
     В.8.2 УЛЗ, тип 3. Обеспечиваемые параметры в ПБД при передаче
     
     

     
     
     В.8.3 УЛЗ, тип 3. Обеспечиваемые параметры в ПБД при приеме
     
     

     
     
     В.8.4 УЛЗ, тип 3. Обеспечиваемые процедуры
     
     

     
     
     В.8.5 УЛЗ, тип 3. Прочие возможности протокола
     
     

     
     
     В.8.6 УЛЗ, тип 3. Параметры протокола
     
     

     
     
     В.9 Логический объект определения маршрута
      ЛОМ : :
     
     Все таблицы в разделе В.9 должны быть заполнены, если перечисленные выше предикаты оценены как "истинные".
     
     Примечание - Использование услуги "логический объект определения маршрута" не требуется данным профилем. Таблицы предполагаемой формы ЗСРП базовых стандартов, относящиеся к этой услуге, опущены в настоящем стандарте.
     
     
     В.9.1 Общие характеристики
     
     См. таблицу А.20 ИСО 8802/Изм.5.
     
     В.9.2 Процедуры, типы и форматы ПБД
     
     См. таблицу А.21 ИСО 8802/Изм.5.
     
     В.9.3 Параметры и их значения
     
     См. таблицу А.22 ИСО 8802/Изм.5.
     
     

ПРИЛОЖЕНИЕ С
(информационное)

     
РЕКОМЕНДАЦИИ

     
     С.1 Введение
     
     Информация, содержащаяся в данном приложении, носит рекомендательный характер и не является обязательной частью настоящего стандарта. При отсутствии конкретных применений, обусловливающих соответствующее альтернативное поведение, рекомендуется реализовать функциональные возможности, представленные в данном приложении.
     
     С.2 Рекомендации ГОСТ Р 34.950
     
     С.2.1 Для улучшения характеристик рекомендуется обеспечить следующие факультативные возможности:
     
     - нестандартные размеры пакета по умолчанию;
     
     - нестандартные размеры окна по умолчанию
     
     и следующие нестандартные значения параметра по умолчанию:
     
     - все нестандартные размеры пакета по умолчанию (максимальная длина поля "данные пользователя") от 32 до 1024 октетов;
     
     - все нестандартные размеры окна по умолчанию от 1 до 7.
     
     Нестандартные значения по умолчанию должны согласовываться для всех ЛВС.
     
     С.2.2 Для того чтобы исключить любые возможные проблемы регламентации фиксированной роли оконечных систем, рекомендуется динамический выбор роли.
     
     С.2.3 В тех случаях, когда требуется динамическая маршрутизация, рекомендуется использовать протокол ГОСТ Р ИСО/МЭК 10030.
     
     С.3 Рекомендации ГОСТ 28907
     
     С.3.1 Рекомендуемые значения параметров приведены в таблице С.1. Рекомендуется, чтобы реализация обеспечивала значение N1, как указано в таблице С.1, т.е. 1031 октет. При некоторых технологиях ЛВС возможно обеспечение более высоких значений размеров. Обеспечение этих более высоких значений не рассматривается в настоящем стандарте. После определения они могут быть включены в те части ГОСТ Р ИСО/МЭК МФС 10609, которые устанавливают требования к ЛВС конкретных технологий.
     
     Примечание - В сервисном блоке данных подуровня УДС всех типов ЛВС по ГОСТ 28907 может быть передан 1031 октет. В тех случаях, когда существует необходимость во взаимосвязях ЛВС, максимальное значение N1 размером в 1031 октет может позволить ретранслировать услуги на подуровне УДС независимо от взаимосвязанных технологий.
     
     
Таблица С.1 - Значения параметров УЛЗ
     

     
     
     С.3.2 Рекомендуемые значения тайм-аутов приведены в таблице С.2. Рекомендуется, чтобы значения всех тайм-аутов можно было изменять. Эти значения тайм-аутов основаны на эмпирических наблюдениях операций мостовых ЛВС. В одной изолированной ЛВС могут использоваться меньшие значения тайм-аутов.
     
     
Таблица С.2 - Значения тайм-аутов УЛЗ
     

     
     
     С.3.3 Рекомендуется, чтобы при работе оконечных систем в мостовых конфигурациях на подуровне УДС использовался описываемый ниже метод управления потоком. Следует заметить, что все оконечные системы, использующие УЛЗ типа 2 и подключенные к таким конфигурациям ЛВС, должны использовать этот метод. Это единственный способ обеспечить справедливое распределение нагрузки.
     
     Для каждого обеспечиваемого соединения УЛЗ оконечная система использует следующую процедуру:
     
     - При каждом обнаружении перегрузки начинается период устранения перегрузки: размер рабочего окна устанавливается в 1 и повторно передается ПБД И, порядковый номер которого равен Нпм последнего правильно принятого ПБД.
     
     - В период устранения перегрузки процедуры УЛЗ типа 2 гарантируют, что максимальное число неподтвержденных ПБД И не превысит размера рабочего окна.
     
     - Когда число ранее не подтвержденных, но к данному моменту успешно переданных и подтвержденных ПБД И достигнет значения размера рабочего окна, размер окна увеличивается на единицу. Период устранения перегрузки заканчивается, когда размер рабочего окна достигнет значения k, определенного в 7.4 ГОСТ 28907.
     
     - ПБД И считается потерянным передающим его логическим объектом УЛЗ при следующих условиях:
     
     1 Передатчик получил ПБД НЕПРИЕМ, который указывает, что приемник обнаружил потерю ПБД И, или
     
     2 Имеет место последовательность событий:
     
     a) тайм-аут подтверждения на передатчике истек, а счет повторных передач меньше N 2,
     
     b) передатчик выдал командный ПБД ГПР с битом З=1,
     
     c) передатчик получил ПБД И или ПБД формата У, в котором бит П=1, но значение Нпм не равно значению Нпд, которое имелось на передатчике при передаче командного ПБД ГПР с битом З=1.
     
     - Выполнение этого алгоритма прерывается любым условием, которое побуждает компонент "соединение" УЛЗ перейти в состояние "сброс" или "разъединение".
     
     Примечание - Этот метод использует механизм параболического возрастания, рассматриваемый в ГОСТ 28907.
     
     
     Кроме того, станция ЛВС может отказаться от установления новых соединений УЛЗ и (или) принять решение освободить обеспечиваемые ею соединения УЛЗ.
     

     Примечание - Рациональное построение мостовой ЛВС может значительно ослабить проблему перегрузки в ретрансляционном оборудовании УДС. Построение реальной конфигурации мостовой ЛВС должно быть тщательно оценено с тем, чтобы ограничить возникновение проблемы перегрузок на подуровне УДС.
     
     

ПРИЛОЖЕНИЕ D
(информационное)

     
БИБЛИОГРАФИЯ

     
     На следующий стандарт даны ссылки в примечаниях, и для настоящего стандарта он носит информационный характер.
     
     ГОСТ Р ИСО/МЭК 10030-96 Информационная технология. Передача данных и обмен информацией между системами. Протокол обмена маршрутной информацией оконечной системы для использования в сочетании с ГОСТ 34.954-91
     
     
     
Текст документа сверен по:
официальное издание
М.:ИПК Издательство стандартов, 1998