ГОСТ Р 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. ССЫЛОЧНЫЕ НОРМАТИВНО-ТЕХНИЧЕСКИЕ ДОКУМЕНТЫ
     

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

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

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 до 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

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

Taблица 1

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

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

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

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

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

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

Черт.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 показаны взаимоотношения между значениями битов Д и М и полнотой поля "данные пользователя" пакетов ДАННЫЕ.
     
     

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

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

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

Черт.6

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

Таблица 2

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

________________
     * Относится к доставленному пакету ДАННЫЕ, у которого последний бит данных пользователя соответствует последнему биту данных пользователя (при его наличии), переданному в пакете ДАННЫЕ ООД-отправителем.
     
     ** Сеть-отправитель будет устанавливать бит М в значение 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

     Процедура прерывания может применяться только в состоянии ГОТОВНОСТЬ К УПРАВЛЕНИЮ ПОТОКОМ (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 схематически показаны рассматриваемые здесь процедуры управления потоком.
     
     

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

     
Предполагаемый размер окна 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. Суммарное по всем классам значение пропускной способности для всех логических каналов виртуальных соединений и постоянных виртуальных каналов, обеспечиваемых на интерфейсе ООД/ХХД, может превышать значение скорости передачи данных по данной линии доступа.
     
     
     См. также:
     
     бит Д (пп 6.3 и 7.1.4);
     
     процедуры управления потоком (разд.7);
     
     факультативная услуга пользователя "назначение рекомендуемых классов пропускной способности" (п.13.11);
     
     факультативная услуга пользователя "согласование класса пропускной способности" (п.13.13).
     
     

8. ПРОЦЕДУРЫ ПОВТОРНОЙ УСТАНОВКИ

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

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

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

Черт.9

     
     Процедура повторной установки может использоваться только в состоянии ПЕРЕДАЧА ДАННЫХ (р4). В любом другом состоянии процедура повторной установки отклоняется. Например, при инициации процедуры завершения (только виртуальных соединений) или процедуры повторного пуска пакеты ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ и ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ остаются неподтвержденными. В рамках состояния р4 существуют три следующих состояния, относящиеся к процедуре повторной установки и показанные на черт.33: ГОТОВНОСТЬ К УПРАВЛЕНИЮ ПОТОКОМ (d1), ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ ООД (d2) и ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ ХХД (d3). Когда логический канал виртуального соединения входит в состояние р4, он оказывается в состоянии d1. Логический канал постоянного виртуального канала постоянно находится в состоянии d1, кроме периода выполнения процедуры повторной установки или повторного пуска.
     
     Действия, выполняемые ООД при приеме пакетов от ХХД и относящиеся к процедуре повторной установки, показаны в табл.40.
     
     См. также:
     
     последовательность бита М (п.6.4 и черт.10);
     
     окно управления потоком (п.7.1.2);
     
     параметры тайм-аута (табл.32);
     
     параметры повторной передачи (черт.27).
     
     8.1. Индикация запроса повторной установки
     
     ООД может выдать запрос повторной установки в любой момент времени, передав через интерфейс ООД/ХХД пакет ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ, определяющий конкретный логический канал, и начав отсчет тайм-аута "ответ на запрос повторной установки" (Т22). Логический канал входит при этом в состояние ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ (d2). В этом состоянии ООД аннулирует все пакеты ДАННЫЕ, ПРЕРЫВАНИЕ, ПОДТВЕРЖДЕНИЕ ПРЕРЫВАНИЯ, ГОТОВНОСТЬ К ПРИЕМУ, НЕГОТОВНОСТЬ К ПРИЕМУ и НЕПРИЕМ, относящиеся к данному логическому каналу. Следовательно, логические объекты вышерасположенного уровня должны быть способны справляться с различными возникающими при этом ситуациями.
     
     Неполучение пакета ПОДТВЕРЖДЕНИЕ ПОВТОРНОЙ УСТАНОВКИ до истечения Т22 после передачи пакета ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ рассматривается как ошибка. Процедура повторной установки повторяет свои попытки максимум до R22 раз. После этого пакетный уровень завершает вызов для логического канала виртуального соединения, указав причину "по инициативе ООД" и диагностику "истек тайм-аут или превышен счет повторных передач запроса повторной установки". Пакетный уровень информирует об этом соответствующий логический объект логического канала постоянного виртуального канала; после этого логический канал остается в состоянии ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ ООД (d2).
     
     См. также:
     

     формат пакета ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ (п.12.5.1 и черт.20);
     
     тайм-аут "ответ на запрос повторной установки" (Т22) (табл.32);
     
     счет повторных передач запроса повторной установки (Р22) (табл.33);
     
     процедуры завершения (п.5.5);
     
     прием индикации повторной установки (п.8.2);
     
     конфликт встречных повторных установок (п.8.3);
     
     подтверждение повторной установки (п.8.4).
     
     8.2. Прием индикации повторной установки
     
     После получения пакета ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ указанный логический канал находится в состоянии ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ ХХД (d3). В этом состоянии ООД рассматривает последующее поступление любых пакетов ДАННЫЕ, ПРЕРЫВАНИЕ, ПОДТВЕРЖДЕНИЕ ПРЕРЫВАНИЯ, ГОТОВНОСТЬ К ПРИЕМУ, НЕГОТОВНОСТЬ К ПРИЕМУ или НЕПРИЕМ как ошибку. Оно аннулирует любой такой пакет и передает пакет ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ, указав причину "по инициативе ООД" и диагностику "недействительный тип пакета для состояния d3".
     
     Пакет ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ определяет причину повторной установки. Код причины повторной установки, диагностический код и извещение о выполнении процедуры повторной установки передаются логическому объекту вышерасположенного уровня.
     
     Примечание. В конфигурации ООД/ООД пакет ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ, получаемый одним ООД, это тот же пакет ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ, который был передан другим ООД.
     
     
     В конфигурации ООД/АКД при появлении в сети кратковременной неисправности из АКД поступит пакет ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ с указанием причины "перегрузка сети". Если сеть временно неспособна обработать трафик данных, то из АКД поступит пакет ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ с указанием причины "сеть вышла из строя". Когда сеть снова сможет обрабатывать трафик данных, постоянный виртуальный канал будет повторно установлен с указанием причины "сеть работоспособна".
     
     После обработки пакета ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ ООД передает через интерфейс ООД/ХХД пакет ПОДТВЕРЖДЕНИЕ ПОВТОРНОЙ УСТАНОВКИ.
     
     См. также:
     
     формат пакета ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ (п.12.5.1. и черт.20);
     
     причина повторной установки (п.12.5.1);
     
     конфликт встречных повторных установок (п.8.3);
     
     подтверждение повторном установки (п.8.4);
     
     тайм-ауты, учитываемые при приеме пакета ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ (табл.34).
     
     8.3. Конфликт встречных повторных установок
     
     Конфликт встречных повторных установок возникает в том случае, когда ООД передает пакет ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ (см. п.8.1) и затем принимает для одного и того же логического канала пакет ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ (как описано в п.8.2). В этом случае ООД не передает пакет ПОДТВЕРЖДЕНИЕ ПОВТОРНОЙ УСТАНОВКИ, не ожидает его поступления и считает, что повторная установка выполнена.
     
     Если процедура повторной установки выполнена, то логический канал входит в состояние ГОТОВНОСТЬ К УПРАВЛЕНИЮ ПОТОКОМ (d1).
     
     8.4. Подтверждение повторной установки
     
     Если ООД готово подтвердить повторную установку, оно передает через интерфейс ООД/ХХД пакет ПОДТВЕРЖДЕНИЕ ПОВТОРНОЙ УСТАНОВКИ. С этого момента процедура повторной установки считается выполненной.
     
     Инициировав процедуру повторной установки, ООД будет считать ее выполненной после приема пакета ПОДТВЕРЖДЕНИЕ ПОВТОРНОЙ УСТАНОВКИ.
     
     После выполнения процедуры повторной установки логический канал входит в состояние ГОТОВНОСТЬ К УПРАВЛЕНИЮ ПОТОКОМ (d1).
     
     В сетевой конфигурации принятый из АКД пакет ПОДТВЕРЖДЕНИЕ ПОВТОРНОЙ УСТАНОВКИ может рассматриваться во всех случаях как имеющий локальную значимость. Однако в некоторых сетях подтверждение повторной установки может иметь межконцевую значимость.
     
     См. также:
     
     формат пакета ПОДТВЕРЖДЕНИЕ ПОВТОРНОЙ УСТАНОВКИ (п.12.5.2 и черт.21).
     
     

9. ВЛИЯНИЕ ПРОЦЕДУР ЗАВЕРШЕНИЯ, ПОВТОРНОЙ УСТАНОВКИ
И ПОВТОРНОГО ПУСКА НА ПЕРЕДАЧУ ПАКЕТОВ

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

10. ВЛИЯНИЕ УРОВНЕЙ 1 И 2 НА ПАКЕТНЫЙ УРОВЕНЬ

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

11. ОБРАБОТКА ОШИБОК

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

     неполучение соответствующего ответного пакета (например ПОДТВЕРЖДЕНИЕ ПРЕРЫВАНИЯ) после передачи пакета ПРЕРЫВАНИЕ и до истечения тайм-аута Т26;
     
     неполучение соответствующего ответного пакета (например ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ) после передачи пакета ЗАПРОС РЕГИСТРАЦИИ и до истечения тайм-аута Т28.
     
     Приведенные выше примеры не охватывают всех ошибочных ситуаций. Действия, выполняемые ООД при обнаружении синтаксической или логической ошибки, приведены в табл.37 ... 42. Действия, выполняемые ООД при обнаружении ошибки передачи, приведены в табл.32 и 33.
     
     11.1. Пакет ДИАГНОСТИКА
     
     Пакет ДИАГНОСТИКА применяется как в конфигурации ООД/АКД, так и в конфигурации ООД/ООД. Однако в первом случае передавать пакет ДИАГНОСТИКА может только АКД. ООД в конфигурации ООД/ООД может передавать пакет ДИАГНОСТИКА при условии, что оно способно подавлять его выдачу, будучи подключенным к сети.
     
     Пакет ДИАГНОСТИКА используется для информирования об ошибочных условиях в тех случаях, когда обычные методы информирования (т.е. повторная установка, завершение и повторный пуск с указанием причины и диагностики) неприменимы (см. табл.37 и 38). Пакет ДИАГНОСТИКА содержит информацию об ошибочных ситуациях, которые считаются неустранимыми на пакетном уровне. При получении пакета ДИАГНОСТИКА пакетный уровень посылает логическому объекту вышерасположенного уровня уведомление о его приеме и содержащуюся в нем информацию об ошибке.
     
     Пакет ДИАГНОСТИКА выдается только один раз для каждого случая возникновения ошибки. От ООД не требуется передавать подтверждения при приеме пакета ДИАГНОСТИКА.
     
     См. также:
     
     формат пакета ДИАГНОСТИКА (п.12.7 и черт.24);
     
     диагностические коды (табл.30 и 31);
     
     процедуры повторной установки (разд.8);
     
     процедуры завершения (п.5.5);
     
     процедуры повторного пуска (разд.4).
     
     11.2. Неполучение информации о продвижении окна
     
     Процедуры, описываемые в данном подразделе, могут быть факультативно реализованы в ООД для восстановления при неполучении информации о продвижении окна (т.е. неполучении Ппм) с целью продвижения окна после передачи пакетов ДАННЫЕ. Для обработки такой ситуации настоятельно рекомендуется использовать протокол вышерасположенного уровня, а не эти процедуры.
     
     Неполучение информации о продвижении окна с точки зрения ООД, передающего пакеты ДАННЫЕ, может произойти по следующим причинам:
     

     а) потеря переданных пакетов ДАННЫЕ в такой мере, что теряется смысл окна пакетов ДАННЫЕ (в случае возникновения подобных потерь передающее ООД не примет пакетов, продвигающих окно);
     
     б) потеря пакета с номером Ппм, продвигающим окно (пакетами, используемыми для переноса Ппм, являются ГПР, НГПР, ДАННЫЕ И НЕПРИЕМ (если он абонирован);
     
     в) число переданных пакетов ДАННЫЕ с битом Д, равным 0, меньше числа пакетов, образующих окно (в нормальных условиях от ООД требуется выполнять продвижение окна только для обеспечения класса пропускной способности и для подтверждения пакетов ДАННЫЕ с битом Д, равным 1);
     
     г) ХХД осуществляет управление потоком при помощи "закрытия" окна (т.е. без передачи пакета НГПР) во время приема пакетов ДАННЫЕ с битом Д, равным 0, из-за временного отсутствия ресурсов или по другим причинам.
     
     Неполучение информации о продвижении окна в зависимости от конкретной причины может привести к ситуации, в которой передающее ООД является "блокированным по управлению потоком" на пакетном уровне. Если окно уже закрыто, то передающее ООД не может более передавать пакеты ДАННЫЕ из-за наличия механизмов управления потоком, определенных в п.7.1. ООД остается "блокированным по управлению потоком" до тех пор, пока его окно передачи не будет продвинуто при отсутствии явного управления по потоку пакетом НГПР. По указанным выше причинам а) и б) ООД может оставаться блокированным по управлению потоком неопределенно долго. Эта ситуация известна как "блокирование управления потоком".
     
     См. также:
     
     описание окна (п.7.1.2);
     
     принципы управления потоком (п.7.1.3).
     
     11.2.1. Факультативные процедуры, передающего ООД
     
     Для эффективного восстановления при неполучении информации о продвижении окна ООД может начать отсчет тайм-аута продвижения окна (Т25) после передачи пакета ДАННЫЕ через интерфейс ООД/ХХД. При приеме Ппм, продвигающего окно, начинается повторный отсчет этого тайм-аута, если внутри окна еще остались переданные перед этим пакеты ДАННЫЕ, либо если после этого были переданы дополнительные пакеты ДАННЫЕ; в противном случае отсчет этого тайм-аута прекращается. Если до истечения Т25 не получен Ппм, продвигающий окно, то передающее ООД должно:
     
     а) повторно установить этот логический канал;
     

     б) повторно передать все переданные до этого пакеты ДАННЫЕ внутри окна и начать повторный отсчет тайм-аута. Если число повторных передач превысило предельное число Р25, ООД должно повторно установить этот логический канал.
     
     Примечания:
     
     1. Повторная передача пакетов ДАННЫЕ не должна касаться факультативной услуги пользователя "повторная передача пакета" или использования пакетов НЕПРИЕМ.
     
     2. Во всех случаях ООД (за исключением работы с одной из альтернативных процедур, описанных в п.11.3 б) и в), и АКД будут воспринимать поступление пакета ДАННЫЕ с номером Ппд, не являющимся очередным или расположенным вне окна, как процедурную ошибку, и будут повторно устанавливать этот логический канал.
     
     3. АКД или ООД, принимающее пакеты ДАННЫЕ, не гарантирует столь быстрого продвижения окна, чтобы предотвратить истечение тайм-аута Т25 в передающем ООД (например см. п.11.2 в) и г). Следовательно, описанной выше процедурой надо пользоваться с осторожностью.
     
     
     При повторной установке логического канала в соответствии с пп.а) и б) ООД указывает причину "по инициативе ООД" с диагностикой "истек тайм-аут или превышен счет повторных передач пакета ДАННЫЕ".
     
     См. также:
     
     тайм-аут продвижения окна (Т25) (табл.32);
     
     счет повторных передач пакета ДАННЫЕ (Р25) (табл.33);
     
     процедуры повторной установки (разд.8).
     
     11.2.2. Факультативные процедуры принимающего ООД
     
     Чтобы уменьшить вероятность потери пакета, сообщающего о продвижении окна, ООД может передавать пакет ГПР, НГПР, ДАННЫЕ или НЕПРИЕМ (если он абонирован) через каждый временной интервал Т24 (т.е. по истечении тайм-аута "передача состояния окна") пока логический канал находится в состоянии ГОТОВ К УПРАВЛЕНИЮ ПОТОКОМ (d1). Если с момента последней передачи пакета, сообщающего о продвижении окна, прошел период времени Т24, то передается пакет ГПР или НГПР. Переданный пакет должен отражать текущее состояние передающего ООД. Таким образом, если ООД не способно принять дополнительные пакеты ДАННЫЕ, то передается пакет НГПР, в противном случае передается пакет ГПР. Эти пакеты содержат номер Ппм, соответствующий самому последнему правильно принятому пакету ДАННЫЕ. Принятый номер Ппм становится нижней границей окна в передающем ООД.
     
     Изложенная выше процедура не исключает использование дополнительных алгоритмов продвижения окна. Эта процедура просто пытается обеспечить условия, при которых принятое решение о продвижении окна будет передано, даже если исходный пакет потерян.
     

     Примечание. В конфигурации ООД/АКД использование этой процедуры на одном интерфейсе ООД/АКД не может влиять на операции другого интерфейса ООД/АКД.
     
     
     См. также:
     
     тайм-аут "передача состояния окна" (Т24) (табл.32).
     
     11.3. Прием ошибочных пакетов ДАННЫЕ
     
     Для нормальной передачи данных требуется, чтобы пакеты ДАННЫЕ принимались по порядку, их длина не превышала максимально допустимой для текущей операции передач данных и чтобы они содержали целое число октетов в поле "данные пользователя". Поступление пакета ДАННЫЕ с неочередным номером Ппд (т.е. Ппдпоследний Ппд+1 по модулю 8 либо по модулю 128 при расширенной нумерации) с длиной поля "данные пользователя", превышающей максимально допустимую или не кратной октету, считается ошибкой.
     
     Для исправления описанных выше ошибок ООД имеет три следующих возможных варианта:
     
     а) проигнорировать ошибочный пакет ДАННЫЕ и повторно установить логический канал, указав причину "по инициативе ООД" и одну из следующих диагностик, в зависимости от ситуации:
     
     недействительный Ппд;
     
     слишком длинный пакет;
     
     поле данных не кратно октету;
     
     б) проигнорировать ошибочный пакет ДАННЫЕ и передать пакет НЕПРИЕМ с Ппм, равным ожидаемому Ппд, в следующем по порядку пакете ДАННЫЕ.
     
     Этот вариант может использоваться только при достижении соглашения с взаимодействующим ХХД об использовании услуги "повторная передача пакета". Кроме того, в конфигурации ООД/АКД выполняемая АКД повторная передача пакета в результате получения пакета НЕПРИЕМ имеет чисто локальную значимость, т.е, АКД ответит на пакет НЕПРИЕМ повторной передачей запрошенного пакета ДАННЫЕ через локальный интерфейс (АКД не передает пакет НЕПРИЕМ удаленному ООД);
     
     в) проигнорировать ошибочный пакет ДАННЫЕ и все последующие пакеты ДАННЫЕ, пока не будет принят правильный пакет ДАННЫЕ. Эта процедура зависит от повторной передачи ООД-отправителем (максимум до R25 раз) всех пакетов ДАННЫЕ, находящихся внутри окна после истечения его тайм-аута Т25 (после этого ООД-отправитель должно повторно установить логический канал, указав причину "по инициативе ООД" и диагностику "истек тайм-аут или превышен счет повторных передач пакета ДАННЫЕ").
     
     В конфигурации ООД/АКД при получении пакета-дубликата ДАННЫЕ АКД повторно установит логический канал. Данный вариант требует согласования между обоими ООД применения этого метода восстановления при ошибочных пакетах ДАННЫЕ.
     
     Этот стандартный режим восстановления требует повторной установки логического канала.
     
     См. также:
     
     процедуры повторной установки (разд.8);
     
     факультативная услуга пользователя "повторная передача пакета" (п.13.4);
     
     тайм-аут продвижения окна (Т25) (п.11.2.1 и табл.32);
     
     счет повторных передач пакета ДАННЫЕ (р25), (п.11.2.1 и табл.33);
     
     принципы управления потоком (п.7.1.3).
     
     

12. ФОРМАТЫ ПАКЕТА

     
     В этом разделе содержится следующая информация:
     
     а) информация об общем формате пакета (п.12.1);
     
     б) форматы пакетов для установления и завершения соединения (п.12.2);
     
     в) форматы пакетов ДАННЫЕ и "прерывание" (п.12.3);
     
     г) форматы пакетов "управление потоком" (п.12.4);
     
     д) форматы пакетов "повторная установка" (п.12.5);
     
     е) форматы пакетов "повторный пуск" (п.12.6);
     
     ж) формат пакета ДИАГНОСТИКА (п.12.7);
     
     з) формат пакета НЕПРИЕМ (п.12.8);
     
     и) форматы пакетов "регистрация" (п.12.9).
     
     12.1. Общие положения
     
     Пакет всегда состоит, по меньшей мере, из трех октетов. Эти три октета содержат поля "идентификатор общего формата", "идентификатор логического канала" и "идентификатор типа пакета". В зависимости от конкретного типа пакета могут быть определены дополнительно и другие поля. На черт.10 показан обобщенный формат пакета.
     

Общий формат пакета

Черт.10

     
     Возможность расширения форматов пакета добавлением новых полей находится в стадии изучения.
     
     Любое такое новое поле:
     
     а) следует вводить только после всех уже определенных полей, а не как вставку между какими-либо ранее определенными полями;
     
     б) должно передаваться в ООД только в том случае, если взаимодействующее ХХД было проинформировано о способности принимающего ООД интерпретировать и обрабатывать это поле, либо, если принимающее ООД может проигнорировать это поле без нарушения работы интерфейса ООД/ХХД (включая тарификацию);
     
     в) не должно содержать никакой информации, относящейся к факультативной услуге пользователя, которая не абонирована для ООД, если только ООД не может проигнорировать эту услугу без нарушения операций интерфейса ООД/ХХД (включая тарификацию).
     
     Биты октета нумеруются от 8 до 1, где бит 1 - наименее значащий бит, передаваемый первым. Октеты пакета нумеруются последовательно, начиная с 1, и передаются в порядке нумерации.
     
     Для осуществления взаимодействия через все интерфейсы ООД/АКД необходимо, чтобы все дополнительные поля после первых трех октетов содержали целое число октетов. Получение октета с полями, некратными октету, рассматривается как ошибка. Если уровень звена данных не обеспечивает исправления таких ошибок, связанных с некратными октету пакетами, то на пакетном уровне должны быть привлечены соответствующие процедуры восстановления при ошибках формата в зависимости от типа пакета.
     
     Каждый пакет, подлежащий передаче через интерфейс ООД/АКД, содержится в поле информации уровня звена данных, которое может ограничивать его длину. В этом поле информации содержится в точности один пакет. С точки зрения услуг уровня звена данных ВОС каждый пакет передается как параметр данных пользователя отдельного сервисного блока данных звена данных.
     
     12.1.1. Поле "идентификатор общего формата"
     
     Поле "идентификатор общего формата" является четырехбитным двоично-кодированным полем и предназначено для указания общего формата оставшейся части заголовка. Это поле расположено в битовых позициях 8, 7, 6 и 5 октета 1, где бит 5 - наименее значащий бит (см. табл.3).
     
     

Таблица 3

     
Идентификатор общего формата

________________
     * Не определено.
     
     Примечание. Бит, обозначенный как X, может быть установлен в значение либо 0, либо 1, как указано в последующих разделах.
     
     
     Позиция бита 8 идентификатора общего формата пакетов ДАННЫЕ используется для бита-определителя (бита 0). Во всех других пакетах этот бит устанавливается в значение 0.
     
     Бит 7 идентификатора общего формата, а в пакетах ДАННЫЕ и пакетах установления соединения используется для процедуры подтверждения доставки. Во всех других пакетах он устанавливается в значение 0.
     
     Биты 6 и 5 кодируются четырьмя возможными комбинациями. Две из них используются для того, чтобы отличить пакеты с порядковой нумерацией по модулю 8 от пакетов с порядковой нумерацией по модулю 128 (т.е. в зависимости от того, разрешена ли в ООД услуга "расширенная порядковая нумерация пакетов"). Третья комбинация используется для указания на переход к расширенному формату кодов идентификатора общего формата и является предметом дальнейшего изучения. Четвертая комбинация зарезервирована для будущих применений.
     
     Примечание. Предполагается, что другие кодовые комбинации идентификатора общего формата могут идентифицировать альтернативные форматы пакета.
     
     
     См. также:
     
     факультативная услуга пользователя "расширенная порядковая нумерация пакетов" (п.13.2).
     
     12.1.2. Поле "идентификатор логического канала"
     
     Поле "идентификатор логического канала"* содержится в каждом пакете в битовых позициях 4, 3, 2 и 1 октета 1 и во всех битовых позициях октета 2. Это поле кодируется двоичным числом с использованием битовых позиций 4-1 октета 1 и вслед за ними - битовых позиций 8-1 октета 2. Бит 1 октета 2 - наименее значащий бит.
________________
     * Поле "идентификатор логического канала" можно также рассматривать, как состоящее из двух подполей: "номер группы логического канала" и "номер логического канала". Подполе "номер группы логического канала" образуется из битовых позиций 4, 3, 2 и 1 октета 1, а подполе "номер логического канала" - из битовых позиций октета 2. Оба подполя двоично-кодированы, при этом бит 1 - наименее значащий бит. Эта альтернативная терминология не используется в настоящем стандарте.
     
     В конфигурации ООД/АКД это число имеет локальную значимость для каждого логического канала.
     

     В пакетах "повторный пуск", ДИАГНОСТИКА и "регистрация" это поле кодируется одними нулями.
     
     12.1.3. Поле "идентификатор типа пакета"
     
     Октет 3 идентифицирует каждый пакет в соответствия с табл.4.
     
     

Таблица 4

     
Идентификатор типа пакета

________________
      Бит, обозначенный как "х", может быть установлен в значение либо 0, либо 1, как указано в последующих разделах.
     
      Нумерация по модулю 128 используется только с использованием услуги "расширенная порядковая нумерация пакетов".
     
      ООД может передать пакет НЕПРИЕМ только в том случае, если разрешена факультативная услуга "повторная передача пакета" для передачи пакетов НЕПРИЕМ от ООД к ХХД (см. п.13.4).
     
      АКД никогда не будет передавать пакет НЕПРИЕМ и, следовательно, от ООД не требуется обрабатывать полученный пакет НЕПРИЕМ в конфигурации ООД/АКД. С другой стороны, ООД должно быть способно обрабатывать полученный пакет НЕПРИЕМ в конфигурации ООД/ООД только в том случае, если соглашение по использованию факультативной услуги "повторная передача пакета" включает повторную передачу пакетов ДАННЫЕ со стороны ООД.
     
      ООД может передать пакет ДИАГНОСТИКА только в конфигурации ООД/ООД и только в том случае, если оно может подавлять его генерацию при работе с сетью.
     
      ООД в конфигурации ООД/АКД может принять пакет ДИАГНОСТИКА от АКД, если это предусмотрено сетью. ООД в конфигурации ООД/ООД может принять пакет ДИАГНОСТИКА от ООД только в том случае, если передающее ООД может подавлять его генерацию при работе с сетью.
     
      Пакеты регистрации используются только в том случае, если используется факультативная услуга "динамическая регистрация услуги" (см. п.13.1).
     
      АКД никогда не передает пакет ЗАПРОС РЕГИСТРАЦИИ и, следовательно, от ООД не требуется обрабатывать полученный пакет ЗАПРОС РЕГИСТРАЦИИ в конфигурации ООД/АКД. ООД должно быть способно обработать полученный пакет ЗАПРОС РЕГИСТРАЦИИ в конфигурации ООД/ООД только в том случае, если соглашение об использовании факультативной услуги "динамическая регистрация услуги" предусматривает ответ ООД на инициацию процедуры регистрации.
     
      ООД не должно передавать пакет ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ в конфигурации ООД/АКД. ООД должно быть способно передавать пакет ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ в ответ на пакет ЗАПРОС РЕГИСТРАЦИИ только в том случае, если соглашение об использовании факультативной услуги "динамическая регистрация услуги" предусматривает ответ на инициацию процедуры регистрации.
     
     
     12.2. Пакеты установления и завершения соединения
     
     При установлении и завершении виртуального соединения используются следующие пакеты:
     
     а) ЗАПРОС ВЫЗОВА и ВХОДЯЩИЙ ВЫЗОВ (п.12.2.1);
     
     б) ВЫЗОВ ПРИНЯТ и СОЕДИНЕНИЕ УСТАНОВЛЕНО (п.12.2.2);
     
     в) ЗАПРОС ЗАВЕРШЕНИЯ и ИНДИКАЦИЯ ЗАВЕРШЕНИЯ (п.12.2.3);
     
     г) ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ (п.12.2.4).
     
     См. также:
     
     процедуры установления и завершения виртуальных соединений (разд.5).
     
     12.2.1. Пакеты ЗАПРОС ВЫЗОВА и ВХОДЯЩИЙ ВЫЗОВ
     
     Формат пакетов ЗАПРОС ВЫЗОВА и ВХОДЯЩИЙ ВЫЗОВ показан на черт.11.
     

Формат пакета ЗАПРОС ВЫЗОВА и ВХОДЯЩИЙ ВЫЗОВ

________________
     * Содержит код 0Х01 (модуль 8) или код 0Х10 (модуль 128).
     
     ** Предполагается, что число цифр в поле "адрес вызываемого ООД" - нечетное, а в поле "адрес вызывающего ООД" - четное
     

Черт.11

     
     
     В конфигурации ООД/АКД пакет ЗАПРОС ВЫЗОВА и пакет ВХОДЯЩИЙ ВЫЗОВ - это два физически разных пакета вследствие наличия промежуточной сети между ООД и АКД. Однако в конфигурации ООД/ООД пакет ЗАПРОС ВЫЗОВА, переданный одним ООД, является пакетом ВХОДЯЩИЙ ВЫЗОВ для другого, принимающего ООД.
     
     12.2.1.1. Основной формат
     
     Первые три октета состоят из полей "идентификатор общего формата", "идентификатор логического канала" и "идентификатор типа пакета", как описано в пп.12.1.1-12.1.3. Однако бит 7 октета 1 (часть идентификатора общего формата) устанавливается так, как указано ниже.
     
     12.2.1.1.1. Идентификатор общего формата
     
     Бит 7 идентификатора общего формата (октет 1) устанавливается в значение 0 или 1 в зависимости от использования механизма, описанного в п.6.3 (этот механизм используется для указания возможности межконцевого подтверждения данных во время фазы передачи данных).
     
     12.2.1.1.2. Поля "длина адреса"
     
     Октет 4 содержит указатели длины полей "адрес вызывающего ООД" и "адрес вызываемого ООД". Биты 8, 7, 6 и 5 указывают длину адреса вызывающего ООД в полуоктетах, а биты 4, 3, 2 и 1 - длину адреса вызываемого ООД и полуоктетах. Каждый указатель длины адреса представлен в двоичном коде, при этом бит 5 или 1 - наименее значащий бит указателя.
     
     12.2.1.1.3. Адресные поля
     
     Октеты, следующие за полями "длина адреса", содержат адрес вызываемого ООД (при его наличии), за которым следует адрес вызывающего ООД (при его наличии).
     
     Каждая цифра адреса кодируется в двоично-десятичном коде, занимая полуоктет, где бит 5 или 1 - наименее значащий бит цифры.
     
     Адрес ООД кодируется в последовательных октетах, начиная с наиболее значащей цифры, по две цифры на октет. В битах 8, 7, 6 и 5 каждого октета кодируется наиболее значащая цифра. Если общее число цифр в адресных полях вызываемого и вызывающего ООД нечетное, то число цифр в общем поле следует округлять до целого числа октетов вставкой нулей в биты 4, 3, 2 и 1 последнего октета этого поля.
     
     Примечание. Это поле может использоваться для факультативных услуг адресации, таких как "сокращенная адресация". Использование этих факультативных услуг адресации так же, как и их кодирование является предметом дальнейшего изучения.
     

     
     12.2.1.1.4. Поле "длина услуги"
     
     Октет, следующий за полем адреса, указывает длину поля услуги в октетах. Указатель длины поля услуги - двоично-кодированное число, где бит 1 - наименее значащий бит этого указателя.
     
     12.2.1.1.5. Поле "услуги"
     
     Поле "услуги" присутствует только в том случае, если ООД или ХХД использует факультативные услуги пользователя, требующие определенного указания в пакете ЗАПРОС ВЫЗОВА или ВХОДЯЩИЙ ВЫЗОВ.
     
     Поле "услуги" состоит из целого числа октетов. Фактическая максимальная длина этого поля зависит от услуг, обеспечиваемых на данном интерфейсе ООД/ХХД. Однако этот максимум не должен превышать 109 октетов.
     
     См. также:
     
     кодирование поля "услуги" (разд.15).
     
     12.2.1.1.6. Поле "данные вызывающего пользователя"
     
     За полем "услуги" может следовать поле "данные вызывающего пользователя", которое имеет максимальную длину 16 октетов. Это поле должно содержать целое число октетов, как указано в п.12.1.
     
     При установлении виртуального соединения между двумя ООД пакетного режима не воздействует ни на одну часть поля "данные вызывающего пользователя" (см. рекомендацию Х.244 МККТТ).
     
     12.2.1.2. Расширенный формат
     
     Расширенный формат может использоваться только совместно с услугой "быстрая выборка" (см. п.13.16). Расширенный формат идентичен основному формату, за исключением того, что поле "данные вызывающего пользователя" имеет максимальную длину 128 октетов.
     
     12.2.2. Пакеты ВЫЗОВ ПРИНЯТ и СОЕДИНЕНИЕ УСТАНОВЛЕНО
     
     Формат пакетов ВЫЗОВ ПРИНЯТ и СОЕДИНЕНИЕ УСТАНОВЛЕНО приведен на черт.12.
     
     

Формат пакета ВЫЗОВ ПРИНЯТ и СОЕДИНЕНИЕ УСТАНОВЛЕНО

________________
     * Содержит код 0Х01 (модуль 8) или код 0Х10 (модуль 128).
     
     ** Предполагается, что число цифр в поле "адрес вызываемого ООД" - нечетное, а в поле "адрес вызывающего ООД" - четное.
     
     *** Используется только в расширенном формате (см. п.12.2.2.2).
     

Черт.12

     
     
     В конфигурации ООД/АКД пакет ВЫЗОВ ПРИНЯТ и пакет СОЕДИНЕНИЕ УСТАНОВЛЕНО - это два физически разных пакета вследствие наличия промежуточной сети между ООД и АКД. Однако в конфигурации ООД/ООД пакет ВЫЗОВ ПРИНЯТ, переданный одним ООД, для другого ООД, принявшего его, является пакетом СОЕДИНЕНИЕ УСТАНОВЛЕНО.
     
     12.2.2.1. Основной формат
     
     Первые три октета содержат поля "идентификатор общего формата", "идентификатор логического канала" и "идентификатор типа пакета", как описано в пп.12.1.1-12.1.3. Однако бит 7 октета 1 (часть идентификатора общего формата) устанавливается так, как указано ниже.
     
     12.2.2.1.1. Идентификатор общего формата
     
     Бит 7 идентификатора общего формата устанавливается в значение 0 или 1 в зависимости от использования механизма, описанного в п.6.3 (этот механизм используется для указания на возможность применения межконцевого подтверждения данных в фазе передачи данных).
     
     12.2.2.1.2. Поле "длина адреса"
     
     Октет 4 содержит указатели длин полей "адрес вызывающего ООД" и "адрес вызываемого ООД". Биты 8, 7, 6 и 5 указывают длину адреса вызывающего ООД в полуоктетах, а биты 4, 3, 2 и 1 - длину адреса вызываемого ООД в полуоктетах. Каждый указатель длины адреса представлен в двоичном коде, где бит 5 или 1 - наименее значащий бит указателя.
     
     Использование полей "длина адреса" в пакетах ВЫЗОВ ПРИНЯТ является обязательным, даже если они установлены в значение 0.
     
     12.2.2.1.3. Адресные поля
     
     Октеты, следующие за полями "длина адреса", содержат адрес вызываемого ООД (при его наличии), за которым следует адрес вызывающего ООД (при его наличии).
     
     Каждая цифра адреса кодируется полуоктетом в двоично-десятичном коде, где бит 5 или 1 - наименее значащий бит цифры.
     
     Адрес ООД кодируется в последовательных октетах, начиная с наиболее значащей цифры, по две цифры в октете. В битах 8, 7, 6 и 5 каждого октета кодируется наиболее значащая цифра. Если общее число цифр в полях вызываемого и вызывающего ООД нечетное, то это число следует округлить до целого числа октетов вставкой нулей в биты 4, 3, 2 и 1 последнего октета этого поля.
     
     Примечание. Эти поля могут использоваться для факультативных услуг адресации, таких как сокращенная адресация. Использование этих факультативных услуг адресации так же, как и их кодирование являются предметом дальнейшего изучения.
     

     
     12.2.2.1.4. Поле "длина услуги"
     
     Октет, следующий за полем адреса, указывает длину поля "услуги" в октетах. Указатель длины поля "услуги" является двоично-кодированным числом, где бит 1 - наименее значащий бит этого указателя.
     
     Использование поля "длина услуги" в пакете ВЫЗОВ ПРИНЯТ является обязательным, даже если оно установлено в значение 0.
     
     12.2.2.1.5. Поле "услуги"
     
     Поле "услуги" присутствует только в том случае, если ООД или ХХД использует факультативные услуги пользователя, требующие определенного указания в пакете ВЫЗОВ ПРИНЯТ или СОЕДИНЕНИЕ УСТАНОВЛЕНО.
     
     Поле "услуги" состоит из целого числа октетов. Фактическая максимальная длина этого поля зависит от услуг, обеспечиваемых на данном интерфейсе ООД/ХХД. Однако этот максимум не должен превышать 109 октетов.
     
     См. также:
     
     кодирование поля "услуги" (разд.15).
     
     12.2.2.2. Расширенный формат
     
     Расширенный формат может использоваться только совместно с услугой "быстрая выборка"' (см. п.13.16). Расширенный формат идентичен основному формату, за исключением того, что здесь может присутствовать поле "данные вызываемого пользователя".
     
     Поле "данные вызываемого пользователя".
     
     За полем "услуги" может следовать поле "данные вызываемого пользователя", максимальная длина которого - 128 октетов. Это поле должно содержать целое число октетов, как указано в п.12.1.
     
     При установлении виртуального соединения между двумя ООД пакетного режима сеть не воздействует ни на одну часть поля "данные вызываемого пользователя" (см. рекомендацию X.244 МККТТ).
     
     
     12.2.3. Пакеты ЗАПРОС ЗАВЕРШЕНИЯ и ИНДИКАЦИЯ ЗАВЕРШЕНИЯ
     
     Формат пакетов ЗАПРОС ЗАВЕРШЕНИЯ и ИНДИКАЦИЯ ЗАВЕРШЕНИЯ показан на черт.13.
     
     

Формат пакета ЗАПРОС ЗАВЕРШЕНИЯ и ИНДИКАЦИЯ ЗАВЕРШЕНИЯ

________________
     * Содержит код 0001 (модуль 8) или код 0010 (модуль 128).
     
     ** Предполагается, что число цифр в поле "адрес вызываемого ООД" - нечетное, а в поле "адрес вызывающего ООД" - четное.
     
     *** Используется только в расширенном формате (см. п.12.2.3.2).

Черт.13

     
     В конфигурации ООД/АКД пакет ЗАПРОС ЗАВЕРШЕНИЯ и пакет ИНДИКАЦИЯ ЗАВЕРШЕНИЯ - это два физически разных пакета, вследствие наличия промежуточной сети между ООД и АКД. Однако в конфигурации ООД/ООД пакет ИНДИКАЦИЯ ЗАВЕРШЕНИЯ, полученный одним ООД, - это тот же пакет ИНДИКАЦИЯ ЗАВЕРШЕНИЯ, который передало другое ООД.
     
     12.2.3.1. Основной формат
     
     Первые три октета содержат поля "идентификатор общего формата", "идентификатор логического канала" и "идентификатор типа пакета", как описано в пп.12.1.1-12.1.3.
     
     12.2.3.1.1. Поле "причина завершения"
     
     Октет 4 - это поле "причина завершения", которое содержит обоснование завершения соединения.
     
     В пакете ЗАПРОС ЗАВЕРШЕНИЯ ООД должно устанавливать это поле в значение "по инициативе ООД".
     
     Кодирование поля "причина завершения" в пакете ИНДИКАЦИЯ ЗАВЕРШЕНИЯ приведено в табл.5 (определение каждой из причин завершения дано в рекомендации Х.96 МККТТ). В конфигурации ООД/АКД для возможных последующих расширений табл.5 ООД должно быть способно воспринимать любое значение в поле "причина завершения" пакета ИНДИКАЦИЯ ЗАВЕРШЕНИЯ. ООД в конфигурации ООД/ООД может либо обрабатывать причину завершения, отличную от "по инициативе ООД" так же, как и в конфигурации ООД/АКД (т.е. нормально обрабатывать пакет), либо рассматривать ее как ошибку. В последнем случае пакетный уровень передает пакет ЗАПРОС ЗАВЕРШЕНИЯ с указанием причины "по инициативе ООД" и диагностики "неправильный код причины от ООД".
     
     

Таблица 5

     
Кодирование поля "причина завершения" в пакетах ИНДИКАЦИЯ ЗАВЕРШЕНИЯ

________________
      Используется, когда поле "код диагностики" кодируется в соответствии с табл.31.
     
      Используется, когда поле "код диагностики" кодируется не в соответствии с табл.31.
     
      Эти причины завершения применимы только в конфигурации ООД/АКД.
     
      Бит, обозначенный "X" и установленный в значение 0, указывает, что причина завершения сгенерирована сетью передачи данных общего пользования, а установленный в значение 1, указывает, что причина завершения сгенерирована сетью частного пользования.
     
      Может быть принят только в том случае, если используется соответствующая факультативная услуга пользователя.
     
      Используется совместно с морской мобильной службой.
     
     
     12.2.3.1.2. Поле "код диагностики"
     
     Октет 5 - это поле "код диагностики", которое содержит дополнительную информацию о причине завершения соединения. Кодирование этого поля зависит от причины завершения, как показано в табл.30.
     
     В пакете ЗАПРОС ЗАВЕРШЕНИЯ наличие поля "код диагностики" обязательно, даже если оно не содержит дополнительной информации.
     
     Если поле "причина завершения"' в пакете ИНДИКАЦИЯ ЗАВЕРШЕНИЯ указывает "по инициативе ООД", то поле "код диагностики" передается без изменений от удаленного ООД, инициировавшего процедуру завершения или (в конфигурации ООД/АКД) процедуру повторного пуска. Если поле "причина завершения" в пакете ИНДИКАЦИЯ ЗАВЕРШЕНИЯ отлично от "по инициативе ООД" то поле "код диагностики" генерируется сетью.
     
     Примечание. Содержимое поля "код диагностики" не меняет смысла поля "причина завершения". ООД не требуется выполнять никаких действий в зависимости от содержимого поля "код диагностики". Поле "причина завершения" должно быть принято, даже в том случае, когда поле "код диагностики" содержит неопределенную кодовую комбинацию.
     
     12.2.3.2. Расширенный формат
     
     Расширенный формат используется только в том случае, если ООД или ХХД необходимо использовать поле адреса, поле услуг и/или поле "данные завершающего пользователя". Поля "адрес" и "услуги" используются в пакете ЗАПРОС ЗАВЕРШЕНИЯ  или ИНДИКАЦИЯ ЗАВЕРШЕНИЯ, передаваемом в ответ на пакет ВХОДЯЩИЙ ВЫЗОВ или ЗАПРОС ВЫЗОВА, соответственно, при использовании услуги "уведомление о модификации адреса вызываемой линии" (см. п.13.26). Поле "услуги" применяется при использовании услуги "информация о тарифах" (см. п.13.22).
     
     Поле "данные завершающего пользователя" используется совместно с услугой "быстрая выборка" (см. п.13.16) и услугой "выбop отражения вызова" (см. п.13.25.2.2).
     

     Содержимое п.12.2.3.1 справедливо и для расширенного формата, но здесь за полем "код диагностики" следуют дополнительные описываемые ниже поля.
     
     12.2.3.2.1. Поля "длина адреса"
     
     Октет 6 содержит указатели длин полей "адрес вызывающего ООД" и "адрес вызываемого ООД". Биты 8, 7, 6 и 5 указывают длину адреса вызывающего ООД в полуоктетах, а биты 4, 3, 2 и 1 - длину адреса вызываемого ООД в полуоктетах. Каждый указатель длины адреса представлен в двоичном коде, где бит 5 или 1 - наименее значащий бит указателя.
     
     12.2.3.2.2. Адресные поля
     
     Октеты, следующие за полями "длина адреса", содержат адрес вызываемого ООД (при его использовании) и адрес вызывающего ООД (при его использовании).
     
     Каждая цифра адреса представляется в двоично-десятичном коде полуоктетом, где бит 5 или 1 - наименее значащий бит цифры.
     
     Адрес ООД кодируется в последовательных октетах, начиная с наиболее значащей цифры, по две цифры в октете. В каждом октете наиболее значащая цифра кодируется в битах 8, 7, 6 и 5. Если общее число цифр в полях адресов вызываемого и вызывающего ООД нечетное, то это число следует округлить до целого числа октетов вставкой нулей в биты 4, 3, 2 и 1 последнего октета объединенного поля.
     
     12.2.3.2.3. Поле "длина услуги"
     
     Октет, следующий за полем адреса, указывает длину поля услуги в октетах. Указатель длины поля услуги является двоично-кодированным числом, где бит 1 - наименее значащий бит этого указателя.
     
     12.2.3.2.4. Поле "услуги"
     
     Поле "услуги" присутствует только в том случае, если ООД или ХХД использует факультативные услуги пользователя, требующие определенного указания в пакете ЗАПРОС ЗАВЕРШЕНИЯ или ИНДИКАЦИЯ ЗАВЕРШЕНИЯ. Поле "услуги" содержит целое число октетов. Фактическая максимальная длина этого поля зависит от услуг, обеспечиваемых на данном интерфейсе ООД/ХХД. Однако этот максимум не должен превышать 109 октетов.
     
     См. также:
     
     кодирование поля "услуги" (разд.15).
     
     12.2.3.2.5. Поле "данные завершающего пользователя"
     
     За полем "услуги" может следовать поле "данные завершающего пользователя", максимальная длина которого - 128 октетов. Оно должно содержать целое число октетов, как указано в п.12.1. При завершении виртуального соединения между двумя ООД пакетного режима сеть не воздействует ни на одну часть поля "данные завершающего пользователя" (см. рекомендацию Х.244 МККТТ).
     

     12.2.4. Пакет ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ
     
     На черт.14 показан формат пакета ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ, передаваемого ООД, и формат пакета ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ, принимаемого ООД.
     
     

Формат пакета ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ

________________
     * Кодируется 0001 (модуль 8) или 0010 (модуль 128).
     
     ** Используются только в расширенном формате (см. п.12.2.4.2).
     

Черт.14

     
     
     12.2.4.1. Основной формат
     
     Этот пакет содержит три октета, в которых размещаются поля "идентификатор общего формата", "идентификатор логического канала" и "идентификатор типа пакета", как описано в пп.12.1.1-12.1.3.
     
     12.2.4.2. Расширенный формат
     
     Расширенный формат используется для пакетов ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ, передаваемых АКД, только совместно с услугой "информация о тарифах", описываемой в п.13.22. Он не используется для пакетов ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ, передаваемых ООД.
     
     Для расширенного формата справедливы положения п.12.2.4.1 и, кроме того, после октета 3 добавляются следующие поля.
     
     12.2.4.2.1. Поля "длина адреса"
     
     Октет 4 содержит указатель длин полей "адрес вызывающего ООД" и "адрес вызываемого ООД". Биты 8, 7, 6 и 5 указывают длину адреса вызывающего ООД в полуоктетах, а биты 4, 3, 2 и 1 - длину адреса вызываемого ООД в полуоктетах. Каждый указатель длины адреса является двоично-кодированным числом, где бит 5 или 1 - наименее значащий бит указателя.
     
     В настоящее время эти поля кодируются нулями.
     
     12.2.4.2.2. Адресные поля
     
     Эти поля отсутствуют.
     
     12.2.4.2.3. Поле "длина услуги"
     
     Октет, следующий за полем адреса, указывает длину поля услуги в октетах. Указатель длины поля услуги является двоично-кодированным числом, где бит 1 - наименее значащий бит указателя.
     
     12.2.4.2.4. Поле "услуги"
     
     Поле "услуги" содержит целое число октетов. Фактическая максимальная длина этого поля зависит от услуг, допустимых на данном интерфейсе ООД/ХХД. Однако этот максимум не должен превышать 109 октетов.
     
     См. также:
     
     кодирование поля "услуги" (разд.15).
     
     12.3. Пакеты ДАННЫЕ и ПРЕРЫВАНИЕ
     
     При передаче данных и в процедуре прерывания используются следующие пакеты:
     
     а) ДАННЫЕ (п.12.3.1);
     
     б) ПРЕРЫВАНИЕ (п.12.3.2) и
     
     в) ПОДТВЕРЖДЕНИЕ ПРЕРЫВАНИЯ (п.12.3.3).
     
     12.3.1. Пакет ДАННЫЕ
     
     На черт.15 показан формат пакета ДАННЫЕ, передаваемого ООД, и формат пакета ДАННЫЕ, принимаемого ООД.
     

Формат пакета ДАННЫЕ

Условные обозначения:

     Д - бит ПОДТВЕРЖДЕНИЕ ДОСТАВКИ;
     
     М - бит ДОПОЛНИТЕЛЬНЫЕ ДАННЫЕ;
     
     Q - бит ОПРЕДЕЛИТЕЛЬ.
     

Черт.15

     
     Первые три октета содержат поля "идентификатор общего формата", "идентификатор логического канала" и "идентификатор типа пакета", как описано в пп.12.1.1-12.1.3. Кроме того, биты 8 и 7 октета 1 (часть идентификатора общего формата) используются в соответствии с нижеизложенным. Если порядковая нумерация пакетов выполняется по модулю 8, то биты 8-2 октета 3 (часть идентификатора типа пакета) используются в соответствии с нижеизложенным.
     
     12.3.1.1. Бит "определитель"
     
     Бит 8 октета 1 является битом-определителем (бит 0).
     
     12.3.1.2. Бит "подтверждение доставки"
     
     Бит 7 октета 1 является битом подтверждения доставки (бит Д).
     
     12.3.1.3. Порядковый номер приема пакета
     
     Биты 8, 7 и 6 октета 3 (или биты 8-2 октета 4 при расширенной нумерации) используются для указания порядкового номера приема пакета Ппм. Номер Ппм является двоично-кодированным числом, где бит 6 (или бит 2 при расширенной нумерации) является наименее значащим битом.
     
     12.3.1.4. Бит "дополнительные данные"
     
     Бит 5 октета 3 (или бит 1 октета 4 при расширенной нумерации) является указателем "дополнительные данные" (бит М).
     
     12.3.1.5. Порядковый номер передачи пакета
     
     Биты 4, 3 и 2 октета 3, (или биты 8-2 октета 3 при расширенной нумерации) используются для указания порядкового номера передачи пакета Ппд. Номер Ппд является двоично-кодированным числом, где бит 2 - наименее значащий бит.
     
     12.3.1.6. Поле "данные пользователя"
     
     Октеты, следующие за октетом 3 (или 4 при расширенной нумерации), содержат данные пользователя. Это поле должно содержать целое число октетов, как указано в п.12.1. Максимальная длина этого поля определена в п.6.2.
     
     12.3.2. Пакет ПРЕРЫВАНИЕ
     
     На черт.16 показан формат пакета ПРЕРЫВАНИЕ, передаваемого ООД, и формат пакета ПРЕРЫВАНИЕ, принимаемого ООД.
     
     

Формат пакета ПРЕРЫВАНИЕ

________________
     * Кодируется 0001 (модуль 8) или 0010 (модуль 128).
     

Черт.16

     
     
     Первые три октета содержат поля "идентификатор общего формата", "идентификатор логического канала" и "идентификатор типа пакета", как описано в пп.12.1.1-12.1.3.
     
     Данные прерывающего пользователя:
     
     Октет 4 и все следующие за ним октеты содержат данные прерывающего пользователя. Это поле содержит от 1 до 32 октетов, при этом число октетов должно быть целым, как указано в п.12.1.
     
     12.3.3. Пакет ПОДТВЕРЖДЕНИЕ ПРЕРЫВАНИЯ
     
     На черт.17 показан формат пакета ПОДТВЕРЖДЕНИЕ ПРЕРЫВАНИЯ, передаваемого ООД, и формат пакета ПОДТВЕРЖДЕНИЕ ПРЕРЫВАНИЯ, принимаемого ООД. Эти пакеты содержат три октета, в которых содержатся поля "идентификатор общего формата", "идентификатор логического канала" и "идентификатор типа пакета", как описано в пп.12.1.1- 12.1.3.
     
     

Формат пакета
ПОДТВЕРЖДЕНИЕ ПРЕРЫВАНИЯ

________________
     * Кодируется 0001 (модуль 8) или 0010 (модуль 128).
     

Черт.17

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

Формат пакета
ГОТОВНОСТЬ К ПРИЕМУ

     
Черт.18

     
     
     Этот пакет содержит 3 или 4 октета в зависимости от использования расширенной порядковой нумерации. Первые три октета содержат поля "идентификатор общего формата", "идентификатор логического канала" и "идентификатор типа пакета", как описано в пп.12.1.1-12.1.3. Однако, если порядковая нумерация пакетов выполняется по модулю 8, то биты 8, 7 и 6 октета 3 (часть идентификатора типа пакета) используются, как указано ниже.
     
     Порядковый номер приема пакета:
     
     Биты 8, 7 и 6 октета 3 (или биты 8-2 октета 4 при расширенной нумерации) используются для указания порядкового номера приема пакета Ппм. Номер Ппм является двоично-кодированным числом, где бит 6 (или бит 2 при расширенной нумерации) - наименее значащий бит.
     
     12.4.2. Пакет НЕГОТОВНОСТЬ К ПРИЕМУ
     
     На черт.19 показан формат пакета НЕГОТОВНОСТЬ К ПРИЕМУ, передаваемого и принимаемого ООД.
     
     

Формат пакета
НЕГОТОВНОСТЬ К ПРИЕМУ

     
Черт.19

     
     
     Этот пакет содержит 3 или 4 октета в зависимости от использования расширенной порядковой нумерации. Первые три октета содержат поля "идентификатор общего формата", "идентификатор логического канала" и "идентификатор типа пакета", как описано в пп.12.1.1-12.1.3. Однако, если порядковая нумерация пакетов выполняется по модулю 8, то биты 8, 7 и 6 октета 3 (часть идентификатора типа пакета) используются, как указано ниже.
     
     Порядковый номер приема пакета:
     
     Биты 8, 7 и 6 октета 3 (или биты 8-2 октета 4 при расширенной нумерации) используются для указания номера приема пакета Ппм. Номер Ппм является двоично-кодированным числом, где бит 6 (или бит 2 при расширенной нумерации) - наименее значащий бит.
     
     12.5. Пакеты повторной установки
     
     При инициации (в том числе повторной) потока пакетов ДАННЫЕ, ПРЕРЫВАНИЕ и управления потоком используются следующие пакеты:
     
     а) ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ и ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ (п.12.5.1);
     
     б) ПОДТВЕРЖДЕНИЕ ПОВТОРНОЙ УСТАНОВКИ (п.12.5.2).
     
     12.5.1. Пакеты ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ и ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ
     
     Формат пакетов ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ и ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ показан на черт.20.
     
     

Формат пакета ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ и ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ

________________
     * Кодируется 0001 (модуль 8) или 0010 (модуль 128).
     

Черт.20

     
     
     В конфигурации ООД/АКД пакет ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ и пакет ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ - это два физически разных пакета вследствие наличия промежуточной сети между ООД и АКД. Однако в конфигурации ООД/ООД пакет ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ, переданный одним ООД, является пакетом ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ для другого ООД, принявшего этот пакет.
     
     Первые три октета содержат поля "идентификатор общего формата", "идентификатор логического канала" и "идентификатор типа пакета", как описано в пп.12.1.1-12.1.3.
     
     12.5.1.1. Поле "причина повторной установки"
     
     Октет 4 - это поле "причина повторной установки", которое содержит обоснование повторной установки.
     
     ООД должно устанавливать поле "причина повторной установки" в значение "по инициативе ООД". Кодирование поля "причина повторной установки" в пакете ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ показано в табл.6 (причины повторной установки определены в рекомендации Х.96 МККТТ). В конфигурации ООД/АКД для обеспечения возможных последующих расширений табл.6 ООД должно быть способно воспринимать любое значение поля "причина повторной установки" пакета ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ. ООД в конфигурации ООД/ООД может воспринимать причину повторной установки, отличную от "по инициативе ООД" так же, как и в конфигурации ООД/АКД (т.е. нормально обрабатывать пакет), либо рассматривать ее как ошибку. В последнем случае пакетный уровень передает пакет ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ с указанием причины "по инициативе ООД" и диагностики "неправильный код причины от ООД".
     
     

Таблицa 6

     
Кодирование поля "причина повторной установки" в пакетах
ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ

________________     
      Используется, когда поле "код диагностики" кодируется в соответствии с табл.31.
     
      Используется, когда поле "код диагностики" кодируется не в соответствии с табл.31.
     
      Эти причины повторной установки применимы только в конфигурации ООД/АКД.
     
      Бит, обозначенный Х и установленный в значение 0, указывает, что причина завершения сгенерирована сетью данных общего пользования, а установленный в значение 1, указывает, что причина завершения сгенерирована сетью частного пользования.
     
      Применима только для постоянных виртуальных каналов.
     
     
     12.5.1.2. Поле "код диагностики"
     
     Октет 5 - это поле "код диагностики", которое содержит дополнительную информацию о причине повторной установки. Кодирование этого поля зависит от причины повторной установки, как показано в табл.30.
     
     В пакете ЗАПРОС ПОВТОРНОЙ УСТАНОВКИ наличие поля "код диагностики" обязательно, даже если оно не несет дополнительной информации.
     
     Если поле "причина повторной установки" пакета ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ указывает "по инициативе ООД", то поле "код диагностики" передается без изменений от удаленного ООД, инициировавшего процедуру повторной установки, или в конфигурации ООД/АКД - процедуру повторной установки, или в конфигурации ООД/АКД - процедуру повторного пуска. Если поле "причина повторной установки" пакета ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ отлично от "по инициативе ООД", это означает, что поле "код диагностики" сгенерировано сетью.
     
     Примечание. Содержимое поля "код диагностики" не меняет смысла поля "причина повторной установки". От ООД не требуется выполнять никаких действий над содержимым поля "код диагностики". Поле "причина повторной установки" должно быть принято даже если поле "код диагностики" содержит неопределенную кодовую комбинацию.
     
     
     12.5.2. Пакет ПОДТВЕРЖДЕНИЕ ПОВТОРНОЙ УСТАНОВКИ
     
     На черт.21 показан формат пакета ПОДТВЕРЖДЕНИЕ ПОВТОРНОЙ УСТАНОВКИ, передаваемого ООД, и формат пакета ПОДТВЕРЖДЕНИЕ ПОВТОРНОЙ УСТАНОВКИ, принимаемого ООД. Этот пакет состоит из трех октетов, в которых содержатся поля "идентификатор общего формата", "идентификатор логического канала" и "идентификатор типа пакета", как описано в пп.12.1.1-12.1.3.
     

Формат пакета ПОДТВЕРЖДЕНИЕ ПОВТОРНОЙ УСТАНОВКИ

________________
     * Кодируется 0001 (модуль 8) или 0010 (модуль 128).
     

Черт.21

     
     
     12.6. Пакеты повторного пуска
     
     Для инициации (в том числе повторной) пакетного уровня интерфейса ООД/ХХД используются следующие пакеты:
     
     а) ЗАПРОС ПОВТОРНОГО ПУСКА и ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА (п.12.6.1);
     
     б) ПОДТВЕРЖДЕНИЕ ПОВТОРНОГО ПУСКА (п.12.6.2).
     
     12.6.1. Пакеты ЗАПРОС ПОВТОРНОГО ПУСКА и ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА
     
     Формат пакетов ЗАПРОС ПОВТОРНОГО ПУСКА и ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА представлен на черт.22.
     
     

Формат пакета ЗАПРОС ПОВТОРНОГО ПУСКА и ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА

________________
     * Кодируется 0001 (модуль 8) или 0010 (модуль 128).
     

Черт.22

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

Таблица 7

     
Кодирование поля "причина повторного пуска" в пакетах
ИНДИКАЦИЯ ПОВТОРНОГО ПУСКА

________________     
      Эти причины повторного пуска применимы только в конфигурации ООД/ООД.
     
      Используется, когда поле "код диагностики" кодируется в соответствии с табл.31.
     
      Используется, когда поле "кода диагностики" кодируется не в соответствии с табл.31.
     
      Эти причины повторного пуска применимы только в конфигурации ООД/АКД.
     
      Может быть принят только при использовании услуги "динамическая регистрация услуги" (см. п.13.1).
     
     12.6.1.2. Поле "код диагностики"
     
     Октет 5 - это поле "код диагностики", которое содержит дополнительную информацию о причине повторного пуска. Кодирование поля "код диагностики" зависит от причины повторного пуска, как показано в табл.30.
     
     В пакете ЗАПРОС ПОВТОРНОГО ПУСКА наличие поля "код диагностики" обязательно, даже если оно не несет дополнительной информации.
     
     При работе через сеть "код диагностики" пакета ЗАПРОС ПОВТОРНОГО ПУСКА передается соответствующим ООД как "код диагностики" пакета ИНДИКАЦИЯ ПОВТОРНОЙ УСТАНОВКИ (для постоянных виртуальных каналов) или пакета ИНДИКАЦИЯ ЗАВЕРШЕНИЯ (для виртуальных соединений).
     
     Примечание. Содержимое поля "код диагностики" не меняет смысла поля "причина повторного пуска". От ООД не требуется выполнять никаких действий над содержимым поля "код диагностики". Поле "причина повторного пуска" должно быть принято даже если поле "код диагностики" содержит неопределенную кодовую комбинацию.
     
     
     12.6.2. Пакет ПОДТВЕРЖДЕНИЕ ПОВТОРНОГО ПУСКА
     
     На черт.23 показан формат пакета ПОДТВЕРЖДЕНИЕ ПОВТОРНОГО ПУСКА, передаваемого ООД, и формат пакета ПОДТВЕРЖДЕНИЕ ПОВТОРНОГО ПУСКА, принимаемого ООД.
     
     

Формат пакета ПОДТВЕРЖДЕНИЕ ПОВТОРНОГО ПУСКА

________________
     * Содержит код 0001 (модуль 8) или 0010 (модуль 128).
     

Черт.23

     
     
     Этот пакет состоит из трех октетов, которые содержат поля "идентификатор общего формата", "идентификатор логического канала" и "идентификатор типа пакета", как описано в пп.12.1.1-12.1.3. Однако поле "идентификатор логического канала" кодируется одними нулями.
     
     12.7. Пакет ДИАГНОСТИКА
     
     Формат пакета ДИАГНОСТИКА показан на черт.24.
     
     

Формат пакета ДИАГНОСТИКА

________________
     * Кодируется 0001 (модуль 8) или 0010 (модуль 128).
     

Черт.24

     
     
     Любое ООД должно быть способно принимать пакет ДИАГНОСТИКА. Пакет ДИАГНОСТИКА может использоваться в конфигурации ООД/АКД и только для передачи от АКД к ООД. Пакет ДИАГНОСТИКА может быть выдан ООД в конфигурации ООД/ООД только при том условии, что при работе через сеть его генерация может быть подавлена генерация может быть подавлена.*
________________
     * Текст соответствует оригиналу. - Примечание .
          
     Первые три октета содержат поля "идентификатор общего формата", "идентификатор логического канала" и "идентификатор типа пакета", как описано в пп.12.1.1-12.1.3. Однако поле "идентификатор логического канала" кодируется одними нулями.
     
     12.7.1. Поле "код диагностики"
     
     Октет 4 - это поле "код диагностики", которое содержит информацию об ошибке, вызвавшей передачу пакета ДИАГНОСТИКА. Кодирование поля "код диагностики" показано в табл.30.
     
     12.7.2. Поле "уточняющая диагностика"
     
     Если пакет ДИАГНОСТИКА передается в результате получения ошибочного пакета (т.е. пакета с одним из условий, перечисленных в табл.37 и 38), то это поле содержит первые три октета заголовка ошибочного пакета. В том случае, когда ошибочный пакет содержит менее трех октетов, это поле будет содержать только полные октеты (если таковые имеются), принятые ООД в конфигурации ООД/ООД, или любые биты, принятые АКД в конфигурации ООД/АКД.
     
     Если пакет ДИАГНОСТИКА передается в результате истечения тайм-аута, то поле "уточняющая диагностика" содержит два октета, которые кодируются следующим образом:
     
     а) биты 8, 7, 6 и 5 первого октета содержат "идентификатор общего формата" для данного интерфейса;
     
     б) биты 4-1 первого октета и биты 8-1 второго октета устанавливаются в значение 0 при истечении тайм-аута повторного пуска (Т10 для конфигурации ООД/АКД) и указывают номер логического канала, в котором истек тайм-аут повторной установки (Т12 в конфигурации ООД/АКД) или тайм-аут завершения (Т13 для конфигурации ООД/АКД).
     
     12.8. Пакет НЕПРИЕМ
     
     На черт.25 показан формат пакета НЕПРИЕМ, используемого совместно с услугой "повторная передача пакета" (см. п.13.4).
     

Формат пакета НЕПРИЕМ

Черт.25

     
     Этот пакет содержит 3 или 4 октета в зависимости от использования расширенной порядковой нумерации. Первые три октета содержат поля "идентификатор общего формата", "идентификатор логического канала" и "идентификатор типа пакета", как описано в пп.12.1.1-12.1.3. Однако, если порядковая нумерация пакета выполняется по модулю 8, то биты 8, 7 и 6 октета 3 (часть "идентификатора типа пакета") используются, как указано ниже.
     
     Порядковый номер приема пакета:
     
     Биты 8, 7 и 6 октета 3 (или биты 8-2 октета 4 при расширенной нумерации) используются для указания порядкового номера приема пакета Ппм. Номер Ппм является двоично-кодированным числом, где бит 6 (или бит 2 при расширенной нумерации) - наименее значащий бит.
     
     12.9. Пакеты регистрации
     
     Перечисленные ниже пакеты используются совместно с услугой "динамическая регистрация услуги" (см. п.13.1).
     
     а) ЗАПРОС РЕГИСТРАЦИИ (п.12.9.1) и
     
     б) ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ (п.12.9.2).
     
     12.9.1. Пакет ЗАПРОС РЕГИСТРАЦИИ
     
     Формат пакета ЗАПРОС РЕГИСТРАЦИИ показан на черт.26.
     
     

Формат пакета ЗАПРОС РЕГИСТАЦИИ

________________
     * Кодируется 0001 (модуль 8) или 0010 (модуль 128).
     

Черт.26

     
     
     Первые три октета содержат поля "идентификатор общего формата", "идентификатор логического канала" и "идентификатор типа пакета", как описано в пп.12.1.1-12.1.3. Однако поле "идентификатор логического канала" кодируется одними нулями.
     
     12.9.1.1. Поля "длина адpeca"
     
     Октет 4 содержит индикаторы длины полей адресов ООД и взаимодействующего с ним ХХД. Биты 8, 7, 6 и 5 указывают длину адреса ООД, передающего пакет ЗАПРОС РЕГИСТРАЦИИ, в полуоктетах. Биты 4, 3, 2 и 1 указывают длину адреса взаимодействующего ХХД в полуоктетах. Каждый указатель длины адреса является двоично-кодированным числом, где бит 5 или 1 - наименее значащий бит указателя.
     
     В процедурах настоящего стандарта эти поля кодируются одними нулями.
     
     12.9.1.2. Адресные поля
     
     Эти поля не используются в процедурах настоящего стандарта.
     
     12.9.1.3. Поле "длина регистрации"
     
     Октет, следующий за полем адреса, указывает длину поля "регистрация" в октетах. Указатель длины поля "регистрация" является двоично-кодированным числом, где бит 1 - наименее значащий бит указателя.
     
     12.9.1.4. Поле "регистрация"
     
     Поле "регистрация" присутствует только при желании изменить соглашение по одной или нескольким факультативным услугам пользователя.
     
     Поле "регистрация" состоит из целого числа октетов. Фактическая максимальная длина этого поля зависит от услуг, обеспечиваемых на данном интерфейсе ООД/ХХД. Однако этот максимум не может превышать 109 октетов.
     
     См. также:
     
     кодирование поля "регистрация" (разд.16).
     
     12.9.2. Пакет ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ
     
     Формат пакета ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ показан па черт.27.
     
     

Формат пакета ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ

________________
     * Кодируется 0001 (модуль 8) или 0010 (модуль 128).
     

Черт.27

     
     
     Первые три октета содержат поля "идентификатор общего формата", "идентификатор логического канала" и "идентификатор типа пакета", как описано в пп.12.1.1-12.1.3. Однако поле "идентификатор логического канала" кодируется одними нулями.
     
     12.9.2.1. Поле "причина"
     
     Октет 4 - это поле "причина", которое содержит либо причину неудачи согласования услуг, либо указание о приемлемости поля "регистрация".
     
     Кодирование поля "причина" в пакете ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ приведено в табл.8.
     
     

Таблица 8

     
Кодирование поля "причина" в пакетах ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ

     
     
     12.9.2.2. Код диагностики
     
     Октет 5 - это поле "код диагностики", которое содержит дополнительную информацию о причине неудачи согласования услуг.
     
     Кодирование поля "код диагностики" приведено в табл.30. Если согласование прошло успешно или если отсутствует дополнительная информация, то все биты поля "код диагностики" устанавливаются в значение 0.
     
     12.9.2.3. Поля "длина адреса"
     
     Октет 6 содержит указатели длины поля адресов ООД и взаимодействующего с ним ХХД. Биты 8, 7, 6 и 5 указывают длину адреса ООД, принимающего пакет ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ, в полуоктетах. Биты 4, 3, 2 и 1 указывают длину адреса взаимодействующего ХХД в полуоктетах. Каждый указатель длины адреса является двоично-кодированным числом, где бит 5 или 1 - наименее значащий бит указателя.
     
     В процедурах настоящего стандарта эти поля кодируются одними нулями.
     
     12.9.2.4. Адресные поля
     
     Эти поля отсутствуют в процедурах настоящего стандарта.
     
     12.9.2.5. Поле "длина регистрации"
     
     Октет, следующий за полем адреса, указывает длину поля "регистрация" в октетах. Указатель длины поля "регистрация" является двоично-кодированным числом, где бит 1 - наименее значащий бит этого указателя.
     
     12.9.2.6. Поле "регистрация"
     
     Поле "регистрация" используется для указания факультативных услуг пользователя, которые доступны и действуют в данный момент. Поле "регистрация" состоит из целого числа октетов. Фактическая максимальная длина этого поля зависит от возможностей, обеспечиваемых на данном интерфейсе ООД/ХХД. Однако этот максимум не может превышать 109 октетов.
     
     См. также:
     
     кодирование поля "регистрация" (разд.16).
     
     

13. ПРОЦЕДУРЫ ДЛЯ ФАКУЛЬТАТИВНЫХ УСЛУГ ПОЛЬЗОВАТЕЛЯ

     
     Между ООД и ХХД может использоваться ряд факультативных услуг пользователя. Эти факультативные услуги пользователя сведены в табл.9.
     
     

Таблица 9

Факультативные услуги пользователя на пакетном уровне

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

     В этом подразделе описываются общие процедуры для использования услуги "динамическая регистрация услуги". Сама по себе процедура регистрации не влияет на состояние какого-либо логического канала. Конкретные процедуры зависят от услуги, подлежащей согласованию, и описываются в п.13.1.2.
     
     13.1.1.1. Запрос регистрации услуги
     
     Положения данного подраздела применимы к ООД только в тех случаях, когда оно выступает инициатором процедуры регистрации.
     
     ООД запрашивает регистрацию факультативных услуг пользователя и/или получает текущие значения применяемых факультативных услуг пользователя, передавая через интерфейс ООД/ХХД пакет ЗАПРОС РЕГИСТРАЦИИ и начиная отсчет тайм-аута "ответ на запрос регистрации" (Т28).
     
     Пакет ЗАПРОС РЕГИСТРАЦИИ может быть передан без попытки регистрации каких-либо факультативных услуг пользователя (т.е. без поля "регистрация") с целью получения текущих значений применяемых факультативных услуг пользователя, либо для отклонения запроса услуг или недоступных значений услуг.
     Передав пакет ЗАПРОС РЕГИСТРАЦИИ, ООД должно дожидаться пакета ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ прежде чем передать пакет ЗАПРОС ВЫЗОВА.
     
     Неполучение пакета ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ до истечения Т28 после передачи пакета ЗАПРОС РЕГИСТРАЦИИ рассматривается как ошибка. Процедура регистрации повторяется вплоть до максимального числа раз R28. После этого пакетный уровень уведомляет соответствующий логический объект о том, что он не получил подтверждения процедуры регистрации.
     
     См. также:
     
     Формат пакета ЗАПРОС РЕГИСТРАЦИИ (п.12.9.1 и черт.26);
     
     прием ответа на регистрацию услуги (п.13.1.1.3);
     
     тайм-аут "ответ на запрос регистрации" (Т28) (табл.32);
     
     счет повторных передач запроса регистрации (Р28) (табл.33).
     
     13.1.1.2. Обработка запроса регистрации услуги
     
     Положения данного подраздела применимы к ООД только в конфигурации ООД/ООД, если ООД действует как ответчик в процедуре регистрации. Они всегда применимы к АКД при использовании процедуры регистрации.
     
     Получив пакет ЗАПРОС РЕГИСТРАЦИИ (даже без поля "регистрация"), ООД или АКД должно будет сообщить доступность и текущие значения всех применимых факультативных услуг пользователя для данного интерфейса, передав через интерфейс ООД/ХХД пакет ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ. О факультативных услугах пользователя, которые не подлежат процедуре регистрации, не сообщается в пакете ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ. Кроме того, пакет ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ содержит соответствующий код причины.
     

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

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

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

     Процедура регистрации конкретной факультативной услуги пользователя зависит от этой услуги. В табл.10 приведена классификация факультативных услуг пользователя с точки зрения предъявляемых к ним требований со стороны процедуры регистрации.
     
     

Таблица 10

     
Классификация факультативных услуг пользователя для регистрации

     
     Условные обозначения:
     
     ЗР - пакет ЗАПРОС РЕГИСТРАЦИИ.
     
     ПР - пакет ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ.     
________________
      Классификация услуг на обязательные и дополнительные приведена в табл.9.
     
      Термин "факультативная услуга пользователя" применительно к процедуре регистрации включает параметры "диапазоны логических каналов". В число этих параметров входят "однонаправленный исходящий логический канал" и "однонаправленный входящий логический канал". Предметом соглашения являются значения соответствующих параметров (т.е. граничных значений) однонаправленных входящих логических каналов (НВК и ВВК), двухнаправленных логических каналов (НДК и ВДК) и однонаправленных исходящих логических каналов (НИК и ВИК).
     
      Процедура регистрации позволяет использовать восемь "регистрирующих услуг". К этим регистрируемым услугам, которые используются только при поддержке процедуры регистрации, относятся:
     
     а) регистрируемая услуга "значения несогласовываемых услуг";
     
     б) регистрируемая услуга "доступность услуг";
     
     в) регистрируемая услуга "услуги, согласовываемые в любое время";
     
     г) регистрируемая услуга "услуги, согласовываемые только в том случае, если все логические каналы, используемые для виртуальных соединений, находятся в состоянии р1";
     
     д) регистрируемая услуга '"нестандартные рекомендуемые размеры пакета";
     
     е) регистрируемая услуга "нестандартные рекомендуемые размеры окна";
     
     ж) регистрируемая услуга "назначение рекомендуемых классов пропускной способности";
     
     з) регистрируемая услуга "диапазоны типов логического канала".
     
     регистрируемые услуги по подпунктам д), е) и ж) используются для согласования факультативных услуг пользователя с тем же самым именем. Однако регистрируемая услуга отличается от факультативной услуги пользователя.
     
      "Нет" означает, что соответствующий бит в регистрируемой услуге должен быть установлен в значение 0.
     
      Значения для этих услуг могут регистрироваться только в том случае, если все логические каналы, используемые для виртуальных соединений, находятся в состоянии р1.
     
     
     Отсутствие регистрации услуг в пакете ЗАПРОС РЕГИСТРАЦИИ означает нежелательность изменения ранее достигнутого соглашения относительно этих услуг.
     
     Отсутствие регистрации и услуг в пакете ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ означает, что соответствующие услуги не обеспечиваются или запрещены для согласования посредством услуги "динамическая регистрация услуги".
     
     ООД должны игнорировать регистрацию услуг, которые они не обеспечивают или которые им неизвестны.
     
     См. также:
     
     кодирование регистрации услуг (разд.16).
     
     13.1.2.1. Факультативные услуги пользователя класса 1
     
     Для факультативных услуг пользователя, входящих в класс 1, процедуры регистрации не применяются. К таким услугам относятся следующие:
     
     а) услуги, для которых согласование запрещено:
     
     динамическая регистрация услуги (п.13.1);
     
     услуги, относящиеся к закрытой группе пользователей (п.13.14);
     
     услуги, относящиеся к закрытой группе двух пользователей (п.13.15);
     
     услуги, относящиеся к идентификации пользователя сети (п.13.21);
     
     группа с выбором (п.13.24);
     
     б) услуги, для которых не требуется согласование (это обязательные услуги, которые ООД может запросить в любое время на повызывной основе):
     
     быстрая выборка (п.13.16);
     
     выбор и индикация транзитной задержки (п.13.27);
     
     в) услуги, которые использует только АКД:
     
     уведомление о переадресации вызова и об отражении вызова (п.13.25.3);
     
     г) услуги, для которых применимость процедуры регистрации находится на стадии изучения:
     
     абонирование ПЧЭО (п.13.23.1);
     
     переадресация вызова (п.13.25.1);
     
     услуги, относящиеся к отражению вызова (п.13.25.2).
     
     13.1.2.2. Использование регистрации услуг, применимых для факультативных услуг пользователя класса 2
     
     В классе 2 имеется единственная факультативная услуга пользователя - запрет локальной тарификации (п.13.20).
     
     Процедура регистрации может использоваться только для определения значений факультативных услуг пользователя класса 2. Она не может использоваться для привлечения или отмены этих услуг.
     
     Для определения значений факультативных услуг пользователя класса 2 ООД должно передать через интерфейс ООД/АКД пакет ЗАПРОС РЕГИСТРАЦИИ с регистрацией каких-либо услуг или без них. АКД использует регистрацию услуги "значения несогласуемых услуг" в пакете ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ для задания значений факультативных услуг пользователя класса 2.
     
     13.1.2.3. Использование регистрации услуг, применимых для факультативных услуг пользователя класса 3
     
     В классе 3 имеется четыре факультативные услуги пользователя:
     
     а) реверсивная тарификация (п.13.18);
     
     б) информация о тарифах (на повызывной основе (п.13.22);
     
     в) выбор ПЧЭО (п.13.23.2);
     
     г) уведомление о модификации адреса вызываемой линии (п.13.26).
     
     Процедура регистрации может использоваться только для определения доступности использования факультативных услуг пользователя класса 3. Она не используется для привлечения и отмены этих услуг. Для определения доступности использования факультативных услуг пользователя класса 3 ООД должно передать через интерфейс ООД/АКД пакет ЗАПРОС РЕГИСТРАЦИИ с регистрацией каких-либо услуг или без них. АКД использует регистрацию услуги "доступность услуг" в пакете ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ с целью определения доступности факультативных услуг пользователя для их использования в ООД. Если эта регистрация услуги указывает, что факультативная услуга пользователя класса 3 доступна для использования, то ООД может запросить ее в последующих виртуальных вызовах.
     
     13.1.2.4. Использование регистрации услуг, применимых для факультативных услуг пользователя класса 4
     
     В классе 4 имеются пять факультативных услуг пользователя:
     
     а) запрет входящих вызовов (п.13.5);
     
     б) запрет исходящих вызовов (п.13.6);
     
     в) согласование параметров управления потоком (п.13.12);
     
     г) согласование класса пропускной способности (п.13.13);
     
     д) приемлемость быстрой выборки (п.13.17).
     
     Регистрация услуги "услуги, согласовываемые в любой момент времени", используется ООД в пакете ЗАПРОС РЕГИСТРАЦИИ для указания необходимости привлечения или отмены факультативных услуг пользователя (пакет ЗАПРОС РЕГИСТРАЦИИ, переданный через интерфейс ООД/ХХД, может содержать также и другие регистрации услуг).
     
     Регистрация услуги "услуги, согласовываемые в любой момент времени", используется АКД или ООД в пакете ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ для определения необходимости привлечения или отмены факультативных услуг пользователя. Если эта регистрация услуги указывает, что привлекается услуга "согласование параметра управления потоком" или "согласование класса пропускной способности", то ООД может согласовать их в последующих виртуальных вызовах. Если же эта регистрация услуги, указывает, что привлекаются услуги "запрет входящих вызовов", "запрет исходящих вызовов" и/или "приемлемость быстрой выборки", то эти услуги становятся действующими для последующих виртуальных соединений.
     
     Примечания:
     
     1. Привлечение/отмена услуг "запрет входящих вызовов" и/или "запрет исходящих вызовов" не изменяет значений параметров для диапазонов типов логических каналов (НВК, ВВК, НДК, ВДК, НИК и ВИК).
     
     2. В конфигурации ООД/ООД процедура регистрации может применяться для услуг "запрет входящих вызовов", "запрет исходящих вызовов" и "приемлемость быстрой выборки" (обычно эти услуги не применяются в данной конфигурации). Услуги "запрет входящих вызовов" и "запрет исходящих вызовов" могут привлекаться/отменяться для управления инициацией виртуального соединения на интерфейсе ООД/ООД. Согласование услуги "приемлемость быстрой выборки" может использоваться для определения возможности обоих ООД поддерживать услугу "быстрая выборка" при установлении виртуального соединения.
     
     
     13.1.2.5. Использование регистрации услуг, применимых для факультативных услуг пользователя класса 5
     
     В классе 5 имеется восемь факультативных услуг пользователя:
     
     а) расширенная порядковая нумерация пакетов (конкретный метод согласования этой услуги изучается в МККТТ) (п.13.2) - класс 5.1;
     
     б) модификация бита Д (п.13.3) - класс 5.1;
     
     в) повторная передача пакета (п.13.4) - класс 5.1;
     
     г) нестандартные рекомендуемые размеры пакета (п.13.9) - класс 5.2;
     
     д) нестандартные рекомендуемые размеры окна (п.13.10) - класс 5.2;
     
     е) рекомендуемое назначение классов пропускной способности  (п.13.11) - класс 5.2;
     
     ж) приемлемость реверсивной тарификации (п.13.19) - класс 5.1;
     
     з) информация о тарифах (на основе интерфейсов) (п.13.22) - класс 5.1.
     
     Набор параметров диапазона логических каналов (НВК, ВВК, НДК, ВДК, НИК и ВИК) также относится к классу 5.2. Этот набор охватывает услуги "однонаправленный исходящий логический канал" (п.13.8).
     
     Примечания:
     
     1. Факультативные услуги пользователя класса 5 в свою очередь подразделяются на услуги, имеющие булево значение (класс 5.1), и услуги, имеющие числовое значение (класс 5.2).
     
     2. В этом подразделе понятие "факультативные услуги пользователя" относится также и к набору параметров, связанных с различными типами логических каналов.
     
     3. Процедура регистрации для ycлуг "нестандартные рекомендуемые размеры пакета", "нестандартные рекомендуемые размеры окна" и "назначение рекомендуемых классов пропускной способности" применяется только при использовании этих услуг в виртуальных соединениях. Для использования этих услуг в постоянных виртуальных каналах процедура регистрации не применяется.
     
     4. ООД может попытаться зарегистрировать значение факультативной услуги пользователя класса 5 без выяснения ее доступности для согласования.
     
     
     Для оценки возможности согласования факультативных услуг пользователя класса 5 ООД должно передать через интерфейс ООД/ХХД пакет ЗАПРОС РЕГИСТРАЦИИ с регистрацией каких-либо услуг или без них. Регистрация услуги "доступность услуг" используется АКД и ООД в пакете ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ, чтобы указать доступность или недоступность факультативных услуг пользователя для их согласования ООД. Если эта регистрация услуги указывает, что факультативная услуга пользователя класса 5 доступна для согласования, то ООД может согласовать для нее значение в последующем пакете ЗАПРОСА РЕГИСТРАЦИИ.
     
     Процедура регистрации значения для такой услуги зависит от того, имеет ли эта услуга булево значение (класс 5.1) или числовое значение (класс 5.2).
     
     Для регистрации значения одной или нескольких факультативных услуг пользователя данного класса ООД передает через интерфейс ООД/ХХД пакет ЗАПРОС РЕГИСТРАЦИИ, содержащий соответствующие регистрации услуг, как указано в табл.10. Соответствующие регистрации услуг, указанные в табл.10, используются ХХД в пакете ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ, чтобы указать значения для каждой факультативной услуги пользователя класса 5, применимой на данном интерфейсе ООД/ХХД.
     
     13.1.2.5.1. Регистрация значений факультативных услуг пользователя для класса 5.1 (булево значение)
     
     Соответствующие регистрации услуг (см. табл.10) используются ООД в пакете ЗАПРОС РЕГИСТРАЦИИ, чтобы определить необходимость привлечения или отмены факультативных услуг пользователя (пакет ЗАПРОС РЕГИСТРАЦИИ, переданный через интерфейс ООД/ХХД, может содержать также и другие регистрации услуг).
     
     Соответствующие регистрации услуг используются АКД или ООД в пакете ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ, чтобы задать привлечение или отмену факультативных услуг пользователя.
     
     13.1.2.5.2. Регистрация значений факультативных услуг пользователя для класса 5.2 (числовое значение)
     
     Соответствующие регистрации услуг (см. табл.10) используются в пакете ЗАПРОС РЕГИСТРАЦИИ, чтобы определить те числовые значения, которые ООД желает согласовать для соответствующих факультативных услуг пользователя класса 5.2 (пакет ЗАПРОС РЕГИСТРАЦИИ, переданный через интерфейс ООД/ХХД, может содержать также другие регистрации услуг).
     
     При использовании регистрации услуг "диапазоны типов логических каналов" согласуемые значения являются параметрами (т.е. граничными точками), связанными с однонаправленными входящими логическими каналами (НВК и ВВК), двухнаправленными логическими каналами (НДК и ВДК) и однонаправленными исходящими логическими каналами (НИК и ВИК), как показано на черт.1. Показанные на черт.1 взаимоотношения между НВК, ВВК, НДК, ВДК, НИК и ВИК должны соблюдаться. При отсутствии однонаправленных входящих логических каналов НВК и ВВК равны нулю. При отсутствии двухнаправленных логических каналов НДК и ВДК равны нулю. При отсутствии однонаправленных исходящих логических каналов НИК и ВИК равны нулю. Кроме того, при регистрации услуги "диапазоны типов логических каналов" указывается также общее число логических каналов, которые ООД желает использовать для виртуальных соединений. Это общее число равно сумме однонаправленных входящих логических каналов, двухнаправленных логических каналов и однонаправленных исходящих логических каналов.
     
     Соответствующие регистрации услуг используются АКД или ООД в пакете ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ для определения значений соответствующих факультативных услуг пользователя класса 5.2. Между значениями факультативных услуг пользователя класса 5.2 (если они используются) в пакете ЗАПРОС РЕГИСТРАЦИИ и значениями в пакете ПОДТВЕРЖДЕНИЕ РЕГИСТРАЦИИ существуют следующие взаимоотношения:
     
     а) если запрошенное значение приемлемо, то указывается запрошенное значение;
     
     б) если запрошенное значение больше максимально допустимого значения для данной услуги, то указывается максимально допустимое значение;
     
     в) если запрошенное значение меньше минимально допустимого значения для данной услуги, то указывается минимально допустимое значение.
     
     13.2. Расширенная порядковая нумерация пакетов
     
     Расширенная порядковая нумерация пакетов - это факультативная услуга пользователя, согласовываемая между ООД и ХХД, на определенный период времени. Она применима в общем случае ко всем логическим каналам интерфейса ООД/ХХД.
     
     Эта услуга пользователя, если она абонирована, обеспечивает порядковую нумерацию пакетов по модулю 128. При отсутствии этой услуги порядковая нумерация пакетов выполняется по модулю 8.
     
     13.3. Модификация бита Д
     
     Эта факультативная услуга пользователя применима только в конфигурации ООД/АКД.
     
     Модификация бита Д - это факультативная услуга пользователя, согласовываемая между ООД и АКД на определенный период времени. Она применима в общем случае ко всем логическим каналам интерфейса ООД/ХХД. Эта услуга предназначена для использования только теми ООД, которые были предназначены для работы в сетях данных общего пользования до введения бита Д с целью обеспечения межконцевой значимости Ппм. Она позволяет этим ООД продолжать работать с Ппм межконцевой значимости в национальной сети.
     
     При обмене данными внутри национальной сети эта услуга пользователя, если она абонирована, обеспечивает:
     
     а) изменение значения бита 7 идентификатора общего формата с 0 на 1 во всех пакетах ЗАПРОС ВЫЗОВА и ВЫЗОВ ПРИНЯТ, а также значения бита Д во всех пакетах ДАННЫЕ, полученных от ООД;
     
     б) установление значения бита 7 идентификатора общего формата в 0 во всех пакетах ВХОДЯЩИЙ ВЫЗОВ и СОЕДИНЕНИЕ УСТАНОВЛЕНО, а также значения бита Д во всех пакетах ДАННЫЕ, переданных в ООД.
     
     При международной связи применяется преобразование б), а преобразование а) не используется. Другие правила преобразования при международной связи являются предметом двухстороннего соглашения между администрациями связи.
     
     См. также:
     
     бит подтверждения доставки (пп.6.3 и 7.1.4).
     
     13.4. Повторная передача пакета
     
     Повторная передача пакета - это факультативная услуга пользователя, согласовываемая между ООД и АКД на определенный период времени. Она применима в общем случае ко всем логическим каналам интерфейса ООД/ХХД. Процедуры, использующие эту услугу для запроса повторной передачи пакетов ДАННЫЕ, применимы только во время нахождения логического канала в состоянии ГОТОВНОСТЬ К УПРАВЛЕНИЮ ПОТОКОМ (d1).
     
     В конфигурации ООД/ООД для использования этой услуги требуется отдельное соглашение в каждом направлении передачи данных. При передаче пакетов ДАННЫЕ в определенном направлении использование этой услуги позволяет ООД, принимающему пакеты ДАННЫЕ, передавать пакеты НЕПРИЕМ и требовать от ООД, передающего пакеты ДАННЫЕ, обрабатывать принимаемые пакеты НЕПРИЕМ, как описано ниже. В конфигурации ООД/АКД оборудование ООД, абонирующее эту услугу, может передавать пакеты НЕПРИЕМ, но никогда не может принимать эти пакеты.
     
     13.4.1. Запрос повторной передачи пакетов ДАННЫЕ
     
     ООД запрашивает повторную передачу одного или нескольких последовательных пакетов ДАННЫЕ, передавая через интерфейс ООД/ХХД пакет НЕПРИЕМ, указывающий логический канал и порядковый номер приема пакета Ппм и начиная отсчет тайм-аута "ответ на неприем" (Т27). Значение указанного Ппм должно быть больше или равно значению последнего Ппм, переданного этим ООД, и меньше чем Ппд следующего пакета ДАННЫЕ, подлежащего передаче противоположным ХХД. Если значение Ппм находится вне этого диапазона, то ХХД, принявшее такой пакет НЕПРИЕМ, начнет процедуру повторной установки. АКД укажет причину "локальная процедурная ошибка", а ООД - "по инициативе ООД". В любом случае будет указана диагностика "неправильный Ппм".     

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

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

     13.7. Однонаправленный исходящий логический канал
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений.
     
     Однонаправленный исходящий логический канал - это факультативная услуга пользователя, согласовываемая между ООД и АКД на определенный период времени. Эта услуга пользователя, если она абонирована, ограничивает использование логического канала только инициацией исходящих виртуальных соединений.
     
     Примечания:
     
     1. Однонаправленный исходящий логический канал, используемый для виртуальных соединений, сохраняет свои способности дуплексного обмена.
     
     На черт.1 показаны правила, в соответствии с которыми однонаправленным исходящим логическим каналам для виртуальных соединений могут назначаться идентификаторы логического канала.
     
     2. Если все логические каналы для виртуальных соединений на интерфейсе ООД/ХХД являются однонаправленными исходящими, то результат эквивалентен услуге "запрет входящих вызовов" (за исключением того, что примечание 2 к п.13.5 не применимо).
     
     
     См. также:
     
     факультативная услуга пользователя "запрет входящих вызовов" (п.13.5).
     
     13.8. Однонаправленный входящий логический канал
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений.
     
     Однонаправленный входящий логический канал - это факультативная услуга пользователя, согласовываемая между ООД и ХХД на определенный период времени. Эта услуга пользователя, если она абонирована, ограничивает использование логического канала только приемом входящих виртуальных соединений.
     
     Примечание. Однонаправленный входящий логический канал, используемый для виртуальных соединений, сохраняет свои способности дуплексного обмена.
     
     
     На черт.1 показаны правила, в соответствии с которыми однонаправленным входящим каналам для виртуальных соединений могут назначаться идентификаторы логического канала.
     
     Примечание. Если все логические каналы для виртуальных соединений на интерфейсе ООД/ХХД являются однонаправленными входящими, то результат эквивалентен услуге "запрет исходящих вызовов".
     
     
     См. также:
     
     факультативная услуга пользователя "запрет исходящих вызовов" (п.13.6).
     
     13.9. Нестандартные рекомендуемые размеры пакета
     
     Нестандартные рекомендуемые размеры пакета - это факультативная услуга пользователя, согласовываемая между ООД и ХХД на определенный период времени. Эта услуга пользователя, ecли она абонирована, обеспечивает выбор рекомендуемого размера пакета для каждого направления передачи данных из списка размеров пакета, обеспечиваемых ООД и ХХД. Некоторые ХХД могут ограничивать рекомендуемый размер пакета, чтобы сделать его равным в обоих направлениях передачи данных через интерфейс ООД/ХХД. Рекомендуемый размер пакета, используемый ООД, всегда должен включать возможность его установки в значение 128. При отсутствии этой услуги рекомендуемый размер пакета для каждого направления передачи данных - 128 октетов.
     
     Примечание. В этом подразделе термин "размер пакета" относится к максимальной длине поля "данные пользователя" в пакете ДАННЫЕ.
     
     
     Размеры пакета, отличные от рекомендуемых, могут быть согласованы для виртуального соединения при помощи услуги "согласование параметров управления потоком" и могут быть приняты на некоторый период времени для каждого постоянного виртуального канала.
     
     См. также:
     
     Факультативная услуга пользователя "согласование параметров управления потоком" (п.13.12).
     
     13.10. Нестандартные рекомендуемые размеры окна
     
     Нестандартные рекомендуемые размеры окна - это факультативная услуга пользователя, согласовываемая между ООД и ХХД на определенный период времени. Эта услуга пользователя, если она абонирована, обеспечивает выбор рекомендуемого размера окна для каждого направления передачи данных из списка размеров окна, обеспечиваемых ООД и ХХД. Некоторые ХХД могут ограничивать рекомендуемый размер окна, чтобы сделать его одинаковым в обоих направлениях передачи данных через интерфейс ООД/ХХД. Рекомендуемый размер окна, используемый ООД, должен всегда предусматривать возможность его установки в значение 2. При отсутствии этой возможности рекомендуемый размер окна для каждого направления передачи данных - 2.
     
     Значения, отличные от рекомендуемых размеров окна, могут быть согласованы для виртуального соединения при помощи услуги "согласование параметров управления потоком" и приняты на некоторый период времени для каждого постоянного виртуального канала.
     
     См. также:
     
     факультативная услуга пользователя "согласование параметров управления потоком" (п.13.12).
     
     13.11. Назначение рекомендуемых классов пропускной способности
     
     Назначение рекомендуемых классов пропускной способности - это факультативная услуга пользователя, согласовываемая между ООД и ХХД на определенный период времени. Эта услуга пользователя, если она абонирована, обеспечивает выбор рекомендуемого класса пропускной способности для каждого направления передачи данных из списка классов пропускной способности, обеспечиваемых ООД и ХХД. Некоторые ХХД могут ограничивать рекомендуемые классы пропускной способности, чтобы сделать их одинаковыми в обоих направлениях передачи данных. При отсутствии этой услуги рекомендуемые классы пропускной способности соответствуют пользовательскому классу услуг (т.е. скорости передачи по линии доступа) ООД. В конфигурации ООД/АКД они не могут превышать максимальный класс пропускной способности, обеспечиваемый АКД.
     
     Рекомендуемые классы пропускной способности представляют собой классы максимальной пропускной способности, которые могут назначаться любому виртуальному соединению данного интерфейса ООД/ХХД. Значения, отличные от рекомендуемых классов пропускной способности, могут быть согласованы для виртуального соединения при помощи услуги "согласование класса пропускной способности" и приняты на некоторый период времени для каждого постоянного виртуального канала.
     
     См. также:
     
     факультативная услуга пользователя "согласование класса пропускной способности" (п.13.13);
     
     значение класса пропускной способности (п.15.2.2.2).
     
     13.12. Согласование параметров управления потоком
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений.
     
     Согласование параметров управления потоком - это факультативная услуга пользователя, согласовываемая между ООД и ХХД на определенный период времени для виртуальных соединений. Эта услуга пользователя, если она абонирована, допускает согласование параметров управления потоком на повызывной основе. Параметрами управления потоком являются размер пакета и размер окна на данном интерфейсе ООД/ХХД для каждого направления передачи данных.
     
     Примечания:
     
     1. Термин "размер пакета" указывает максимальную длину поля "данные пользователя" в пакете ДАННЫЕ.
     
     При отсутствии услуги "согласование параметров управления потоком" параметрами управления потоком, подлежащими использованию на конкретном интерфейсе ООД/ХХД, являются рекомендуемые размеры пакета и рекомендуемые размеры окна.
     
     2. Термин "рекомендуемый размер окна" означает либо 2, либо значение, выбранное при помощи услуги "нестандартные рекомендуемые размеры окна". Термин "рекомендуемый размер пакета" означает либо 128, либо значение, выбранное при помощи услуги "нестандартные рекомендуемые размеры пакета".
     
     
     Если вызывающему ООД абонирована услуга "согласование параметров управления потоком", оно может отдельно запросить (в пакете ЗАПРОС ВЫЗОВА) размер пакета и/или размер окна для обоих направлений передачи данных виртуального соединения. Если конкретный размер окна явно не затребован в пакете ЗАПРОС ВЫЗОВА, то ХХД будет полагать, что для обоих направлений передачи данных затребованы рекомендуемые размеры окна. Если конкретные размеры пакета явно не затребованы, то ХХД будет полагать, что для обоих направлений передачи данных затребованы рекомендуемые размеры пакета.
     
     Если вызываемому ООД абонирована услуга "согласование параметров управления потоком", то в каждом пакете ВХОДЯЩИЙ ВЫЗОВ указаны те размеры пакета и окна, с которых ООД может начать согласование (в конфигурации ООД/ООД такая индикация параметров осуществляется только в том случае, если вызывающее ООД предусмотрело это в своем пакете ЗАПРОС ВЫЗОВА). Между размером пакета (Р) и/или размером окна (W), затребованными в пакете ЗАПРОС ВЫЗОВА, и этими же параметрами, указанными в пакете ВХОДЯЩИЙ ВЫЗОВ, нет никакой взаимосвязи (исключая конфигурацию ООД/ООД, где пакет ЗАПРОС ВЫЗОВА и пакет ВХОДЯЩИЙ ВЫЗОВ - это один и тот же пакет). Вызываемое ООД может запросить размеры окна и/или размеры пакета посредством услуг в пакете ВЫЗОВ ПРИНЯТ. В табл.11 приведены единственно правильные запросы услуг в пакете ВЫЗОВ ПРИНЯТ, определяемые индикациями услуг в пакете ВХОДЯЩИЙ ВЫЗОВ. Если в пакете ВЫЗОВ ПРИНЯТ отсутствует запрос услуг, то предполагается, что вызываемое ООД приняло значения, указанные в пакете ВХОДЯЩИЙ ВЫЗОВ. В конфигурации ООД/ООД при отсутствии индикаций услуг в пакете ВХОДЯЩИЙ ВЫЗОВ и при отсутствии запроса услуги в пакете ВЫЗОВ ПРИНЯТ предполагается, что вызываемое ООД приняло рекомендуемые значения.
     
     

Таблица 11

Правильные запросы параметров "управление потоком" в пакете ВЫЗОВ ПРИНЯТ
в ответ на индикации параметров "управление потоком" в пакете ВХОДЯЩИЙ ВЫЗОВ

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

Таблица 12

     
Правильные индикации параметров "управление потоком" в пакете СОЕДИНЕНИЕ УСТАНОВЛЕНО
 в ответ на запросы параметров "управление потоком" в пакете ЗАПРОС ВЫЗОВА

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

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

     См. также:
     
     кодирование услуги "согласование класса пропускной способности" (пп.15.2.1 и 15.2.2.2);
     
     факультативная услуга пользователя "назначение рекомендуемых классов пропускной способности" (п.13.11);
     
     факультативная услуга пользователя "согласование параметров управления потоком" (п.13.12).
     
     13.14. Услуги, относящиеся к закрытой группе пользователей
     
     Описываемые в данном подразделе факультативные услуги пользователя применимы только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Набор факультативных услуг пользователя для закрытой группы пользователя (ЗГП) позволяет пользователям формировать группы ООД с ограниченным входящим и/или исходящим доступом. Различные комбинации ограничений доступа к и/или от ООД, имеющих одну или несколько таких услуг, приводят к различным комбинациям доступности внутри конфигурации сети. На черт.28 показаны некоторые возможности, существующие для гипотетической ситуации.
     
     Существует семь относящихся к ЗГП услуг: пять из них - те, которые каждое ООД и сеть могут согласовать на определенный период времени; две другие услуги позволяют определять ЗГП, выбранную для данного виртуального соединения. К этим семи услугам относятся следующие:
     
     а) закрытая группа пользователей (п.13.14.1); это основная услуга, позволяющая ООД принадлежать одной или нескольким ЗГП;
     
     б) закрытая группа пользователей с исходящим доступом (п.13.14.2).
     
     Это вариант а), позволяющий одному ООД осуществлять исходящие вызовы к другому ООД в открытой части сети (т.е. к ООД, не принадлежащим ни к какой ЗГП) и к ООД из других ЗГП, обладающих возможностью входящего доступа (см. ниже подпункт в);
     
     в) закрытая группа пользователей с входящим доступом (п.13.14.3);
     
     Это вариант а), позволяющий одному ООД принимать входящие вызовы от других ООД из открытой части сети (т.е. из ООД, не принадлежащих ни к какой ЗГП) и из ООД других ЗГП, обладающих возможностью исходящего доступа (см. выше подпункт б);
     
     г) запрет входящих вызовов внутри закрытой группы пользователей (п.13.14.4); это услуга, дополняющая услугу по подпунктам а) или б) и/или в) и предохраняющая ООД от приема любых входящих вызовов от ООД из определенной ЗГП;
     

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

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

Информация закрытой группы пользователей (ЗГП)

     
Черт.28

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

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

     Закрытая группа пользователей с входящим доступом - это факультативная услуга пользователя, согласовываемая между ООД и АКД на определенный период времени для виртуальных соединений. Эта услуга пользователя, если она абонирована, позволяет ООД принадлежать одной или нескольким ЗГП и принимать входящие вызовы от ООД, принадлежащих открытой части сети (т.е. от ООД, не принадлежащих ни к одной ЗГП) и от ООД, принадлежащих другим ЗГП, обладающим возможностью исходящего доступа.
     
     Если услуга "закрытая группа пользователей с входящим доступом" абонирована и если сеть предоставляет ООД возможность не задавать предпочтительную ЗГП и ООД решило не задавать предпочтительную ЗГП, то обе услуги "выбор закрытой группы пользователей" и "выбор закрытой группы пользователей с исходящим доступом" применимы на данном интерфейсе. Во всех других случаях абонирования услуги "закрытая группа пользователей с входящим доступом" ООД должно указать предпочтительную ЗГП и на данном интерфейсе для использования применима только услуга "выбор закрытой группы пользователей".
     
     13.14.4. Запрет входящих вызовов внутри закрытой группы пользователей
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Запрет входящих вызовов внутри ЗГП - это факультативная услуга пользователя, согласовываемая между ООД и АДК на определенный период времени. Эта услуга пользователя, если она абонирована для данной ЗГП, позволяет ООД устанавливать виртуальные соединения с ООД этой ЗГП, но запрещает прием входящих вызовов от ООД этой ЗГП.
     
     13.14.5. Запрет исходящих вызовов "внутри закрытой группы пользователей
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Запрет исходящих вызовов внутри ЗГП - это факультативная услуга пользователя, согласовываемая между ООД и АКД на определенный период времени. Эта услуга пользователя, если она абонирована для данной ЗГП, позволяет ООД принимать виртуальные вызовы от ООД этой ЗГП, но запрещает ООД устанавливать виртуальные соединения с ООД этой ЗГП.
     
     13.14.6. Выбор закрытой группы пользователей
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Выбор закрытой группы пользователей - это факультативная услуга пользователя, которая может использоваться на повызывной основе. Эта услуга может быть запрошена или воспринята ООД только в том случае, если ему абонирована услуга "закрытая группа пользователей" или "закрытая группа пользователей с исходящим доступом" и/или "закрытая группа пользователей с входящим доступом".
     
     Услуга "выбор закрытой группы пользователей" может быть использована вызывающим ООД в пакете ЗАПРОС ВЫЗОВА, чтобы указать ЗГП, выбранную для виртуального соединения.
     
     Услуга "выбор закрытой группы пользователей" используется в пакете ВХОДЯЩИЙ ВЫЗОВ, чтобы указать вызываемому ООД ту ЗГП, которая выбрана для виртуального соединения.
     
     Число ЗГП, к которым может принадлежать ООД, зависит от сети. Если максимальное значение индекса, назначенного для использования оборудованием ООД с целью выбора ЗГП, равно 99 или меньше, то следует использовать базовый формат услуги "выбор ЗГП". Если же максимальное значение назначенного индекса находится в диапазоне между 100 и 9999, то следует использовать расширенный формат услуги "выбор ЗГП".
     
     В некоторых сетях ООД может использовать либо базовый, либо расширенный формат услуги "выбор ЗГП" при значении индекса 99 или меньше.
     
     Примечание. Когда ООД абонирует меньше 101 ЗГП, сеть должна быть способна согласовать максимальное значение индекса, меньшее 100, при запросе со стороны ООД.
     
     
     Наличие в пакете ЗАПРОС ВЫЗОВА обоих форматов или несовместимость формата с количеством абонированных ЗГП является ошибкой, при которой сеть производит завершение соединения с указанием причины "недействительный запрос услуги".
     
     Значение наличия услуги "выбор закрытой группы пользователей" в пакетах ЗАПРОС ВЫЗОВА и ВХОДЯЩИЙ ВЫЗОВ приведено в табл.13 и 14 соответственно.
     
     

Таблица 13

     
Содержимое услуг, относящихся к закрытой группе пользователей, в пакетах ЗАПРОС ВЫЗОВА

     
     Условные обозначения:
     
     ВД - входящий доступ;
     
     ИД - исходящий доступ.    
________________      
      Наличие двух услуг "выбор закрытой группы пользователей" и "выбор закрытой группы пользователей с исходящим доступом" в одном пакете ЗАПРОС ВЫЗОВА не допускается.
     
      ЗГП без предпочтения не допускается.
     
      Если исходящие вызовы запрещены внутри указанной ЗГП, либо внутри предпочтительной или единственной ЗГП, то это соединение завершается.
     
      Если исходящие вызовы запрещены внутри указанной ЗГП, либо внутри предпочтительной или единственной ЗГП, то применим только исходящий доступ.
     
      При международных соединениях, если адресуемая сеть не поддерживает услугу "выбор закрытой группы пользователей с исходящим доступом", то соединение может быть завершено, даже если вызываемое ООД принадлежит к указанной ЗГП или к открытой части или имеет входящий доступ.
     
     

Таблица 14

     
Содержимое услуг, относящихся к закрытой группе пользователей, в пакетах ВХОДЯЩИЙ ВЫЗОВ

     
     Условные обозначения: ВД - входящий доступ; ИД - исходящий доступ.
________________     
      АКД никогда не поместит две услуги: "выбор закрытой группы пользователей" и "выбор закрытой группы пользователей с исходящим доступом" в один пакет ВХОДЯЩИЙ ВЫЗОВ.
     
      ЗГП без предпочтения не допускается.
     
      Если входящие вызовы запрещены внутри данной ЗГП, то такой вызов блокируется; входящий вызов отсутствует.
     
      Если входящие вызовы запрещены внутри данной ЗГП, то применим только входящий доступ и пакет ВХОДЯЩИЙ ВЫЗОВ не содержит ни услуги "выбор закрытой группы пользователей", ни услуги "выбор закрытой группы пользователей с исходящим доступом".
     
      Если входящие вызовы запрещены внутри данной ЗГП, то применим только входящий доступ.
     
     
     См. также:
     
     кодирование услуги "выбор закрытой группы пользователей" (пп.15.2.1 и 15.2.2.3).
     
     13.14.7. Выбор закрытой группы пользователей с исходящим доступом
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Выбор закрытой группы пользователей с исходящим доступом - это факультативная услуга пользователя, которая может использоваться на повызывной основе. Эта услуга может использоваться только в том случае, если сеть предоставляет ООД возможность не задавать предпочтительную ЗГП и ООД решило ее не задавать. Эта услуга может быть запрещена ООД только в том случае, если ему абонирована услуга "закрытая группа пользователей с исходящим доступом" или обе услуги "закрытая группа пользователей с исходящим доступом" и "закрытая группа пользователей с входящим доступом". Эта услуга может быть воспринята ООД только в том случае, если ему абонирована услуга "закрытая группа пользователей с входящим доступом" или обе услуги "закрытая группа пользователей с входящим доступом" и "закрытая группа пользователей с исходящим доступом".
     
     Услуга "выбор закрытой группы пользователя с исходящим доступом" может быть использована вызывающим ООД в пакете ЗАПРОС ВЫЗОВА, чтобы определить ЗГП, выбранную для виртуального соединения, и указать, что возможность исходящего доступа также желательна.
     
     Услуга "выбор закрытой группы пользователей с исходящим доступом" используется в пакете ВХОДЯЩИЙ ВЫЗОВ, чтобы указать вызываемому ООД ту ЗГП, которая выбрана для виртуального соединения, и то, что вызывающее ООД использовало исходящий доступ.
     

     Число ЗГП, к которым может принадлежать ООД, зависит от сети. Если максимальное значение индекса, назначенного для использования оборудованием ООД с целью выбора ЗГП, равно 99 или меньше, то следует использовать базовый формат услуги "закрытая группа пользователей с выбором исходящего доступа". Если же максимальное значение назначенного индекса находится в диапазоне от 100 до 9999, то следует использовать расширенный формат услуги "закрытая группа пользователя с выбором исходящего доступа".
     
     В некоторых сетях ООД разрешается использовать либо основной, либо расширенный формат услуги "закрытая группа пользователей с выбором исходящего доступа" при значении индекса 99 или меньше.
     
     Примечание. Если ООД абонировано для менее чем 101 ЗГП, то сеть должна быть способна согласовывать максимальное значение индекса, меньшее 100 при запросе со стороны ООД.
     
     
     При появлении в пакете ЗАПРОС ВЫЗОВА обоих форматов либо при несовместимости формата с количеством абонируемых ЗГП является ошибкой, при которой сеть завершает соединение с указанием причины "запрос недействительной услуги".
     
     Значение наличия услуги "выбор закрытой группы пользователей с исходящим доступом" в пакетах ЗАПРОС ВЫЗОВА и ВХОДЯЩИЙ ВЫЗОВ приведено в табл.13 и 14 соответственно.
     
     См. также:
     
     кодирование услуги "выбор закрытой группы пользователей с исходящим доступом" (пп.15.2.1 и 15.2.2.4).
     
     13.14.8. Отсутствие обеих услуг выбора ЗГП
     
     Значение отсутствия обеих услуг "выбор закрытой группы пользователей" и "выбор закрытой группы пользователей с исходящим доступом" в пакете ЗАПРОС ВЫЗОВА и ВХОДЯЩИЙ ВЫЗОВ указано в табл.13 и 14 соответственно.
     
     13.15. Услуги, относящиеся к закрытой группе двух пользователей
     
     Описываемые в данном подразделе факультативные услуги пользователя применимы только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Набор услуг, относящихся к закрытой группе двух пользователей (ЗГДП), позволяет парам ООД устанавливать двухсторонние отношения, допускающие доступ друг к другу при ограничении доступа к другим (или от других) ООД, с которыми такие отношения не установлены. Различные комбинации ограничений доступа для ООД, обеспечивающих эти услуги, приводят к различным комбинациям доступности внутри сети.
     
     Существуют три относящиеся к ЗГДП услуги: две из них могут быть согласованы между любым ООД и сетью на определенный период времени; третья позволяет указывать ЗГДП, выбранную для данного виртуального соединения. Этими услугами являются:
     

     а) закрытая группа двух пользователей (п.13.15.1) - это базовая услуга, которая позволяет ООД принадлежать одной или нескольким ЗГДП;
     
     б) закрытая группа двух пользователей с исходящим доступом (п.13.15.2) - это услуга (п.13.15.1), но позволяющая ООД выдавать исходящие вызовы к ООД открытой части сети (т.е. к ООД, не принадлежащим ни к одной ЗГДП);
     
     в) выбор закрытой группы двух пользователей (п.13.15.3) - эта услуга обеспечивает спецификацию ЗГДП, относящуюся к конкретному виртуальному соединению.
     
     ООД может принадлежать одной или нескольким ЗГДП. Каждое ООД, принадлежащее хотя бы к одной ЗГДП, обеспечивает либо услугу "закрытая группа двух пользователей", либо услугу "закрытая группа двух пользователей с исходящим доступом". В конкретной ЗГДП допускается абонировать одному ООД услугу "закрытая группа двух пользователей", а другому ООД - услугу "закрытая группа двух пользователей с исходящим доступом".
     
     Если ООД, принадлежащее одной или нескольким ЗГДП, устанавливает виртуальное соединение, то в пакете ЗАПРОС ВЫЗОВА оно должно указать ЗГДП, выбранную посредством услуги "выбор закрытой группы двух пользователей". Если ООД, принадлежащее одной или нескольким ЗГДП, принимает виртуальный вызов, то в пакете ВХОДЯЩИЙ ВЫЗОВ будет указана та ЗГДП, которая выбрана посредством использования услуги "выбор закрытой группы двух пользователей".
     
     Число ЗГДП, к которым может принадлежать ООД, зависит от сети.
     
     ООД может одновременно обеспечивать одну из услуг, относящихся к ЗГДП, и одну или несколько услуг, относящихся к ЗГП и описанных в п.13.14. Услуги ЗГП и ЗГДП независимы друг от друга. Например, вызов внутри ЗГП не рассматривается как вызов исходящего доступа по отношению к услугам ЗГДП.
     
     13.15.1. Закрытая группа двух пользователей
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Закрытая группа двух пользователей - это факультативная услуга пользователя, согласовываемая между ООД и АКД на определенный период времени для виртуальных соединений. Эта услуга, если она абонирована, позволяет ООД принадлежать одной или нескольким ЗГДП. Для пары ООД, между которыми достигнуто двухстороннее соглашение об обмене данными, ЗГДП позволяет осуществлять его, но запрещает взаимодействие со всеми другими ООД.
     
     13.15.2. Закрытая группа двух пользователей с исходящим доступом
     

     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Закрытая группа двух пользователей с исходящим доступом - это факультативная услуга пользователя, согласовываемая между ООД и АКД на определенный период времени для виртуальных соединений. Эта услуга пользователя, если она абонирована, позволяет ООД принадлежать одной или нескольким ЗГДП и выдавать виртуальные вызовы к ООД открытой части сети (т.е. к ООД, не принадлежащим ни к одной ЗГДП).
     
     13.15.3. Выбор закрытой группы двух пользователей
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Выбор закрытой группы двух пользователей - это факультативная услуга, которая может использоваться на повызывной основе. Эта услуга должна быть запрошена или будет воспринята ООД только в случае, если этому ООД абонирована услуга "закрытая группа двух пользователей" или "закрытая группа двух пользователей с исходящим доступом".
     
     Услуга "выбор закрытой группы двух пользователей" используется вызывающим ООД в пакете ЗАПРОС ВЫЗОВА, чтобы определить ЗГДП, выбранную для виртуального соединения. Длина адреса вызываемого ООД должна быть закодирована одними нулями.
     
     Услуга "выбор закрытой группы двух пользователей" используется в пакете ВХОДЯЩИЙ ВЫЗОВ, чтобы указать вызываемому ООД ту ЗГДП, которая выбрана для виртуального соединения. Длина адреса вызывающего ООД кодируется одними нулями.
     
     См. также:
     
     кодирование услуги "выбор закрытой группы двух пользователей (п.15.2.1 и п.15.2.2.5).
     
     13.16. Быстрая выборка
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений.
     
     Быстрая выборка - это факультативная услуга пользователя, которая может быть запрошена ООД для данного виртуального соединения. ООД в конфигурации ООД/АКД может использовать эту услугу без предварительного согласования. В конфигурации ООД/ООД использование этой услуги требует предварительного согласования между двумя ООД. Достигаемое соглашение позволяет обоим ООД инициировать вызовы с этой услугой и требует от них обработки принятых вызовов с использованием этой услуги.
     
     Если ООД в конфигурации ООД/АКД устанавливает соединение, используя быструю выборку, с другим ООД, для которого не абонирована услуга "приемлемость быстрой выборки", то сеть завершит это соединение с указанием причины "приемлемость быстрой выборки не абонирована". Если ООД в конфигурации ООД/ООД устанавливает соединение с ООД, с которым не согласовано использование быстрой выборки, то вызываемое ООД может завершить это соединение с указанием причины "по инициативе ООД" и диагностики "быстрая выборка не абонирована".
     

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

     См. также:
     
     пакеты установления и завершения соединения (п.12.2);
     
     кодирование услуги "быстрая выборка" (п.15.2.1 и п.15.2.2.6);
     
     факультативная услуга пользователя "приемлемость быстрой выборки (п.13.17).
     
     13.17. Приемлемость быстрой выборки
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Приемлемость быстрой выборки - это факультативная услуга пользователя, согласовываемая между ООД и АКД на определенный период времени для виртуальных соединений. Эта услуга пользователя, если она абонирована, позволяет АКД передавать ООД входящие вызовы, запрашивающие услугу "быстрая выборка". При отсутствии этой услуги АКД не будет передавать ООД входящие вызовы, требующие услуги "быстрая выборка".
     
     Если вызываемому ООД абонирована услуга "приемлемость быстрой выборки", то оно будет извещено, что "быстрая выборка" вместе с указанием наличия ограничения на ответ была запрошена путем введения услуги "быстрая выборка" в пакет ВХОДЯЩИЙ ВЫЗОВ.
     
     Наличие в пакете ВХОДЯЩИЙ ВЫЗОВ услуги "быстрая выборка", указывающей отсутствие ограничения на выдачу ответа, позволяет вызываемому ООД:
     
     а) в качестве прямого ответа на этот пакет выдавать пакет ВЫЗОВ ПРИНЯТ с полем "данные вызываемого пользователя" длиной до 128 октетов;
     
     б) выдавать в любое время пакет ЗАПРОС ЗАВЕРШЕНИЯ с полем "данные завершающего пользователя" длиной до 128 октетов;
     
     в) принимать после выполнения установления соединения пакет ИНДИКАЦИЯ ЗАВЕРШЕНИЯ с полем "данные завершающего пользователя" длиной до 128 октетов.
     
     Наличие в пакете ВХОДЯЩИЙ ВЫЗОВ услуги "быстрая выборка" с указанием ограничения на выдачу ответа позволяет вызываемому ООД в качестве прямого ответа на этот пакет выдавать пакет ЗАПРОС ЗАВЕРШЕНИЯ с полем "данные завершающего пользователя" длиной до 128 октетов; вызываемому ООД не разрешено передавать пакет ВЫЗОВ ПРИНЯТ.
     
     Поля "данные вызывающего пользователя", "данные вызываемого пользователя" и "данные завершающего пользователя" нельзя разбивать на сегменты при доставке через интерфейс ООД/ХХД.
     
     Поля "данные вызывающего пользователя", "данные вызываемого пользователя" и "данные завершающего пользователя" должны содержать целое число октетов, как указано в п.12.1.
     

     Все другие процедуры обработки виртуального вызова, в которых была запрошена услуга "быстрая выборка", не затрагиваются этим запросом.
     
     См. также:
     
     пакеты установления и завершения соединения (п.12.2);
     
     факультативную услугу пользователя "быстрая выборка" (п.13.6);
     
     процедуры завершения (п.5.5);
     
     кодирование услуги "быстрая выборка" (пп.15.2.1 и 15.2.2.6).
     
     13.18. Реверсивная тарификация
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Реверсивная тарификация - это факультативная услуга пользователя, которую может запросить ООД для конкретного виртуального соединения. Эта услуга, если она применяется, требует, чтобы сеть начисляла все расходы, связанные с представлением виртуального соединения, вызываемому ООД.
     
     См. также:
     
     факультативную услугу пользователя "приемлемость реверсивной тарификации (п.13.19);
     
     кодирование услуги "реверсивная тарификация" (пп 15.2.1 и 15.2.2.6).
     
     13.19. Приемлемость реверсивной тарификации
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Приемлемость реверсивной тарификации - это факультативная услуга пользователя, согласовываемая между ООД и АКД на определенный период времени для виртуальных соединений. Эта услуга пользователя, если она абонирована, предоставляет АКД право передавать в ООД входящие вызовы, запрашивающие услугу "реверсивная тарификация". При отсутствии этой услуги АКД не будет передавать в ООД входящие вызовы, запрашивающие услугу "реверсивная тарификация".
     
     См. также:
     
     факультативная услуга пользователя "реверсивная тарификация" (п.13.18).
     
     13.20. Запрет локальной тарификации
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Запрет локальной тарификации - это факультативная услуга пользователя, согласовываемая между ООД и АКД на определенный период времени для виртуальных соединений. Эта услуга пользователя, если она абонирована, предоставляет АКД право запрещать установление виртуальных соединений, за которые должен платить абонент, следующим образом:
     
     а) не передавая в ООД входящие вызовы, которые требуют услуги "реверсивная тарификация";
     

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

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

Таблица 15

     
Факультативные услуги пользователя в сочетании с услугой "игнорирование ИПС"

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

     Если ООД на некоторый период времени абонирована услуга "информация о тарифах", то эта услуга выполняется в данном ООД, если только это ООД должно оплачивать соединение, без посылки запроса услуги в пакете ЗАПРОС ВЫЗОВА или ВЫЗОВ ПРИНЯТ.
     
     АКД будет использовать услуги "индикация информации о тарифах" в пакете ИНДИКАЦИЯ ЗАВЕРШЕНИЯ или ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ, чтобы сообщить тому ООД, которое должно оплачивать, информацию об оплате за это соединение и/или другую информацию, которая позволит пользователю вычислить сумму оплаты.
     
     См. также:
     
     кодирование услуги "запрос информации о тарифах" (пп.15.2.1 и 15.2.2.8.1);
     
     кодирование услуг "индикация информации о тарифах" (пп.15.2.1 и 15.2.2.8.2-15.2.2.8.5);
     
     13.23. Услуги, относящиеся к ПЧЭО
     
     Эти факультативные услуги пользователя применимы только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Набор факультативных услуг пользователя, относящихся к ПЧЭО, позволяет вызывающему ООД определить внутри страны -  источника вызова одной или последовательности нескольких транзитных сетей ПЧЭО, через которую(ые) будет проходить соединение в случае наличия нескольких транзитных сетей ПЧЭО с одним или последовательностью нескольких шлюзов. В случае международных вызовов эта возможность включает выбор международной сети ПЧЭО в стране - источнике вызова.
     
     При отсутствии обеих услуг "абонирование ПЧЭО" и "выбор ПЧЭО" никакие назначения пользователями транзитных сетей ПЧЭО не действуют.
     
     13.23.1. Абонирование ПЧЭО
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     "Абонирование ПЧЭО" - это факультативная услуга пользователя, которая согласовывается между ООД и АКД на определенный период времени для виртуальных соединений. Эта услуга пользователя, если она абонирована, применима (при условии, что она не игнорируется для отдельного виртуального соединения услугой "выбор ПЧЭО") ко всем виртуальным соединениям при наличии нескольких транзитных сетей с одним или последовательностью нескольких шлюзов. Услуга "абонирование ПЧЭО" обеспечивает последовательность транзитных сетей ПЧЭО, через которые должны проходить вызовы.
     
     См. также:
     

     факультативная услуга пользователя "выбор ПЧЭО" (п.13.23.2).
     
     13.23.2. Выбор ПЧЭО
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Выбор ПЧЭО - эта факультативная услуга пользователя, которая может быть запрошена ООД для данного виртуального соединения. Для использования этой услуги не обязательно абонировать услугу "абонирование ПЧЭО". Будучи использована для конкретного виртуального соединения, эта услуга применима к нему только при наличии нескольких транзитных сетей ПЧЭО с одним или последовательностью нескольких шлюзов. Услуга "выбор ПЧЭО" обеспечивает последовательность транзитных сетей ПЧЭО, через которые должен проходить вызов. При наличии этой услуги в пакете ЗАПРОС ВЫЗОВА полностью игнорируется последовательность транзитных сетей ПЧЭО, которые могут быть специфицированы услугой "абонирование ПЧЭО".
     
     Если ООД выбирает только одну транзитную сеть ПЧЭО, то может использоваться либо основной, либо расширенный формат услуги "выбор ПЧЭО". Если ООД выбирает более одной транзитной сети ПЧЭО, то должен использоваться расширенный формат услуги "выбор ПЧЭО". Появление обоих форматов в пакете ЗАПРОС ВЫЗОВА должно рассматриваться как недопустимый код услуги.
     
     См. также:
     
     факультативная услуга пользователя "абонирование ПЧЭО" (п.13.23.1);
     
     кодирование услуги "выбор ПЧЭО" (пп.15.2.1 и 15.2.2.9).
     
     13.24. Группа с выбором
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Группа с выбором - это факультативная услуга пользователя, согласовываемая между ООД и АКД на определенный период времени для виртуальных соединений. Эта услуга пользователя, если она абонирована, распределяет входящие вызовы, имеющие адрес данной группы с выбором, по назначенной группе интерфейсов ООД/АКД.
     
     Выбор выполняется для входящих виртуальных соединений при условии, что существует, по крайней мере, один незанятый логический канал (исключая однонаправленные исходящие логические каналы), доступный для виртуальных соединений на любом интерфейсе ООД/АКД в этой группе. Как только виртуальное соединение прикрепляется к интерфейсу ООД/АКД, оно рассматривается как обычное соединение.
     
     Если виртуальные соединения устанавливаются по адресу группы с выбором и к тому же указаны конкретные адреса отдельных интерфейсов ООД/АКД, то пакет ИНДИКАЦИЯ ЗАВЕРШЕНИЯ (если не был передан пакет ВЫЗОВ ПРИНЯТ) или пакет СОЕДИНЕНИЕ УСТАНОВЛЕНО, передаваемый выбывающему ООД, возможно будет содержать адрес вызываемого ООД в выбранном интерфейсе ООД/АКД. Он будет содержать также услугу "уведомление о модификации адреса вызываемой линии", включая причину отличия адреса вызываемого ООД от первоначально запрошенного адреса.
     

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

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

     а) сеть запоминает список альтернативных ООД (например В1, В2, ...) для первоначально вызываемого ООД (например ООД Б). Последующие попытки переадресации вызова применяются к каждому из этих адресов в списочном порядке вплоть до завершения соединения.
     
     б) переадресация вызова может осуществляться по логической цепочке; если для ООД В абонирована переадресация вызова на ООД Г, то вызов, переадресованный первоначально из ООД Б и ООД В может быть переадресован к ООД Г; переадресации и отражения вызова могут также осуществляться по цепочке.
     
     Порядок обработки установления соединения в первоначально вызываемом АКД такой же, как и в альтернативном АКД, и должен соответствовать последовательности сигналов прохождения вызова, определенной в рекомендации Х.96 МККТТ. Для тех сетей, которые обеспечивают систематическую переадресацию вызова с предварительным запросом вызываемого ООД, запрос на систематическую переадресацию вызова будет иметь наивысший приоритет в последовательности обработки установления соединения в первоначально вызванном ООД.
     
     13.25.2. Услуги, относящиеся к отражению вызова
     
     13.25.2.1. Абонирование отражения вызова
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Абонирование отражения вызова - это факультативная услуга пользователя, согласовываемая между ООД и АКД на определенный период времени. Эта услуга, если она абонирована, позволяет ООД запросить с помощью услуги "выбор отражения вызова", чтобы отдельный вызов, направленный ему путем передачи пакета ВХОДЯЩИЙ ВЫЗОВ, был отражен к альтернативному ООД.
     
     АКД может использовать сетевой тайм-аут, значение которого согласовано с абонентом, для ограничения промежутка времени между передачей пакета ВХОДЯЩИЙ ВЫЗОВ к первоначально вызванному ООД и выдачей со стороны этого ООД запроса на отражение вызова. При истечении этого тайм-аута первоначально вызванному ООД запрещается использовать услугу "выбор отражения вызова" для отражения вызова. Если же первоначально вызванное ООД попытается отразить вызов и после истечения этого тайм-аута, то сеть завершит соединение.
     
     13.25.2.2. Выбор отражения вызова
     

     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Выбор отражения вызова - это факультативная услуга пользователя, которая может быть использована на повызывной основе. Она может быть запрошена ООД только в том случае, если ему абонирована услуга "абонирование отражения вызова".
     
     Услуга "выбор отражения вызова" может быть использована вызываемым ООД в пакете ЗАПРОС ЗАВЕРШЕНИЯ только в виде прямого ответа на пакет ВХОДЯЩИЙ ВЫЗОВ для определения адреса альтернативного ООД, к которому должен быть отражен вызов. При запросе конкретного виртуального соединения сеть отражает вызов альтернативному ООД и не отвечает вызывающему ООД вследствие процедуры завершения на первоначально вызываемом интерфейсе ООД/АКД.
     
     Если услуга "выбор отражения вызова" используется в пакете ЗАПРОС ЗАВЕРШЕНИЯ, то ООД должно включить в него также все специфицированные МККТТ услуги ООД и данные пользователя, подлежащие передаче альтернативному ООД. В пакет ЗАПРОС ЗАВЕРШЕНИЯ может быть включено до 16 октетов данных пользователя, если первоначальный вызов был выдан без услуги быстрой выборки и до 128 октетов, если первоначальный вызов был выдан с услугой быстрой выборки. Если в пакет ЗАПРОС ЗАВЕРШЕНИЯ не включена ни одна из специфицированных МККТТ услуг ООД, то ни одна услуга не будет передана в пакете ВХОДЯЩИЙ ВЫЗОВ альтернативному ООД. Если в пакет ЗАВЕРШЕНИЕ ВЫЗОВА не включены данные завершающего пользователя, то никакие данные этого пользователя не будут включены в пакет ВХОДЯЩИЙ ВЫЗОВ для альтернативного ООД.
     
     Примечание. В течение переходного периода в некоторых сетях может быть запрещена модификация содержимого отраженного пакета ВХОДЯЩИЙ ВЫЗОВ. В этом случае отражающему ООД не разрешается использовать в пакете ЗАПРОС ЗАВЕРШЕНИЯ никаких данных пользователя или специфицированных МККТТ услуг ООД.
     
     
     Услуги протокола Х.25, содержащиеся в пакете ВХОДЯЩИЙ ВЫЗОВ, который передается альтернативному ООД, - это те услуги, которые содержались бы в пакете ВХОДЯЩИЙ ВЫЗОВ, если бы этот вызов был прямым вызовом, передаваемым из вызывающего ООД к альтернативному ООД. Более того, может иметь место также услуга "переадресация вызова" или "отражение вызова", если они обеспечиваются сетью.
     
     Бит 7 идентификатора общего формата в пакете ВХОДЯЩИЙ ВЫЗОВ при передаче в первоначально вызванное ООД и в альтернативное ООД имеет то же значение, что и в пакете ЗАПРОС ВЫЗОВА.
     

     Если сеть обеспечивает только базовые услуги и если переадресация и отражение вызова уже выполнены, то ООД завершает соединение при использовании услуги "выбор отражения вызова".
     
     См. также:
     
     факультативная услуга пользователя "быстрая выборка" (п.13.16);
     
     кодирование услуги "выбор отражения вызова" (пп.15.2.1 и 15.2.2.10).
     
     13.25.3. Уведомление о переадресации вызова или отражении вызова
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Уведомление о переадресации или отражении вызова - это услуга пользователя, используемая АКД в пакете ВХОДЯЩИЙ ВЫЗОВ для информирования альтернативного ООД о факте и причинах переадресации или отражения вызова и об адресе первоначально вызываемого ООД.
     
     При использовании услуги "уведомление о переадресации или отражении вызова" могут быть указаны следующие причины:
     
     а) переадресация вызова вследствие выхода из строя первоначально вызванного ООД;
     
     б) переадресация вызова вследствие занятости первоначально вызванного ООД;
     
     в) переадресация вызова вследствие поступившего ранее запроса от первоначально вызванного ООД на систематическую переадресацию вызова.
     
     г) отражение вызова первоначально вызванным ООД.
     
     В тех случаях, где сказывается влияние сетевых особенностей, некоторые сети могут использовать также следующую причину:
     
     д) распределение вызова внутри группы с выбором.
     
     См. также:
     
     кодирование услуги "уведомление о переадресации или отражении вызова" (пп.15.2.1 и 15.2.2.11).
     
     13.26. Уведомление о модификации адреса вызываемой линии
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Уведомление о модификации адреса вызываемой линии - это факультативная услуга пользователя, используемая АКД или ООД.
     
     Она используется АКД в пакете СОЕДИНЕНИЕ УСТАНОВЛЕНО или ИНДИКАЦИЯ ЗАВЕРШЕНИЯ для информирования вызывающего ООД о причине отличия адреса вызываемого в этом пакете ООД от адреса, запрошенного в пакете ЗАПРОС ВЫЗОВА.
     
     Если для интерфейса ООД/АКД используется несколько адресов, то ООД использует услугу "уведомление о модификации адреса вызываемой линии" в пакете ЗАПРОС ЗАВЕРШЕНИЯ (только в ответ на пакет ВХОДЯЩИЙ ВЫЗОВ) или в пакете ВЫЗОВ ПРИНЯТ, когда адрес вызываемого ООД в этих пакетах отличается от адреса, указанного в пакете ВХОДЯЩИЙ ВЫЗОВ. Если эта услуга получена из ООД, то АКД должна завершить это соединение в том случае, когда адрес вызываемого ООД не входит в число адресов ООД, используемых для данного интерфейса.
     

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

     кодирование услуги "уведомление о модификации адреса вызываемой линии" (пп.15.2.1 и 15.2.2.12);
     
     факультативная услуга пользователя "группа с выбором" (п.13.24);
     
     факультативные услуги пользователя "переадресация вызова" и "отражение вызова" (п.13.25).
     
     13.27. Выбор и индикация транзитной задержки
     
     Эта факультативная услуга пользователя применима только в службе виртуальных соединений в конфигурации ООД/АКД.
     
     Индикация и выбор транзитной задержки - это факультативная услуга пользователя, которую ООД может запросить для заданного виртуального соединения. Эта услуга позволяет выбирать и указывать на повызывной основе транзитную задержку, применимую для данного виртуального соединения.
     
     Если вызывающее ООД намерено определить для виртуального соединения желаемую транзитную задержку, оно указывает ее желаемое значение при помощи услуги "индикация и выбор транзитной задержки" в пакете ЗАПРОС ВЫЗОВА.
     
     Сеть, если она способна делать это, должна распределять ресурсы и определять маршрут виртуального соединения таким образом, чтобы действующая для этого соединения транзитная задержка не превышала ее желаемое значение.
     
     Пакет ВХОДЯЩИЙ ВЫЗОВ, переданный вызываемому ООД, и пакет СОЕДИНЕНИЕ УСТАНОВЛЕНО, переданный вызывающему ООД, будут содержать значение действующей транзитной задержки для этого виртуального соединения. Эта транзитная задержка может быть меньше, равна или больше транзитной задержки, запрошенной в пакете ЗАПРОС ВЫЗОВА.
     
     См. также:
     
     кодирование услуги "выбор и индикация транзитной задержки" (пп.15.2.1 и 15.2.2.13);
     
     транзитная задержка (п.6.9).
     
     

14. ПРОЦЕДУРЫ ДЛЯ ФАКУЛЬТАТИВНЫХ УСЛУГ ООД, ОПРЕДЕЛЕННЫХ МККТТ

     
     Описываемые в настоящем разделе факультативные услуги ООД, определенные МККТТ, применимы только в службе виртуального соединения.
     
     Эти услуги дополняют другие процедуры настоящего стандарта с целью обеспечения услуг сетевого уровня взаимосвязи открытых систем (ВОС). Эти услуги следуют за специфицированным МККТТ маркером услуги ООД, определенном в п.15.1, и применимы к конфигурациям ООД/АКД и ООД/ООД. Эти услуги передаются сетями общего пользования без изменений.
     
     В определенных ситуациях некоторые из этих услуг могут быть модифицированы шлюзами и/или сетями частного пользования, как будет показано ниже.
     
     14.1. Расширение адреса вызывающего
     
     Расширение адреса вызывающего - это факультативная, определенная МККТТ, услуга ООД, которая может быть использована для заданного виртуального соединения. Она предназначена для прозрачной передачи сетевого адреса вызывающей стороны в пакетах ЗАПРОС ВЫЗОВА и ВХОДЯЩИЙ ВЫЗОВ. Сетевой адрес вызывающей стороны передается логическому объекту вышерасположенного уровня вызываемого ООД.
     
     См. также:
     
     кодирование услуги "расширение адреса вызывающего" (пп.15.3.1 и 15.3.2.1).
     
     14.2. Расширение адреса вызываемого
     
     Расширение адреса вызываемого - это факультативная определенная МККТТ услуга ООД, которая может быть использована для заданного виртуального соединения. Она предназначена для прозрачной передачи сетевого адреса вызываемой стороны в пакетах ЗАПРОС ВЫЗОВА и ВХОДЯЩИЙ ВЫЗОВ, обеспечиваемого логическим объектом вышерасположенного уровня вызывающего ООД. Она обеспечивает также прозрачную передачу сетевого адреса отвечающей стороны в пакетах ВЫЗОВ ПРИНЯТ и СОЕДИНЕНИЕ УСТАНОВЛЕНО (в случае приема вызова) и в пакетах ЗАПРОС ЗАВЕРШЕНИЯ и ИНДИКАЦИЯ ЗАВЕРШЕНИЯ (в случае отклонения вызова). Сетевой адрес отвечающей стороны передается логическому объекту вышерасположенного уровня вызывающего ООД.
     
     См. также:
     
     кодирование услуги "расширение адреса вызываемого" (пп.15.3.1 и 15.3.2.2).
     
     14.3. Согласование класса минимальной пропускной способности
     

     Согласование класса минимальной пропускной способности - это факультативная определенная МККТТ услуга ООД, которая может использоваться для заданного виртуального соединения. Вызывающее ООД указывает для каждого направления передачи данных минимально приемлемое значение класса пропускной способности посредством услуги "согласование класса минимальной пропускной способности" в пакете ЗАПРОС ВЫЗОВА. Эти два значения передаются вызываемому ООД в прозрачном виде в пакете ВХОДЯЩИЙ ВЫЗОВ. Шлюзы, сети частного пользования и вызываемое ООД могут завершить соединение при отсутствии ресурсов, необходимых для обеспечения классов минимально приемлемой пропускной способности. Шлюзы, сети частного пользования и вызываемое ООД могут использовать услугу "согласование класса пропускной способности" для определения способности сети данных общего пользования обеспечить классы минимально приемлемой пропускной способности и необходимости завершения соединения, если сеть данных общего пользования не может обеспечить эти классы.
     
     Отсутствие этой услуги указывает, что вызывающее ООД не установило нижнюю границу классов приемлемой пропускной способности. Сообщаемые этой услугой значения обеспечиваются логическим объектом вышерасположенного уровня вызывающего ООД и передаются логическому объекту вышерасположенного уровня вызываемого ООД.
     
     См. также:
     
     факультативная услуга пользователя "согласование класса пропускной способности" (п.13.13);
     
     кодирование услуги "согласование класса минимальной пропускной способности" (пп.15.3.1 и 15.3.2.3).
     
     14.4. Согласование межконцевой транзитной задержки
     
     Согласование межконцевой транзитной задержки - это факультативная определенная МККТТ услуга ООД, которая может быть использована для заданного виртуального соединения. Вызывающее ООД указывает совокупную транзитную задержку протоколов пакетного и нижерасположенных уровней ООД с учетом влияния скорости передачи в линии доступа с помощью услуги "согласование межконцевой транзитной задержки" в пакете ЗАПРОС ВЫЗОВА. Значение совокупной транзитной задержки передается сетями данных общего пользования в прозрачном виде и обновляется шлюзами и вызываемым ООД в процессе обработки установления соединения. Шлюзы и вызываемое ООД могут использовать услугу "выбор и индикация транзитной задержки", введенную предыдущей сетью, при вычислении совокупной транзитной задержки.
     
     Помимо совокупной транзитной задержки вызывающее ООД может факультативно указать желаемое (целевое) значение межконцевой транзитной задержки. Если вызывающее ООД указывает желаемое значение, оно может факультативно указать и максимально приемлемое значение межконцевой транзитной задержки. Эти значения (при их наличии) обеспечиваются логическим объектом вышерасположенного уровня вызывающего ООД и передаются в "прозрачном" виде вызываемому ООД в пакете ВХОДЯЩИЙ ВЫЗОВ. Отсутствие этих услуг говорит о том, что вызывающее ООД не обеспечивает желаемого значения и/или верхней границы транзитной задержки.
     

     Шлюзы, сети частного пользования и вызываемое ООД должны завершать вызов, если значение совокупной транзитной задержки превышает ее максимально приемлемое значение (если оно определено). Максимально приемлемое значение транзитной задержки (при его наличии) и значение совокупной транзитной задержки, вычисленное пакетным уровнем вызываемого ООД, передаются логическому объекту вышерасположенного уровня вызываемого ООД.
     
     Значение совокупной транзитной задержки, вычисленное пакетным уровнем вызываемого ООД, указывается в пакете ВЫЗОВ ПРИНЯТ, передается в прозрачном виде вызывающему ООД в пакете СОЕДИНЕНИЕ УСТАНОВЛЕНО и выдается логическому объекту вышерасположенного уровня вызывающего ООД.
     
     См. также:
     
     факультативная услуга пользователя "выбор и индикация транзитной задержки" (п.13.27);
     
     кодирование услуги "согласование межконцевой транзитной задержки" (пп.15.3.1 и 15.3.2.4).
     
     14.5. Приоритет
     
     Приоритет - это факультативная определенная МККТТ услуга ООД, которая может быть использована для определенного виртуального соединения. Вызывающее ООД может указать в пакете ЗАПРОС ВЫЗОВА желаемое значение и наименьшее приемлемое значение для приоритета данных в соединении, приоритета получения соединения и приоритета удержания соединения. Эти значения, если они указываются, обеспечиваются логическим объектом вышерасположенного уровня в вызывающем ООД и передаются в "прозрачном" виде сетями данных общего пользования.
     
     Шлюзы, сети частного пользования и вызываемое ООД могут при необходимости понизить желаемые значения и могут завершить соединение, если они не в состоянии обеспечить наименьшее приемлемое значение. Значения, принятые вызываемым ООД, передаются логическому объекту вышерасположенного уровня, который может выдать в ответ выбранные значения. Эти выбранные значения указываются вызываемым ООД в пакете ВЫЗОВ ПРИНЯТ, передаются в прозрачном виде вызывающему ООД в пакете СОЕДИНЕНИЕ УСТАНОВЛЕНО и выдаются логическому объекту вышерасположенного уровня вызывающего ООД.
     
     См. также:
     
     кодирование услуги "приоритет" (пп.15.3.1 и 15.3.2.5).
     
     14.6. Защита
     
     Защита - это факультативная определенная МККТТ услуга ООД, которая может быть использована для заданного виртуального соединения. Вызывающее ООД может указать в пакете ЗАПРОС ВЫЗОВА желаемое значение и наименьшее приемлемое значение для услуги "защита". Эти значения, если они указываются, обеспечиваются логическим объектом вышерасположенного уровня в вызывающем ООД и передаются в прозрачном виде сетями данных общего пользования.
     
     Шлюзы, сети частного пользования и вызываемое ООД могут при необходимости понизить желаемые значения и могут завершить соединение, если они не в состоянии обеспечить наименьшее приемлемое значение. Значения, принятые вызываемым ООД, передаются логическому объекту вышерасположенного уровня, который может выдать в ответ выбранные значения. Эти выбранные значения указываются вызываемым ООД в пакете ВЫЗОВ ПРИНЯТ, передаются в прозрачном виде вызывающему ООД в пакете СОЕДИНЕНИЕ УСТАНОВЛЕНО и выдаются логическому объекту вышерасположенного уровня вызывающего ООД.
     
     См. также:
     
     кодирование услуги "защита" (пп.15.3.1 и 15.3.2.6).
     
     14.7. Согласование срочных данных
     
     Согласование срочных данных - это факультативная определенная МККТТ услуга ООД, которая может быть использована для заданного виртуального соединения. Вызывающее ООД использует услугу "согласование срочных данных" в пакете ЗАПРОС ВЫЗОВА для информирования о своем желании или нежелании использовать процедуры срочной передачи данных (например процедуры прерывания). Это желание указывается логическим объектом вышерасположенного уровня вызывающего ООД. Данная услуга передается в прозрачном виде сетями данных общего пользования, но она может быть установлена шлюзами и сетями частного пользования, которые не обеспечивают этих процедур, в значение "неиспользование процедур передачи срочных данных".
     
     Если логический объект вышерасположенного уровня вызываемого ООД желает использовать процедуры срочных данных и услуга, принятая в пакете ВХОДЯЩИЙ ВЫЗОВ, указывает на использование этих процедур, то их использование указывается в пакете ВЫЗОВ ПРИНЯТ и передается в прозрачном виде в пакете СОЕДИНЕНИЕ УСТАНОВЛЕНО. В противном случае в этих пакетах указывается "неиспользование процедур передачи срочных данных".
     
     Указанный в пакете СОЕДИНЕНИЕ УСТАНОВЛЕНО результат согласования использования процедур передачи срочных данных должен быть передан логическому объекту вышерасположенного уровня вызывающего ООД.
     
     См. также:
     
     процедуры прерывания (п.6.8);
     
     кодирование услуги "согласование срочных данных" (пп.15.3.1 и 15.3.2.7).
     
     

15. ФОРМАТЫ ПОЛЕЙ "УСЛУГА" В ПАКЕТАХ
УСТАНОВЛЕНИЯ/ЗАВЕРШЕНИЯ СОЕДИНЕНИЯ

     
     Описываемые в настоящем разделе форматы применимы только к факультативным услугам пользователя и к определенным МККТТ услугам ООД, которые могут присутствовать в пакетах установления соединения и завершения соединения в службе виртуальных соединений.
     
     В п.15.1 описана общая структура кодирования поля "услуги". В п.15.2 приведено кодирование поля "услуги" для факультативных услуг пользователя, а в п.15.3 - кодирование поля "услуги" для услуг ООД, определенных МККТТ.
     
     15.1. Общие сведения
     
     Поле "услуга" присутствует только тогда, когда ООД и/или ХХД используют факультативную услугу пользователя или специфицированную МККТТ услугу ООД, требующую некоторого указания в пакете ЗАПРОС ВЫЗОВА, ВХОДЯЩИЙ ВЫЗОВ, ВЫЗОВ ПРИНЯТ, СОЕДИНЕНИЕ УСТАНОВЛЕНО, ЗАПРОС ЗАВЕРШЕНИЯ, ИНДИКАЦИЯ ЗАВЕРШЕНИЯ или ПОДТВЕРЖДЕНИЕ ЗАВЕРШЕНИЯ.
     
     Поле "услуга" содержит по одному элементу услуги для каждой запрошенной услуги или группы услуг. Первый октет каждого элемента услуги является полем "код услуги", которое содержит код запрошенной услуги или услуг. Остальные октеты элемента услуги содержат длину поля "параметр услуги" (если оно имеется) и затем поле "параметр услуги".
     
     Примечания:
     
     1. Если код услуги представлен не один раз, то ООД должно использовать последний код. ООД не должно повторять код услуги.
     
     2. ООД может либо игнорировать, либо рассматривать как ошибку те коды услуг, которые не обеспечиваются или которые неприменимы в конфигурации ООД/ООД. Если ООД решило трактовать эти ситуации как ошибочные, то оно передает через интерфейс ООД/ХХД пакет ЗАПРОС ЗАВЕРШЕНИЯ с указанием причины "по инициативе ООД" и диагностики "услуга не разрешена".
     
     
     Для того чтобы определить параметры услуги, состоящие из одного, двух, трех или переменного числа октетов, коды услуг подразделяются на четыре класса путем использования битов 8 и 7 поля "код услуги". Обобщенное по классам кодирование поля "код услуги" приведено в табл.16. Общие форматы для четырех классов элементов услуги приведены на черт.29.
     
     

Таблица 16

     
Обобщенное по классам кодирование полей "код услуги"

     
Обобщенные форматы элементов услуги

Черт.29

     
     
     Поле "код услуги" представляется в двоичном коде и при отсутствии расширения обеспечивает максимум 64 кода услуги для каждого из классов А, Б и В и 63 кода услуги для класса Г, обеспечивая в сумме 255 кодов услуги.
     
     Код услуги 11111111 зарезервирован для расширения кодов услуг. Октет, следующий за этим октетом, указывает на расширенный код услуги, имеющий один из определенных выше форматов А, Б, В или Г. Разрешается повторение кода услуги 11111111, что обеспечивает дополнительное расширение.
     
     Код услуги может назначаться с целью идентификации ряда специальных услуг, каждая из которых имеет в поле "параметр/услуги" бит "услуга запрошена/услуга не запрошена". В этой ситуации поле "параметр услуги" представляется в двоичном коде, где каждая битовая позиция относится к конкретной услуге. Значение 0 указывает, что услуга, представленная данным битом, не запрошена, а значение I - что услуга, представленная данным битом, запрошена. Те битовые позиции параметра, которым не присвоена конкретная услуга, устанавливаются в значение 0. Если ни одна из услуг, представленных кодом услуги, не запрошена для виртуального соединения, тогда нет необходимости в коде услуги и в соответствующем поле "параметр услуги".
     
     Для кодов услуг в классе Г октет, следующий за полем "код услуги", указывает длину поля "параметр услуги" в октетах. Длина поля "параметр услуги" представлена в двоичном коде, где бит I - младший бит этого указателя.
     
     Кодирование поля "параметр услуги" зависит от запрашиваемой услуги.
     
     Существуют четыре категории услуг:
     
     а) услуги Х.25, определенные в разд.13;
     
     б) услуги, обеспечиваемые локальной сетью и отсутствующие в Х.25;
     
     в) услуги, обеспечиваемые удаленной сетью (только в случае межсетевых виртуальных соединений) и отсутствующие в Х.25;
     
     г) определенные МККТТ услуги ООД, описанные в разд.14.
     
     Для отделения запросов услуг Х.25 от запросов трех других, описанных выше категорий услуг, используются маркеры услуги, состоящие из двух октетов. Если одновременно представлено несколько категорий услуг, то для разделения этих категорий услуг друг от друга используются маркеры услуги. В этом случае, однако, запросы услуг Х.25 должны предшествовать другим запросам, а запросы на определенные МККТТ услуги ООД должны следовать за другими запросами.
     
     Первым октетом маркера услуги является поле "код услуги", установленное в ноль. Кодирование второго октета - поля "параметры услуги", зависит от категории услуг в соответствии с нижеизложенным:
     

     
     
     15.2. Кодирование поля "услуги" для факультативных услуг пользователя
     
     Кодирование поля "код услуги" и формат поля "параметр услуги" одинаковы в различных пакетах установления и завершения соединения которых они могут присутствовать.*
_______________
     * Текст соответствует оригиналу. - Примечание .
     
     15.2.1. Кодирование поля "код услуги"
     
     В табл.17 приведены коды поля "код услуги" для каждой факультативной услуги пользователя и указаны типы пакетов, в которых они могут присутствовать.
     
     

Таблица 17

     
Кодирование поля "код услуги"