Часть 3. Работа с процедурами УЛЗ типа 1

Часть 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, с	Тайм-аут	Рекомендуемые временные пределы при работе с процедурами УЛЗ типа 1, с
Т20 (Ответ на запрос повторного пуска)	1	Т24 (Передача состояния окна)	1,5
Т21 (Ответ на запрос соединения)	1	Т25 (Поворот окна)	2
Т22 (Ответ на запрос сброса)	1	Т26 (Ответ на прерывание)	1
Т23 (Ответ на запрос завершения)	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). При приеме пакета "Подтверждение завершения" ООД вводит состояние "Готово" (p1).

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). В этом случае оно должно сверить все получаемые пакеты "Подтверждение повторного пуска" с таблицей всех станций ЛВС путем просмотра адресов ППП. Если какое-либо ООД не получило подтверждения повторного пуска, то ООД-отправитель должно передать пакет "Запрос повторного пуска" через каждый из этих интерфейсов. После завершения второго цикла повторного пуска каждый логический канал находится в состоянии "Готово" (p1).

Примечания

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

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

Случай 2 - ООД не знает адресов станций в ЛВС.

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