ГОСТ Р ИСО/МЭК 8881-98
Группа П85
ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Информационная технология
ПЕРЕДАЧА ДАННЫХ
Использование протокола пакетного уровня Х.25
в локальных вычислительных сетях
Information technology. Data communication. Use of the X.25
packet level protocol in local area networks
ОКС 35.100.30*
ОКСТУ 4002
_____________________
* В Указателе "Государственные стандарты" 2003 г. код ОКС 35.100.10. -
Примечание.
Дата введения 1999-01-01
Предисловие
1 РАЗРАБОТАН Московским научно-исследовательским центром Государственного Комитета Российской Федерации по связи и информатизации
ВНЕСЕН Техническим Комитетом по стандартизации ТК 22 "Информационные технологии"
2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 14 мая 1998 г. N 206
Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 8881-89 "Системы обработки информации. Передача данных. Использование протокола пакетного уровня Х.25 в локальных вычислительных сетях"
3 ВВЕДЕН ВПЕРВЫЕ
Введение
Введение
ГОСТ 28907-91 определяет процедуры подуровней "управление доступом к среде" (УДС) и "управление" логическим звеном" (УЛЗ) в работе локальной вычислительной сети (ЛВС). Настоящий стандарт определяет использование протокола пакетного уровня (ППУ) Х.25 (обе редакции - ППУ Х.25-1980 и ППУ Х.25-1984), определенного в ГОСТ Р 34.950-92, с целью выполнения дополнительных функций, помимо тех, которые обеспечиваются при использовании процедур УДС и УЛЗ. Эти дополнительные функции охватывают возможности обеспечения в станции ЛВС услуг сетевого уровня (УСУ) в режиме с установлением соединения, определенных в ГОСТ Р 34.954-91, а также подключения терминалов к станции ЛВС, действующей как средство сборки/разборки пакетов (см., например, рекомендации Х.3, Х.28 и Х.29 МККТТ).
Протокол ППУ Х.25 обеспечивает большое количество различных функциональных возможностей, в том числе:
a) мультиплексирование - способность поддержать несколько потоков данных;
b) передача адресной информации - способность передачи адресной информации, включая адреса пунктов доступа к услугам сетевого уровня (ПДУСУ) ВОС;
c) сегментирование и сборка - способность разбиения блока данных на небольшие пакеты для передачи по ЛВС и повторной сборки пакета в исходный блок данных;
d) управление потоком - способность управления каждым потоком данных между передающим и принимающим оконечным оборудованием данных (ООД);
e) передача срочных данных - способность передачи небольшого объема данных вне обычных процедур управления потоком;
g) обработка ошибок - способность обнаруживать ошибки на пакетном уровне и
h) сброс и повторный пуск - способность повторно инициировать маршруты передачи данных на пакетном уровне в случае появления невосстанавливаемых ошибок.
При использовании протокола ППУ Х.25 внутри ЛВС этот протокол действует в двухпунктовом режиме (ООД - ООД) без промежуточной сети коммутации пакетов. Станция ЛВС действует как отдельный логический объект пакетного уровня для каждого интерфейса ООД/ООД (т.е. для каждой другой станции, с которой она взаимодействует).
ИСО/МЭК/ТО 10029 определяет операции устройства взаимодействия для соединения логического объекта пакетного уровня Х.25 станции ЛВС с другим логическим объектом пакетного уровня Х.25.
Часть 1. ОБЩИЕ ПОЛОЖЕНИЯ
1 Назначение
Настоящий стандарт рассматривает вопрос использования протокола пакетного уровня Х.25, определенного в ГОСТ Р 34.950, для работы по локальным вычислительным сетям, приведенным в ГОСТ 28907.
В части 2 настоящего стандарта определены операции протокола ППУ Х.25 при использовании процедур управления логическим звеном (УЛЗ) типа 2, стандартизованных в ГОСТ 28907. В части 3 определены операции протокола ППУ Х.25 при использовании процедур УЛЗ типа 1, приведенных в ГОСТ 28907.
2 Нормативные ссылки
Настоящий стандарт содержит ссылки на следующие документы:
ГОСТ 28906-91 (ИСО 7498-84, ИСО 7498-84 Доп. 1-84) Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель
ГОСТ 28907-91 (ИСО 8802-2-89) Системы обработки информации. Локальные вычислительные сети. Часть 2. Управление логическим звеном
ГОСТ 29099-91 Системы обработки информации. Сети вычислительные локальные. Термины и определения
ГОСТ Р 34.950-92 (ИСО 8208-87) Системы обработки информации. Передача данных. Протокол пакетного уровня Х.25 для оконечного оборудования данных
ГОСТ Р 34.954-91 (ИСО 8878-87) Системы обработки информации. Передача данных. Использование протокола Х.25 для обеспечения услуг сетевого уровня ВОС в режиме с установлением соединения
ГОСТ Р ИСО 8348/Доп.2-93 Системы обработки информации. Передача данных. Определение услуг сетевого уровня. Дополнение 2. Адресация на сетевом уровне
ИСО/МЭК 8208-90/Изм.1-90 Информация технологии. Передача данных. Протокол пакетного уровня Х.25 для оконечного оборудования данных. Изменение 1. Альтернативное назначение номеров логического канала
ИСО/МЭК/ТО 10029-89* Системы обработки информации. Передача данных. Операции устройства взаимодействия Х.25.
______________
* Оригиналы стандартов и проектов ИСО/МЭК - во ВНИИКИ Госстандарта России.
3 Определения
3.1 Определения из эталонной модели
Настоящий стандарт использует следующие термины, определенные в ГОСТ 28906:
a) услуги сетевого уровня ВОС;
b) адрес пункта доступа к услугам сетевого уровня ВОС.
3.2 Определения из стандарта по адресации
Настоящий стандарт использует следующий термин, определенный в ГОСТ Р ИСО 8348/Доп.2: адрес пункта подключения подсети.
3.3 Определения из стандартов по локальным вычислительным сетям
Настоящий стандарт использует следующие термины, определенные в ГОСТ 29099:
a) локальная вычислительная сеть;
b) управление логическим звеном;
с) управление доступом к среде;
d) адрес пункта доступа к услугам уровня звена данных.
3.4 Определения из стандарта по протоколу пакетного уровня Х.25
Настоящий стандарт использует следующие термины, определенные в ГОСТ Р 34.950:
a) логический объект пакетного уровня;
b) виртуальное соединение;
c) логический канал;
d) младший входящий канал;
e) старший входящий канал;
f) младший двунаправленный канал;
g) старший двунаправленный канал;
h) младший исходящий канал;
i) старший исходящий канал.
4 Сокращения
АКД - аппаратура окончания канала данных
ИДС - идентификатор станции
ЛВС - локальная вычислительная сеть
MBК - младший входящий канал
МДК - младший двунаправленный канал
МИК - младший исходящий канал
МККТТ - международный консультативный комитет по телеграфии и телефонии
НЛК - номер логического канала
ООД - оконечное оборудование данных
ПБД - протокольный блок данных
ПДУСУ - пункт доступа к услугам сетевого уровня
ППП - пункт подключения подсети
ППУ - протокол пакетного уровня
ПУ - пакетный уровень
СВК - старший входящий канал
СДК - старший двунаправленный канал
СИК - старший исходящий канал
УДС - управление доступом к среде
УЛЗ - управление логическим звеном
5. Рассмотрение нижерасположенных уровней
При использовании протокола ППУ Х.25 в ЛВС этот протокол используется в двупунктовом режиме (ООД-ООД), разрешенном в стандарте ГОСТ Р 34.950. В этом случае каждая станция ЛВС действует как ООД. Станция ЛВС имеет (концептуально) по одному логическому объекту ПУ на каждый интерфейс ООД/ООД, в котором она является одной из сторон (т.е. по одному для каждой удаленной станции ЛВС, с которой она взаимодействует). Внутри станции ЛВС логический объект ПУ, связанный с интерфейсом ООД/ООД, индентифицируется адресом логического объекта подуровня УДС удаленной станции ЛВС. Таким образом интерфейс ООД/ООД индентифицируется парой адресов УДС двух станций ЛВС, связанных этим интерфейсом. Эта концепция показана на рисунке 1.
Рисунок 1
Рисунок 1
Примечание - Логический объект ППУ Х.25 индентифицируется одним адресом пункта доступа к услугам уровня звена данных.
6 Рассмотрение пакетного уровня
6.1 Назначение номеров логических каналов
В том случае, когда взаимосвязь ООД-ООД осуществляется через ЛВС, задача согласования диапазонов логических каналов, доступных для каждой пары взаимодействующих ООД, потенциально затруднена. К различным станциям ЛВС, реализующим различные функции в ППУ Х.25, могут предъявляться существенно отличающиеся друг от друга требования относительно числа одновременных виртуальных соединений, с которыми придется оперировать при обмене данными с любой другой отдельной станцией ЛВС. Для облегчения решения этой задачи используется следующий метод.
Администрация ЛВС определяет диапазон логических каналов (МВК, СВК, МДК, СДК, МИК и СИК по ГОСТ Р 34.950) для использования всеми ООД, подключенными к ЛВС. Заметим, что для каждого логического объекта ПУ X.25 в ООД всегда существует хотя бы одно использование параметров из диапазона логических каналов (МВК и т.д.), и, следовательно, в общем случае может иметь место многократное использование всех логических каналов (достигающее числа логических объектов ПУ X.25). При этом работа ООД может основываться на предположении, что все логические каналы определенных диапазонов доступны для использования в соответствии с процедурами, определенными в ГОСТ Р 34.950.
Однако для ООД не требуется распределение ресурсов по всем доступным логическим каналам. ООД, которое принимает пакет ВХОДЯЩИЙ ВЫЗОВ, определяющий действующий НЛК в пределах установленного диапазона, но которое не способно принять вызов из-за недостатка ресурсов логического канала, должно завершить этот вызов. В этом случае причиной является "по инициативе ООД", а диагностикой - "ограничение ресурсов ООД" (код 163).
Одно из ООД выполняет роль АКД с целью выбора логического канала в соответствии с процедурами, определенными в ГОСТ Р 34.950. Для определения ООД, выполняющего роль АКД, в разделах 8 и 11 определяются процедуры пуска.
Парой ООД может быть использована услуга "динамическая регистрация услуг" для повторного определения диапазонов логических каналов, подлежащих использованию между этими ООД (т.е. для изменения значений МВК и т.д.). Для использования этой услуги необходимо предварительное двустороннее соглашение между ООД.
Примечание - После повторного определения диапазонов логических каналов к действительным НЛК применимы те же рассмотренные выше соображения относительно доступности ресурсов.
6.2. Факультативные услуги пользователя
Для ООД, работающих в соответствии с настоящим стандартом по протоколу ППУ Х.25 в режиме ООД/ООД через ЛВС, определенные в ГОСТ 28907, установлено следующее подмножество факультативных услуг пользователя:
a) динамическая регистрация услуг;
b) расширенная порядковая нумерация пакетов;
c) односторонние исходящие логические каналы;
d) односторонние входящие логические каналы;
e) нестандартные рекомендуемые размеры пакета;
f) нестандартные рекомендуемые размеры окна;
g) присвоение рекомендуемого класса пропускной способности;
h) согласование параметра управления потоком;
i) согласование класса пропускной способности;
j) быстрая выборка;
к) выбор и индикация транзитной задержки;
l) расширенный адрес вызывающего;
m) расширенный адрес вызываемого;
n) согласование класса минимальной пропускной способности;
о) согласование межконцевой транзитной задержки;
р) согласование возможности передачи срочных данных.
Для каждой из услуг е), f) и g) каждая станция ЛВС должна использовать одно и то же значение.
Примечание - В понятиях протокола ППУ Х.25 пропускная способность измеряется в битах в секунду относительно данных пользователя, которые логический объект верхнего уровня желает передать по конкретному виртуальному соединению. В свою очередь, это предполагает некоторое распределение ресурсов станции ЛВС для обеспечения требуемой пропускной способности среды, относящейся к данному виртуальному соединению. Эта среда включает в себя нижерасположенную среду передачи (например, физическую среду ЛВС). Следовательно, в данном контексте пропускную способность не следует понимать как пропускную способность физической среды ЛВС.
Для приспособления факультатиных услуг пользователя к любым специальным потребностям пары ООД эта пара может использовать двустороннее соглашение или услугу "динамическая регистрация услуг". В дополнение к перечисленным выше услугам могут быть приспособлены услуги "запрет входящего вызова", "запрет исходящего вызова" и "применимость быстрой выборки" с использованием услуги "динамическая регистрация услуг".
6.3 Размеры пакета и размеры окна по умолчанию
Должны обеспечиваться определенные к настоящему времени в стандартах и нестандартные значения по умолчанию согласно ГОСТ Р 34.950 размеры пакетов и окна.
Для оптимального использования методов нижерасположенных уровней администрация ЛВС может выбрать нестандартные значения по умолчанию размеров пакета и окна из набора возможных значений, определенных в ГОСТ Р 34.950. Однако нижерасположенный подуровень УДС может ограничить максимально доступный размер пакета.
Примечания
1 В тех, случаях, когда окно на пакетном уровне должно превышать значение 7, может быть использована услуга "расширение порядковой нумерации пакетов".
2 Для лучшего использования технологии нижерасположенных уровней ЛВС может оказаться желательным определить нестандартное значение по умолчанию размера пакета дополнительно к тем, которые определены в ГОСТ Р 34.950. Значение такого нестандартного размера пакета может быть ограничено максимальным числом октетов, которые может иметь поле "данные пользователя" пакета ДАННЫЕ в конкретной реализации ЛВС. Это значение снижено до ближайшего числа, кратного 128 октетам. Вычисленное таким образом нестандартное значение по умолчанию размера пакета недоступно при использовании услуг "согласование параметра управления потоком" и "динамическая регистрация услуг".
Часть 2. РАБОТА С ПРОЦЕДУРАМИ УЛЗ ТИПА 2
7 Системные параметры
7.1 Тайм-ауты
Тайм-ауты и метод их работы определены в ГОСТ Р 34.950. В таблице 1 показаны используемые тайм-ауты и их значения по умолчанию при использовании протокола ППУ Х.25 с процедурами УЛЗ типа 2.
Таблица 1 - Тайм-ауты протокола ППУ Х.25 при работе в ЛВС
Тайм-аут | Рекомендуемые временные пределы при работе с процедурами УЛЗ типа 2, с |
Т20 (Ответ на запрос повторного пуска) | 36 |
Т21 (Ответ на запрос соединения) | 40 |
Т22 (Ответ на запрос сброса) | 36 |
Т23 (Ответ на запрос завершения) | 36 |
Т24 (Передача состояния окна) | 12 |
Т25 (Поворот окна) | 40 |
Т26 (Ответ на прерывание) | 36 |
Т28 (Ответ на запрос регистрации) | 60 |
Примечания
1 Временные пределы указаны только как значения по умолчанию (эти значения отличаются от указанных в ГОСТ Р 34.950). Фактический выбор значений может зависеть от многих факторов, в том числе от необходимости быстрого обнаружения сложных ситуаций, используемых процедур УДС, желательности использования значений по умолчанию по ГОСТ Р 34.950 и др. Однако, если выбраны другие значения, то все станции ЛВС должны работать с этими выбранными значениями.
Несмотря на то, что значения временных пределов могут отличаться от их значений по умолчанию, для выбранных значений должны сохраняться соотношения между указанными временными пределами с целью обеспечения правильной работы. В частности, это относится к тайм-аутам Т22 и Т25 при выборе факультативных возможностей (из ГОСТ Р 34.950).
2 Протокол ППУ Х.25 станции ЛВС должен учитывать значения этих тайм-аутов для обеспечения своевременных ответов.
7.2 Счетчики повторной передачи
Счетчики повторной передачи, их режимы работы и значения по умолчанию определены в ГОСТ Р 34.950.
8 Операции пуска
Для установления виртуального соединения станция ЛВС инициирует установление звена данных между собой и удаленной станцией этой ЛВС в соответствии с процедурами УЛЗ типа 2, если такое звено еще не установлено.
Примечания
1 Соперничество при установлении звена данных должно разрешаться в соответствии с процедурами УЛЗ типа 2.
2 Холостое звено - т.е. звено, которое не поддерживается установленным логическим каналом, или соответствующий логический канал находится в процессе установления, и которое может быть разъединено любой станцией ЛВС.
Рекомендуемое значение максимального числа неподтвержденных ПБД должно быть равно 7 (ГОСТ 28907).
Примечание - Это значение может быть изменено администрацией ЛВС или имеющимися в распоряжении механизмами, определенными в ГОСТ 28907.
Как только между двумя ООД ЛВС будет установлено звено УЛЗ типа 2, "роль" каждого ООД может быть определена посредством процедуры повторного пуска, описанной в 4.5 ГОСТ Р 34.950. По завершении последовательности повторного пуска одна из станций ЛВС получает роль ООД, другая - АКД. При установлении виртуального соединения эти роли касаются выбора логического канала и разрешения соперничества вызовов.
Примечание - ГОСТ Р 34.950 требует использования процедур повторного пуска независимо от метода выбора роли.
Часть 3. РАБОТА С ПРОЦЕДУРАМИ УЛЗ ТИПА 1
9 Применимость процедур УЛЗ типа 1
Протокол ППУ Х.25 может работать с процедурами УЛЗ типа 1 в конфигурациях, в которых удовлетворяются требования ГОСТ Р 34.950 к незначительности числа неупорядоченных, дублированных и потерянных пакетов или где появление сигнализируемых ошибок в протоколе ППУ Х.25 обеспечивает приемлемое качество услуг для пользователя ППУ Х.25.
Примечание - Решение об использовании процедур УЛЗ типа 1 в конкретном случае обмена данными не входит в предмет рассмотрения настоящего стандарта. Для принятия такого решения используют следующие обоснования:
a) наличие априорных сведений о возможностях удаленной станции ЛВС, с которой необходимо осуществить взаимодействие;
b) использование процедуры ИДС из стандарта ГОСТ 28907 для определения способностей удаленной станции ЛВС;
c) безуспешность первой попытки использовать процедуры УЛЗ типа 2, в случае чего после безуспешности выполнения процедуры установления соединения звена система, способная работать с ППУ Х.25, может попытаться использовать процедуры УЛЗ типа 1.
10 Системные параметры
10.1 Тайм-ауты
Тайм-ауты и методы работы с ними определены в ГОСТ Р 34.950. В таблице 2 приведены применяемые тайм-ауты и их значения по умолчанию при использовании в станциях ЛВС протокола ППУ Х.25.
Таблица 2 - Тайм-ауты протокола ППУ Х.25 при работе в ЛВС
Тайм-аут | Рекомендуемые временные пределы при работе с процедурами УЛЗ типа 1, с |
Т20 (Ответ на запрос повторного пуска) | 1 |
Т21 (Ответ на запрос Соединения) | 1 |
Т22 (Ответ на запрос сброса) | 1 |
Т23 (Ответ на запрос завершения) | 1 |
Т24 (Передача состояния окна) | 1, 5 |
Т25 (Поворот окна) | 2 |
Т26 (Ответ на прерывание) | 1 |
Т27 (Ответ на запрос регистрации) | 1 |
Примечания
1 Значения временных пределов указаны только как значения по умолчанию (эти значения отличаются от указанных в ГОСТ Р 34.950). Фактический выбор значений может зависеть от многих факторов, в том числе от необходимости быстрого обнаружения сложных ситуаций, используемых процедур УДС, желательности использования значений по умолчанию по ГОСТ Р 34.950 и др. Однако, если выбраны другие значения, то все станции ЛВС должны работать с этими выбранными значениями.
Несмотря на то, что значения временных пределов могут отличаться от их значений по умолчанию, для выбранных значений должно сохраняться соотношение между указанными временными пределами с целью обеспечения правильной работы. В частности, это относится к тайм-аутам Т22 и Т25 при выборе факультативных возможностей (из ГОСТ Р 34.950).
2 Протокол ППУ Х.25 станции ЛВС должен учитывать значения этих тайм-аутов для обеспечения своевременных ответов.
10.2 Счетчики повторной передачи
Счетчики повторной передачи и режимы их работы определены в ГОСТ Р 34.950. В таблице 3 приведены применяемые счетчики повторной передачи и их значения по умолчанию при использовании протокола ППУ Х.25 в станциях ЛВС.
Таблица 3 - Счетчики повторной передачи ППУ Х.25 при работе в ЛВС
Счетчик повторной передачи | Рекомендуемое значение при работе с процедурами УЛЗ типа 1 |
Р20 (Запрос повторного пуска) | 1 |
Р22 (Запрос сброса) | 1 |
Р23 (Запрос завершения) | 1 |
Р25 (Пакет данных) | 0* |
Р28 (Запрос регистрации) | 1 |
_____________
* Несмотря на то, что значение по умолчанию по ГОСТ Р 34.950 счетчика Р25 равно 0, при использовании процедур УЛЗ типа 1 счетчик Р25 в виде факультативной возможности может быть установлен в значение, большее 0, обеспечивая тем самым возможность повторной передачи пакета ДАННЫЕ (см. ГОСТ Р 34.950). В этом случае факультативная возможность передатчика должна обеспечивать повторную передачу содержимого окна (посредством факультативной услуги согласно 11.2.1 b ГОСТ Р 34.950), а факультативная услуга приемника должна игнорировать пакеты ДАННЫЕ с неправильными значениями Ппд (посредством факультативной услуги согласно 11.3 d ГОСТ Р 34.950).
11 Операции пуска
В подразделе 4.5 ГОСТ Р 34.950 рекомендуется процедура определения "роли" ООД относительно выбора логического канала и разрешения соперничества вызовов. Для функционирования этой процедуры ГОСТ Р 34.950 предполагает работу нижележащего уровня в режиме с установлением соединения.
При использовании процедур УЛЗ типа 1 понятие нижерасположенного соединения отсутствует. Для определения роли ООД в указанном выше смысле станция ЛВС, при необходимости установления виртуального соединения, должна проверить, не установлены ли уже какие-либо соединения или не находятся ли они в процессе установления со станцией назначения. Если нет, то сначала должны быть выполнены процедура повторного пуска и факультативная услуга "динамическая регистрация услуг" (при ее использовании). После этого передается пакет ЗАПРОС ВЫЗОВА.
При использовании услуги справочной нумерации для обеспечения альтернативного назначения номеров логических каналов (см. ИСО/МЭК 8208-90/Изм.1) положения подраздела 4.5 ГОСТ Р 34.950 неприменимы.
12 Использование возможностей широковещательной передачи
Возможности процедур УЛЗ типа 1 по широковещательной передаче могут быть использованы для передачи некоторых пакетов ППУ Х.25 к более чем одному получателю. Она особенно применима к случаю передачи пакетов ЗАПРОС ВЫЗОВА и ЗАПРОС ПОВТОРНОГО ПУСКА.
Использование этой возможности для передачи пакета ЗАПРОС ВЫЗОВА требует использования факультативной услуги справочной нумерации (см. ИСО/МЭК 8208-90/Изм. 1).
В следующих разделах термин "широковещательная передача" используется для обозначения способа передачи данных с глобальным или групповым адресом УДС всех станций данной ЛВС. Диспетчер ЛВС определяет, какой адрес должен использоваться всеми ООД, подключенными к данной ЛВС.
12.1 Широковещательная передача пакета ЗАПРОС ВЫЗОВА
Для ЛВС может оказаться удобным реализовать "Справочник распределенной сети". Рассмотрим станцию ЛВС, которая не знает адреса УДС (или адреса ООД) вызываемой ею группы, а знает только ее адрес ПДУСУ. Станция ЛВС передает свой вызов в широковещательном режиме, но только вызываемое ООД распознает адрес своего ПДУСУ (или адрес ООД) и ответит на вызов.
Описываемый здесь механизм широковещательной передачи применим в тех случаях, когда ООД-отправитель ожидает получить только один ответ.
В соответствии с изложенным только один логический объект пакетного уровня может работать с одним адресом УДС.
12.1.1 Ответ на пакет ЗАПРОС ВЫЗОВА
ООД, которое выполняет широковещательную передачу пакета ЗАПРОС ВЫЗОВА, должно ввести в поле адреса вызываемого и/или в факультативную услугу расширения адреса вызываемого адрес получателя, которому она хочет передать данные. В таком случае ООД-отправитель может получить одно из следующих:
a) отсутствие ответа;
b) вначале отрицательный ответ (ИНДИКАЦИЯ ЗАВЕРШЕНИЯ);
c) вначале положительный ответ (СОЕДИНЕНИЕ УСТАНОВЛЕНО и ВХОДЯЩИЙ ВЫЗОВ) или
d) ошибочный ответ.
Поступление нескольких ответов на широковещательный пакет ЗАПРОС ВЫЗОВА, как будет показано в 12.1.1.2 и 12.1.1.3, является ошибочным условием.
Получив пакет ЗАПРОС ВЫЗОВА с глобальным адресом, ООД, которое не распознало адреса своего ПДУСУ (или адреса ООД), не должно передавать пакет ЗАПРОС ЗАВЕРШЕНИЯ.
12.1.1.1 Отсутствие ответа
Если вызывающее ООД не получило ответа и его тайм-аут Т21 истек, оно должно осуществить широковещательную передачу пакета ЗАПРОС ЗАВЕРШЕНИЯ в расширенном формате и с адресом вызываемого ООД. При этом логический канал устанавливается в состояние ЗАПРОС ЗАВЕРШЕНИЯ (р6). При приеме пакета ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ ООД вводит состояние ГОТОВО (р1).
12.1.1.2 ООД вначале получает отрицательный ответ
Получив пакет ИНДИКАЦИЯ ЗАВЕРШЕНИЯ, ООД должно аннулировать все последующие пакеты завершения, рассматривать первый пакет ВХОДЯЩИЙ ВЫЗОВ (если он поступил) как запрос соединения и сбросить все пакеты СОЕДИНЕНИЕ УСТАНОВЛЕНО (при их получении).
Фактически после приема первого пакета ИНДИКАЦИЯ ЗАВЕРШЕНИЯ указатель, назначенный для данного виртуального канала, не используется и может быть назначен для данного виртуального соединения (при его наличии), созданного при приеме пакета ВХОДЯЩИЙ ВЫЗОВ (если он поступил).
12.1.1.3 ООД вначале получает положительный ответ
Получив положительный ответ, ООД может затем принимать положительные, отрицательные или ошибочные ответы. Если ООД получает ошибочные ответы. Оно должно обрабатывать их так, как определено в ГОСТ Р 34.950.
Если ООД получает отрицательный ответ, то такой ответ (содержащий справочный номер, назначенный логическому каналу) может иметь:
a) тот же самый адрес УДС, что и в ранее полученном положительном ответе, или
b) адрес УДС, отличный от адреса в ранее полученном ответе.
В случае а) ООД-отправитель должно подтвердить завершение соединения путем передачи пакета ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ.
В случае b), т.е. если адрес УДС отличается от адреса в полученном ответе, ООД-отправитель должно передать пакет ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ для станции с только что полученным адресом УДС. Следует заметить, что первое соединение остается действительным и что назначенные ему справочные номера сохраняются.
Если ООД получает второй положительный ответ, то этот ответ (содержащий справочный номер, назначенный данному логическому каналу) может иметь:
a) тот же самый адрес УДС, что и в первом ответе, или
b) адрес УДС, отличный от адреса в первом ответе.
В случае а) ООД-отправитель должно завершить соединение путем передачи пакета ЗАПРОС ЗАВЕРШЕНИЯ без адреса вызываемого и без адреса вызывающего ООД на станцию, адрес которой получен в ответе как адрес УДС. После выполнения процедуры завершения ООД должно закончить присвоение справочного номера данному виртуальному соединению.
В случае b) ООД-отправитель должно передать пакет ЗАПРОС ЗАВЕРШЕНИЯ. После этого оно входит в состояние ЗАПРОС ЗАВЕРШЕНИЯ ООД (р6). Присвоенный справочный номер первого ответа остается действительным.
12.1.1.4 Ошибочные ответы
При получении ошибочного ответа ООД должно обработать его в соответствии с процедурами, описанными в ГОСТ Р 34.950.
12.1.2 Прием пакета ВХОДЯЩИЙ ВЫЗОВ по активному логическому каналу
Если ООД получает пакет ВХОДЯЩИЙ ВЫЗОВ с идентификатором логического канала, равным текущему справочному номеру, назначенному для виртуального соединения, оно должно передать в ответ пакет ЗАПРОС ЗАВЕРШЕНИЯ на станцию, адрес которой только что был получен в виде адреса УДС, с идентификатором логического канала, равным указанному в пакете ВХОДЯЩИЙ ВЫЗОВ, с причиной разъединения - "по инициативе ООД" и с кодом диагностики - "не обеспечена ожидаемая услуга" (76). После этого ООД входит в состояние ЗАПРОС ЗАВЕРШЕНИЯ ООД (р6). Следует заметить, что первое соединение остается действительным и что назначенные для него справочные номера сохраняются.
Примечание - Данная ситуация может возникнуть только в том случае, если при работе ППУ Х.25 с процедурами УЛЗ типа 1 не используется факультативная услуга справочной нумерации.
12.2 Широковещательная передача пакета ЗАПРОС ПОВТОРНОГО ПУСКА
В функциональной среде ЛВС необходимо иметь механизм, эквивалентный процедуре повторного пуска Х.25 на интерфейсе ООД/АКД. Механизм повторного пуска используется для завершения всех виртуальных соединений конкретного ООД.
Станция ЛВС может изъявить желание проинформировать все остальные станции ЛВС о том, что она завершает все свои виртуальные соединения. Она выполняет это путем широковещательной передачи пакета ЗАПРОС ПОВТОРНОГО ПУСКА. При этом возможны два случая.
Случай 1 - ООД известны адреса пунктов подключения к подсети всех станций ЛВС.
При широковещательной передаче пакета ЗАПРОС ПОВТОРНОГО ПУСКА ООД входит в состояние ЗАПРОС ПОВТОРНОГО ПУСКА ООД (р2). В этом случае оно должно сверить все получаемые пакеты ПОДТВЕРЖДЕНИЕ ПОВТОРНОГО ПУСКА с таблицей всех станций ЛВС путем просмотра адресов ППП. Если какое-либо ООД не получило подтверждения повторного пуска, то ООД-отправитель должно передать пакет ЗАПРОС ПОВТОРНОГО ПУСКА через каждый из этих интерфейсов. После завершения второго цикла повторного пуска каждый логический канал находится в состоянии ГОТОВО (р1).
Примечания
1 Передающее ООД проверяет также адрес УДС поступающих пакетов ПОДТВЕРЖДЕНИЕ ПОВТОРНОГО ПУСКА. Если они отсутствуют в его таблице, ООД аннулирует такие пакеты и рассматривает их как протокольные ошибки.
2 Получатель пакета ЗАПРОС ПОВТОРНОГО ПУСКА с глобальным адресом должен использовать адрес удаленного УДС для определения тех виртуальных соединений, которые должны быть завершены.
Случай 2 - ООД не знает адресов станций в ЛВС.
В этом случае каждый логический канал находится в состоянии ГОТОВ (р1). Следует заметить, что если данная процедура реализуется, то ООД должно аннулировать все пакеты ПОДТВЕРЖДЕНИЕ ПОВТОРНОГО ПУСКА и не рассматривать их как протокольные ошибки.
Часть 4 ТРЕБОВАНИЯ К СООТВЕТСТВИЮ
13 Соответствие
Системы, претендующие на соответствие настоящему стандарту, должны реализовать процедуры, изложенные в разделах 5 и 6 части 1, а также процедуры, описанные в части 2 (работа с процедурами УЛЗ типа 2). Системы также могут факультативно реализовать процедуры, описанные в части 3 (работа с процедурами УЛЗ типа 1).
Примечание - Использование процедур УЛЗ типа 1 позволяет данной системе взаимодействовать с другой системой (не соответствующей настоящему стандарту), в которой могут использоваться только процедуры УЛЗ типа 1.