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

ГОСТ Р ИСО/МЭК ТО 10172-99

Группа П85

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


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

ПЕРЕДАЧА ДАННЫХ И ОБМЕН ИНФОРМАЦИЕЙ МЕЖДУ СИСТЕМАМИ

Спецификация взаимодействия между протоколами сетевого
и транспортного уровней

Information technology. Telecommunications and information exchange
between systems. Network/Transport Protocol interworking specification

ОКС 35.100.30
ОКСТУ 4002

Дата введения 2000-1-01*
_________________________
* Дата введения 2000-01-01
(ИУС N 6, 1999 г.). - Примечание "КОДЕКС".

Предисловие

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

ВНЕСЕН Техническим Комитетом по стандартизации ТК 22 "Информационные технологии"

2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 25 марта 1999 г. N 92

Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК ТО 10172-91 "Информационная технология. Передача данных и обмен информацией между системами. Спецификация взаимодействия между протоколами сетевого и транспортного уровней"

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

Введение

Введение

В настоящее время существуют два различных типа протоколов обмена данными на сетевом уровне в рамках взаимосвязи открытых систем (ВОС), однако системы, работающие по протоколу любого из этих типов, не могут взаимодействовать между собой. Протокол сетевого уровня в режиме с установлением соединения (ПСУ УС), ГОСТ Р ИСО/МЭК 8208 (Х.25), действующий в соответствии с ГОСТ Р 34.954, не может взаимодействовать с протоколом сетевого уровня в режиме без установления соединения (ПСУ БУС), ГОСТ Р 34.1952. Для обеспечения взаимодействия между этими двумя различными протоколами необходимо промежуточное устройство для выполнения ретрансляции и/или преобразования ПБД из одного типа протокола сетевого уровня в другой. Это устройство называется "функциональная система взаимосвязи" (ФСВ). При решении проблемы взаимодействия УС/БУС должны учитываться две достаточно общие цели:

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

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

Настоящий стандарт идентифицирует взаимодействие услуг протокола с установлением соединения и услуг протокола без установления соединения, которое основывается на трех режимах работы: режим ретрансляции на сетевом уровне (РСУ), режим пассивной ретрансляции на транспортном уровне (ПРТУ) и режим активной ретрансляции на транспортном уровне (АРТУ). Некоторые их этих режимов работы охватываются архитектурой ВОС, другие не входят в сферу этой архитектуры.

1 Назначение

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

a) определяет условия, при которых функциональные станции взаимосвязи могут использоваться для обеспечения УТУ УС ВОС между двумя ОС, когда:

- одна ОС доступна с использованием ПТУ УС, определенного в ГОСТ Р ИСО/МЭК 8073, в сочетании с протоколом, определенным в ГОСТ Р 34.1952;

- другая ОС доступна при использовании ПТУ УС, определенного в ГОСТ Р ИСО/МЭК 8073, в сочетании с процедурами, определенными в ГОСТ Р 34.950/ГОСТ 34.954*;

_______________

* Для краткости написание ГОСТ Р 34.950/ГОСТ 34.954 будет означать протокол по ГОСТ Р 34.950, действующий в соответствии с ГОСТ 34.954.

b) определяет различные наборы процедур для работы таких ФСВ;

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

d) определяет требования к последовательной и/или параллельной работе ФСВ.

Примечание - Только ретрансляционный режим работы на сетевом уровне (РСУ) относится к области ВОС. Режимы работы активной ретрансляции на транспортном уровне (АРТУ) и пассивной ретрансляции на транспортном уровне (ПРТУ) не рассматриваются как операции ВОС, поскольку ГОСТ 28906 не определяет ретрансляцию как функцию транспортного уровня.


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

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

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

ГОСТ 34.954-91 (ИСО 8878-87) Информационная технология. Взаимосвязь открытых систем. Использование протокола пакетного уровня X.25 для обеспечения услуг сетевого уровня ВОС в режиме с установлением соединения

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

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

ГОСТ Р 34.951-92 (ИСО 8348-87, ИСО 8348 с Доп. 1-87) Информационная технология. Передача данных. Определение услуг сетевого уровня

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

ГОСТ Р ИСО/МЭК 8072-96 Информационная технология. Взаимосвязь открытых систем. Определение услуг транспортного уровня

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

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

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

ГОСТ Р ИСО 8881-98* Информационная технология. Передача данных. Использование протокола пакетного уровня Х.25 в локальных вычислительных сетях
________________
* Вероятно ошибка оригинала. Следует читать ГОСТ Р ИСО/МЭК 8881-98 Информационная технология. Передача данных. Использование протокола пакетного уровня Х.25 в локальных вычислительных сетях. - Примечание "КОДЕКС".

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

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

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

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

ИСО 7498-3-86* Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 3. Присвоение имен и адресация**

_______________

* Оригиналы и проекты ИСО/МЭК - во ВНИИКИ Госстандарта России.

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

_______________

* Оригиналы и проекты ИСО/МЭК - во ВНИИКИ Госстандарта России.

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

_______________

* Оригиналы и проекты ИСО/МЭК - во ВНИИКИ Госстандарта России.

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

_______________

* Оригиналы и проекты ИСО/МЭК - во ВНИИКИ Госстандарта России.

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

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

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

маршрутизация;

наименование;

(N)-ypовень;

(N)-пункт доступа к услугам;

(N)-aдpec;

(N)-ретрансляция;

(N)-протокольный блок данных;

(N)-интерфейсный блок данных.

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

Настоящий стандарт использует следующие понятия из ГОСТ Р ИСО 8648:

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

протокол сходимости, не зависимый от подсети.

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

Настоящий стандарт использует следующие определения.

3.3.1 Оконечная система - система, в которой существует логический объект транспортного уровня, предоставляющий при обмене данными услуги для логического объекта сеансового уровня.

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

3.3.2 Адрес (N)-ПДУС; (N)-адрес

Примечание - Термины "адрес (N)-ПДУС" и "(N)-aдpec" используются здесь, как и в большинстве стандартов по транспортному уровню, как синонимы.

4 Символы и сокращения

5 Общее описание функциональной станции взаимосвязи

5.1 Применимость ФСВ

ФСВ применяется только при некоторых ограниченных условиях, когда для взаимосвязи двух несовместимых ОС необходимо взаимодействие УС/БУС. Любое другое использование ФСВ не входит в предмет рассмотрения настоящего стандарта. Ограничивающие условия для требований к ФСВ определены в разделе 7.

5.2 Режимы работы ФСВ

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

а) Активная ретрансляция на транспортном уровне (АРТУ)

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

Рисунок 1 - Пример конфигурации активной ретрансляции на транспортном уровне

_____________
* Необычное очертание функции ретрансляции должно привлечь внимание к различиям между функциями АРТУ и ПРТУ

Рисунок 1 - Пример конфигурации активной ретрансляции на транспортном уровне

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

b) Пассивная ретрансляция на транспортном уровне (ПРТУ)

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

Рисунок 2 - Пример конфигурации пассивной ретрансляции на транспортном уровне

________________
* Необычное очертание функции ретрансляции должно привлечь внимание к различиям между функциями АРТУ и ПРТУ

Рисунок 2 - Пример конфигурации пассивной ретрансляции на транспортном уровне

c) Ретрансляция на сетевом уровне (РСУ)

В этом режиме ФСВ действует как типичная промежуточная система (ПС).

Действия РСУ в режиме без установления соединения (БУС) должны соответствовать ГОСТ Р 34.1952.

Действия РСУ в режиме с установлением соединения (УС) должны соответствовать ГОСТ Р ИСО 10177* (в сочетании с ГОСТ Р ИСО/МЭК 10028) либо ИСО ТО 10029, обеспечивающему все услуги ГОСТ Р 34.950, необходимые для обеспечения услуг сетевого уровня в режиме с установлением соединения.
________________
* Вероятно ошибка оригинала. Слудует читать ГОСТ Р ИСО/МЭК 10177. - Примечание "КОДЕКС".

Оконечные системы, которые нуждаются во взаимосвязи через ФСВ, идентифицируют друг для друга пункты доступа к услугам сетевого уровня (ПДУСУ) и пункты доступа к услугам транспортного уровня (ПДУТУ) с помощью их адресации на транспортном и сетевом уровнях точно так же, как если бы они были соединены через ретрансляционную систему сетевого уровня. Следовательно, ФСВ на рисунках 1 и 2 выполняют протоколы ГОСТ Р ИСО/МЭК 8073 и ГОСТ 34.954 так, как если бы адреса транспортного и сетевого уровней системы В были расположены в пунктах доступа к услугам в ФСВ. Точно так же протоколы ГОСТ Р ИСО/МЭК 8073 и ГОСТ Р 34.1952 действуют так, как если бы адреса транспортного и сетевого уровней системы А были расположены в ФСВ в пунктах доступа к услугам.

5.3 Выбор режима работы

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

В общем случае при получении ПБДС ФСВ может не знать заранее, является ли адресуемый ПДУСУ оконечной системой, обеспечивающей режимы работы с установлением соединения или без установления соединения, и какие классы протокола транспортного уровня обеспечиваются во втором случае. Если ФСВ обеспечивает несколько режимов работы, она может оценить, какие из них следует использовать посредством процедур, определенных в разделе 10, включая использование идентификации протокола (ГОСТ Р ИСО/МЭК ТО 9577) и согласование классов протокола транспортного уровня.

5.4 Обеспечение услуг транспортного уровня

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

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

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

5.5 Использование адресов на сетевом уровне

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

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

a) Во всех случаях, когда ОС будет требовать использования локального адреса сетевого уровня, т.е. адреса, присвоенного ПДУСУ в самой этой системе, измененные с учетом наличия ФСВ требования состоят в том, что ФСВ оперирует с адресами так, как если бы она была ретранслятором сетевого уровня, несмотря на наличие логического объекта транспортного уровня. Эти действия определены в 5.5.1.

b) В случаях, когда ОС потребуется использовать адрес сетевого уровня, который назначен не данной, а другой системе (например, системе, с которой она взаимодействует), то эти требования применимы к ФСВ без изменений.

5.5.1 Локальные адреса на сетевом уровне

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

5.5.2 Использование адресов ПДУСУ по ГОСТ Р 34.950 и ГОСТ Р 34.1952

Когда ФСВ передает пакет "вызов принят" в соответствии с ГОСТ Р 34.950, она передает адрес вызываемого на сетевом уровне, принимаемый в соответствующем пакете "входящий вызов" (ГОСТ Р 34.950) как адрес отвечающего.

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

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

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

6.1 Статические требования соответствия

ФСВ, для которой заявлено соответствие положениям настоящего стандарта, должна реализовать обязательную функцию АРТУ, определенную в 8.2.1, 8.3.1, 8.4.1, 8.5.1 и 8.9.1.

6.2 Динамические требования соответствия

Все обеспечиваемые функции должны реализовываться в соответствии с разделом 8 для режима работы АРТУ. Факультативный режим работы ПРТУ, если он реализован, должен соответствовать разделу 9. Все ФСВ должны работать с адресами ПДУСУ в соответствии с 5.5.

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

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

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

7 Требования функциональной среды к использованию ФСВ

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

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

7.1 Требования топологии и маршрутизации

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

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

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

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

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

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

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

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


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

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

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

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

Примечание - Поскольку ФСВ может также работать как ПС в режиме РСУ, то настоящий стандарт не запрещает участия ФСВ в выполнении функций ПС, таких как части промежуточной системы по ГОСТ Р ИСО/МЭК 9542* или протоколы маршрутизации ПС-ПС.
________________
* Вероятно ошибка оригинала. Следует читать ГОСТ Р ИСО 9542. - Примечание "КОДЕКС".

8 Операции активного ретранслятора на транспортном уровне

8.1 Концептуальная структура активного ретранслятора на транспортном уровне

В целях простоты описания АРТУ рассматривается как состоящий из следующих частей:

- часть "режим с установлением соединения на транспортном уровне" (ЧТУ УС), действующая как протокол транспортного уровня в режиме с установлением соединения (ГОСТ Р ИСО/МЭК 8073) в соответствии с 8.4;

- часть "режим без установления соединения на транспортном уровне" (ЧТУ БУС), действующая как протокол транспортного уровня в режиме с установлением соединения (ГОСТ Р ИСО/МЭК 8073) в соответствии с 8.5;

- часть "сеть Х.25", действующая в соответствии с 8.2 с использованием ГОСТ Р 34.950/ГОСТ 34.954 (Х.25);

- часть "режим без установления соединения на сетевом уровне", действующая в соответствии с 8.3 с использованием протокола, определенного в ГОСТ Р 34.1952;

- часть "ретрансляция на транспортном уровне", которая стыкует обычные соединения транспортного уровня с соединениями транспортного уровня класса 4 режима УС/БУС по ГОСТ Р ИСО/МЭК 8073.

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

8.2 Функция части "сеть Х.25" (ГОСТ Р 34.950)

8.2.1 Обязательные функции

Часть "сеть Х.25" должна выполнять протокол пакетного уровня Х.25 по ГОСТ Р 34.950 в соответствии с положениями ГОСТ 34.954 и с учетом модификации, определенных в 5.5 и касающихся использования адресов сетевого уровня.

Настоящий стандарт не налагает никаких ограничений на использование других процедур, применимых в сочетании с ГОСТ 34.954 в таких конкретных конфигурациях, как ГОСТ Р ИСО/МЭК 9574 и ГОСТ Р ИСО 8881*.
________________
* Вероятно ошибка оригинала. Следует читать ГОСТ Р ИСО/МЭК 8881-98. - Примечание "КОДЕКС".

8.2.2 Факультативный протокол маршрутизации

Часть "сеть Х.25" может также факультативно обеспечивать протокол маршрутизации, определенный в ГОСТ Р ИСО/МЭК 10030, при следующем ограничении: поскольку ПДУСУ, по поручению которых ФСВ выполняет ретрансляцию, отсутствуют в ФСВ, то она не должна выполнять функцию "уведомление о конфигурации" несмотря на то, что она использует эти адреса ПДУСУ для выполнения ГОСТ Р 34.954 в соответствии с 5.5.

8.3 Функция части "режим без установления соединения на сетевом уровне" (ГОСТ Р 34.1952)

8.3.1 Обязательные функции

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

8.3.2 Операции факультативного протокола маршрутизации

8.3.2.1 ФСВ, выполняющая функции оконечной системы

Часть "режим без установления соединения на сетевом уровне" может также факультативно выполнять протокол маршрутизации, определенный в ГОСТ Р ИСО/МЭК 9542*, при следующем ограничении: поскольку ПДУСУ, по поручению которых ФСВ выполняет ретрансляцию, отсутствуют в ФСВ, то она не должна передавать ПБД "заявка оконечной системы" в функциях "ответ на конфигурацию" и "отчет о конфигурации", даже если она использует в действиях ГОСТ Р 34.1952 адреса ПДУСУ в соответствии с 5.5.
________________
* Вероятно ошибка оригинала. Следует читать ГОСТ Р ИСО 9542. - Примечание "КОДЕКС".

В этом случае протокол ГОСТ Р ИСО/МЭК 9542 используется ФСВ только для получения информации о наличии и достижимости ОС и ПС в подсетях, к которым она непосредственно подсоединена. Наличие и достижимость ФСВ не могут обнаруживаться динамически путем использования ГОСТ Р ИСО/МЭК 9542*.
________________
* Вероятно ошибка оригинала. Следует читать ГОСТ Р ИСО 9542. - Примечание "КОДЕКС".

8.3.2.2 ФСВ, выполняющая функции промежуточной системы

Если ФСВ выполняет ретрансляционную функцию сетевого уровня в режиме без установления соединения, она может выполнять функции ПС по ГОСТ Р ИСО/МЭК 9542* и действовать так, как если бы часть РСУ (БУС) обеспечивала доступ к ПДУСУ, по поручению которых ФСВ выполняет ретрансляцию путем использования функции ретранслятора транспортного уровня.
________________
* Вероятно ошибка оригинала. Следует читать ГОСТ Р ИСО 9542. - Примечание "КОДЕКС".

В этом случае наличие и доступность ФСВ могут быть обнаружены динамически путем использования ГОСТ Р ИСО/МЭК 9542*.
________________
* Вероятно ошибка оригинала. Следует читать ГОСТ Р ИСО 9542. - Примечание "КОДЕКС".

8.4 Функция ЧТУ УС

8.4.1 Обязательные функции

Часть "режим с установлением соединения на транспортном уровне" должна выполнять протокол транспортного уровня в режиме с установлением соединения в соответствии с ГОСТ Р ИСО/МЭК 8073 с учетом уточнений по 5.5, 8.6-8.8 настоящего стандарта. Часть "ретрансляция на транспортном уровне" должна выполнять роль пользователя услуг, которые обеспечиваются ГОСТ Р ИСО/МЭК 8073 и относятся к услугам, определенным в ГОСТ Р ИСО/МЭК 8072 и модифицированным в 5.5, 8.6-8.8 настоящего стандарта.

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

8.4.2 Рекомендуемое использование времени подтверждения в классе 4

Если ЧТУ УС работает с классом 4 протокола транспортного уровня, рекомендуется, чтобы она использовала параметр времени подтверждения, определенный в 8.10.

8.4.3 Факультативное использование ПУССУ

ПУССУ функционирует в соответствии с ГОСТ Р ИСО/МЭК 8073, т.е. его использование либо оконечной системой, либо ФСВ факультативно. Поскольку ПУССУ не может использоваться через УСУ БУС, то его действие не поддерживается в течение всего времени существования СТУ.

8.5 Функция ЧТУ БУС

8.5.1 Обязательные функции

ЧТУ БУС должны работать с протоколом транспортного уровня в режиме с установлением соединения, определенного ГОСТ Р ИСО/МЭК 8073 и модифицированного в 5.5, 8.6-8.8 настоящего стандарта. Часть "ретрансляция на транспортном уровне" должна выполнять роль пользователя услуг, определенных в ГОСТ Р ИСО/МЭК 8073, которые должны представлять собой услуги по ГОСТ Р ИСО/МЭК 8072, модифицированные в 5.5, 8.6-8.8 настоящего стандарта.

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

8.5.2 Рекомендуемое использование времени подтверждения

Рекомендуется, чтобы ЧТУ БУС использовала параметр времени подтверждения, определенный в 8.10.

8.6 Обработка модифицированного КУ

В данном подразделе определяется способ, с помощью которого обработка КУ в ЧТУ УС и ЧТУ БУС отличается от способа, определенного ГОСТ Р ИСО/МЭК 8072 и ГОСТ Р ИСО/МЭК 8073.

ЧТУ УС и ЧТУ БУС должны извлекать из входящих ПБДТ ЗС и ПБДТ ПС следующие параметры, при их наличии:

- коэффициент необнаруженных ошибок,

- транзитная задержка.

Значения каждого их этих параметров или уведомления об их отсутствии должны сообщаться части "ретрансляция на транспортном уровне" при передаче примитива Т-СОЕДИНЕНИЕ индикация или Т-СОЕДИНЕНИЕ подтверждение, в дополнение к параметрам, определенным для этих примитивов в ГОСТ Р ИСО/МЭК 8072.

В примитивах Т-СОЕДИНЕНИЕ запрос и Т-СОЕДИНЕНИЕ ответ также должны использоваться те же параметры (или уведомления о том, что они не обеспечиваются). ЧТУ УС и ЧТУ БУС должны вводить обеспечиваемые параметры в ПБДТ ПС или ПБДТ ЗС, передаваемых в виде последовательности примитивов Т-СОЕДИНЕНИЕ запрос или ответ, за исключением случая, когда используется класс 0 протокола транспортного уровня.

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

8.7 Дополнительные функции разъединения

В данном подразделе определяется способ, с помощью которого можно отличить функции разъединения СТУ в ЧТУ УС и ЧТУ БУС от соответствующих операций, определенных ГОСТ Р ИСО/МЭК 8072 и ГОСТ Р ИСО/МЭК 8073. В нем определяются дополнительные функциональные возможности ЧТУ УС и ЧТУ БУС, которые необходимы для сохранения межконцевых семантик параметра "причина" в примитиве Т-СОЕДИНЕНИЕ индикация.

В ГОСТ Р ИСО/МЭК 8072 определено, что примитив Т-РАЗЪЕДИНЕНИЕ индикация содержит код причины, указывающий инициатора разъединения соединения - либо удаленного пользователя УТУ, либо поставщика.

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


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

ЧТУ УС и ЧТУ БУС должны принимать вместе с примитивом С-РАЗЪЕДИНЕНИЕ запрос дополнительную информацию из частей "ретрансляция на транспортном уровне", определяющих причину. Этой причиной должно быть либо "по инициативе поставщика", либо "по инициативе пользователя", и в первом случае она может иметь временный или постоянный характер. Если указана причина "по инициативе пользователя", то ЧТУ УС и ЧТУ БУС должны обрабатывать примитив Т-РАЗЪЕДИНЕНИЕ запрос как обычно - согласно процедурам при отклонении соединения или обычном разъединении, определенном в ГОСТ Р ИСО/МЭК 8073.

Если причиной является "по инициативе поставщика", ЧТУ УС и ЧТУ БУС должны выполнять процедуры отклонения разъединения соединения со следующим исключением.

Во всех случаях, когда процедура, определенная в ГОСТ Р ИСО/МЭК 8073, требует передачи ПБДТ ЗР, поле "причина" ПБДТ не должно устанавливаться в значение 128+0, как было бы в обычной ситуации при обработке примитива Т-РАЗЪЕДИНЕНИЕ запрос. Вместо этого должно использоваться другое значение. Этим значением может быть 2, если указываемая причина имеет постоянный характер, или 0, если причина имеет временный характер. Как вариант, это значение может иметь в основном информационное значение, которое сохраняет значимость постоянное/временное и которое выбрано из значений, допустимых по ГОСТ Р ИСО/МЭК 8073 на основе локальных сведений, полученных в процессе внутренних взаимодействий с другими частями ФСВ.

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

8.8 Использование значений идентификатора ПДУТУ

В данном подразделе определяется, каким образом использование и значимость параметров идентификатора (ИД) ПДУТУ, определенных для оконечных систем в ГОСТ Р ИСО/МЭК 8073 в сочетании с ГОСТ Р ИСО/МЭК 8072, изменяются при их использовании в ФСВ.

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

8.9 Функция преобразования СТУ

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

Дополнительная информация о локальной координации действий в АРТУ приведена в приложении А.

8.9.1 Обязательные функции

ПБДТ ЗС, поступающий через ЧТУ БУС, доставляется (в зависимости от ограничений ресурсов и от приемлемости, а также от способности обеспечивать соответствующее КУ) в виде примитива Т-СОЕДИНЕНИЕ индикация в ретранслятор транспортного уровня. В результате ретранслятор на транспортном уровне преобразуется в соответствующий примитив Т-СОЕДИНЕНИЕ запрос, поступающий в ЧТУ УС со всеми теми же параметрами, что и в примитиве Т-СОЕДИНЕНИЕ индикация.

Параметры "адрес вызываемого" и "адрес вызывающего" определяют ИД ПДУТУ, который использует ЧТУ УС, и адрес ПДУСУ, который ЧТУ УС определяет для части "сеть Х.25".

Если это соединение, проходящее через ЧТУ УС, принято, ЧТУ УС доставляет примитив Т-СОЕДИНЕНИЕ подтверждение ретранслятору на транспортном уровне, который преобразует его в соответствующий примитив Т-СОЕДИНЕНИЕ ответ, поступающий в ЧТУ БУС со всеми теми же параметрами, что и в примитиве Т-СОЕДИНЕНИЕ подтверждение.

Аналогично устанавливаются соединения в обратном направлении, когда первоначальный примитив Т-СОЕДИНЕНИЕ индикация принимается из ЧТУ УС, а ретранслятор на транспортном уровне инициирует затем установление соединения через ЧТУ БУС и в конечном счете выдает в ЧТУ УС примитив Т-СОЕДИНЕНИЕ ответ.

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

Если ретранслятор на транспортном уровне принимает из ЧТУ УС или ЧТУ БУС примитив Т-РАЗЪЕДИНЕНИЕ индикация, он преобразует его в примитив Т-РАЗЪЕДИНЕНИЕ запрос по соответствующему СТУ к другой части. В этом примитиве Т-РАЗЪЕДИНЕНИЕ запрос введена дополнительная информация, определенная в 8.10, для указания причины "по инициативе пользователя" или "по инициативе поставщика" как временное или постоянное условие согласно значению параметра "причина" примитива Т-РАЗЪЕДИНЕНИЕ индикация. Данные пользователя, определенные в примитиве Т-РАЗЪЕДИНЕНИЕ запрос, такие же, как и в примитиве Т-РАЗЪЕДИНЕНИЕ индикация.

Как отмечено в ГОСТ Р ИСО/МЭК 8072, локальный механизм используется для того, чтобы можно было отличать различные СТУ в ПДУТУ. Локальным является также вопрос, какой механизм используется для этой цели ЧТУ УС: такой же, как и используемый ЧТУ БУС, либо ретранслятор на транспортном уровне обеспечивает регистрацию, чтобы позволить ему правильно определять, какие СТУ преобразованы друг в друга.

Как уже отмечалось в этом разделе, все те аспекты СТУ, межконцевая значимость которых должна сохраняться, проходят через ретрансляцию на транспортном уровне. Но поскольку разбиение ФСВ на части является только описательным методом, то при практической реализации ЧТУ УС и ЧТУ БУС могут хорошо использовать локальные сведения о действиях других частей.

8.10 Рекомендуемое использование времени подтверждения в классе 4

Если ЧТУ УС или ЧТУ БУС используют протокол транспортного уровня класса 4, то рекомендуется передавать максимальное время подтверждения в параметре "время подтверждения" ПБДТ ЗС и ПБДТ ПС, определяющем наибольшее время подтверждения, приемлемое после завершения процесса установления соединения.

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

8.11 Длина ПБДТ

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

9 Операции пассивной ретрансляции на транспортном уровне

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

9.1 Концептуальная структура пассивной ретрансляции на транспортном уровне

В целях описания действия ПРТУ рассматриваются состоящими из следующих частей:

a) часть "сеть Х.25", которая работает в соответствии с 9.2, используя ГОСТ Р 34.950/ГОСТ 34.954;

b) часть "режим без установления соединения сетевого уровня", которая работает в соответствии с 9.3, используя протокол, определенный в ГОСТ Р 34.1952;

c) часть "ретрансляция на транспортном уровне", которая осуществляет преобразования ПБДТ, передаваемых через часть "режим без установления соединения на сетевом уровне".

9.2 Функции части "сеть Х.25"

9.2.1 Обязательные функции

Часть "сеть Х.25" должна работать по протоколу пакетного уровня (Х.25) ГОСТ Р 34.950 с соблюдением положений ГОСТ 34.954 и с учетом изменений, определенных в 5.5, 9.4 и 9.5 настоящего стандарта. Часть "ретрансляция на транспортном уровне" должна представлять собой пользователя услуг, обеспечиваемых частью "сеть Х.25", которая должна представлять собой услуги режима с установлением соединения, определенные в ГОСТ Р 34.951 и смодифицированные по 5.5 настоящего стандарта. Настоящий стандарт не налагает никаких ограничений на использование других процедур, применимых в сочетании с ГОСТ 34.954 в конкретных конфигурациях, как, например, определенных ГОСТ Р ИСО 8881* и ГОСТ Р ИСО/МЭК 9574.
________________
* Вероятно ошибка оригинала. Следует читать ГОСТ Р ИСО/МЭК 8881-98. - Примечание "КОДЕКС".

9.2.2 Факультативный протокол маршрутизации

Часть "сеть Х.25" может также факультативно реализовывать протокол маршрутизации, определенный в ГОСТ Р ИСО/МЭК 10030 при наличии следующих ограничений:

- поскольку ПДУСУ, по поручению которых ФСВ выполняет ретрансляцию, отсутствуют в ФСВ, она не должна выполнять функцию "уведомление о конфигурации", несмотря на то, что она использует эти адреса ПДУСУ для работы по ГОСТ 34.954, как описано в 5.5.

9.3 Функция части "режим без установления соединения на сетевом уровне"

9.3.1 Обязательные функции

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

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

9.3.2 Факультативные операции протокола маршрутизации

9.3.2.1 ФСВ, работающая в качестве оконечной системы

Часть "режим без установления соединения сетевого уровня" может также факультативно выполнять протокол маршрутизации, определенный в ГОСТ Р ИСО/МЭК 9542* с учетом следующего ограничения: поскольку ПДУСУ, по поручению которых ФСВ выполняет ретрансляцию, отсутствуют в ФСВ, она не должна передавать ПБД "заявка оконечной системы" в функциях ГОСТ Р ИСО/МЭК 9542* "ответ на конфигурацию" и " отчет о конфигурации", даже если она использует адреса ПДУСУ для действий по ГОСТ Р 34.1952, как определено в 5.5.
________________
* Вероятно ошибка оригинала. Следует читать ГОСТ Р ИСО 9542. - Примечание "КОДЕКС".

В этом случае ГОСТ Р ИСО/МЭК 9542* используются ФСВ только для получения информации о наличии и доступности ОС и ПС в подсетях, к которым они непосредственно подсоединены. Наличие и доступность ФСВ не могут быть обнаружены динамически путем использования ГОСТ Р ИСО/МЭК 9542*.
________________
* Вероятно ошибка оригинала. Следует читать ГОСТ Р ИСО 9542. - Примечание "КОДЕКС".

9.3.2.2 ФСВ, работающая в качестве промежуточной системы

Если ФСВ содержит часть "ретрансляция на сетевом уровне в режиме без установления соединения", она может выполнять функции промежуточных систем ГОСТ Р ИСО/МЭК 9542* и действовать так, как если бы часть (РСУ) БУС обеспечивала доступ к тем ПДУСУ, по поручению которых ФСВ выполняет ретрансляцию путем использования функции "ретрансляция на транспортном уровне".
________________
* Вероятно ошибка оригинала. Следует читать ГОСТ Р ИСО 9542. - Примечание "КОДЕКС".

В этом случае наличие и доступность ФСВ можно определять динамически с помощью протокола по ГОСТ Р ИСО/МЭК 9542*.
________________
* Вероятно ошибка оригинала. Следует читать ГОСТ Р ИСО 9542. - Примечание "КОДЕКС".

9.4 Модифицированное согласование КУ

В этом подразделе определяется способ, с помощью которого согласование КУ сетевой части протокола Х.25 можно отличить от согласования КУ, определенного в ГОСТ 34.954 для ОС.

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

a) транзитной задержки, свойственной сетевой части Х.25;

b) транзитной задержки, свойственной ретрансляционной части транспортного уровня;

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

9.5 Обработка расширенного времени существования

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

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

9.6 Функции ретрансляционной части транспортного уровня

9.6.1 Обязательные функции

9.6.1.1 Входящие запросы соединения Х.25

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

9.6.1.2. Инициализация соединения Х.25

При необходимости ПРТУ может инициировать новое соединение с сетевой частью Х.25 с помощью примитива С-СОЕДИНЕНИЕ запрос в соответствии с процедурами, определенными в остальной части подраздела 9.6 для продвижения ПБДТ к оконечной системе режима с установлением соединения, если

a) не существует соединения Х.25, для которого уже существует или может быть присвоено соответствующее СТУ, или

b) необходимо использовать новое соединение Х.25 для поддержания согласованного КУ транспортного уровня.

9.6.1.3 Обработка СБДС

При получении СБДС ПРТУ должен в соответствии с ГОСТ Р ИСО/МЭК 8073 выполнить функции "разделения" и "логической увязки ПБДТ с СТУ" и проверку контрольной суммы. Затем он должен обработать образованный ПБДТ в соответствии с изложенным ниже.

9.6.1.4 Обработка ПБДТ ЗС

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

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

b) Запрошенное КУ может быть изменено, но так, чтобы оно не превышало значений, которые могут обеспечить функции ПРТУ.

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

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

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

9.6.1.5 Обработка ПБДТ ПС

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

9.6.1.6 Обработка других ПБДТ

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

9.7 Совместное использование режимов работы ПРТУ и АРТУ парой сетевых адресов

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

В этом случае входящие СБДС могут содержать смесь ПБДТ для обоих режимов. Следовательно, процедуры ГОСТ Р ИСО/МЭК 8073 по отключению и логической привязке ССУ к СТУ и процедуры проверки контрольной суммы, выполняемые в обоих режимах, в данном случае выполняются для каждого ПБДТ до определения применимого режима, который определяет необходимую обработку.

ФСВ, которая готова для работы в любом режиме между заданной парой адресов сетевого уровня, может динамически определить, какой режим необходимо использовать для каждого СТУ; в разделе 10 изложен метод выбора наиболее подходящего режима для каждого конкретного случая. В данном случае согласование КУ сетевого и транспортного уровней может осуществляться частично или полностью до определения возможного режима работы. Эти согласования необходимо выполнять в соответствии с положениями подразделов 9.4 и 9.6 с тем, чтобы выбранный режим работы ПРТУ мог применяться корректно. В случае, когда принято решение использовать режим АРТУ, может оказаться, что выбранное КУ отличается от значений КУ, которые могли бы потребоваться, если бы с самого начала выполнялись процедуры АРТУ.

9.8 Использование

ПУССУ функционирует в соответствии с ГОСТ Р ИСО/МЭК 8073, т.е. его использование со стороны ОС и ФСВ факультативно. Поскольку ПУССУ не может применяться при использовании УСУ БУС, его функционирование не поддерживается по всему СТУ.

10 Выбор режима работы ФСВ

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

10.1 Выбор режима для поступающих ПБД протокола по ГОСТ Р 34.1952

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

Шаг 1

Шаг 1 относится только к тем ФСВ, которые выполняют функцию ретрансляции УСУ БУС.

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

b) Если неизвестно о наличии доступного маршрута с использованием УСУ БУС, но известен адресуемый ППП, с которым может быть установлено соединение Х.25, ФСВ может попытаться определить, можно ли использовать ретранслирующие УСУ БУС путем установления виртуальных каналов согласно ГОСТ Р 34.1952. В случае положительного ответа ретрансляция может осуществляться одним из методов, определенных в 5.2с.

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


Шаг 2

Если шаг 1 опускается или не проводит в результате к операциям ретрансляции УСУ БУС, используется шаг 2 при условии, что ФСВ готова выполнять функции как АРТУ, так и ПРТУ для пары ПДП. (В противном случае следует перейти на выполнение функции АРТУ).

а) ФСВ должна действовать по протоколу ГОСТ Р 34.1952 так, как если бы получатель входящего ПБД был достижим. Как только будет сформирован полный СБДС, она должна использовать функцию логической увязки ПБДТ с СТУ согласно ГОСТ Р ИСО/МЭК 8073.

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

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

с) В случае принятия соединения и если согласованный класс протокола транспортного уровня не является классом 4, ФСВ должна продолжить выполнение функций АРТУ. В противном случае она может перейти на функцию ПРТУ на оставшееся время существования соединения.

10.2 Выбор режима для входящего ССУ

Эта функция может выполняться ФСВ, которая воспринимает попытку установления ССУ.

Шаг 1

Шаг 1 относится только к тем ФСВ, которые выполняют ретрансляционную функцию УСУ УС.

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

b) Если не известно наличие доступного маршрута, использующего УСУ УС, но имеется ПДП адресата, с которым может быть установлено соединение Х.25, ФСВ может попытаться определить возможность его использования для ретрансляции УСУ УС путем установки виртуального канала по одному из методов, определенных в 5.2с. При успешном установлении соединения может осуществляться ретрансляция без изменения типа услуг.

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


Шаг 2

Если шаг 1 не выполняется или его выполнение не приводит к выполнению функции ретрансляции в режиме с установлением соединения, следует переход к шагу 2 при условии, что ФСВ подготовлена для выполнения функций как АРТУ, так и ПРТУ для пары ПДУС (в противном случае она должна продолжать выполнение функции АРТУ).

a) ФСВ должна воспринимать соединение так, как если бы она собиралась использовать режим ПРТУ (см. 9.6.1.1), и продолжать работу в соответствии с ГОСТ 34.954. Если СБДС получен по соединению, ФСВ должна применить функцию логической привязки ПДБС с СТУ, как определено в ГОСТ Р ИСО/МЭК 8073. Те ПБДС, которые создают ассоциацию с существующим СТУ, должны рассматриваться в соответствии с процедурой АРТУ или ПРТУ, применяемой к данному соединению.

b) При появлении ПБДТ ЗС, для которого должно быть создано новое СТУ и запрошенный класс протокола транспортного уровня не является классом 4, ФСВ должна продолжать обработку нового СТУ в режиме АРТУ. Если запрошенным классом является класс 4, ФСВ может либо немедленно выбрать режим работы - АРТУ или ПРТУ, либо вначале действовать в режиме АРТУ и затем решить, следует ли ей перейти в режим ПРТУ при получении ПБДТ ПС.

ПРИЛОЖЕНИЕ А (обязательное). Форма "заявки о соответствии реализации протоколу"

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

А.1 Введение

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

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

Н/И - не используется

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

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

Х - запрещено

n - статус соответствует этому символу только в том случае, если обеспечивается позиция "n" данной ЗСРП

А.3 Инструкции по заполнению формы ЗСРП

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

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

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

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

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

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

ПРИЛОЖЕНИЕ В (справочное). Локальная координация между СТУ в режиме АРТУ

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

B.1 Общее применение локальной координации

Как отмечалось в разделе 8, функции, обслуживающие СТУ по протоколу ГОСТ Р 34.950/ГОСТ Р 34.951 в режиме АРТУ, могут обладать локальными сведениями о работе соответствующих СТУ по протоколу ГОСТ Р 34.1952 и наоборот. Таким образом те операции, выполнение которых является частным вопросом реализации протокола транспортного уровня и на которые положения раздела 8 не налагают ограничений, например, объем предоставляемого кредита, размер ПБДТ и др., могут при необходимости быть скоординированы между двумя СТУ. Например, кредит, предоставляемый для одного СТУ, может поддерживаться равным кредиту, доступному удаленной ОС в другом СТУ, где может обеспечиваться упрощенное управление буферами в режиме АРТУ (оно может выглядеть как межконцевое управление потоком). Как одна из крайностей, продвигаемые СБДТ можно так тесно скоординировать, что данные в каждом поступающем ПБДТ будут обрабатываться и продвигаться как единое целое, не дожидаясь поступления оставшихся ПБДТ. Если указатели скоординированы и оба СТУ используют класс 4, может оказаться возможным исключить повторное использование контрольной суммы. (На метод, используемый для определения контрольной суммы, никаких ограничений со стороны протокола по ГОСТ Р ИСО/МЭК 8073 не налагается, и в этом случае ее можно определить, запомнив контрольную сумму, применимую к содержимому данного конкретного ПБДТ, исходя из того момента, когда она была обнаружена правильной в поступающем ПБДТ в другой части системы).

Следует, однако, подчеркнуть, что такая координация возможна только в пределах той степени локальной свободы, которая допускается спецификацией протокола транспортного уровня. Например, если было решено скоординировать подтверждения так, чтобы они передавались по одному СТУ только тогда, когда подтвержденные данные уже продвинуты к удаленной ОС и подтверждены ею по другому СТУ, то это может быть ограничено в классе 4 требованием оставаться в пределах локального времени подтверждения. (Было бы, разумеется, хорошо, если бы значение локального времени подтверждения было определено с учетом предполагаемой работы по этому методу и возможной задержки, но, тем не менее, в случае запоздалого поступления подтверждения ПТБ БУС или ПТУС, реализующий класс 4 может оказаться вынужден требованиями ГОСТ Р ИСО/МЭК 8073 передавать подтверждения независимо от этого).

В.2 Использование причин разъединения

Как отмечалось в разделе 8, ситуацией, когда локальная координация соединений в АРТУ может оказаться особенно полезной, является использование параметра "причина" разъединения СТУ.

При наличии достаточного количества локальных сведений и если код причины разъединения одного СТУ равен 9, 1, 2 или 3, уместно использовать тот же самый код причины разъединения в другом СТУ. То же может быть сделано и при кодах 128+1 и 128+7, за исключением использования класса 0, где должно использоваться значение 0. Код причины разъединения 128+2 в соединении по ГОСТ Р 34.950/ГОСТ 34.954 может быть преобразован в код 2 для соединения по ГОСТ Р 34.1952 (не очень близко по существу, но указывает постоянные условия). Другие коды причины разъединения должны приводить к использованию в других соединениях значения 0.

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

Текст документа сверен по:
официальное издание
М.: ИПК Издательство стандартов, 1999