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

ГОСТ Р ИСО 9542-93

Группа П85

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

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

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

In formation processing systems. Telecommunications and information exchange
between systems. End system to Intermediate system routeing exchange protocol
for use in conjuction with the protocol for providing the connectionless-mode
network service

ОКСТУ 4002

Дата введения 1994-07-01

Предисловие

1 ПОДГОТОВЛЕН И ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационная технология"

2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 20.12.93 N 264

3 Настоящий стандарт подготовлен на основе применения аутентичного текста международного стандарта ИСО 9542-88 "Информационная технология. Передача данных и обмен информацией между системами. Протокол обмена маршрутной информацией между оконечной системой и промежуточной системой при его использовании в сочетании с протоколом, обеспечивающим услуги сетевого уровня в режиме-без-установления-соединения (ИСО 8473-88)

4 ВВЕДЕН ВПЕРВЫЕ

0 ВВЕДЕНИЕ

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

Место настоящего стандарта среди других соответствующих стандартов определено уровнями, стандартизованными в ГОСТ 28906, а также структурой сетевого уровня, стандартизованной в ИСО 8648. В частности, он определяет протокол сетевого уровня.

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

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

Настоящий стандарт следует применять совместно с ГОСТ Р 34.1952.

Настоящий стандарт обеспечивает решение следующих практических вопросов:

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

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

c) Как промежуточной системе распознать наличие и доступность оконечных систем в каждой из подсетей, к которым они непосредственно подсоединены?

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

Настоящий протокол исходит из того, что:

a) маршрутизация по определенному адресу пункта подключения подсети (ППП) одной и той же подсети осуществляется удовлетворительно самой этой подсетью;

b) подсеть неспособна осуществлять маршрутизацию на глобальной основе с использованием только одного адреса ПБДС для осуществления обмена данными с запрошенным адресатом*.

________________

* Следовательно, для выполнения функций настоящего стандарта невозможно использовать обмен данными на прикладном уровне.

Кроме того, некоторые протокольные функции исходят из предположения, что:

c) подсети обеспечивают глобальную, групповую и другие виды множественной адресации при однонаправленной передаче.

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

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

- минимизации емкости памяти, необходимой для хранения маршрутной информации в оконечных системах и

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

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

Настоящий стандарт определяет протокол, используемый логическими объектами сетевого уровня, функционирующими в соответствии с ГОСТ Р 34.1952 в оконечных системах (ОС) и промежуточных системах (ПС) для обеспечения маршрутной информации. Определяемый здесь протокол основан на обеспечении нижерасположенных услуг режима-без-установления-соединения*.

________________

* Описание механизмов, необходимых для реализации этих услуг в подсетях, соответствующих ГОСТ Р 34.950 и ГОСТ 28907, см. в разделе 8 ГОСТ Р 34.1952.

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

a) процедуры передачи информации о конфигурации и маршрутной информации между логическими объектами сетевого уровня, содержащимися в оконечных системах, и логическими объектами сетевого уровня, содержащимися в промежуточных системах;

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

c) процедуры правильной интерпретации протокольной управляющей информации и

d) функциональные требования к заявкам о соответствии конкретных реализаций настоящему стандарту.

Перечисленные процедуры определены с точки зрения:

a) взаимодействий между логическими объектами оконечных и промежуточных систем путем обмена протокольными блоками данных и

b) взаимодействий между логическим объектом сетевого уровня и поставщиком нижерасположенной услуги путем обмена примитивами услуг подсети.

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

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

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

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

ИСО 7498-84/Доп.4-89* "Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель. Дополнение 4. Основы управления ВОС"

________________

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

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

ГОСТ Р 34.951-92 (ИСО 8348-87 и ИСО 8348/Доп.1-87) "Информационная технология. Взаимосвязь открытых систем. Услуги сетевого уровня"

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

ГОСТ Р 34.1952-92 (ИСО 8473-88) "Системы обработки информации. Передача данных. Протокол сетевого уровня в режиме-без-установления-соединения"

ИСО 8648-88* "Системы обработки информации. Взаимосвязь открытых систем. Внутренняя организация сетевого уровня"

________________

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

МККТТ Х.25. "Интерфейс между оконечным оборудованием данных (ООД) и аппаратурой окончания канала данных (АКД) для оконечных установок, работающих в пакетном режиме и подключенных к сетям данных общего пользования выделенными каналами, 1985"

Часть первая. Общие положения

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) Протокольная адресная информация сетевого уровня

d) Наименование логического объекта сетевого уровня

3.4 Определения из стандарта по локальным вычислительным сетям

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

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

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

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

Для целей настоящего стандарта введено следующее определение:

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

4 СИМВОЛЫ И СОКРАЩЕНИЯ

4.1 Блоки данных

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

4.3 Поля протокольных блоков данных

4.4 Параметры

4.5 Адреса

4.6 Разное

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

5.1 Информация, обеспечиваемая протоколом

Настоящий стандарт обеспечивает для логических объектов сетевого уровня, поддерживающих его работу, два вида информации:

- информацию о конфигурации и

- информацию о переадресации маршрута.

Информация о конфигурации позволяет оконечным системам распознавать наличие и доступность промежуточных систем, а промежуточным системам - распознавать наличие и доступность оконечных систем. Эта информация позволяет подключать ОС и ПС к одной и той же подсети с целью динамического распознавания наличия и доступности друг друга, исключая тем самым необходимость ручного вмешательства в ОС и ПС с целью установления идентичности тех логических объектов сетевого уровня, которые могут быть использованы для маршрутизации СБДС.

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

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

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

5.2 Адресация

Параметрами "адрес отправителя" и "адрес получателя", которыми оперирует настоящий стандарт, являются адреса пунктов доступа к услугам сетевого уровня ВОС. Синтаксис и семантика адреса ПДУСУ описаны в ГОСТ Р ИСО 8348/Доп.2.

5.3 Нижерасположенные услуги, на которые ориентируется настоящий протокол

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

Таблица 1 - Сервисные примитивы нижерасположенных услуг

Примечание - Эти сервисные примитивы используются для описания абстрактного интерфейса между протокольными автоматами и нижерасположенной реальной подсетью или функции сходимости, зависимой от подсети (ФСЗП), которая действует через реальную подсеть или реальное звено данных с целью обеспечения требуемых нижерасположенных услуг*.

________________

* Описание механизмов, необходимых для реализации этих услуг в подсетях, соответствующих ГОСТ Р 34.950 и ГОСТ 28907, см в разделе 8 ГОСТ Р 34.1952.

5.3.1 Адреса подсети

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

Настоящий стандарт призван использовать преимущества тех подсетей, которые обеспечивают глобальную, групповую или другие формы множественной адресации при n-направленной передаче данных. Предполагается, что параметр "адрес-получателя-ПСТ" может принимать одно из следующих значений множественного адреса дополнительно к обычному индивидуальному адресу:

- все логические объекты сетевого уровня оконечной системы;

- все логические объекты сетевого уровня промежуточной системы.

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

Если адрес-ПСТ-получателя в примитиве ПСТ-БЛОК-ДАННЫХ.запрос явится множественным адресом, то параметр адрес-ПСТ-получателя в соответствующем примитиве ПСТ-БЛОК-ДАННЫХ.индикация должен быть таким же множественным адресом.

В настоящем стандарте не определяется синтаксис и семантика адресов подсети, за исключением описанных выше свойств.

5.3.2 Данные пользователя подсети

Параметр "данные-пользователя-ПСТ" представляет собой упорядоченный набор октетов, передаваемых "прозрачно" между заданными пунктами подключения подсети.

Нижерасположенные услуги должны обеспечивать такую длину сервисных блоков данных, которая, по меньшей мере, необходима для работы протокола ГОСТ Р 34.1952.

5.4 Типы подсетей

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

a) двухпунктовая подсеть;

b) широковещательная подсеть и

c) подсеть общей топологии.

Эти типы подсетей обсуждаются ниже.

5.4.1 Двухпунктовые подсети

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

5.4.1.1 Информация о конфигурации в двухпунктовой подсети

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

a) топология сети содержит либо только две оконечные системы, либо

b) одной из двух систем является промежуточная система.

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

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

5.4.1.2 Информация о переадресации маршрута в двухпунктовой подсети

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

5.4.2 Широковещательные подсети

Широковещательная подсеть поддерживает любое число оконечных и промежуточных систем и, кроме того, она способна передавать отдельные ПБДП всем этим системам или их подмножеству в ответ на получение одного примитива ПСТ-БЛОК-ДАННЫХ.запрос. Примером широковещательной подсети служит локальная вычислительная сеть (ЛВС), соответствующая ГОСТ 28907, реализующая операции типа 1.

5.4.2.1 Информация о конфигурации в широковещательной подсети

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

a) оконечные системы проинформированы о доступности, наименованиях логических объектов сетевого уровня и адресе(ах) ППП каждой активной промежуточной системы данной подсети;

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

c) при отсутствии доступной ПС оконечные системы могут через широковещательную подсеть задать вопрос: доступен ли конкретный ПДУСУ в данной подсети и если да, то какой адрес следует использовать для обращения к этому ПДУСУ?

5.4.2.2 Информация о переадресации маршрута по широковещательной подсети

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

5.4.3 Подсети общей топологии

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

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

5.4.3.1 Информация о конфигурации в подсети общей топологии

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

5.4.3.2 Информация о переадресации маршрута в подсети общей топологии

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

Часть вторая. Спецификация протокола

6 ПРОТОКОЛЬНЫЕ ФУНКЦИИ

В данном разделе описываются функции, выполняемые как часть протокола. Конкретные реализации не обязательно должны выполнять все эти функции: в 8.1 указано, какие функции являются обязательными, а какие - факультативными.

6.1 Протокольные тайм-ауты

Многие из протокольных функций основаны на тайм-аутах. Это значит, что они выполняются в результате истечения тайм-аутов, а не в результате приема ПБД или привлечения сервисного примитива. К двум типам используемых протоколом тайм-аутов относятся тайм-аут конфигурации (ТК) и тайм-аут удержания (ТУ).

Примечание - Рекомендуется, чтобы значения тайм-аутов были реализованы с точностью не хуже одной секунды.

6.1.1 Тайм-аут конфигурации

Тайм-аут конфигурации - это локальный тайм-аут (т.е. поддерживаемый в каждой системе независимо от других систем), который участвует в выполнении функции "отчет о конфигурации" (см. 6.2). Это тайм-аут определяет, как часто система сообщает о своей доступности другим системам той же подсети. Чем короче ТК, тем более быстро другие системы подсети узнают о том, что данная подсеть стала доступной или недоступной. Существует некоторое компромиссное решение между ускорением реакции сети и ростом использования ресурсов подсети и систем-получателей.

6.1.2 Тайм-аут удержания

Тайм-аут удержания применим к обоим видам информации: о конфигурации и о переадресации маршрута. Значение тайм-аута удержания устанавливается источником информации и передается в поле "время удержания" соответствующего ПБД. Получатель информации рассчитывает хранить ее не дольше длительности тайм-аута удержания. Прежняя информация о конфигурации и о переадресации должна быть аннулирована после истечения тайм-аута удержания с тем, чтобы гарантировать корректность операций протокола.

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

6.2 Функция "отчет о конфигурации"

Функция "отчет о конфигурации" используется оконечными и промежуточными системами для информирования друг друга о своей доступности и о текущем(их) адресе(ах) подсети(ей). Эта функция привлекается всякий раз при истечении локального тайм-аута конфигурации в ОС и ПС. Она может быть привлечена и при других обстоятельствах. Например, если один из системных ППП входит в рабочее состояние, эта функция может выполняться более часто, чем по истечении тайм-аута конфигурации. Это позволяет более быстро сообщать другим системам об изменениях конфигурации.

6.2.1 Отчет о конфигурации, выдаваемый оконечными системами

Логический объект сетевого уровня оконечной системы формирует и передает ПБД ЗОС для информирования других систем об обслуживаемых им ПДУСУ. Это может выполняться путем формирования одного ПБД ЗОС для каждого ПДУСУ. Как вариант могут формироваться такие ПБД ЗОС, каждый из которых переносит информацию сразу о нескольких ПДУСУ, число которых ограничивается лишь допустимой длиной СБДП и максимальной длиной заголовка ПБД ЗОС. Передача каждого ПБД ЗОС осуществляется путем выдачи примитива ПСТ-БЛОК-ДАННЫХ.запрос со следующими параметрами:

данные-пользователя-ПСТ (СБДП) - ПБД ЗОС;

адрес-ПСТ-получателя - групповой адрес, указывающий "все логические объекты сетевого уровня промежуточной системы".

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

Примечание - Необходимость информирования других систем об отдельных ПДУСУ, обслуживаемых логическим объектом сетевого уровня, возникает из-за отсутствия формализованных взаимоотношений между наименованиями логических объектов сетевого уровня и адресами ПДУСУ. Если бы эти взаимоотношения можно было ограничить требованием назначать адреса ПДУСУ как новые подрегионы региона, представленного наименованием локального логического объекта сетевого уровня, то можно было бы передать отдельный ПБД 3ОC, который содержал бы наименование логического объекта сетевого уровня оконечной системы. По наименованию логического объекта сетевого уровня можно было бы определить, какой из ПДУСУ может быть представлен в этой оконечной системе.

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

Примечание - Фактическое значение адреса-ПСТ-получателя, используемого для обозначения "все логические объекты сетевого уровня промежуточной системы", зависит от подсети и будет, видимо, различным в разных подсетях. Конечно, в широко используемых типах подсетей (основанных, например, на ГОСТ Р 34.950) желательно, чтобы это значение группового адреса получателя "все логические объекты сетевого уровня оконечной системы" было стандартным.

6.2.2 Отчет о конфигурации, выдаваемый промежуточной системой

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

данные-пользователя-ПСТ (СБДП) - ПБД ЗПС;

адрес-ПСТ-получателя - групповой адрес получателя, указывающий "все логические объекты сетевого уровня оконечной системы".

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

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

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

6.3 Функция "запись конфигурации"

Функция "запись конфигурации" принимает ПБД ЗОС или ЗПС, извлекает из них информацию о конфигурации и обновляет эту информацию в базе информации о конфигурации локального логического объекта сетевого уровня.

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

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

От системы-получателя не требуется, чтобы при приеме ПБД ЗОС или ЗПС она обрабатывала какие-либо факультативные поля.

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

6.3.1 Запись информации о конфигурации промежуточными системами

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

6.3.2 Запись информации о конфигурации оконечными системами

При приеме ПБД ЗПС оконечная система выделяет информацию о конфигурации и запоминает в своей локальной базе маршрутной информации пары значений {НЛС, ППП}, заменяя любую другую информацию той же пары {НЛС, ППП}. Если для размещения новой информации о конфигурации нет достаточной емкости памяти, то полученный ПБД аннулируется.

Кроме того, ОС может выполнить перерасчет своего ТК, основываясь на принятом ПБД ЗПС, который содержит факультативное поле "тайм-аут конфигурации, предложенный ОС (ТКОС)". Если оконечная система предпочитает использовать вычисленный ТК, а не локальное его значение, предоставленное диспетчером системы, то она выполняет следующие операции:

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

- если ТКОС предложен одной или несколькими ПС, то минимальное из предложенных значений заменяет текущее значение ТКОС.

6.4. Функция "удаление старой информации о конфигурации"

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

Функция "удаление старой информации о конфигурации" выполняется также всякий раз, когда поставщик услуг подсети повторно инициирует локальный ППП. Если ППП вошел в неактивное состояние или повторно инициирован, то вся информация о конфигурации как для ОС, так и для ПС, относящаяся к данному ППП, удаляется.

6.5 Функция "запрос конфигурации"

Функция "запрос конфигурации" выполняется при следующих условиях:

a) оконечная система подключена к широковещательной подсети;

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

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

d) адрес ППП нельзя получить ни путем локальной передачи, ни путем просмотра локальной таблицы и

e) ограничения, налагаемые на качество услуг, допускают широковещательную передачу ПБД.

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

Если оконечной системе необходимо направить ПБДС в адресуемый ПДУСУ, у которого неизвестен ППП, она выдает примитив ПСТ-БЛОК-ДАННЫХ.запрос со следующими параметрами:

адрес-ПСТ-получателя - групповой адрес получателя, указывающий "все логические объекты сетевого уровня оконечной системы".

Затем может быть принят ПБД ЗОС, содержащий адрес ПДУСУ с соответствующим адресом ППП (см. 6.6). В этом случае оконечная система выполняет функцию "запись конфигурации" для данного ПДУСУ и, следовательно, она становится способной направлять последующие ПБД данным адресатам с использованием определенного ППП. Если ПБД ЗОС не получен, то оконечная система может объявить адресуемый ПДУСУ недоступным. Длительность ожидания ответа до указания неисправности или возможности многократного повторения этого процесса перед возвратом в состояние безуспешности является частным вопросом и не определяется настоящим стандартом.

6.6 Функция "ответ о конфигурации"

Функция "ответ о конфигурации" выполняется, когда оконечная система, подключенная к широковещательной подсети, получит ПБДС, адресованный одному из ее ПДУСУ, с параметром адрес-ПСТ-получателя примитива ПСТ-БЛОК-ДАННЫХ.индикация, установленным в значение "все логические объекты сетевого уровня оконечной системы". Это происходит в результате выполнения другой ОС функции "запрос конфигурации", описанной в 6.5.

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

данные-пользователя-ПСТПБД ЗОС;

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

6.7 Функция "информирование о конфигурации"

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

Система, предпочитающая реализовать эту функцию, выполняет ее, определив по полученному ПБД ЗОС или ЗПС, что другая система только что стала доступной. Затем она формирует ПБД ЗПС или ЗОС, как описано в 6.2.2 или 6.2.1 соответственно, но передает его, специально адресуя новой операционной системе с помощью примитива ПСТ-БЛОК-ДАННЫХ.запрос со следующими параметрами:

данные-пользователя-ПСТПБД ЗОС или ЗПС;

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

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

6.8 Функция "переадресация запроса"

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

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

Примечание - В качестве процесса оптимизации функция "переадресация запроса" может исследовать параметр адрес-ПСТ-отправителя примитива ПСТ-БЛОК-ДАННЫХ.индикация, который принял данный СБДП (содержащий этот ПБДС). Если можно определить (например, путем анализа информации о конфигурации, полученной посредством функции "запись конфигурации"), что адрес-ПСТ-отправителя не исходит от оконечной системы данной локальной подсети, то ПБД "переадресация" не нужно передавать.

Этот выход будет содержать среди прочего следующую информацию:

a) локальный идентификатор подсети, через которую направляется данный ПБДС, плюс либо

b) наименование логического объекта сетевого уровня и подсетевой адрес той ПС, к которой направляется данный ПБДС, либо

c) подсетевой адрес адресуемой оконечной системы.

Функция "переадресация запроса" определяет теперь, смогла ли ОС-отправитель послать ПБДС непосредственно логическому объекту сетевого уровня, которому ПС намерена направить этот ПБД. Если КУ и другие ограничения позволяют ПБДС обойти эту ПС, то при выполнении следующих условий ПС информирует ОС-отправителя о "лучшем" маршруте (передав ОС-отправителю ПБД ПА):

а) Следующий шаг делается в направлении адресуемой системы и адресат достигается непосредственно (по подсетевому адресу АПЛМ) через подсеть ОС-отправителя либо

b) следующий шаг делается в направлении ПС, которая подключена к той же подсети, что и ОС.

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

ПС может привлекать функцию "переадресация запроса" также в том случае, когда она получает ПБД, адресованный тому ПДУСУ, который недоступен для данной ПС, но для которого эта ПС знает первый шаг маршрута от ПБДС-отправителя к ПДУС-получателю. В этом случае ПС должна сначала выполнить процедуры, описанные в 6.9 и 6.10 ГОСТ Р 34.1952 по аннулированию этого ПБД и генерации отчета об ошибках. При завершении этой процедуры ПС должна проинформировать об этом систему-инициатора маршрута к адресуемому ПДУСУ, передав ПБД ПА.

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

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

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

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

Промежуточная система (в предположении, что она обладает достаточными ресурсами) передает затем полученный ПБД ПA оконечной системе-отправителю посредством примитива ПСТ БЛОК-ДАННЫХ.запрос со следующими параметрами:

данные-пользователя-ПСТПБД ПА;

адрес-ПСТ-отправителязначение параметра адрес-ПСТ-отправителя из примитива ПСТ-БЛОК-ДАННЫХ.индикация, содержащего исходный ПБДС в качестве его данных-пользователя-ПСТ.

6.9 Функция "переадресация записи"

Функция "переадресация записи" имеется только в оконечных системах. (Промежуточные системы могут принимать ПБД ПА, но не могут обрабатывать их). Эта функция привлекается всякий раз при приеме ПБД ПА. Она выделяет информацию переадресации и добавляет или заменяет соответствующую переадресующую информацию в базе маршрутной информации логического объекта сетевого уровня. Существенно важным является преобразование информации переадресации из адреса получателя в подсетевой адрес вместе с факультативными функциями приоритета, защиты и обеспечения КУ, а также со значением тайм-аута удержания, для которого данное преобразование рассматривается действительным. Если переадресация осуществлялась к другой промежуточной системе, то наименование логического объекта считается действительным. Если переадресация осуществлялась к другой промежуточной системе, то наименование логического объекта сетевого уровня также регистрируется.

Примечание - Если для хранения новой информации о переадресации нет достаточной емкости памяти, то ПСД ПА можно уверенно аннулировать, поскольку промежуточная система-отправитель будет в любом случае продолжать продвигать ПБД по поручению этого логического объекта сетевого уровня.

6.10 Функция "обновление информации о переадресации"

Функция "обновление информации о переадресации" имеется только в оконечных системах. Эта функция привлекается всякий раз, когда ПБДС поступает в адресуемую ОС. Она тесно связана с функцией, обрабатывающей ПБДС, принятые адресуемым логическим объектом сетевого уровня (т.е. с функцией декомпозиции ПБД в ГОСТ Р 34.1952). Цель этой функции состоит в том, чтобы продлить время существования информации о переадресации, предотвращая неопределенно долгое существование неправильного маршрута.

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

_______________

* Текст соответствует оригиналу. - .

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

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

6.11 Функция "удаление старой информации о переадресации"

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

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

6.12 Обнаружение ошибок в заголовке ПБД

Функция "обнаружение ошибок в заголовке ПБД" защищает от сбоев логические объекты сетевого уровня промежуточных и оконечных систем, вызванных обработкой ошибочной информации в заголовке ПБД. Эта функция реализуется с помощью контрольной суммы, вычисляемой на основе всего заголовка ПБД. Эта контрольная сумма проверяется каждый раз, когда обрабатывается ПБД. Если подсчет контрольной суммы дает отрицательный результат, то ПБД аннулируется.

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

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

;

,

где - число октетов в заголовке ПБД, - значение октета в позиции . Считается, что первый октет заголовка ПБД занимает позицию 1.

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

6.13 Функция "обработка протокольных ошибок"

Блок ПБД, в котором имеется поле "идентификатор протокола сетевого уровня" в значении, определенном в 7.2.2, и поле "версия/расширение идентификатора протокола" в значении, определенном в 7.2.4, и который не аннулируется функцией "обнаружение ошибок в заголовке ПБД", должен рассматриваться как протокольная ошибка, если его код не совпадает с остатком вычислений, рассматриваемым в разделе 7. Любые такие ПБД с протокольными ошибками должны быть аннулированы.

Примечание - Те ПБД, в которых ИПСУ имеет значение, отличное от указанного в 7.2.2. или параметр В/РИП имеет значение, отличное от указанного в 7.2.4, не рассматриваются в настоящем стандарте.

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

Примечание - В настоящем стандарте ПБД кодируются так же, как и в ГОСТ Р 34.1952.

7.1 Структура

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

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

Примечание - Если кодирование ПБД представлено с помощью диаграмм этого раздела, то используется следующее представление:

a) октеты показаны так, что младший по номеру октет расположен слева, а старший по номеру октет - справа;

b) в пределах октета биты расположены так, что бит восемь (8) расположен слева, а бит единица (1) - справа.

ПБД содержат следующие элементы в перечисляемой последовательности:

a) фиксированная часть;

b) часть "параметры адресации" и

c) факультативная часть (при ее наличии).

7.2 Фиксированная часть

7.2.1 Общие положения

Фиксированная часть заголовка ПБД имеет формат, показанный на рисунке 1.

Рисунок 1 - Фиксированная часть заголовка ПБД

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

Это поле должно иметь значение 1000 0010. Оно идентифицирует данный протокол сетевого уровня как ГОСТ Р ИСО 9542-93.

7.2.3 Указатель длины

Длина указывается двоичным числом, максимальное значение которого равно 254 (1111 1110). Указываемая длина означает длину всего ПБД (который состоит только из заголовка, поскольку настоящий стандарт не определяет передачи данных пользователя), выраженную в октетах, как определено в 7.1. Значение длины 1111 1111 зарезервировано для возможных будущих расширений.

7.2.4 Версия/расширение идентификатора протокола

Это поле содержит двоичное значение 0000 0001. Оно идентифицирует версию ГОСТ Р ИСО 9542.

7.2.5 Код типа

Поле "код типа" указывает тип протокольного блока данных. Значения, определенные для этого поля, приведены в таблице 2.

Таблица 2 - Действительные типы ПБД

Все остальные значения типа ПБД зарезервированы.

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

Поле "время удержания" определяет максимальное время, в течение которого принимающий логический объект сетевого уровня может хранить информацию о конфигурации/маршрутизации, содержащуюся в данном ПБД.

Поле "время удержания" кодируется виде целого числа секунд.

7.2.7 Контрольная сумма ПБД

Контрольная сумма вычисляется на основе всего заголовка ПБД. Нулевое значение контрольной суммы зарезервировано для указания того, что контрольная сумма должна игнорироваться. Функция "обнаружение ошибок в заголовке" (см. 6.12) гарантирует, что это нулевое значение не отражает действительной контрольной суммы.

7.3 Часть "параметры адресации"

7.3.1 Общие положения

Параметры адресации различаются позиционно. Различные типы ПБД содержат различные параметры адресации: ПБД ЗОС содержит один или несколько адресов ПДУСУ-отправителя (АО), ПБД ЗПС - наименование логического объекта сетевого уровня (НЛС) промежуточной системы и ПБД ПА - адрес ПДУСУ-получателя (АП), адрес подсети (АПЛМ) и, возможно, наименование логического объекта сетевого уровня (НЛС).

Адресная информация имеет переменную длину. Каждый параметр адресации кодируется в соответствии с рисунком 2.

Рисунок 2 - Кодирование параметра адресации

7.3.2 Кодирование ПАИСУ (протокольной адресной информации сетевого уровня)

Адреса получателя и отправителя являются адресами ПДУСУ, определенными в ГОСТ Р ИСО 8348/Доп.2. Параметр адресации "наименование логического объекта сетевого уровня" является наименованием логического объекта сетевого уровня, определенным в ГОСТ Р ИСО 8348/Доп.2. Адрес получателя, адрес отправителя и наименование логического объекта сетевого уровня кодируется в виде ПАИСУ с использованием двоичного синтаксиса, определенного в 8.3.1 ГОСТ Р ИСО 8348/Доп.2.

7.3.3 Параметр "адрес отправителя" для ПБД ЗОС

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

Рисунок 3 - ПБД ЗОС. Параметр "адрес отправителя"

7.3.4 Параметр "наименование логического объекта сетевого уровня" для ПБД ЗПС и ПБД ПА

Параметр "наименование логического объекта сетевого уровня является наименованием логического объекта сетевого уровня промежуточной системы, передающей ПБД ЗПС или ПБД ПА. Его кодирование в ПБД показано на рисунке 4.

Рисунок 4 - ПБД ЗПС или ПБД ПА. Параметр "наименование логического объекта сетевого уровня"

7.3.5 Параметр "адрес- получателя" в ПБД ПА

Адрес получателя - это адрес ПДУСУ получателя, ассоциированного с некоторым ПБДС, который продвигается промежуточной системой, передающей ПБД ПА. Его кодирование в ПБД ПА показано на рисунке 5.

Рисунок 5 - ПБД ПА. Параметр "адрес получателя"

7.3.6 Параметр "адрес подсети" для ПБД ПА

Параметр "адрес подсети" имеется только в блоках ПБД ПА. Он используется для указания подсетевого адреса другого логического объекта сетевого уровня той же подсети, к которой относится оконечная (и промежуточная) система, являющаяся, возможно, наилучшим маршрутом к адресату, определенному параметром "адрес получателя".

Параметр "адрес получателя" кодируется в ПБД ПА так, как показано на рисунке 6.

Рисунок 6 - ПБД ПА. Параметр "адрес подсети"

7.4 Факультативная часть

7.4.1 Общие положения

Факультативная часть заголовка ПБД показана на рисунке 7.

Рисунок 7 - Все ПБД. Факультативная часть

При наличии факультативной части в ней может содержаться один или несколько параметров. Число параметров, которые могут содержаться в факультативной части, ограничено длиной этой части, а также длиной отдельных факультативных параметров. Длина факультативной части определяется по следующей формуле:

Длина заголовка ПБД = длина фиксированной части + длина части параметров адресации.

Если в принятом ПБД содержится поле параметра, для которого код параметра не указан в 7.4.2, то это поле должно игнорироваться, но остальная часть ПБД должна обрабатываться как обычно.

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

Кодирование параметров, содержащихся в факультативной части заголовка ПБД, показано на рисунке 8.

Рисунок 8 - Кодирование факультативных параметров

Поле "код параметра" представляется в двоичном коде и при отсутствии расширения обеспечивает максимум 255 различных параметров. Ни один из кодов параметра не использует биты 8 и 7 в значении 00, поэтому фактическое максимальное число параметров меньше. Код параметра 255 (двоичный 1111 1111) зарезервирован для возможных будущих расширений.

Поле "длина параметра" указывает длину (в октетах) поля "значение параметра". Эта длина указывается положительным двоичным числом и его теоретическое максимальное значение равно 254. Практическое максимальное значение ниже. Например, в случае одного параметра, содержащегося в факультативной части, для указателей кода параметра и длины параметра требуются два октета. Таким образом ограничена значением

252 - (длина фиксированной части + длина части параметров адресации).

Для каждого последующего параметра максимальное значение уменьшается.

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

7.4.2 Защита

Факультативный параметр "защита" может иметь место в ПБД ЗОС, ЗПС, ПА.

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

Этот параметр имеет то же кодовое представление и ту же семантику, что и параметр "защита" в ГОСТ Р 34.1952.

Значение параметра: см. ГОСТ Р 34.1952.

7.4.3 Обеспечение качества услуг

Факультативный параметр КУ может присутствовать только в ПБД ПА.

Параметр "качество услуг" обеспечивает информацию о качестве услуг, запрошенных в ПБД "данные", который обуславливает генерацию ПБД ПА, содержащего этот параметр.

Этот параметр имеет то же кодовое представление и ту же семантику, что и параметр "обеспечение КУ" в ГОСТ Р 34.1952.

Значение параметра: см. ГОСТ Р 34.1952.

7.4.4 Приоритет

Факультативный параметр "приоритет" может присутствовать в ПБД ЗОС, ЗПС или ПА.

В ПБД ПА параметр "приоритет" переносит информацию о приоритете, запрошенном в ПБД "данные", который обуславливает генерацию ПБД ПА, содержащего этот параметр. В ПБД ЗОС и ЗПС параметр "приоритет" сообщает о приоритете передающей системы. Этот параметр имеет то же кодовое представление и ту же семантику, что и параметр "приоритет" в ГОСТ Р 34.1952.

Значение параметра: см. ГОСТ Р 34.1952.

7.4.5 Маска адреса

Факультативный параметр "маска адреса" может присутствовать только в ПБД ПА.

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

Маска адреса устанавливает эквивалентный класс адресов ПДУСУ, для которых применима одна и та же информация переадресации. Для выяснения вопроса: совпадает или нет проверяемый адрес ПДУСУ с эквивалентным классом, ОС выравнивает проверяемый адрес ПДУСУ с маской адреса, дополняя его при необходимости концевыми нулевыми октетами. Если в битовых позициях, в которых маска адреса равна 1, проверяемый адрес ПДУСУ совпадает с полем АП блока ПБД ПА, то проверяемый адрес ПДУСУ относится к эквивалентному классу, описанному ПБД ПА. При принятии решения о маршрутизации полное совпадение адресов ПДУСУ предпочтительнее использования эквивалентных классов. Полное совпадение имеет место, когда проверяемый адрес ПДУСУ идентичен адресу, содержащемуся в поле АП блока ПБД ПА без учета какой-либо маски. Если адресаты относятся к нескольким эквивалентным классам, то выбор из них, если он необходим, является частным вопросом.

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

Примечание - Маска адреса, выбранная в соответствии с границами иерархически администрируемого адреса ПДУСУ, позволяет осуществлять маршрутизацию с помощью подсети, региона маршрутизации, либо по другому административно управляемому критерию.

Параметр "маска адреса" имеет дополнительную семантику при рассмотрении с параметром "маска ППП", см. 7.4.6.

7.4.6 Маска ППП

Факультативный параметр "маска ППП" может присутствовать только в ПБД ПА.

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

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

7.4.7 Предложенный тайм-аут конфигурации ОС

Факультативный параметр ТКОС может присутствовать только в ПБД ЗПС.

Параметр ТКОС переносит то значение, которое ПС желает предложить оконечным системам использовать в качестве их локальных тайм-аутов конфигурации.

7.5 ПБД "заявка оконечной системы" (ЗОС)

ПБД ЗОС имеет формат, представленный на рисунке 9.

Рисунок 9 - Формат ПБД ЗОС

7.6 ПБД "заявка промежуточной системы" (ЗПС)

ПБД ЗПС имеет формат, представленный на рисунке 10.

Рисунок 10 - Формат ПБД ЗПС

7.7 ПБД "переадресация" (ПА)

ПБД ПА имеет формат, представленный на рисунке 11 и 12.

Рисунок 11 - Формат ПБД ПА при выполнении переадресации к ПС

Рисунок 12 - Формат ПБД ПА при выполнении переадресации к ОС

8 СООТВЕТСТВИЕ

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

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

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

Таблица 3 - Требование к статическому соответствию

Обозначения: ИК - информация о конфигурации обеспечивается;

ИП - информация о переадресации обеспечивается;

мин - ничего не обеспечивается (минимальная реализация ОС);

О - обязательно;

Ф - факультативно;

"-" - не используется.

8.1.1 Требования к статическому соответствию для оконечных систем

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

Та реализация оконечной системы, которая обеспечивает информацию о переадресации, должна выполнять функции, отмеченные в колонке 6 таблицы 3 как обязательные (О).

Та реализация оконечной системы, которая обеспечивает оба вида информации: о конфигурации и о переадресации, должна выполнять все функции, отмеченные в колонке 5 или 6 таблицы 3 как обязательные.

Та реализация оконечной системы, которая не обеспечивает ни информацию о конфигурации, ни информацию о переадресации, должна выполнять функцию "ответ о конфигурации", отмеченную в колонке 4 таблицы 3 как обязательная.

8.1.2 Требования к статическому соответствию для промежуточных систем

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

Та реализация промежуточной системы, которая обеспечивает информацию переадресации, должна выполнять функции, отмеченные в колонке 8 таблицы 3 как обязательные.

Та реализация промежуточной системы, которая обеспечивает как информацию о конфигурации, так и информацию о переадресации, должна выполнять функции, отмеченные в колонке 7 или 8 таблицы 3 как обязательные.

8.2 Динамическое соответствие

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

Любой передаваемый ПБД должен формироваться, как указано в соответствующем подразделе раздела 7.

8.3 Заявка о соответствии реализации протоколу

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

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

ФОРМА ЗСРП

А.1 Введение

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

А.2 Сокращения и специальные символы

А.2.1 Общие сокращения и символы

А.2.2 Символы факультативных состояний и предикатов

А.3 Руководящие указания по заполнению формы ЗСРП

Основная часть каждой формы ЗСРП представляет собой вопросник фиксированного формата. Поставщик может также обеспечить или запросить обеспечение вспомогательной информации, называемой либо особой информацией, либо дополнительной информацией. Любой из этих видов вспомогательной информации должен обеспечиваться как элемент, обозначаемый соответственно О.<и> или Д.<и> в целях взаимных ссылок, где <и> - любой недвусмысленный идентификатор данного элемента (например, обычный номер); никаких других ограничений на его формат и представление не существует.

Заполненная форма ЗСРП представляет собой "заявку о соответствии реализации протоколу" относительно конкретной рассматриваемой реализации.

Ответы на вопросы должны помещаться в самой правой колонке в виде либо простой пометки ответа из ограниченного выбора (типа ДА или НЕТ), либо указанием значения, либо набора или диапазона значений.

Элементы особой информации требуют записи в вопроснике определенного ответа: они обозначаются знаком "X..." с пробелами, подлежащими заполнению. Они имеют место, например, когда ответ указывает, что возможность, относящаяся к обязательным, не реализована; элемент особой информации должен содержать соответствующее обоснование.

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

Ссылки на элементы дополнительной информации могут быть введены в вопроснике сразу после любого ответа и могут быть включены в элементы особой информации.

А.4 Форма ЗСРП

Форма ЗСРП: ГОСТ Р ИСО 9542 - оконечная система

Форма ЗСРП (продолжение): ГОСТ Р ИСО 9542 - оконечная система

Форма ЗСРП: ГОСТ Р ИСО 9542 - промежуточная система

ПРИЛОЖЕНИЕ В
(справочное)

ВСПОМОГАТЕЛЬНЫЙ ТЕХНИЧЕСКИЙ МАТЕРИАЛ

В.1 Использование тайм-аутов

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

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

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

В.1.1 Пример использования тайм-аута удержания для переадресации маршрута

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

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

В.1.2 Пример использования тайм-аута удержания для информации о конфигурации

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

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

В.2 Обновление и таймирование информации о переадресации

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

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

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

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

c) "Предыдущий шаг" принятого ПБД "данные" должен соответствовать "следующему шагу", содержащемуся в информации переадресации. В особенности, адрес-ПСТ-отправителя примитива ПСТ-БЛОК-ДАННЫХ.индикация, по которому принят ПБД, должен в точности совпадать с адресом-ПСТ-отправителя, определенным в информации переадресации, подлежащей использованию для передающего трафика через примитив ПСТ-БЛОК-ДАННЫХ.запрос. Это совпадение гарантирует, что информация переадресации будет обновляться только тогда, когда принят обратный трафик из той же ПС (или адресуемой ОС), через которую (или в которую) посылается продвигаемый трафик. Эта проверка дает уверенность, что информация переадресации обновляется не только на основе трафика, принятого от адресата. Вполне возможно, что этот трафик просто указывает о неработоспособности используемого маршрута.

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

В.3 Вопросы инициации системы

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

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

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

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

В.4 Оптимизация удаления информации о переадресации

Оконечная система будет пытаться направлять блоки ПБДС через ту промежуточную систему, к которой она была переадресована, до тех пор, пока не истечет тайм-аут удержания, определенный в поле "время удержания" ПБДТ ПА, даже в том случае, когда эта ПС становится недоступной. В некоторых случаях можно достичь лучшего и более быстро распознать существование "черной дыры". В частности, если ОС предполагает обнаружить прохождение блоков ПБД ЗПС из ПС, к которой она была переадресована, и тайм-аут удержания для данной ПС истек, то эта ОС может проигнорировать все сведения об этой ПС. Это касается информации о всех переадресациях, которая может быть удалена (см. функцию "удаление устаревшей информации о переадресации"), даже если ее тайм-ауты еще не истекли.

В.5 Пример использования маски адреса и маски ППП

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

Рисунок 13 - Пример разложения адреса на составляющие

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

Примером применения этой иерархической модели является такая сеть частного пользования, в топологию которой входят ЛВС, глобальные сети, основанные на ГОСТ Р 34.950, и двухпунктовые звенья, основанные на процедурах HDLC. На рисунке 14 промежуточные системы , , и объединяют четыре логические группы ОС (с 1-й по 4-ю). Используемый для такой топологии СЧР может иметь два иерархических уровня, которые (из-за отсутствия лучших наименований) получили название {ид.подсети, элемент}. Две маски для такого адреса ПДУСУ могут быть определены так, как показано на рисунке 15.

Рисунок 14 - Пример топологии

Рисунок 15 - Пример маски адреса и маски ППП

Пользуясь моделью, видим, что ОС в подсети 3 принимает ПБД ПА из промежуточной системы С, которая содержит адрес маски, указывающий, что все адресаты {4, i} достижимы через ПС D. Эта ОС регистрирует тот факт, что конкретный ПДУСУ достижим через ПС D, а также регистрирует маску адреса. При выдаче запроса на передачу ПБДС другому (отличному от первого) ПДУСУ-получателю ОС будет сравнивать адрес этого ПДУСУ с маской адреса. Если соответствующие биты адреса ПДУСУ-получателя равны битам записанного адреса ПДУСУ, то ОС продвигает ПБДС в ПС D. Если сравнение дает отрицательный результат (в данном ограниченном сценарии), то решение о том, куда ОС направляет данный ПБДС: в ПС С или в ПС D принимается локально; если это решение оказывается субоптимальным, то оно может быть скорректировано последующим ПБД ПА.

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

Конкретный метод странично-уровневой маршрутизации зависит от конкретной ситуации. Одним из примеров служит решение уполномоченного администратора адресации воплотить ППП в адресе ПДУСУ для большинства ОС подсети ЛВС. В этом примере эквивалентный класс указывает набор ОС той подсети, из которой использовано данное соглашение, а маска ППП указывает место ППП в адресе ПДУСУ. Другие ОС той же подсети могут администрироваться индивидуально без включения ППП в адрес ПДУСУ. Остальные ОС этой подсети могут составить отдельный эквивалентный класс, установленный по правилам другого уполномоченного администратора адресации. Другой пример касается ОС, доступных через данную сеть, и маска ППП указывает место в адресе ППП адреса Х.121 первого (или единственного) этапа в данном маршруте. Последний пример касается ОС, подключенной к набору выделенных двухпунктовых звеньев, а также к другим подсетям. Некоторые из двухпунктовых звеньев достигают оконечных систем, другие - промежуточных систем. Эквивалентный класс указывает набор тех ОС, доступ к которым обеспечивается через двухпунктовые звенья, а маска ППП указывает, где в адресе ПДУСУ находится идентификатор, из которого можно установить идентичность конкретного звена.

ПРИЛОЖЕНИЕ С
(справочное)

ТАБЛИЦЫ СОСТОЯНИЙ

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

В данном приложении протокол описан в виде таблиц состояний (таблица 7 и 8), которые показывают состояние оконечной системы и промежуточной системы, события, появляющиеся в протоколе, выполняемые действия и результирующие состояния. В таблицах 4, 5 и 6, а также в последующем описании определены понятия, используемые в самих таблицах состояний.

Таблица 4 - События

Таблица 5 - Предикаты

Таблица 6 - Специфичные действия

С.1 Состояния

Единственным состоянием, определенным в настоящем стандарте, является состояние ГОТОВНОСТЬ. Находясь в состоянии ГОТОВНОСТЬ, протокол способен выполнять любую из перечисленных в таблице 6 функций.

С.2 События

События представлены их сокращенными наименованиями, определенными в таблице 4.

Таблица 7 - Таблица состояний оконечной системы

Таблица 8 - Таблица состояний промежуточной системы

С.3 Действия и предикаты

Для каждого события таблицы определяют результирующий набор действий; эти действия представлены их сокращенными наименованиями в соответствии с таблицей 6.

Некоторые наборы действий являются условными: в таблице это указывается наличием входа в колонке предикатов. Предикаты представляют собой булевы выражения, использующие сокращенные наименования, определенные в таблице 5. Набор действий выполняется только в том случае, если соответствующий ему предикат имеет значение "истинно". Значение предиката "ложно" в таблице 8 указывает, что событие ЗК никогда не применимо к промежуточным системам.

С.4 Обозначения при адресации

В таблице 5 сокращение ПСТ-АП означает значение параметра "адрес-ПСТ-получателя" примитива ПСТ-БЛОК-ДАННЫХ.индикация, который содержит принятый ПБД "данные" в виде своего параметра "данные-пользователя-ПСТ". Точно так же в таблице 6 сокращение ПСТ-АО означает параметр "адрес-ПСТ-отправителя" соответствующего примитива ПСТ-БЛОК-ДАННЫХ.индикация. Аналогично, в таблице 6 сокращение ПСТАП означает значение параметра "адрес-ПСТ-получателя" примитива ПСТ-БЛОК-ДАННЫХ.запрос, вырабатываемого для переноса передаваемого ПБД в виде своего параметра "данные-пользователя-ПСТ".

Групповые адреса для "логических объектов сетевого уровня всех оконечных систем" и "логических объектов сетевого уровня всех промежуточных систем" пишутся сокращенно в виде "все-ОС" и "все-ПС" соответственно.

Электронный текст документа

и сверен по:

М.: Издательство стандартов, 1994