Стр. 1
 

42 страницы

517.00 ₽

Купить официальный бумажный документ с голограммой и синими печатями. подробнее

Официально распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО "ЦНТИ Нормоконтроль".

Наши цены ниже, чем в других местах, потому что мы работаем напрямую с поставщиками документов.

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

Определяет протокол обмена маршрутной информацией между оконечной системой (ОС) и логическим обьектом разрешения адреса подсети.

Настоящий стандарт применим:

a) к оконечным системам, работающим в соответствии с основной частью ГОСТ 34.954 для обеспечения и поддержки услуг сетевого уровня в режиме с установлением соединения при использовании ГОСТ Р 34.950;

б) к логическим обьектам разрешения адресов подсети, функционирующим в соостветствии с ГОСТ Р 34.950.

Настоящий стандарт не определяет каких-либо протокольных элементов или алгоритмов для обеспечения маршрутизации между логическими объектами разрешения адресов подсети.

Стандарт предназначен для:

а) минимизации объема априорной информации о состоянии, необходимой оконечным системам до того, как они смогут начать обмен данными с другими ОС;

b) минимизации объема памяти, необходимой для хранения маршрутной информации в ОС;

c) минимизации вычислительной сложности алгоритмов маршрутизации оконечных систем

Оглавление

Введение

1 Назначение

2 Нормативные ссылки

3 Определения

4 Сокращения

5 Общее описание протокола

6 Соответствие

7 Адрес подсети ЛОРАП

8 Подмножество "Информация о конфигурации" ОС

9 Подмножество "Информация о переадресации" ОС

10 Маски адреса и ППП

11 Процедуры ЛОРАП

12 Структура и кодирование ПБД

Приложение А Получение адресов ППП ЛОРАП с использованием процедур УЛЗ типа 1

Показать даты введения Admin

Страница 1

ГОСТ P ИСО/МЭК 100.10-96 ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ИНФОРМАЦИОННАЯ ТЕХНОЛОГ ИЯ

ПЕРЕДАЧА ДАННЫХ И ОБМЕН ИНФОРМАЦИЕЙ МЕЖДУ СИСТЕМАМИ. ПРОТОКОЛ ОБМЕНА МАРШРУТНОЙ ИНФОРМАЦИЕЙ ОКОНЕЧНОЙ СИСТЕМЫ ДЛЯ ИСПОЛЬЗОВАНИЯ В СОЧЕТАНИИ С ГОСТ 34.954-91

Изляние официальное

I —95/36


ГОССТАНДАРТ РОССИИ Москва

2

Страница 2

ГОСТ Р ИСО/МЭК 10030-96

Предисловие

1    РАЗРАБОТАН Московским научно-исследовательским центром (МНИЦ) Комитета при Президенте Российской Федерации по политике информатизации и Российским научно-исследовательским институтом информационных систем (РосНИИ ИС)

ВНЕСЕН Комитетом при Президенте Российской Федерации по политике информа1изаиии

2    ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 10 июни 1946 г № 369

Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 10030 90 "Информационная технология Пе|>елача данных и обмен информацией между системами. Протокол обмена маршрутной информацией оконечной системы для использования в сочетании с ИСО 8878”

3    ВВЕДЕН ВПЕРВЫЕ

<9 ИПК Издательство стандартов. 1996

Настоящий стандарт не может быть полностью или частично воспроизведен, тиражирован и распространен в качестве официального издания без разрешения Госстандарта России

II

Страница 3

ГОСТ Р ИСО/МЭК 10050—96

Содержание

Введение.......................................... IV

1    Назначение ..................................... I

2    Нормативные ссылки.............................. 2

3    Определения .................................... 3

4    Сокращения..................................... 4

5    Общее описание протокола.......................... 5

6    Соответствие..................................... 8

7    Адрес подсети ЛОРАГ1 ............................. 9

8    Подмножество "Информация    о конфигурации"    ОС........ 9

9    Подмножество ’Информация    о переадресации"    ОС........ 16

10    Маски адреса и ППП ............................ 19

11    Процедуры ЛОРАП ...........................20

12    Структура и кодирование 11 БД....................... 24

Приложение А Получение адресов ППП ЛОРАП с использованием процедур УЛЗ типа I.............. 34

ill

Страница 4

I ОСТ P ИСО/МЭК 10030-96

Введение

Настоящий стандарт — один из совокупности стандартов, относящихся к протоколам маршрутизации на сетевом уровне Общие основы маршрутизации изложены в ИСО/МЭК ТО 9575. Настоящий стандарт касается в основном той части указанных основ, в которой рассматривается маршрутизация по отдельной подсети

Настоящий стандарт должен применяться совместно с ГОСТ 34 954. который определяет использование рекомендации X 25 для обеспечения услуг сетевою уровня в режиме с установлением соединения. Этот стандарт обеспечивает решение следующих практических вопросов:

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

b)    Каким образом данная ОС определяет достижимость других ОС в гой же подсети 1когда прямой анализ адреса пункта доступа к услугам сетевою уровня (ПДУС) не дает информации об адресе получателя подсети |?

c)    Каким образом логический объект разрешения адресов подсети (ЛОРЛП) определяет достижимость ОС через тс подсети, с которыми он непосредственно соединен4

Стандарт исходит из предположения, что:

a)    маршрризапия по определенному адресу пункта подключения подсети (Г1Г1П) в той же подсети удовлетворительно выполняется самой подсетью.

b)    подсеть неспособна маршрутизировать на глобальной основе с использованием только адреса ПДУС для обеспечения обмена данными с требуемым получателем;

c)    оконечные системы, использующие данный протокол, нуждаются в знании, по меньшей мерс, одного адреса 1111П. который может быть использован для доступа к ЛОРАП

Стандарт предназначен для:

a)    минимизации объема априорной информации о состоянии, необходимой оконечным системам до того, как они смогут начать обмен данными с другими ОС;

b)    минимизации объема памяти, необходимой для хранения маршрутной информации в ОС:

c)    минимизации вычислительной сложности алгоритмов маршрутизации оконечных систем.

IV

Страница 5

ГОСТ Р ИСО/МЭК 10030-96

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

a)    в общих нешироковешательных средах подмножество “конфигурация" протокола ГОСТ Р ИСО/МЭК 9542 неадекватно;

b)    в широковещательных средах функционирования протокола ГОСТ Р 34.950 подмножество "переадресация" протокола ГОСТ Р ИСО/МЭК 9542 становится недействительным.

По указанным причинам данный стандарт разработан для выполнения всех вышеупомянутых функций в соответствии с операциями по ГОСТ Р 34.950.

v

Страница 6

ГОСТ Р ИСО/МЭК 10030-96 ГОСУДАРСТВЕННЫ Й СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная 1гхма*яия

ПЕРЕДАЧА ДАННЫХ И ОБМЕН ИНФОРМАЦИЕЙ МЕЖДУ СИСТЕМАМИ ПРОТОКОЛ ОБМЕНА МАРШРУТНОЙ ИНФОРМАЦИЕЙ ОКОНЕЧНОЙ СИСТЕМЫ ДЛЯ ИСПОЛЬЗОВАНИЯ В СОЧЕТАНИИ С ГОСТ 34.954- 91

Information technology Tetccoiiiinunicjiioi* and information exchange between systems.

End System Rouicing Information Exchange Protocol for use in conjunction with ISO 8878

Дат* яяг.кния 1997—01—01

1 НАЗНАЧЕНИЕ

Настояший стандарт определяет протокол обмена маршрутной информацией между оконечной системой и логическим объектом разрешения адреса подсети.

Настоящий стандарт применим:

a)    к оконечным системам, работающим в соответствии с основной час|ью ГОСГ 34.954 для обеспечения и поддержки услуг сетевого уровня в режиме с установлением соединения при использовании ГОСТ Р 34.950;

b)    к логическим объектам разрешения адресов подсети, функционирующим в соответствии с ГОСТ Р 34.950.

Примечание - Определяемый и настоящем стандарте логический объект (кпрешений чдресов подсети может быть сея ин с функциями ретрансляции всоотвст ствии с ГОСТ Р ИСО/МЭК 10028 и ИСО/МЭК 10177

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

Настоящий стандарт не определяет каких-либо протокольных элементов или алгоритмов для обеспечения маршрутизации между объектами ЛОРАП. Такие функции сознательно выведены за рамки предмета рассмотрения настоящего стандарта

Ишшг официальное

I

Страница 7

IОСГР ИСО/МЭК 10030-96

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

8 настоящем стандарте использованы ссылки на следующие стандарты:

ГОСТ 28906-91 (ИСО 749R-84. ИСО 7498-84 Дон 1—84) Информационная технология. Взаимосвязь открытых систем. Базовая г/талонная молсль

ГОСТ 28907-91 (ИСО 8802—2—89) Системы обработки информации. Локальные вычислительные сети. Часть 2. Управление логическим звеном

ГОСТ 34.936-91 (ИСО 10039—91) Информационная технология Передача данных и обмен информацией между системами Определение услуг подуровня УДС локальных вычислительных сетей

ГОСТ 34 954—91 (ИСО 8878—87) Системы обработки информации Передача данных Использование протокола Х.25 для обеспечения услу| сетевого уровня в режиме с установлением соединения

ГОСТ I* 34.90—93 Информационная технология Передача данных н обмен информации между системами. Протокольные комбинации для обеспечения и иолдержки услуг сетевого уровня НОС

ГОСТ Р 34.950-92 (ИСО 8208—87) Системы обработки информации Передача данных. Протокол пакетного уровня Х.25 для оконечного оборудования данных

ГОСТ Р ИСО 8348/Доп. 2—93 Информационная технологии. Передача данных. Определение услуг сетевого уровня. Дополнение 2. Адресация на сетевом уровне

ГОСТ Р ИСО 864.4-95 Системы обработки информации. Взаимосвязь открытых систем. Внутренняя организация сетевого уровня

ГОСТ Р ИСО/МЭК 8881—95 Системы обработки информации. Передача данных Использование протокола пакетного уровня Х.25 в локальных вычислительных сетях

ГОСТ Р ИСО/МЭК 9542—93 Системы обработки информации. Передача данных и обмен информацией между системами. Протокол обмена маршрутной информацией между оконечной и промежуточной системами для использования совместно с протоколом, обеспечивающим услуги сетевого уровня н режиме без установления соединения

ГОСТ Р ИСО/МЭК 10028 - 95 Информационная технология. Передача данных и обмен информацией между системами. Определение ретрансляционных функций промежуточной системы на сетевом уровне

Страница 8

ГОСТ I* ИСО/МЭК 100Л0 —9Ь

ИСО/МЭК 8208—90/Изм 3—91* Информационная технология Передача данных. П|к>токол пакетного уровни Х.25 для оконечного оборудования данных. Изменение 3 Требования к соответствию

ИСО/МЭК ТО 9575—89* Информационная технология Передача данных и обмен информацией между системами. Основы маршрути зации В ОС

ИСО/МЭК ТО 9577—93* Информационная технология Передача данных и обмен информацией между системами. Идентификация протоколов сетевого уровни ВОС

ИСО/МЭК 10177—93* Информационная технология. Передача данных и обмен информацией между системами. Обеспечение про межуточной системой внутренних услуг сстепого уровня в режиме с установлением соединения с использованием протокола пакетного уровня X 25 по ИСО/МЭК 8208

ИСО/МЭК ТО I017H—92* Информационная технология. Переда* ча данных и обмен информацией между системами. Структура и кодирование адресов пунктов доступа к услугам уровня звена данных (ПДУЗ) в локальных вычислительных сетях

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

3.1    Определения и т эталонной модели

В настоящем стандарте используются следующие понятия, определенные в ГОСТ 2890о:

a)    сетевой уровень:

b)    пункт доступа к услучам сетевого уровня;

c)    адрес пункта доступа к услугам сетевого уровня:

d)    логический объект сетевого уровня;

с) маршругиззиия;

I) протокол сетевого уровня;

g> ретрансляция на сетевом уровне;

h) протокольный блок данных сетевого уровня

3.2    Определения, относящиеся к архитектуре сетевого уровня

В настоящем стандарте используются следующие понятия, определенные в ГОСТ Р ИСО 8648-

a)    подсеть;

b)    оконечная система;

c)    промежуточная система;

d)    услуга подсети;

с) протокол доступа к подсети.

•До прямого применения данного документ.» в качестве государственного стандарта его распространение осуществляет секретариат ТК 22 "Информационная технология"

3

Страница 9

ГОСТ Р ИГО/МЭК 10030—96

3.3    Определения, относящиеся к адресации на сетевом уровне

В настоящем стандарте используются следующие понятия, определенные в ГОСТ Р И СО 8348/Доп. 2:

a)    заголовки логических объектов сетевого уровня;

b)    адрес подсети;

c)    пункт подключения подсети.

3.4    Определения, принятые в локальных вы-чи с л и Iельных сетях

В настоящем стандарте используются следующие понятия, определенные в ГОСТ 28907:

a)    групповой адрес:

b)    глобальный адрес.

3.5. Дополнительные определе н и я

Для настоящего стандарта применимы следующие определения:

3    5.1 Информация о конфигурации - информация о совокупности оконечных систем и промежуточных систем, подсоединенных к подсети и определенных с точки зрения типов систем, наличия сетевых адресов, наличия заголовков логических объектов сетевого уровня и соответствия между системами, адресов ПГ1П и возможных маршрутов.

3.5.2    Информация о переадресации — информация, предоставляемая в том случае, когда пакету "запрос вызова" не удается установить соединение сетевою уровня (ССУ). и указывающая тот ППП, который мог быть использован для установления такого соединения.

3.5.3    Логический объект разрешения алрссов подсети — поставщик информации о маршрутах в пределах одной подсети

4    СОКРАЩЕНИЯ

4.1 Системы

ЛОРАП — Логический объект разрешения адресов подсети

ОС    — Оконечная система

ООД    — Оконечное оборудование данных

4 2 Протокольные блоки данных

Г1БД    —    Протокольный    блок    данных

ПБД ЗВЛ — Протокольный блок данных "заявка ЛОРАП"

ПБД ЗОС Протокольный блок данных "заявка ОС”

ПБД ЗЗЛ — Протокольный блок данных "заявка запроса ЛОРАП"

ПБД ЗКЛ — Протокольный блок данных "завершение конфигурации ЛОРАП"

4

Страница 10

ГОСТ I* ИСО/МЭК 10030 -96

ПБД ЗКОС — Протокольный блок данных "запрос о конфигурации оконечной системы"

ПБД ЗУЛ — Протокольный блок данных "завершение у ведом ления ЛОРАП"

ПБД ЗУОС — Протокольный блок данных "завершение уведомления ОС'

ПБД ОК.П — Протокольный блок данных 'ответ на конфигурацию ЛОРАП"

ПБД Г10С — Протокольный блок данных "переадресация ОС" ПБД ПУЛ — Протокольный блок данных "принятое уведомление ЛОРАП"

ПБД СОС — Протокольный блок данных ’соединение ОС"

4.3 Разное

АСУ    — Адрес на сетевом уровне

ДДК    — Двоично-десятичный кол

ИИП    — Идентификатор исходного протокола

КУ    — Качество услуг

ПБДС    — Протокольный блок данных    сетевого уровня

ПДУЗ    — Пункт досту па к услугам звена данных

ППП    — Пункт подключения подсети

ССУ    — Соединение сетевого уровня

УЛЗ    — Управление логическим звеном

УДС    — Управление доступом к среде

УСУ УС — Услуги сетевого уровня в режиме с установлением соединения

5 ОБЩЕЕ ОПИСАНИЕ ПРОТОКОЛА

Протокол, определяемый в настоящем стандарте, состоит из двух подмножеств:

a)    информация о конфигурации,

b)    информация о переадресации.

К функциям подмножества "информация о конфигурации" относятся:

a)    обеспечение возможности оконечным системам уведомлять ЛОРАП о существовании и достижимости адресов на сетевом уровне (АСУ);

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

Функция подмножества "информация переадресации" должна позволять тем ОС, которые пытаются установить соединение, направ-

5

Страница 11

ГОСТ Р ИСО/МЭК 10030-96

лять данные по конкретному соответствующему аарссу ППП. через который должно маршрутизироваться соединение.

Оба подмножества взаимно дополняют друг друга в том смысле, что информация, получаемая из подмножества "информация о поре-адресации' содержит в неявном виде соответствующую информацию о конфигурации, а информация, получаемая из подмножества ’информация о конфигурации" может быть использована для образования подходящего адреса ППП и, тем самым, исключения необходимости использования подмножества ’информация о переадресации" Выбор конкретного подмножества, которое должно использоваться для получения информации о маршрутизации в конкретных сеансах обмена данными, является локальным решением ОС. которое может быть различным в разных сеансах обмена данными и может свободно изменяться в процессе работы ОС, не влияя на возможности взаимодействия.

5.1 Функция Л О РА П

Обьект ЛОРАП является таким логическим объектом, который накапливает информацию о конфигурации из оконечных систем и распределяет среди них информацию о конфигурации и переадресации.

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

Функция ЛОРАП может быть выполнена одной или несколькими ОС или ПС, подключенными к подсети. Если подсеть такова, что она сама действует в соответствии с протоколом Х.25. то возможно, что некоторые из операций или все операции ЛОРАП могут быть выполнены функциями самой подсети

Для того, чтобы ОС использовала данный протокол, необходимо знать, по меньшей мере, адрес одного ППП, который может быть использован для доступа к ЛОРАП. В общем случае этот адрес заранее закладывается в ОС. В приложении А описана методика, которая может быть использована в некоторых ситуациях для исключении необходимости такого предварительного запоминания адреса.

5.2. Общее описание подмножества “информации о конфигурации”

Протокольные обмены, которые образуют подмножество "информация о конфигурации", начинаются с того, что ОС устанавливает соединение Х.25 с ЛОРАП путем выдачи пакета "запрос вызова" протокола Х.25. Первый октет.данных пользователя пакета содержит идентификатор протокола, указывающий протокол, определяемый

Страница 12

ГОСТ Р ИСО/МЭК ЮОЗО - 96

настоящим стандартом. Если ЛОРАП принимает ны «он. ОС может затем передать ЛОРЛП подробные сведения о его адресах на сетевом уровне. Как только информация о всех его адресах на сетевом уровне будет передана, ОС неявно сообщает ЛОРАП, что это уведомление выполнено и. таким образом, ЛОРАП может гарантировать, что вся полученная информация защищена в той степени, которая необходима для сс использования ОС может также запросить информацию об удаленных адресах на сетевом уровне. Для каждого запрошенного адреса на сетевом уровне ЛОРАП обеспечивает подробные сведения об одном или нескольких ПГ1II подсети, через который (ые) может быть достигнут адресат(ы) на сетевом уровне и обеспечено соответствующее возможное качество услуг. Получив информацию об одном адресе на сетевом уровне. ОС может запросить информацию о других адресах. При получении всей необходимой информации ОС завершает данное соединение

5.3 Общее описание подмножества ‘информация о переадресации"

Функции информации о переадресации могут бить подразделены на дне части.

Первая часть имеет место, когда ОС готова установить соединение на сетевом уровне в соответствии с ГОСТ 34.954, но не имеет информации, необходимой для определения соответствующего адреса подсети, по которому должен быть передан запрос вызова. Действия ОС в этом случае состоят в том, чтобы просто использовать адрес ЛОРАП. Пакет "запрос вызова" формируется в точном соответствии с ГОСТ 34.954 и перелается ЛОРАП.

В дальнейшем ОС продолжает управлять соединением в соответствии с ГОСТ 34 954 В случае, когда ЛОРАП представляет собой ОС или Г1С, подсоединенную к подсети, и не является набором функций, встроенных в саму подсеть, он не может:

—    использовать услугу “отражение вызова" X 25. чтобы перенаправить вызов в соответствующую ОС или ПС;

—    завершить соединение, обеспечив информацию о соответствующем ППП, который может быть исполыован в последующих попытках;

—    если содержит функцию ретрансляции, то может воспринять вызов и принять участие в ор1анизации соединения в качестве ретранслятора.

Если функция ЛОРАП встроена в саму подсеть, то дополнительно к вышеизложенному она может доставить вызов соответствующему ЛОРАП другими способами, которые не входят в предмет рассмот-

7

Страница 13

ГОСТ Р ИСО/МЭК 10030—96

рении настоящего стандарта (например, путем привлечения услуги Х.25 'переадрссаиия вызова").

Следовательно, поскольку установление соединения может в данном случае осуществляться удовлетворительно без тою, чтобы инициирующая ОС выполняла какие-либо дополнительные операции маршрутизации, ОС продолжает обрабатывать ССУ в соответствии с ГОСТ 34.954 до тех пор, пока не будет получена индикация завершения.

Получение индикации завершения в ответ на запрос вызова приводит к выполнению второй части процедуры информации о переадресации. В этот момент, если коды причины и диагностики d пакете индикации завершения показывают, что разъединение не было инициировано пользователем услуг сетевого уровня, ОС проверяет, имеются ли в пакете данные пользователя, содержащие информацию, закодированную в соответствии с настоящим стандартом, и указывающие соответствующий адрес подсети, через который могло быть установлено ССУ, эквивалентное отклоненному. Эквивалентное ССУ — это соединение между одинаковыми ПДУС с одинаковыми параметрами качества услуг. ОС может использовать эту информацию либо для повторной попытки установления соединения в соответствии с возможностями ГОСТ 34.954, либо при установлении последующих эквивалентных ССУ.

6 СООТВЕТСТВИЕ

6.1    Требования к статическому соответствию

Тс ОС. соответствие которых заявлено настоящему стандарту,

должны реализовывать одну или несколько следующих функций:

a)    подмножество "информации о конфигурации" ОС, определенное в разделе 8;

b)    подмножество "информации о переадресации* ОС, определенное в разделе 9

ЛОРАП, соответствие которого заявлено настоящему стандарту, должен реализовывать те процедуры раздела 11, которые предписаны в виде требований.

Примечание — Следовательно, ЛОРАП должен обрабатывать как информацию о хонфюурании, г.»к и информацию о переадресации

6.2    Требо в а н и я к динамическому соответствию

Система, соответствие которой заявлено настоящему стандарту,

должна проявлять внешнее поведение, соответствующее реализованному

а) для каждой обеспечиваемой функции соответствующие процедуры и кодирование любых передаваемых протокольных блоков

X

Страница 14

ГОСТ Р ИСО/МЭК 10030—96

данных, как определено в соответствующих пол разделах |>азлелов 8. 9. 10. II и 12;

Ь) протокол пакетного уровня Х.25 в соответствии с требованиями ИСО/МЭК 8208/И эм. 3 и с процедурами, привлекаемыми протоколами ГОСТ Р 34.90 для соответствующей конфигурации

7    АДРЕС ПОДСЕТИ ЛОРАГ1

Использование данного протокола требует, чтобы ОС знала, по меньшей мерс, один адрес подсети, но которому может быть достигнут ЛОРАП. Для определения такого адреса могут быть предусмотрены локальные методы: при наличии альтернативных методов, описанных в приложении А. они могут быть также использованы.

В случае, когда ОС знает несколько (1 ПП. через которые может быть достигнут ЛОРАП, выбор конкретного ППП является локальным вопросом.

8    ПОДМНОЖЕСТВО ИНФОРМАЦИЯ О КОНФИГУРАЦИИ" ОС

8.1    Параметры протокола

В данном разделе определены параметры, используемые в рассматриваемом протоколе, и в необходимых случаях определены значения утих параметров, которые должны быть обеспечены всеми соответствующими ОС Способность обеспечивать значения, отличные от специально требуемых, и средства, определяющие необходимость использования таких значений в любом конкретном случае, являются локальными вопросами.

8.1.1    Время ответа

Это временной предел, используемый ОС во время функционирования протокола.

Любая реализация подмножества "информация о конфигурации" должна быть способна обеспечить значение времени ответа, равное (180+30) с.

8.1.2    Время повторного уведомления

Это тот интервал времени, в течение которого ОС должна повторить неудачную попытку уведомить ЛОРАП о своей конфигурации.

Любая реализация подмножества “информация о конфигурации'' должна быть способна обеспечить значение времени повторного уведомления, равное 900 с с точностью ±120 с, если она обеспечивает любое из значений параметра "трсбустся уведомление", отличное от значения, указывающего, что уведомление никогда не потребуется, и значения, указывающего, что никакого специального значения не предложено.

9

Страница 15

IXX.T P ИСО/МЭК 10030 96

Примечание — К реализации. которая не обеспечивает таких значений параметра "требуется уведомление", никаких требований по обеспечению времени повторного уведомления не предъявляется

К.1.3 Требуется уведомление

Этот параметр определяет условия, при которых ОС должна пытаться уведомить ЛОРАП о своей конфигурации

Любая реализация подмножества информации о конфшурацни должна быть способна обеспечить такое значение этого параметра, которое указывает, что уведомление никогда не потребуется.

Примечание — Примерами других значений параметра "требуется уведомление-'. которые могут быть факультативно обеспечены, служат:

—    значение. укатывающее, что уведомление требуется каждый раз. когда ОС итшиируегси и тем ко истечении времени, определенном ЛОРАП в конце каждого предыдущею уведомления.

-    значение, указывакнисс. что уведомление требуется при каждом подсоединении <Х' к другой подсети

Обратим внимание, что эти значения яяднюкя только примерами Допускаются и другие значения.

8.2 Операции протокола

В данном разделе определен протокол, который использует процедуры пакетного уровня Х.25, определенные в ГОСТ Р 34.950. Осуществляемый в зависимости от возможностей ГОСТ Р 34.950 выбор значений для полей X 25. которые не определены в данном разделе, является локальным вопросом.

8.2.1 Установление соединения

ОС должна пытаться установить соединение всякий раз при наличии любого из следующих условий:

a)    требуется получить информацию о конфигурации от ЛОРАП,

b)    условия, определенные в 8.1.3, вызывают необходимость сообщить ЛОРАП информацию о конфигурации, при условии, что используемый ППП ОС не имеет уже установленного или устанавливаемого соединении с ЛОРАП для его использования при передаче информации о конфигурации.

ОС не должна пытаться устанавливать в любой конкретный момент времени несколько соединений с ЛОРАП из любого одного ПИП ОС.

ОС может попытаться установить соединение с ЛОРАП, инициировав виртуальное соединение в соответствии с процедурами установления виртуального соединения, определенными в ГОСТ Р 34 950. Алрее ПГ1П, по которому должен быть передан запрос вызова, должен быть применим к этому ППП, как описано в разделе 7. Должна быть определена услуга ‘быстрая выборка", указывающая отсутствие ограничений на выдачу ответа. Данные пользователя, |п

Страница 16

ГОСТ Р ИСО/МЭК 10030- %

которые должны быть переданы в пакете "запрос вызова ", должны содержать ПГ>Д ('ОС.

Если процедура установления виртуального соединении выполнена успешно. ОС должна проанализировать данные пользователя, поступившие и пакете “соединение установлено''

Если эти данные содержат действительный ПБД ЗУП, ОС должна продолжать передачу данных, как определено в 8.2.3. В противном случае ОС должна завершить соединение согласно процедурам завершении виртуальных соединении, определенных в ГОСТ Р 34.950, используя код причины 0 и кол диагностики 242, после чего действовать в соответствии с процедурой безуспешного установления соединения, описанной в 8.2.2.

Ec;jji процедура установления виртуального соединения оказалась безуспешной, ОС может повторить ее при условии, чго безуспешность была обусловлена причиной, которая, если она имела место при попытке установить ССУ, может быть интерпретирована в соответствии с ГОСТ 34.954 как "отклонение соединения — неустойчивое состояние". Однако повторные попытки не должны продолжаться дольше указанного значения параметра 'время ответа" Закончив повторные попытки, ОС должна действовать в соответствии с 8.2.2.

8.2.2    Процедура безуспешного установления соединения

Если попытка установления соединения оказалась безуспешной и если ОС знает любой альтернативный адрес подсети ЛОРАН, она должна попытаться установить соединение по тому адресу, по которому она euic не пыталась его устанавливать.

Если все известные адреса ЛОРАП были опробованы безуспешно.

то:

a)    если в соответствии с положениями 8.1.3 ОС должна была уведомить ЛОРАП о своей конфигурации, то эта попытка уведомления должна рассматриваться безуспешной. Другая попытка может быть осуществлена по истечении времени повторного уведомления;

b)    если ОС требуется информация о конфигурации от ЛОРАП. то время, в течение которого осуществляются последующие попытки (если они выполняются) или выполняются другие вилы действий (например, возврат к конфигурации по умолчанию или использованию подмножества "переадресация" в качестве основы для маршрутизации), определяется локально.

8.2.3    Процедура передачи данных

В данном разделе определяется передача данных после установления приемлемого соединения с ЛОРАП.

и

Страница 17

ГОСТ Р ИГО/МЭК 10030-96

В данном разделе требуется передача нескольких ПБД. Каждый II БД должен передаваться в виде отдельной последовательности битов М бел установленного бита О в соответствии с процедурами передачи данных, определенными в ГОСТ Р 34.950.

В данном разделе гребуется также, чтобы в некоторых ситуациях соединение было отклонено до завершения передачи данных. Это должно выполняться путем завершения соединения к соогнстствии с процедурами завершения виртуального соединения, определенными в ГОСТ Р 34 950. с использованием кода причины 0 и кода диагностики 242.

В случае завершения виртуального соединения (либо самой ОС. отклоняющей соединение в соответствии с положениями настоящего стандарта, либо вследствие выполнения процедур ГОСТ Р 34.950) до нормального завершения процедуры передачи данных, определенной в данном разделе, ОС должна действовать согласно процедуре безуспешного установления, определенной в 8.2.4

В том случае, если в любой момент времени при выполнении процедуры передачи данных поступает пакет "индикация повторной установки", "прерывание** или данные бита Q, ОС должна отказаться от соединения.

Процедура передачи данных состоит из двух частей: уведомление о конфшурапии и сбор информации о конфигурации Если приемлема процедура уведомления о конфигурации, она должна быть выполнена сразу после завершения установления соединения. Если приемлема процедура сбора информации о конфигурации, она должна быть выполнена после завершения процедуры уведомления о конфжурации (либо сразу, если процедура уведомления о конфигурации неприемлема). После завершения всех приемлемых частей процедуры ОС должна действовать согласно процедуре нормального шнершенин в соответствии с 8.3.

8.2.3.1 Уведомление о конфигурации

Процедура уведомления о конфигурации является факультативной и в случае ее реализации ее действия контролируются путем установки параметра “требуется уведомление".

»ia процедура применима только при наличии следующих условий:

a)    параметр "требуется уведомление" установлен в значение, которое указывает, что н данный момент ОС должна уведомить ЛОРАН о своей конфигурации;

b)    попытка уведомить о конфигурации не была безуспешной в течение времени, определяемого параметром “время повторного уведомления"

12

Страница 18

IUC1 I' ИСО/МЭК I00.)0-V6

ОС должна инициировать процедуру передачи одного ПБД ЗОС по каждому сетевому адресу, доступному через свой ЛОРАП После передачи ПОЯ ЗОС она должна передать ПБД ЗУОС. Затем она должна ожидать поступления ПБД ОКЛ Если полученный ПБД ЗЗЛ содержит параметр "требуется уведомление". ОС должна извлечь его и использовать его значение н качестве следующего интервала времени до уведомления ЛОРАП При приеме ПБД ПУЛ процедура уведомления о конфигурации успешно заканчивается.

Примечание I - После такого успешного свершения пдокиис параметра "требустся уведомление* он реле л ист. при каких условиях и когда па процедура может быть с поил испольнтама

Если после передачи первою блока ПБД ЗОС блок ПБД ЗЗЛ не был получен в течение времени, равного параметру "время ответа", соединение должно быть прервано.

Прим с ч а н и о 2 - Истечение «ото вымени может произойти в ре |ультате либо ^лержек при передаче ПБД (наиромер. nj-ia управления потоком), либо илержки I» выдаче отпета ЛОРАП.

Если ОС получила какие-либо данные до передачи ПБД ЗУОС или она получила данные, которые не содержат действительных ПБД ЗЗЛ. соединение должно быть прервано.

8.2 3 2 Сбор информации о конфигурации

Процедура сбора информации о конфигурации является факультативной и в случае ее реализации она применима всякий раз, когда ОС нуждается в информации от ЛОРАП относительно ППП тех систем, которые могут быть использованы для достижения удаленных адресов сетевою уровня. Настоящий стандарт не налагает никаких ограничений на частоту попыток ОС собрать информацию о конфигурации.

ОС должна передать ПБД ЗКОС, определяющий адрес сетевою уровня, но которому она запрашивает информацию. В отве! она может получить несколько ПБД ОКЛ, содержащих информацию о тех ППП. через которые может быть достигнут конкретный адрес сетевого уровня. ПБД ОКЛ может содержать параметры "маска адреса" и “маска ППП“. Эти параметры могут быть использованы в соответствии с положениями 8.1.4 и 8.1.5 соответственно.

Получение ПБД ЗКЛ указывает, что информация полная; если ни один из ПБД ОКЛ не поступил до получения ПБД ЗКЛ, это указывает, что по данному конкретному адресу на сетевом уровне никакой информации нет. Если ОС запрашивает информацию о последующих адресах на сетевом уровне, она может затем повторить этот процесс при условии, что поле "предельное число запросов" в ПБД ЗКЛ

и

Страница 19

ГОСТ Г ИСО/МЭК 10030-96

определяет допустимость другого запроса. Если это поле определяет, что последующие запросы не разрешены, ОС не лолжна передавать больше никаких ПБД ЗКОС. Если ОС имеет информацию для всех ;шрссов на сетевом уровне, коюрые она запрашивает, либо если поле "предельное число запросов" не разрешает последующих запросов, то функция сбора информации о конфигурации успешно завершается.

Если после передачи ПВД ЗКОС и до получения соответствующего ПБД ЗКЛ прошло времени больше, чем значение параметра “время ответа", соединение должно быть прервано.

Следующие события также должны вы >ывать отказ от соединения:

a)    получение любых данных, которые не содержат действительных ПГ>Д ОКЛ или ПБД 3KJ1,

b)    получение любою ПБД до передачи первого ПБД ЗКОС или между получением ПБД ЗКЛ и передачей следующего ПВД ЗКОС;

c)    получение ПБД. относящегося к адресу на сетевом уровне, отличному от того, по которому (К.' передала ПБД ЗКОС поданному соединению и не получила П БД ЗКЛ.

S.2.4 Процедура прерывания соединения

Соединение прекращает действовать:

a)    если применима процедура уведомления о конфшурации, это должно рассматриваться как безуспешность попытки уведомления. (Следовательно, она должна быть снова предпринята по истечении времени, указанного параметром "время повторного уведомления");

b)    при получении неполной информации о конфигурации в ПБД ОКЛ, для которою не был получен соответствующий ПБД ЗКЛ.

Примечание - Вопрос о том. лолжна ли ОС ислольюпать неполные данные или аннулирован, их. «мнется локальным Будет ли предпринята попытка получить остимиисгя неполные данные, либо продолжите» ипрос информации по другим адресам сетевого уропни - также является локальным вопросом

8.3 Нормальная процедура завершения

Если используемые процедуры передачи данных успешно закончены и если поле "предельное число запросов", содержащееся в ПБД ЗКЛ. указывает, что дальнейшие запросы больше не разрешаются, ОС должна заверцпиь соединение согласно процедуре завершения виртуального соединения, определенной в ГОСТ Р 34.950, используя код причины 0 и код диагностики 241. Если поле "предельное число запросов" разрешает другой запрос. ОС должна выполнить одну из следующих процедур:

a)    она может немедленно завершить соединение, используя код причины 0 и код диагностики 241;

b)    она может сохранить соединение на некоторое время и в

14

Страница 20

Г ОСТ Р ИСО/МЭК 19930 96

дальнейшем использовать его для последующих функций передачи данных и соответствии с 8.2.3. когда эти функции снова окажутся применимыми Максимальное время, в течение которого может сохраняться соединение при отсутствии дальнейшей передачи данных. равно половине значения параметра "время запроса", полученного в ПБД ЗУЛ. Сразу, как только это время истечет. ОС должна освободить соединение с кодом причины 0 и колом диагностики 241 ОС не обязательно должна сохранять соединение в течение этого максимального периода времени Вместо этого она может по своему усмотрению завершить соединение в любое удобное время, также используя кол причины 0 и кол диагностики 241 В течение времени, когда соединение сохраняется, ОС должна продолжать работать но нему в соответствии с процедурами, определенными в ГОСТ Р 34.950. При получении пакета "данные", "сброс" или "прерывание'' ОС должна завершить соединение с колом причины 0 и кодом диагностики 242. В этом случае или в случае получения индикации завершения, либо если действия процедур ГОСТ P 34.950 привели к завершению соединения, необходимость и время следующей попытки установить другое соединение в соответствии с процедурами, определенными в Н.2.1, является локальным вопросом.

Выбор между процедурами по подпунктам а) и Ь), а также длительность времени, в течение которою сохраняются соединения в случае выбора варианта по подпункту Ь), является локальным вопросом и ОС может свободно менять их в соответствии с внутренними условиями, не влияя на взаимодействие.

8.4 Использование информации о конфигурации

Настоящий стандарт не налагает никаких ограничений на количество информации, собранной ОС, которая сохраняется или используется. ОС может в любое время аннулировать собранную информацию и снова выдать новый запрос на сбор информации, если эго потребуется в дальнейшем

ОС может в любое время использовать локальные сведения или любой другой способ определения ПГ1П. который должен использоваться при установлении любого ССУ по любому адресу на сетевом уровне независимо от того, собрана ли информация о конфигурации, которая может быть использована

Информация о конфигурации, получаемая данным протоколом, является действительной и зависит только от следующих ограничений:

а) информация о конфигурации, указывающая, какой адрес Г1Г1Г1

is

Страница 21

ГОСТ Р ИСО/МЭК 1003# <М>

использовать для устаноачсния соединения, является недействитсль-ной, если только она не была обеспечена в информации для соответствующего адреса на сетевом уровне и применима к диапазону КУ, который содержит минимально приемлемое КУ для запрошенного

ССУ;

b)    информация о конфигурации является недействительной, если время, прошедшее с момента ее получения, превышает время, определенное в поле "время удержания" ПБД ОКЛ, который его передал;

c)    информация о конфигурации, которая уже была собрана, становится действительной, как только ОС снова успешно соберет полную информацию о конфигурации по тому же адресу на сетевом уровне, независимо от того, истекло время удержания, определенное при сборе первоначальной информации, или нет.

'> ПОДМНОЖЕСТВО “ИНФОРМАЦИЯ О ПЕРЕАДРЕСАЦИИ" ОС

9.1    Использование переадресации

В данном разделе определяются процедуры, которые должны выполнять (X' при использовании подмножества "информация о переадресации” для выбора Г111П, которому должен быть передан запрос соединения Вопрос о том, использовать ли эту процедуру в любом конкретном сеансе взаимодействия или использовать ранее полученную информацию о переадресации или информацию о кон* фигурапии, либо какой-то другой метол, является локальным.

Для того, чтобы привлечь процедуру переадресации, ОС должна выполнить процедуру установлении ССУ. определенную в ГОСТ 34.954. но в качестве адреса Г1ПП, по которому послан вызов. ОС должна использовать адрес ЛОРЛП. как определено в разделе 7.

Примечания

1    Нанримср, «случае подсети коммутации монетой дярсс ООД ЛОРАП может Омть помешен в ноле “адрес иы«ываюикго" ллноио пакета В случае ЛВС' по ГОСТ 2Н907 (X может работать в соответствии с ГОСТ Р ИСО/МЭК HKKI. и адрес УЛ1 ЛОРАП может ислолыомтм и качестве адреса получателя при передаче кддра. содержащею пакет 'мпрос ни юна'

2    0 тех случаях, ко!Да в результате адрес п попе "адрес ни iu нас мот" пакета "мпрос ииии" ока швастся адресом ЛОРАП. из положения ГОСТ М 954 следует, что адрес имшнаемгао ПДУС кодируется к услуге "расширение алреса*. поскольку удаленная СХ' может мкадегы:» не в состоянии инекчь cm из ноци адреса

ОС должна продолжить работу с соединением в соответствии с ГОСТ 34.954.

9.2    Получение информации о переадресации

В данном разлеле описана процедура, которую следует выполнить

для получения информации о переадресации, н.

Страница 22

ГОСТ Р ИСО/МЭК IOO.10-96

9.2.1 Процедура информации о переадресации при индикации weep шения

ОС, которая реализует подмножество "информация о переадреса-ции, должна выполнять эту ироислуру всякий раз. когда попытка установить ССУ оказывается безуспешной по причине получения пакета "индикация завершения".

Примечание— •♦га процедура не офаничииасцм теми пытовамн. которые iirpiiotia'iaiiiaio 6ы1Ы переданы ЛОРАП и соотистспиш с 9 I -)го юккмо тем. что лаже и юн случае. котл-i адрес 11ПП пли данного пыюв> 6мл лыбраи другими cikk.hCi.imii. он может фактически оказаться 11П11 системы с функциями ЛОРдП. либо №ыюя может бмгъ mcixijqux-coiiuh ЛОРДП

Должны выть проанализированы колы причины и диагностики для определения соответствующих значении параметров "причина" н "инициатор" примитива пиликании разъединения услуг сетевого уровня в соответствии с критериями, определенными в ГОСТ 34

Гели значением параметра “инициатор" не является "поставщик УСУ", процедура считается выполненной, информации о переадресации отсутствует. ОС должна продолжить выполнение процедур. определенных в ГОСТ 34.954. для обработки пиликаний -завершения

Если значением параметра "инициатор* является "поставщик УСУ", должно быть проанали шровано иоле "данные пользователя-' пакета "индикация завершении".

Гели >то поле содержит ПБД ПОС и если задержка установления ССУ не превышена, то вызов должен быть повторен с использованием ППП в П БД ПОС. если только он не совпадает с ППП. который был использован при безуспешном вызове.

Гели пакет "индикация завершения" содержит ПБЛ ПОС, но превышена задержка установлении ССУ, информация из ПБД ПОС может быть сохранена для использования при установлении последующих соединений с тем же адресом на сетевом уровне и тем же КУ. если только ППГ1 не совпадает с тем, который был использован при безуспешном вызове, в случае чего эта информация должна быть аннулирована.

Если пакет "индикация завершения" не содержит ПБД ПОС. рекомендуется, чтобы в случае, если вызов первоначально был передан ЛОРАП в соответствии с 9.1. кол причины завершения был проанализирован с точки зрения категорий, определенных в рекомендации Х.96 МККТТ. Если это кол категории П. предпочтение должно быть отдано использованию другого адреса ППП для последующего доступа к ЛОРАП, если доступны другие адреса ППП ЛОРАП

|>

Страница 23

ГОСТ Р ИСО/МЭК 10030 -96

В случае, когда вызов. переданный ППГ1 ЛОРАП, не приведет к установлению соединения при неполучении информации о переадресации, рекомендуется учитывать любую информацию о других возможных адресах ППГ1 ЛОРАП. которые могут обеспечить информацию о переадресации при определении необходимости повторной попытки вызова в соответствии с ГОСТ 34.954.

ПБЛ ПОС может содержать параметры "маска адреса" и "маска IIПII" Эти параметры могут быть использованы так. как описано в 10.1 и 10.2 соответственно

9.2.2 Рекомендуемая обработка пакетов "соединение установлено" В случае, когда ОС. реализующая подмножество информации о пере адресации, получает пакет "соединение установлено", завершающий установление виртуального соединения, начатого передачей пакета "запрос вызова" в ППП ЛОРАП. рекомендуется, чтобы проверялось, указано ли в пакете "соединение установлено", что вызов был отражен (в соответствующих случаях) или переадресован. Если да. то ОС может зарегистрировать ППП. с которым, возможно, было установлено соединение, и может использовать эту информацию при установлении последующих соединений по тем же адресам сетевою уровня и тем же КУ, чтобы сохранить ссылку на данный ЛОРАП.

Однако ОС. реализующая эту рекомендацию, должна прекратить использование информации, полученной таким способом, если попытка ее использования привела к безуспешности установления соединения по причинам, отличным от причины отклонения соединении удаленным пользователем Примечания

1    ОС, которая реализует лу процедуру и использует зарегистрированный ППП для последующего соединения, нсоби итсльно должна использовать ее .тля всех подобных соелимсний. но может использовать се и некоторых, но не но мех сеансах мои молейстимя на осноис локальных решений

2    Поскольку не существует таймера, относящегося к получаемой таким способом информации, то возможно, что ОС может продолжить использование маршрута, копи он становится уже нсоптимальным. при условии, что он все сше достаточно хорош для обеспечения требуемого КУ ОС может использовать эту возможность не совсем опгимхтьмой маршрутизации в противовес продолжающегося отсутствия доступа к ЛОРАП ал* получения новейшей информации (и последующею сокращения времени установления соединения)

9.3 Использование информации о переадресации Настоящий стандарт не налагает никаких ограничений на то, какое количество информации о переадресации, полученной ОС, сохраняется или используется. ОС может в любой момент времени аннулировать полученную информацию и снова привлечь переадресацию для последующих соединений.

IX

Страница 24

ГОСТ Р ИСО/МЭК 10030— 96

ОС может в любой момент времени использовать локальные сведения или другой способ определения ПГ1Г1, который может быть использован при установлении любою ССУ независимо от того, получила она приемлемую информацию о переадресации или нет.

Полученная этим протоколом информация о переадресации действительна только с учетом следующих ограничений

a)    информация о псрсадресации, указывающая адрес того 11(111. который должен использоваться для установления соединения, недействительна, если только она не была обеспечена и информации для соответствующею адреса сетевого уровня и не применима к диапазону КУ. который охватывает минимально приемлемое КУ для требуемого ССУ:

b)    информация о переадресации недействительна, если время, прошедшее с момента се получения, больше, чем определено в поле "время удержания" того II БД I10C. который передал се;

c)    элемент информации о переадресации становится недействительным. если попытка установления соединения, использующая этот элемент, оказалась безуспешной по причинам, отличным от отказа удаленного пользователя.

10 МАСКИ АДРЕСА И IIIIII

В данном разделе описывается метод передачи дополнительной информации в ПБД ОКЛ и Г1БД ПОС. Эта информация передается посредством полей ПБД 'маска адреса" и "маска ППП". значимость которых описывается ниже.

ЛОРАП может факультативно ввести в любой ПБД ОКЛ или ПБД ПОС либо только поле "маска адреса", либо и поле "маска адреса" и поле "маска ППП". При получении одного из таких блоков ПБД, содержащих любое из этих полей. ОС должна либо проигнорировать оба этих поля, либо обработать их. как описано в следующих подразделах.

10.1 Маска адреса

Параметр "маска адреса" указывает, что информация продвижении применима к большему числу АСУ по сравнению с исходным адресуемым АСУ, относящимся к полученному ПБД ОКЛ или ПБД ПОС Оконечная система может по своему усмотрению проигнорировать этот параметр

Маска адреса устанавливает эквивалентный класс АСУ, с которым применима одна и та же информация продвижения. Для того, чтобы определить, попадает потенциальный адресуемый АСУ в эквивалентный класс или нет, инициирующая система уравнивает потенциальный адресуемый АСУ с маской адреса, заполняя последний при необходимости концевыми нулевыми октетами (двоичные 0000 0000). Если во всех битовых позициях, где маска адреса равна “Г,

IV

Страница 25

ГОСТ Р ИСО/МЭК 11)030- 96

конисвой АСУ совпадает с АСУ. относящимся к ПБЛ ОКЛ или ПВД ПОС. то этот конисвой адрссусмый АСУ относится к эквивалентному классу, описываемому в ПБЛ ОКЛ или ПБЛ ПОС При принятии решений о маршрутизации точное совпадение АСУ более предпочтительно по сравнению с использованием эквивалентных классов. Точное совпадение имеет место, когда исслелуемый АСУ идентичен одному из АСУ, относящемуся к ПБЛ ОКЛ или ПБЛ ПОС без учета каких-либо масок. Если адресуемый АСУ находится в пределах нескольких эквивалентных классов, то вопрос, какой in них использовать. если такой выбор имеется, является локальным

Все нулевые маски адреса мо|ут использоваться с целью указания всеобщей ПС для таких исходящих вызовов, для которых маршрутизация и другом виде неизвестна

Примечание — Сели часка адреса пыбрана в соотнстстаии с транииамп в иерархически администрируемом адресе се тс но* о уровня, оно допускает маршрут ю-Пию со стороны подсети, маршрутизацию со стороны региона или по другим административно украшаемым критериям

Параметр "маска адреса имеет дополнительную семантику при ее рассмотрении в сочетании с параметром "маска ПИН" (см 8.1.5).

10.2 Маска ППП

При наличии маски ППП эквивалентный класс, определяемый маской адреса, также имеет общую структуру ниже маски адреса, то есть в той части адреса сетевою уровня, где маска адреса логически равна 0 Маска ППП обеспечивает дополнительную информацию о структуре, указывая определенные битовые позиции в пространстве "ниже" маски адреса. В частности маска ППП указывает положение ППП в адресе сетевою уровня.

Система, которая принимает ПБЛ ОКЛ или ПБЛ ПОС, содержащие маски адреса и/или маски ППП. может предпочесть игнорирование обеих масок. Поскольку наличие обеих масок диктует другое поведение, чем в случае наличии только одной маски, ОС не должна иг норировать одну из этих масок, когда необходима другая. Гели ОС получает один из таких ПБЛ, который содержит маску ППП. но не содержит маску адреса, она должна либо проигнорировать маску ППП, либо считать ПБЛ недействительным.

п процедуры лорап

Процедуры, которые должен выполнять ЛОРАП при выполнении своих функций, объединенных с функциями подсети X 25, не входят в предмет рассмотрения настоящего стандарта. В данном разделе описываются те процедуры, которые должна выполнять система, соединенная с подсетью для выполнения функций ЛОРАП.

20

Страница 26

ГОСТ Р ИСО/МЭК 10030-96

При получении пакета "входящий вызов" ЛОРАП. если он имеет в данный момент ресурсы для приема вызова, должен проанализировать первым октет поля "данные пользователя” и действовать затем следующим образом:

a)    Если данные пользователя отсутствуют, или если первый октет имеет значение в диапазоне 0000 00Ю - ООП 1111, ЛОРАП должен действовать в соответствии с требованиями 11-2.

b)    Если первый октет данных пользователя имеет значение, определенное в 12.1.1, ЛОРАП должен действовать в соответствии с требованиями 11.1,

c)    В любом другом случае действия, выполняемые ЛОРАП. не входят в предмет рассмотрения настоящего стандарта.

П.1 Обработка подмножества “информация о конфигураии и"

11.1.1    / 1араметры протокола

R данном разделе определяются параметры, используемые в протоколе, и в применимых случаях устанавливаются требования к значениям параметров, которые должны быть обеспечены всеми системами, претендующими на соответствие. Возможность обеспечивать значения, отличные о тех, которые специально заданы, и способы, определяющие использование таких значений и любом . конкретном случае, являются частными вопросами.

11.1.1.1    Время запроса

Этот параметр указывает время, н течение которого ЛОРАП должен ожидать запросов от ОС. с которой у него установлено соединение, либо может указывать на неограниченное время ожидания.

Любая реализация ЛОРАП должна обеспечивать время запроса 60 с с точностью ±10 с.

II.1.2 Процедура информации о конфигурации

Если поле "данные пользователя" пакета "входящий вызов" не \ содержит действительного ПБД СОС. ЛОРАП должна завершить соединение в соответствии с процедурами завершения виртуальною 1 соединения, определенными в ГОСТ Р 34.9S0, с колом причины 0 и кодом диагностики 248.

Если вызов не содержит услуги "быстрая выборка без ограничс- i ний", ЛОРАП должен завершить соединение с кодом причины 0 и кодом диагностики 76

Если ЛОРАП временно неспособен обработать информацию о конфжураиии. он должен завершить соединение с кодом причины 0 и кодом диагност к и 244

21

Страница 27

ГОСТ Р ИСО/МЭК I00M-96

Если ЛОРЛП нс желает обеспечивать услуги вызывающей ОС. он лолжен завершить соединение с колом причины 0 и кодом диагностики 245.

В противном случае ЛОРАГ1 лолжен принять вызов в соответствии с процедурами установления соединения, определенными в ГОСТ Р

34.950,    передав IIЬД ЗУЛ в поле "данные пользователя" пакета 'соединение установлено”. Поле "время запроса" Г1БД ЗУЛ должно указывать наибольшее значение, которое допускается колом поля, определенным в 12.1.11. и которое не превышает предела минимальною времени, при его наличии, в течение которого ЛОРАП может ожидать запроса от той ОС. с которой у него установлено соединение.

Примечание I — Минимальный предел времени, в течение которою ЛОРЛП может ожидать опросов. определяется итачением параметра время ипрося", обсспе-чинаи допуски такой точности, с которой реалиюлан лот параметр

ЛОРЛП должен работать с виртуальным соединением в соответствии с процедурами передачи данных, определенными в ГОСТ Р

34.950.    Если он получает индикацию сброса, пакет данных с установленным битом 0. пакет прерывания или данные, которые не соответствуют форматам 11БД, определенным в разделе 12, он должен ывершить соединение с кодом причины 0 и колом диагностики 242.

Если время, превышающее значение параметра "время запроса", истекло ло получения Г1 БД ЗОС или ПБД ЗКОС, ЛОРАП должен завершить соединение с колом причины 0 и кодом диагностики 242.

При получении ПБД ЗОС ЛОРАП лолжен записывать содержащуюся в них информацию.

Примечании

1    Испольммшшс гтой информации ЛОРЛП нс ачодит в предмет рассмотрения настоящего стандарта

2    Определение маршрутов на основе информации, полученной через функцию уведомления о конфигурации, может в некоторых случаях внести риск пщишсмиостм информации Можно уменьшить такой риск административным или локальным решением, используя погможности проюкола ГОСТ Р М 950. который обеспечивает некоторую степень иденгификлиин. как например, юкрытис группы по.пыоизтелей

Если после получения ПБД ЗВОС ЛОРАП получает ПБД ЗКОС ло получения ПБД ЗУОС, он должен завершить соединение с колом причины 0 и кодом диагностики 243. Он может, но не обязательно, поступать так. котла он принимает несколько ПБД ЗВОС, определяющих один и тот же адрес на сетевом уровне.

Если после получения ПБД ЗВОС. но ло получения ПБД ЗУОС или другого ПБД ЗВОС прошло больше времени, чем определено параметром "время запроса", ЛОРАП должен завершить соединение с колом причины 0 и кодом диагностики 242.

22

Страница 28

ГОСТ Р ИСО/М Ж 10030-96

При получении ПБД ЗУОС ЛОРЛП должен предусмотреть, чтобы информация. полученная из ПБЛ ЗВОС. была закрыта ло такой степени, которая необходима для ее использования. и татем передать ПГ>Д ЗЗЛ в 11|юстой последовательности бита М в соответствии с процедурами, определенными в ГОСТ Р 34.950. Параметр "требуется уведомление'4 ПБД ЗЗЛ должен быть установлен в значение, укатывающее время, в течение которого предполагается, что ОС должна ожидать при отсутствии изменения конфигурации или доступности перед выполнением последующего уведомления Если после згою ЛОРАП получает другой ПБД ЗВОС. он должен завершить соединение. используя кол причины 0 и код диагностики 243.

Если после получения ПБД ЗЗЛ и при отсутствии ПБД ЗКОС прошло время, превышающее время запроса, ЛОРАП должен завершить соединение с кодом причины 0 и кодом диагностики 242.

При получении ПБД ЗКОС и при наличии у ЛОРАП информанин о пунктах ППП подсети, которая может быть использована ОС для достижения определен ною адреса На сетевом уровне. ЛОРАП должен передать ПБД ОКЛ для каждого такого ППП. Если ЛОРАП уже передал ПБД ОКЛ для каждого соответствующего ППП (либо сразу же при отсутствии информанин о любом подходящем ППП). он должен передать ПБД ЗКЛ. Поле "предельное число запросов" ПБЛ ЗКЛ должно быть установлено ЛОРАП в значение, определяющее допустимость другого запроса

Если после передачи ПБД ЗКЛ идо получения jipyioi о ПБД ЗКОС прошло время, превышающее время запроса, ЛОРАП должен завершить соединение с колом причины 0 и кодом диагностики 242.

Гели ЛОРАП получил другой ПБД СОС или если он получил другой ПБД ЗКОС до передачи ЗКЛ, происходящей из предыдущей передачи, либо если он получил ПБД, отличные от указанных выше, он должен завершить соединение, используя кол причины 0 и кол диагностики 243.

Если ЛОРАП получил другой ПБД ЗКОС после передачи ПБД ЗКЛ с полем "предельное число запросов”, определяющим отсутствие последующих запросов, он должен завершить соединение с кодом причины 0 и кодом диагностики 242.

II.2 Обработка подмножества ” переадресация" ЛОРАП должен определять "адрес вызываемого" на сетевом уровне, идентифицируемый пакетом "запрос вызова", в соответствии с ГОСТ 34.954. Если это адрес на сетевом уровне, назначенный для самого ЛОРАП, то ЛОРАП должен управлять ССУ в соответствии с процедурами, определенными в ГОСТ 34.954.

2}

Страница 29

ГОСТ Р ИСО/МЭК 10030-96

Если адрес на сетевом уровне расположен и другой системе, к которой инициирующая ОС может обратиться через другой ППП той же подсети с приемлемым качеством услуг. ЛОРАП должен выполнить одно из следующих действий:

а» Если услуга 'отражение вызова" доступна для использования при данном вызове, ЛОРАП может использовать ее в соответствии с процедурами ГОСТ Р 34.950 для отражения вызова к соответствующему ППП.

Ь) Если услуга 'отражение вызова’ недоступна или если ЛОРАП решает не использовать ее, он должен завершить соединение в соответствии с процедурами завершения виртуального соединения. определенными в ГОСТ Р 34.950, используя кол причины 0 и код диагностики 230, н передать ПБД ПОС в поле "данные пользователя" пакета "запрос завершения". Однако, если пакет "запрос вызова"не имеет услуги “быстрая выборка", он должен завершить соединение без данных пользователя с кодом причины 0 и колом диагностики 76

Если ЛОРАП не имеет информации, указывающей ППП, через который может быть установлено требуемое ССУ, он должен завершить соединение без данных пользователя с кодом причины 0 и колом диагностики 232

12 СТРУКТУРА И КОДИРОВАНИЕ ПБД

12.1 Параметры

ПБД должен содержать, по меньшей мере, следующие параметры в указанной последовательности:

—    идентификатор протокола сетевою уровня;

—    номер версии;

—    тип ПБД

Все другие перечисленные параметры имеют место в некоторых ПБД, как указано в 12.2.

12 11 Идентификатор протокола сетевого уровня

Значение этого параметра должно быть равно 1000 ГОЮ.

Этот параметр идентифицирует протокол сетевого уровня, как указано в настоящем стандарте.

12.1.2    Номер версии

Значение этого параметра 000 0001. Оно определяет версию настоящею стандарта.

12.1.3    Тип ПБД

Параметр “тип П БД" определяет тип протокольного блока данных. Допустимые значения приведены в таблице I.

24

Страница 30

ГОСТ Р ИСО/МЭК 10030—96

Таблица I — Типы лейстнигсльнмх ПБД

Биты

Тип ПЬД    |    s

*

?

6

1

*

)

I

1

ПБДЗКОС . 0

0

0

0

0

0

0

1

Г1БДЗУОС

0

0

0

0

(1

0

1

0

ПБД СОС

0

0

0

0

0

0

1

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

«

ПБД ОКЛ

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

1

0

0

0

1

Все другие значения типов ПБД зарезервированы.

12.1.4    Адрес на сетевом уровне

В ПБД ЗВОС он определяет адрес на сетевом уровне, который сообщен как имеющийся и доступный в данной ОС. В ПБД ЗКОС он определяет адрес на сетевом уровне, для которого должна быть собрана информация. В ПБД OKJ1 и ПБД 3KJ1 он определяет адрес на сетевом уровне, для которого обеспечивается информация.

Параметр ‘адрес на сетевом уровне" кодируется, как показано на рисунке I.

Ок гст

Указатель. длины адреса на сетевом уровне (например, k) | j

Значение параметра "адрес на сетевом уровне” j * +

_____J j к

Рисунок I - Параметр "адрес на сотовом уровне'

Содержимое этого поля должно кодироваться в соответствии с предпочтительным двоичным кодированием, определенным в ГОСТ Р ИСО 8348/Доп. 2.

12.1.5    Адрес 11 ПИ

В ПБД ОКЛ и ПБД ПОС он определяет адрес ППП. который может использоваться для обращения к требуемому адресу на сетевом

уровне.

Страница 31

ГОСТ P ИСО/МЭК 10030-96

Параметр "адрес ППП” колируется в соответствии с рисунком 2.

Октет

Тип Указатель длины адреса ППП (например, k) J j

Значение параметр;» "адрес ППП"    И * *

______ ____ Jj + k

Рисунок 2 — Параметр "адрсс ППП"

Поле “тип" состоит из двух битов, указывающих формат кодирования 11Г1. Оно принимает следующие значения:

00    — кодирование в соответствии с настоящим стандартом;

01    — зарезервировано;

10    —зарезервировано;

11    — локальное — только для временного использования.

Гели ноле "тип” имеет значение 00, то следующие 6 битов представляют собой длину поля "значение параметра адреса ППП". Определены следующие стандартные коды:

a)    Если адрес ППГ1 передан в соответствии с протоколом досту па к подсети в виде последовательности нслых октетов, то эта последовательность октетов представляет собой значение поля “значение параметра адреса ППП".

Примечание I — Сюда относится, например, адреса УДС по ГОСТ 28907. которые должны быть прсдстанлсиы н дкмчном коде адресов УЛС в соответствии с ГОСТ 34 936. а также тс ситуации, где ис пол муст ей кол MKS

b)    Если адрес П П П передан в соответствии с протоколом доступа к подсети в виде последовательности полуоктстов с использованием кола ДДК, то эта последовательность кодируется в поле "значение параметра адреса ПГ1ГГ и представлена нечетным числом полуокте-тов с последним полуоктетом, содержащим значение 1111 в конце последовательности.

Примем анис2 — Значения по подпунктам а) и Ь) иыбиракл с таким расчетом, чтобы они соответствовали тем значениям, которые должны бытьобшеиспол му с ч ы м и в нолях ПИП ГОСТ Р ИСО/МЭК 9542 с точки трения одних и тех же требований, ирг,-п.»плясмых »тим стандартом

12.16 Качество услуг

В Г1БД ОКЛ этот параметр определяет диапазон КУ, в котором применим указанный ППП. В ПБД ЗВОС он определяет диапазон КУ, который может быть обеспечен указанной ОС заданного ППП.

Параметр КУ кодируется в соответствии с рисунком 3.

26

Страница 32

ГОСТ Р ИСО/МЭК 10030—96

Октет i

j+1 j + 2 j + k + I Рисунок i — Кодирование параметрит КУ

Код параметра,__

Длина параметра

Значение параметра

Поле "код параметра’' представляется » двоичном виде и при отсутствии расширений обеспечивает максимум 255 различных параметров. Код 255 (двоичное значение 1111 1111) зарезервирован для возможных будущих расширений

Поле “длина параметра- указывает длину в октетах поли "значение параметра". Длина указывается положительным двоичным числом К., теоретическое максимальное значение которою равно 254 Практическое максимальное значение к меньше и с каждым следующим параметром максимальное значение к уменьшается.

Поле "значение параметра" содержит значение параметра, указанное полем "код параметра".

121.6.1 Пропускная способность

При наличии параметра КУ "пропускная способность" он указывает диапазон значений пропускной способности, относящихся к заданному маршруту.

Код параметра 0000 0001

Длина параметра:    Один    октет.

Значение параметра: Четыре наиболее значащих бита определяют максимальную пропускную способность в соответствии с кодом, заданным в таблице 18 ГОСТ 28907, четыре наименее значащих бита определяют минимальную пропускную способность в соответствии с кодом, заданным в таблице 18 ГОСТ 28907.

12.1.6.2 Транзитная задержка

При наличии параметра КУ "транзитная задержка" он указывает максимальное и минимальное значения транзитной задержки, которые следует ожидать на заданном маршруте.

Код параметра:    0000 0010

Длина параметра:    Четыре    октета.

Значение параметра: Первые два октета определяют целое число секунд, указывающих максимальное значение ожидаемой транзитной задержки, а следующие два октета — минимальное значение ожидаемой транзитной задержки.

г

Страница 33

ГОСТ Р ПСО/М ЭК 10030 96

12 1.6 3 Приоритет

При наличии параметра КУ "приоритет" ом определяет максимальное и минимальное значения приоритета данных в соединении, приоритет получения соединения и приоритет сохранения соединения по сданному маршруту.

Кол параметра:    0000 CJ11

Длина параметра:    Шесть октетов

Значение параметра: Первые гри октета определяют макси мал ыюе значение приоритета данных в соединениях, приоритет получения соединения и приоритет сохранения соединения соответственно. Следующие три октета определяют минимальное значение приоритета данных в соединении, приоритет получения соединения и приоритет сохранения соединения соответственно

12.1.6.4 Защита

При наличии параметра КУ "зашита" он указывает максимальное и минимальное значения уровней защиты информации, ожидаемые в данном маршруте

Кол параметра    0000 0100

Длина параметра:    Переменная.

Значение параметра. Биты 8 и 7 первого октета определяют код формата защиты, а именно:

00    — зарезервировано;

01    — конкретный адрес отправления;

10    — конкретный адрес получателя;

11    — глобальный уникальный.

Остальные шесть битов первого октета зарезервированы и должны быть установлены в значение 0. Второй октет определяет длину р в октетах максимального ожидаемого уровня зашиты. Фактическое значение максимального уровня зашиты содержится в следующих р октетах.

Октет р + 2 определяет длину q в октетах минимального ожидаемого уровня защиты. Фактическое -значение минимального уровня защиты содержится в следующих Я октетах.

12.1.7 Время сохранения

2*

Страница 34

ГОСТ P ИСО/МЭК 10030-96

В ПБД ОКЛ и ПОС это двухоктетный параметр, определяющий целое число секунд, и течение которых передаваемая информации является действительной. Двоичное значение 0000 0000 0000 0000 указывает, что временной предел отсутствует.

12.1-8 Маска адреса

При наличии этого поля в ПБД ОКЛ и ПОС оно содержит маску адреса, которая должна использоваться в соответствии с 10 I

Параметр "маска адреса” колируется следующим образом:

Код параметра:    1110 0001

Длина параметра:    Переменная, до 20 октетов

Значение параметра: Маска сравнения октетов, которая должна быть уравнена с адресом получателя

12.1 9 Маска //////

При наличии этого ноля в ПБД ОКЛ и ПОС оно содержит маску ППП. которая должна использоваться в соответствии с 10.2.

Кол параметра:    I \ 10 0010

Длина параметра:    Переменная.

Значение параметра: Маска сравнения октетов, которая должна быть уравнена с адресом получателя

12.1.10    Предельное число зап/юсов

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

Параметр "предельное число запросов" кодируется одним октетом, где двоичное значение 0000 0000 указывает, что последующие запро сы не разрешаются, а двоичное значение 0000 0001 — что ОС разрешено выдать следующий запрос, если она пожелает.

12.1.11    Время запросов

В ПБД ЗУЛ этот параметр указывает промежуток времени между запросами от ОС. допускаемый ЛОРАП Двоичное значение 0000 0000 указывает отсутствие временного предела

Параметр "время запроса" кодируется в виде одного октета, определяющего целое число секунд.

12.1.12    Требуется уведомление

В ПБД ПУЛ этот параметр указывает временной интервал, в течение которого ОС может не выдавать ЛОРАП повторного уведомления.

Параметр "требуется уведомление" является двухоктетным и определяет целое число секунд временного интервала Двоичное значе ние 0000 0000 0000 0000 означает, что уведомление не требуется.

29

Страница 35

ГОСТ Р ИСО/МЭК 10030-96

Двоичное значение till INI 1111 III) означает, что никакою конкретного значения не рекомендуется.

12.2 Структура ПБД

Все ПБД состоят из целою числа октегов. В ПБЛ октеты нумеруются в воэрастаюшем порядке, начиная с I. Бит октета нумеруются от I до 8. при этом бит ! является битом младшей значимости.

При использовании последовательности октетов для представле-ния двоичного числа октет с наименьшим номером имеет наибольшую значимость.

Примечание — Если ПБД кодируется с иеппльхнинием диаграмм данного ромело. то ислолыустся следующее ирелстамснне:

-- октеты указаны в иерчмей част с наименьшим номером, а в нижней — с наибольшим номером,

-- и пределах октега Г>иг 8 покатан слева, а бит I — справа

12.2.1 Структура ПБД 3КОС

Формат ПБД ЗКОС показан на рисунке 4.

Октет

Идентификатор протокола сетевого уровня Номер версии |    Тип ПБД

Указатель длины адреса на сетевом уровне

Адрес на сетевом уровне

Рисунок 4 — Структура ПБД ЗКОС

12.2.2    Структура ПБД ЗУОС

Формат ПБД ЗУОС показан на рисунке 5.

Октет

1

2 3

Идентификатор протокола сетевого уровня Номер версии Тип ПБД

Рисунок 5 — Структура П БД ЗУОС

12.2.3    Структура ПБД СОС

Формат ПБД СОС показан на рисунке 6.

30

Страница 36

ГОСТ Р ИСО/МЭК 10030-96

Октет

Идентификатор протокола сетевого уровня 1 Номер версии    _    ,2

__________Тип ПБД________3

Рисунок 6 — Структура ПБД СОС

12.2.4 Структура ПБД ЗВОС Формат ПБД ЗКОС показан на рисунке 7.

Октет

I

Идентификатор протокола сетевого уровня

Номер версии_______

__ Тип ПБД_____________

Указатель длины адресатаi сетевом уровне

Алрсс на сетевом уровне

[- ■■

+ m

КУ

Рисунок 7 — Структура ПБД ЗВОС

12.2 5 Структура IIБД ПОС

Формат ПБД ЗКОС показан на рисунке 8.

Октет

Идентификатор протокола сетевого уровня •. 1 .........Номер версии    ____________2

Тип ПБД    I    ]

. . I 4 I 5

____Время удержания

Тип (____Указатель длины адреса ППП

6

7

k - I к

m — I m

n — 1

Значение параметра адреса ППП

Параметр маски адреса

Параметр маски ППП

Рисунок 8 - Структура ПБД ПОС

Страница 37

ГОСТ Р ИСО/МЭК 100.10-%

12.2.6    Структура ПБД ЗКЛ Формат ПБД ЗКЛ показан на рисунке 9.

Идентификатор протокола сетевого уровня Помер версии Тип ПБД

Октет

1

2

3

4

5

k -1 m

п — I

Октет

\

2

3

4

5

6 7

j k- I

J к

I к + \

] m — I

I m n — I

n

p- 1

Указатель длины адреса на сетевом уровне Адрес на сетевом уровне

Предел запросон ^ Рисунок 9 — Структура ПБД ЗКЛ

12.2.7    Структура ПБД ОКЛ Формат ПБД ОКЛ показан на рисунке 10.

Идентификатор протокола сетевого^уровня Помер версии

Тип ПБД

Время удержания _ _____

Указатель длины адреса на сетевом уровне

Адрес на сетевом уровне

Тип j    Указатель    длины    адреса ППП_

Значение параметра адреса ППП

Параметр маски адреса

Параметр маски ППП

КУ

Рисунок 10 — Структура ПБД OKJl

32

Страница 38

ГОСТ Р ИСО/МЭК 10030—96

12.2.8 Структура ПБД ЗУЛ

Формат ПБД ЗУЛ показан на рисунке 11.

Октет

1

2

3

4

Октет

1

2

3

4

Идентификатор протокола сетевого уровня Номер версии Тип ПБД

Время запроса Рисунок II — Структура ПБД ЗУЛ

12.2.9 Структура Л БД ПУЛ

Формат ПБД ПУЛ показан на рисунке 12.

Идентификатор протокола сетевого уровня Номер версии Тип ПБД

______ Требуется уведомление

Рисунок 12 - Структура ПЬД ПУЛ

Страница 39

ГОСТ Р ИСО/МЭК 10030-96

ПРИЛОЖЕНИЕ А (обяютсгыюе)

ПОЛУЧЕНИЕ АДРЕСОВ КПП ЛОРА11 С ИСПОЛЬЗОВАНИЕМ нрошлур

УЛЗ ТИПА I

А.1 Введение

В данном Приложении привадится описание тех процедур, которые могут быть испозыовлны п некоторых конкретных ситуациях с тем. чтобы обеспечить возможность оконечным системам распознавать адреса ППП ЛОРАП

А.2 Широковещательны* подсети. использ)зошие процедуры УЛЗ гни* I Шщюкоьеша тельная подсеть — это такая подсеть, физические характеристики которой позволяют обеспечить прием отдельной передачи II БД С всеми системами или предварительно заданной группой систем, подключенных к подсети Данный раздел относится к тем широковещательным подсетям. в которых используются процедуры УЛЗ типа I. определенные в ГОСТ 2Я907

При выполнении происдур. описываемых в данном разделе, должно использозшть-ся значение ПДУЗ. приведенное в ИСО/МЭК ТО 10178 для использования совместно с ИСО/МЭК ТО 9577. В ПБД данного протокола входит поде идентификатор исходною протокола <ИИП). обсспечивоюшес идентификацию протокола способами, описанными в ИСО/МЭК ТО 9577.

А.2-1 Широковещательные процедуры УЛЗ типа 1 ЛОРАП А.2 I I Параметры пр<т-око.ю

А 2 ! I I Параметр "время широковещательной передачи" определяет временной интервал, в течение которого ЛОРАП, реализующий данную процедуру, может передавать широковещательную информацию, чтобы обеспечить распознавание своего ЛОРАП А 2 1.1.2 Параметр 'время сохранения" входит в передаваемые ПБД и указывает время, в течение которого содержащаяся в них информация остается действительной. А.2.1 2 Операции протокша

Объект ЛОРАП. подключенный к ЛВС в соответствии с ГОСТ 28907 и выполняющий широковещательные процедуры ЛОРАП. должен передавать ПБД ЗВЛ, сформированный в соответствии с А 2 3. через интервалы времени, равш4с значению пара, метра "время широковещательной передачи" Он должен передавать зги ПБД с использованием примитива ЗД-БЛОК-ДАННЫХ запрос, определяющего адрес получателя. значение которого в данной подсети должно означать “все оконечные системы с УСУ УС*.

А.2 2 111 и ро ко ве ща те л ьн ые процедуры УЛЗ типа I ОС Оконечная система, палкгкукнная к ЛВС о соответствии с ГОСТ 2X907 и выполняющая широковещательные процедуры УЛЗ типа I ОС. должна воспринимать примитив ЗД-БЛОК-ДАННЫХ индикация, чей адрес получателя представляет собой значение, которое в данной подсети должно означать "осе оконечные системы с УСУ УС".

При получении примитива ЗД-БЛОК-ДАННЫХ индикация должны быть проанализированы содержащиеся в нем данные Если он не содержит ПБД ЗВЛ, сформированный в соответствии с А.2 3. он должен быть проигнорирован. Если же он содержит

34

Страница 40

ГОСТ Р ИСО/МЭК 10030—96

такой ПБД и если ОС еще не имеет зарегистрированный ллрсс ППП ЛОРАП. ОС должна зарегистрировать адрес отправителя, от которого получен примитив 311-БЛОК ДАННЫХ в качестве адреса 1111(1 ЛОРАП, и должна увязать его со временем, указанным в поле ‘время сохранения"

При получении действительного ПБД ЗВЛ, когда ОС имеет зарегистрированный алрсс отправителя в качестве адреса ППП ЛОРАП. она должна обновить регистрацию соответствующего параметра ’время сохранении* на содержащееся в полученном ПБД

При получении действительного ПБД ЗВЛ. когда ОС уже имеет aapciистрирован-ный адрес ППП ЛОРА11. но не адрес, содержащийся в адресе отправителя и» примитива ЗД-БЛОК-ДАННЫХ индикация, ОС можс( и регистрировать ППП и время сохранения, как указано выше, но необязательно Если ома выполняет такую регистрацию, она может аннулировать любой из уже зарегистрированных адресов ППП ЛОРАП или нее такие адреса

ОС должна аннулировать любой зарегистрированный адрес ППП ЛОРАП. если время, прошедшее с момента получения последнего ПБД ЗВЛ из литого адреса. достигло соответствующего времени сохранения

Кроме тою, ОС может проанализировать поле "требуется уведомление* и определить необходимость уведомления

А23 Структура ПБД ЗВЛ

ПБД ЗВЛ формируется п соответствии с рисунком A I

Октет

Идентификатор протокола сетевого уровня Номер версии Тип ПБД

1

2

3

4

5

Требуется умеломление Время сохранения

Рисунок А I — Структура ПБД ЗВЛ

А З Широковещательная процедура УЛЗ типа I ОС

Эта процедура является факульгашвной

При функционировании процедур, описываемых в данном разделе, применяют значение ПДУЗ, установленное ц ИСО/МЭК ТО 10178 при совместном использовании с ИСО/МЭК ТО 9577 В ПБД данного протокола входит поле ИИП, обеспечивающее идентификацию протокола способами, описанными в ИСО/МЭК ТО 9577

ОС. которой подключена к ЛВС в соответствии с ГОСТ 2К907 и желает распознавать адрес ПГ1П ЛОРАП. но которая еще не получила ПБД ЗВЛ. может передать ПБД ЗЗЛ, е<|я>рмированный в соответствии с А 31 Она должна передать этот ПБД ЗЗЛ, используя примитив ЗД-БЛОК*ДАННЫХ запрос, определяющий адрес получателя, значение которого в данной подсети должно означать "все ЛОРАП Х.25*

35

Страница 41

ГОСТ Р ИСО/МЭК 10030-96

Объект ЛОРЛЛ. подключенный к ЛВС’ но ГОСТ 28907 и желающий выполнять широкоиеишсльные процедуры ЛОРАН, должен воспринимать примитивы ЗД-БЛОК-ЛАННЫХ пиликании. адреса получателя которых и данной подсети означают "IICC ЛОРАН X 25"

При получении примитива Ш-БЛОК-ДАННЫХ пиликания должны был. проаиа литироганы содержащиеся в нем данные Гели он не содержит ПБД ЗВЛ. сформиро ванный в соответствии с Л 3 I. он должен быть проигнорирован Рели *с он содержит такой ПБД, ЛОРАП должен передать ПБД ЗВЛ в соответствии с А 2

Примечай и с Такая передача Г1БЛ ЗВЛ со стороны ЛОРАП должна рассматриваться как дополнительная передача н. следовательно. не должна приводить к сбросу нормального тайм-аута для ПБД ЗВЛ А.З. I Структура ПБД ЗЗЛ Формат ПБД ЗЗЛ покатан на рисунке А 2

Октет

Идентификатор протокола сетевого уровня Номер версии Тип ПБД

1

2 3

Рисунок А 2 — Структура ПБД ЗЗЛ

36

Страница 42

ГОСТ Р ИСО/МЭК 100М-96

УДК 681.324 006 354 О КС 35 100.30    П85    ОКСТУ    4002

Ключевые слова: обраСкмка данных. обмен информацией, взаимосвязь сстсй, взаимосвязь открытых систем, процедура обмена данными, процедуры управления, протоколы

Редактор ГС Ш<КО Технический редактор И С Гришпнова Когг<к>тор В И Воренцалп Компьютерная перстка В И Грищгмка

Им. лиц N1021007 от 10 08.95 Слано и набор 04 07 96 Подписано в печать 18.09 96 Угл печ я 2,33 Уч -им л 2,25 Тираж 311 м». C382I Зак 422 И ПК И i.un nu rnn стандартов 107076. Москш, Ко.юлс тыл пер U Hafipano и Мшательсгае на ПЭВМ Филиал ИПК И 1лателигт*остандартов — тип ‘Московский печатник"

Моек ко. Лялин (»ср . 6