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

ГОСТ Р 34.950-92
(ИСО 8208-87)

Группа П85

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

     

Информационная технология
     
ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ.
ПЕРЕДАЧА ДАННЫХ. ПРОТОКОЛ ПАКЕТНОГО УРОВНЯ Х.25
ДЛЯ ОКОНЕЧНОГО ОБОРУДОВАНИЯ ДАННЫХ

     
Information Technology. Open Systems Interconnection.
Data Communications. Packet Layer Protocol Х.25 for Data Terminal Equipment

     
ОКСТУ 0034

Дата введения 1993-01-01

     
ИНФОРМАЦИОННЫЕ ДАННЫЕ

1. ПОДГОТОВЛЕН И ВНЕСЕН Министерством радиопромышленности СССР
     

2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 06.08.92 N 902
     
     Настоящий стандарт подготовлен методом прямого применения международного стандарта ИСО 8208-87 "Системы обработки информации. Взаимосвязь открытых систем. Передача данных. Протокол пакетного уровня Х.25 для оконечного оборудования данных" и полностью ему соответствует
     

3. Срок проверки - 1997 г., периодичность проверки - 5 лет
     

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

5. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ
     

Обозначение отечественного НТД, на который дана ссылка	Обозначение соответствующего международного стандарта	Номер раздела, пункта, в котором дана ссылка
ГОСТ 28906-91	ИСО 7498-84	1.2
-	ИСО 7776-86*	2.3
-	ИСО 8348-87*	2, 3.5
-	ИСО 8348/Доп.2*	2, 15.3.2.1
-	ИСО 8348/Доп.3*	2, 15.3.2.2
-	ИСО 8878-87*	2, 3.5
-	ИСО 8880-2-89*	2, 3.5
-	ИСО/МЭК 8881-89*	2, 3.2
-	ИСО/МЭК 8886-89*	2.3
-	ИСО/МЭК 9574-89*	2, 3.5
-	ИСО/МЭК Т0 10029-89*	2, 13.1.1
-	МККТТ Д.12-88*	15.2.2.8.3
-	МККТТ Х.25-88*	1, 3.1, 3.2, 13.25.2.2, 17
-	МККТТ Х.29-88*	6.6
-	МККТТ Х.31-88*	3.2
-	МККТТ Х.32-88*	3.4
-	МККТТ Х.96-88*	12.2.3.1.1, 12.5.1.1
-	МККТТ X.244-88*	12.2.2.2, 12.2.3.2.5

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

Настоящий стандарт распространяется на сетевой уровень эталонной модели взаимосвязи открытых систем (ВОС) - ГОСТ 28906 и определяет процедуры, форматы и услуги пакетного уровня для оконечного оборудования данных (ООД), работающего в соответствии с рекомендацией Х.25 МККТТ в любом из двух режимов работы: режим виртуальных соединений и режим постоянных виртуальных каналов.
     
     Настоящий стандарт эквивалентен стандарту ИСО 8208, за исключением:
     

а) ссылки на стандарты ИСО заменены ссылками на соответствующие государственные стандарты;
     

б) исключено приложение в "Различия между первым и вторым изданиями ИСО/МЭК 8208" с изменением нумерации приложений.
     
     Термины и определения, используемые в настоящем стандарте, соответствуют ГОСТ 24402.
     
     

1. НАЗНАЧЕНИЕ

1. НАЗНАЧЕНИЕ

     Настоящий стандарт определяет процедуры, форматы и услуги пакетного уровня для ООД, работающего в соответствии с рекомендацией Х.25 МККТТ. Рассматриваются два режима работы: режим виртуальных соединений и режим постоянных виртуальных каналов.
     
     Протокол пакетного уровня может быть использован как в среде ВОС, так и в среде, отличной от ВОС. При использовании в среде ВОС протокол пакетного уровня охватывается сетевым уровнем эталонной модели ВОС - ГОСТ 28906 (ИСО 7498).
     
     Настоящий стандарт распространяется на операции пакетного уровня ООД, выполняемые в процессе доступа к сетям общего или частного пользования с коммутацией пакетов, соответствующих рекомендации Х.25 МККТТ, по выделенному маршруту либо по соединению с коммутацией каналов. Он определяет также дополнительные процедуры пакетного уровня, необходимые для прямого обмена данными (т.е. без использования промежуточной сети с коммутацией пакетов) между двумя ООД, соответствующими настоящему стандарту, по выделенному маршруту, по соединению с коммутацией каналов или по локальным вычислительным сетям.
     
     Настоящий стандарт распространяется также на сети частного пользования, которые используют рекомендацию Х.25 МККТТ для подключения к сети общего пользования с коммутацией пакетов и которые также могут обеспечить интерфейс Х.25 с ООД (см. приложение А).
     
     Следует заметить, что назначения настоящего стандарта и рекомендации Х.25 МККТТ различны в их применении к ООД. В настоящем стандарте содержатся те требования, которые рекомендация Х.25 предъявляет к ООД. Помимо этого в нем содержатся дополнительные требования по упрощению взаимодействий между оборудованием ООД и по обеспечению прямых взаимодействий ООД-ООД. При использовании настоящего стандарта следует учитывать более широкое его назначение.
     
     

2. ССЫЛКИ

     ГОСТ 28906 (ИCО 7498) "Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель".
     
     ИСО 7776* "Системы обработки информации. Передача данных. Процедуры управления звеном данных верхнего уровня. Описание процедур звена данных, совместимых с Х.25 LAPB, для ООД".
     
     ИСО 8348* "Системы обработки информации. Передача данных. Определение услуг сетевого уровня".
     
     ИСО 8348/Доп.2* "Системы обработки информации. Передача данных. Определение услуг сетевого уровня. Дополнение 2. Адресация на сетевом уровне".
     
     ИСО 8348/Доп.3* "Системы обработки информации. Передача данных. Определение услуг сетевого уровня. Дополнение 3. Дополнительные возможности услуг сетевого уровня".
     
     ИСО 8878* "Системы обработки информации. Передача дачных. Использование Х.25 для обеспечения услуг сетевого уровня в режиме-с-установлением-соединения".
     
     ИСО 8880/2* "Системы обработки информации. Передача данных. Протокольные комбинации для обеспечения и поддержки услуг сетевого уровня ВОС. Часть 2. Обеспечение и поддержка услуг сетевого уровня в режиме-с-установлением-соединения".
     
     ИСО/МЭК 8881* "Системы обработки информации. Передача данных. Использование протокола пакетного уровня Х.25 в локальных вычислительных сетях".
     
     ИСО/МЭК 8886* "Системы обработки информации. Передача данных. Определение услуг уровня звена данных для взаимосвязи открытых систем".
     
     ИСО/МЭК 9574* "Системы обработки информации. Передача данных. Обеспечение услуг сетевого уровня ВОС в режиме-с-установлением-соединения в ООД пакетного режима, подключенного к цифровой сети интегрального обслуживания (ЦСИО)".
     
     ИСО/МЭК ТО 10029* "Информационная технология. Передача данных и обмен информацией между системами. Операции устройства взаимодействия Х.25".
     
     Рекомендация D.12 МККТТ* "Единица измерения для тарификации объема информации в международной службе передачи данных с коммутацией пакетов", "Голубая книга" МККТТ, 1988.
     
     Рекомендация Х.25 МККТТ* "Интерфейс между оконечным оборудованием данных (ООД) и аппаратурой окончания канала данных (АКД) для оконечных установок, работающих в пакетном режиме и подключенных к сетям данных общего пользования по выделенному каналу", "Голубая книга" МККТТ, 1988.
     
     Рекомендация Х.29 МККТТ* "Процедуры обмена управляющей информацией и данными пользователя между средством сборки/разборки пакетов (СРП) и пакетным ООД или другим СРП", "Голубая книга" МККТТ, 1988.
     

Рекомендация Х.31 МККТТ* "Поддержка оконечного оборудования пакетного режима в сетях ЦСИО", "Голубая книга" МККТТ, 1988.
     
     Рекомендация X.32 МККТТ* "Интерфейс между оконечным оборудованием данных (ООД) и аппаратурой окончания канала данных (АКД) для оконечных установок, работающих в пакетном режиме и имеющих доступ в сеть данных общего пользования с коммутацией пакетов через телефонную сеть общего пользования или сеть данных общего пользования с коммутацией каналов", "Голубая книга" МККТТ, 1988.
     
     Рекомендация Х.96 МККТТ* "Сигналы прохождения связи в сетях данных общего пользования", "Голубая книга" МККТТ, 1988.
     
     Рекомендация Х.244 МККТТ* "Процедуры обмена идентификаторами протокола во время установления виртуального соединения по сетям данных общего пользования с коммутацией пакетов", "Голубая книга" МККТТ, 1988.
________________
     * До прямого применения данного документа в качестве государственного стандарта распространение его осуществляет секретариат ТК 22 "Информационная технология".
     
     

3. ОБЩИЕ ПОЛОЖЕНИЯ

     Настоящий стандарт определяет с точки зрения ООД пакетный уровень, управляющий передачей пакетов данных на интерфейсе ООД/АКД или ООД/ООД*. На передающей стороне пакетный уровень ООД выполняет основную функцию формирования пакетов из сообщений, получаемых этим ООД от логического объекта вышерасположенного уровня, до выдачи информации протоколу уровня звена данных с целью ее передачи в ХХД. На приемной стороне пакетный уровень ООД выполняет основные функции по приему пакетов из уровня звена данных, проверке пакетов на правильность, удалению заголовков пакетного уровня, формированию сообщений из пакетов данных пользователя и их передаче логическому объекту вышерасположенного уровня ООД.
________________
     * В тех случаях, когда можно давать ссылку как на ООД, так и на АКД, используется обозначение ХХД. Настоящий стандарт можно рассматривать как определение пакетного уровня на интерфейсе ООД/ХХД.
     
     В настоящем стандарте содержится описание интерфейса пакетного уровня для служб "виртуальное соединение" и "постоянный виртуальный канал".
     
     Представлена следующая информация:
     

а) общие положения (разд.3);
     

б) процедуры обмена пакетами через интерфейс ООД/ХХД (разд.4-11). В разд.5 рассматриваются процедуры установления и завершения для службы виртуального соединения, тогда как другие разделы касаются обеих служб: виртуального соединения и постоянного виртуального канала;
     

в) форматы пакета (разд.12);
     

г) процедуры факультативных услуг пользователя, которые могут быть доступны на интерфейсе ООД/ХХД (разд.13 и 14);
     

д) форматы факультативных услуг пользователя и регистрации услуг (разд.15 и 16);
     

е) кодирование поля "код диагностики" (разд.17);
     

ж) тайм-ауты и счетчики повторной передачи (разд.18);
     

з) диаграммы состояний и таблицы состояний (разд.19 и 20);
     

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

а) наименования состояний и пакетов написаны прописными буквами;
     

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

в) термины, не определенные в настоящем стандарте, взяты из рекомендаций МККТТ серии X.
     
     Определяемые в настоящем стандарте процедуры пакетного уровня основаны на услугах нижерасположенного уровня (определенных, например, в ИСО 7776 или в более общем виде - обеспечение услуг звена данных, определенных в ИСО/МЭК 8886), которые обеспечивают незначительную частоту:
     

а) необнаруживаемых ошибок по битам;
     

б) нарушения порядка следования пакетов;
     

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

а) мультиплексирование - возможность обеспечивать групповые обмены данными;
     

б) передача данных - возможность передавать и принимать данные;
     

в) управление потоком - возможность управлять потоком данных;
     

г) прерывание передачи - возможность передавать и принимать небольшие объемы информации, независимо от интенсивности потока данных;
     

д) обработка ошибок - возможность обнаруживать ошибки на пакетном уровне;
     

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

а) полное соответствие рекомендации X.25 МККТТ при работе по сетям с коммутацией пакетов;
     

б) минимум различий в работе по сетям с коммутацией пакетов и непосредственно с другим ООД;
     

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

г) приведение услуг пакетного уровня в соответствие с услугами сетевого уровня, определенными в рамках взаимосвязи открытых систем;
     

д) построение текста стандарта в соответствии с рекомендацией Х.25.
     

3.1. Совместимость с версиями рекомендации Х.25 МККТТ
     
     Определяемые в настоящем стандарте процедуры и форматы пакетного уровня совместимы с версией рекомендации Х.25 МККТТ 1988 г. ("Голубая книга").
     
     Примечание. Возможности "тип адресации" и "индикация нумерационного плана", введенные в версию рекомендации Х.25 МККТТ 1988 г., не включены в настоящий стандарт, поскольку МККТТ оставил их для дальнейшего изучения.
     
     
     Для тех ООД, которые должны работать с прежними версиями рекомендации Х.25, имеют место следующие ограничения.
     

3.1.1. Ограничения совместимости с Х.25 1984 г.
     
     В тех ООД, которые работают с версией рекомендации Х.25 1984 г. ("Красная книга"), не используются следующие возможности версии 1988 г.
     

а) расширенные возможности следующих факультативных средств пользователя:
     
     соответствующие средства идентификации пользователя сети (ИПС) (см. п.13.21);
     
     соответствующие средства признанной частной эксплуатационной организации (ПЧЭО) (см. п.13.23);
     
     соответствующие средства перемаршрутизации вызова и отражения вызова (см. п.13.25).
     
     При работе по версии 1984 г. не были определены средства "отражения вызова" и "игнорирование ИПС"', а средства ИПС и ПЧЭО не разделены в явном виде на средства индексирования и согласования.
     

б) следующие специфицированные МККТТ средства ООД:
     
     приоритет (см. п.14.5);
     
     защита (см. п.14.6).
     
     При работе по версии 1984 г. перечисленные средства не были определены.
     

в) изменено кодирование следующих специфицированных МККТТ средств ООД:
     
     расширение адреса вызываемого (см. п.15.3.2.1);
     
     расширение адреса вызывающего (см. п.15.3.2.2).
     
     При работе с версией 1984 г. кодирование адресов разрешается только в коде ВС.
     

г) класс пропускной способности 64000 бит/с; при работе по версии 1984 г. классом наибольшей пропускной способности является 48000 бит/с.
     

3.1.2. Ограничения на совместимость с Х.25 1980 г.
     
     Для тех ООД, которым необходимо работать по версии 1980 г. рекомендации Х.25 ("Желтая книга"), помимо возможностей, перечисленных в п.3.1.1, не используются следующие возможности протокола версии 1984 г.:
     

а) максимальные длины поля "данные пользователя" в пакетах ДАННЫЕ-2048 и 4096 октетов (см. п.6.2); по версии 1980 г. наибольшая допустимая максимальная длина этого поля составляет 1024 октета;
     

б) поле "услуги" в пакетах ЗАПРОС ВЫЗОВА, ВХОДЯЩИЙ ВЫЗОВ, ВЫЗОВ ПРИНЯТ и СОЕДИНЕНИЕ УСТАНОВЛЕНО имеет длину от 64 до 109 октетов (см. пп.12.2.1.1. и 12.2.2.1); по версии 1980 г. длина этого поля ограничена 63 октетами, а бит 7 поля "длина услуги" должен быть равен 0;
     

в) в кодах причины в пакетах ЗАПРОС/ИНДИКАЦИЯ ЗАВЕРШЕНИЯ, ЗАПРОС/ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ и ЗАПРОС/ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА (см. пп.12.2.3.1.1, 12.5.1.1 и 12.6.1.1 соответственно) бит 8 равен 1; по версии 1980 г. этот бит должен быть равен 0;
     

г) поля "длина адреса" и "длина услуги" пакетов ЗАПРОС ЗАВЕРШЕНИЯ и ИНДИКАЦИЯ ЗАВЕРШЕНИЯ (см. п.12.2.3.2) имеют ненулевую длину; по версии 1980 г. длины этих полей должны указывать ноль октетов и эти поля могут присутствовать только в том случае, если пакет содержит поле "данные завершающего пользователя";
     

д) пакеты ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ (см. п.12.2.4.2) имеют расширенный формат; по версии 1980 г. может использоваться только основной формат;
     

е) поле "данные прерывающего пользователя" в пакетах ПРЕРЫВАНИЕ содержит от 2 до 32 октетов (см. п.12.3.2); по версии 1980 г. это поле должно содержать 1 октет;
     

ж) следующие факультативные услуги пользователя:
     
     динамическая регистрация услуги (см. п.13.1);
     
     запрет локальной тарификации (см. п.13.20);
     
     идентификация пользователя сети (см. п.13.21);
     
     информация о тарифах (см. п.13.22);
     
     группа с выбором (см. п.13.24);
     
     уведомление о переадресации вызова и отражении вызова (см. п.13.25);
     
     уведомление о модификации адреса вызываемой линии (см. п.13.26);
     

выбор и индикация транзитной задержки (см. п.13.27).
     
     При работе по версии 1980 г. вышеперечисленные услуги не могут быть использованы.
     

з) расширенные возможности для следующих факультативных услуг пользователя:
     
     закрытые группы пользователей (ЗГП): абонирование услуг ЗГП с исходящим и/или входящим доступом без предпочтительных ЗГП (см. пп.13.14.2 и 13.14.3 соответственно), использование расширенного формата услуги "выбор ЗГП" для отражения членства в более чем 100 ЗГП (см. п.13.14.6) и использование услуги "выбор закрытой группы пользователей с исходящим доступом" (ЗГП/ИД) (см. п.13.14.7). При работе по версии 1980 г. разрешение на использование всех ЗГП должно указывать предпочтительную ЗГП; для отражения членства в 100 или менее ЗГП допустим только основной формат услуги "выбор ЗГП", а услуга "выбор ЗГП/ИД" не может использоваться;
     
     быстрая выборка и приемлемость быстрой выборки (см. пп.13.16 и 13.17): включение поля "данные завершающего пользователя" в пакеты ЗАПРОС ЗАВЕРШЕНИЯ и ИНДИКАЦИЯ ЗАВЕРШЕНИЯ после установления соединения. При работе по версии 1980 г. вышеуказанные пакеты могут содержать поле "данные завершающего пользователя" только в том случае, когда они переданы или приняты как прямой ответ на пакет ВХОДЯЩИЙ ВЫЗОВ или ЗАПРОС ВЫЗОВА соответственно;
     
     выбор ПЧЭО (см. п.13.23). Использование расширенного формата услуги "выбор ПЧЭО" с целью выбора одной или нескольких ПЧЭО и согласование на некоторый период времени с АКД относительно набора ПЧЭО, относящихся ко всем пакетам ЗАПРОС ВЫЗОВА; по версии 1980 г. ООД, желающее выбрать ПЧЭО, может сделать это только в пакете ЗАПРОС ВЫЗОВА и может использовать только основной формат услуги "выбор ПЧЭО" для выбора отдельной ПЧЭО;
     

и) услуги ООД, определенные МККТТ, и маркер соответствующей услуги (см. разд.14 и п.15.1). По версии 1980 г. эти услуги и маркер не могут использоваться.
     

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

а) операция ООД/АКД:
     

доступ ООД к АКД через арендованные тракты;
     
     доступ ООД к АКД через соединения с коммутацией каналов (сети данных с коммутацией каналов, средства коммутации каналов сетей ЦСИО или коммутируемые телефонные сети). Дополнительные соображения содержатся в п.3.4.
     
     Примечания:
     

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

2. В качестве АКД может быть либо сеть данных с коммутацией пакетов, работающая в соответствии с рекомендацией Х.25 МККТТ, либо средства обработки пакетов в сетях ЦСИО, работающих в соответствии с рекомендацией Х.31 МККТТ.
     
     

б) операции ООД/ООД:
     
     работа ООД-ООД по арендованным линиям (сети данных, сети ЦСИО или телефонные сети);
     
     работа ООД-ООД по соединениям с коммутацией каналов (сети данных с коммутацией каналов, возможности работы сетей ЦСИО по коммутируемым каналам или коммутируемые телефонные сети). Дополнительные соображения содержатся в п.3.4.
     
     работа ООД-ООД через ЛВС. Здесь применимы положения стандарта ИСО/МЭК 8881.
     

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

а) поля "длина адреса" и "длина услуги" необходимы в пакетах ВЫЗОВ ПРИНЯТ, даже если эти поля указывают, что адресная информация и информация об услугах соответственно отсутствует в этих пакетах;
     

б) поле "код диагностики" должно содержаться в пакетах ЗАПРОС ПОВТОРНОГО ПУСКА, ЗАПРОС ЗАВЕРШЕНИЯ и ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ даже если оно указывает "нет дополнительной информации" (т.е. несмотря на то, что для конкретных ошибочных ситуаций определены специальные коды диагностики, ООД может использовать более общие коды, как отмечено в примечании 2 к табл.31);
     

в) пакет ДАННЫЕ не должен передаваться, если его поле "данные пользователя" меньше максимально допустимого и его бит Д равен 0, а бит М равен 1;
     

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

а) одно из ООД должно действовать как АКД при:
     
     выборе логического канала во время установления виртуального соединения (черт.1);
     
     разрешении конфликтов в процессе установления виртуального соединения (см. п.5.2.5).
     
     Соответствующее решение принимается независимо для каждого логического объекта пакетного уровня ООД (см. п.3.8).
     
     Процедура повторного пуска (см. п.4.5) может использоваться для определения, какое из ООД действует в качестве АКД и какое из них сохраняет роль ООД относительно перечисленных выше факторов (процедуры п.4.5 могут использоваться в интерфейсе ООД/ХХД либо по выделенному каналу, либо по соединению с коммутацией каналов. Если же ООД должно работать только в конфигурации ООД/АКД или только в конфигурации ООД/ООД, где его роли могут быть заранее определены и зафиксированы администрацией связи, то такое ООД может быть инициировано на соответствующую работу);
     

б) ООД должно быть способно принять пакет ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА с полем причины повторного пуска "по инициативе ООД" - ситуация, которая не возникает в конфигурации ООД/АКД;
     

в) ООД не должно принимать пакет ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА, ЗАВЕРШЕНИЯ или ПОВТОРНОЙ УСТАНОВКИ с полем причины, отличным от "по инициативе ООД" (хотя такое возможно в конфигурации ООД/АКД). Поэтому ООД может либо обрабатывать такой пакет так, как оно делает это в конфигурации ООД/АКД (т.е. нормально обрабатывать пакет), либо рассматривать его как ошибку (только в конфигурации ООД/ООД);
     

г) При соответствующих обстоятельствах ООД может передавать пакет ДИАГНОСТИКА (см. п.11.1), если только оно может подавлять его генерацию при соединении с сетью;
     

д) ООД может либо игнорировать, либо рассматривать как ошибку получение таких кодов услуги, которые не применимы в конфигурации ООД/ООД;
     

е) Вопрос использования факультативной услуги "динамическая регистрация услуги" (см. п.13.1) требует согласования по каждому направлению инициации процедуры регистрации, т.е. для данного направления инициации процедуры регистрации согласование использования этой услуги разрешает инициирующему ООД передавать пакеты ЗАПРОС РЕГИСТРАЦИИ и требует от отвечающего ООД обрабатывать принимаемые пакеты ЗАПРОС РЕГИСТРАЦИИ (в конфигурации ООД/АКД ООД не должно принимать пакет ЗАПРОС РЕГИСТРАЦИИ);
     

ж) Вопрос использования факультативной услуги "повторная передача пакета" (см. п.13.4) требует согласования по каждому направлению передачи пакетов ДАННЫЕ, т.е. для данного направления передачи пакетов ДАННЫЕ согласование использования этой услуги разрешает ООД-получателю передавать пакеты НЕПРИЕМ и требует от ООД-отправителя обрабатывать принимаемые пакеты НЕПРИЕМ (в конфигурации ООД/АКД ООД не должно принимать пакет НЕПРИЕМ);
     

з) Использование факультативной услуги "быстрая выборка" (см. п.13.16) должно согласовываться обоими ООД до передачи любых пакетов установления соединения, использующих эту услугу. (В конфигурации ООД/АКД такое предварительное согласование не требуется - ООД всегда может использовать эту услугу при установлении соединения);
     

и) Вызываемое ООД, для которого абонирована услуга "согласование параметров управления потоком" (см. п.13.12) и/или услуга "согласование класса пропускной способности" (см. п.13.13), не должно принимать в пакете ВХОДЯЩИЙ ВЫЗОВ индикацию услуги, на основе которой осуществляется согласование, если вызывающее ООД удовлетворено рекомендуемыми значениями и оно не включает запрос услуги в свой пакет ЗАПРОС ВЫЗОВА. Аналогичным образом вызывающее ООД, которому абонированы эти услуги, не должно принимать в пакете СОЕДИНЕНИЕ УСТАНОВЛЕНО индикацию услуги, если вызываемое ООД согласно с полученными значениями в пакете ВХОДЯЩИЙ ВЫЗОВ, и поэтому оно не включает запрос услуги в свой пакет ВЫЗОВ ПРИНЯТ (в конфигурации ООД/АКД эти индикации всегда присутствуют, если для ООД абонированы указанные услуги).
     

3.4. Работа по соединениям с коммутацией каналов
     

Если обмен данными между ООД и ХХД осуществляется по соединению с коммутацией каналов (например через сеть данных с коммутацией каналов через средства коммутации каналов сетей ЦСИО или через телефонную коммутируемую сеть), то могут потребоваться процедуры идентификации. Такие процедуры, в том числе на пакетном уровне, выполняются в сочетании с работой по рекомендации Х.32 МККТТ.
     
     Большая часть обменов данными по соединениям с коммутацией каналов происходит между ООД и ХХД, взаимная совместимость которых установлена некоторой предварительно принятой административной процедурой. Соглашение должно достигаться, например, в отношении конкретных используемых логических каналов, используемых размеров окна и многих других факторов, относящихся к работе пакетного уровня. Однако в некоторых случаях может оказаться целесообразным разрешить случайные обмены данными, где одно ООД обращается к ХХД по соединению с коммутацией каналов без предварительного соглашения (например служба электронной почты). Для обеспечения такой возможности должно использоваться следующее подмножество процедур пакетного уровня:
     

а) интерфейс должен состоять из одного двухнаправленного логического канала виртуального соединения, использующего идентификатор логического канала 1;
     

б) требуются процедуры, описываемые в п.4.5;
     

в) должны использоваться рекомендуемые значения для всех применимых параметров, перечисленных в разд.18; параметры Т24, Т25, Т27, Т28, Р25, Р27 и Р28, а также процедуры, изложенные в п.11.2, 11.3, 13,1 и 13.4, не применяются;
     

г) при приеме пакетов ДАННЫЕ с ошибками должны использоваться процедуры повторной установки (см. п.11.3);
     

д) не разрешается использовать никаких факультативных услуг пользователя.
     
     Расширения этого основного набора процедур и возможностей могут быть обеспечены путем использования процедур, определенных в рекомендации Х.32 МККТТ.
     

3.5. Обеспечение услуг сетевого уровня ВОС
     
     Определяемый в настоящем стандарте протокол пакетного уровня может быть использован для обеспечения услуг сетевого уровня ВОС в режиме с-установлением-соединения в различных условиях применения (например, ИСО 8880/2). Протокол пакетного уровня обеспечивает все элементы услуг сетевого уровня ВОС в режиме с-установлением-соединения, определенных в ИСО 8348 и в дополнении 3 к нему. Прямые и обратные преобразования между элементами протокола пакетного уровня и примитивами и параметрами услуг сетевого уровня в режиме с-установлением-соединения описаны в ИСО 8878. Дополнительные соображения относительно условий применения сетей ЦСИО описаны в ИСО/МЭК 9574.
     

3.6. Внешние взаимодействия пакетного уровня
     

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

а) запросы уровня звена данных на передачу исходящих пакетов;
     

б) прием от уровня звена данных входящих пакетов;
     

в) прием от логического объекта вышерасположенного уровня запросов на инициацию некоторых протокольных процедур пакетного уровня, в том числе:
     
     инициация пакетного уровня (см. п.4.1);
     
     инициация виртуального соединения (см. п.5.2.1);
     
     принятие виртуального соединения (см. п.5.2.3);
     
     окончание виртуального соединения (см. п.5.5.1);
     
     передача данных и информация прерывания (см. разд.6);
     
     повторная инициация логического канала (см. п.8.1).
     
     Необходимо, чтобы для протокола была доступна достаточная информация, позволяющая выполнять эти процедуры. Заметим, что в некоторых случаях протокол пакетного уровня может по своему усмотрению завершить виртуальное соединение или повторно инициировать логический канал;
     

г) информирование логического объекта вышерасположенного уровня о появлении некоторых протокольных событий пакетного уровня, в том числе:
     
     повторная инициация всех логических каналов (см. п.4.2);
     
     прием входящего запроса на установление виртуального соединения (см. п.5.2.2);
     
     завершение виртуального соединения (см. п.5.5.2);
     
     прием данных и информации прерывания (см. разд.6);
     
     повторная инициация логического канала (см. п.8.2).
     
     Наряду с информированием о появлении указанных событий пакетный уровень обеспечивает логическому объекту вышерасположенного уровня также любую другую информацию, относящуюся к этим событиям. Кроме того, пакетный уровень может сообщать о состоянии перечисленных в подпункте в) процедур.
     

3.7. Логические каналы
     

Логические каналы применяются для совместного использования нескольких виртуальных соединений и/или постоянных виртуальных каналов. Каждому виртуальному соединению и каждому постоянному виртуальному каналу назначается идентификатор логического канала*, который может принимать любое значение в диапазоне от 0 до 4095. Для каждого виртуального соединения в фазе установления соединения назначается идентификатор логического канала из диапазона предварительно согласованных идентификаторов. Для каждого постоянного виртуального соединения по согласованию с ХХД назначается идентификатор логического канала (идентификатор логического канала в значении 0 не может быть назначен виртуальному соединению или постоянному виртуальному каналу).
________________
     * Логический канал может рассматриваться как одно 12-битовое поле или два подполя, содержащих соответственно 4 и 8 битов. Если он рассматривается как одно поле, то используется понятие "идентификатор логического канала" или просто "логический канал"; если же он рассматривается в виде двух полей, то используются понятия: "групповой номер логического канала" (4 бита) и "номер логического канала" (8 битов). В настоящем стандарте логический канал рассматривается как одно поле.
     
     Использование логических каналов ООД согласовывает с ХХД на определенный период времени. Структура распределения логических каналов для виртуальных соединений и постоянных виртуальных каналов приведена на черт.1.
     
     

Черт.1. Схема назначения идентификатора логических каналов

Схема назначения идентификатора логических каналов

     В случае интерфейса ООД/ХХД одного логического канала должен быть использован логический канал 1.
     
     В случае интерфейса ООД/ХХД группы логических каналов должен быть согласован диапазон логических каналов в соответствии со следующей схемой     

        

НВК - низший входящий канал;	НДК - низший двухнаправленный канал;	НИК - низший исходящий канал;
ВВК - высший входящий канал;	ВДК - высший двухнаправленный канал;	ВИК - высший исходящий канал.

     Логические каналы с номерами от 1-го до НВК-1 - диапазон логических каналов, назначаемых постоянным виртуальным каналам.
     
     Логические каналы от НВК до ВВК - диапазон логических каналов, назначаемых однонаправленным входящим логическим каналам для виртуальных соединений.
     
     Логические каналы от НДК до ВДК - диапазон логических каналов, назначаемых двухнаправленным логическим каналам для виртуальных соединений.
     
     Логические каналы от НИК до ВИК - диапазон логических каналов, назначаемых однонаправленным исходящим логическим каналам для виртуальных соединений.
     
     Номера от ВВК плюс 1 до НДК минус 1, от ВДК плюс 1 до НИК минус 1 и от ВИК плюс 1 до 4095 не назначаются логическим каналам.
     
     Примечания:
     

1. Для ссылок на идентификаторы логического канала используют непрерывную последовательность чисел от 0 (наименьшее) до 4095 (наибольшее), кодируемых 12-ю битами, в том числе, используя биты 4-1 октета 1 и все биты октета 2. Номера идентификаторов представляются в двоичном коде с использованием битов 4-1 октета 1 и бит 8-1 октета 2, где бит 1 октета 2 - младший бит.
     

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

3. Все пределы нумерации логических каналов согласовываются с ХХД на определенный период времени.
     

4. В конфигурации ООД/ООД одно из ООД воспринимает диапазон идентификаторов логических каналов так, как они представлены здесь, тогда как другое ООД воспринимает его с точки зрения АКД (например другое ООД рассматривает диапазон от НВК до ВВК как однонаправленный исходящий). Это определение рассмотрено в п.4.5.
     

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

6. При отсутствии постоянных виртуальных каналов для НВК доступен логический канал 1. При отсутствии постоянных виртуальных каналов и однонаправленных входящих логических каналов для НДК доступен логический канал 1. При отсутствии постоянных виртуальных каналов, однонаправленных входящих логических каналов и двухнаправленных логических каналов для НИК доступен логический канал 1.
     

7. Алгоритм поиска АКД или ООД, выполняющего роль АКД в конфигурации ООД/ООД, будет выбирать для нового входящего вызова логический канал с самым младшим номером из всех логических каналов, находящихся в состоянии ГОТОВНОСТЬ (р1) в диапазонах от НВК до ВВК и от НДК до ВДК.
     

8. Для того чтобы свести к минимуму вероятность конфликта встречных вызовов алгоритм поиска в ООД начинает с наибольшего по номеру логического канала, находящегося в состоянии ГОТОВНОСТЬ (р1), в диапазоне двухнаправленных и однонаправленных исходящих логических каналов.
     

Черт.1

     

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

Черт.2. Логические объекты пакетного уровня

Логические объекты пакетного уровня

ЛОПУ - логический объект пакетного уровня

Черт.2

3.9. Типы пакетов
     
     Типы пакетов и их использование в различных службах приведены в табл.1.
     
     

Taблица 1

Группы/функции пакета

Группа пакета	Функция	Типы пакета	Служба ВС ПВК
Установление и завершение соединения	Установление и окончание виртуального соединения при взаимосвязи ООД/ХХД; может передавать данные для обработки логическим объектам вышерасположенного уровня	ЗАПРОС ВЫЗОВА	Х
		ВХОДЯЩИЙ ВЫЗОВ	Х
		ВЫЗОВ ПРИНЯТ	Х
		СОЕДИНЕНИЕ УСТАНОВЛЕНО	Х
		ЗАПРОС ЗАВЕРШЕНИЯ	Х
		ИНДИКАЦИЯ ЗАВЕРШЕНИЯ	Х
		ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ	Х
Данные и прерывание	Передача данных или информации прерывания для обработки логическим объектом вышерасположенного уровня	ДАННЫЕ	X Х
		ПРЕРЫВАНИЕ	Х Х
		ПОДТВЕРЖДЕНИЕ ПРЕРЫВАНИЯ	Х Х
Управление потоком и повторная установка	Управление потоком пакетов ДАННЫЕ через интерфейс ООД/ХХД	ГОТОВ К ПРИЕМУ	Х Х
		НЕ ГОТОВ К ПРИЕМУ	Х Х
		НЕПРИЕМ	Х Х
		ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ	Х Х
		ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ	Х Х
		ПОДТВЕРЖДЕНИЕ ПОВТОРНОЙ УСТАНОВКИ	X Х
Повторный пуск	Инициация (в том числе повторная) всех обменов данными между ООД и ХХД	ЗАПРОС ПОВТОРНОГО ПУСКА	Х Х
		ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА	Х Х
		ПОДТВЕРЖДЕНИЕ ПОВТОРНОГО ПУСКА	Х Х
Диагностика	Передача в ООД результатов диагностики ошибок	ДИАГНОСТИКА	Х Х
Регистрация	Выполнение процедуры регистрации	ЗАПРОС РЕГИСТРАЦИИ	Х Х
		ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ	Х Х

     Условные обозначения:
     
     ВС - виртуальное соединение;
     
     ПВК - постоянный виртуальный канал.
     
     

3.10. Процедуры инициации
     
     Инициация пакетного уровня соответствует инициации каждого логического канала в логическом объекте пакетного уровня. До начала передачи данных по любому логическому каналу должна быть выполнена процедура инициации уровня звена данных (например с точки зрения услуг уровня звена данных ВОС в режиме с-установлением-соединения - это установление соединения звена данных). После этого ООД должно инициировать процедуру повторного пуска.
     

См. также:
     
     процедуры повторного пуска (разд.4).
     
     

4. ПРОЦЕДУРЫ ПОВТОРНОГО ПУСКА

     Процедура повторного пуска используется для инициации или повторной инициации пакетного уровня интерфейса ООД/ХХД. Эта процедура выполняет одновременное завершение всех виртуальных соединений и повторную установку всех постоянных виртуальных каналов на интерфейсе ООД/ХХД (т.е. всех логических каналов в логическом объекте пакетного уровня). В то же время она может использоваться также для определения способа, по которому ООД будет впоследствии выбирать логические каналы для виртуальных соединений и разрешать конфликты встречных виртуальных соединений (см. п.4.5).
     
     На черт.3 приведен схематический вид процедуры повторного пуска.
     

Черт.3. Схема повторного пуска

Схема повторного пуска

Черт.3

     Существуют три состояния логического канала относительно процедуры повторного пуска. Этими состояниями являются: ГОТОВНОСТЬ ПАКЕТНОГО УРОВНЯ (r1), ЗАПРОС ПОВТОРНОГО ПУСКА ООД (r2) и ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА ХХД (r3). При входе в состояние r1 каждый логический канал виртуального соединения оказывается в состоянии ГОТОВНОСТЬ (р1), а каждый логический канал постоянного виртуального канала - в состоянии ГОТОВНОСТЬ К УПРАВЛЕНИЮ ПОТОКОМ (d1) (заметим, что эти состояния относятся к состоянию ГОТОВНОСТЬ ПАКЕТНОГО УРОВНЯ (r1)) (см. разд.19).
     

4.1. Инициация запроса повторного пуска
     
     ООД может выдать запрос повторного пуска в любой момент времени, передав через интерфейс ООД/ХХД пакет ЗАПРОС ПОВТОРНОГО ПУСКА и начав отсчет тайм-аута "ответ на запрос повторного пуска" (Т20). При этом интерфейс для каждого логического канала находится в состоянии ЗАПРОС ПОВТОРНОГО ПУСКА ООД (r2). В этом состоянии все пакеты, кроме пакетов ПОДТВЕРЖДЕНИЕ ПОВТОРНОГО ПУСКА, ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА, ЗАПРОС РЕГИСТРАЦИИ (только в конфигурации ООД/ХХД), ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ и ДИАГНОСТИКА игнорируются. Следовательно, логические объекты более высоких уровней должны справляться с различными ситуациями, которые могут здесь возникнуть.
     
     Неполучение пакетов ПОДТВЕРЖДЕНИЕ ПОВТОРНОГО ПУСКА и ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА до истечения Т20 после передачи пакета ЗАПРОС ПОВТОРНОГО ПУСКА рассматривается как ошибка. Процедура повторного пуска может выполняться повторно максимум R20 раз. После выполнения максимального числа попыток пакетный уровень сообщает соответствующему объекту, что он не получил подтверждения на процедуру повторного пуска. При этом каждый логический канал остается в состоянии ЗАПРОС ПОВТОРНОГО ПУСКА ООД (r2).
     

См. также:
     
     формат пакета ЗАПРОС ПОВТОРНОГО ПУСКА (п.12.6.1 и черт.22);
     
     тайм-аут "ответ на запрос повторного пуска" (Т20) (табл.32);
     
     счет повторных передач запроса повторного пуска (R20) (табл.27);
     
     прием индикации повторного пуска (п.4.2);
     
     конфликты встречных повторных пусков (п.4.3);
     

подтверждение повторного пуска (п.4.4);
     
     инициация и повторная инициация пакетного уровня (п.3.10 и разд.10).
     

4.2. Прием индикации повторного пуска
     
     После того как ООД примет пакет ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА, интерфейс для каждого логического канала будет находиться в состоянии ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА ХХД (r3). В этом состоянии ООД должно рассматривать последующий прием любого пакета (кроме другого пакета ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА, пакета ЗАПРОС РЕГИСТРАЦИИ (только в конфигурации ООД/ООД), ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ И ДИАГНОСТИКА) как ошибку. Оно должно аннулировать любой такой пакет и передать при этом пакет ЗАПРОС ПОВТОРНОГО ПУСКА, указав причину "по инициативе ООД" и диагностику "недействительный тип пакета для состояния r3".
     
     Пакет ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА определяет причину повторного пуска. Код причины повторного пуска, а также код диагностики - индикация того, что выполнена процедура повторного пуска, передаются логическому объекту вышерасположенного уровня.
     
     Примечание. В конфигурации ООД/ООД пакет ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА, полученный одним из ООД, это тот же пакет ЗАПРОС ПОВТОРНОГО ПУСКА, который передало другое ООД.
     
     
     После обработки пакета ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА ООД передает через интерфейс ООД/ХХД пакет ПОДТВЕРЖДЕНИЕ ПОВТОРНОГО ПУСКА.
     

См. также:
     
     формат пакета ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА (п.12.6.1 и черт.22);
     
     причина повторного пуска (п.12.6.1);
     
     конфликты встречных повторных пусков (п.4.3);
     
     подтверждение повторного пуска (п.4.4);
     
     тайм-ауты, учитываемые при приемке пакета ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА (табл.34).
     

4.3. Кoнфликты при пoвтopнoм пуске
     
     Конфликт при повторном пуске возникает, когда ООД передает пакет ЗАПРОС ПОВТОРНОГО ПУСКА (см. п.4.1) и затем принимает пакет ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА (см. п.4.2). В этом случае ООД не передает и не ожидает приема пакета ПОДТВЕРЖДЕНИЕ ПОВТОРНОГО ПУСКА и считает, что повторный пуск выполнен. Однако при использовании процедур по п.4.5 ООД должно выяснить, указывает ли поле причины повторного пуска в пакете ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА "по инициативе ООД". Если да, то ООД не должно предпринимать никаких других действий, кроме передачи еще одного пакета ЗАПРОС ПОВТОРНОГО ПУСКА после некоторой случайно выбранной временной задержки. Если же это поле не указывает "по инициативе ООД", то процедура повторного пуска считается выполненной.
     
     После выполнения процедуры повторного пуска каждый логический канал виртуального соединения входит в состояние ГОТОВНОСТЬ (р1), а каждый логический канал постоянного виртуального канала - в состояние ГОТОВНОСТЬ К УПРАВЛЕНИЮ ПОТОКОМ (d1).
     

4.4. Подтверждение повторного пуска
     
     Если ООД готово подтвердить повторный пуск, оно передает через интерфейс ООД/ХХД пакет ПОДТВЕРЖДЕНИЕ ПОВТОРНОГО ПУСКА. С этого момента процедура повторного пуска считается выполненной.
     
     Инициировав процедуру повторного пуска, ООД будет считать ее выполненной после приема пакета ПОДТВЕРЖДЕНИЕ ПОВТОРНОГО ПУСКА.
     
     После выполнения процедуры повторного пуска каждый логический канал виртуального соединения будет находиться в состоянии ГОТОВНОСТЬ (р1), а каждый логический канал постоянного виртуального канала - в состоянии ГОТОВНОСТЬ К УПРАВЛЕНИЮ ПОТОКОМ (d1).
     
     При работе с сетью пакет ПОДТВЕРЖДЕНИЕ ПОВТОРНОГО ПУСКА, принятый от АКД, может рассматриваться во всех случаях как имеющий только локальную значимость:
     

См. также:
     
     формат пакета ПОДТВЕРЖДЕНИЕ ПОВТОРНОГО ПУСКА (п.12.6.2 и черт.23).
     

4.5. Определение роли ООД или АКД
     
     Процедура повторного пуска может использоваться для ответа на вопрос действует ли данное ООД как АКД или же оно выполняет свою роль ООД при выборе логического канала во время установления виртуального соединения и при разрешении конфликтов встречных виртуальных соединений.
     
     При подготовке к инициации пакетного уровня ООД должно инициировать процедуру повторного пуска (т.е. передать пакет ЗАПРОС ПОВТОРНОГО ПУСКА). Решение указанного выше вопроса основывается на полученном от ХХД ответе в соответствии с нижеизложенным:
     

а) если ООД получило пакет ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА с кодом причины повторного пуска, отличным от "по инициативе ООД" (т.е. пакет поступил от АКД), оно должно выполнить процедуры по пп.4.2, 4.3 и 4.4 в зависимости от обстоятельств и сохранить свою роль ООД;
     

б) если ООД получило пакет ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА с кодом причины повторного пуска "по инициативе ООД" (т.е. пакет поступил от другого ООД) и оно не имеет неподтвержденных пакетов ЗАПРОС ПОВТОРНОГО ПУСКА (т.е. отсутствуют конфликты повторного пуска), то это ООД должно подтвердить повторный пуск (как в п.4.4) и действовать как АКД;
     

в) если ООД получило пакет ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА с кодом причины повторного пуска "по инициативе ООД" (т.е. пакет поступил от другого ООД) и есть неподтвержденный пакет ЗАПРОС ПОВТОРНОГО ПУСКА (т.е. имеет место конфликт повторного пуска), то это ООД должно  рассматривать процедуру  повторного пуска выполненной (как в п.4.3) и не должно выполнять других действий, кроме передачи еще одного пакета ЗАПРОС ПОВТОРНОГО ПУСКА после некоторой произвольно выбранной временной задержки;
     

г) если ООД выдало пакет ЗАПРОС ПОВТОРНОГО ПУСКА, который затем подтвержден пакетом ПОДТВЕРЖДЕНИЕ ПОВТОРНОГО ПУСКА (как в п.4.4), то это ООД должно сохранить свою роль ООД.
     
     Примечание. Если ООД работает только в конфигурации ООД/АКД, либо только в конфигурации ООД/ООД, где функции ООД могут быть заранее определены и зафиксированы администрацией связи, то рассмотренные выше процедуры не нужны. В этих случаях ООД может быть инициировано на выполнение соответствующей роли.
     
     

См. также:
     
     выбор логического канала (черт.1);
     
     конфликт встречных виртуальных соединений (п.5.2.5);
     
     инициация запроса повторного пуска (п.4.1);
     
     прием индикации повторного пуска (п.4.2);
     
     конфликт встречных повторных пусков (п.4.3);
     
     подтверждение повторного пуска (п.4.4);
     
     причина повторного пуска (п.12.6.1).
     
     

5. ПРОЦЕДУРЫ УСТАНОВЛЕНИЯ И ЗАВЕРШЕНИЯ ВИРТУАЛЬНОГО СОЕДИНЕНИЯ

     В данном разделе описываются процедуры установления и завершения виртуальных соединений. Они применяются независимо для каждого логического канала, назначенного для службы виртуального соединения на интерфейсе ООД/ХХД (здесь не рассматриваются процедуры установления и завершения постоянных виртуальных каналов).
     
     На черт.4 и 5 схематически изображены процессы установления и завершения виртуального соединения соответственно. Аналогичная информация приведена также в диаграмме состояний на черт.32. В табл.39 определены действия, выполняемые ООД при приеме пакетов от ХХД, применительно к процедурам установления и завершения виртуального соединения.
     
     

Черт.4. Схема установления соединения

Схема установления соединения

Черт. 4     
   

Черт.5. Схема завершения соединения

Схема завершения соединения

________________
     * В сетевой конфигурации пакет ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ, полученный ООД "А", не обязательно является ответом на пакет ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ, переданный ООД "Б".
     

Черт.5

     

5.1. Состояние ГОТОВНОСТЬ
     
     При отсутствии вызова логический канал, используемый для виртуальных соединений, находится в состоянии ГОТОВНОСТЬ (р1).
     

5.2. Процедуры установления виртуального соединения
     

5.2.1. Инициация виртуального соединения
     
     ООД выдает запрос вызова путем передачи через интерфейс ООД/ХХД пакета ЗАПРОС ВЫЗОВА и запуска тайм-аута "ответ на запрос вызова" (Т21). При этом выбранный ООД логический канал входит в состояние ЗАПРОС ВЫЗОВА ООД (р2).
     
     Пакет ЗАПРОС ВЫЗОВА может содержать адрес вызываемого ООД и адрес вызывающего ООД. Каждый адрес формируется из последовательности цифр (максимум 15). Такой пакет может содержать также любые данные пользователя, выдаваемые логическим объектом вышерасположенного уровня для передачи удаленному ООД.
     
     Примечания:
     

1. Включение адреса вызываемого ООД и адреса вызывающего ООД в пакет ЗАПРОС ВЫЗОВА зависит от требований противоположного ХХД.
     

2. Адрес ООД может быть сетевым адресом ООД или любым другим идентификатором ООД, согласованным между ООД и ХХД на определенный период времени.
     

3. Процедуры, с помощью которых ООД выбирает логический канал в состоянии ГОТОВНОСТЬ (р1) при инициации виртуального соединения приведены в п.4.5 и на черт.1. Если ООД выполняет роль ООД, то оно выбирает логический канал, начиная с верхнего конца диапазона номеров логических каналов, согласованного с ХХД. Однако в конфигурации ООД/ООД, если ООД функционирует для этих процедур как АКД, оно выбирает логический канал в состоянии ГОТОВНОСТЬ (р1), начиная с нижнего конца указанного диапазона логических каналов. Тем самым минимизируется вероятность конфликтов встречных вызовов.
     
     
     Неполучение пакета СОЕДИНЕНИЕ УСТАНОВЛЕНО или пакета ИНДИКАЦИЯ ЗАВЕРШЕНИЯ до истечения тайм-аута Т21, отсчитываемого с момента передачи пакета ЗАПРОС ВЫЗОВА, рассматривается как ошибка. Пакетный уровень завершает вызов, указывая причину "по инициативе ООД" и диагностику "истек тайм-аут запроса вызова".
     

См. также:
     

конфликт встречных вызовов (п.5.2.5);
     
     прерывание запроса вызова (п.5.4);
     
     тайм-аут "ответ на запрос вызова" (Т21) (табл.32);
     
     формат пакета ЗАПРОС ВЫЗОВА (п.12.2.1 и черт.11);
     
     процедуры завершения (п.5.5);
     
     процедуры установления соединения при использовании бита Д (п.6.3);
     
     выбор логического канала (черт.1).
     

5.2.2. Прием индикации входящего вызова
     
     При получении от ХХД пакета ВХОДЯЩИЙ ВЫЗОВ ООД получает индикацию входящего вызова. После этого логический канал входит в состояние ВХОДЯЩИЙ ВЫЗОВ ХХД (р3).
     
     Пакет ВХОДЯЩИЙ ВЫЗОВ может содержать адрес вызывающего ООД и адрес вызываемого ООД. Адресная информация и любые данные, принятые в составе этого пакета, должны быть переданы логическому объекту вышерасположенного уровня. Кроме того, логическому объекту вышерасположенного уровня может быть направлена информация о факультативных услугах пользователя.
     
     Примечания:
     

1. Включение адреса вызывающего ООД и адреса вызываемого ООД в пакет ВХОДЯЩИЙ ВЫЗОВ зависит от действия противоположного ХХД.
     

2. Адрес ООД может быть сетевым адресом ООД или любым другим идентификатором ООД, согласованным между ООД и ХХД на определенный период времени.
     

3. В конфигурации ООД/ООД пакет ВХОДЯЩИЙ ВЫЗОВ, полученный одним из ООД, это тот же пакет ЗАПРОС ВЫЗОВА, который передан другим ООД.
     
     

См. также:
     
     формат пакета ВХОДЯЩИЙ ВЫЗОВ (п.12.2.1 и черт.11);
     
     конфликт встречных вызовов (п.5.2.5);
     
     принятие входящего вызова (п.5.2.3);
     
     отклонение входящего вызова (п.5.3);
     
     процедуры установления соединения при использовании бита Д (п.6.3);
     
     тайм-ауты, учитываемые при приеме пакета ВХОДЯЩИЙ ВЫЗОВ (табл.34).
     

5.2.3. Принятие виртуального вызова
     
     ООД, получающее пакет ВХОДЯЩИЙ ВЫЗОВ, сообщает о принятии вызова передачей через интерфейс ООД/ХХД пакета ВЫЗОВ ПРИНЯТ. Этот пакет должен определять тот же логический канал, что и пакет ВХОДЯЩИЙ ВЫЗОВ.
     
     Определенный таким образом логический канал входит после этого в состояние ГОТОВНОСТЬ К УПРАВЛЕНИЮ ПОТОКОМ (d1).
     

Решение о принятии вызова принимается логическим объектом вышерасположенного уровня перед выдачей на пакетный уровень пакета ВЫЗОВ ПРИНЯТ. Более того, он может обеспечить в составе пакета ВЫЗОВ ПРИНЯТ данные для передачи вызывающему ООД. Данные могут быть возвращены только в том случае, если пакет ВХОДЯЩИЙ ВЫЗОВ указывает услугу быстрой выборки без каких либо ограничений на выдачу ответа. Пакет ВЫЗОВ ПРИНЯТ не должен передаваться в обратном направлении, если пакет ВХОДЯЩИЙ ВЫЗОВ указывает на услугу быстрой выборки с ограничением на выдачу ответа.
     
     Вызов может быть отклонен по локальным причинам для пакетного уровня (например ошибка формата в пакете ВХОДЯЩИЙ ВЫЗОВ) без информирования логического объекта вышерасположенного уровня о его получении.
     

См. также:
     
     формат пакета ВЫЗОВ ПРИНЯТ (п.12.2.2 и черт.12);
     
     процедуры установления соединения при использовании бита Д (п.6.3);
     
     отклонение входящего вызова (п.5.3);
     
     факультативная услуга пользователя "быстрая выборка" (п.13.16).
     

5.2.4. Получение индикации о принятии вызова
     
     Получение вызывающим ООД пакета СОЕДИНЕНИЕ УСТАНОВЛЕНО, определяющего тот же логический канал, что и в пакете ЗАПРОС ВЫЗОВА, свидетельствует о том, что вызов принят вызываемым ООД. Определенный таким образом логический канал входит при этом в состояние ГОТОВНОСТЬ К УПРАВЛЕНИЮ ПОТОКОМ (d1).
     
     Любая адресная информация и любые данные, принятые в составе пакета СОЕДИНЕНИЕ УСТАНОВЛЕНО, направляются логическому объекту вышерасположенного уровня. Кроме того, этому логическому объекту может быть направлена информация о факультативной услуге пользователя.
     
     Примечание. В конфигурации ООД/ООД пакет СОЕДИНЕНИЕ УСТАНОВЛЕНО, принятый одним ООД, это тот же пакет ВЫЗОВ ПРИНЯТ, который передан другим ООД.
     
     

См. также:
     
     неподтверждение запроса вызова (п.5.4);
     
     формат пакета СОЕДИНЕНИЕ УСТАНОВЛЕНО (п.12.2.2 и черт.12);
     
     процедуры установления соединения при использовании бита Д (п.6.3);
     

5.2.5. Конфликт встречных вызовов
     

Конфликт встречных вызовов возникает, когда ООД передает пакет ЗАПРОС ВЫЗОВА (в соответствии с п.5.2.1) и затем получает для того же логического канала пакет ВХОДЯЩИЙ ВЫЗОВ (в соответствии п.5.2.2). В этот момент логический канал находится в состоянии КОНФЛИКТ ВСТРЕЧНЫХ ВЫЗОВОВ (р5). Дальнейшие действия ООД зависят от того, сохраняет ли оно свою роль ООД или действует как АКД при разрешении конфликта встречных вызовов (в соответствии с процедурами п.4.5):
     
     если ООД сохраняет свою роль ООД, оно будет игнорировать пакет ВХОДЯЩИЙ ВЫЗОВ и ждать ответа от ХХД. ООД должно получить либо пакет СОЕДИНЕНИЕ УСТАНОВЛЕНО (если вызов принят удаленным ООД), либо пакет ИНДИКАЦИЯ ЗАВЕРШЕНИЯ для того же логического канала, что и в пакете ЗАПРОС ВЫЗОВА;
     
     в конфигурации ООД/ООД, если ООД выполняет роль АКД, оно должно аннулировать свой запрос вызова и решить, какой пакет передавать: ВЫЗОВ ПРИНЯТ или ЗАПРОС ЗАВЕРШЕНИЯ.
     

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

а) отклонение сетью, так как вызов не может быть выполнен в направлении адресуемого ООД;
     

б) отклонение сетью или вызываемым ООД вследствие перегрузки;
     

в) отклонение сетью или вызываемым ООД вследствие ошибки формата пакета;
     

г) отклонение сетью или вызываемым ООД некоторых факультативных услуг пользователей, запрошенных вызывающим ООД;
     

д) отклонение вызываемым ООД по инициативе логического объекта вышерасположенного уровня.
     
     В любом случае ООД или АКД завершает вызов передачей соответствующего пакета вызывающему ООД. В тех случаях, когда входящий вызов отклоняется, то и пакет ВЫЗОВ ПРИНЯТ не передается (см. п.5.2.3).
     

См. также:
     
     процедуры завершения (п.5.5).
     

5.4. Прерывание запроса вызова
     
     Вызывающее ООД может прервать вызов, выдав на него завершение до получения пакета СОЕДИНЕНИЕ УСТАНОВЛЕНО или ИНДИКАЦИЯ ЗАВЕРШЕНИЯ. Это может произойти вследствие прерывания, инициированного логическим объектом вышерасположенного уровня или вследствие истечения тайм-аута Т21.
     
     Как отмечено ранее, отсчет тайм-аута должен начинаться ООД, когда оно инициирует запрос вызова. Истечение этого тайм-аута (до получения сообщения о принятии или отклонении запроса вызова) рассматривается как процедурная ошибка и приводит к завершению вызова со стороны ООД с указанием причины "по инициативе ООД" и диагностики "истек тайм-аут запроса вызова".
     

См. также:
     
     тайм-аут ответа на запрос вызова (Т21) (табл.32);
     
     процедуры завершения (п.5.5).
     

5.5. Процедуры завершения виртуального соединения
     
     Соединение или запрос вызова любая сторона может завершить в любой момент времени. Это может быть выполнено при установлении соединения, например вызываемым ООД по причинам, указанным в п.5.3, или вызывающим ООД по причинам, указанным в п.5.4. Вызываемое или вызывающее ООД может закончить виртуальное соединение либо нормальным образом вследствие выполнения вызова, либо прервать его из-за обнаружения ошибки.
     

5.5.1. Инициация завершения виртуального соединения
     
     ООД может указать завершение виртуального соединения в любой момент времени, передав через интерфейс ООД/ХХД пакет ЗАПРОС ЗАВЕРШЕНИЯ, определяющий логический канал, и начав отсчет тайм-аута "ответ на запрос завершения" (Т23). Логический канал входит после этого в состояние ЗАПРОС ЗАВЕРШЕНИЯ ООД (р6). В этом состоянии единственными приемлемыми пакетами для логического канала являются пакеты ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ и ИНДИКАЦИЯ ЗАВЕРШЕНИЯ. Другие типы пакетов для данного логического канала игнорируются. Следовательно, логические объекты вышерасположенного уровня должны быть способны справляться с различными возможными здесь ситуациями.
     
     Неполучение пакета ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ до истечения тайм-аута Т23 рассматривается как ошибка. Процедура повторяет попытки завершения максимум R23 раз. После этого пакетный уровень сообщает соответствующему логическому объекту, что он не получил подтверждения процедуры завершения и логический канал остается в состоянии ЗАПРОС ЗАВЕРШЕНИЯ ООД (р6).
     
     Пакет ЗАПРОС ЗАВЕРШЕНИЯ может содержать данные, обеспечиваемые логическим объектом вышерасположенного уровня и подлежащие передаче удаленному ООД. Они могут быть переданы только в том случае, если пакеты ЗАПРОС ВЫЗОВА и ВХОДЯЩИЙ ВЫЗОВ указывали услугу быстрой выборки. ООД, которое после передачи пакета ЗАПРОС ВЫЗОВА и до получения ответа прерывает свой собственный вызов, может не передавать данные в пакете ЗАПРОС ЗАВЕРШЕНИЯ.
     

См. также:
     
     формат пакета ЗАПРОС ЗАВЕРШЕНИЯ (п.12.2.3 и черт.13);
     
     тайм-аут "ответ на запрос завершения" (Т23) (табл.32);
     
     счет повторных передач запроса завершения (Р23) (табл.33);
     
     факультативная услуга пользователя "быстрая выборка" (п.13.16);
     
     прием индикации завершения (п.5.5.2);
     
     конфликт встречных завершений (п.5.5.3);
     
     подтверждение завершения (п.5.5.4).
     

5.5.2. Прием индикации завершения виртуального соединения
     
     Прием пакета ИНДИКАЦИЯ ЗАВЕРШЕНИЯ указывает на завершение виртуального соединения. В это время логический канал находится в состоянии ИНДИКАЦИЯ ЗАВЕРШЕНИЯ (р7). В этом состоянии ООД воспринимает последующее поступление по данному логическому каналу любых пакетов, кроме другого пакета ИНДИКАЦИЯ ЗАВЕРШЕНИЯ, как ошибку. Оно аннулирует любой такой пакет и передает пакет ЗАПРОС ЗАВЕРШЕНИЯ с указанием причины "по инициативе ООД" и диагностики "недействительный тип пакета для состояния р7".
     
     Пакет ИНДИКАЦИЯ ЗАВЕРШЕНИЯ определяет причину завершения. Код причины завершения, код диагностики и сообщение о выполнении процедуры завершения передаются логическому объекту вышерасположенного уровня. Любые данные и информация о факультативных услугах пользователя, принятые в пакете ИНДИКАЦИЯ ЗАВЕРШЕНИЯ, также должны быть переданы логическому объекту вышерасположенного уровня.
     
     Примечание. В конфигурации ООД/ООД пакет ИНДИКАЦИЯ ЗАВЕРШЕНИЯ, полученный одним ООД, это тот же пакет ЗАПРОС ЗАВЕРШЕНИЯ, который передан другим ООД.
     
     
     После обработки пакета ИНДИКАЦИЯ ЗАВЕРШЕНИЯ ООД передает через интерфейс ООД/ХХД пакет ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ.
     

См. также:
     
     формат пакета ИНДИКАЦИЯ ЗАВЕРШЕНИЯ (п.12.2.3 и черт.13);
     
     причина завершения (п.12.2.3);
     
     конфликт встречных завершений (п.5.5.3);
     
     подтверждение завершения (п.5.5.4);
     
     тайм-ауты, учитываемые при приеме пакета ИНДИКАЦИЯ ЗАВЕРШЕНИЯ (табл.34).
     

5.5.3. Конфликт встречных завершений
     
     Конфликт встречных завершений происходит, когда ООД передает пакет ЗАПРОС ЗАВЕРШЕНИЯ (в соответствии с п.5.5.1) и затем получает пакет ИНДИКАЦИЯ ЗАВЕРШЕНИЯ (в соответствии с п.5.5.2) для того же логического канала. В этом случае ООД ничего не передает и не ожидает поступления пакета ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ, а считает, что завершение выполнено.
     
     Если процедура завершения выполнена, то логический канал входит в состояние ГОТОВНОСТЬ (р1).
     

5.5.4. Подтверждение завершения
     
     Если ООД готово подтвердить завершение, оно передает через интерфейс ООД/ХХД пакет ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ. В это время процедура завершения считается выполненной.
     
     Инициировав процедуру завершения, ООД будет считать ее выполненной после приема пакета ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ.
     
     После выполнения процедуры завершения логический канал входит в состояние ГОТОВНОСТЬ (р1).
     
     В сетевой конфигурации пакет ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ, поступивший от АКД, всегда может рассматриваться как имеющий только локальную значимость. Однако в некоторых сетях подтверждение завершения может иметь межконцевую значимость.
     

См. также:
     
     формат пакета ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ (п.12.2.4 и черт.14).
     
     

6. ПРОЦЕДУРЫ ПЕРЕДАЧИ ДАННЫХ И ПРЕРЫВАНИЯ

     Описываемые в данном разделе процедуры передачи данных и прерываний применяются независимо для каждого из логических каналов, назначенных для виртуальных соединений или постоянных виртуальных каналов, существующих на интерфейсе ООД/ХХД.
     
     Для нормального выполнения операций необходимо, чтобы все данные пользователя в пакетах ДАННЫЕ и ПРЕРЫВАНИЕ передавались в "прозрачном" и неизменном виде либо непосредственно, либо через сеть в случае обмена данными между ООД, работающими в пакетном режиме. Расположение бит в пакетах ДАННЫЕ и ПРЕРЫВАНИЕ сохраняется неизменным. Последовательности пакетов должны доставляться как полные последовательности.
     

См. также:
     
     формат пакета ДАННЫЕ (п.12.3.1 и черт.15);
     
     формат пакета ПРЕРЫВАНИЕ (п.12.3.2 и черт.16);
     
     полные последовательности пакетов (п.6.5).
     

6.1. Состояния при передаче данных и прерывании
     
     Для передачи данных и прерываний логический канал должен находиться в состоянии ГОТОВНОСТЬ К УПРАВЛЕНИЮ ПОТОКОМ (d1). Логический канал виртуального соединения входит в состояние d1 после выполнения установления соединения и до инициации процедур завершения, повторной установки или повторного пуска. Логический канал постоянного виртуального канала постоянно находится в состоянии d1, кроме периодов выполнения процедуры повторной установки или повторного пуска.
     
     В состоянии d1 через интерфейс ООД/ХХД могут передаваться пакеты ДАННЫЕ, прерывания, управления потоком, повторной установки и НЕПРИЕМ (если он абонирован). В других состояниях вышеупомянутые пакеты могут аннулироваться. Поэтому логические объекты вышерасположенных уровней должны быть способны справляться с различными возможными здесь ситуациями.
     

См. также:
     
     процедуры повторного пуска (разд.4);
     
     процедуры установления соединения (п.5.2);
     
     процедуры завершения (п.5.5);
     
     процедуры управления потоком (п.7.1);
     
     процедуры повторной установки (разд.8);
     
     неполучение информации о продвижении окна (п.11.2);
     
     получение пакетов ДАННЫЕ с ошибками (п.11.3.);
     

факультативная услуга пользователя "повторная передача пакетов" (п.13.4).
     

6.2. Максимальная длина поля "данные пользователя" пакетов ДАННЫЕ
     
     Рекомендуемая стандартная максимальная длина поля "данные пользователя" составляют 128 октетов.
     
     Кроме того, могут использоваться другие (нестандартные) рекомендуемые максимальные длины этого поля, выбираемые из следующего набора значений: 16, 32, 64, 256, 512, 1024, 2048 и 4096 октетов.
     
     Для каждого направления передачи данных максимальная длина данных пользователя должна выбираться из набора стандартных и нестандартных (если они абонированы) рекомендуемых значений. При использовании виртуальных соединений такой выбор производится в целом для всех логических каналов интерфейса ООД/ХХД. При использовании постоянных виртуальных каналов этот выбор производится отдельно для каждого логического канала. Выбираемые варианты согласовываются с ХХД на определенный период времени. Кроме того, если услуга "согласование параметра управления потоком" абонирована, то допускается производить согласование максимальной длины поля "данные пользователя" для каждого виртуального соединения.
     
     В пакетах ДАННЫЕ, передаваемых ООД, поле "данные пользователя" должно содержать целое число октетов (см. п.12.1).
     
     Если поле "данные пользователя" превышает локально-допустимую максимальную длину этого поля или если оно не кратно октету, то принимающее ООД будет привлекать соответствующие процедуры восстановления при ошибках.
     

См. также:
     
     факультативная услуга пользователя "рекомендуемые нестандартные размеры пакета" (п.13.9);
     
     факультативная услуга пользователя "согласование параметров управления потоком" (п.13.12);
     
     получение пакетов ДАННЫЕ с ошибками (п.11.3).
     

6.3. Бит подтверждения доставки
     
     Установка бита подтверждения доставки (бита Д) используется для того, чтобы сообщить о желании ООД получить межконцевые подтверждения доставки переданных им данных. Чтобы указать те данные, для которых ООД желает получить межконцевое подтверждение доставки, оно должно установить бит Д в значение 1. Подтверждение осуществляется посредством порядкового номера принимаемых пакетов Ппм. Если бит равен 0, то принимаемые затем номера Ппм не рассматриваются как подтверждение доставки.
     
     Примечания:
     

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

2. Установка бита Д определяется на основе инструкций, получаемых от логического объекта вышерасположенного уровня.
     
     
     Ниже излагается факультативный механизм, который ООД может использовать во время установления виртуального соединения с целью согласования вопроса использования бита Д в состоянии ГОТОВНОСТЬ К УПРАВЛЕНИЮ ПОТОКОМ (d1).
     
     Если вызывающее ООД желает использовать процедуру бита Д, оно должно установить бит 7 идентификатора общего формата пакета ЗАПРОС ВЫЗОВА в значение 1; в противном случае оно должно установить этот бит в значение 0. Если вызываемое ООД желает использовать процедуру бита Д и оно получило пакет ВХОДЯЩИЙ ВЫЗОВ, в котором бит 7 идентификатора общего формата равен 0, оно должно установить этот бит в пакете ВЫЗОВ ПРИНЯТ в значение 1; в противном случае оно должно установить этот бит в значение 0.
     
     При использовании этой процедуры бит 7 идентификатора общего формата в пакетах ВЫЗОВ ПРИНЯТ и СОЕДИНЕНИЕ УСТАНОВЛЕНО в значении 1 указывает, что процедура бита Д (см. п.7.1.4) используется для виртуального соединения. Если же бит 7 установлен в значение 0, то ООД должно устанавливать бит Д в значение 0 во всех пакетах ДАННЫЕ.
     
     Если ООД не желает использовать процедуру бита Д, но получает пакет ДАННЫЕ с битом Д, равным 1, это ООД должно осуществить повторную установку логического канала, указав причину "по инициативе ООД" и диагностику "не обеспечена процедура бита Д".
     

См. также:
     
     порядковый номер приема пакетов Ппм (п.7.13);
     
     подтверждение доставки (п.7.1.4);
     
     процедуры установления виртуального соединения (п.5.2);
     
     процедуры повторной установки (разд.8).
     

6.4. Маркер "дополнительные данные"
     
     Если ООД или ХХД желает указать последовательность из нескольких пакетов ДАННЫЕ, оно использует маркер
"дополнительные данные" (бит М) в соответствии с тем, что:
     
     бит М может быть установлен в значение 1 в любом пакете ДАННЫЕ, кроме неполного пакета ДАННЫЕ с битом Д, равным 0. Если бит М равен 1 либо в полном пакете ДАННЫЕ, либо в неполном пакете ДАННЫЕ, но с битом Д, равным 1, это означает что последуют дополнительные данные. Объединение пакета ДАННЫЕ с последующим пакетом ДАННЫЕ может быть выполнено в сети только в том случае, если в полном пакете ДАННЫЕ бит М установлен в 1, а бит Д - в 0;
     

последовательность пакетов ДАННЫЕ, в каждом из которых, кроме последнего, бит М равен 1, будет доставлена как последовательность пакетов ДАННЫЕ с битом М, равным 1, в каждом пакете, кроме последнего, если исходные пакеты с битом М, равным 1, являются либо полными (независимо от значения бита Д), либо неполными, но с битом Д, равным 1. В области применения настоящего стандарта такие последовательности используются для разграничения логических сообщений, передаваемых между логическими объектами вышерасположенного уровня. Такие последовательности называются последовательностями бита М. Для последовательностей бита М на черт.6 показаны взаимоотношения между значениями битов Д и М и полнотой поля "данные пользователя" пакетов ДАННЫЕ.
     
     

Черт.6. Образование последовательности пакетов

Образование последовательности пакетов

Полная последовательность пакетов содержит ноль или несколько пакетов ДАННЫЕ категории "А" плюс один пакет ДАННЫЕ категории "Б".
     
     

Бит Д	Бит М	Поле "данные пользователя"	Примечания
0	1	Полное	Пакет ДАННЫЕ категории "А"
1	1	Меньше полного	Пакет ДАННЫЕ категории "Б", который одновременно помечает конец ППП, но не конец ПБМ
1	1	Полное
0	0	Меньше полного	Пакет ДАННЫЕ категории "Б", который одновременно помечает конец ППП и ПБМ
0	0	Полное
0	1*	Меньше полного
1	0	Меньше полного
1	0	Полное

________________
     * Сеть установит этот бит М в значение 0; следовательно, ООД никогда не должно инициировать этот пакет категории "Б". Если ООД получает пакет этого типа, то оно выполнит повторную установку логического канала с указанием причины "по инициативе ООД" и диагностики "недействительный неполный пакет ДАННЫЕ".
     
     Условные обозначения:
     
     Бит М - бит ДОПОЛНИТЕЛЬНЫЕ ДАННЫЕ;
     
     Бит Д - бит ПОДТВЕРЖДЕНИЕ ДОСТАВКИ;
     
     ППП - полная последовательность пакетов;
     
     ПБМ - последовательность бита М.
     

Черт.6

     
     В табл.2 определены две категории пакетов ДАННЫЕ: А и Б, а также показано восприятие сетью битов Д и М для виртуального соединения или постоянного виртуального канала. ООД не должно передавать неполный пакет ДАННЫЕ с битом М, равным 1, и с битом Д, равным 0. При получении такого пакета ООД должно выполнить повторную установку логического канала, указав причину "по инициативе ООД" и диагностику "недействительный неполный пакет ДАННЫЕ".
     

См. также:
     
     сегментирование и сборка сообщений (п.6.7);
     
     процедуры повторной установки (разд.8).
     
     

Таблица 2

Определение двух категорий пакетов данных и обработка сетью битов М и Д

Пакет ДАННЫЕ, полученный от ООД-отправителя				Объединение с последующим(и) пакетом(ами) выполняется сетью по возможности	Пакет ДАННЫЕ, переданный ООД-получателю*
Категория	М	Д	Полный		М	Д
Б	0 или 1	0	Нет	Нет	0**	0
Б	0	1	Нет	Нет	0	1
Б	1	1	Нет	Нет	1	1
Б	0	0	Да	Нет	0	0
Б	0	1	Да	Нет	0	1
А	1	0	Да	Да***	1	0
Б	1	1	Да	Нет	1	1

________________
     * Относится к доставленному пакету ДАННЫЕ, у которого последний бит данных пользователя соответствует последнему биту данных пользователя (при его наличии), переданному в пакете ДАННЫЕ ООД-отправителем.
     
     ** Сеть-отправитель будет устанавливать бит М в значение 0.
     
     *** Если пакет ДАННЫЕ, посланный ООД-отправителем, объединяется с другими пакетами, в том числе с пакетами категории Б, то значения битов М и Д в пакете ДАННЫЕ, устанавливаемые ООД-получателем, будут соответствовать их значениям, приведенным в двух правых колонках таблицы для последнего пакета ДАННЫЕ, переданного ООД-отправителем и входящего в состав объединяемых пакетов.
     
     

6.5. Полная последовательность пакетов
     
     Последовательность пакетов считается полной, если она содержит один пакет категории Б и все предшествующие непрерывно следующие пакеты категории А (при их наличии). Пакеты категории А содержат поле "данные пользователя" максимальной длины с битом М, равным 1 и битом Д, равным 0. Все остальные пакеты ДАННЫЕ - это пакеты категории Б. Для полной последовательности пакетов на черт.6 показана взаимосвязь между значениями битов М и Д и полнотой полей "данные пользователя" пакетов ДАННЫЕ.
     
     При передаче полной последовательности пакетов ООД-отправителем она всегда доставляется ООД-получателю в виде одной полной последовательности пакетов (заметим, что одна последовательность бита М может содержать одну или несколько таких полных последовательностей пакетов).
     
     В остальной части данного подраздела рассматриваются операции сети по передаче и доставке пакетов в полной последовательности пакетов.
     
     Если принимающее ООД имеет большую максимальную длину поля "данные пользователя", чем передающее ООД, то при передаче в сети пакеты ДАННЫЕ полной последовательности пакетов будут объединяться. Они будут доставляться в полной последовательности пакетов, где каждый пакет, кроме последнего, имеет в точности максимальную длину поля "данные пользователя", бит М, равный 1, и бит Д, равный 0.
     
     Длина поля "данные пользователя" последнего пакета такой последовательности может быть меньше максимальной, а его биты М и Д могут иметь значения, указанные в табл.2.
     

Если максимальная длина поля "данные пользователя" одинакова в обоих ООД, то в пакетах ДАННЫЕ эти поля доставляются принимающему ООД точно такими, какими они были получены сетью, за следующим исключением. Если за полным пакетом ДАННЫЕ с битом М, равным 1, и битом Д, равным 0, следует пустой пакет ДАННЫЕ, то оба эти пакета могут объединиться, образовав единый полный пакет категории Б. Если же в последнем пакете полной последовательности пакетов, переданной ООД-отправителем, длина поля "данные пользователя" меньше максимальной, бит М равен 1, а бит Д равен 0 (что согласно настоящему стандарту запрещает ООД передавать пакет), то последний пакет полной последовательности пакетов, доставленной сетью принимающему ООД, должен иметь бит М, равный 0.
     
     Если у принимающего ООД максимальная длина поля "данные пользователя" меньше, чем у передающего ООД, то пакеты должны сегментироваться в сети. Биты М и Д будут устанавливаться сетью в соответствии с правилами сохранения полных последовательностей пакетов.
     

См. также:
     
     бит Д (п.6.3);
     
     последовательности бита М (п.6.4 и черт.6).
     

6.6. Бит-определитель
     
     В некоторых случаях для поля "данные пользователя" пакетов ДАННЫЕ может потребоваться специальный указатель, позволяющий различать два вида информации, переносимой в этом поле. Он может потребоваться, например, для дифференциации данных и управляющей информации. Подобный пример применения имеется в рекомендации Х.29 МККТТ. При необходимости механизма может быть использован указатель, называемый битом-определителем (бит Q).
     
     Использование бита Q факультативно. Если этот механизм не требуется, то бит Q устанавливается в значение 0. Если же механизм бита Q используется, то передающее ООД должно устанавливать этот бит во всех пакетах ДАННЫЕ полной последовательности пакетов в одинаковое значение (0 или 1). Конкретное значение бита Q в полной последовательности пакетов определяется инструкцией, получаемой от логического объекта вышерасположенного уровня. Точно так же установленное значение бита Q в каждой принятой полной последовательности пакетов передается логическому объекту вышерасположенного уровня.
     
     Полная последовательность пакетов, передаваемая с одинаковым значением бита Q во всех пакетах ДАННЫЕ, доставляется как полная последовательность пакетов со значением бита Q во всех пакетах ДАННЫЕ, определенным передающим ООД.
     

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

См. также:
     
     полные последовательности пакетов (п.6.5 и черт.6);
     
     нумерация пакетов (п.7.1.1.);
     
     процедуры повторной установки (разд.8).
     

6.7. Сегментирование и сборка сообщений
     
     Пакетный уровень обеспечивает службу передачи сообщений (называемых также последовательностями бита М) между равноправными логическими объектами вышерасположенного уровня. В ООД-отправителе пакетный уровень сегментирует (т.е. разделяет) сообщения на соответствующее число пакетов ДАННЫЕ и устанавливает значения битов Д, М и Q для каждого образуемого пакета. При этом он должен учитывать максимальную длину поля "данные пользователя", разрешенную для данного логического канала, значение бита Q и длину каждой полной последовательности пакетов, содержащейся в сообщении, а также наличие запроса на  межконцевое подтверждение сообщения. Если такое подтверждение запрошено, то в последнем пакете ДАННЫЕ сообщения бит Д устанавливается в значение 1.
     
     Примечание. Допускается сегментировать сообщения таким образом, чтобы в образуемых пакетах ДАННЫЕ поле "данные пользователя" имело нулевую длину.
     
     
     В принимающем ООД пакетный уровень осуществляет сборку полей "данные пользователя" пакетов ДАННЫЕ в сообщение. Образуемое сообщение передается логическому объекту вышерасположенного уровня с указанием длины каждой полной последовательности пакетов и значения бита Q в ней, а также необходимости выдачи логическим объектом вышерасположенного уровня подтверждения доставки сообщения.
     

См. также:
     
     максимальная длина поля "данные пользователя" пакетов ДАННЫЕ (п.6.2);
     
     бит Д (п.6.3);
     
     последовательности бита М (п.6.4 и черт.6);
     
     полные последовательности пакетов (п.6.5 и черт.6);
     
     бит Q (п.6.6);
     
     подтверждение доставки (п.7.1.4).
     

6.8. Процедуры прерывания
     
     Процедура прерывания позволяет ООД передавать данные удаленному ООД, не применяя к пакетам процедуры управления потоком. Эти данные содержатся в пакете ПРЕРЫВАНИЕ. Инициация процедуры прерывания и генерация данных происходит под управлением логического объекта вышерасположенного уровня. При приеме пакета ПРЕРЫВАНИЕ сигнал, информирующий о прерывании, передается вместе с данными логическому объекту вышерасположенного уровня.
     
     На черт.7 приведено схематическое представление процедуры прерывания.
     
     

Черт.7. Схема процедуры прерывания

Схема процедуры прерывания

Черт.7

Процедура прерывания может применяться только в состоянии ГОТОВНОСТЬ К УПРАВЛЕНИЮ ПОТОКОМ (d1). Следовательно, эта процедура отклоняется в результате выполнения процедур завершения (только виртуальных соединений), повторной установки или повторного пуска. В пределах состояния d1 существуют четыре состояния (по два для каждого направления передачи прерывания), относящихся к процедуре прерывания. Этими состояниями являются ГОТОВНОСТЬ К ПРЕРЫВАНИЮ ООД (i1), ПЕРЕДАНО ПРЕРЫВАНИЕ ООД (i2), ГОТОВНОСТЬ К ПРЕРЫВАНИЮ ХХД (j1) и ПЕРЕДАНО ПРЕРЫВАНИЕ ХХД (j2), показанные на черт.34. В табл.41 показаны действия, выполняемые ООД при приеме от ХХД пакетов прерывания, применительно к процедуре прерывания.
     
     Процедура прерывания не влияет на процедуры передачи данных и управления потоком, относящиеся к пакетам ДАННЫЕ для виртуального соединения и постоянного виртуального канала. Для заданного виртуального соединения или постоянного виртуального канала пакет ПРЕРЫВАНИЕ доставляется в том месте потока пакетов ДАННЫЕ, в котором было сгенерировано прерывание, или до этого места. Этот пакет должен быть обработан сразу при его получении.
     
     Пакет ПРЕРЫВАНИЕ может содержать до 32 октетов данных пользователя. Если длина поля "данные пользователя" в пакете ПРЕРЫВАНИЕ превышает 32 октета или оно не кратно октету, то принимающее ООД должно привлечь процедуру повторной установки.
     

6.8.1. Передача прерывания
     
     До передачи прерывания логический канал находится в состоянии ГОТОВНОСТЬ К ПРЕРЫВАНИЮ ООД (i1). Для передачи прерывания ООД посылает через интерфейс ООД/ХХД пакет ПРЕРЫВАНИЕ, определяющий логический канал и данные прерывающего пользователя, полученные от логического объекта вышерасположенного уровня, и начинает отсчет тайм-аута "ответ на прерывание" (Т26). В этот момент логический канал находится в состоянии ПЕРЕДАНО ПРЕРЫВАНИЕ ООД (i2). В этом состоянии ООД не может передавать следующий пакет ПРЕРЫВАНИЕ до тех пор, пока ранее выданный пакет ПРЕРЫВАНИЕ не будет подтвержден пакетом ПОДТВЕРЖДЕНИЕ ПРЕРЫВАНИЯ.
     
     Неполучение пакета ПОДТВЕРЖДЕНИЕ ПРЕРЫВАНИЯ до истечения тайм-аута Т26, отсчитываемого после передачи пакета ПРЕРЫВАНИЕ, рассматривается как ошибка. В этом случае ООД осуществляет повторную установку логического канала, указав причину "по инициативе ООД" и диагностику "истек тайм-аут прерывания".
     

См. также:
     
     формат пакета ПРЕРЫВАНИЕ (п.12.3.2 и черт.16);
     
     тайм-аут "ответ на прерывание" (Т26) (табл.32);
     
     процедуры повторной установки (разд.8);
     
     подтверждение прерывания (п.6.8.3).
     

6.8.2. Прием прерывания
     
     До получения прерывания логический канал находится в состоянии ГОТОВНОСТЬ К ПРЕРЫВАНИЮ ХХД (j1). Если ООД получает от ХХД пакет ПРЕРЫВАНИЕ, то логический канал входит в состояние ПЕРЕДАНО ПРЕРЫВАНИЕ ХХД (j2). В этом состоянии поступление следующего пакета ПРЕРЫВАНИЕ до подтверждения предыдущего пакета ПРЕРЫВАНИЕ рассматривается как ошибка. В этом случае ООД осуществляет повторную установку логического канала, указав причину "по инициативе ООД" и диагностику "неполномочное прерывание".
     
     Пакетный уровень передает логическому объекту вышерасположенного уровня индикацию прерывания и данные прерывающего пользователя.
     

См. также:
     
     процедуры повторной установки (разд.8);
     
     подтверждение прерывания (п.6.8.3);
     
     тайм-ауты, учитываемые при приеме пакета ПРЕРЫВАНИЕ (табл.34).
     

6.8.3. Подтверждение прерывания
     
     ООД подтверждает прием пакета ПРЕРЫВАНИЕ при первой возможности путем передачи через интерфейс ООД/ХХД пакета ПОДТВЕРЖДЕНИЕ ПРЕРЫВАНИЯ. В этот момент логический канал находится в состоянии ГОТОВНОСТЬ К ПРЕРЫВАНИЮ ХХД (j1).
     
     Если ООД после передачи пакета ПРЕРЫВАНИЕ получает пакет ПОДТВЕРЖДЕНИЕ ПРЕРЫВАНИЯ, то логический канал входит в состояние ГОТОВНОСТЬ К ПРЕРЫВАНИЮ ООД (i1). В этот момент ООД может передавать через интерфейс ООД/ХХД следующий пакет ПРЕРЫВАНИЕ.
     

См. также:
     
     формат пакета ПОДТВЕРЖДЕНИЕ ПРЕРЫВАНИЯ (п.12.3.3 и черт.17).
     

6.9. Транзитная задержка пакетов ДАННЫЕ
     
     Транзитная задержка является неотъемлемой характеристикой виртуального соединения или постоянного виртуального канала, общей для обоих направлений передачи. Транзитная задержка представляет собой задержку передачи пакета ДАННЫЕ, выраженную в средних значениях величины.
     
     Выбор транзитной задержки для каждого виртуального соединения и информирование вызывающего и вызываемого ООД о значении транзитной задержки, используемой для данного виртуального соединения, может быть выполнен посредством услуги "выбор и индикация транзитной задержки".
     

См. также:
     
     факультативная услуга пользователя "выбор и индикация транзитной задержки" (п.13.27).
     
     

7. ПРОЦЕДУРЫ УПРАВЛЕНИЯ ПОТОКОМ

     Описываемые в данном разделе процедуры, относящиеся к управлению потоком пакетов ДАННЫЕ, независимы для каждого логического канала, используемого для виртуального соединения или постоянного виртуального канала.
     
     Процедура управления потоком может использоваться только в состоянии ГОТОВНОСТЬ К УПРАВЛЕНИЮ ПОТОКОМ (d1). Следовательно, эта процедура отклоняется в результате выполнения процедуры завершения (только виртуальных соединений), повторной установки или повторного пуска. Внутри состояния d1 существуют четыре состояния (по два для каждого направления управления потоком), относящиеся к процедуре управления потоком. Этими состояниями являются ГОТОВНОСТЬ ХХД К ПРИЕМУ (f1), НЕГОТОВНОСТЬ ХХД К ПРИЕМУ (f2), ГОТОВНОСТЬ ООД К ПРИЕМУ (g1) и НЕГОТОВНОСТЬ ООД К ПРИЕМУ (g2), показанные на черт.35. В табл.42 определены действия, выполняемые ООД при получении от ХХД пакетов управления потоком, ДАННЫЕ и НЕПРИЕМ (если он разрешен) применительно к процедуре управления потоком.
     
     Процедура управления потоком не влияет на процедуры, применимые к пакетам ПРЕРЫВАНИЕ для виртуального соединения или постоянного виртуального канала.
     

7.1. Управление потоком
     
     На интерфейсе ООД/ХХД логического канала передача пакетов ДАННЫЕ происходит под раздельным управлением для каждого направления, которое санкционируется получателем. На черт.8 схематически показаны рассматриваемые здесь процедуры управления потоком.
     
     

Черт.8. Схема управления потоком

Схема управления потоком

Предполагаемый размер окна W=2

     А: можно передать столько последовательно пронумерованных пакетов ДАННЫЕ, сколько разрешено окном W - это пакеты 0 и 1     
     
         

     
     Б: Есть некоторые данные для передачи. Поскольку приняты все пакеты ДАННЫЕ, включая пакет 0, то следующий пакет, ожидаемый на приеме, является пакетом 1.
     
     

     
     А: Таким образом, получен пакет 0 и ожидается следующий пакет 1. Он уже внутри окна (и передан). Необходимо передвинуть границы окна так, чтобы пакет 1 оказался нижней границей, а пакет 2 - верхней границей. Теперь можно передать пакет 2.
     
     

Черт.8

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

См. также:
     
     тайм-ауты, учитываемые при приеме пакета ДАННЫЕ (табл.34).
     

7.1.1. Нумерация пакетов
     
     Каждому передаваемому через интерфейс ООД/ХХД пакету ДАННЫЕ в каждом направлении передачи данного виртуального соединения или постоянного виртуального канала присваивается порядковый номер.
     
     Порядковая нумерация пакетов ДАННЫЕ осуществляется по модулю 8. Порядковые номера пакетов циклически изменяются во всем диапазоне чисел от 0 до 7. Как вариант, на интерфейсе ООД/ХХД может быть обеспечена услуга расширенной порядковой нумерации пакетов. В этом случае порядковая нумерация пакетов ДАННЫЕ выполняется по модулю 128 и порядковые номера пакетов циклически изменяются во всем диапазоне чисел от 0 до 127. Для обоих направлений передачи данных модуль одинаков (8 или 128) и является общим для всех логических каналов логического объекта пакетного уровня.
     
     Только пакеты ДАННЫЕ содержат этот порядковый номер, который называется порядковым номером передачи пакета Ппд.
     
     Первый подлежащий передаче через интерфейс ООД/ХХД пакет ДАННЫЕ по данному направлению передачи данных сразу после входа логического канала в состояние ГОТОВНОСЬ К УПРАВЛЕНИЮ ПОТОКОМ (d1) имеет номер Ппд, равный нулю. Все последующие пакеты ДАННЫЕ нумеруются последовательно.
     

См. также:
     
     факультативная услуга пользователя "расширенная порядковая нумерация пакетов" (п.13.2).
     

7.1.2. Описание окна
     
     На интерфейсе ООД/ХХД логического канала, используемого для виртуального соединения или постоянного виртуального канала и для каждого направления передачи данных, окно определяется как упорядоченное (по модулю) множество То последовательных порядковых номеров передачи Ппд пакетов ДАННЫЕ, которым разрешено пересекать интерфейс.
     
     Порядковый номер передачи первого пакета окна То называется "нижней границей окна". Если виртуальное соединение или постоянный виртуальный канал только что вошел в состояние ГОТОВНОСТЬ К УПРАВЛЕНИЮ ПОТОКОМ (d1), то окно каждого направления передачи данных имеет нижнюю границу, равную нулю. "Верхняя граница окна" - это номер Ппд последнего из пакетов окна, которым разрешено пересекать интерфейс.
     

Номер Ппд первого пакета ДАННЫЕ, которому не разрешено пересекать интерфейс, равен значению нижней границы окна плюс То (по модулю 8 либо по модулю 128 при расширенной нумерации).
     
     Рекомендуемый стандартом размер окна То равен двум для каждого направления передачи данных на интерфейсе ООД/ХХД.
     
     Могут использоваться также другие (нестандартные) размеры окна.
     
     Для каждого направления передачи данных размер окна должен выбираться из стандартного рекомендуемого и перечня нестандартных (при их наличии) рекомендуемых значений. В случае виртуальных соединений этот выбор осуществляется в целом для всех логических каналов на интерфейсе ООД/ХХД. В случае постоянных виртуальных каналов этот выбор осуществляется отдельно для каждого логического канала. Выбранные значения согласовываются с ХХД на определенный период времени. Кроме того, допускается согласование размера окна для каждого виртуального соединения, если выбрана услуга "согласование параметров управления потоком".
     

См. также:
     
     факультативная услуга пользователя "рекомендуемые нестандартные размеры окна" (п.13.10);
     
     факультативная услуга пользователя "согласование параметров управления потоком" (п.13.12).
     

7.1.3. Принципы управления потоком
     
     Если порядковый номер Ппд очередного пакета ДАННЫЕ, который должно передать ООД или ХХД, находится в пределах окна, то ООД или ХХД имеет право передать этот пакет. Если же номер Ппд очередного подлежащего передаче пакета ДАННЫЕ находится за пределами окна, то ООД или ХХД не должно передавать этот пакет через интерфейс ООД/ХХД.
     
     Если порядковый номер Ппд пакета ДАННЫЕ, полученного ООД или ХХД, является следующим по порядку и находится в пределах окна, то ООД или ХХД должно принять этот пакет. Поступление пакета ДАННЫЕ, у которого номер Ппд либо не является очередным (т.е. в нумерации Ппд образовалось дублирование или пробел), либо он находится за пределами окна, либо не равен нулю у первого пакета ДАННЫЕ после входа в состояние ГОТОВНОСТЬ К УПРАВЛЕНИЮ ПОТОКОМ (d1), рассматривается ООД или ХХД как процедурная ошибка. АКД в конфигурации ООД/АКД должна осуществить повторную установку логического канала, указав причину "локальная процедурная ошибка", а ООД - повторную установку логического канала, указав причину "по инициативе ООД". В любом случае поле диагностики должно иметь значение "недействительный Ппд".
     
     Если полученный пакет ДАННЫЕ имеет номер Ппд, который не является очередным, но находится в пределах окна, то в качестве альтернативного варианта ООД может использовать процедуры б) или в) п.11.3.
     

Номер Ппм (отсчитываемый по модулю 8 либо 128 при расширенной нумерации), называемый порядковым номером приема пакетов, передает через интерфейс ООД/ХХД информацию получателя для передачи пакетов ДАННЫЕ. При прохождении через интерфейс ООД/ХХД правильный номер Ппм (определенный ниже) становится нижней границей окна. Подобным способом получатель может разрешать прохождение через интерфейс ООД/ХХД дополнительных пакетов ДАННЫЕ.
     
     Порядковый номер приема пакетов Ппм передается в пакетах ДАННЫЕ ГОТОВНОСТЬ К ПРИЕМУ (ГПР), НЕГОТОВНОСТЬ К ПРИЕМУ (НГПР) и НЕПРИЕМ (НПР) (если он абонирован).
     
     Значение полученного номера Ппм должно превышать или быть равным последнему номеру Ппм, принятому ООД или ХХД, и быть меньше или равно номеру Ппд следующего пакета ДАННЫЕ, подлежащего передаче этим ООД или ХХД. Если это требование не выполнено, то ООД или ХХД должно рассматривать получение этого Ппм как процедурную ошибку и выполнить повторную установку логического канала. При этом АКД должна указать причину "локальная процедурная ошибка", а ООД - "по инициативе ООД". В любом случае поле диагностики должно иметь значение "недействительный Ппм".
     
     Номер Ппм, возвращаемый в любом из вышеуказанных пакетов, будет меньше или равен номеру Ппд (отсчитываемому по модулю 8, либо 128 при расширенной нумерации) следующего ожидаемого пакета ДАННЫЕ. Это означает, что ООД или ХХД, передающее номер Ппм, получило, по меньшей мере, все пакеты ДАННЫЕ с номерами до (Ппм-1) включительно.
     

См. также:
     
     пакет ГОТОВНОСТЬ К ПРИЕМУ (п.7.1.5);
     
     пакет НЕГОТОВНОСТЬ К ПРИЕМУ (п.7.1.6);
     
     процедуры повторной установки (разд.8);
     
     прием пакетов ДАННЫЕ с ошибками (п.11.3);
     
     факультативная услуга пользователя "повторная передача пакетов" (п.13.4);
     
     факультативная услуга пользователя "расширенная порядковая нумерация пакетов" (п.13.2).
     

7.1.4. Подтверждение доставки
     
     Если бит Д в пакете ДАННЫЕ с номером Ппд=р равен 0, то значение возвращенного номера Ппм, соответствующего этому пакету ДАННЫЕ (т.е. Ппмр+1), представляет собой локальное обновление окна через интерфейс пакетного уровня. В конфигурации ООД/АКД возвращенный номер Ппм не означает, что он поступил от удаленного ООД. Более того, достижимая пропускная способность не ограничивается задержкой кругового обхода по сети(ям) между двумя ООД.
     
     Если в пакете ДАННЫЕ с номером Ппд=р бит Д равен 1, то возвращение Ппм, соответствующего этому пакету ДАННЫЕ (т.е. Ппмр+1) означает, что Ппм, получен от удаленного ООД для всех битов данных пакета ДАННЫЕ, в котором бит Д был первоначально равен 1.
     
     Если ООД не желает использовать процедуру бита Д, но получает пакет ДАННЫЕ с битом Д, равным 1, то оно должно повторно установить логический канал с кодом причины "по инициативе ООД" и с кодом диагностики "не обеспечена процедура бита Д".
     
     Для достижения более высокой надежности ООД могут использовать процедуру бита Д для извещения о получении данных логическим объектом вышерасположенного уровня. Такое использование бита Д должно быть предварительно согласовано между двумя ООД. При использовании этой процедуры передающий пакетный уровень устанавливает бит Д последнего пакета ДАННЫЕ из последовательности бита М в значение 1, если со стороны логического объекта вышерасположенного уровня требуется межконцевое подтверждение приема. При приеме последнего из последовательности бита М пакета ДАННЫЕ с битом Д в значении 1 пакетный уровень не должен возвращать соответствующий номер Ппм до тех пор, пока данные в этом пакете не будут подтверждены логическим объектом вышерасположенного уровня (вопрос о том, должен ли пакетный уровень ждать от вышерасположенного уровня подтверждения данных в пакете ДАННЫЕ с битом Д, равным 1, когда этот пакет не является последним в последовательности бита М, является предметом дальнейшего изучения). При получении такого подтверждения пакетный уровень должен вернуть этот номер Ппм как можно быстрее (например, не дожидаясь других пакетов ДАННЫЕ), чтобы предотвратить возможные тупиковые ситуации. Пакет ДАННЫЕ, ГПР, НГПР или НЕПРИЕМ (если он разрешен) может использоваться для передачи номера Ппм (см. примеч.2 к п.7.1.6). Точно так же в сетевой конфигурации АКД должна передать ООД номер Ппм как можно быстрее после его приема от удаленного ООД.
     
     Примечания:
   

1. Если пакет ДАННЫЕ с номером Ппм и битом Д, равным 1, не подтвержден, то локальное обновление окна на интерфейсе ООД/АКД будет отложено до последующих пакетов ДАННЫЕ с битом Д, равным 0. Некоторые сети также могут откладывать обновление окна для предыдущих пакетов ДАННЫЕ (в пределах окна) с битом Д, равным 0, до тех пор, пока в ООД не будет передан соответствующий номер Ппм для пакета с неподтвержденным битом Д, равным 1.
     

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

3. Если ООД передало пакеты ДАННЫЕ с битом Д, равным 0, то для инициации процедуры повторной установки или процедуры завершения оно не должно дожидаться локального обновления окна.
     
     

См. также:
     
     бит Д (п.6.3);
     
     последовательность бита М (п.6.4);
     
     процедуры повторной установки (разд.8);
     
     процедуры завершения (п.5.5).
     

7.1.5. Пакеты ГОТОВНОСТЬ К ПРИЕМУ (ГПР)
     
     Пакеты ГОТОВНОСТЬ К ПРИЕМУ (ГПР) используется как ООД, так и ХХД для указания их готовности принять То пакетов ДАННЫЕ в пределах окна, начиная с номера Ппм, указанного в пакете ГПР.
     
     Примечание. Передачу пакета ГПР с конкретным значением Ппм не следует рассматривать как запрос повторной передачи уже переданных пакетов ДАННЫЕ.
     
     

См. также:
     
     формат пакета ГОТОВНОСТЬ К ПРИЕМУ (п.12.4.1 и черт.18).
     

7.1.6. Пакеты НЕГОТОВНОСТЬ К ПРИЕМУ (НГПР)
     
     Пакеты НЕГОТОВНОСТЬ К ПРИЕМУ (НГПР) используются как ООД, так и ХХД для информирования о временной неготовности принимать дополнительные пакеты ДАННЫЕ по рассматриваемому виртуальному соединению или постоянному виртуальному каналу. При приеме пакета НГПР ООД или ХХД прекращает передачу пакетов ДАННЫЕ по указанному логическому каналу, но обновляет окно значением Ппм принятого пакета НГПР, если это значение Ппм действительное. Ситуация неготовности к приему, указанная передачей пакета НГПР, завершается передачей в том же направлении пакета ГОТОВНОСТЬ К ПРИЕМУ или НЕПРИЕМ (если он абонирован), либо путем инициации процедуры повторной установки.
     
     Примечания:
     

1. Передачу пакета ГПР после передачи НГПР не следует рассматривать как требование повторной передачи ранее переданных пакетов ДАННЫЕ.
     

2. Пакет НГПР может быть использован для передачи через интерфейс ООД/ХХД значения Ппм, соответствующего пакету ДАННЫЕ с битом Д, равным 1, в том случае, когда дополнительные пакеты ДАННЫЕ не могут быть приняты.
     
     

См. также:
     
     формат пакета НЕГОТОВНОСТЬ К ПРИЕМУ (п.12.4.2 и черт.19);
     
     пакет ГОТОВНОСТЬ К ПРИЕМУ (п.7.1.5);
     
     процедуры повторной установки (разд.8).
     

7.2. Характеристики пропускной способности и классы пропускной способности
     
     Класс пропускной способности для определенного направления передачи является неотъемлемой характеристикой виртуального соединения и постоянного виртуального канала относительно объема ресурсов, выделенных для этого виртуального соединения или постоянного виртуального канала. Эта характеристика является мерой пропускной способности в устойчивом состоянии, которая может быть обеспечена при наличии оптимальных условий в виртуальном соединении или в постоянном виртуальном канале. Однако из-за статистического характера коллективного использования связных и коммутационных ресурсов не гарантируется, что данный класс пропускной способности будет обеспечиваться в течение всего времени работы.
     
     К оптимальным условиям измерения относятся следующие:
     

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

б) размеры окон на локальном и удаленном интерфейсах не налагают ограничений на пропускную способность;
     

в) характеристики трафика других логических каналов на локальном и удаленном интерфейсах не налагают ограничений на пропускную способность;
     

г) принимающее ООД не управляет потоком данных ХХД, в результате чего класс пропускной способности не обеспечивается;
     

д) передающее ООД посылает только пакеты ДАННЫЕ, имеющие максимальную длину поля "данные пользователя";
     

е) бит Д не установлен в значение 1.
     
     Класс пропускной способности измеряется в бит/с. На интерфейсе ООД/ХХД максимальная длина поля "данные пользователя" определяется для виртуального соединения или постоянного виртуального канала и, таким образом, класс пропускной способности может восприниматься ООД как скорость передачи полных пакетов ДАННЫЕ (пакет/с) на интерфейсе ООД/ХХД.
     
     В отсутствии услуги "назначение рекомендуемых классов пропускной способности" рекомендуемые классы пропускной способности для обоих направлений передачи данных соответствуют пользовательскому классу услуг ООД (т.е. скорости передачи сигналов данных), но не превышают класса максимальной пропускной способности, обеспечиваемого ХХД. Кроме того, допускается согласование классов пропускной способности по каждому виртуальному соединению, если абонирована услуга "согласование класса пропускной способности".
     
     Примечание 2. Суммарное по всем классам значение пропускной способности для всех логических каналов виртуальных соединений и постоянных виртуальных каналов, обеспечиваемых на интерфейсе ООД/ХХД, может превышать значение скорости передачи данных по данной линии доступа.