ГОСТ Р ИСО/МЭК 10030-96 Информационная технология (ИТ). Передача данных и обмен информацией между системами. Протокол обмена маршрутной информацией оконечной системы для использования в сочетании с ГОСТ 34.954-91.
ГОСТ Р ИСО/МЭК 10030-96
Группа П85
ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Информационная технология
ПЕРЕДАЧА ДАННЫХ И ОБМЕН ИНФОРМАЦИЕЙ МЕЖДУ СИСТЕМАМИ.
ПРОТОКОЛ ОБМЕНА МАРШРУТНОЙ ИНФОРМАЦИЕЙ ОКОНЕЧНОЙ СИСТЕМЫ ДЛЯ ИСПОЛЬЗОВАНИЯ В СОЧЕТАНИИ С ГОСТ 34.954-91
Information technology.
Telecommunications and information exchange between systems.
End System Routeing Information Exchange Protocol
for use in conjunction with ISO 8878
ОКС 35.100.30
ОКСТУ 4002
Дата введения 1997-01-01
Предисловие
1 РАЗРАБОТАН Московским научно-исследовательским центром (МНИЦ) Комитета при Президенте Российской Федерации по политике информатизации и Российским научно-исследовательским институтом информационных систем (РосНИИ ИС)
ВНЕСЕН Комитетом при Президенте Российской Федерации по политике информатизации
2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 10 июня 1996 г. N 369
Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 10030-90 "Информационная технология. Передача данных и обмен информацией между системами. Протокол обмена маршрутной информацией оконечной системы для использования в сочетании с ИСО 8878"
3 ВВЕДЕН ВПЕРВЫЕ
Введение
Настоящий стандарт - один из совокупности стандартов, относящихся к протоколам маршрутизации на сетевом уровне. Общие основы маршрутизации изложены в ИСО/МЭК ТО 9575. Настоящий стандарт касается в основном той части указанных основ, в которой рассматривается маршрутизация по отдельной подсети.
Настоящий стандарт должен применяться совместно с ГОСТ 34.954, который определяет использование рекомендации Х.25 для обеспечения услуг сетевого уровня в режиме с установлением соединения. Этот стандарт обеспечивает решение следующих практических вопросов:
a) Каким образом оконечные системы (ОС) определяют достижимость тех промежуточных систем (ПС), которые могут маршрутизировать протокольные блоки данных сетевого уровня (ПБДС) к пунктам назначения, расположенным в тех подсетях, с которыми непосредственно соединена данная ОС?
b) Каким образом данная ОС определяет достижимость других ОС в той же подсети [когда прямой анализ адреса пункта доступа к услугам сетевого уровня (ПДУС) не дает информации об адресе получателя подсети]?
c) Каким образом логический объект разрешения адресов подсети (ЛОРАП) определяет достижимость ОС через те подсети, с которыми он непосредственно соединен?
Стандарт исходит из предположения, что:
a) маршрутизация по определенному адресу пункта подключения подсети (ППП) в той же подсети удовлетворительно выполняется самой подсетью;
b) подсеть неспособна маршрутизировать на глобальной основе с использованием только адреса ПДУС для обеспечения обмена данными с требуемым получателем;
c) оконечные системы, использующие данный протокол, нуждаются в знании, по меньшей мере, одного адреса ППП, который может быть использован для доступа к ЛОРАП.
Стандарт предназначен для:
a) минимизации объема априорной информации о состоянии, необходимой оконечным системам до того, как они смогут начать обмен данными с другими ОС;
b) минимизации объема памяти, необходимой для хранения маршрутной информации в ОС;
c) минимизации вычислительной сложности алгоритмов маршрутизации оконечных систем.
Настоящий стандарт выполняет функции, аналогичные тем, которые определены в ГОСТ Р ИСО/МЭК 9542. Однако характеристики функциональной среды по ГОСТ Р 34.950 и фактические функциональные возможности указанного стандарта сами по себе делают недействительным функционирование протокола ГОСТ Р ИСО/МЭК 9542 по следующим причинам:
а) в общих нешироковещательных средах подмножество "конфигурация" протокола ГОСТ Р ИСО/МЭК 9542 неадекватно;
b) в широковещательных средах функционирования протокола ГОСТ Р 34.950 подмножество "переадресация" протокола ГОСТ Р ИСО/МЭК 9542 становится недействительным.
По указанным причинам данный стандарт разработан для выполнения всех вышеупомянутых функций в соответствии с операциями по ГОСТ Р 34.950.
1 НАЗНАЧЕНИЕ
Настоящий стандарт определяет протокол обмена маршрутной информацией между оконечной системой и логическим объектом разрешения адреса подсети.
Настоящий стандарт применим:
a) к оконечным системам, работающим в соответствии с основной частью ГОСТ 34.954 для обеспечения и поддержки услуг сетевого уровня в режиме с установлением соединения при использовании ГОСТ Р 34.950;
b) к логическим объектам разрешения адресов подсети, функционирующим в соответствии с ГОСТ Р 34.950.
Примечание - Определяемый в настоящем стандарте логический объект разрешения адресов подсети может быть связан с функциями ретрансляции в соответствии с ГОСТ Р ИСО/МЭК 10028 и ИСО/МЭК 10177.
Оконечные системы, которые обеспечивают и поддерживают услуги сетевого уровня в режиме с установлением соединения (УСУ УС) ВОС, используя процедуры быстрой выборки версии 1980 или альтернативные процедуры версии 1980 приложения А ГОСТ 34.954, не входят в предмет рассмотрения настоящего стандарта.
Настоящий стандарт не определяет каких-либо протокольных элементов или алгоритмов для обеспечения маршрутизации между объектами ЛОРАП. Такие функции сознательно выведены за рамки предмета рассмотрения настоящего стандарта.
2 НОРМАТИВНЫЕ ССЫЛКИ
В настоящем стандарте использованы ссылки на следующие стандарты:
ГОСТ 28906-91 (ИСО 7498-84, ИСО 7498-84 Доп.1-84) Информационная технология. Взаимосвязь открытых систем. Базовая эталонная модель
ГОСТ 28907-91 (ИСО 8802-2-89) Системы обработки информации. Локальные вычислительные сети. Часть 2. Управление логическим звеном
ГОСТ 34.936-91 (ИСО 10039-91) Информационная технология. Передача данных и обмен информацией между системами. Определение услуг подуровня УДС локальных вычислительных сетей
ГОСТ 34.954-91 (ИСО 8878-87) Системы обработки информации. Передача данных. Использование протокола Х.25 для обеспечения услуг сетевого уровня в режиме с установлением соединения
ГОСТ Р 34.90-93 Информационная технология. Передача данных и обмен информации между системами. Протокольные комбинации для обеспечения и поддержки услуг сетевого уровня ВОС
ГОСТ Р 34.950-92 (ИСО 8208-87) Системы обработки информации. Передача данных. Протокол пакетного уровня Х.25 для оконечного оборудования данных
ГОСТ Р ИСО 8348/Доп.2-93 Информационная технология. Передача данных. Определение услуг сетевого уровня. Дополнение 2. Адресация на сетевом уровне
ГОСТ Р ИСО 8648-95 Системы обработки информации. Взаимосвязь открытых систем. Внутренняя организация сетевого уровня
ГОСТ Р ИСО/МЭК 8881-95 Системы обработки информации. Передача данных. Использование протокола пакетного уровня Х.25 в локальных вычислительных сетях
ГОСТ Р ИСО/МЭК 9542-93* Системы обработки информации. Передача данных и обмен информацией между системами. Протокол обмена маршрутной информацией между оконечной и промежуточной системами для использования совместно с протоколом, обеспечивающим услуги сетевого уровня в режиме без установления соединения
ГОСТ Р ИСО/МЭК 10028-95 Информационная технология. Передача данных и обмен информацией между системами. Определение ретрансляционных функций промежуточной системы на сетевом уровне
ИСО/МЭК 8208-90/Изм.3-91* Информационная технология. Передача данных. Протокол пакетного уровня Х.25 для оконечного оборудования данных. Изменение 3. Требования к соответствию
ИСО/МЭК ТО 9575-89* Информационная технология. Передача данных и обмен информацией между системами. Основы маршрутизации ВОС
ИСО/МЭК ТО 9577-93* Информационная технология. Передача данных и обмен информацией между системами. Идентификация протоколов сетевого уровня ВОС
ИСО/МЭК 10177-93* Информационная технология. Передача данных и обмен информацией между системами. Обеспечение промежуточной системой внутренних услуг сетевого уровня в режиме с установлением соединения с использованием протокола пакетного уровня Х.25 по ИСО/МЭК 8208
ИСО/МЭК ТО 10178-92* Информационная технология. Передача данных и обмен информацией между системами. Структура и кодирование адресов пунктов доступа к услугам уровня звена данных (ПДУЗ) в локальных вычислительных сетях
____________________
* До прямого применения данного документа в качестве государственного стандарта его распространение осуществляет секретариат ТК 22 "Информационная технология".
3 ОПРЕДЕЛЕНИЯ
3.1 Определения из эталонной модели
В настоящем стандарте используются следующие понятия, определенные в ГОСТ 28906:
a) сетевой уровень;
b) пункт доступа к услугам сетевого уровня;
c) адрес пункта доступа к услугам сетевого уровня;
d) логический объект сетевого уровня;
e) маршрутизация;
f) протокол сетевого уровня;
g) ретрансляция на сетевом уровне;
h) протокольный блок данных сетевого уровня.
3.2 Определения, относящиеся к архитектуре сетевого уровня
В настоящем стандарте используются следующие понятия, определенные в ГОСТ Р ИСО 8648:
a) подсеть;
b) оконечная система;
c) промежуточная система;
d) услуга подсети;
e) протокол доступа к подсети.
3.3 Определения, относящиеся к адресации на сетевом уровне
В настоящем стандарте используются следующие понятия, определенные в ГОСТ Р ИСО 8348/Доп.2:
a) заголовки логических объектов сетевого уровня;
b) адрес подсети;
c) пункт подключения подсети.
3.4 Определения, принятые в локальных вычислительных сетях
В настоящем стандарте используются следующие понятия, определенные в ГОСТ 28907:
a) групповой адрес;
b) глобальный адрес.
3.5. Дополнительные определения
Для настоящего стандарта применимы следующие определения:
3.5.1 Информация о конфигурации - информация о совокупности оконечных систем и промежуточных систем, подсоединенных к подсети и определенных с точки зрения типов систем, наличия сетевых адресов, наличия заголовков логических объектов сетевого уровня и соответствия между системами, адресов ППП и возможных маршрутов.
3.5.2 Информация о переадресации - информация, предоставляемая в том случае, когда пакету "запрос вызова" не удается установить соединение сетевого уровня (ССУ), и указывающая тот ППП, который мог быть использован для установления такого соединения.
3.5.3 Логический объект разрешения адресов подсети - поставщик информации о маршрутах в пределах одной подсети.
4 СОКРАЩЕНИЯ
4.1 Системы
ЛОРАП - Логический объект разрешения адресов подсети
ОС - Оконечная система
ООД - Оконечное оборудование данных
4.2 Протокольные блоки данных
ПБД - Протокольный блок данных
ПБД ЗВЛ - Протокольный блок данных "заявка ЛОРАП"
ПБД ЗОС - Протокольный блок данных "заявка ОС"
ПБД ЗЗЛ - Протокольный блок данных "заявка запроса ЛОРАП"
ПБД ЗКЛ - Протокольный блок данных "завершение конфигурации ЛОРАП"
ПБД ЗКОС - Протокольный блок данных "запрос о конфигурации оконечной системы"
ПБД ЗУЛ - Протокольный блок данных "завершение уведомления ЛОРАП"
ПБД ЗУОС - Протокольный блок данных "завершение уведомления ОС"
ПБД ОКЛ - Протокольный блок данных "ответ на конфигурацию ЛОРАП"
ПБД ПОС - Протокольный блок данных "переадресация ОС"
ПБД ПУЛ - Протокольный блок данных "принятое уведомление ЛОРАП"
ПБД СОС - Протокольный блок данных "соединение ОС"
4.3 Разное
АСУ - Адрес на сетевом уровне
ДДК - Двоично-десятичный код
ИИП - Идентификатор исходного протокола
КУ - Качество услуг
ПБДС - Протокольный блок данных сетевого уровня
ПДУЗ - Пункт доступа к услугам звена данных
ППП - Пункт подключения подсети
ССУ - Соединение сетевого уровня
УЛЗ - Управление логическим звеном
УДС - Управление доступом к среде
УСУ УС - Услуги сетевого уровня в режиме с установлением соединения
5 ОБЩЕЕ ОПИСАНИЕ ПРОТОКОЛА
Протокол, определяемый в настоящем стандарте, состоит из двух подмножеств:
a) информация о конфигурации;
b) информация о переадресации.
К функциям подмножества "информация о конфигурации" относятся:
a) обеспечение возможности оконечным системам уведомлять ЛОРАП о существовании и достижимости адресов на сетевом уровне (АСУ);
b) обеспечение возможности оконечным системам обнаруживать для некоторых удаленных АСУ адреса ППП систем той подсети, через которую могут маршрутизироваться обмениваемые данные.
Функция подмножества "информация переадресации" должна позволять тем ОС, которые пытаются установить соединение, направлять данные по конкретному соответствующему адресу ППП, через который должно маршрутизироваться соединение.
Оба подмножества взаимно дополняют друг друга в том смысле, что информация, получаемая из подмножества "информация о переадресации", содержит в неявном виде соответствующую информацию о конфигурации, а информация, получаемая из подмножества "информация о конфигурации", может быть использована для образования подходящего адреса ППП и, тем самым, исключения необходимости использования подмножества "информация о переадресации". Выбор конкретного подмножества, которое должно использоваться для получения информации о маршрутизации в конкретных сеансах обмена данными, является локальным решением ОС, которое может быть различным в разных сеансах обмена данными и может свободно изменяться в процессе работы ОС, не влияя на возможности взаимодействия.
5.1 Функция ЛОРАП
Объект ЛОРАП является таким логическим объектом, который накапливает информацию о конфигурации из оконечных систем и распределяет среди них информацию о конфигурации и переадресации.
Примечание - Объект ЛОРАП может также взаимодействовать с промежуточными системами, однако подробная информация таких взаимодействий не входит в предмет рассмотрения настоящего стандарта.
Функция ЛОРАП может быть выполнена одной или несколькими ОС или ПС, подключенными к подсети. Если подсеть такова, что она сама действует в соответствии с протоколом Х.25, то возможно, что некоторые из операций или все операции ЛОРАП могут быть выполнены функциями самой подсети.
Для того, чтобы ОС использовала данный протокол, необходимо знать, по меньшей мере, адрес одного ППП, который может быть использован для доступа к ЛОРАП. В общем случае этот адрес заранее закладывается в ОС. В приложении А описана методика, которая может быть использована в некоторых ситуациях для исключения необходимости такого предварительного запоминания адреса.
5.2. Общее описание подмножества "информация о конфигурации"
Протокольные обмены, которые образуют подмножество "информация о конфигурации", начинаются с того, что ОС устанавливает соединение Х.25 с ЛОРАП путем выдачи пакета "запрос вызова" протокола Х.25. Первый октет данных пользователя пакета содержит идентификатор протокола, указывающий протокол, определяемый настоящим стандартом. Если ЛОРАП принимает вызов, ОС может затем передать ЛОРАП подробные сведения о его адресах на сетевом уровне. Как только информация о всех его адресах на сетевом уровне будет передана, ОС неявно сообщает ЛОРАП, что это уведомление выполнено и, таким образом, ЛОРАП может гарантировать, что вся полученная информация защищена в той степени, которая необходима для ее использования. ОС может также запросить информацию об удаленных адресах на сетевом уровне. Для каждого запрошенного адреса на сетевом уровне ЛОРАП обеспечивает подробные сведения об одном или нескольких ППП подсети, через который(ые) может быть достигнут адресат(ы) на сетевом уровне и обеспечено соответствующее возможное качество услуг. Получив информацию об одном адресе на сетевом уровне, ОС может запросить информацию о других адресах. При получении всей необходимой информации ОС завершает данное соединение.
5.3 Общее описание подмножества "информация о переадресации"
Функции информации о переадресации могут быть подразделены на две части.
Первая часть имеет место, когда ОС готова установить соединение на сетевом уровне в соответствии с ГОСТ 34.954, но не имеет информации, необходимой для определения соответствующего адреса подсети, по которому должен быть передан запрос вызова. Действия ОС в этом случае состоят в том, чтобы просто использовать адрес ЛОРАП. Пакет "запрос вызова" формируется в точном соответствии с ГОСТ 34.954 и передается ЛОРАП.
В дальнейшем ОС продолжает управлять соединением в соответствии с ГОСТ 34.954. В случае, когда ЛОРАП представляет собой ОС или ПС, подсоединенную к подсети, и не является набором функций, встроенных в саму подсеть, он не может:
- использовать услугу "отражение вызова" Х.25, чтобы перенаправить вызов в соответствующую ОС или ПС;
- завершить соединение, обеспечив информацию о соответствующем ППП, который может быть использован в последующих попытках;
- если содержит функцию ретрансляции, то может воспринять вызов и принять участие в организации соединения в качестве ретранслятора.
Если функция ЛОРАП встроена в саму подсеть, то дополнительно к вышеизложенному она может доставить вызов соответствующему ЛОРАП другими способами, которые не входят в предмет рассмотрения настоящего стандарта (например, путем привлечения услуги Х.25 "переадресация вызова").
Следовательно, поскольку установление соединения может в данном случае осуществляться удовлетворительно без того, чтобы инициирующая ОС выполняла какие-либо дополнительные операции маршрутизации, ОС продолжает обрабатывать ССУ в соответствии с ГОСТ 34.954 до тех пор, пока не будет получена индикация завершения.
Получение индикации завершения в ответ на запрос вызова приводит к выполнению второй части процедуры информации о переадресации. В этот момент, если коды причины и диагностики в пакете индикации завершения показывают, что разъединение не было инициировано пользователем услуг сетевого уровня, ОС проверяет, имеются ли в пакете данные пользователя, содержащие информацию, закодированную в соответствии с настоящим стандартом, и указывающие соответствующий адрес подсети, через который могло быть установлено ССУ, эквивалентное отклоненному. Эквивалентное ССУ - это соединение между одинаковыми ПДУС с одинаковыми параметрами качества услуг. ОС может использовать эту информацию либо для повторной попытки установления соединения в соответствии с возможностями ГОСТ 34.954, либо при установлении последующих эквивалентных ССУ.
6 СООТВЕТСТВИЕ
6.1 Требования к статическому соответствию
Те ОС, соответствие которых заявлено настоящему стандарту, должны реализовывать одну или несколько следующих функций:
a) подмножество "информации о конфигурации" ОС, определенное в разделе 8;
b) подмножество "информации о переадресации" ОС, определенное в разделе 9.
ЛОРАП, соответствие которого заявлено настоящему стандарту, должен реализовывать те процедуры раздела 11, которые предписаны в виде требований.
Примечание - Следовательно, ЛОРАП должен обрабатывать как информацию о конфигурации, так и информацию о переадресации.
6.2 Требования к динамическому соответствию
Система, соответствие которой заявлено настоящему стандарту, должна проявлять внешнее поведение, соответствующее реализованному:
а) для каждой обеспечиваемой функции соответствующие процедуры и кодирование любых передаваемых протокольных блоков данных, как определено в соответствующих подразделах разделов 8, 9, 10, 11 и 12;
b) протокол пакетного уровня Х.25 в соответствии с требованиями ИСО/МЭК 8208/Изм.3 и с процедурами, привлекаемыми протоколами ГОСТ Р 34.90 для соответствующей конфигурации.
7 АДРЕС ПОДСЕТИ ЛОРАП
Использование данного протокола требует, чтобы ОС знала, по меньшей мере, один адрес подсети, по которому может быть достигнут ЛОРАП. Для определения такого адреса могут быть предусмотрены локальные методы; при наличии альтернативных методов, описанных в приложении А, они могут быть также использованы.
В случае, когда ОС знает несколько ППП, через которые может быть достигнут ЛОРАП, выбор конкретного ППП является локальным вопросом.
8 ПОДМНОЖЕСТВО "ИНФОРМАЦИЯ О КОНФИГУРАЦИИ" ОС
8.1 Параметры протокола
В данном разделе определены параметры, используемые в рассматриваемом протоколе, и в необходимых случаях определены значения этих параметров, которые должны быть обеспечены всеми соответствующими ОС. Способность обеспечивать значения, отличные от специально требуемых, и средства, определяющие необходимость использования таких значений в любом конкретном случае, являются локальными вопросами.
8.1.1 Время ответа
Это временной предел, используемый ОС во время функционирования протокола.
Любая реализация подмножества "информация о конфигурации" должна быть способна обеспечить значение времени ответа, равное (180±30) с.
8.1.2 Время повторного уведомления
Это тот интервал времени, в течение которого ОС должна повторить неудачную попытку уведомить ЛОРАП о своей конфигурации.
Любая реализация подмножества "информация о конфигурации" должна быть способна обеспечить значение времени повторного уведомления, равное 900 с с точностью ±120 с, если она обеспечивает любое из значений параметра "требуется уведомление", отличное от значения, указывающего, что уведомление никогда не потребуется, и значения, указывающего, что никакого специального значения не предложено.
Примечание - К реализации, которая не обеспечивает таких значений параметра "требуется уведомление", никаких требований по обеспечению времени повторного уведомления не предъявляется.
8.1.3 Требуется уведомление
Этот параметр определяет условия, при которых ОС должна пытаться уведомить ЛОРАП о своей конфигурации.
Любая реализация подмножества информации о конфигурации должна быть способна обеспечить такое значение этого параметра, которое указывает, что уведомление никогда не потребуется.
Примечание - Примерами других значений параметра "требуется уведомление", которые могут быть факультативно обеспечены, служат:
- значение, указывающее, что уведомление требуется каждый раз, когда ОС инициируется и затем по истечении времени, определенном ЛОРАП в конце каждого предыдущего уведомления;
- значение, указывающее, что уведомление требуется при каждом подсоединении ОС к другой подсети.
Обратим внимание, что эти значения являются только примерами. Допускаются и другие значения.
8.2 Операции протокола
В данном разделе определен протокол, который использует процедуры пакетного уровня Х.25, определенные в ГОСТ Р 34.950. Осуществляемый в зависимости от возможностей ГОСТ Р 34.950 выбор значений для полей Х.25, которые не определены в данном разделе, является локальным вопросом.
8.2.1 Установление соединения
ОС должна пытаться установить соединение всякий раз при наличии любого из следующих условий:
a) требуется получить информацию о конфигурации от ЛОРАП;
b) условия, определенные в 8.1.3, вызывают необходимость сообщить ЛОРАП информацию о конфигурации, при условии, что используемый ППП ОС не имеет уже установленного или устанавливаемого соединения с ЛОРАП для его использования при передаче информации о конфигурации.
ОС не должна пытаться устанавливать в любой конкретный момент времени несколько соединений с ЛОРАП из любого одного ППП ОС.
ОС может попытаться установить соединение с ЛОРАП, инициировав виртуальное соединение в соответствии с процедурами установления виртуального соединения, определенными в ГОСТ Р 34.950. Адрес ППП, по которому должен быть передан запрос вызова, должен быть применим к этому ППП, как описано в разделе 7. Должна быть определена услуга "быстрая выборка", указывающая отсутствие ограничений на выдачу ответа. Данные пользователя, которые должны быть переданы в пакете "запрос вызова", должны содержать ПБД СОС.
Если процедура установления виртуального соединения выполнена успешно, ОС должна проанализировать данные пользователя, поступившие в пакете "соединение установлено".
Если эти данные содержат действительный ПБД ЗУП, ОС должна продолжать передачу данных, как определено в 8.2.3. В противном случае ОС должна завершить соединение согласно процедурам завершения виртуальных соединений, определенных в ГОСТ Р 34.950, используя код причины 0 и код диагностики 242, после чего действовать в соответствии с процедурой безуспешного установления соединения, описанной в 8.2.2.
Если процедура установления виртуального соединения оказалась безуспешной, ОС может повторить ее при условии, что безуспешность была обусловлена причиной, которая, если она имела место при попытке установить ССУ, может быть интерпретирована в соответствии с ГОСТ 34.954 как "отклонение соединения - неустойчивое состояние". Однако повторные попытки не должны продолжаться дольше указанного значения параметра "время ответа". Закончив повторные попытки, ОС должна действовать в соответствии с 8.2.2.
8.2.2 Процедура безуспешного установления соединения
Если попытка установления соединения оказалась безуспешной и если ОС знает любой альтернативный адрес подсети ЛОРАП, она должна попытаться установить соединение по тому адресу, по которому она еще не пыталась его устанавливать.
Если все известные адреса ЛОРАП были опробованы безуспешно, то:
a) если в соответствии с положениями 8.1.3 ОС должна была уведомить ЛОРАП о своей конфигурации, то эта попытка уведомления должна рассматриваться безуспешной. Другая попытка может быть осуществлена по истечении времени повторного уведомления;
b) если ОС требуется информация о конфигурации от ЛОРАП, то время, в течение которого осуществляются последующие попытки (если они выполняются) или выполняются другие виды действий (например, возврат к конфигурации по умолчанию или использованию подмножества "переадресация" в качестве основы для маршрутизации), определяется локально.
8.2.3 Процедура передачи данных
В данном разделе определяется передача данных после установления приемлемого соединения с ЛОРАП.
В данном разделе требуется передача нескольких ПБД. Каждый ПБД должен передаваться в виде отдельной последовательности битов М без установленного бита О в соответствии с процедурами передачи данных, определенными в ГОСТ Р 34.950.
В данном разделе требуется также, чтобы в некоторых ситуациях соединение было отклонено до завершения передачи данных. Это должно выполняться путем завершения соединения в соответствии с процедурами завершения виртуального соединения, определенными в ГОСТ Р 34.950, с использованием кода причины 0 и кода диагностики 242.
В случае завершения виртуального соединения (либо самой ОС, отклоняющей соединение в соответствии с положениями настоящего стандарта, либо вследствие выполнения процедур ГОСТ Р 34.950) до нормального завершения процедуры передачи данных, определенной в данном разделе, ОС должна действовать согласно процедуре безуспешного установления, определенной в 8.2.4.
В том случае, если в любой момент времени при выполнении процедуры передачи данных поступает пакет "индикация повторной установки", "прерывание" или данные бита Q, ОС должна отказаться от соединения.
Процедура передачи данных состоит из двух частей: уведомление о конфигурации и сбор информации о конфигурации. Если приемлема процедура уведомления о конфигурации, она должна быть выполнена сразу после завершения установления соединения. Если приемлема процедура сбора информации о конфигурации, она должна быть выполнена после завершения процедуры уведомления о конфигурации (либо сразу, если процедура уведомления о конфигурации неприемлема). После завершения всех приемлемых частей процедуры ОС должна действовать согласно процедуре нормального завершения в соответствии с 8.3.
8.2.3.1 Уведомление о конфигурации
Процедура уведомления о конфигурации является факультативной и в случае ее реализации ее действия контролируются путем установки параметра "требуется уведомление".
Эта процедура применима только при наличии следующих условий:
a) параметр "требуется уведомление" установлен в значение, которое указывает, что в данный момент ОС должна уведомить ЛОРАП о своей конфигурации;
b) попытка уведомить о конфигурации не была безуспешной в течение времени, определяемого параметром "время повторного уведомления".
ОС должна инициировать процедуру передачи одного ПБД ЗОС по каждому сетевому адресу, доступному через свой ЛОРАП. После передачи ПБД ЗОС она должна передать ПБД ЗУОС. Затем она должна ожидать поступления ПБД ОКЛ. Если полученный ПБД ЗЗЛ содержит параметр "требуется уведомление", ОС должна извлечь его и использовать его значение в качестве следующего интервала времени до уведомления ЛОРАП. При приеме ПБД ПУЛ процедура уведомления о конфигурации успешно заканчивается.
Примечание 1 - После такого успешного завершения значение параметра "требуется уведомление" определяет, при каких условиях и когда эта процедура может быть снова использована.
Если после передачи первого блока ПБД ЗОС блок ПБД ЗЗЛ не был получен в течение времени, равного параметру "время ответа", соединение должно быть прервано.
Примечание 2 - Истечение этого времени может произойти в результате либо задержек при передаче ПБД (например, из-за управления потоком), либо задержки в выдаче ответа ЛОРАП.
Если ОС получила какие-либо данные до передачи ПБД ЗУОС или она получила данные, которые не содержат действительных ПБД ЗЗЛ, соединение должно быть прервано.
8.2.3.2 Сбор информации о конфигурации
Процедура сбора информации о конфигурации является факультативной и в случае ее реализации она применима всякий раз, когда ОС нуждается в информации от ЛОРАП относительно ППП тех систем, которые могут быть использованы для достижения удаленных адресов сетевого уровня. Настоящий стандарт не налагает никаких ограничений на частоту попыток ОС собрать информацию о конфигурации.
ОС должна передать ПБД ЗКОС, определяющий адрес сетевого уровня, по которому она запрашивает информацию. В ответ она может получить несколько ПБД ОКЛ, содержащих информацию о тех ППП, через которые может быть достигнут конкретный адрес сетевого уровня. ПБД ОКЛ может содержать параметры "маска адреса" и "маска ППП". Эти параметры могут быть использованы в соответствии с положениями 8.1.4 и 8.1.5 соответственно.
Получение ПБД ЗКЛ указывает, что информация полная; если ни один из ПБД ОКЛ не поступил до получения ПБД ЗКЛ, это указывает, что по данному конкретному адресу на сетевом уровне никакой информации нет. Если ОС запрашивает информацию о последующих адресах на сетевом уровне, она может затем повторить этот процесс при условии, что поле "предельное число запросов" в ПБД ЗКЛ определяет допустимость другого запроса. Если это поле определяет, что последующие запросы не разрешены, ОС не должна передавать больше никаких ПБД ЗКОС. Если ОС имеет информацию для всех адресов на сетевом уровне, которые она запрашивает, либо если поле "предельное число запросов" не разрешает последующих запросов, то функция сбора информации о конфигурации успешно завершается.
Если после передачи ПБД ЗКОС и до получения соответствующего ПБД ЗКЛ прошло времени больше, чем значение параметра "время ответа", соединение должно быть прервано.
Следующие события также должны вызывать отказ от соединения:
a) получение любых данных, которые не содержат действительных ПБД ОКЛ или ПБД ЗКЛ;
b) получение любого ПБД до передачи первого ПБД ЗКОС или между получением ПБД ЗКЛ и передачей следующего ПБД ЗКОС;
c) получение ПБД, относящегося к адресу на сетевом уровне, отличному от того, по которому ОС передала ПБД ЗКОС по данному соединению и не получила ПБД ЗКЛ.
8.2.4 Процедура прерывания соединения
Соединение прекращает действовать:
a) если применима процедура уведомления о конфигурации, это должно рассматриваться как безуспешность попытки уведомления. (Следовательно, она должна быть снова предпринята по истечении времени, указанного параметром "время повторного уведомления");
b) при получении неполной информации о конфигурации в ПБД ОКЛ, для которого не был получен соответствующий ПБД ЗКЛ.
Примечание - Вопрос о том, должна ли ОС использовать неполные данные или аннулировать их, является локальным. Будет ли предпринята попытка получить оставшиеся неполные данные, либо продолжится запрос информации по другим адресам сетевого уровня - также является локальным вопросом.
8.3 Нормальная процедура завершения
Если используемые процедуры передачи данных успешно закончены и если поле "предельное число запросов", содержащееся в ПБД ЗКЛ, указывает, что дальнейшие запросы больше не разрешаются, ОС должна завершить соединение согласно процедуре завершения виртуального соединения, определенной в ГОСТ Р 34.950, используя код причины 0 и код диагностики 241. Если поле "предельное число запросов" разрешает другой запрос, ОС должна выполнить одну из следующих процедур:
a) она может немедленно завершить соединение, используя код причины 0 и код диагностики 241;
b) она может сохранить соединение на некоторое время и в дальнейшем использовать его для последующих функций передачи данных в соответствии с 8.2.3, когда эти функции снова окажутся применимыми. Максимальное время, в течение которого может сохраняться соединение при отсутствии дальнейшей передачи данных, равно половине значения параметра "время запроса", полученного в ПБД ЗУЛ. Сразу, как только это время истечет, ОС должна освободить соединение с кодом причины 0 и кодом диагностики 241. ОС не обязательно должна сохранять соединение в течение этого максимального периода времени. Вместо этого она может по своему усмотрению завершить соединение в любое удобное время, также используя код причины 0 и код диагностики 241. В течение времени, когда соединение сохраняется, ОС должна продолжать работать по нему в соответствии с процедурами, определенными в ГОСТ Р 34.950. При получении пакета "данные", "сброс" или "прерывание" ОС должна завершить соединение с кодом причины 0 и кодом диагностики 242. В этом случае или в случае получения индикации завершения, либо если действия процедур ГОСТ Р 34.950 привели к завершению соединения, необходимость и время следующей попытки установить другое соединение в соответствии с процедурами, определенными в 8.2.1, является локальным вопросом.
Выбор между процедурами по подпунктам а) и b), а также длительность времени, в течение которого сохраняются соединения в случае выбора варианта по подпункту b), является локальным вопросом и ОС может свободно менять их в соответствии с внутренними условиями, не влияя на взаимодействие.
8.4 Использование информации о конфигурации
Настоящий стандарт не налагает никаких ограничений на количество информации, собранной ОС, которая сохраняется или используется. ОС может в любое время аннулировать собранную информацию и снова выдать новый запрос на сбор информации, если это потребуется в дальнейшем.
ОС может в любое время использовать локальные сведения или любой другой способ определения ППП, который должен использоваться при установлении любого ССУ по любому адресу на сетевом уровне независимо оттого, собрана ли информация о конфигурации, которая может быть использована.
Информация о конфигурации, получаемая данным протоколом, является действительной и зависит только от следующих ограничений:
а) информация о конфигурации, указывающая, какой адрес ППП использовать для установления соединения, является недействительной, если только она не была обеспечена в информации для соответствующего адреса на сетевом уровне и применима к диапазону КУ, который содержит минимально приемлемое КУ для запрошенного ССУ;
b) информация о конфигурации является недействительной, если время, прошедшее с момента ее получения, превышает время, определенное в поле "время удержания" ПБД ОКЛ, который его передал;
c) информация о конфигурации, которая уже была собрана, становится действительной, как только ОС снова успешно соберет полную информацию о конфигурации по тому же адресу на сетевом уровне, независимо от того, истекло время удержания, определенное при сборе первоначальной информации, или нет.
9 ПОДМНОЖЕСТВО "ИНФОРМАЦИЯ О ПЕРЕАДРЕСАЦИИ" ОС
9.1 Использование переадресации
В данном разделе определяются процедуры, которые должны выполнять ОС при использовании подмножества "информация о переадресации" для выбора ППП, которому должен быть передан запрос соединения. Вопрос о том, использовать ли эту процедуру в любом конкретном сеансе взаимодействия или использовать ранее полученную информацию о переадресации или информацию о конфигурации, либо какой-то другой метод, является локальным.
Для того, чтобы привлечь процедуру переадресации, ОС должна выполнить процедуру установления ССУ, определенную в ГОСТ 34.954, но в качестве адреса ППП, по которому послан вызов, ОС должна использовать адрес ЛОРАП, как определено в разделе 7.
Примечания
1 Например, в случае подсети коммутации пакетов адрес ООД ЛОРАП может быть помещен в поле "адрес вызывающего" данного пакета. В случае ЛВС по ГОСТ 28907 ОС может работать в соответствии с ГОСТ Р ИСО/МЭК 8881, и адрес УЛЗ ЛОРАП может использоваться в качестве адреса получателя при передаче кадра, содержащего пакет "запрос вызова".
2 В тех случаях, когда в результате адрес в поле "адрес вызываемого" пакета "запрос вызова" оказывается адресом ЛОРАП, из положений ГОСТ 34.954 следует, что адрес вызываемого ПДУС кодируется в услуге "расширение адреса", поскольку удаленная ОС может оказаться не в состоянии извлечь его из поля адреса.
ОС должна продолжить работу с соединением в соответствии с ГОСТ 34.954.
9.2 Получение информации о переадресации
В данном разделе описана процедура, которую следует выполнить для получения информации о переадресации.
9.2.1 Процедура информации о переадресации при индикации завершения
ОС, которая реализует подмножество "информация о переадресации", должна выполнять эту процедуру всякий раз, когда попытка установить ССУ оказывается безуспешной по причине получения пакета "индикация завершения".
Примечание - Эта процедура не ограничивается теми вызовами, которые первоначально были переданы ЛОРАП в соответствии с 9.1. Это обусловлено тем, что даже в том случае, когда адрес ППП для данного вызова был выбран другими способами, он может фактически оказаться ППП системы с функциями ЛОРАП, либо вызов может быть переадресован ЛОРАП.
Должны быть проанализированы коды причины и диагностики для определения соответствующих значений параметров "причина" и "инициатор" примитива индикации разъединения услуг сетевого уровня в соответствии с критериями, определенными в ГОСТ 34.954.
Если значением параметра "инициатор" не является "поставщик УСУ", процедура считается выполненной, информация о переадресации отсутствует. ОС должна продолжить выполнение процедур, определенных в ГОСТ 34.954, для обработки индикаций завершения.
Если значением параметра "инициатор" является "поставщик УСУ", должно быть проанализировано поле "данные пользователя" пакета "индикация завершения".
Если это поле содержит ПБД ПОС и если задержка установления ССУ не превышена, то вызов должен быть повторен с использованием ППП в ПБД ПОС, если только он не совпадаете ППП, который был использован при безуспешном вызове.
Если пакет "индикация завершения" содержит ПБД ПОС, но превышена задержка установления ССУ, информация из ПБД ПОС может быть сохранена для использования при установлении последующих соединений с тем же адресом на сетевом уровне и тем же КУ, если только ППП не совпадает с тем, который был использован при безуспешном вызове, в случае чего эта информация должна быть аннулирована.
Если пакет "индикация завершения" не содержит ПБД ПОС, рекомендуется, чтобы в случае, если вызов первоначально был передан ЛОРАП в соответствии с 9.1, код причины завершения был проанализирован с точки зрения категорий, определенных в рекомендации Х.96 МККТТ. Если это код категории D, предпочтение должно быть отдано использованию другого адреса ППП для последующего доступа к ЛОРАП, если доступны другие адреса ППП ЛОРАП.
В случае, когда вызов, переданный ППП ЛОРАП, не приведет к установлению соединения при неполучении информации о переадресации, рекомендуется учитывать любую информацию о других возможных адресах ППП ЛОРАП, которые могут обеспечить информацию о переадресации при определении необходимости повторной попытки вызова в соответствии с ГОСТ 34.954.
ПБД ПОС может содержать параметры "маска адреса" и "маска ППП". Эти параметры могут быть использованы так, как описано в 10.1 и 10.2 соответственно.
9.2.2 Рекомендуемая обработка пакетов "соединение установлено"
В случае, когда ОС, реализующая подмножество информации о переадресации, получает пакет "соединение установлено", завершающий установление виртуального соединения, начатого передачей пакета "запрос вызова" в ППП ЛОРАП, рекомендуется, чтобы проверялось, указано ли в пакете "соединение установлено", что вызов был отражен (в соответствующих случаях) или переадресован. Если да, то ОС может зарегистрировать ППП, с которым, возможно, было установлено соединение, и может использовать эту информацию при установлении последующих соединений по тем же адресам сетевого уровня и тем же КУ, чтобы сохранить ссылку на данный ЛОРАП.
Однако ОС, реализующая эту рекомендацию, должна прекратить использование информации, полученной таким способом, если попытка ее использования привела к безуспешности установления соединения по причинам, отличным от причины отклонения соединения удаленным пользователем.
Примечания
1 ОС, которая реализует эту процедуру и использует зарегистрированный ППП для последующего соединения, необязательно должна использовать ее для всех подобных соединений, но может использовать ее в некоторых, но не во всех сеансах взаимодействия на основе локальных решений.
2 Поскольку не существует таймера, относящегося к получаемой таким способом информации, то возможно, что ОС может продолжить использование маршрута, когда он становится уже неоптимальным, при условии, что он все еще достаточно хорош для обеспечения требуемого КУ. ОС может использовать эту возможность не совсем оптимальной маршрутизации в противовес продолжающегося отсутствия доступа к ЛОРАП для получения новейшей информации (и последующего сокращения времени установления соединения).
9.3 Использование информации о переадресации
Настоящий стандарт не налагает никаких ограничений на то, какое количество информации о переадресации, полученной ОС, сохраняется или используется. ОС может в любой момент времени аннулировать полученную информацию и снова привлечь переадресацию для последующих соединений.
ОС может в любой момент времени использовать локальные сведения или другой способ определения ППП, который может быть использован при установлении любого ССУ независимо от того, получила она приемлемую информацию о переадресации или нет.
Полученная этим протоколом информация о переадресации действительна только с учетом следующих ограничений:
a) информация о переадресации, указывающая адрес того ППП, который должен использоваться для установления соединения, недействительна, если только она не была обеспечена в информации для соответствующего адреса сетевого уровня и не применима к диапазону КУ, который охватывает минимально приемлемое КУ для требуемого ССУ;
b) информация о переадресации недействительна, если время, прошедшее с момента ее получения, больше, чем определено в поле "время удержания" того ПБД ПОС, который передал ее;
c) элемент информации о переадресации становится недействительным, если попытка установления соединения, использующая этот элемент, оказалась безуспешной по причинам, отличным от отказа удаленного пользователя.
10 МАСКИ АДРЕСА И ППП
В данном разделе описывается метод передачи дополнительной информации в ПБД ОКЛ и ПБД ПОС. Эта информация передается посредством полей ПБД "маска адреса" и "маска ППП", значимость которых описывается ниже.
ЛОРАП может факультативно ввести в любой ПБД ОКЛ или ПБД ПОС либо только поле "маска адреса", либо и поле "маска адреса" и поле "маска ППП". При получении одного из таких блоков ПБД, содержащих любое из этих полей, ОС должна либо проигнорировать оба этих поля, либо обработать их, как описано в следующих подразделах.
10.1 Маска адреса
Параметр "маска адреса" указывает, что информация продвижения применима к большему числу АСУ по сравнению с исходным адресуемым АСУ, относящимся к полученному ПБД ОКЛ или ПБД ПОС. Оконечная система может по своему усмотрению проигнорировать этот параметр.
Маска адреса устанавливает эквивалентный класс АСУ, с которым применима одна и та же информация продвижения. Для того, чтобы определить, попадает потенциальный адресуемый АСУ в эквивалентный класс или нет, инициирующая система уравнивает потенциальный адресуемый АСУ с маской адреса, заполняя последний при необходимости концевыми нулевыми октетами (двоичные 0000 0000). Если во всех битовых позициях, где маска адреса равна "1", концевой АСУ совпадает с АСУ, относящимся к ПБД ОКЛ или ПБД ПОС, то этот концевой адресуемый АСУ относится к эквивалентному классу, описываемому в ПБД ОКЛ или ПБД ПОС. При принятии решений о маршрутизации точное совпадение АСУ более предпочтительно по сравнению с использованием эквивалентных классов. Точное совпадение имеет место, когда исследуемый АСУ идентичен одному из АСУ, относящемуся к ПБД ОКЛ или ПБД ПОС без учета каких-либо масок. Если адресуемый АСУ находится в пределах нескольких эквивалентных классов, то вопрос, какой из них использовать, если такой выбор имеется, является локальным.
Все нулевые маски адреса могут использоваться с целью указания всеобщей ПС для таких исходящих вызовов, для которых маршрутизация в другом виде неизвестна.
Примечание - Если маска адреса выбрана в соответствии с границами в иерархически администрируемом адресе сетевого уровня, она допускает маршрутизацию со стороны подсети, маршрутизацию со стороны региона или по другим административно управляемым критериям.
Параметр "маска адреса" имеет дополнительную семантику при ее рассмотрении в сочетании с параметром "маска ППП" (см. 8.1.5).
10.2 Маска ППП
При наличии маски ППП эквивалентный класс, определяемый маской адреса, также имеет общую структуру ниже маски адреса, то есть в той части адреса сетевого уровня, где маска адреса логически равна 0. Маска ППП обеспечивает дополнительную информацию о структуре, указывая определенные битовые позиции в пространстве "ниже" маски адреса. В частности маска ППП указывает положение ППП в адресе сетевого уровня.
Система, которая принимает ПБД ОКЛ или ПБД ПОС, содержащие маски адреса и/или маски ППП, может предпочесть игнорирование обеих масок. Поскольку наличие обеих масок диктует другое поведение, чем в случае наличия только одной маски, ОС не должна игнорировать одну из этих масок, когда необходима другая. Если ОС получает один из таких ПБД, который содержит маску ППП, но не содержит маску адреса, она должна либо проигнорировать маску ППП, либо считать ПБД недействительным.
11 ПРОЦЕДУРЫ ЛОРАП
Процедуры, которые должен выполнять ЛОРАП при выполнении своих функций, объединенных с функциями подсети Х.25, не входят в предмет рассмотрения настоящего стандарта. В данном разделе описываются те процедуры, которые должна выполнять система, соединенная с подсетью для выполнения функций ЛОРАП.
При получении пакета "входящий вызов" ЛОРАП, если он имеет в данный момент ресурсы для приема вызова, должен проанализировать первым октет поля "данные пользователя" и действовать затем следующим образом:
a) Если данные пользователя отсутствуют, или если первый октет имеет значение в диапазоне 0000 0010-0011 1111, ЛОРАП должен действовать в соответствии с требованиями 11.2.
b) Если первый октет данных пользователя имеет значение, определенное в 12.1.1, ЛОРАП должен действовать в соответствии с требованиями 11.1.
c) В любом другом случае действия, выполняемые ЛОРАП, не входят в предмет рассмотрения настоящего стандарта.
11.1 Обработка подмножества "информация о конфигурации"
11.1.1 Параметры протокола
В данном разделе определяются параметры, используемые в протоколе, и в применимых случаях устанавливаются требования к значениям параметров, которые должны быть обеспечены всеми системами, претендующими на соответствие. Возможность обеспечивать значения, отличные о тех, которые специально заданы, и способы, определяющие использование таких значений в любом конкретном случае, являются частными вопросами.
11.1.1.1 Время запроса
Этот параметр указывает время, в течение которого ЛОРАП должен ожидать запросов от ОС, с которой у него установлено соединение, либо может указывать на неограниченное время ожидания.
Любая реализация ЛОРАП должна обеспечивать время запроса 60 с с точностью ±10 с.
11.1.2 Процедура информации о конфигурации
Если поле "данные пользователя" пакета "входящий вызов" не содержит действительного ПБД СОС, ЛОРАП должна завершить соединение в соответствии с процедурами завершения виртуального соединения, определенными в ГОСТ Р 34.950, с кодом причины 0 и кодом диагностики 248.
Если вызов не содержит услуги "быстрая выборка без ограничений", ЛОРАП должен завершить соединение с кодом причины 0 и кодом диагностики 76.
Если ЛОРАП временно неспособен обработать информацию о конфигурации, он должен завершить соединение с кодом причины 0 и кодом диагностики 244.
Если ЛОРАП не желает обеспечивать услуги вызывающей ОС, он должен завершить соединение с кодом причины 0 и кодом диагностики 245.
В противном случае ЛОРАП должен принять вызов в соответствии с процедурами установления соединения, определенными в ГОСТ Р 34.950, передав ПБД ЗУЛ в поле "данные пользователя" пакета "соединение установлено". Поле "время запроса" ПБД ЗУЛ должно указывать наибольшее значение, которое допускается кодом поля, определенным в 12.1.11, и которое не превышает предела минимального времени, при его наличии, в течение которого ЛОРАП может ожидать запроса от той ОС, с которой у него установлено соединение.
Примечание 1 - Минимальный предел времени, в течение которого ЛОРАП может ожидать запросов, определяется значением параметра "время запроса", обеспечивая допуски такой точности, с которой реализован этот параметр.
ЛОРАП должен работать с виртуальным соединением в соответствии с процедурами передачи данных, определенными в ГОСТ Р 34.950. Если он получает индикацию сброса, пакет данных с установленным битом 0, пакет прерывания или данные, которые не соответствуют форматам ПБД, определенным в разделе 12, он должен завершить соединение с кодом причины 0 и кодом диагностики 242.
Если время, превышающее значение параметра "время запроса", истекло до получения ПБД ЗОС или ПБД ЗКОС, ЛОРАП должен завершить соединение с кодом причины 0 и кодом диагностики 242.
При получении ПБД ЗОС ЛОРАП должен записывать содержащуюся в них информацию.
Примечания
1 Использование этой информации ЛОРАП не входит в предмет рассмотрения настоящего стандарта.
2 Определение маршрутов на основе информации, полученной через функцию уведомления о конфигурации, может в некоторых случаях внести риск защищенности информации. Можно уменьшить такой риск административным или локальным решением, используя возможности протокола ГОСТ Р 34.950, который обеспечивает некоторую степень идентификации, как например, закрытие группы пользователей.
Если после получения ПБД ЗВОС ЛОРАП получает ПБД ЗКОС до получения ПБД ЗУОС, он должен завершить соединение с кодом причины 0 и кодом диагностики 243. Он может, но не обязательно, поступать так, когда он принимает несколько ПБД ЗВОС, определяющих один и тот же адрес на сетевом уровне.
Если после получения ПБД ЗВОС, но до получения ПБД ЗУОС или другого ПБД ЗВОС прошло больше времени, чем определено параметром "время запроса", ЛОРАП должен завершить соединение с кодом причины 0 и кодом диагностики 242.
При получении ПБД ЗУОС ЛОРАП должен предусмотреть, чтобы информация, полученная из ПБД ЗВОС, была закрыта до такой степени, которая необходима для ее использования, и затем передать ПБД ЗЗЛ в простой последовательности бита М в соответствии с процедурами, определенными в ГОСТ Р 34.950. Параметр "требуется уведомление" ПБД ЗЗЛ должен быть установлен в значение, указывающее время, в течение которого предполагается, что ОС должна ожидать при отсутствии изменения конфигурации или доступности перед выполнением последующего уведомления. Если после этого ЛОРАП получает другой ПБД ЗВОС, он должен завершить соединение, используя код причины 0 и код диагностики 243.
Если после получения ПБД ЗЗЛ и при отсутствии ПБД ЗКОС прошло время, превышающее время запроса, ЛОРАП должен завершить соединение с кодом причины 0 и кодом диагностики 242.
При получении ПБД ЗКОС и при наличии у ЛОРАП информации о пунктах ППП подсети, которая может быть использована ОС для достижения определенного адреса на сетевом уровне, ЛОРАП должен передать ПБД ОКЛ для каждого такого ППП. Если ЛОРАП уже передал ПБД ОКЛ для каждого соответствующего ППП (либо сразу же при отсутствии информации о любом подходящем ППП), он должен передать ПБД ЗКЛ. Поле "предельное число запросов" ПБД ЗКЛ должно быть установлено ЛОРАП в значение, определяющее допустимость другого запроса.
Если после передачи ПБД ЗКЛ и до получения другого ПБД ЗКОС прошло время, превышающее время запроса, ЛОРАП должен завершить соединение с кодом причины 0 и кодом диагностики 242.
Если ЛОРАП получил другой ПБД СОС или если он получил другой ПБД ЗКОС до передачи ЗКЛ, происходящей из предыдущей передачи, либо если он получил ПБД, отличные от указанных выше, он должен завершить соединение, используя код причины 0 и код диагностики 243.
Если ЛОРАП получил другой ПБД ЗКОС после передачи ПБД ЗКЛ с полем "предельное число запросов", определяющим отсутствие последующих запросов, он должен завершить соединение с кодом причины 0 и кодом диагностики 242.
11.2 Обработка подмножества "переадресация"
ЛОРАП должен определять "адрес вызываемого" на сетевом уровне, идентифицируемый пакетом "запрос вызова", в соответствии с ГОСТ 34.954. Если это адрес на сетевом уровне, назначенный для самого ЛОРАП, то ЛОРАП должен управлять ССУ в соответствии с процедурами, определенными в ГОСТ 34.954.
Если адрес на сетевом уровне расположен в другой системе, к которой инициирующая ОС может обратиться через другой ППП той же подсети с приемлемым качеством услуг, ЛОРАП должен выполнить одно из следующих действий:
a) Если услуга "отражение вызова" доступна для использования при данном вызове, ЛОРАП может использовать ее в соответствии с процедурами ГОСТ Р 34.950 для отражения вызова к соответствующему ППП.
b) Если услуга "отражение вызова" недоступна или если ЛОРАП решает не использовать ее, он должен завершить соединение в соответствии с процедурами завершения виртуального соединения, определенными в ГОСТ Р 34.950, используя код причины 0 и код диагностики 230, и передать ПБД ПОС в поле "данные пользователя" пакета "запрос завершения". Однако, если пакет "запрос вызова" не имеет услуги "быстрая выборка", он должен завершить соединение без данных пользователя с кодом причины 0 и кодом диагностики 76.
Если ЛОРАП не имеет информации, указывающей ППП, через который может быть установлено требуемое ССУ, он должен завершить соединение без данных пользователя с кодом причины 0 и кодом диагностики 232.
12 СТРУКТУРА И КОДИРОВАНИЕ ПБД
12.1 Параметры
ПБД должен содержать, по меньшей мере, следующие параметры в указанной последовательности:
- идентификатор протокола сетевого уровня;
- номер версии;
- тип ПБД.
Все другие перечисленные параметры имеют место в некоторых ПБД, как указано в 12.2.
12.1.1 Идентификатор протокола сетевого уровня
Значение этого параметра должно быть равно 1000 1010.
Этот параметр идентифицирует протокол сетевого уровня, как указано в настоящем стандарте.
12.1.2 Номер версии
Значение этого параметра 000 0001. Оно определяет версию настоящего стандарта.
12.1.3 Тип ПБД
Параметр "тип ПБД" определяет тип протокольного блока данных. Допустимые значения приведены в таблице 1.
Таблица 1 - Типы действительных ПБД
|
|
|
|
|
|
|
|
|
Тип ПБД | Биты | |||||||
| 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
ПБД ЗКОС | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 |
ПБД ЗУОС | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 |
ПБД СОС | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 1 |
ПБД ЗВОС | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 |
ПБД ПОС | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
ПБД ЗКЛ | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 |
ПБД ОКЛ | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 |
ПБД ЗВЛ | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 |
ПБД ЗУЛ | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 1 |
ПБД ЗЗЛ | 0 | 0 | 0 | 0 | 1 | 1 | 0 | 0 |
ПБД ПУЛ | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 1 |
Все другие значения типов ПБД зарезервированы.
12.1.4 Адрес на сетевом уровне
В ПБД ЗВОС он определяет адрес на сетевом уровне, который сообщен как имеющийся и доступный в данной ОС. В ПБД ЗКОС он определяет адрес на сетевом уровне, для которого должна быть собрана информация. В ПБД ОКЛ и ПБД ЗКЛ он определяет адрес на сетевом уровне, для которого обеспечивается информация.
Параметр "адрес на сетевом уровне" кодируется, как показано на рисунке 1.
|
|
| Октет |
Указатель длины адреса на сетевом уровне (например, k) | j |
| j+1 |
Значение параметра "адрес на сетевом уровне" |
|
| j+k |
Рисунок 1 - Параметр "адрес на сетевом уровне"
Содержимое этого поля должно кодироваться в соответствии с предпочтительным двоичным кодированием, определенным в ГОСТ Р ИСО 8348/Доп.2.
12.1.5 Адрес ППП
В ПБД ОКЛ и ПБД ПОС он определяет адрес ППП, который может использоваться для обращения к требуемому адресу на сетевом уровне.
Параметр "адрес ППП" кодируется в соответствии с рисунком 2.
|
|
|
| Октет | |
Тип | Указатель длины адреса ППП (например, k) | j |
| j+1 | |
Значение параметра "адрес на сетевом уровне" |
| |
| j+k | |
Рисунок 2 - Параметр "адрес ППП"
Поле "тип" состоит из двух битов, указывающих формат кодирования ПП. Оно принимает следующие значения:
00 - кодирование в соответствии с настоящим стандартом;
01 - зарезервировано;
10 - зарезервировано;
11 - локальное - только для временного использования.
Если поле "тип" имеет значение 00, то следующие 6 битов представляют собой длину поля "значение параметра адреса ППП". Определены следующие стандартные коды:
a) Если адрес ППП передан в соответствии с протоколом доступа к подсети в виде последовательности целых октетов, то эта последовательность октетов представляет собой значение поля "значение параметра адреса ППП".
Примечание 1 - Сюда относятся, например, адреса УДС по ГОСТ 28907, которые должны быть представлены в двоичном коде адресов УДС в соответствии с ГОСТ 34.936, а также те ситуации, где используется код МК5.
b) Если адрес ППП передан в соответствии с протоколом доступа к подсети в виде последовательности полуоктетов с использованием кода ДДК, то эта последовательность кодируется в поле "значение параметра адреса ППП" и представлена нечетным числом полуоктетов с последним полуоктетом, содержащим значение 1111 в конце последовательности.
Примечание 2 - Значения по подпунктам а) и b) выбирают с таким расчетом, чтобы они соответствовали тем значениям, которые должны быть общеиспользуемыми в полях ППП ГОСТ Р ИСО/МЭК 9542 с точки зрения одних и тех же требований, предъявляемых этим стандартом.
12.1.6 Качество услуг
В ПБД ОКЛ этот параметр определяет диапазон КУ, в котором применим указанный ППП. В ПБД ЗВОС он определяет диапазон КУ, который может быть обеспечен указанной ОС заданного ППП.
Параметр КУ кодируется в соответствии с рисунком 3.
|
|
| Октет |
Код параметра | j |
Длина параметра | j+1 |
| j+2 |
Значение параметра |
|
| j+k+1 |
Рисунок 3 - Кодирование параметров КУ
Поле "код параметра" представляется в двоичном виде и при отсутствии расширений обеспечивает максимум 255 различных параметров. Код 255 (двоичное значение 1111 1111) зарезервирован для возможных будущих расширений.
Поле "длина параметра" указывает длину в октетах поля "значение параметра". Длина указывается положительным двоичным числом k, теоретическое максимальное значение которого равно 254. Практическое максимальное значение k меньше и с каждым следующим параметром максимальное значение k уменьшается.
Поле "значение параметра" содержит значение параметра, указанное полем "код параметра".
12.1.6.1 Пропускная способность
При наличии параметра КУ "пропускная способность" он указывает диапазон значений пропускной способности, относящихся к заданному маршруту.
|
|
Код параметра | 0000 0001 |
Длина параметра: | Один октет. |
Значение параметра: | Четыре наиболее значащих бита определяют максимальную пропускную способность в соответствии с кодом, заданным в таблице 18 ГОСТ 28907; четыре наименее значащих бита определяют минимальную пропускную способность в соответствии с кодом, заданным в таблице 18 ГОСТ 28907. |
12.1.6.2 Транзитная задержка
При наличии параметра КУ "транзитная задержка" он указывает максимальное и минимальное значения транзитной задержки, которые следует ожидать на заданном маршруте.
|
|
Код параметра: | 0000 0010 |
Длина параметра: | Четыре октета. |
Значение параметра: | Первые два октета определяют целое число секунд, указывающих максимальное значение ожидаемой транзитной задержки, а следующие два октета - минимальное значение ожидаемой транзитной задержки. |
12.1.6.3 Приоритет
При наличии параметра КУ "приоритет" он определяет максимальное и минимальное значения приоритета данных в соединении, приоритет получения соединения и приоритет сохранения соединения по заданному маршруту.
|
|
Код параметра: | 0000 0011 |
Длина параметра: | Шесть октетов. |
Значение параметра: | Первые три октета определяют максимальное значение приоритета данных в соединениях, приоритет получения соединения и приоритет сохранения соединения соответственно. Следующие три октета определяют минимальное значение приоритета данных в соединении, приоритет получения соединения и приоритет сохранения соединения соответственно. |
12.1.6.4 Защита
При наличии параметра КУ "защита" он указывает максимальное и минимальное значения уровней защиты информации, ожидаемые в данном маршруте.
|
|
Код параметра: | 0000 0100 |
Длина параметра: | Переменная. |
Значение параметра: | Биты 8 и 7 первого октета определяют код формата защиты, а именно: |
| 00 - зарезервировано; |
| 01 - конкретный адрес отправления; |
| 10 - конкретный адрес получателя; |
| 11 - глобальный уникальный. |
| Остальные шесть битов первого октета зарезервированы и должны быть установлены в значение 0. Второй октет определяет длину  в октетах максимального ожидаемого уровня защиты. Фактическое значение максимального уровня защиты содержится в следующих октетах. |
| Октет +2 определяет длину  в октетах минимального ожидаемого уровня защиты. Фактическое значение минимального уровня защиты содержится в следующих октетах. |
12.1.7 Время сохранения
В ПБД ОКЛ и ПОС это двухоктетный параметр, определяющий целое число секунд, в течение которых передаваемая информация является действительной. Двоичное значение 0000 0000 0000 0000 указывает, что временной предел отсутствует.
12.1.8 Маска адреса
При наличии этого поля в ПБД ОКЛ и ПОС оно содержит маску адреса, которая должна использоваться в соответствии с 10.1.
Параметр "маска адреса" кодируется следующим образом:
|
|
Код параметра: | 1110 0001 |
Длина параметра: | Переменная, до 20 октетов. |
Значение параметра: | Маска сравнения октетов, которая должна быть уравнена с адресом получателя. |
12.1.9 Маска ППП
При наличии этого поля в ПБД ОКЛ и ПОС оно содержит маску ППП, которая должна использоваться в соответствии с 10.2.
|
|
Код параметра: | 1110 0010 |
Длина параметра: | Переменная. |
Значение параметра: | Маска сравнения октетов, которая должна быть уравнена с адресом получателя. |
12.1.10 Предельное число запросов
В ПБД ЗКЛ это поле определяет, разрешено ли ОС запрашивать информацию о конфигурации относительно другого адреса на сетевом уровне, либо ОС не может больше выдавать никаких запросов по данному соединению.
Параметр "предельное число запросов" кодируется одним октетом, где двоичное значение 0000 0000 указывает, что последующие запросы не разрешаются, а двоичное значение 0000 0001 - что ОС разрешено выдать следующий запрос, если она пожелает.
12.1.11 Время запросов
В ПБД ЗУЛ этот параметр указывает промежуток времени между запросами от ОС, допускаемый ЛОРАП. Двоичное значение 0000 0000 указывает отсутствие временного предела.
Параметр "время запроса" кодируется в виде одного октета, определяющего целое число секунд.
12.1.12 Требуется уведомление
В ПБД ПУЛ этот параметр указывает временной интервал, в течение которого ОС может не выдавать ЛОРАП повторного уведомления.
Параметр "требуется уведомление" является двухоктетным и определяет целое число секунд временного интервала. Двоичное значение 0000 0000 0000 0000 означает, что уведомление не требуется. Двоичное значение 1111 1111 1111 1111 означает, что никакого конкретного значения не рекомендуется.
12.2 Структура ПБД
Все ПБД состоят из целого числа октетов. В ПБД октеты нумеруются в возрастающем порядке, начиная с 1. Биты октета нумеруются от 1 до 8, при этом бит 1 является битом младшей значимости.
При использовании последовательности октетов для представления двоичного числа октет с наименьшим номером имеет наибольшую значимость.
Примечание - Если ПБД кодируется с использованием диаграмм данного раздела, то используется следующее представление:
- октеты указаны в верхней части с наименьшим номером, а в нижней - с наибольшим номером;
- в пределах октета бит 8 показан слева, а бит 1 - справа.
12.2.1 Структура ПБД ЗКОС
Формат ПБД ЗКОС показан на рисунке 4.
|
|
| Октет |
Идентификатор протокола сетевого уровня | 1 |
Номер версии | 2 |
Тип ПБД | 3 |
Указатель длины адреса на сетевом уровне | 4 |
Адрес на сетевом уровне | 5 |
| k-1 |
Рисунок 4 - Структура ПБД ЗКОС
12.2.2 Структура ПБД ЗУОС
Формат ПБД ЗУОС показан на рисунке 5.
|
|
| Октет |
Идентификатор протокола сетевого уровня | 1 |
Номер версии | 2 |
Тип ПБД | 3 |
Рисунок 5 - Структура ПБД ЗУОС
12.2.3 Структура ПБД СОС
Формат ПБД СОС показан на рисунке 6.
|
|
| Октет |
Идентификатор протокола сетевого уровня | 1 |
Номер версии | 2 |
Тип ПБД | 3 |
Рисунок 6 - Структура ПБД СОС
12.2.4 Структура ПБД ЗВОС
Формат ПБД ЗКОС показан на рисунке 7.
|
|
| Октет |
Идентификатор протокола сетевого уровня | 1 |
Номер версии | 2 |
Тип ПБД | 3 |
Указатель длины адреса на сетевом уровне | 4 |
| 5 |
Адрес на сетевом уровне |
|
| k-1 |
| k |
КУ |
|
| k+m |
Рисунок 7 - Структура ПБД ЗВОС
12.2.5 Структура ПБД ПОС
Формат ПБД ЗКОС показан на рисунке 8.
|
|
|
| Октет | |
Идентификатор протокола сетевого уровня | 1 | |
Номер версии | 2 | |
| 3 | |
Тип ПБД |
| |
| 4 | |
Время удержания | 5 | |
Тип | Указатель длины адреса ППП | 6 |
Значение параметра адреса ППП | 7
k-1 | |
| k | |
Параметр маски адреса |
| |
| m-1 | |
| m | |
Параметр маски ППП |
| |
| n-1 | |
Рисунок 8 - Структура ПБД ПОС
12.2.6 Структура ПБД ЗКЛ
Формат ПБД ЗКЛ показан на рисунке 9.
|
|
| Октет |
Идентификатор протокола сетевого уровня | 1 |
Номер версии | 2 |
Тип ПБД | 3 |
Указатель длины адреса на сетевом уровне | 4 |
| 5 |
Адрес на сетевом уровне |
|
| k-1 |
| m |
Предел запросов |
|
| n-1 |
Рисунок 9 - Структура ПБД ЗКЛ
12.2.7 Структура ПБД ОКЛ
Формат ПБД ОКЛ показан на рисунке 10.
|
|
|
| Октет | |
Идентификатор протокола сетевого уровня | 1 | |
Номер версии | 2 | |
| 3 | |
Тип ПБД |
| |
| 4 | |
Время удержания | 5 | |
Указатель длины адреса на сетевом уровне | 6 | |
| 7 | |
Адрес на сетевом уровне |
| |
| k-1 | |
Тип | Указатель длины адреса ППП | k |
| k+1 | |
Значение параметра адреса ППП |
| |
| m-1 | |
| m | |
Параметр маски адреса |
| |
| n-1 | |
| n | |
Параметр маски ППП |
| |
| p-1 | |
| p | |
КУ |
| |
| p+q | |
Рисунок 10 - Структура ПБД ОКЛ
12.2.8 Структура ПБД ЗУЛ
Формат ПБД ЗУЛ показан на рисунке 11.
|
|
| Октет |
Идентификатор протокола сетевого уровня | 1 |
Номер версии | 2 |
Тип ПБД | 3 |
Время запроса | 4 |
Рисунок 11 - Структура ПБД ЗУЛ
12.2.9 Структура ПБД ПУЛ
Формат ПБД ПУЛ показан на рисунке 12.
|
|
| Октет |
Идентификатор протокола сетевого уровня | 1 |
Номер версии | 2 |
Тип ПБД | 3 |
Требуется уведомление | 4 |
Рисунок 12 - Структура ПБД ПУЛ
ПРИЛОЖЕНИЕ А
(обязательное)
ПОЛУЧЕНИЕ АДРЕСОВ ППП ЛОРАП С ИСПОЛЬЗОВАНИЕМ ПРОЦЕДУР
УЛЗ ТИПА 1
А.1 Введение
В данном приложении приводится описание тех процедур, которые могут быть использованы в некоторых конкретных ситуациях с тем, чтобы обеспечить возможность оконечным системам распознавать адреса ППП ЛОРАП.
А.2 Широковещательные подсети, использующие процедуры УЛЗ типа 1
Широковещательная подсеть - это такая подсеть, физические характеристики которой позволяют обеспечить прием отдельной передачи ПБДС всеми системами или предварительно заданной группой систем, подключенных к подсети. Данный раздел относится к тем широковещательным подсетям, в которых используются процедуры УЛЗ типа 1, определенные в ГОСТ 28907.
При выполнении процедур, описываемых в данном разделе, должно использоваться значение ПДУЗ, приведенное в ИСО/МЭК ТО 10178 для использования совместно с ИСО/МЭК ТО 9577. В ПБД данного протокола входит поле идентификатор исходного протокола (ИИП), обеспечивающее идентификацию протокола способами, описанными в ИСО/МЭК ТО 9577.
А.2.1 Широковещательные процедуры УЛЗ типа 1 ЛОРАП
А.2.1.1 Параметры протокола
А.2.1.1.1 Параметр "время широковещательной передачи" определяет временной интервал, в течение которого ЛОРАП, реализующий данную процедуру, может передавать широковещательную информацию, чтобы обеспечить распознавание своего ЛОРАП.
А.2.1.1.2 Параметр "время сохранения" входит в передаваемые ПБД и указывает время, в течение которого содержащаяся в них информация остается действительной.
А.2.1.2 Операции протокола
Объект ЛОРАП, подключенный к ЛВС в соответствии с ГОСТ 28907 и выполняющий широковещательные процедуры ЛОРАП, должен передавать ПБД ЗВЛ, сформированный в соответствии с А.2.3, через интервалы времени, равные значению параметра "время широковещательной передачи". Он должен передавать эти ПБД с использованием примитива ЗД-БЛОК-ДАННЫХ запрос, определяющего адрес получателя, значение которого в данной подсети должно означать "все оконечные системы с УСУ УС".
А.2.2 Широковещательные процедуры УЛЗ типа 1 ОС
Оконечная система, подключенная к ЛВС в соответствии с ГОСТ 28907 и выполняющая широковещательные процедуры УЛЗ типа 1 ОС, должна воспринимать примитив ЗД-БЛОК-ДАННЫХ индикация, чей адрес получателя представляет собой значение, которое в данной подсети должно означать "все оконечные системы с УСУ УС".
При получении примитива ЗД-БЛОК-ДАННЫХ индикация должны быть проанализированы содержащиеся в нем данные. Если он не содержит ПБД ЗВЛ, сформированный в соответствии с А.2.3, он должен быть проигнорирован. Если же он содержит такой ПБД и если ОС еще не имеет зарегистрированный адрес ППП ЛОРАП, ОС должна зарегистрировать адрес отправителя, от которого получен примитив ЗД-БЛОК-ДАННЫХ в качестве адреса ППП ЛОРАП, и должна увязать его со временем, указанным в поле "время сохранения".
При получении действительного ПБД ЗВЛ, когда ОС имеет зарегистрированный адрес отправителя в качестве адреса ППП ЛОРАП, она должна обновить регистрацию соответствующего параметра "время сохранения" на содержащееся в полученном ПБД.
При получении действительного ПБД ЗВЛ, когда ОС уже имеет зарегистрированный адрес ППП ЛОРАП, но не адрес, содержащийся в адресе отправителя из примитива ЗД-БЛОК-ДАННЫХ индикация, ОС может зарегистрировать ППП и время сохранения, как указано выше, но необязательно. Если она выполняет такую регистрацию, она может аннулировать любой из уже зарегистрированных адресов ППП ЛОРАП или все такие адреса.
ОС должна аннулировать любой зарегистрированный адрес ППП ЛОРАП, если время, прошедшее с момента получения последнего ПБД ЗВЛ из данного адреса, достигло соответствующего времени сохранения.
Кроме того, ОС может проанализировать поле "требуется уведомление" и определить необходимость уведомления.
А.2.3 Структура ПБД ЗВЛ
ПБД ЗВЛ формируется в соответствии с рисунком А.1.
|
|
| Октет |
Идентификатор протокола сетевого уровня | 1 |
Номер версии | 2 |
Тип ПБД | 3 |
| 4 |
Требуется уведомление |
|
| 5 |
| 6 |
Время сохранения |
|
| 7 |
Рисунок А.1 - Структура ПБД ЗВЛ
А.3 Широковещательная процедура УЛЗ типа 1 ОС
Эта процедура является факультативной
При функционировании процедур, описываемых в данном разделе, применяют значение ПДУЗ, установленное в ИСО/МЭК ТО 10178 при совместном использовании с ИСО/МЭК ТО 9577. В ПБД данного протокола входит поле ИИП, обеспечивающее идентификацию протокола способами, описанными в ИСО/МЭК ТО 9577.
ОС, которая подключена к ЛВС в соответствии с ГОСТ 28907 и желает распознавать адрес ППП ЛОРАП, но которая еще не получила ПБД ЗВЛ, может передать ПБД ЗЗЛ, сформированный в соответствии с А.3.1. Она должна передать этот ПБД ЗЗЛ, используя примитив ЗД-БЛОК-ДАННЫХ запрос, определяющий адрес получателя, значение которого в данной подсети должно означать "все ЛОРАП Х.25".
Объект ЛОРАП, подключенный к ЛВС по ГОСТ 28907 и желающий выполнять широковещательные процедуры ЛОРАП, должен воспринимать примитивы ЗД-БЛОК-ДАННЫХ индикация, адреса получателя которых в данной подсети означают "все ЛОРАП Х.25".
При получении примитива ЗД-БЛОК-ДАННЫХ индикация должны быть проанализированы содержащиеся в нем данные. Если он не содержит ПБД ЗВЛ, сформированный в соответствии с А.3.1, он должен быть проигнорирован. Если же он содержит такой ПБД, ЛОРАП должен передать ПБД ЗВЛ в соответствии с А.2.
Примечание - Такая передача ПБД ЗВЛ со стороны ЛОРАП должна рассматриваться как дополнительная передача и, следовательно, не должна приводить к сбросу нормального тайм-аута для ПБД ЗВЛ.
А.3.1 Структура ПБД ЗЗЛ
Формат ПБД ЗЗЛ показан на рисунке А.2.
|
|
| Октет |
Идентификатор протокола сетевого уровня | 1 |
Номер версии | 2 |
Тип ПБД | 3 |
Рисунок А.2 - Структура ПБД ЗЗЛ