ГОСТ Р ИСО/МЭК МФС 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 - Значения адреса УЛЗ
Поле адреса ПДУП | Поле адреса ПДУО | |||||||||||||||
Формат поля | И/Г | П | П | П | П | П | П | П | К/О | О | О | О | О | О | О | О |
Значение | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | К/О | 1 | 1 | 1 | 1 | 1 | 1 | 0 |
Примечание - И/Г - бит, определяющий тип адреса (индивидуальный/групповой); |
с) если должно использоваться значение 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. Настоящий стандарт налагает на нее следующие ограничения:
С.5 Общие характеристики ООД | ||
Позиция базового стандарта | Описание | Ограничение |
Вс | Служба виртуальных соединений | о |
ХХД/8 | Операции ООД/АКД (1988) | з |
ХХД/4 | Операции ООД/АКД (1984) | з |
ХХД/0 | Операции ООД/АКД (1980) | з |
С.6.4.1 Установление соединения | ||
Позиция базового стандарта | Описание | Ограничение |
В1с | Запрос небыстрой выборки | н/р |
В2а | Приемлемость быстрой выборки | о |
В2с | Приемлемость небыстрой выборки | н/р |
С.6.4.2 Освобождение соединения | ||
Позиция базового | Описание | Ограничение |
02а | Освобождение соединения для прерывания ВС | о |
02b | Освобождение соединения для отклонения ВС | о |
02с | Инициируемое освобождение установленного ВС | о |
C.6.5 Сброс логических каналов | ||
Позиция базового стандарта | Описание | Ограничение |
СБо | Сброс со стороны ответчика | о |
С.6.8.1 Передача данных | ||
Позиция базового стандарта | Описание | Ограничение |
ПдД | Передача пакетов ДАННЫЕ | о |
ПОПд | Поворот окна на передаче | о |
ПдОД | Передача бита О=0 в пакете ДАННЫЕ | о |
С.6.8.2 Прием данных | ||
Позиция базового стандарта | Описание | Ограничение |
ПмД | Прием пакетов ДАННЫЕ | о |
ПОПм | Поворот окна на приеме | о |
ПмМд | Прием бита М=1 в пакетах ДАННЫЕ | о |
ПмОД | Прием бита О=1 в пакетах ДАННЫЕ | о |
С.8.1.1 Услуги, передаваемые в пакетах ЗАПРОС ВЫЗОВА | ||
Позиция базового стандарта | Описание | Ограничение |
УПд2 | Согласование класса пропускной способности | о |
УПд6а | Быстрая выборка | о |
УПд12 | Выбор и индикация транзитной задержки | о |
УПд20 | Маркер услуги | о |
УПд21 | Расширение адреса вызывающего | о |
УПд22 | Расширение адреса вызываемого | о |
УПд23 | Согласование класса минимальной пропускной способности | о |
УПд24 | Согласование межконцевой транзитной задержки | о |
УПд25 | Согласование срочных данных | о |
С.8.1.2 Услуги, передаваемые в пакетах ВЫЗОВ ПРИНЯТ | ||
Позиция базового стандарта | Описание | Ограничение |
УПм2 | Согласование класса пропускной способности | о |
УПм20 | Маркер услуги | о |
УПм22 | Расширение адреса вызываемого | о |
УПм24 | Согласование межконцевой транзитной задержки | о |
УПм25 | Согласование срочных данных | о |
С.8.1.3 Услуги, передаваемые в пакетах ЗАПРОС ОСВОБОЖДЕНИЯ | ||
Позиция базового стандарта | Описание | Ограничение |
УПм6а | Быстрая выборка | о |
УПм21 | Расширение адреса вызывающего | о |
С.8.2.1 Услуги, принимаемые в пакетах ВХОДЯЩИЙ ВЫЗОВ | ||
Позиция базового стандарта | Описание | Ограничение |
УПм2 | Согласование класса пропускной способности | о |
УПм6а | Быстрая выборка | о |
УПм12 | Выбор и индикация транзитной задержки | о |
УПм20 | Маркер услуги | о |
УПм21 | Расширение адреса вызывающего | о |
УПм22 | Расширение адреса вызываемого | о |
УПм23 | Согласование класса минимальной пропускной способности | о |
УПм24 | Согласование межконцевой транзитной задержки | о |
УПм25 | Согласование срочных данных | о |
С.8.2.2 Услуги, принимаемые в пакетах СОЕДИНЕНИЕ УСТАНОВЛЕНО | ||
Позиция базового стандарта | Описание | Ограничение |
УПм2 | Согласование класса пропускной способности | о |
УПм12 | Выбор и индикация транзитной задержки | о |
УПм20 | Маркер услуги | о |
УПм22 | Расширение адреса вызываемого | о |
УПм24 | Согласование межконцевой транзитной задержки | о |
УПм25 | Согласование срочных данных | о |
А.4 СТЗФС для ГОСТ 28907
Соответствующая форма ЗСРП базового стандарта приведена в приложении В. Настоящий стандарт налагает на нее следующие ограничения:
В.6.1 УЛЗ, тип 1. Обеспечиваемые типы ПБД | ||
Позиция базового стандарта | Описание | Ограничение |
НИ/1 | НИ_КМД, обеспечивается при передаче | н/р |
НИ/2 | НИ_КМД, обеспечивается при приеме | н/р |
ИДС/3 | ИДС_КМД, обеспечивается при передаче | y1 |
ИДС/6 | ИДС_ОТВ, обеспечивается при приеме | y1 |
ТСТ/7 | ТЕСТ_КМД, обеспечивается при передаче | н/р |
В.6.2 УЛЗ, тип 1. Обеспечиваемые параметры в ПБД при передаче | ||
Позиция базового стандарта | Описание | Ограничение |
НИПд/13 | НИ_КМД - бит 3=0 | н/р |
ИДПд/17 | ИДС_КМД - бит 3=1 | У2 |
ИДПд/18 | ИДС_КМД - бит 3=0 | у3 |
ТСПд/26 | ТЕСТ_КМД - бит 3=1 | н/р |
ТСПд/27 | ТЕСТ_КМД - бит 3=0 | н/р |
В.6.3 УЛЗ, тип 1. Обеспечиваемые параметры в ПБД при приеме | ||
Позиция базового стандарта | Описание | Ограничение |
НИПм/35 | НИ_КМД с битом 3=0 | н/р |
В.7.5 УЛЗ, тип 2. Параметры протокола | ||
Позиция базового стандарта | Описание | Ограничение |
ПАП/148 | Значение тайм-аута подтверждения по умолчанию | Должно обеспечиваться значение (5±1) с |
ПАП/158 | Максимальное число неподтвержденных ПБД и (К) | Должно обеспечиваться значение 7 |
Определение условных позиций статуса:
y1 - если обеспечиваемое значение k не равно 7, тогда о, иначе ф;
у2 - если обеспечиваемое значение k не равно 7 И НЕ ИДПд/17, то о, иначе з;
у3 - если обеспечиваемое значение k не равно 7 И НЕ ИДПд/18, то о, иначе з.
ПРИЛОЖЕНИЕ В (обязательное). ПРЕДПОЛАГАЕМАЯ ФОРМА ЗСРП БАЗОВЫХ СТАНДАРТОВ ДЛЯ УПРАВЛЕНИЯ ЛОГИЧЕСКИМ ЗВЕНОМ ПО ГОСТ 28907
ПРИЛОЖЕНИЕ В
(обязательное)
В.1 Введение
Поставщик реализации протокола, заявляющий о ее соответствии ГОСТ 28907 и изменениям 1-4 к ИСО 8802-2, должен заполнить приведенную ниже форму заявки о соответствии реализации протоколу (ЗСРП).
Заполненная форма ЗСРП представляет собой ЗСРП для рассматриваемой реализации. ЗСРП представляет собой констатацию тех функций и факультативных возможностей, которые обеспечивает данная реализация. ЗСРП может быть использована многими, в том числе:
- разработчиком протокола в качестве проверочного списка с целью уменьшить риск ошибиться в оценке соответствия стандарту из-за возможного недосмотра;
- поставщиком и покупателем или потенциальным покупателем реализации в виде подробного описания ее возможностей, которое изложено на общевоспринимаемой основе, предусмотренной стандартной формой ЗСРП;
- пользователем или потенциальным пользователем реализации в качестве основы для начальной проверки возможностей взаимодействия с другими реализациями. (Заметим, что если взаимодействие никогда нельзя гарантировать, то ошибки взаимодействия часто можно предсказать, исходя из несовместимых ЗСРП.);
- исполнителем протокольного теста в качестве основы для выбора соответствующих тестов, по которым оценивают заявку на соответствие реализации.
В.2 Сокращения и специальные символы
В.2.1 Символы состояний:
О | - обязательный; | |||
Ф | - факультативный; | |||
Ф, <n> | - факультативный, но с обязательным обеспечением, по меньшей мере, одной из групп факультативных возможностей, имеющих один и тот же номер n; | |||
3 | - запрещенный; | |||
<пред>: | - условный символ, включающий в себя идентификацию предиката (см. В.3.3) и относящийся к конкретной позиции; | |||
<пред>:: | - условный символ, включающий в себя идентификацию предиката (см. В.3.3) и относящийся к таблице или группе таблиц; | |||
<позиция>: | - условный символ, статус зависит от обеспечения, указанного для данной позиции (см. В.3.4). |
8.2.2 Общие сокращения
Н/И | - не используется; | |||
ЗСРП | - заявка о соответствии реализации протоколу. |
8.2.3 Указатели позиции
Ниже приведен перечень указателей позиций, используемых в форме ЗСРП:
Основные возможности:
КЛС | Класс обеспечиваемого протокола УЛЗ | |||
ЛОМ | Логический объект определения маршрута |
УЛЗ, тип 1 | ||||
НИ | ПБД НИ | |||
ИДС | ПБД ИДС | |||
ТСТ | ПБД ТЕСТ | |||
НИПд | Параметры в передаваемых ПБД НИ | |||
ИДПд | Параметры в передаваемых ПБД ИДС | |||
ТСПд | Параметры в передаваемых ПБД ТЕСТ | |||
НИПр | Параметры в принимаемых ПБД НИ | |||
ИДПр | Параметры в принимаемых ПБД ИДС | |||
ТСПр | Параметры в принимаемых ПБД ТЕСТ | |||
ПРЧ | Прочие возможности протокола | |||
УЛЗ, тип 2 | ||||
ИК | ПБД И_КМД | |||
ИО | ПБД И_ОТВ | |||
ГПК | ПБД ГПР_КМД | |||
ГПО | ПБД ГПР_ОТВ | |||
НГК | ПБД НГПР_КМД | |||
НГО | ПБД НГПР_ОТВ | |||
НПК | ПБД НПР_КМД | |||
НПО | ПБД НПР_ОТВ | |||
УРС | ПБД УРРАС | |||
РЗД | ПБД РЗД | |||
НП | ПБД НП | |||
ФРЗ | ПБД ФРЗД | |||
НРК | ПБД НПРК | |||
ППд | Параметры в передаваемых ПБД | |||
ППм | Параметры в принимаемых ПБД | |||
ОПП | Процедуры протокола | |||
ПАП | Параметры протокола | |||
ПРЧ | Прочие возможности протокола | |||
УЛЗ, тип 3 | ||||
ПпК | Командные ПБД ПДп | |||
П0К | ПБД ПД0_КМД | |||
П0О | ПБД ПД0_ОТВ | |||
П1К | ПБД ПД1_КМД | |||
П1О | ПБД ПД1_ОТВ | |||
П0Пд | Параметры в передаваемых ПБД ПД0 | |||
П1Пд | Параметры в передаваемых ПБД ПД1 | |||
П0Пм | Параметры в принимаемых ПБД ПД0 | |||
П1Пм | Параметры в принимаемых ПБД ПД1 | |||
ОПП | Процедуры протокола | |||
ППР | Параметры протокола | |||
ПРЧ | Прочие возможности протокола |
В.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 Сводные сведения о протоколе
Идентификация спецификации протокола | ГОСТ 28907 |
Идентификация изменений и поправок к данной форме ЗСРП, которая заполнена как часть данной ЗСРП | ГОСТ 28907 |
Требуются ли какие-либо особые позиции (В.3.3)? (см. Нет [ ] Да [ ]) |
Дата заявки |
В.5 Основные возможности
Позиция | Возможности протокола | Ссылки | Статус | Обеспечение |
*КЛС1а | Обеспечивается ли класс I УЛЗ? | 4.2 | Ф.1 | Да [ ] Нет [ ] |
КЛС1b | Обеспечиваются ли процедуры УЛЗ типа 1? | 4.2 | КЛС1а:О | Да [ ] |
*КЛС2а | Обеспечивается ли класс II УЛЗ? | 4.2 | Ф.1 | Да [ ] Нет [ ] |
КЛС2b | Обеспечиваются ли процедуры УЛЗ типов 1 и 2? | 4.2 | КЛС2а:О | Н/И [ ] Да [ ] |
*КЛСЗа | Обеспечивается ли класс III УЛЗ? | 4.2 | Ф.1 | Да [ ] Нет [ ] |
КЛС3b | Обеспечиваются ли процедуры УЛЗ типов 1 и 3? | 4.2 | КЛС3а:О | Н/И [ ] Да [ ] |
*КЛС4а | Обеспечивается ли класс IV УЛЗ? | 4.2 | Ф.1 | Да [ ] Нет [ ] |
КЛС4b | Обеспечиваются ли процедуры УЛЗ типов 1, 2 и 3? | 4.2 | КЛС4а:О | Н/И [ ] Да [ ] |
*ОМР | Обеспечивается ли определение маршрута? | 10 | Ф | Да [ ] Нет [ ] |
В.6 Операции УЛЗ типа 1. Режим без установления соединения и без подтверждений
КЛС1а ИЛИ КЛС2а ИЛИ КЛС3а ИЛИ КЛС4а::
Все таблицы в разделе В.6 должны быть заполнены, если перечисленные выше предикаты оценены как "истинные".
В.6.1 УЛЗ, тип 1. Обеспечиваемые типы ПБД
Позиция | Возможности протокола. Обеспечиваемые типы ПБД | Ссылки | Статус | Обеспечение |
НИ/1 | НИ_КМД, обеспечивается при передаче | 6.1, 6.5.1 | О | Да [ ] |
НИ/2 | НИ_КМД, обеспечивается при приеме | 6.1, 6.5.1 | О | Да [ ] |
*ИДС/3 | ИДС_КМД, обеспечивается при передаче | 6.6 | Ф | Да [ ] Нет [ ] |
ИДС/4 | ИДС_КМД, обеспечивается при приеме | 6.6 | О | Да [ ] |
ИДС/5 | ИДС_ОТВ, обеспечивается при передаче | 6.6 | О | Да [ ] |
ИДС/6 | ИДС_ОТВ, обеспечивается при приеме | 6.6 | ИДС/3:О | Н/И [ ] Да [ ] |
*ТЕС/7 | ТЕСТ_КМД, обеспечивается при передаче | 6.7 | Ф | Да [ ] Нет [ ] |
ТЕС/8 | ТЕСТ_КМД, обеспечивается при приеме | 6.7 | О | Да [ ] |
ТЕС/9 | ТЕСТ_ОТВ, обеспечивается при передаче | 6.7 | О | Да [ ] |
ТЕС/10 | ТЕСТ_ОТВ, обеспечивается при приеме | 6.7 | ТЕСТ/7:О | Н/И [ ] Да [ ] |
В.6.2 УЛЗ, тип 1. Обеспечиваемые параметры в ПБД при передаче
Позиция | Возможности протокола. Обеспечиваемые параметры при передаче | Ссылки | Статус | Обеспечение |
НИПд/11 | НИ_КМД - адрес ПДУП | 6.2 | О | Да [ ] |
НИПд/12 | НИ_КМД - ПДУО | 6.2 | О | Да [ ] |
НИПд/13 | НИ_КМД - бит З=0 | 6.3 | О | Да [ ] |
НИПд/14 | НИ_КМД - информация | 3.3 | Ф | Да [ ] Нет [ ] |
ИДПд/15 | ИДС_КМД - адрес ПДУП | 6.2, 6.6 | ИДС/З:О | Н/И [ ] Да [ ] Нет [ ] |
ИДПд/16 | ИДС_КМД - адрес ПДУО | 6.2, 6.6 | ИДС/З:О | Н/И [ ] Да [ ] Нет [ ] |
ИДПд/17 | ИДС_КМД - бит З=1 | 6.3 | ИДС/З:Ф.2 | Н/И [ ] Да [ ] Нет [ ] |
ИДПд/18 | ИДС_КМД - бит З=0 | 6.3 | ИДС/З:Ф.2 | Н/И [ ] Да [ ] Нет [ ] |
ИДПд/19 | ИДС_КМД - информация | 5.4.1.1.2, 6.6 | ИДС/З:О | Н/И [ ] Да [ ] Нет [ ] |
ИДПд/20 | ИДС_ОТВ - адрес ПДУП | 6.2, 6.6 | О | Да [ ] |
ИДПд/21 | НДС_ОТВ - адрес ПДУО | 6.2, 6.6 | О | Да [ ] |
ИДПд/22 | ИДС_ОТВ - бит П=бит З | 6.3 | О | Да [ ] |
ИДПд/23 | ИДС_ОТВ - информация | 5.4.1.2.1, 6.6 | О | Да [ ] |
ТСПд/24 | ТЕСТ_КМД - адрес ПДУП | 6.2 | ТСПд/7:О | Н/И [ ] Да [ ] Нет[ ] |
ТСПд/25 | ТЕСТ_КМД - адрес ПДУО | 6.2 | ТСПд/7:О | Н/И [ ] Да [ ] Нет [ ] |
ТСПд/26 | ТЕСТ_КМД - бит З=1 | 6.3 | ТСПд/7:Ф.З | Н/И [ ] Да [ ] Не [ ] |
ТСПд/27 | ТЕСТ_КМД - бит З=0 | 6.3 | ТСПд/7:Ф.З | Н/И [ ] Да [ ] Нет [ ] |
ТСПд/28 | ТЕСТ_КМД - информация | 5.4.1.1.3, 6.7 | ТСПд/7:0 | Н/И [ ] Да [ ] Нет [ ] |
ТСПд/29 | ТЕСТ_ОТВ - адрес ПДУП | 6.2 | О | Да [ ] |
ТСПд/30 | ТЕСТ_ОТВ - адрес ПДУО | 6.2 | О | Да [ ] |
ТСПд/31 | ТЕСТ_ОТВ - бит П=бит З | 6.3 | О | Да [ ] |
ТСПд/32 | ТЕСТ_ОТВ - информация | 5.4.1.2.2, 6.7 | О | Да [ ] |
В.6.3 УЛЗ, тип 1. Обеспечиваемые параметры в ПБД при приеме
Позиция | Возможности протокола. Обеспечиваемые параметры при приеме | Ссылки | Статус | Обеспечение |
НИПм/33 | НИ_КМД - адрес ПДУП | 6.2 | О | Да [ ] |
НИПм/34 | НИ_КМД-ПДУО | 6.2 | О | Да [ ] |
НИПм/35 | НИ_КМД-битЗ=0 | 6.3 | О | Да [ ] |
НИПм/36 | НИ_КМД - информация | 6.3 | Ф | Да [ ] Нет [ ] |
ИДПм/37 | ИДС_КМД - адрес ПДУП | 6.2, 6.6 | О | Да [ ] |
ИДПм/38 | ИДС_КМД - адрес ПДУО | 6.2, 6.6 | О | Да [ ] |
ИДПм/39 | ИДС_КМД - бит З=1 | 6.3 | О | Да [ ] |
ИДПм/40 | ИДС_КМД - бит З=0 | 6.3 | О | Да [ ] |
ИДПм/41 | ИДС_КМД - информация | 5.4.1.1.2, 6.6 | О | Да[ ] |
ИДПм/42 | ИДС_ОТВ - адрес ПДУП | 6.2, 6.6 | О | Да [ ] |
ИДПм/43 | ИДС_ОТВ - адрес ПДУО | 6.2, 6.6 | О | Да [ ] |
ИДПм/44 | ИДС_ОТВ - бит П=бит З | 6.3 | О | Да [ ] |
ИДПм/45 | ИДС_ОТВ - информация | 5.4.1.2.1, 6.6 | О | Да [ ] |
ТСПм/46 | ТЕСТ_КМД - адрес ПДУП | 6.2 | О | Да [ ] |
ТСПм/47 | ТЕСТ_КМД - адрес ПДУО | 6.2 | О | Да [ ] |
ТСПм/48 | ТЕСТ_КМД - бит З=1 | 6.3 | О | Да [ ] |
ТСПм/49 | ТЕСТ_КМД - бит З=0 | 6.3 | О | Да [ ] |
ТСПм/50 | ТЕСТ_КМД - информация | 5.4.1.1.3, 6.7 | О | Да [ ] |
ТСПм/51 | ТЕСТ_ОТВ - адрес ПДУП | 6.2 | О | Да [ ] |
ТСПм/52 | ТЕСТ_ОТВ - адрес ПДУО | 6.2 | О | Да [ ] |
ТСПм/53 | ТЕСТ_ОТВ - бит П=бит З | 6.3 | О | Да [ ] |
ТСПм/54 | ТЕСТ_ОТВ - информация | 5.4.1.2.2, 6.7 | ТСПд/28:О | Н/И [ ] Да [ ] |
В.6.4 УЛЗ, тип 1. Прочие возможности протокола
Позиция | Прочие функциональные возможности протокола | Ссылки | Статус | Обеспечение |
ПРЧ/55 | Все ли передаваемые ПБД содержат целое число октетов? | 3.3 | О | Да [ ] |
Если следующие ПБД получены из подуровня УДС, они рассматриваются как недействительные и игнорируются? | ||||
ПРЧ/56 | - не содержат целого числа октетов | 3.3.4 | О | Да [ ] |
ПРЧ/57 | - их длина меньше трех октетов | 3.3.4 | О | Да [ ] |
Какие из перечисленных ниже адресов обеспечиваются в поле "адрес ПДУП" ПБД НИ? | ||||
ПРЧ/58 | - индивидуальный адрес | 5.4.1.1.1 | Ф.4 | Да [ ] Нет [ ] |
ПРЧ/59 | - групповой адрес | 5.4.1.1.1 | Ф.4 | Да [ ] Нет [ ] |
ПРЧ/60 | - глобальный адрес | 5.4.1.1.1 | Ф.4 | Да [ ] Нет [ ] |
ПРЧ/61 | - нулевой адрес | 5.4.1.1.1 | Ф.4 | Да [ ] Нет [ ] |
ПРЧ/62 | Является ли адрес в поле "адрес ПДУО" ПБД НИ индивидуальным адресом отправителя? | 5.4.1.1.1 | О | Да [ ] |
ПРЧ/63 | Все ли ПБД НИ передаются в виде ПБД НИ_КМД? | 6.5.1 | О | Да [ ] |
ПРЧ/64 | Все ли ПБД НИ_КМД передаются с битом З=1? | 6.5.1 | О | Да [ ] |
ПРЧ/65 | Если получен ПБД НИ_ОТВ, аннулируется ли кадр? | 6.5.2 | О | Да [ ] |
Какие из перечисленных ниже адресов обеспечиваются в поле "адрес ПДУП" ПБД ИДС_КМД? | ||||
ПРЧ/66 | - индивидуальный адрес | 5.4.1.1.2 | ИДС/3:Ф.6 | Н/И [ ] Да [ ] Нет [ ] |
ПРЧ/67 | - групповой адрес | 5.4.1.1.2 | ИДС/3:Ф.6 | Н/И [ ] Да [ ] Нет [ ] |
ПРЧ/68 | - глобальный адрес | 5.4.1.1.2 | ИДС/3:Ф.6 | Н/И [ ] Да [ ] Нет [ ] |
ПРЧ/69 | - нулевой адрес | 5.4.1.1.2 | ИДС/3:Ф.6 | Н/И [ ] Да [ ] Нет [ ] |
Какие из перечисленных ниже адресов обеспечиваются в поле "адрес ПДУО" ПБД ИДС_КМД? | ||||
ПРЧ/70 | - индивидуальный адрес | 5.4.1.1.2 | ИДС/3:Ф.6 | Н/И [ ] Да [ ] Нет [ ] |
ПРЧ/71 | - нулевой адрес | 5.4.1.1.2 | ИДС/3:Ф.6 | Н/И [ ] Да [ ] Нет [ ] |
Какие из перечисленных ниже адресов обеспечиваются в поле "адрес ПДУП" ПБД ИДС_ОТВ? | ||||
ПРЧ/72 | - индивидуальный адрес | 5.4.1.2.1 | О | Да [ ] |
ПРЧ/73 | - нулевой адрес | 5.4.1.2.1 | О | Да[] |
Какие из перечисленных ниже адресов обеспечиваются в поле "адрес ПДУО" ПБД ИДС_ОТВ? | ||||
ПРЧ/74 | - индивидуальный адрес | 5.4.1.2.1 | О | Да [ ] |
ПРЧ/75 | - нулевой адрес | 5.4.1.2.1 | О | Да [ ] |
Какие из перечисленных ниже адресов обеспечиваются в поле "адрес ПДУП" ПБД ТЕСТ_КМД? | ||||
ПРЧ/76 | - индивидуальный адрес | 5.4.1.1.3 | ТСПд/7:Ф.7 | Н/И [ ] Да [ ] Нет [ ] |
ПРЧ/77 | - групповой адрес | 5.4.1.1.3 | ТСПд/7:Ф.7 | Н/И [ ] Да [ ] Нет [ ] |
ПРЧ/78 | - глобальный адрес | 5.4.1.1.3 | ТСПд/7:Ф.7 | Н/И [ ] Да [ ] Нет [ ] |
ПРЧ/79 | - нулевой адрес | 5.4.1.1.3 | ТСПд/7:Ф.7 | Н/И [ ] Да [ ] Нет [ ] |
Какие из перечисленных ниже адресов обеспечиваются в поле "адрес ПДУО" ПБД ТЕСТ_КМД? | ||||
ПРЧ/80 | - индивидуальный адрес | 5.4.1.1.3 | ТСПд/7:Ф.8 | Н/И [ ] Да [ ] Нет [ ] |
ПРЧ/81 | - нулевой адрес | 5.4.1.1.3 | ТСПд/7:Ф.8 | Н/И [ ] Да [ ] Нет [ ] |
Какие из перечисленных ниже адресов обеспечиваются в поле "адрес ПДУП" ПБД ТЕСТ_ОТВ? | ||||
ПРЧ/82 | - индивидуальный адрес | 5.4.1.2.2 | О | Да [ ] |
ПРЧ/83 | - нулевой адрес | 5.4.1.2.2 | О | Да [ ] |
Какие из перечисленных ниже адресов обеспечиваются в поле "адрес ПДУО" ПБД ТЕСТ_ОТВ? | ||||
ПРЧ/84 | - индивидуальный адрес | 5.4.1.2.2 | О | Да [ ] |
ПРЧ/85 | - нулевой адрес | 5.4.1.2.2 | О | Да [ ] |
*ПРЧ/86 | Обеспечивается ли проверка дублирования адреса? | 6.9.2 | Ф | Да [ ] Нет [ ] |
ПРЧ/87 | - Обеспечивается ли функция ТАЙМ-АУТ_ ПДТ? | 6.9.2 | ПРЧ/86:О | Н/И [ ] Да [ ] |
ПРЧ/88 | - Диапазон ТАЙМ-АУТ_ПДТ (с) | Минимальное значение = | ||
ПРЧ/89 | - Обеспечивается ли функция СЧЕТ_ПОВТОРЕНИЙ? | 6.9.2 | ПРЧ/88:О | Н/И [ ] Да [ ] |
ПРЧ/90 | - Диапазон СЧЕТ_ПОВТОРЕНИЙ (с) | Минимальное значение = | ||
ПРЧ/91 | - Обеспечивается ли функция СЧЕТ_ ИДС_ОТВ? | 6.9.2 | ПРЧ/88:О | Да [ ] |
В.7 Операции УЛЗ типа 2. Режим с установлением соединения
КЛС2а ИЛИ КЛС4а::
Все таблицы в разделе В.7 должны быть заполнены, если перечисленные выше предикаты оценены как "истинные".
В.7.1 УЛЗ, тип 2. Обеспечиваемые типы ПБД
Позиция | Возможности протокола. | Ссылки | Статус | Обеспечение |
*ИП/92а | ПБД И, обеспечивается при передаче | 7.4.2 | Ф | Да [ ] Нет [ ] |
*ИК/92b | И_КМД, обеспечивается при передаче | Таблица 7-1 | ИП/92а:Ф | Н/И [ ] Да [ ] Нет [ ] |
ИК/93 | И_КМД, обеспечивается при приеме | То же | О | Да [ ] |
ИК/94 | И_ОТВ, обеспечивается при передаче | " | ИП/92а:О | Н/И [ ] Да [ ] |
ИК/95 | И_ОТВ, обеспечивается при приеме | " | О | Да [ ] |
ГПК/96 | ГПР_КМД, обеспечивается при передаче | " | О | Да [ ] |
ГПК/97 | ГПР_КМД, обеспечивается при приеме | " | О | Да [ ] |
ГПО/98 | ГПР_ОТВ, обеспечивается при передаче | " | О | Да [ ] |
ГПО/99 | ГПР_ОТВ, обеспечивается при приеме | " | О | Да [ ] |
НГК/100 | НГПР_КМД, обеспечивается при передаче | " | О | Да [ ] |
НГК/101 | НГПР_КМД, обеспечивается при приеме | " | О | Да [ ] |
НГО/102 | НГПР_ОТВ, обеспечивается при передаче | " | О | Да [ ] |
НГО/103 | НГПР_ОТВ, обеспечивается при приеме | " | О | Да [ ] |
*НПК/104 | НПР_КМД, обеспечивается при передаче | " | Ф | Да [ ] Нет [ ] |
НПК/105 | НПР_КМД, обеспечивается при приеме | " | О | Да [ ] |
НПО/106 | НПР_ОТВ, обеспечивается при передаче | " | О | Да [ ] |
НПО/107 | НПР_ОТВ, обеспечивается при приеме | " | О | Да [ ] |
УРК/108 | УРРАС_КМД, обеспечивается при передаче | " | О | Да [ ] |
УРК/109 | УРРАС_КМД, обеспечивается при приеме | " | О | Да [ ] |
РЗК/110 | РЗД_КМД, обеспечивается при передаче | " | О | Да [ ] |
РЗК/111 | РЗД_КМД, обеспечивается при приеме | " | О | Да [ ] |
НПО/112 | НП_ОТВ, обеспечивается при передаче | " | О | Да [ ] |
НПО/113 | НП_ОТВ, обеспечивается при приеме | " | О | Да [ ] |
ФРО/114 | ФРЗД_ОТВ, обеспечивается при передаче | " | О | Да [ ] |
ФРО/115 | ФРЗД_ОТВ, обеспечивается при приеме | " | О | Да [ ] |
НКО/116 | НПРК_ОТВ, обеспечивается при передаче | " | О | Да [ ] |
НКО/117 | НПРК_ОТВ, обеспечивается при приеме | " | О | Да [ ] |
В.7.2 УЛЗ, тип 2. Обеспечиваемые параметры в ПБД
Позиция | Возможности протокола. Обеспечиваемые параметры при передаче | Ссылки | Статус | Обеспечение |
Содержат ли следующие ПБД адрес ПДУП, адрес ПДУО и поле управления, как определено в указанных в "Ссылках" разделах? | ||||
ППд/118а | - И_КМД | 3.2, 3.3, 5.4 | ИК/92b:О | Н/И [ ] Да [ ] |
ППд/118b | - И_ОТВ | 3.2, 3.3, 5.4 | ИП/92b:О | Н/И [ ] Да [ ] |
ППд/119 | - НПР_КМД | 3.2, 3.3, 5.4 | НПР/104:О | Н/И [ ] Да [ ] |
ППд/120 | - И_ОТВ, ГПР_КМД, ГПР_ОТВ, НГПР_КМД, НГПР _ОТВ, НПР_КМД, УРРАС_КМД, РЗД_КМД, НП_ОТВ, ФРЗД_ОТВ, НПРК_ОТВ | 3.2, 3.3, 5.4 | О | Да [ ] |
Содержат ли следующие ПБД поле информации? | Да [ ] | |||
ППд/121 | - И_КМД, И_ОТВ, НПРК_ОТВ | 3.2, 3.3, 5.4 | О | |
Содержат ли следующие ПБД поле информации? | ||||
ППд/122 | - НПР_КМД, ГПР_КМД, ГПР_ОТВ, НГПР_КМД, НГПР_ОТВ, НПР_ОТВ, УРРАС_КМД, РЗД_КМД, НП_ ОТВ, ФРЗД_ОТВ | 3.2, 3.3, 5.4 | З | Нет [ ] |
Обеспечивается ли прием адресов ПДУП, ПДУО и поля управления для следующих ПБД? | ||||
ППм/123 | - И_КМД, И_ОТВ, ГПР_КМД, ГПР_ОТВ, НГПР_КМД, НГПР_ОТВ, НПР_КМД, НПР_ОТВ, УРРАС_КМД, РЗД_КМД, НП_ОТВ, ФРЗД_ОТВ, НПРК_ОТВ | 3.2, 3.3, 5.4 | О | Да [ ] |
Обеспечивается ли прием поля управления в следующих ПБД? | ||||
ППм/124 | - И_КМД, И_ОТВ, НПРК_ОТВ | 3.2, 3.3, 5.4 | О | Да [ ] |
(Примечание - Ответ на получение ПБД, в котором не разрешено поле информации, но который содержит его, определяется процедурами "неприем кадра".) |
В.7.3 УЛЗ, тип 2. Обеспечиваемые процедуры
Позиция | Возможности протокола. Обеспечиваемые процедуры | Ссылки | Статус | Обеспечение |
Обеспечение установления соединения | ||||
ОПР/125 | - инициатором | 7.4.1, 7.4.5 | Ф | Да [ ] Нет [ ] |
ОПР/126 | - ответчиком | 7.4.1, 7.4.5 | О | Да [ ] |
Обеспечение освобождения соединения | ||||
ОПР/127 | - инициатором (освобождение отправителем) | 7.4.3, 7.4.4, 7.4.5 | Ф | Да [ ] Нет [ ] |
ОПР/128 | - инициатором (отклонение установления соединения) | 7.4.3, 7.4.4, 7.4.5 | О | Да [ ] |
ОПР/129 | - ответчиком | 7.4.3, 7.4.4, 7.4.5 | О | Да [ ] |
Обеспечение передачи данных | ||||
ОПР/130 | - инициатором | 7.4.2, 7.5 | Ф | Да [ ] Нет [ ] |
ОПР/131 | - ответчиком | 7.4.2, 7.5 | О | Да [ ] |
ОПР/132 | Обеспечивается ли процедура "удаленная занятость" при приеме ПБД НГПР? | 7.5.7 | О | Да [ ] |
ОПР/133 | Обеспечивается ли процедура "повторная передача" при приеме ПБД НПР? | 7.5.6 | О | Да [ ] |
ОПР/134 | Обеспечивается ли процедура "неприем" при приеме ПБД И с неожидаемым Нпд? | 7.4.2, 7.5 | О | Да [ ] |
ОПР/135 | Обеспечивается ли процедура "локальная занятость"? | 7.5.8 | О | Да [ ] |
ОПР/136 | Обеспечивается ли процедура "неприем кадра"? | 5.4.2.3.5.5 | О | Да [ ] |
Обеспечивается ли процедура "сброс" | ||||
ОПР/137 | - инициатором | 7.5, 7.6, 7.7 | О | Да [ ] |
ОПР/138 | - ответчиком | 7.5, 7.6, 7.7 | О | Да [ ] |
ОПР/139 | Обеспечивается ли процедура "управления потоком УЛЗ"? | ИСО 8802-2/Изм.1 | Ф | Да [ ] Нет [ ] |
В.7.4 УЛЗ, тип 2. Прочие возможности протокола
Позиция | Прочие возможности протокола | Ссылки | Статус | Обеспечение |
ПРЧ/140 | Содержат ли все передаваемые ПБД целое число октетов? | 3.3 | О | Да [ ] |
При получении следующих ПБД из подуровня УДС рассматриваются ли они как недействительные и игнорируются? | ||||
ПРЧ/141 | - содержат нецелое число октетов | 3.3.4 | О | Да [ ] |
ПРЧ/142 | - имеют длину менее трех октетов (в случае однооктетного поля управления) | 3.3.4 | О | Да [ ] |
ПРЧ/143 | - имеют длину менее четырех октетов (в случае двухоктетного поля управления) | 3.3.4 | О | Да [ ] |
В.7.5 УЛЗ, тип 2. Параметры протокола
Позиция | Возможности протокола. | Ссылки | Статус | Обеспечение/Значение |
ПАП/144 | Реализована ли функция ТАЙМ-АУТ_ПДТ? | 7.8.1.1 | О | Да [ ] |
ПАП/145 | - Диапазон ТАЙМ-АУТА_ПДТ | Минимальное значение = | ||
ПАП/146 | Реализована ли функция ТАЙМ-АУТ_бита З? | 7.8.1.2 | О | Да [ ] |
ПАП/147 | - Диапазон ТАЙМ-АУТА_бита З | Минимальное значение = Максимальное значение = | ||
ПАП/148 | Реализована ли функция ТАЙМ-АУТ_НПР? | 7.8.1.3 | О | Да [ ] |
ПАП/149 | - Диапазон ТАЙМ-АУТА_НПР | Минимальное значение = | ||
ПАП/150 | Реализована ли функция ТАЙМ-АУТ_ЗАНЯТОСТИ? | 7.8.1.4 | О | Да [ ] |
ПАП/151 | - Диапазон ТАЙМ_АУТА_ЗАНЯТОСТИ | Минимальное значение = | ||
ПАП/152 | Реализована ли функция N2 (максимальное число передач)? | 7.8.2 | О | Да [ ] |
ПАП/153 | - Число передач | Минимальное значение = Максимальное значение = | ||
ПАП/154 | Реализована ли функция k (размер окна на передаче)? | 7.8.4 | О | Да [ ] |
ПАП/155 | - Максимальное значение k | Значение = | ||
ПАП/156 | Реализована ли функция управления потоком УЛЗ? | ИСО 8802-2/Изм.1 | ЭПР/139:0 | Н/И [ ] Да [ ] |
ПАП/157а | - Диапазон шага К | Минимальное значение = | ||
ПАП/157b | Реализована ли функция РО (размер окна) на приеме? | 7.8.6 | О | Да [ ] |
ПАП/157с | - Максимальное значение РО | Значение = |
В.8 Операции УЛЗ типа 3. Режим без установления соединения с подтверждениями
КЛСЗа ИЛИ КЛС4а::
Все таблицы в разделе В.8 должны быть заполнены, если перечисленные выше предикаты оценены как "истинные".
В.8.1 УЛЗ, тип 3. Обеспечиваемые типы ПБД
Позиция | Возможности протокола. Обеспечиваемые типы ПБД | Ссылки | Статус | Обеспечение |
ПпК/158а | Все передаваемые команды ПКn | 8.5.1 | О | Да [ ] Нет [ ] |
П0К/158b | ПД0_КМД, обеспечиваемые при передаче | 8.5.1 | ПnК/158а:О | Н/И [ ] Да [ ] |
П0К/159 | ПД0_КМД, обеспечиваемые при приеме | 8.5.2 | О | Да [ ] |
П0К/160 | ПД0_ОТВ, обеспечиваемые при передаче | 8.5.3 | О | Да [ ] |
П0К/161 | ПД0_ОТВ, обеспечиваемые при приеме | 8.5.4 | ПnК/158а:О | Н/И [ ] Да [ ] |
П1К/162 | ПД1_КМД, обеспечиваемые при передаче | 8.5.1 | ПnК/158а:О | Н/И [ ] Да [ ] |
П1К/163 | ПД1_КМД, обеспечиваемые при приеме | 8.5.2 | О | Да [ ] |
П1О/164 | ПД1_ОТВ, обеспечиваемые при передаче | 8.5.3 | О | Да [ ] |
П 1О/165 | ПД1_ОТВ, обеспечиваемые при приеме | 8.5.4 | ПnК/158а:0 | Н/И[ ] Да[ ] |
В.8.2 УЛЗ, тип 3. Обеспечиваемые параметры в ПБД при передаче
Позиция | Возможности протокола. Обеспечиваемые параметры при передаче | Ссылки | Статус | Обеспечение |
П0Пд/166 | ПД0_КМД - адрес ПДУП | 8.2 | ПnК/158а:0 | Н/И [ ] Да [ ] |
П0Пд/167 | ПД0_КМД - адрес ПДУО | 8.2 | ПnК/158а:0 | Н/И [ ] Да [ ] |
ПД0 КМД - | ||||
П0Пд/168 | - бит З=1 и ненулевое поле информации | 8.3 | ПnК/158а:Ф.9 | Н/И [ ] Да [ ] Нет [ ] |
П0Пд/169 | - бит З=1 и нулевое поле информации | 8.3 | ПnК/158а:Ф.9 | Н/И [ ] Да [ ] Нет [ ] |
ПДО_КМД - | ||||
П0Пд/170 | - бит З=0 и ненулевое поле информации | 8.3 | ПnК/158а:Ф.9 | Н/И [ ] Да [ ] Нет [ ] |
П0Пд/171 | - бит З=0 и нулевое поле информации | 8.3 | ПnК/158а:Ф.9 | Н/И [ ] Да [ ] Нет [ ] |
П1ПД/172 | ПД1_КМД - адрес ПДУП | 8.2 | ПnК/158а:О | Н/И [ ] Да [ ] |
П1Пд/173 | ПД1_КМД - адрес ПДУО | 8.2 | ПnК/158а:О | Н/И [ ] Да [ ] |
ПД1_КМД - | ||||
П1Пд/174 | - бит З=1 и ненулевое поле информации | 8.3 | ПnК/158а:Ф.10 | Н/И [ ] Да [ ] Нет [ ] |
П1Пд/175 | - бит З= 1 и нулевое поле информации | 8.3 | ПnК/158а:Ф.10 | Н/И [ ] Да [ ] Нет [ ] |
ПД1_КМД - | ||||
П1Пд/176 | - бит З=0 и ненулевое поле информации | 8.3 | ПnК/158а:Ф.10 | Н/И [ ] Да [ ] Нет [ ] |
П1ПД/177 | - бит З=0 и нулевое поле информации | 8.3 | ПnК/158а:Ф.10 | Н/И [ ] Да [ ] Нет [ ] |
П0Пд/178 | ПД0_ОТВ - адрес ПДУП | 8.2 | О | Да [ ] |
П0Пд/179 | ПД0_ОТВ - адрес ПДУО | 8.2 | О | Да [ ] |
ПД0_ОТВ - бит П = бит З (=1) | ||||
П0Пд/180 | - с подполем "статус" и ненулевым подполем СБДЗ | 8.3 | Ф | Да [ ] |
П0Пд/181 | - с подполем "статус" и нулевым подполем СБДЗ | 8.3 | О | Да [ ] |
ПД0_ОТВ - бит П=бит З (=0) | ||||
П0Пд/182 | - с подполем "статус" и ненулевым подполем СБДЗ | 8.3 | З | Да [ ] |
П0Пд/183 | - с подполем "статус" и нулевым подполем СБДЗ | 8.3 | О | Да [ ] |
П1Пд/184 | ПД1_ОТВ - адрес ПДУП | 8.2 | О | Да [ ] |
П1Пд/185 | ПД1_ОТВ - адрес ПДУО | 8.2 | О | Да [ ] |
ПД1_ОТВ - бит П=бит З (=1) | ||||
П1Пд/186 | - с подполем "статус" и ненулевым подполем СБДЗ | 8.3 | Ф | Да [ ] |
П1Пд/187 | - с подполем "статус" и нулевым подполем СБДЗ | 8.3 | О | Да [ ] |
ПД1_ОТВ - бит П=бит З (=0) | ||||
П1Пд/188 | - с подполем "статус" и ненулевым подполем СБДЗ | 8.3 | З | Да [ ] |
П1Пд/189 | - с подполем "статус" и нулевым подполем СБДЗ | 8.3 | О | Да [ ] |
В.8.3 УЛЗ, тип 3. Обеспечиваемые параметры в ПБД при приеме
Позиция | Возможности протокола. Обеспечиваемые параметры при приеме | Ссылки | Статус | Обеспечение |
П0Пм/190 | ПД0_КМД - адрес ПДУП | 8.1,8.2 | О | Да [ ] |
П0Пм/191 | ПД0_КМД - адрес ПДУО | 8.1, 8.2 | О | Да [ ] |
ПД0_КМД - | ||||
П0Пм/192 | - бит З=1 и ненулевое поле информации | 8.1, 8.3 | О | Да [ ] |
П0Пм/193 | - бит З=1 и нулевое поле информации | 8.1, 8.3 | О | Да [ ] |
ПД0_КМД- | ||||
П0Пм/194 | - бит З=0 и ненулевое поле информации | 8.1, 8.3 | О | Да [ ] |
П0Пм/195 | - бит З=0 и нулевое поле информации | 8.1, 8.3 | О | Да [ ] |
П1Пм/196 | ПД1_КМД - адрес ПДУП | 8.1, 8.2 | О | Да [ ] |
П1Пм/197 | ПД1_КМД - адрес ПДУО | 8.1, 8.2 | О | Да [ ] |
ПД1_КМД - | ||||
П1Пм/198 | - бит З=1 и ненулевое поле информации | 8.1, 8.3 | О | Да [ ] |
П1Пм/199 | - бит З=1 и нулевое поле информации | 8.1, 8.3 | О | Да [ ] |
ПД1_КМД - | ||||
П1Пм/200 | - бит З=0 и ненулевое поле информации | 8.1, 8.3 | О | Да [ ] |
П1Пм/201 | - бит З=0 и нулевое поле информации | 8.1, 8.3 | О | Да [ ] |
П0Пм/202 | ПД0_ОТВ - адрес ПДУП | 8.1, 8.2 | О | Да [ ] |
П0Пм/203 | ПД0_ОТВ - адрес ПДУО | 8.1, 8.2 | О | Да [ ] |
ПД0_ОТВ - бит П=бит 3 (=1) | ||||
П0Пм/204 | - с подполем "статус" и ненулевым подполем СБДЗ | 8.1, 8.3 | О | Да [ ] |
П0Пм/205 | - с подполем "статус" и нулевым подполем СБДЗ | 8.1, 8.3 | О | Да [ ] |
ПД0_ОТВ - бит П=бит З (=0) | ||||
П0Пм/206 | - с подполем "статус" и ненулевым подполем СБДЗ | 8.1, 8.3, 8.7.2 | О | Да [ ] |
П0Пм/207 | - с подполем "статус" и нулевым подполем СБДЗ | 8.1, 8.3 | О | Да [ ] |
П1Пм/208 | ПД1_ОТВ - адрес ПДУП | 8.1, 8.2 | О | Да [ ] |
П1Пм/209 | ПД1_ОТВ - адрес ПДУО | 8.1, 8.2 | О | Да [ ] |
ПД1_ОТВ - бит П=бит З (=1) | ||||
П1Пм/210 | - с подполем "статус" и ненулевым подполем СБДЗ | 8.1, 8.3 | О | Да [ ] |
П1Пм/211 | - с подполем "статус" и нулевым подполем СБДЗ | 8.1, 8.3 | О | Да [ ] |
ПД1_ОТВ - бит П=бит З (=0) | ||||
П1Пм/212 | - с подполем "статус" и ненулевым подполем СБДЗ | 8.1, 8.3, 8.7.2 | О | Да [ ] |
П1Пм/213 | - с подполем "статус" и нулевым подполем СБДЗ | 8.1, 8.3 | О | Да [ ] |
В.8.4 УЛЗ, тип 3. Обеспечиваемые процедуры
Позиция | Возможности протокола. | Ссылки | Статус | Обеспечение |
ППС/214 | Обеспечивается ли процедура повторной синхронизации порядковых номеров? | 8.4, 8.4.1 | ПnК/158а:О | Н/И [ ] Да [ ] Нет [ ] |
ОПР/215а | Обеспечивается ли процедура аннулирования переменной передачи Ппд? | 8.4, 8.4.1 | ПnК/158а:О | Н/И [ ] Да [ ] Нет [ ] |
ОПР/215b | Обеспечивается ли процедура аннулирования переменной передачи Ппд и переменной приема Ппм? | 8.4, 8.4.3 | Ф | Да [ ] Нет[ ] |
Обеспечиваются ли процедуры передачи информации | ||||
ОПР/216 | - для случая общих возможностей УДС? | 8.5, 8.5.1, | Ф.11 | Да [ ] Нет [ ] |
ОПР/217 | - для случая некоторых специальных возможностей УДС? | 8.5, 8.5.1, 8.5.2.2, 8.5.3, 8.5.4.3 | Ф.11 | Да [ ] Нет [ ] |
В.8.5 УЛЗ, тип 3. Прочие возможности протокола
Позиция | Прочие возможности протокола | Ссылки | Статус | Обеспечение |
ПРЧ/218 | Содержат ли все передаваемые ПБД целое число октетов? | 3.3 | О | Да [ ] |
При получении следующих ПБД из подуровня УДС обрабатываются ли они как недействительные и игнорируются? | ||||
ПРЧ/219 | - содержат нецелое число октетов | 3.3.4 | О | Да [ ] |
ПРЧ/220 | - имеют длину менее трех октетов | 3.3.4 | О | Да [ ] |
Примечание - Прием ПД0_ОТВ или ПД1_ОТВ с битом 8 поля управления, равным Ппд, рассматривается в позициях ОПР/216 и ОПР/217 | ||||
Какие из перечисленных ниже адресов обеспечиваются в поле "адрес ПДУП" ПБД ПД0_КМД и ПД1_КМД? | ||||
ПРЧ/221 | - индивидуальный адрес | 5.4.3.1 | Ф.12 | Да [ ] Нет [ ] |
ПРЧ/222 | - групповой адрес | 5.4.3.1 | Ф.12 | Да [ ] Нет [ ] |
ПРЧ/223 | - глобальный адрес | 5.4.3.1 | Ф.12 | Да [ ] Нет [ ] |
ПРЧ/224 | Является ли адрес в поле "адрес ПДУО" ПБД ПД0_КМД и ПД1_КМД индивидуальным адресом отправителя? | 5.4.3.1 | О | Да [ ] |
Является ли адрес в поле "адрес ПДУП" ПБД ПД0_ОТВ и ПД1_ОТВ | ||||
ПРЧ/225 | - индивидуальным адресом соответствующего отправителя ПД0_КМД или ПД1_ КМД? | 5.4.3.2 | О | Да [ ] |
Является ли адрес в поле "адрес ПДУО" ПБД ПД0_ОТВ и ПД1_ОТВ | ||||
ПРЧ/226 | - индивидуальным адресом передатчика ПД0_ОТВ или ПД1_ОТВ? | 5.4.3.2 | О | Да [ ] |
В.8.6 УЛЗ, тип 3. Параметры протокола
Позиция | Возможности протокола. | Ссылки | Статус | Обеспечение/Значение |
ПАП/227 | Реализована ли функция N4 (максимальное число передач)? | 8.6.1 | О | Да [ ] |
*ПАП/228 | - Максимальное число передач | Минимальное значение = | ||
ПАП/229 | Реализована ли функция Т1 (ТАЙМ-АУТ_ПДТ)? | 8.6.4 | Если N4>1:O | Н/И [ ] Да [ ] |
ПАП/230 | - Диапазон ТАЙМ-АУТА_ПДТ | Минимальное значение = Максимальное значение = | ||
ПАП/231 | Реализована ли функция Т2 (ТАЙМ-АУТ_ВР_ СУЩЕСТВ_ПМ)? | 8.6.5 | О | Да [ ] |
ПАП/232 | - Диапазон ТАЙМ-АУТА_ВР_СУЩЕСТВ_ПМ | Минимальное значение = Максимальное значение = | ||
ПАП/233 | Реализована ли функция ТЗ (ТАЙМ-АУТ_ВР_СУЩЕСТВ_ПД)? | 8.6.6 | О | Да [ ] |
ПАП/234 | - Диапазон ТАЙМ-АУТА_ВР_СУЩЕСТВ_ПД | Минимальное значение = Максимальное значение = |
В.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 - Значения параметров УЛЗ
Параметр | Значение |
Максимальное число октетов в ПБД И (N 1) | 1031 |
Максимальное число октетов в ПБД (N 3) | 4 |
Максимальное число неподтвержденных ПБД И (k) | 7 |
Максимальное число передач (N 2) | 10 |
Относительно обеспечения других значений величины N 1 см. основную часть стандарта. |
С.3.2 Рекомендуемые значения тайм-аутов приведены в таблице С.2. Рекомендуется, чтобы значения всех тайм-аутов можно было изменять. Эти значения тайм-аутов основаны на эмпирических наблюдениях операций мостовых ЛВС. В одной изолированной ЛВС могут использоваться меньшие значения тайм-аутов.
Таблица С.2 - Значения тайм-аутов УЛЗ
Наименование тайм-аута | Значение (в секундах) |
Состояние занятости | 30 |
Неприем | 10 |
Бит З | 5 |
С.3.3 Рекомендуется, чтобы при работе оконечных систем в мостовых конфигурациях на подуровне УДС использовался описываемый ниже метод управления потоком. Следует заметить, что все оконечные системы, использующие УЛЗ типа 2 и подключенные к таким конфигурациям ЛВС, должны использовать этот метод. Это единственный способ обеспечить справедливое распределение нагрузки.
Для каждого обеспечиваемого соединения УЛЗ оконечная система использует следующую процедуру:
- При каждом обнаружении перегрузки начинается период устранения перегрузки: размер рабочего окна устанавливается в 1 и повторно передается ПБД И, порядковый номер которого равен Нпм последнего правильно принятого ПБД.
- В период устранения перегрузки процедуры УЛЗ типа 2 гарантируют, что максимальное число неподтвержденных ПБД И не превысит размера рабочего окна.
- Когда число ранее не подтвержденных, но к данному моменту успешно переданных и подтвержденных ПБД И достигнет значения размера рабочего окна, размер окна увеличивается на единицу. Период устранения перегрузки заканчивается, когда размер рабочего окна достигнет значения k, определенного в 7.4 ГОСТ 28907.
- ПБД И считается потерянным передающим его логическим объектом УЛЗ при следующих условиях:
1 Передатчик получил ПБД НЕПРИЕМ, который указывает, что приемник обнаружил потерю ПБД И, или
2 Имеет место последовательность событий:
a) тайм-аут подтверждения на передатчике истек, а счет повторных передач меньше N 2,
b) передатчик выдал командный ПБД ГПР с битом З=1,
c) передатчик получил ПБД И или ПБД формата У, в котором бит П=1, но значение Нпм не равно значению Нпд, которое имелось на передатчике при передаче командного ПБД ГПР с битом З=1.
- Выполнение этого алгоритма прерывается любым условием, которое побуждает компонент "соединение" УЛЗ перейти в состояние "сброс" или "разъединение".
Примечание - Этот метод использует механизм параболического возрастания, рассматриваемый в ГОСТ 28907.
Кроме того, станция ЛВС может отказаться от установления новых соединений УЛЗ и (или) принять решение освободить обеспечиваемые ею соединения УЛЗ.
Примечание - Рациональное построение мостовой ЛВС может значительно ослабить проблему перегрузки в ретрансляционном оборудовании УДС. Построение реальной конфигурации мостовой ЛВС должно быть тщательно оценено с тем, чтобы ограничить возникновение проблемы перегрузок на подуровне УДС.
ПРИЛОЖЕНИЕ D (информационное). БИБЛИОГРАФИЯ
ПРИЛОЖЕНИЕ D
(информационное)
На следующий стандарт даны ссылки в примечаниях, и для настоящего стандарта он носит информационный характер.
ГОСТ Р ИСО/МЭК 10030-96 Информационная технология. Передача данных и обмен информацией между системами. Протокол обмена маршрутной информацией оконечной системы для использования в сочетании с ГОСТ 34.954-91