ГОСТ Р ИСО/МЭК 8073-96

Группа П85

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

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

     
ПЕРЕДАЧА ДАННЫХ И ОБМЕН ИНФОРМАЦИЕЙ МЕЖДУ СИСТЕМАМИ.
ВЗАИМОСВЯЗЬ ОТКРЫТЫХ СИСТЕМ.
ПРОТОКОЛ ДЛЯ ОБЕСПЕЧЕНИЯ УСЛУГ ТРАНСПОРТНОГО УРОВНЯ
В РЕЖИМЕ С УСТАНОВЛЕНИЕМ СОЕДИНЕНИЯ

     
Information technology. Telecommunications and information exchange
between systems. Open Systems Interconnection.
Protocol for providing the connection-mode transport service

     
     
ОКС 35.100.40
ОКСТУ 4002

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

Предисловие

     
     1 РАЗРАБОТАН Комитетом при Президенте Российской Федерации по политике информатизации и ВНЕСЕН НА УТВЕРЖДЕНИЕ техническим комитетом по стандартизации ТК 22 "Информационная технология"
     
     2 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 7 августа 1996 г. N 504
     
     Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 8073-92 "Информационная технология. Передача данных и обмен информацией между системами. Взаимосвязь открытых систем. Протокол для обеспечения услуг транспортного уровня в режиме с установлением соединения".
     
     3 ВВЕДЕН ВПЕРВЫЕ
     

Введение

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

Рисунок 1 - Взаимоотношения между протоколом транспортного уровня и услугами смежных уровней

     
     
     Настоящий стандарт определяет общие правила кодирования данных и несколько классов протокольных процедур транспортного уровня, подлежащих использованию при различном качестве услуг сетевого уровня (УСУ).
     
     Задача состоит в том, чтобы создать простой, но достаточно универсальный протокол транспортного уровня, который охватил бы весь возможный диапазон качества услуг, не налагая ограничений на будущие расширения.
     
     Структура протокола учитывает введение различных его классов, которые предназначены для уменьшения возможных взаимных несовместимостей и затрат на реализацию.
     
     Классы протокола выбирают относительно услуг транспортного и сетевого уровней с обеспечением качества услуг, необходимого для взаимодействия двух логических объектов сеансового уровня (с целью расширения качественных характеристик услуг каждый класс обеспечивает различный набор функций).
     
     Настоящий стандарт определяет механизмы, которые могут быть использованы для оптимизации сетевых тарифов и улучшения следующих качественных характеристик услуг:
     
     a) различные пропускные способности;
     
     b) различные частоты появления ошибок;
     
     c) требования к целостности данных;
     
     d) требования к надежности.
     
     Стандарт не требует, чтобы какая-либо его реализация использовала все эти механизмы, и не определяет методов измерения достигнутых значений качества услуг или критериев оценки той степени ухудшения качества услуг, при которой должно следовать разъединение соединения транспортного уровня (СТУ).
     
     Основная цель настоящего стандарта состоит в том, чтобы определить набор правил обмена данными между равноуровневыми логическими объектами в виде конкретных процедур, реализуемых ими в процессе обмена данными. Эти правила должны обеспечить хорошую основу для дальнейшего развития протокола и служить различным целям, в частности:
     
     a) в качестве руководства для проектировщиков и разработчиков;
     
     b) для использования при тестировании и приобретении оборудования;
     
     c) в качестве составной части соглашения о включении систем в область применения открытых систем;
     
     d) в качестве пособия для лучшего понимания ВОС.
     
     Предполагается, что первыми пользователями настоящего стандарта будут разработчики и проектировщики оборудования. В примечаниях и приложениях к стандарту приведены руководства по применению определяемых в нем процедур.
     
     Следует заметить, что ввиду большого количества разрешенных протокольных процедур невозможно при существующей технологии удостовериться, что каждая реализация будет во всех случаях правильно работать по протоколу, определенному в настоящем стандарте. Методом тестирования можно убедиться в том, что в некоторых типовых применениях конкретная реализация работает в полном соответствии с протоколом. Ставится, однако, задача, чтобы в случае нарушения взаимодействия двух реализаций настоящий стандарт помог определить, какая из них (или обе одновременно) неправильно реализует (ют) протокол.
     
     Отдельный раздел настоящего стандарта посвящен вопросам соответствия оборудования, претендующего на реализацию стандартизуемых здесь процедур. Для оценки соответствия конкретной реализации необходимо иметь констатацию всех реализованных функциональных и факультативных возможностей заданного протокола ВОС. Такая констатация называется "заявкой о соответствии реализации протоколу" (ЗСРП). Форма ЗСРП приведена в приложении С. При этом следует иметь ввиду, что настоящий стандарт не определяет методов проверок, подтверждающих такое соответствие.
     
     Предусмотренные настоящим стандартом различные варианты и факультативные возможности имеют важное значение, поскольку они позволяют обеспечивать услуги транспортного уровня (УТУ) для самых различных применений при большом разнообразии качественных показателей сети. Оборудование, обладающее минимальным соответствием, не может быть использовано во всех возможных случаях. Поэтому важно, чтобы все ссылки на настоящий стандарт сопровождались сведениями об обеспечиваемых или требуемых факультативных возможностях либо сведениями о поставленных целях или необходимых потребностях.
     

     1 НАЗНАЧЕНИЕ

     
     Настоящий стандарт устанавливает:
     
     a) пять классов процедур передачи данных и управляющей информации между логическими объектами транспортного уровня в режиме с установлением соединения при использовании услуг сетевого уровня (УСУ) в режиме с установлением соединения:
     
     0 - простой класс;
     
     1 - основной класс с восстановлением при ошибках;
     
     2 - класс с мультиплексированием;
     
     3 - класс с восстановлением при ошибках и с мультиплексированием;
     
     4 - класс с обнаружением ошибок и с восстановлением;
     
     b) один класс процедур (класс 4) для работы с УСУ в режиме с установлением соединения;
     
     c) средства согласования класса процедур, подлежащего использованию логическими объектами транспортного уровня;
     
     d) структуру и кодирование протокольных блоков данных транспортного уровня (ПБДТ), используемых для передачи данных и управляющей информации.
     
     Процедуры определяются в понятиях:
     
     - взаимодействий между равноуровневыми логическими объектами транспортного уровня путем обмена протокольными блоками данных транспортного уровня;
     
     - взаимодействий между логическими объектами транспортного уровня и пользователем УТУ той же системы путем обмена примитивами УТУ;
     
     - взаимодействий между логическими объектами транспортного уровня и поставщиком УСУ путем обмена примитивами УСУ.
     
     Эти процедуры определены в основной части настоящего стандарта и дополнены таблицами состояний в приложении А.
     
     Указанные процедуры применимы при обмене данными между системами, реализующими транспортный уровень эталонной модели ВОС и предназначенными для взаимодействия в среде открытых систем.
     
     Настоящий стандарт устанавливает в разделе 14 аттестационные требования к системам, реализующим эти процедуры, и содержит форму ЗСРП, отвечающую установленным требованиям и руководящим материалам, приведенным в ГОСТ Р ИСО/МЭК 9646-2. Однако он не определяет проверочных тестов, которые можно было бы использовать для подтверждения соответствия.
     

     2 НОРМАТИВНЫЕ ССЫЛКИ

     
     В настоящем стандарте использованы ссылки на следующие стандарты:
     
     ГОСТ 34.960-91 (ИСО 8072-86, Доп.1-86) Системы обработки информации. Взаимосвязь открытых систем. Определение услуг транспортного уровня
     
     ГОСТ 28906-91 (ИСО 7498-84, ИСО 7498-84, Доп.1-84) Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель
     
     ГОСТ Р 34.915-92 (ИСО 8348-87, Доп.1-87) Системы обработки информации. Передача данных. Определение услуг сетевого уровня
     
     ГОСТ Р ИСО/МЭК 9646-1-93 Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования ВОС. Часть 1. Общие принципы
     
     ГОСТ Р ИСО/МЭК 9646-2-93 Информационная технология. Взаимосвязь открытых систем. Методология и основы аттестационного тестирования ВОС. Часть 2. Спецификация комплекта абстрактных тестов
     
     ИСО 7498-3-89* Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель. Часть 3. Присвоение имен и адресация
_________________
     * До прямого применения данного документа в качестве государственного стандарта распространение его осуществляет секретариат ТК 22 "Информационная технология"
     
     ИСО/МЭК 11570-92* Информационная технология. Передача данных и обмен информацией между системами. Взаимосвязь открытых систем. Механизм идентификации протоколов транспортного уровня
_________________
     * До прямого применения данного документа в качестве государственного стандарта распространение его осуществляет секретариат ТК.22 "Информационная технология"
     
     Рекомендация Х.224 МККТТ спецификация протоколов транспортного уровня взаимосвязи открытых систем для применения МККТТ.
     

     ЧАСТЬ ПЕРВАЯ. ОБЩИЕ ПОЛОЖЕНИЯ

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

     
     Примечание - В определениях, содержащихся в настоящем разделе, использованы сокращения, приведенные в разделе 4.
     
     
     3.1 Настоящий стандарт основан на концепциях, изложенных в ГОСТ 28906 и ИСО/МЭК 7498-3, и использует следующие определенные в нем термины:
     
     a) сцепление и расцепление;
     
     b) сегментирование и сборка;
     
     c) мультиплексирование и демультиплексирование;
     
     d) расщепление и рекомбинация;
     
     e) управление потоком;
     
     f) передача в режиме без установления соединения;
     
     g) нулевое значение селектора.
     
     3.2 В настоящем стандарте используются следующие термины и их определения.
     
     3.2.1 Оборудование - аппаратные или программные средства, либо их сочетание; они не должны быть физически обособлены от вычислительной системы.
     
     3.2.2 Пользователь услуг транспортного уровня - абстрактное представление совокупности тех логических объектов одной системы, которые пользуются услугами транспортного уровня.
     
     3.2.3 Поставщик услуг сетевого уровня - с точки зрения транспортного уровня абстрактный автомат, который моделирует совокупность логических объектов, предоставляющих услуги сетевого уровня.
     
     3.2.4 Частный вопрос - решение, принимаемое системой относительно ее поведения на транспортном уровне и не являющееся объектом требований настоящего протокола.
     
     3.2.5 Инициатор - логический объект транспортного уровня, инициирующий ПБДТ "запрос соединения" (ЗС).
     
     3.2.6 Ответчик - логический объект транспортного уровня, с которым инициатор желает установить СТУ.
     
     Примечание - Определения инициатора и ответчика даны относительно одного СТУ. Логический объект транспортного уровня может быть одновременно и инициатором и ответчиком.
     
     
     3.2.7 Передающий логический объект транспортного уровня - логический объект транспортного уровня, который передает данный ПБДТ.
     
     3.2.8 Принимающий логический объект транспортного уровня - логический объект транспортного уровня, который принимает данный ПБДТ.
     
     3.2.9 Предпочтительный класс - класс протокола, который инициатор помечает в ПБДТ ЗС как первый выбранный вариант для использования в данном СТУ.
     

     3.2.10 Альтернативный класс - класс протокола, который инициатор помечает в ПБДТ ЗС как альтернативный выбранный вариант для использования в данном СТУ.
     
     3.2.11 Предложенный класс - предпочтительный класс или альтернативный класс.
     
     3.2.12 Выбранный класс - протокольный класс, который ответчик помечает в ПБДТ "подтверждение соединения" (ПС) как предложенный им класс для использования в данном СТУ.
     
     3.2.13 Предложенный параметр - значение параметра, указанноe инициатором в ПБДТ ЗС как желаемое для использования в данном СТУ.
     
     3.2.14 Выбранный параметр - значение параметра, указанное ответчиком в ПБДТ ЗС как выбранное им для использования в данном СТУ.
     
     3.2.15 Индикация ошибки - примитив С-СБРОС индикация или С-РАЗЪЕДИНЕНИЕ индикация с кодом причины ошибки, поступающий к логическому объекту транспортного уровня от поставщика УТУ.
     
     3.2.16 Недействительный ПБДТ - ПБДТ, не отвечающий требованиям настоящего стандарта в части его структуры и кодирования.
     
     3.2.17 Протокольная ошибка - такой ПБДТ, использование которого не соответствует процедурам данного класса.
     
     3.2.18 Порядковый номер -
     
     a) номер в поле НР-ПБДТ блока ПБДТ "данные" (ДН), указывающий очередность, в которой ПБДТ ДН был передан логическим объектом транспортного уровня;
     
     b) номера в поле НР-ОТВ блока ПБДТ ПД или ПБДТ "отклонение" (ОТК), указывающий порядковый номер следующего ПБДТ ДН, ожидаемого логическим объектом транспортного уровня.
     
     3.2.19 Окно передачи - набор следующих подряд порядковых номеров, которые данный логический объект транспортного уровня может передать с разрешения равноуровневого логического объекта в определенный период времени по данному СТУ.
     
     3.2.20 Нижняя граница окна - наименьший порядковый номер окна передачи.
     
     3.2.21 Верхняя граница окна - порядковый номер, на единицу превышающий наибольший порядковый номер окна передачи.
     
     3.2.22 Верхняя граница окна, представленная равноуровневому логическому объекту - значение, сообщаемое логическим объектом транспортного уровня равноуровневому логическому объекту в качестве новой верхней границы окна.
     
     3.2.23 Закрытое окно - окно передачи, не содержащее порядковых номеров.
     

     3.2.24 Информация об окне - информация, содержащаяся в ПБДТ относительно верхней и нижней границ окна.
     
     3.2.25 Заблокированный указатель - указатель, не доступный для присвоения соединению по причине, указанной в 6.18.
     
     3.2.26 Неприсвоенный указатель - указатель, который не находится в текущем использовании для идентификации СТУ или в заблокированном состоянии.
     
     3.2.27 Прозрачные данные - данные пользователя - УТУ, передаваемые в целостном виде между логическими объектами транспортного уровня и не доступные для использования этими объектами.
     
     3.2.28 Владелец (соединения сетевого уровня) - логический объект транспортного уровня, выдавший примитив С-СОЕДИНЕНИЕ запрос, который обусловил образование ССУ.
     
     3.2.29 Хранимый ПБДТ - ПБДТ, являющийся объектом процедуры повторной передачи либо задержанный до выполнения процедуры подтверждения и доступный для возможной повторной передачи.
     
     3.3 Настоящий стандарт использует следующие термины, определенные в ГОСТ Р 34.915:
     
     a) услуга сетевого уровня в режиме с установлением соединения;
     
     b) услуга сетевого уровня в режиме без установления соединения.
     
     3.4 Настоящий стандарт использует следующие термины, определенные в ГОСТ Р ИСО/МЭК 9646-1:
     
     a) форма ЗСРП;
     
     b) заявка о соответствии реализации протоколу (ЗСРП).
     

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

     
     4.1 Блоки данных
     
     ПБДТ - протокольный блок данных транспортного уровня
     
     СБДС - сервисный блок данных сетевого уровня
     
     СБДТ - сервисный блок данных транспортного уровня
     
     4.2 Типы протокольных блоков данных транспортного уровня
     

     
     4.3 Поля ПБДТ
     

     
     4.4 Времена и соответствующие переменные
     

     
     4.5 Разное
     

     5 Общее описание протокола транспортного уровня

     
     Примечание - Приводимое описание не является исчерпывающим и приводится в качестве руководящего пособия.
     
     
     5.1. Услуги, предоставляемые транспортным уровнем
     
     Протокол, устанавливаемый настоящим стандартом, обеспечивает услуги транспортного уровня, установленные ГОСТ 34.960.
     
     Информация в направлении к пользователю - УТУ и от него передается в виде примитивов УТУ, перечисленных в таблице 1.
     
     
Таблица 1 - Примитивы услуг транспортного уровня
     

     
     
     5.2 Услуги, ожидаемые от сетевого уровня
     
     Протокол, устанавливаемый настоящим стандартом, предполагает использование услуг сетевого уровня, установленных ГОСТ Р 34.915.
     
     При работе с УСУ-УС информация в направлении к поставщику УСУ и от него передается в виде примитивов УСУ, перечисленных в таблице 2а. При работе с УСУ-БУС информация в направлении к поставщику УСУ и от него передается в виде примитивов УСУ, перечисленных в таблице 2b.
     
     Примечания
     
     1 В таблице 2а перечислены параметры, используемые в УСУ-УС, определенных к настоящему времени в ГОСТ 34.915.
     
     2 В таблице 2b перечислены параметры, используемые в УСУ-БУС, определенных к настоящему времени в ГОСТ 34.915.
     
     3 Способ обмена параметрами между логическими объектами транспортного уровня и поставщиком УСУ является частным вопросом.
     
     
Таблица 2а - Примитивы услуг сетевого уровня в режиме с установлением соединения

     
     
Таблица 2b - Примитивы услуг сетевого уровня в режиме без установления соединения

     
     5.3 Функции транспортного уровня
     
     5.3.1 Общее описание функций
     
     К функциям транспортного уровня относятся те, которые необходимы для устранения различий между услугами, доступными от сетевого уровня, и услугами, которые должны быть предоставлены пользователю УТУ.
     
     Функции транспортного уровня касаются расширения качества услуг с учетом аспектов оптимизации стоимости.
     
     Эти функции подразделяют на две группы: функции, используемые в течение всего времени существования СТУ, и функции, относящиеся к фазе установления соединения, передачи данных или разъединения соединения.
     
     Примечание - Настоящий стандарт не распространяется на нижеперечисленные функции, вопрос о включении которых в одно из последующих изданий настоящего стандарта изучается:
     
     
     a) шифрование данных;
     
     b) механизмы учетных операций;
     
     c) обмен информацией о состояниях и контроль КУ;
     
     d) блокирование данных;
     
     e) временное разъединение соединений сетевого уровня;
     
     f) альтернативный алгоритм вычисления контрольной суммы.
     
     5.3.1.1 Функции, используемые постоянно
     
     В зависимости от выбранного класса протокола и выбранных факультативных возможностей те или иные из нижеперечисленных функций используются постоянно во время существования СТУ:
     
     a) передача ПБДТ (см. 6.2 и 6.9);
     
     b) мультиплексирование и демультиплексирование (см. 6.15) - функция, используемая только при работе с УСУ-УС для коллективного использования одного ССУ двумя или более СТУ;
     
     c) обнаружение ошибок (см. 6.10, 6.13 и 6.17) - функция, используемая для обнаружения потерь, искажений, дублирований, нарушения порядка следования или доставки ПБДТ не по адресу;
     
     d) восстановление при ошибках (см. 6.12, 6.14, 6.18-6.22) - функция, используемая для восстановления работоспособности после обнаружения ошибок и информирования о них.
     
     5.3.1.2 Установление соединения
     
     Назначение фазы установления соединения состоит в обеспечении СТУ между двумя пользователями УТУ. В этой фазе нижеперечисленные функции транспортного уровня согласовывают запрашиваемое пользователями УТУ качество услуг с качеством услуг, предлагаемых сетевым уровнем:
     
     а) выбор УСУ, наилучшим образом соответствующих требованиям пользователя УТУ с учетом стоимости различных услуг только при работе С УСУ-УС (см. 6.5);
     
     b) решение о необходимости мультиплексирования нескольких СТУ в одно ССУ (см. 6.5);
     
     с) установление оптимального размера ПБДТ (см. 6.5);
     
     d) выбор функций, необходимых для выполнения операций при входе в фазу передачи данных (см. 6.5);
     
     e) преобразование адресов транспортного уровня в адреса сетевого уровня;
     
     f) обеспечение средств определения различий между двумя СТУ (см. 6.5);
     
     g) доставка данных пользователя УТУ (см. 6.5);
     
     h) обмен значениями тайм-аутов неактивности (см. 6.5).
     
     5.3.1.3 Передача данных
     
     Назначение фазы передачи данных состоит в том, чтобы обеспечить дуплексный обмен блоками ПБДТ между двумя пользователями УТУ, взаимосвязанными через СТУ. Эта цель достигается путем двустороннего одновременного обмена данными и с помощью следующих функций, использование которых определяется при установлении соединения:
     
     a) сцепление и расцепление (см. 6.4) - функция, используемая для объединения нескольких ПБДТ в один СБДС в передающем логическом объекте транспортного уровня и для выделения ПБДТ в принимающем логическом объекте транспортного уровня;
     
     b) сегментирование и сборка (см. 6.3) - функция, используемая для разделения одного СБДТ на несколько ПБДТ в передающем логическом объекте транспортного уровня и для их сборки в первоначальный формат в принимающем логическом объекте транспортного уровня;
     
     c) расщепление и рекомбинация (см. 6.23) - функция, обеспечивающая одновременное использование двух или более ССУ для поддержания одного и того же СТУ;
     
     d) управление потоком (см. 6.16) - функция, используемая для регулирования потока ПБДТ между двумя логическими объектами транспортного уровня в одном СТУ;
     
     e) идентификация транспортного соединения - средство однозначной идентификации СТУ между парой логических объектов транспортного уровня, поддерживающих между собой соединение в течение всего времени существования СТУ;
     
     f) срочные данные (см. 6.11) - функция, используемая для обхода нормального потока ПБДТ. Поток срочных ПБДТ регулируется отдельной функцией управления потоком;
     
     g) разграничение СБДТ (см. 6.3) - функция, используемая для определения начала и конца СБДТ.
     
     5.3.1.4 Paзъединение
     
     Задача фазы разъединения (см. 6.7 и 6.8) состоит в том, чтобы разъединить СТУ независимо от текущих операций.
     
     5.4 Классы и факультативные функции при работе с УСУ-УС
     
     5.4.1 Общие положения
     
     Все функции транспортного уровня подразделяют на классы и факультативные функциональные возможности.
     
     Класс определяет набор функций. К факультативным возможностям относятся такие функции в пределах класса, которые могут либо использоваться, либо не использоваться.
     
     Настоящий стандарт определяет пять классов протокола:
     
     0 - простой класс;
     
     1 - основной класс с восстановлением при ошибках;
     
     2 - класс с мультиплексированием;
     
     3 - класс с восстановлением при ошибках и с мультиплексированием;
     
     4 - класс с обнаружением ошибок и с восстановлением.
     
     Примечания
     
     1 СТУ классов 2-4 могут мультиплексироваться в одно и то же ССУ.
     
     2 В классах 0-3 не определены механизмы обнаружения тех безуспешных передач по сети, о которых не было сообщено.
     
     
     5.4.2 Согласование
     
     Использование протокольных классов и факультативных функций согласовывается во время установления соединения. Выбор, производимый логическими объектами транспортного уровня, должен основываться на следующем:
     
     a) требованиях пользователей-УТУ, выражаемых посредством сервисных примитивов Т-СОЕДИНЕНИЕ;
     
     b) качестве доступных УСУ;
     
     c) запрашиваемой пользователем услуге в сопоставлении с приемлемыми для пользователя УТУ затратами на нее.
     
     5.4.3 Выбор соединения сетевого уровня
     
     Ниже приведена классификация УСУ с точки зрения отношения требований пользователя к различным видам ошибок. Основная цель данной классификации состоит в том, чтобы обеспечить основу для принятия решения: какой из классов протокола транспортного уровня следует использовать для данного ССУ:
     
     a) тип А - ССУ с приемлемым коэффициентом необнаруженных ошибок (например, не сообщаемых примитивами разъединения или сброса) и с приемлемой частотой сообщаемых ошибок;
     
     b) тип В - ССУ с приемлемым коэффициентом необнаруженных ошибок (например, не сообщаемых примитивами разъединения или сброса), но с неприемлемой частотой сообщаемых ошибок;
     
     c) тип С - ССУ с неприемлемым коэффициентом необнаруженных ошибок.
     
     Предполагается, что каждый логический объект транспортного уровня осведомлен о качестве услуг, обеспечиваемом конкретными ССУ.

     
     5.4.4 Характеристики класса 0
     
     Класс 0 обеспечивает простейший тип СТУ и полностью совместим с рекомендацией Т.70 МККТТ для телетекстных терминалов.
     
     Класс 0 предназначен для использования в ССУ типа А.
     
     5.4.5 Характеристики класса 1
     
     Класс 1 обеспечивает основное СТУ с минимальными вспомогательными операциями.
     
     Основное назначение этого класса - восстановление работоспособности после разъединения или сброса СТУ.
     
     Выбор этого класса обычно основывается на критерии надежности. Класс 1 предназначен для использования с ССУ типа В.
     
     5.4.6 Характеристики класса 2
     
     5.4.6.1 Общие положения
     
     Класс 2 предусматривает способ мультиплексирования нескольких СТУ в одно ССУ. Данный класс предназначен для использования с ССУ типа А.
     
     5.4.6.2 Использование явного управления потоком
     
     Задача явного управления потоком состоит в том, чтобы помочь устранить перегрузки в оконечных точках СТУ и в ССУ. Обычно оно применяется при интенсивной и непрерывной нагрузке либо при интенсивном мультиплексировании. Применение управления потоком может оптимизировать времена ответа и использование ресурсов.
     
     5.4.6.3 Неиспользование явного управления потоком
     
     Задача состоит в том, чтобы обеспечить основное СТУ минимумом вспомогательных операций, используемых при необходимости явного разъединения СТУ. Эта факультативная возможность может использоваться для простых терминалов и при отсутствии необходимости мультиплексирования СТУ в ССУ. Срочные данные здесь никогда не передаются.
     
     5.4.7 Характеристики класса 3
     
     Класс 3 обеспечивает те же характеристики, что и класс 2, плюс возможность восстановления работы после разъединения или сброса СТУ. Выбор этого класса обычно основывается на критерии надежности. Класс 3 предназначен для использования с ССУ типа В.
     
     5.4.8 Характеристики класса 4
     
     Класс 4 обеспечивает те же характеристики, что и класс 3, плюс обнаружение ошибок, возникающих в результате низкого уровня обслуживания со стороны поставщика УСУ, и их устранение. Виды обнаруживаемых ошибок следующие: потеря ПБДТ, доставка ПБДТ с нарушением последовательности, дублирование ПБДТ и искажение ПБДТ. Эти ошибки могут влиять как на управляющие ПБДТ, так и на ПБДТ "данные".
     
     Этот класс обеспечивает также повышение пропускной способности и дополнительную устойчивость при неисправностях сети.
     

     Он предназначен для использования с ССУ типа С.
     
     5.5 Характеристики класса 4 протокола транспортного уровня при работе с УСУ-БУС
     
     При работе с УСУ-УС класс 4 протокола транспортного уровня обеспечивает возможность управления потоком между взаимодействующими равноправными логическими объектами транспортного уровня с целью обнаружения и восстановления ошибок, возникающих в результате низкого качества услуг сетевого уровня, и повышения устойчивости к неисправностям равноправных логических объектов. К обнаруживаемым видам ошибок относятся: потери ПБДТ, доставка ПБДТ вне последовательности, дублирование ПБДТ и искажение ПБДТ. Эти ошибки могут появляться в управляющих и информационных ПБДТ.
     
     Примечание - Логический объект транспортного уровня не способен различать ошибки УСУ и неисправности равноправных логических объектов, кроме случаев использования некоторых факультативных локальных средств в случае неисправности в локальном интерфейсе с УСУ (например, при неисправности локального приемопередатчика в локальных вычислительных сетях).
     
     
     Относительно возможностей логического объекта сетевого уровня соблюдать требования к услугам, задаваемые в примитиве С-БЛОК-ДАННЫХ, никаких указаний со стороны логического объекта транспортного уровня нет. Однако, как частное решение, можно возложить на логические объекты транспортного уровня ответственность за доступность и характеристики (КУ) УСУ-БУС, поскольку благодаря особенностям УСУ-БУС соответствующие логические ассоциации ПДУСУ существуют и могут быть распознаны логическими объектами сетевого уровня.
     
     5.6 Модель транспортного уровня
     
     Логический объект транспортного уровня взаимодействует со своими пользователями УТУ через один или несколько ПДУТУ посредством сервисных примитивов в соответствии с определением УТУ (см. ГОСТ 34.960). Сервисные примитивы могут быть причиной или результатом обменов ПБДТ между равноуровневыми логическими объектами транспортного уровня, поддерживающими СТУ. Такие протокольные обмены осуществляются с использованием УСУ, определенных в ГОСТ Р 34.915, через один или несколько ПДУСУ.
     
     Оконечные пункты СТУ идентифицируются в оконечных системах внутренним зависящим от реализации механизмом таким образом, что пользователь УТУ и логический объект транспортного уровня могут обращаться к любому СТУ.
     

Рисунок 2 - Модель транспортного уровня

     
     
     Примечание - Для наглядности на рисунке 2 показано только по одному ПДУТУ и ПДУСУ для каждого логического объекта транспортного уровня. В некоторых случаях с конкретным логическим объектом транспортного уровня могут быть связаны несколько ПДУТУ и/или несколько ПДУСУ.
     

     ЧАСТЬ ВТОРАЯ. СПЕЦИФИКАЦИЯ ПРОТОКОЛА ТРАНСПОРТНОГО УРОВНЯ

     
     6 Элементы процедуры

     
     В данном разделе определены элементы процедуры, используемые при спецификации классов протокола (разделы 7-12). Сами по себе эти элементы не имеют смысла.
     
     Рассматриваемые процедуры определяют передачу ПБДТ, структура и кодирование которых определены в разделе 13. Логические объекты транспортного уровня должны принимать любые ПБДТ, полученные в действительных СБДС, и выдавать на них ответы, и могут выдавать ПБДТ, которые инициируют конкретные определяемые в данном разделе элементы процедур.
     
     Примечание - В тех случаях, когда сервисные примитивы, ПБДТ, а также используемые параметры не являются существенными для данного элемента процедуры, они не включаются в спецификацию.
     
     
     6.1 Использование услуг сетевого уровня
     
     6.1.1 Прикрепление к ССУ при работе с УСУ-УС
     
     Эти процедуры используются только при работе с УСУ-УС.
     
     6.1.1.1 Назначение
     
     Данная процедура используется во всех классах протокола для прикрепления СТУ к ССУ.
     
     6.1.1.2 Примитивы услуг сетевого уровня
     
     Данная процедура использует следующие примитивы УСУ:
     
     a) С-СОЕДИНЕНИЕ;
     
     b) С-РАЗЪЕДИНЕНИЕ.
     
     6.1.1.3 Процедура
     
     Каждое СТУ должно быть прикреплено к ССУ. Инициатор может прикрепить СТУ к уже существующему ССУ, владельцем которого он является, или к новому ССУ (см. примечание 1), которое он создает для этой цели.
     
     Инициатор не должен прикреплять или повторно прикреплять СТУ к существующему ССУ, если предполагаемый(е) или используемый(е) протокольный(е) класс(ы) для данного СТУ несовместим(ы) с текущим использованием ССУ с точки зрения мультиплексирования (см. примечание 2).
     
     При выполнении процедур повторной синхронизации (см. 6.14) и повторного прикрепления после неисправности (см. 6.12) инициатор может повторно прикрепить СТУ к другому ССУ, соединяющему те же ПДУСУ, при условии, что он является владельцем данного ССУ, и что СТУ прикрепляется в данный момент времени только к одному ССУ.
     
     При выполнении процедуры расщепления (см. 6.23) логический объект транспортного уровня может прикрепить СТУ к любому другому ССУ, соединяющему те же ПДУСУ, при условии, что он является владельцем данного ССУ и что либо данное ССУ не использует другого прикрепленного к нему СТУ, либо в данном ССУ возможно мультиплексирование.
     
     Логический объект транспортного уровня, который не инициирует прикрепление, информируется о прикреплении СТУ при получении:
     

     а) ПБДТ ЗС во время выполнения процедуры установления соединения (см. 6.5) или
     
     b) ПБДТ ОТК либо повторно переданного ПБДТ ЗС или ЗР во время повторной синхронизации (см. 6.14) и повторного прикрепления после неисправности (см. 6.12), или
     
     c) любого ПБДТ при использовании расщепления (см. 6.23).
     
     Примечания
     
     1 При создании нового ССУ запрашиваемое КУ является частным вопросом, хотя оно обычно обусловливается требованиями СТУ, которое(ые) должно(ы) быть прикреплено(ы) к нему.
     
     2 Существующее ССУ также может оказаться непригодным, если, например, запрошенное КУ для СТУ не может быть обеспечено путем использования или расширения возможностей ССУ.
     
     3 ССУ, не имеющее прикрепленного(ых) к нему СТУ, может стать доступным либо после его начального установления, либо при разъединении всех ССУ, ранее прикрепленных к данному СТУ. Рекомендуется, чтобы правом разъединения ССУ обладал только его владелец. Кроме того, рекомендуется не разъединять ССУ сразу после передачи по данному СТУ последнего ПБДТ либо после передачи ПБДТ ЗР в ответ на ПБДТ ЗС или ПБДТ ПР в ответ на ПБДТ ЗР. Создаваемая задержка позволяет соответствующему ПБДТ достигнуть другого логического объекта транспортного уровня, освобождая при этом все ресурсы, связанные с рассматриваемым СТУ.
     
     4 После появления неисправности ССУ все ранее мультиплексированные СТУ могут быть прикреплены к другим ССУ и наоборот.
     
     
     6.1.2 Передача с использованием УСУ-БУС
     
     Данная процедура используется только при работе УСУ-БУС.
     
     6.1.2.1 Назначение
     
     Данная процедура используется для передачи ПБДТ при работе с УСУ-БУС.
     
     6.1.2.2 Примитивы услуг сетевого уровня
     
     Данная процедура использует следующий примитив УСУ:
     
     С-БЛОК-ДАННЫХ.
     
     6.1.2.3 Процедура
     
     Каждый ПБДТ должен передаваться при единичном привлечении УСУ-БУС по предварительно установленной ассоциации между парой ПДУСУ. Эта ассоциация рассматривается логическими объектами транспортного уровня как постоянно установленная и доступная.
     
     6.2 Передача ПБДТ
     

     6.2.1 Назначение
     
     Процедура передачи ПБДТ используется во всех классах протокола для передачи ПБДТ в полях данных пользователя примитивов УСУ.
     
     6.2.2 Примитивы УСУ
     
     Данная процедура использует следующие примитивы УСУ при работе с УСУ-УС:
     
     а) С-ДАННЫЕ;
     
     b) С-СРОЧНЫЕ-ДАННЫЕ.
     
     Данная процедура использует следующий примитив УСУ при работе с УСУ-БУС:
     
     С-БЛОК-ДАННЫХ.
     
     6.2.3 Процедура
     
     Определенные для данного протокола ПБДТ перечислены в 4.2.
     
     При работе с УСУ-БУС логические объекты транспортного уровня должны передавать и принимать все ПБДТ в виде параметров "данные пользователя УСУ" примитивов С-БЛОК-ДАННЫХ.
     
     При работе с УСУ-УС и если для класса 1 выбран сетевой срочный вариант, логические объекты транспортного уровня должны передавать и принимать ПБДТ СД и ПБДТ ПСД в виде параметров "данные пользователя-УСУ" примитивов С-СРОЧНЫЕ-ДАННЫЕ.
     
     Во всех других случаях логические объекты транспортного уровня должны передавать и принимать ПБДТ в виде параметров "данные пользователя УСУ" примитивов С-ДАННЫЕ.
     
     Если ПБДТ содержится в параметре "данные пользователя УСУ", то значимость бит октетов и последовательность октетов в ПБДТ должны соответствовать 13.2.
     
     Примечание - ПБДТ могут подвергаться сцеплению (см. 6.4).
     
     
     6.3 Сегментирование и сборка.
     
     6.3.1 Назначение
     
     Процедура сегментирования и сборки используется во всех классах протокола для преобразования СБДТ в ПБДТ.
     
     6.3.2 Используемые ПБДТ и параметр
     
     Данная процедура использует следующий ПБДТ и параметр:
     
     ПБДТ ДН
     
     - конец СБДТ.
     
     6.3.3 Процедура
     
     Логический объект транспортного уровня может преобразовать СБДТ в один или упорядоченную последовательность нескольких ПБДТ ДН. Эта последовательность не должна прерываться другими ПБДТ ДН в том же СТУ.
     
     Во всех ПБДТ ДН, кроме последнего в последовательности из нескольких ПБДТ, длина данных должна быть больше нуля.
     
     Примечания
     

     1 Параметр КС в ПБДТ ДН определяет наличие или отсутствие в данной последовательности последующих ПБДТ ДН.
     
     2 Не требуется, чтобы ПБДТ ДН имели максимальную длину, выбранную во время установления соединения.
     
     
     6.4 Сцепление и разделение
     
     6.4.1 Назначение
     
     Процедура сцепления и разделения используется в классах протокола 1-4 для передачи нескольких ПБДТ в одном СБДС.
     
     6.4.2 Процедура
     
     Логический объект транспортного уровня может сцеплять друг с другом ПБДТ одного и того же или различных СТУ при сохранении порядка следования ПБДТ в данном СТУ, совместимого с протокольными операциями.
     
     Действительный набор сцепленных ПБДТ может содержать:
     
     a) любое число различных ПБДТ из следующего перечня: ПД, ПСД, ОТК, ОШ, ПР при условии, что эти ПБДТ поступают из различных СТУ;
     
     b) не более одного ПБДТ из следующего перечня: ЗС, ЗР, ПС, ДН, СД; при наличии такого ПБДТ он помещается последним в наборе сцепленных ПБДТ.
     
     Логический объект транспортного уровня должен принимать действительный набор сцепленных ПБДТ.
     
     Примечания
     
     1 Блоки ПБДТ в сцепленном наборе могут различаться с помощью параметра "указатель длины".
     
     2 Конец ПБДТ, содержащего данные, указывается окончанием СБДС.
     
     3 При работе с УСУ-УС число сцепленных ПБДТ, указанных в 6.4.2а, ограничивается максимальным числом СТУ, которые мультиплексируются вместе, кроме случая прикрепления или повторного прикрепления.
     
     При работе с УСУ-БУС число сцепленных ПБДТ ограничивается числом СТУ, установленных между двумя ПДУСУ, и/или максимально возможным размером СБДС.
     
     
     6.5 Установление соединения
     
     6.5.1 Назначение
     
     Процедура установления соединения используется во всех классах протокола с целью организации нового СТУ.
     
     6.5.2 Примитивы УСУ
     
     При работе с УСУ-УС данная процедура использует следующий примитив УСУ:
     
     С-ДАННЫЕ.
     
     При работе с УСУ-БУС данная процедура использует следующий примитив УСУ:
     
     С-БЛОК-ДАННЫХ.
     

     6.5.3 Используемые ПБДТ и параметры
     
     Данная процедура использует следующие ПБДТ и параметры:
     
     a) ПБДТ ЗС:
     
     КРД,
     
     УКАЗ-ПОЛ (устанавливается в ноль),
     
     УКАЗ-ОТП,
     
     КЛАСС и ФАКУЛЬТАТИВНЫЕ ФУНКЦИИ (например, предпочтительный класс, использование расширенного формата, неиспользование явного управления потоком в классе 2),
     
     идентификатор вызывающего ПДУТУ,
     
     идентификатор вызываемого ПДУТУ,
     
     длина ПБДТ (предложенная),
     
     предпочтительный максимальный размер ПБДТ (предложенный),
     
     номер версии,
     
     параметр защиты,
     
     контрольная сумма,
     
     выбор дополнительной факультативной функции (например, использование срочного сетевого варианта в классе 1, использование подтверждения приема в классе 1, неиспользование контрольной суммы в классе 4, использование услуги передачи срочных данных транспортного уровня, использование избирательного подтверждения, использование подтверждения запроса),
     
     альтернативный(ые) класс(ы) протокола,
     
     время подтверждения,
     
     время неактивности,
     
     пропускная способность (предложенная),
     
     коэффициент необнаруженных ошибок (предложенный),
     
     приоритет (предложенный),
     
     транзитная задержка (предложенная),
     
     время повторного прикрепления,
     
     данные пользователя;
     
     b) ПБДТ ПС:
     
     КРД,
     
     УКАЗ-ПОЛ,
     
     УКАЗ-ОТП,
     
     КЛАСС и ФАКУЛЬТАТИВНЫЕ ФУНКЦИИ (выбранные),
     
     идентификатор вызывающего ПДУТУ,
     
     идентификатор вызываемого ПДУТУ,
     
     длина ПБДТ (выбранная),
     
     предпочтительный максимальный размер ПБДТ (предложенный),
     
     параметр защиты,
     
     контрольная сумма,
     
     выбор дополнительной факультативной функции (выбранная),
     
     время подтверждения,
     
     время неактивности,
     
     пропускная способность (выбранная),
     
     коэффициент необнаруженных ошибок (выбранный),
     
     приоритет (выбранный),
     
     транзитная задержка (выбранная),
     

     данные пользователя.
     
     6.5.4 Процедура при работе с УСУ-УС
     
     Соединение транспортного уровня устанавливается путем передачи ПБДТ ЗС от одного логического объекта транспортного уровня (инициатора) к другому логическому объекту транспортного уровня (ответчику), который выдает в ответ ПБДТ ПС.
     
     Перед передачей ПБДТ ЗС инициатор прикрепляет установленное СТУ к одному (или нескольким в случае использования процедуры расщепления) ССУ. Именно по этому набору ССУ передаются ПБДТ.
     
     Примечание - Даже если инициатор прикрепляет СТУ более чем к одному ССУ, все ПБДТ ЗС (если они передаются повторно) либо ПБДТ ЗР вместе с УКАЗ-ПОЛ, равным нулю, которые выдаются до получения ПБДТ ПС, должны передаваться по одному и тому же ССУ, если только не получен примитив С-РАЗЪЕДИНЕНИЕ индикация. (Это необходимо потому, что удаленный логический объект может не обеспечивать класс 4 протокола и следовательно, может не распознать расщепления.) Если инициатор организовал другие прикрепления, он должен использовать их только после получения ПБДТ ПС, соответствующего классу 4 (см. также процедуру расщепления 6.23).
     
     
     В процессе такого обмена должна передаваться или согласовываться вся информация и параметры, необходимые для работы логических объектов транспортного уровня.
     
     Примечание - За исключением класса 4, рекомендуется, чтобы одновременно с передачей ПБДТ ЗС инициатор начинал отсчет факультативного тайм-аута ТУ1. Отсчет этого тайм-аута должен быть прекращен, когда соединение будет признано либо принятым, либо отклоненным, либо безуспешным. При истечении тайм-аута инициатор должен сбросить или разъединить ССУ, а в классах 1 и 3 заблокировать указатель (см. 6.18). Для всех других СТУ, мультиплексированных в одно и то же ССУ, должны использоваться процедуры сброса или разъединения в зависимости от обстоятельств.
     
     
     При получении не ожидавшегося дубликата ПБДТ ЗС (с указанием класса 4 в качестве предпочтительного) он должен быть проигнорирован в классах 0-3, а в классе 4 на него должен быть передан ответ ПБДТ ПС.
     
     После приема ПБДТ ПС для класса, который обеспечивает процедуру сохранения блоков ПБДТ до получения подтверждения приема ПБДТ, инициатор должен подтвердить ПБДТ ПС в соответствии с таблицей 5 (см. 6.13).
     

     Если принят (возможно только для класса 1) сетевой срочный вариант срочной передачи данных (см. 6.11), ответчик не должен передавать ПБДТ СД до получения подтверждения ПБДТ ПС.
     
     Осуществляется обмен следующей информацией:
     
     a) Указатели. Каждый логический объект транспортного уровня выбирает указатель, подлежащий использованию равноуровневым логическим объектом, длина которого 16 бит, а содержимое произвольное, за исключением следующих ограничений:
     
     1) он не должен уже находиться в пользовании или в заблокированном состоянии (см. 6.18),
     
     2) он не должен быть нулевым.
     
     Этот механизм является симметричным и обеспечивает идентификацию СТУ независимо от ССУ. Диапазон указателей, используемых для СТУ в данном логическом объекте транспортного уровня, является частным вопросом.
     
     b) Идентификаторы ИД вызывающего и вызываемого ПДУТУ (факультативные). Если любой сетевой адрес однозначно определяет адрес транспортного уровня, то эта информация может не передаваться.
     
     c) Первоначальный кредит. Относится только к тем классам, которые содержат функцию явного управления потоком.
     
     d) Данные пользователя. Отсутствуют, если предпочтительным является класс 0 (см. примечание). В других классах их длина может быть до 32 октетов.
     
     Примечание - Если действительный ответ указывает класс 0 в соответствии с таблицей 3, то включение в ПБДТ ЗС данных пользователя может привести к отказу отвечающего объекта от соединения (например, если он обеспечивает только класс 0).
     
     
     e) Время подтверждения. Только в классе 4.
     
     f) Параметр контрольной суммы. Только в классе 4.
     
     g) Параметр защиты. Этот параметр и его семантика определяются пользователем.
     
     i) Время неактивности. Только в классе 4. Параметр "время неактивности" не должен вводиться в состав ПБДТ ПС, если он отсутствовал в соответствующем ПБДТ ЗС.
     
     Согласованию подлежит следующее.
     
     j) Класс протокола. Инициатор должен предложить предпочтительный класс и может предложить любое число альтернативных классов, допускающих действительный ответ в соответствии с таблицей 3. При передаче ПБДТ ЗС инициатор должен, исходя из того, что его предпочтительный класс будет согласован, начать выполнение процедур этого класса кроме случаев, когда альтернативными являются классы 0 и 1; мультиплексирование не должно начинаться до приема ПБДТ ПС, выбирающего использование класса 2, 3 или 4.
     
     
Таблица 3 - Действительные ответы, соответствующие предпочтительному и любому из альтернативных классов, предложенных в ПБДТ ЗС

          
     Обозначение: Н/Д - недействительный
     
     Примечание - Это означает, например, что если предпочтительный класс предусматривает повторную синхронизацию (см. 6.14), то повторная синхронизация произойдет, если во время установления соединения будет передан сброс.
     
     
     Ответчик должен выбрать один из классов, указанных в таблице 3, как действительный ответ, соответствующий предпочтительному классу и классу(ам), содержащемуся(имся) в параметре альтернативных классов ПБДТ ЗС. Он должен указать выбранный класс ПБДТ ПС и действовать в соответствии с процедурами этого класса.
     
     Если предпочтительный класс не выбран, то при приеме ПБДТ ПС инициатор должен приспособить свои операции к процедурам выбранного класса.
     
     Примечания
     
     1 Действительные ответы, указанные в таблице 3, являются результатом как явного согласования, при котором действительным ответом является каждый из предлагаемых классов, так и неявного согласования, при котором:
     
     a) если предлагается класс 3 или 4, то действительным ответом будет класс 2;
     
     b) если предлагается класс 1, то действительным ответом будет класс 0.
     
     2 Согласование перехода от класса 2 к классу 1, а также от любого класса к более высокому классу не разрешается.
     
     3 Избыточные комбинации не являются протокольной ошибкой.
     
     
     k) Длина ПБДТ. Инициатор может предложить максимальную длину ПБДТ, а ответчик может либо принять это значение, либо предложить из набора доступных значений любое другое значение в диапазоне между 128 и предложенным значением (см. 13.3.4b).
     
     Примечание - Длина ПБДТ ЗС не должна превышать 128 октетов (см. 13.3).
     
     
     m) Предпочтительная максимальная длина ПБДТ. Значение этого параметра, умноженное на 128, создает предложенное или максимально приемлемое значение длины ПБДТ в октетах. Инициатор может предложить предпочтительную максимальную длину ПБДТ, а ответчик может либо принять это значение, либо выдать в ответ меньшее значение.
     
     Примечание - Если этот параметр используется в ПБДТ ЗС также при отсутствии параметра "длина ПБДТ", то это может привести к выбору максимальной длины ПБДТ в 128 октетов, если удаленный логический объект не распознает параметра "предпочтительная длина ПБДТ". Поэтому рекомендуется, чтобы оба эти параметра входили в ПБДТ ЗС.
     
     

     Если параметр "предпочтительная длина ПБДТ" имеется в ПБДТ ЗС, ответчик должен:
     
     - либо проигнорировать этот параметр и следовать согласованной длине ПБДТ согласно определению в 6.5.4k;
     
     - либо использовать этот параметр для определения максимальной длины ПБДТ, запрошенной инициатором, и проигнорировать параметр "длина ПБДТ". В этом случае ответчик должен использовать параметр "предпочтительная длина ПБДТ" в ПБДТ ПС и не включать в ПБДТ ПС параметр "длина ПБДТ".
     
     Если параметр "предпочтительная длина ПБДТ" отсутствует в ПБДТ ЗС, то его не следует включать в соответствующий ПБДТ ПС. В этом случае длина ПБДТ согласовывается согласно 6.5.4k.
     
     n) Обычный или расширенный формат. Доступен любой из форматов: обычный или расширенный. При использовании расширенного формата применяются параметры КРД, НР-ПБДТ, НР-ПБДТ-СД, НР-ОТВ и НР-СПБДТ-ОТВ.
     
     р) Выбор контрольной суммы. Эта информация определяет, должна или не должна контрольная сумма входить в состав ПБДТ данного соединения.
     
     q) Параметры качества услуг. Определяют пропускную способность, транзитную задержку, приоритет и коэффициент необнаруженных ошибок.
     
     Примечание - УТУ определяют транзитную задержку как параметр, требующий предварительного установления средней длины СБДТ в качестве основы для любой спецификации. Данный протокол, как указано в 13.3.4р, использует СБДТ длиной 128 октетов. Переход к спецификациям, основанным на некоторых других значениях, является частным вопросом.
     
     
     r) Неиспользование явного управления потоком в классе 2.
     
     s) Использование подтверждения приема на сетевом уровне и сетевой срочный вариант при необходимости использования класса 1.
     
     t) Использование услуги передачи срочных данных. Позволяет обоим пользователям-УТУ согласовывать вопрос использования услуги передачи срочных данных в соответствии с определениями УТУ (см. ГОСТ 34.960).
     
     u) Использование избирательного подтверждения. Позволяет логическим объектам транспортного уровня принимать решение о необходимости использования процедур, которые допускают подтверждение ПБДТ ДН, полученных вне последовательности (только в классе 4).
     
     v) Использование подтверждения запроса. Позволяет обоим логическим объектам транспортного уровня согласовывать решение об использовании или неиспользовании услуги подтверждения запроса, определенной в 6.13.4.2 (только в классах 1, 3, 4).
     

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

     
     Примечание - В таблице 4 указаны процедуры согласования факультативных функций. Согласование организовано таким образом, что если инициатор предлагает обязательную реализацию факультативной функции, определенной в разделе 14, то ответчик должен согласиться с использованием этой функции в данном СТУ, за исключением использования услуги по передаче срочных данных, которая может быть отклонена пользователем-УТУ. Если инициатор предлагает необязательное использование факультативной функции, то ответчику предоставляется право выбора в части обязательности ее реализации в данном СТУ.
     
     
     Если параметр (который для данного(ых) класса(ов) является действительным) отсутствует, но рекомендуемое его значение определено в настоящем стандарте, то эта ситуация эквивалентна наличию данного параметра с рекомендуемым значением.
     
     Каждый раз, когда в классе 2 логический объект транспортного уровня запрашивает или согласовывает услугу передачи срочных данных или услугу с использованием расширенных форматов, он должен также запрашивать или согласовывать, соответственно, использование явного управления потоком.
     
     6.5.5 Процедуры при работе с УСУ-БУС
     
     Соединение транспортного уровня устанавливается одним логическим объектом транспортного уровня (инициатором), передающим ПБДТ ЗС другому логическому объекту транспортного уровня (ответчику), который выдает в ответ ПБДТ ПС. В процессе таких передач должен осуществляться обмен информацией и параметрами, необходимыми для работы логических объектов транспортного уровня, и осуществляться согласование этих параметров. В случае поступления неожидаемого дубликата ПБДТ ЗС (с указанием класса 4 в качестве предпочтительного) в ответ должен быть выдан ПБДТ ПС.
     
     После получения ПБДТ ПС инициатор должен выдать на него подтверждение в соответствии с таблицей 5 (см. 6.13).
     
     Осуществляется обмен следующей информацией:
     
     a) Указатели: каждый логический объект транспортного уровня выбирает указатель длиной 16 бит, который должен использовать равноправный логический объект и который анализируется на соблюдение следующих ограничений:
     
     1) он не должен находиться в пользовании или в заблокированном состоянии (см. 6.18);
     

     2) он не должен быть равен нулю.
     
     Этот механизм симметричен и сам обеспечивает идентификацию СТУ. Диапазон указателей, используемых для СТУ данным логическим объектом транспортного уровня, является частным вопросом;
     
     b) Идентификаторы вызываемого и вызывающего ИД-ПДУТУ (факультативные). Обозначают вызываемый и вызывающий ПДУТУ. Если любой из сетевых адресов однозначно определяет адрес транспортного уровня, эта информация может быть опущена.
     
     c) Начальный кредит.
     
     d) Данные пользователя до 32 октетов.
     
     е) Время подтверждения.
     
     f) Параметр "контрольная сумма".
     
     g) Параметр "защита". Этот параметр и его семантика определяются пользователем.
     
     h) Время неактивности. Параметр "время неактивности" не должен вводиться в состав ПБДТ ПС, если он отсутствовал в соответствующем ПБДТ ЗС.
     
     i) Класс протокола. Класс 4 является единственным действительным значением для предпочтительного протокольного класса, предложенного инициатором и для класса, выбранного ответчиком. Альтернативный класс не разрешается.
     
     Выполняется согласование следующих параметров:
     
     k) Длина ПБДТ. Инициатор может предложить максимальную длину ПБДТ из набора доступных значений (см. 13.3.4b). Ее значение может быть ограничено максимально допустимой длиной ПБДТ (если оно известно) и не может превышать максимальную длину СБДС для УСУ-БУС в соответствии с ИСО/МЭК 8348. Ответчик может либо принять это значение, либо выдать в ответ любое значение в диапазоне между 128 и предложенным значением из набора возможных значений (см. 13.3.4b).
     
     Примечания
     
     1 Длина ПБДТ ЗС не превышает 128 октетов (см. 13.3).
     
     2 Логический объект транспортного уровня может с помощью некоторых локальных средств получить сведения о максимально доступной длине СБДС.
     
     
     m) Предпочтительная максимальная длина ПБДТ. Значение этого параметра, умноженное на 128, создает предложенное или максимально приемлемое значение длины ПБДТ в октетах. Инициатор может предложить предпочтительную максимальную длину ПБДТ, а ответчик может либо принять это значение, либо выдать в ответ меньшее значение.
     
     

     Примечание - Если этот параметр используется в ПБДТ ЗС также при отсутствии параметра "длина ПБДТ", то это может привести к выбору максимальной длины ПБДТ в 128 октетов, если удаленный логический объект не распознает параметра "предпочтительная длина ПБДТ". Поэтому рекомендуется, чтобы оба эти параметра входили в ПБДТ ЗС.
     
     
     Если "параметр "предпочтительная длина ПБДТ" имеется в ПБДТ ЗС, ответчик должен:
     
     - либо проигнорировать этот параметр и следовать согласованной длине ПБДТ согласно определению в 6.5.5k,
     
     - либо использовать этот параметр для определения максимальной длины ПБДТ, запрошенной инициатором, и проигнорировать параметр "длина ПБДТ". В этом случае ответчик должен использовать параметр "предпочтительная длина ПБДТ" в ПБДТ ПС и не включать в ПБДТ ПС параметр "длина ПБДТ".
     
     Если параметр "предпочтительная длина ПБДТ" отсутствует в ПБДТ ЗС, то его не следует включать в соответствующий ПБДТ ПС. В этом случае длина ПБДТ согласовывается согласно 6.5.5k.
     
     n) Нормальный или расширенный формат. Доступен либо нормальный, либо расширенный формат. При использовании расширенного формата он применим к параметрам КРД, НР-ПБДТ, НР-ПБДТ-СД, НР-ОТВ и НР-СПБДТ-ОТВ.
     
     р) Выбор контрольной суммы. Определяется, должна ли входить контрольная сумма в состав ПБДТ данного соединения.
     
     q) Параметр "качество услуг". Определяется пропускная способность, транзитная задержка, приоритет и коэффициент необнаруженных ошибок.
     
     Примечание - Данная УТУ определяет транзитную задержку в соответствии с требованием предварительно установленной средней длины СБДТ как основы любой спецификации. Данный протокол в соответствии с 13.3.4м использует значение 128 октетов. Переход к спецификациям, основанным на некоторых других значениях, является частным вопросом;
     
     
     r) Использование услуги передачи срочных данных. Позволяет обоим пользователям согласовать вопрос: использовать или не использовать услугу передачи срочных данных в соответствии со стандартом по услугам транспортного уровня (ГОСТ 34.960).
     
     s) Использование избирательного подтверждения. Позволяет логическим объектам транспортного уровня принимать решение о необходимости использования процедур, которые допускают подтверждение ПБДТДН, полученных вне последовательности.
     

     t) Использование подтверждения запроса. Позволяет обоим логическим объектам транспортного уровня согласовывать решение об использовании или неиспользовании услуги подтверждения запроса, определенной в 6.13.4.2.
     
     Следующая информация передается только в ПБД ЗС:
     
     u) Номер версии. Определяет версию стандарта по протоколу транспортного уровня, используемую для данного соединения.
     
     6.6 Отказ от соединения
     
     6.6.1 Назначение
     
     Процедура отказа от соединения используется во всех классах, когда в ответ на ПБДТ ЗС логический объект транспортного уровня отказывается от СТУ.
     
     6.6.2 Используемые ПБДТ и параметры
     
     Данная процедура использует следующие ПБДТ и параметры:
     
     a) ПБДТ ЗР:
     
     УКАЗ-ОТП,
     
     причина,
     
     данные пользователя;
     
     b) ПБДТ ОШ:
     
     причина отказа,
     
     недействительный ПБДТ.
     
     6.6.3 Процедура
     
     Если СТУ не может быть принято, то при получении ПБДТ ЗС ответчик должен передать ПБДТ ЗР. Параметр "причина" должен указать, почему соединение не было принято. Поле указателя отправителя в ПБДТ ЗР должно быть установлено в ноль, чтобы обозначить неприсвоенный указатель.
     
     При приеме ПБДТ ЗР логический объект транспортного уровня должен рассматривать соединение разъединенным.
     
     Ответчик в ответ на недействительный ПБДТ ЗС должен передать ПБДТ ОШ или ПБДТ ЗР. Если в ответ на ПБДТ ЗС инициатор принял ПБДТ ОШ, он должен считать соединение разъединенным.
     
     Примечания
     
     1 Если недействительный ПБДТ ЗС содержит класс 0 как предпочтительный, рекомендуется выдать в ответ ПБДТ ОШ. На все другие недействительные ПБДТ ЗС в ответ может быть выдан либо ПБДТ ОШ, либо ПБДТ ЗР.
     
     2 Если для данного соединения был установлен факультативный управляющий тайм-аут ТУ1, то после приема ПБДТ ЗР или ПБДТ ОШ инициатор соединения должен прекратить его отсчет.
     
     3 Если ни одного СТУ в данный момент не прикреплено к ССУ, то решение инициатора о необходимости разъединения ССУ является частным вопросом.
     
     

     6.7 Нормальное разъединение
     
     6.7.1 Нормальное разьединение при работе с УСУ-УС
     
     6.7.1.1 Назначение
     
     Процедура разъединения используется логическим объектом транспортного уровня для завершения СТУ. Неявный вариант используется в классе 0. Явный вариант используется в классах 1-4.
     
     Примечания
     
     1 При использовании неявного варианта (т.е. в классе 0) время существования СТУ непосредственно связано с временем существования ССУ.
     
     2 Использование явного варианта процедуры разъединения позволяет разъединять СТУ независимо от нижерасположенного ССУ.
     
     
     6.7.1.2 Примитивы УСУ
     
     Данная процедура использует следующие примитивы УСУ:
     
     а) С-РАЗЪЕДИНЕНИЕ,
     
     b) С-ДАННЫЕ.
     
     6.7.1.3 Используемые ПБДТ и параметры
     
     Данная процедура использует следующие ПБДТ и параметры:
     
     a) ПБДТ ЗР:
     
     причина,
     
     данные пользователя,
     
     УКАЗ-ОТП,
     
     УКАЗ-ПОЛ;
     
     b) ПБДТ ПР.
     
     6.7.1.4 Процедура для неявного варианта
     
     В неявном варианте каждый логический объект транспортного уровня разъединяет СТУ путем разъединения ССУ, к которому оно прикреплено. Если логический объект транспортного уровня получил примитив С-РАЗЪЕДИНЕНИЕ, это должно рассматриваться как разъединение СТУ.
     
     6.7.1.5 Процедура для явного варианта
     
     При необходимости инициирования разъединения СТУ логический объект транспортного уровня
     
     a) если он предварительно передал или принял ПБДТ ПС (см. примечание 1), должен:
     
     1) передать ПБДТ ЗР;
     
     2) аннулировать все последующие полученные ПБДТ, кроме ПБДТ ЗР или ПР;
     
     3) при приеме ПБДТ ЗР или ПР рассматривать СТУ разъединенным;
     
     b) если условие подпункта а) не имеет места, он должен:
     
     1) для всех классов, кроме класса 4, ожидать подтверждения неподтвержденных ПБДТ ЗС; если логический объект получит ПБДТ ПС, - выполнить процедуры, приведенные в 6.7.1.5а;
     
     2) для класса 4 - либо передать ПБДТ ЗР с нулевым значением поля УКАЗ-ПОЛ, либо выполнить процедуру по 6.7.1.5b. В первом случае полученный затем ПБДТ ПС, относящийся к классу 4, будет проигнорирован. Принятый ПБДТ ПС другого класса будет обрабатываться следующим образом: при классе 0 ССУ должно быть разъединено, при других классах должен быть передан ПБДТ ЗР с УКАЗ-ПОЛ, равным значению УКАЗ-ОТП в принятом ПБДТ ПС, после чего процедура разъединения для данного класса продолжается.
     
     Логический объект транспортного уровня, получивший ПБДТ ЗР, должен:
     

     c) если он предварительно передал ПБДТ ЗР для того же СТУ, рассматривать СТУ разъединенным;
     
     d) если он предварительно передал ПБДТ ЗС, которое не было подтверждено ПБДТ ПС, рассматривать соединение отклоненным (см. 6.6);
     
     если поле УКАЗ-ОТП не равно нулю, то ПБДТ ПР должен быть передан с полем УКАЗ-ПОЛ, равным УКАЗ-ОТП принятого ПБДТ ЗР.
     
     Примечание - В этом случае логическая связь с ПБДТ ЗР устанавливается независимо от его поля УКАЗ-ОТП (см. 6.9.1.4 и 6.9.2.4).
     
     
     e) если условия подпунктов с) и d) не имеют места, передать ПБДТ ПР и рассматривать СТУ разъединенным. Если полученный ПБДТ ЗР имеет поле УКАЗ-ПОЛ, равный нулю, то независимо от локального указателя должен быть передан ПБДТ ПР с полем УКАЗ-ОТП, равным нулю.
     
     Примечание - Если логический объект, получивший такой ПБДТ ЗР, заранее решил согласовать снижение класса, он всегда имеет право рассматривать такой ПБДТ ЗР как ложный. Поскольку никакой логической взаимосвязи ПБДТ с СТУ не установлено, СТУ на стороне ответчика не сбрасывается, но в ответ на переданный ПБДТ ПС должен быть выдан ПБДТ ЗР (ложный ПБДТ ПС).
     
     
     Примечания
     
     1 Это требование обеспечивает осведомленность логического объекта транспортного уровня об удаленном указателе для данного СТУ.
     
     2 Если СТУ рассматривается разъединенным, то локальный указатель для СТУ либо доступен для повторного использования, либо заблокирован (см. 6.18).
     
     3 После разъединения СТУ соединение сетевого уровня может быть также разъединено либо сохранено для его повторного использования с целью прикрепления других СТУ (см. 6.1.1).
     
     4 За исключением класса 4 рекомендуется, чтобы в случае неполучения в течение ТУ логическим объектом транспортного уровня подтверждения ПБДТ ЗР, он в зависимости от обстоятельств либо сбросил, либо разъединил ССУ и заблокировал указатель (см. 6.18). Для всех других СТУ, мультиплексированных в данном ССУ, должна быть выполнена процедура сброса или разъединения.
     
     5 Если логический объект транспортного уровня перед передачей ПБДТ ЗР находится в состоянии ожидания ПБДТ ПС и ССУ сброшено или разъединено, он должен рассматривать СТУ разъединенным и во всех классах, кроме классов 0 и 2, заблокировать указатель (см. 6.18).
     
     
     6.7.2 Нормальное разъединение при работе с УСУ-БУС
     
     6.7.2.1 Назначение
     
     Процедура разъединения используется логическим объектом транспортного уровня для завершения СТУ.
     
     6.7.2.2 Примитивы УСУ
     
     Данная процедура использует следующий примитив УСУ:
     
     С-БЛОК-ДАННЫХ.
     
     6.7.2.3 Используемые ПБДТ и параметры
     
     Данная процедура использует следующие ПБДТ и параметры:
     
     a) ПБДТ ЗР
     
     - причина;
     
     - данные пользователя;
     
     - УКАЗ-ОТП;
     
     - УКАЗ-ПОЛ;
     
     b) ПБДТ ПР.
     
     6.7.2.4 Процедура
     
     При необходимости инициировать разъединение СТУ логический объект транспортного уровня должен передавать ПБДТ ЗР и аннулировать все последующие поступающие ПБДТ за исключением ПБДТ ЗР и ПР.
     
     При получении ПБДТ ЗР или ПР он должен рассматривать СТУ разъединенным и заблокировать локальный указатель (см. 6.18). Если ПБДТ ПС был ранее передан или принят этим СТУ, то удаленный указатель известен и должен использоваться для формирования УКАЗ-ПОЛ в подлежащем передаче ПБДТ ЗР. Если удаленный указатель неизвестен, то поле УКАЗ-ПОЛ в ПБДТ ЗР может быть установлено в ноль, либо логический объект может ожидать получения ПБДТ ПС, прежде чем передать ПБДТ ЗР.
     
     Примечание - В случае, когда логический объект решил ожидать поступления ПБДТ ПС по данному соединению, тупиковая ситуация, которая может возникнуть вследствие непоступления ПБДТ СС вообще, предотвращается благодаря истечению счетчика повторных передач ПБДТ ЗС, что обуславливает передачу ПБД ЗР.
     
     
     Логический объект транспортного уровня, получив ПБДТ ЗР, должен:
     
     a) считать СТУ разъединенным, если он перед этим передал по данному СТУ ПБДТ ЗР;
     
     b) считать запрос на СТУ отклоненным (см. 6.6), если он перед этим передал по данному СТУ ПБДТ ЗС и в подтверждение не получил ПБДТ ПС;
     
     c) считать СТУ разъединенным и передать ПБДТ ПР во всех других случаях. Если в полученном ПБДТ ЗР поле УКАЗ-ПОЛ установлено в ноль, должен быть передан ПБДТ ПР с полем УКАЗ-ОТП, равным нулю, независимо от значения локального указателя.
     
     6.8 Разъединение при ошибках при работе с УСУ-УС
     
     6.8.1 Назначение
     
     Эта процедура используется только в классах 0 и 2 с целью разъединения СТУ при приеме примитива С-РАЗЪЕДИНЕНИЕ индикация
     
     6.8.2 Примитивы УСУ
     
     Эта процедура использует следующие сервисные примитивы:
     
     a) С-РАЗЪЕДИНЕНИЕ запрос;
     
     b) С-РАЗЪЕДИНЕНИЕ индикация;
     
     c) С-СБРОС индикация;
     
     d) С-СБРОС ответ
     
     6.8.3 Процедура
     
     Если по ССУ, к которому прикреплено СТУ, принят примитив С-РАЗЪЕДИНЕНИЕ индикация или С-СБРОС индикация, то оба логических объекта транспортного уровня должны считать, что СТУ разъединено, и должны проинформировать об этом пользователя УТУ.
     
     При получении примитива С-СБРОС индикация:
     
     - в классе 0 должен выдаваться примитив С-РАЗЪЕДИНЕНИЕ запрос;
     
     - в классе 2 должен выдаваться один из двух примитивов:
     
     С-СБРОС ответ или С-РАЗЪЕДИНЕНИЕ запрос. Конкретный выбор является частным вопросом. Однако, если к ССУ прикреплены другие СТУ либо ССУ назначен другой класс, то для определения конкретного выдаваемого примитива должны использоваться процедуры восстановления при ошибках для данного класса.
     
     6.9 Логическая привязка ПБДТ к СТУ
     
     6.9.1 Логическая привязка ПБДТ к СТУ при работе с УСУ-УС
     
     6.9.1.1 Назначение
     
     Данная процедура используется во всех классах для интерпретации принимаемого СБДС как одного или нескольких ПБДТ и, по возможности, для привязки каждого ПБДТ к СТУ.
     
     6.9.1.2 Примитивы УСУ
     
     Данная процедура использует следующие примитивы УСУ:
     
     a) С-ДАННЫЕ индикация;
     
     b) С-СРОЧНЫЕ-ДАННЫЕ индикация;
     
     c) С-СБРОС запрос;
     
     d) С-РАЗЪЕДИНЕНИЕ запрос.
     
     6.9.1.3 Используемые ПБДТ и параметры
     
     Данная процедура использует следующие ПБДТ и параметры:
     
     a) любые ПБДТ, кроме ПБДТ ЗС, ПБДТ ДН в классах 0 и 1 и ПБДТ ПД в классе 1:
     
     - УКАЗ-ПОЛ;
     
     b) ПБДТ: ЗС, ПС, ЗР и ПР
     
     - УКАЗ-ОТП;
     
     c) ПБДТ ДН в классах 0 и 1 и ПБДТ ПД в классе 1.
     
     6.9.1.4 Процедуры
     
     6.9.1.4.1 Идентификация ПБДТ
     
     Если полученный СБДС или срочный СБДС не может быть декодирован (т.е. он не содержит безошибочных ПБДТ), либо он искажен (т.е. содержит ПБДТ с неправильной контрольной суммой), то логический объект транспортного уровня должен действовать следующим образом:
     
     a) если ССУ, в котором обнаружена ошибка, имеет прикрепленное СТУ класса 0 или 1 - рассматривать полученный СБДС как протокольную ошибку (см. 6.22) для данного СТУ;
     
     b) в противном случае:
     
     1) если полученный СБДС может быть декодирован, но содержит искаженные ПБДТ - проигнорировать эти ПБДТ (только в классе 4) и действовать факультативно в соответствии с 6.9.4.1b 2);
     
     2) если полученный СБДС не может быть декодирован - передать примитив С-СБРОС запрос или С-РАЗЪЕДИНЕНИЕ запрос для данного ССУ и для всех СТУ, прикрепленных к этому ССУ (при их наличии), применив процедуры, определенные для обработки передаваемых сетевым уровнем сбросов и разъединений.
     
     Если полученный СБДС может быть декодирован и он не искажен, то логический объект транспортного уровня должен действовать следующим образом:
     
     a) если ССУ, по которому был принят СБДС, имеет прикрепленное к нему СТУ класса 0 - рассматривать этот СБДС как формирующий один ПБДТ и логически связать этот ПБДТ с СТУ (см. 6.9.1.4.2);
     
     b) в противном случае вызвать процедуры разделения и для каждого ПБДТ применить процедуры, определенные в 6.9.1.4.2, в том порядке, в котором они представлены в СБДС.
     
     6.9.1.4.2 Логическая привязка отдельных ПБДТ
     
     Если принятый ПБДТ представляет собой ПБДТ ЗС и если он является дубликатом (что обнаруживается путем использования ПДУ-СУ данного ССУ и параметра УКАЗ-ПОЛ), то этот ПБДТ логически привязывается к СТУ, организованному при передаче исходного ПБДТ ЗС; в противном случае он обрабатывается как запрос на создание нового СТУ.
     
     Если принятый ПБДТ представляет собой ПБДТ ДН и ССУ не имеет прикрепленного к нему СТУ, а ПБДТ ДН относится к ПБДТ класса 0 или 1 (что распознается по отсутствию поля УКАЗ-ПОЛ), то этот ПБДТ должен быть проигнорирован.
     
     В противном случае для идентификации СТУ используется параметр УКАЗ-ПОЛ. Различают следующие случаи:
     
     а) Если УКАЗ-ПОЛ не назначен для СТУ, то логической привязки с СТУ не создается и возможны три случая:
     
     1) если принятый ПБДТ представляет собой ПБДТ ПС, то логический объект транспортного уровня должен выдать в ответ по тому же ССУ ПБДТ ЗР. Поле УКАЗ-ОТП в этом ПБДТ может иметь либо значение 0, либо это поле может быть взято из полученного ПБДТ ПС;
     
     2) если принятый ПБДТ представляет собой ПБДТ ЗР, то логический объект транспортного уровня должен выдать в ответ ПБДТ ПР по тому же ССУ, кроме случая, когда в ПБДТ ЗР содержится поле УКАЗ-ОТП в значении 0, что требует передачи ПБДТ ПР, либо если логический объект транспортного уровня обеспечивает только класс 0, ССУ должно быть разъединено;
     
     3) если принятый ПБДТ не является ни ПБДТ ЗР, ни ПБДТ ПС, этот ПБДТ должен быть аннулирован.
     
     b) Если УКАЗ-ПОЛ назначен СТУ, а ПБДТ принят по ССУ, к которому это СТУ не было прикреплено, то возможны четыре случая:
     
     1) если СТУ относится к классу 4 и если данный ПБДТ и ПБДТ ЗС приняты по ССУ с одной и той же парой ПДУСУ, то принятый ПБДТ логически связывается с этим СТУ и рассматривается как осуществляющий прикрепление;
     
     2) если СТУ не прикреплено ни к одному ССУ (ожидая повторного прикрепления после неисправности) и если данный ПБДТ принят по ССУ с той же парой ПДУСУ, по которому принят ПБДТ ЗС, то осуществляется логическая привязка ПБДТ к этому ССУ, кроме случаев приема ПБДТ ПР, ЗР и ПС, приведенных в 6.9.1.4.2с, d, e соответственно;
     
     3) в классах 1 и 3 возможно также получение ПБДТ, выполняющего прикрепление до уведомления о разъединении существующего ССУ (т.e. СТУ прикреплено к ССУ, но ПБДТ, содержащий соответствующий УКАЗ-ПОЛ, получен по другому ССУ). В этом случае рекомендуется, чтобы логический объект транспортного уровня:
     
     - выдал примитив С-РАЗЪЕДИНЕНИЕ запрос по тому ССУ, к которому в данный момент прикреплено СТУ;
     
     - применил ко всем СТУ, прикрепленным к данному ССУ, процедуры обработки принятого примитива С-РАЗЪЕДИНЕНИЕ индикация;
     
     - после чего обработал ПБДТ, выполняющий повторное прикрепление;
     
     4) в остальных случаях ПБДТ рассматривается как имеющий УКАЗ-ПОЛ, не назначенный для СТУ (случай а)).
     
     c) Если принятый ПБДТ представляет собой ПБДТ ПР, он логически привязывается к тому СТУ, которому назначен УКАЗ-ПОЛ, если только УКАЗ-ОТП не является ожидаемым, в случае чего ПБДТ ПР аннулируется.
     
     d). Если принятый ПБДТ представляет собой ПБДТ ЗР, то возможны четыре случая:
     
     1) если УКАЗ-ОТП не является ожидаемым, то ПБДТ ПР передается обратно с УКАЗ-ПОЛ, равным УКАЗ-ОТП принятого ПБДТ ЗР, без выполнения логической привязки, кроме случая, когда логический объект транспортного уровня обеспечивает только класс 0 и не может передавать ПБДТ ПР и когда он должен разъединить ССУ вместо передачи ПБДТ ПР;
     
     2) если ПБДТ ЗС не подтвержден, то ПБДТ ЗР логически привязывается к СТУ независимо от значения его параметра УКАЗ-ОТП;
     
     3) если логический объект транспортного уровня реализует класс 4 и если УКАЗ-ПОЛ равен 0 и имеется неподтвержденный ПБДТ ПС, либо ожидается примитив Т-СОЕДИНЕНИЕ ответ, то ПБДТ ЗР должен быть логически привязан к СТУ, имеющему УКАЗ-ОТП как указатель удаленного объекта;
     
     4) В остальных случаях ПБДТ ЗР логически привязывается к СТУ, идентифицированному параметром УКАЗ-ПОЛ;
     
     e) Если принятый ПБДТ представляет собой ПБДТ ПС, параметр которого УКАЗ-ПОЛ идентифицирует открытое соединение (для которого был ранее принят ПБДТ ПС), а параметр УКАЗ-ОТП в ПБДТ ПС не соответствует удаленному указателю, то ПБДТ ЗР передается обратно с УКАЗ-ПОЛ, равным УКАЗ-ОТП принятого ПБДТ ПС, и никакой логической привязки ПБДТ к СТУ не осуществляется.
     
     f) Если ни один из перечисленных случаев не имеет места, то осуществляется логическая привязка ПБДТ к СТУ, идентифицированному параметром УКАЗ-ПОЛ.
     
     6.9.2 Логическая привязка ПБДТ к СТУ при работе с УСУ-БУС
     
     6.9.2.1 Назначение
     
     Данная процедура используется для интерпретации принятых СБДС как одного или нескольких ПБДТ и, по возможности, для логической привязки каждого такого ПБДТ к СТУ.
     
     6.9.2.2 Примитивы УСУ
     
     Данная процедура использует следующий примитив УСУ
     
     С-БЛОК-ДАННЫХ
     
     6.9.2.3 Используемые ПБДТ и параметры
     
     Данная процедура использует следующие ПБДТ и параметры:
     
     a) все ПБДТ кроме ПБДТ ПС
     
     - УКАЗ-ПОЛ;
     
     b) ПБДТ ЗС, ПС, ЗР и ПР
     
     - УКАЗ-ОТП.
     
     6.9.2.4 Процедура
     
     6.9.2.4.1 Идентификация ПБДТ
     
     Если полученный СБДС не может быть декодирован (т.е. он не содержит одного или нескольких правильных ПБДТ), либо если он искажен (т.е. содержит СБДС с неправильной контрольной суммой), логический объект транспортного уровня должен проигнорировать (аннулировать) такие ПБДТ. Если же СБДС может быть декодирован и он не искажен, то логический объект транспортного уровня должен привлечь отдельные процедуры и применить для каждого отдельного ПБДТ в порядке их расположения в СБДС процедуру по 6.9.2.4.2.
     
     6.9.2.4.2 Логическая привязка отдельных ПБДС
     
     Логическая привязка принятых ПБДТ к СТУ в общем случае осуществляется попытками увязать поле УКАЗ-ПОЛ в принятом ПБДТ и пару ПДУСУ, через которые он был получен с аналогичными объектами существующего СТУ. Имеются три исключения из этой общей процедуры: если принятым ПБДТ является ПБДТ ЗС, то вместо УКАЗ-ПОЛ используется УКАЗ-ОТП; если принятым ПБДТ является ПБДТ ЗР или ПР, то дополнительно к УКАЗ-ПОЛ используется УКАЗ-ОТП; и если принятым ПБДТ является ПБДТ ПС, у которого параметр УКАЗ-ПОЛ идентифицирует открытое соединение (т.е. по которому ранее был получен ПБДТ ПС), то дополнительно к УКАЗ-ПОЛ используется УКАЗ-ОТП.
     
     Следующие действия должны выполняться в результате невозможности логически увязать ПБДТ с существующим СТУ.
     
     a) Для ПБДТ ЗС должно быть создано новое СТУ.
     
     b) Для ПБДТ ПС должен быть передан ПБДТ ЗР с использованием полей УКАЗ-ОТП и УКАЗ-ПОЛ принятого ПБДТ ПС в виде УКАЗ-ПОЛ и УКАЗ-ОТП соответственно ПБД ЗР.
     
     c) Для ПБДТ ЗР возможны четыре случая:
     
     1) если ПБДТ ЗС не подтвержден для соединения, идентифицированного полем УКАЗ-ПОЛ в ПБДТ ЗР, то ПБДТ ЗР логически увязывается с этим соединением независимо от поля УКАЗ-ОТП в ПБДТ ЗР;
     
     2) если ПБДТ ЗС подтвержден для соединения, идентифицированного полем УКАЗ-ПОЛ в ПБДТ ЗР, и УКАЗ-ОТП не ожидается, то передается ПБДТ ПР, использующий поле УКАЗ-ОТП ПБДТ ЗР в качестве УКАЗ-ПОЛ, и никакой логической привязки не делается;
     
     3) если поле УКАЗ-ПОЛ в ПБД ЗР равно нулю и имеется неподтвержденный ПБДТ ПС, либо если ожидается поступление примитива И-СОЕДИНЕНИЕ.запрос по СТУ, содержащем удаленный указатель, равный УКАЗ-ОТП блока ПБДТ ЗР, то этот ПБДТ ЗР логически увязывается с этим СТУ;
     
     4) во всех других ситуациях ПБДТ ЗР логически увязывается с СТУ, которое идентифицируется полем УКАЗ-ПОЛ блока ПБДТ ЗР.
     
     d) При всех других типах ПБДТ они аннулируются.
     
     6.10 Нумерация ПБДТ "данные"
     
     6.10.1 Назначение
     
     Нумерация ПБДТ "данные" используется в классах 1, 2 (кроме случая неиспользования факультативной функции явного управления потоком), 3 и 4. Цель нумерации - обеспечить возможность использования функций восстановления, управления потоком и упорядочения.
     
     6.10.2 Используемые ПБДТ и параметры
     
     Данная процедура использует следующий ПБДТ и параметр:
     
     ПБДТ ДН
     
     - НР-ПБДТ.
     
     6.10.3 Процедура
     
     Логический объект транспортного уровня должен присвоить порядковый номер ноль для НР-ПБДТ первого ПБДТ ДН, который он передает по СТУ. Для последующих ПБДТ ДН, передаваемых по тому же СТУ, логический объект транспортного уровня должен присваивать порядковые номера, на единицу большие предыдущего.
     
     Если ПБДТ передается повторно, то параметр НР-ПБДТ должен иметь то же значение, которое он имел при первой передаче ПБДТ ДН.
     
     В случае выбора нормальных форматов должны использоваться арифметические операции по модулю 2, а при выборе расширенных форматов - арифметические операции по модулю 2. В настоящем стандарте соотношения "больше чем" и "меньше чем" применимы к набору порядковых номеров ПБДТ, диапазон которых меньше указанных модулей, а начальный и конечный номера известны. Термин "меньше чем" означает "более раннее появление в последовательности окна", а термин "больше чем" - "более позднее появление в последовательности окна".
     
     6.11 Передача срочных данных
     
     6.11.1 Передача срочных данных при работе с УСУ-УС
     
     6.11.1.1 Назначение
     
     Выбор процедуры передачи срочных данных осуществляется во время установления соединения. Сетевой нормальный вариант данных может быть использован в классах 1-4. Сетевой срочный вариант используется только в классе 1.
     
     6.11.1.2 Примитивы УСУ
     
     Данная процедура использует следующие примитивы УСУ:
     
     a) С-ДАННЫЕ;
     
     b) С-СРОЧНЫЕ-ДАННЫЕ.
     
     6.11.1.3 Используемые ПБДТ и параметры
     
     Данная процедура использует следующие ПБДТ и параметры:
     
     a) ПБДТ СД
     
     - НР-ПБДТ-СД;
     
     b) ПБДТ ПСД
     
     - НР-СПБДТ-ОТВ.
     
     6.11.1 Процедуры
     
     Параметр "данные пользователя-УТУ" каждого примитива Т-СРОЧНЫЕ-ДАННЫЕ запрос должен передаваться в виде поля данных ПБДТ СД.
     
     Каждый принятый ПБДТ СД должен быть подтвержден блоком ПБДТ ПСД.
     
     В любой момент времени в каждом направлении СТУ может быть только один неподтвержденный ПБДТ СД.
     
     ПБДТ СД с полем данных нулевой длины должен рассматриваться как протокольная ошибка.
     
     Примечания
     
     1 Для передачи данных используется сетевой нормальный вариант данных, если только не согласовано использование сетевого срочного варианта (только для класса 1); в последнем случае ПБДТ СД и ПБДТ ПСД передаются в полях "данные" примитивов С-СРОЧНЫЕ-ДАННЫЕ (см. 6.2.3).
     
     2 Никакие ПБДТ не могут быть переданы с использованием сетевого срочного варианта до подтверждения приема ПБДТ ПС, чтобы предотвратить возможность обгона ПБДТ ПС сетевыми срочными данными.
     
     
     6.11.2 Передача срочных данных при работе с УСУ-БУС
     
     6.11.2.1 Назначение
     
     Процедуры передачи срочных данных выбираются в процессе установления соединения.
     
     6.11.2.2 Примитивы УСУ
     
     Данная процедура использует следующий примитив УСУ
     
     С-БЛОК-ДАННЫХ.
     
     6.11.2.3 Используемые ПБДТ и параметры.
     
     Данная процедура использует следующие ПБДТ и параметры:
     
     a) ПБДТ СД
     
     - НР-ПБДТ-СД;
     
     b) ПБДТ ПСД
     
     - НР-СПБДТ-ОТВ.
     
     6.11.2.4 Процедуры
     
     Параметр "данные-пользователя-УТУ" каждого примитива Т-СРОЧНЫЕ-ДАННЫЕ.запрос должен передаваться в виде поля данных ПБДТ СД.
     
     На каждый принятый ПБДТ СД должно быть выдано подтверждение в виде ПБДТ ПСД.
     
     В любой момент времени в каждом направлении СТУ может находиться не более одного неподтвержденного ПБДТ СД.
     
     ПБДТ СД с нулевой длиной поля данных должен рассматриваться как протокольная ошибка (см. 6.22).
     
     6.12 Повторное прикрепление после отказа при работе с УСУ-УС
     
     6.12.1 Назначение
     
     Процедура повторного прикрепления после отказа используется в классах 1 и 3 для того, чтобы начать восстановление после сигнала поставщика УСУ о разъединении.
     
     6.12.2 Примитивы УСУ
     
     Данная процедура использует следующий примитив УСУ:
     
     С-РАЗЪЕДИНЕНИЕ индикация.
     
     6.12.3 Процедура
     
     При получении примитива С-РАЗЪЕДИНЕНИЕ индикация для ССУ, к которому прикреплено СТУ, инициатор должен выполнить одно из следующих действий:
     
     а) Если тайм-аут ТПР еще не истек и нет сохраняемого ПБДТ ЗР, то:
     
     1) прикрепить СТУ к другому ССУ (см. 6.1) и начать отсчет тайм-аута ТПР (если он не отсчитывается);
     
     2) при ожидании завершения прикрепления, если:
     
     - принят примитив С-РАЗЪЕДИНЕНИЕ индикация - повторить процедуру по 6.12.3а;
     
     - истек ТПР - начать процедуру по 6.12.3b;
     
     3) если повторное прикрепление завершено - начать повторную синхронизацию, выполнив процедуру, описанную в 6.14.4.1, и, если выполнена процедура по 6.14.4.1b, ожидать следующего события следующим образом:
     
     - если в результате повторной синхронизации получен действительный ПБДТ - прекратить отсчет тайм-аута ТПР либо
     
     - если ТПР истек, - ждать следующего события, либо
     
     - если принят примитив С-РАЗЪЕДИНЕНИЕ индикация - начать процедуру либо по 6.12.3а, либо по 6.12.3b в зависимости от состояния ТПР.
     
     Примечание - По истечении ТПР в состоянии ожидания следующего события рекомендуется, чтобы инициатор установил тайм-аут в значение, равное значению ТОП. Если этот тайм-аут истечет до наступления следующего события, инициатор должен начать процедуру по 6.12.3b.
     
     
     b) Если тайм-аут ТПР истек - рассматривать СТУ разъединенным и заблокировать указатель (см. 6.18).
     
     c) Если имеется сохраняемый ПБДТ ЗР и тайм-аут ТПР еще не истек - выполнить действия по 6.12.3а либо по 6.12.3b.
     
     Ответчик должен начать отсчет своего ТОП, если он еще не отсчитывается. Поступление первого ПБДТ, относящегося к данному СТУ (в результате повторной синхронизации со стороны инициатора) завершает процедуру повторного прикрепления после неисправности. Отсчет тайм-аута ТОП прекращается, и ответчик должен продолжить повторную синхронизацию (см. 6.14). Если за это время не произошло повторного прикрепления, СТУ считается разъединенным, а указатель блокируется (см. 6.18).
     
     6.12.4 Тайм-ауты
     
     Процедура повторного прикрепления после отказа использует два тайм-аута:
     
     a) ТПР - время для попытки повторного прикрепления/повторной синхронизации;
     
     b) ТОП - время ожидания повторного прикрепления/повторной синхронизации.
     
     Тайм-аут ТПР используется инициатором. Его длительность не должна превышать 2 мин минус сумма максимальной задержки распространения сигналов разъединения и максимальной транзитной задержки ССУ (см. примечание 1). Значение ТПР может быть указано в ПБДТ ЗС.
     
     Тайм-аут ТОП используется ответчиком. Если параметр "время повторного прикрепления" имеется в ПБДТ ЗС, длительность ТОД должна быть больше суммы значений трех величин: длительности ТПР, максимальной задержки распространения сигналов разъединения и максимальной транзитной задержки ССУ.
     
     Если параметр "время повторного прикрепления" отсутствует в ПБДТ ЗС, для ТОП должно использоваться рекомендуемое значение 2 мин.
     
     Примечания
     
     1 ТПР может быть установлен в ноль (т.е. прикрепление отсутствует) при условии, что требуемое КУ удовлетворено. Это может иметь место, если, например, частота генерации разъединений со стороны поставщика ССУ очень низка.
     
     2 Включение параметра "время повторного прикрепления" в ПБДТ ЗС позволяет ответчику использовать значение ТОП, меньшее 2 мин.
     
     3 При использовании факультативных тайм-аутов ТУ1 и ТУ2 рекомендуется:
     
     a) прекратить отсчет тайм-аутов ТУ1 или ТУ2, если они отсчитываются во время запуска тайм-аутов ТПР или ТОП;
     
     b) при необходимости повторно начать отсчет ТУ1 или ТУ2, если соответствующий ПБДТ (ЗС или ЗР соответственно) передается повторно;
     
     c) выбрать значения ТУ1 и ТУ2, превышающие значение ТПР.
     
     
     6.13 Сохранение ПБДТ до получения подтверждения
     
     6.13.1 Назначение
     
     Процедура сохранения ПБДТ до получения подтверждения используется в классах 1, 3 и 4 для обеспечения и уменьшения повторных передач после возможной потери ПБДТ.
     
     Вариант подтверждения приема используется только в классе 1, если он согласован во время установления соединения (см. примечание).
     
     Вариант ПБДТ ПД используется в классах 3 и 4, а также в классе 1, если вариант подтверждения приема не был согласован во время установления соединения. Кроме того, в классе 4 факультативная возможность избирательного подтверждения может быть согласована во время установления соединения.
     
     Процедура подтверждения запроса выбирается во время установления соединения и может использоваться в классах 3 и 4, а также в классе 1, если подтверждение варианта приема не было согласовано во время установления соединения. Это позволяет логическому объекту транспортного уровня запрашивать подтверждения сохраняемых ПБДТ ДН путем установки параметра ЗМП в передаваемом ПБДТ ДН.
     
     Примечание - Использование варианта подтверждения приема зависит от доступности услуги подтверждения приема на сетевом уровне и от ожидаемого снижения затрат.
     
     
     6.13.2 Примитивы услуг сетевого уровня
     
     При работе с УСУ-УС данная процедура использует следующие примитивы УСУ:
     
     a) С-ДАННЫЕ,
     
     b) С-ПОДТВЕРЖДЕНИЕ-ДАННЫХ.
     
     При работе с УСУ-БУС данная процедура использует следующий примитив УСУ:
     
     С-БЛОК-ДАННЫХ.
     
     6.13.3 Используемые ПБДТ и параметры
     
     Данная процедура использует следующие ПБДТ и параметры:
     
     a) ПБДТ: ЗС, ПС, ЗР и ПР;
     
     b) ПБДТ ОТК и ПД
     
     - НР-ОТВ;
     
     - параметры избирательного подтверждения;
     
     c) ПБДТ ДН
     
     - НР-ПБДТ;
     
     d) ПБДТ СД
     
     - НР-ПБДТ-СД;
     
     e) ПБДТ СД
     
     - НР-ПБДТ-СД;
     
     f) ПБДТ ПСД
     
     - НР-СПБДТ-ОТВ.
     
     6.13.4 Процедуры
     
     6.13.4.1 Сохранение до получения подтверждения ПБДТ
     
     Для осуществления повторной передачи должны сохраняться копии следующих ПБДТ в процессе их первоначальной передачи:
     
     ПБДТ: ЗС, ПС, ЗР, ДН и СД,
     
     за исключением следующего случая: если ПБДТ ЗР передан в ответ на ПБДТ ЗС, то необходимости в сохранении копии ПБДТ ЗР нет.
     
     Копия каждого из перечисленных ПБДТ должна сохраняться до тех пор, пока
     
     а) он не будет подтвержден, как указано в таблице 5, или
     
     b) не будет разъединено СТУ.
     
     
Таблица 5 - Подтверждение ПБДТ
     

     
     
     6.13.4.2 Подтверждение варианта приема
     
     В варианте подтверждения приема, применимом только в классе 1, логические объекты транспортного уровня должны:
     
     a) установить параметр "запрос подтверждения" только в том случае, если параметр "данные" содержит ПБДТ ПС или ДН (см. примечания 1 и 2);
     
     b) выдать примитив С-ДАННЫЕ-ПОДТВЕРЖДЕНИЕ запрос, если он принял примитив С-ДАННЫЕ индикация с установленным параметром "запрос подтверждения".
     
     Примечания
     
     1 Решение о том, в каких из примитивов С-ДАННЫЕ запрос должен быть установлен параметр "запрос подтверждения" для каждого логического объекта транспортного уровня является частным вопросом. Это решение обычно зависит от доступной емкости памяти для сохраняемых копий ПБДТ ДН.
     
     2 Использование параметра "запрос подтверждения" может влиять на качество УСУ.
     
     3 В классе 3, а также в классе 2 в случае использования явного варианта ПД, если логический объект транспортного уровня не передает ПБДТ ПД на каждый полученный ПБДТ ДН, рекомендуется:
     
     - начать отсчет тайм-аута после приема ПБДТ ДН;
     
     - передать ПБДТ ПД с обновленной информацией окна при истечении тайм-аута, если ПБДТ ПД с той же информацией окна не был ранее передан.
     
     Выбор значения тайм-аута является локальным вопросом, однако он может повлиять на производительность.
     
     4 Рекомендуется, чтобы в случае, если передающий логический объект транспортного уровня имеет ограничения на число сохраняемых у него ПБДТ, он устанавливал параметр ЗМП для устранения задержки, в передаче ПБДТ ДН, обусловленной удаленным логическим объектом транспортного уровня, который следует политике удержания ПД.
     
     
     6.14 Повторная синхронизация
     
     6.14.1 Назначение
     
     Процедуры повторной синхронизации используются в классах 1 и 3 для возврата СТУ в нормальное состояние после сброса или во время повторного прикрепления после неисправности в соответствии с 6.12.
     
     6.14.2 Примитивы УСУ
     
     Данная процедура использует следующий примитив УСУ:
     
     С-СБРОС индикация.
     

     6.14.3 ПБДТ и используемые параметры
     
     Данная процедура использует следующие ПБДТ и параметры:
     
     a) ПБДТ: ЗС, ЗР, ПС и ПР;
     
     b) ПБДТ ОТК
     
     - НР-ОТВ;
     
     c) ПБДТ ДН
     
     - НР-ПБДТ;
     
     d) ПБДТ СД
     
     - НР-ПБДТ-СД;
     
     e) ПБДТ ПСД
     
     - НР-СПБДТ-ОТВ.
     
     6.14.4 Процедура
     
     Логический объект транспортного уровня, который уведомляется о выполнении примитива С-СБРОС, должен:
     
     a) если логический объект транспортного уровня является ответчиком, - выполнить процедуру пассивной повторной синхронизации (см. 6.14.4.2);
     
     b) если логический объект транспортного уровня решил не выполнять повторного прикрепления, - не выполнять никаких действий;
     
     с) в остальных случаях выполнить процедуру активной повторной синхронизации, описанную в 6.14.4.1, и, если выполнена процедура по 6.14.4.1b, ожидать следующего события следующим образом:
     
     - если в результате повторной синхронизации принят действительный ПБДТ, - прекратить отсчет тайм-аута ТПР либо
     
     - если ТПР истек, - ожидать следующего события, либо
     
     - если принят примитив С-СБРОС индикация, - выполнить процедуру по 6.14.4.
     
     6.14.4.1 Процедуры активной повторной синхронизации
     
     Логический объект транспортного уровня должен выполнить одно из следующих действий:
     
     a) если отсчет тайм-аута ТПР был начат и он истек (т.е. в процессе его отсчета не было получено ни одного действительного ПБДТ), использовать процедуры, определенные в 6.12.3а3);
     
     b) в противном случае должен быть начат отсчет тайм-аута ТПР (если он еще не отсчитывается) и должно быть выполнено первое приемлемое действие из перечисленных ниже:
     
     1) если ПБДТ ЗС не подтвержден, логический объект транспортного уровня должен передать его повторно;
     
     2) если ПБДТ ЗР не подтвержден, логический объект транспортного уровня должен передать его повторно;
     
     3) в остальных случаях логический объект транспортного уровня должен выполнить процедуры повторной синхронизации (см. 6.14.4.3).
     
     6.14.4.2 Процедуры пассивной повторной синхронизации
     

     До получения ПБДТ логический объект транспортного уровня не должен передавать никаких ПБДТ. Если отсчет ТОП еще не начат (поскольку получен примитив С-РАЗЪЕДИНЕНИЕ индикация или С-СБРОСиндикация), логический объект транспортного уровня должен начать его отсчет. Если ТОП истечет до приема действительного ПБДТ, начинающего повторную синхронизацию (т.е. ПБДТ ЗС, ЗР, СД или ОТК), СТУ считается разъединенным и указатель блокируется (см. 6.18).
     
     При приеме действительного ПБДТ логический объект транспортного уровня должен прекратить отсчет ТОП и выполнить в зависимости от типа ПБДТ одно из следующих действий:
     
     a) если принят ПБДТ ЗР, логический объект транспортного уровня должен передать ПБДТ ПР;
     
     b) если принят повторный ПБДТ ЗС (см. примечание 1), логический объект транспортного уровня должен выполнить соответствующее действие из следующего перечня:
     
     1) если ПБДТ ПС уже передан и подтвержден, - рассматривать это как протокольную ошибку;
     
     2) если ПБДТ ЗР не подтвержден (независимо от того, подтвержден или нет ПБДТ ПС), - повторно передать ПБДТ ЗР, установив указатель отправителя в ноль;
     
     3) если от пользователя еще не поступил примитив Т-СОЕДИНЕНИЕ ответ - не выполнять никаких действий;
     
     4) в остальных случаях передать (повторно передать) ПБДТ ПС с последующей повторной передачей любого неподтвержденного ПБДТ СД (см. примечание 2) и любых неподтвержденных ПБДТ ДН в зависимости от применимых процедур управления потоком.
     
     Примечания
     
     1 Повторяемый ПБДТ ЗС может быть обнаружен по его прохождению в ССУ с соответствующими сетевыми адресами и с правильным указателем отправителя.
     
     2 Логический объект транспортного уровня не должен использовать УСУ по передаче срочных данных до тех пор, пока не будет подтвержден ПБДТ ПС (см. 6.5). Это правило предотвращает возможность обгона ПБДТ ПС сетевыми срочными данными;
     
     
     c) если принят ПБДТ ОТК или СД, должно быть выполнено одно из следующих действий:
     
     1) если ПБДТ ЗР не подтвержден, логический объект транспортного уровня должен передать его повторно;
     
     2) если ПБДТ ПС не подтвержден, ПБДТ ОТК или СД должен рассматриваться как подтверждение ПБДТ ПС и логический объект транспортного уровня должен выполнить процедуры повторной синхронизации данных (6.14.4.3);
     

     3) в противном случае логический объект транспортного уровня должен выполнить процедуру повторной синхронизации данных (см. 6.14.4.3).
     
     6.14.4.3 Процедуры повторной синхронизации данных
     
     Логический объект транспортного уровня должен выполнить следующие действия в перечисляемой последовательности:
     
     a) (повторно) передать любой неподтвержденный ПБДТ СД;
     
     b) передать ПБДТ ОТК с полем НР-ОТВ, установленным в значение HP-ПБДТ следующего ожидаемого ПБДТ ДН;
     
     c) ожидать следующий ПБДТ от партнера, если еще не получен ПБДТ ОТК или ЗР. При получении ПБДТ ЗР логический объект транспортного уровня должен передать ПБДТ ПР, заблокировать указатель, проинформировать пользователя СТУ о разъединении и не выполнять никаких других действий (т.е. он не должен выполнять процедуры, описанные в 6.14.4.3d). При получении ПБДТ ОТК должна быть выполнена процедура по 6.14.4.3d. При получении ПБДТ СД должна быть выполнена процедура по 6.11. Если полученный ПБДТ СД является дубликатом, логический объект транспортного уровня должен подтвердить его передачей ПБДТ СД, аннулировать дубликат и снова ожидать следующего ПБДТ;
     
     d) (повторно) передать любые неподтвержденные ПБДТ ДН под управлением любой применимой процедуры управления потоком (см. примечание).
     
     Примечание - Блок ПБДТ ОТК может снизить кредит.
     
     
     6.15 Мультиплексирование и демультиплексирование при работе с УСУ-УС
     
     6.15.1 Назначение
     
     Процедуры мультиплексирования и демультиплексирования используются в классах 2-4 с целью обеспечения одновременного коллективного использования одного ССУ несколькими СТУ.
     
     6.15.2 Используемые ПБДТ и параметры
     
     Эта процедура использует следующие ПБДТ и параметры:
     
     ПБДТ: ПС, ЗР, ПР, ДН, ПД, СД, ПСД, ОТК и ОШ
     
     - УКАЗ-ПОЛ.
     
     6.15.3 Процедура
     
     Логические объекты транспортного уровня должны обладать способностью передавать и принимать по одному и тому же ССУ ПБДТ, принадлежащие различным СТУ.
     
     Примечания
     

     1 При использовании демультиплексирования СТУ, к которому относятся ПБДТ, определяется процедурами по 6.9.
     
     2 Мультиплексирование обеспечивает объединение ПБДТ, принадлежащих разным СТУ и подлежащих передаче в одном и том же примитиве С-ДАННЫЕ (см. 6.4).
     
     
     6.16 Явное управление потоком
     
     6.16.1 Назначение
     
     Процедура явного управления потоком используется в классах 2-4 для упорядочения потока ПБДТ ДН независимо от управления потоком на других уровнях.
     
     6.16.2 Используемые ПБДТ и параметры
     
     Эта процедура использует следующие ПБДТ и параметры:
     
     a) ПБДТ: ЗС, ПС, ПД и ОТК
     
     - КРД;
     
     b) ПБДТ ДН
     
     - НР-ПБДТ;
     
     c) ПБДТ ПД
     
     - НР-ОТВ,
     
     - порядковый номер,
     
     - подтверждение управление потоком;
     
     d) ПБДТ ОТК
     
     - НР-ОТВ.
     
     6.16.3 Процедура
     
     Разные классы имеют различные процедуры. Эти процедуры определены в разделах, описывающих соответствующие классы.
     
     6.17 Контрольная сумма
     
     6.17.1 Назначение
     
     Процедура вычисления контрольной суммы используется для обнаружения ПБДТ, искаженных поставщиком-УСУ.
     
     Примечание - Хотя алгоритмы вычисления контрольной суммы должны быть приспособлены к тем типам ошибок, которые ожидаются в ССУ, в настоящее время определен только один алгоритм.
     
     
     6.17.2 Используемые ПБДТ и параметры
     
     Эта процедура использует следующие ПБДТ и параметры:
     
     все ПБДТ
     
     - контрольная сумма.
     
     6.17.3 Процедура
     
     Контрольная сумма должна использоваться только в классе 4. Она всегда должна применяться к ПБДТ ЗС, а также ко всем другим ПБДТ, кроме случая, когда неиспользование этой процедуры было оговорено при установлении соединения.
     
     Передающий логический объект транспортного уровня должен передавать ПБДТ с установленным значением параметра "контрольная сумма", удовлетворяющим следующим выражениям:
     
      (по модулю 255);
     
      (по модулю 255),
     
где   - номер (т.е. позиция) октета в ПБДТ (см. 13.2);
     
      - значение октета в позиции ;
     
      - длина ПБДТ в октетах.
     
     Логический объект транспортного уровня, принимающий ПБДТ для СТУ, для которого было согласовано использование контрольной суммы, не удовлетворяющей вышеприведенным выражениям, должен аннулировать такой ПБДТ (см. также примечание 2).
     
     При получении ложного ПБДТ и необходимости выдачи на него ответа логический объект транспортного уровня должен:
     
     a) если он обеспечивает алгоритм вычисления контрольной суммы и принятый ПБДТ содержит параметр "контрольная сумма", включить параметр "контрольная сумма" в ответный ПБДТ либо
     
     b) во всех остальных случаях не включать параметр "контрольная сумма" в ответный ПБДТ.
     
     Логический объект, не обеспечивающий вычисление контрольной суммы, всегда может исходить из предположения, что ПБДТ ЗС с предложенным классом 4 правильный, а вследствие этого может согласовать снижение класса ниже 4-го.
     
     Примечания
     
     1 Эффективный алгоритм определения параметров контрольной суммы приведен в приложении В.
     
     2 Если контрольная сумма неверна, то невозможно достоверно определить, к какому СТУ относится данный ПБДТ; последующие действия могут быть предприняты для всех СТУ, прикрепленных к данному ССУ (см. 6.9.1 для УСУ-УС и 6.9.2 для УСУ-БУС).
     
     3 Предложенный метод вычисления контрольной суммы прост в реализации и не сильно усложняет изделие. Он не обнаруживает добавлений или потерь начальных и концевых нулей, а также перестановок некоторых октетов.
     
     4 При использовании УСУ-УС в случае приема ПБДТ по ССУ нельзя быть уверенным, что данное ССУ используется СТУ только класса 4, поскольку это может быть ПБДТ, выполняющий повторное прикрепление.
     
     Следовательно, единственный способ убедиться в этом состоит в следующем:
     
     a) если ССУ используется СТУ класса 0 или 1, контрольная сумма отсутствует;
     
     b) проанализировать код ПБДТ;
     
     c) определить длину фиксированной части;
     
     d) определить из ИД переменную часть;
     
     e) проанализировать параметры и при обнаружении параметра "контрольная сумма" проверить ее значение;
     
     f) если контрольная сумма неверна, исходить из предположения, что используется СТУ класса 4, и снизить класс;
     
     g) если контрольная сумма верна, логически увязать ПБДТ с СТУ; если СТУ использует контрольную сумму, она верна; в противном случае следует считать, что имеет место протокольная ошибка.
     
     
     6.18 Заблокированные указатели
     
     6.18.1 Назначение
     
     Эта процедура должна применяться для предотвращения повторного использования указателя, поскольку могут еще существовать ПБДТ, связанные с прежним использованием указателя.
     
     6.18.2 Процедура
     
     Если логический объект транспортного уровня определяет, что конкретное соединение разъединено, он блокирует указатель, назначенный этому соединению, в соответствии с процедурой данного класса. Будучи заблокированным, указатель не может быть использован повторно.
     
     Примечание - Необходимость процедуры блокирования указателя обусловлена тем, что повторная передача или неправильное упорядочение могут обусловить доставку ПБДТ, содержащего указатель, логическому объекту после того, как этот объект уже разъединил соединение, которому он назначил данный указатель. Например, повторная передача может возникнуть, когда данный класс предусматривает либо повторную синхронизацию (см. 6.14), либо повторную передачу по тайм-ауту (см. 6.19).
     
     
     6.18.2.1 Процедура для классов 0 и 2
     
     Настоящий стандарт не определяет процедур блокирования указателя для классов 0 и 2
     
     Примечание - Для совместимости с другими классами блокирование указателя может быть определено как частный вопрос.
     
     
     6.18.2.2 Процедура для классов 1 и 3
     
     Процедура блокирования указателя используется за исключением следующих случаев (см. примечание 1):
     
     a) когда логический объект транспортного уровня получает ПБДТ ПР в ответ на переданный им ПБДТ ЗР (см. примечание 2);
     
     b) когда логический объект транспортного уровня передает ПБДТ ЗР или ОШ в ответ на принятый им ПБДТ ЗС (см. примечание 3);
     
     c) когда логический объект транспортного уровня определяет, что соединение разъединено после истечения тайм-аута ТОП (см. примечание 4);
     
     d) когда логический объект транспортного уровня получает ПБДТ ЗР или ОШ в ответ на переданный им ПБДТ ЗС;
     
     e) когда указатель равен нулю.
     
     Период времени, в течение которого указатель остается заблокированным, должен превышать длительность тайм-аута ТОД.
     
     Примечания
     
     1 Однако даже в этих случаях в целях обеспечения совместимости блокирование указателей может быть частным вопросом.
     
     2 При получении ПБДТ ПР очевидно, что другой логический объект-партнер считает соединение разъединенным.
     
     3 При передаче ПБДТ ЗР или ОШ логический объект-партнер еще не проинформирован о присвоении указателя и потому, возможно, не сможет использовать его (сюда относится случай, когда ПБДТ ПС передан и потерян).
     
     4 В условиях подпункта с) логический объект транспортного уровня уже успешно заблокировал указатель на соответствующий период времени.
     
     
     6.18.2.3 Процедура для класса 4
     
     Процедура блокирования указателя должна использоваться в классе 4. Период нахождения указателя в заблокированном состоянии должен превышать значение (см. 12.2.1.1.6).
     
     6.19 Повторная передача по тайм-ауту
     
     6.19.1 Назначение
     
     Эта процедура используется в классе 4 для того, чтобы устранить последствия, связанные с потерей поставщиком УСУ ПБДТ, о которой не было сообщено.
     
     6.19.2 Используемые ПБДТ
     
     Данная процедура использует следующие ПБДТ:
     
     ПБДТ: ЗС, ПС, ЗР, ДН, СД, ПД.
     
     6.19.3 Процедура
     
     Данная процедура определена в процедурах класса 4 (см. 12.2.1.2j, g).
     
     6.20 Упорядочение
     
     6.20.1 Назначение
     
     Процедура упорядочения используется в классе 4, чтобы устранить нарушение последовательности ПБДТ, обусловленные поставщиком УСУ.
     
     6.20.2 Используемые ПБДТ и параметры
     
     Данная процедура использует следующие ПБДТ и параметры:
     
     a) ПБДТ ДН
     
     - НР-ПБДТ;
     
     b) ПБДТ СД
     
     - НР-ПБДТ-СД.
     
     6.20.3 Процедура
     
     Данная процедура определена в процедурах класса 4 (см. 12.2.3.5).
     
     6.21 Контроль неактивности
     
     6.21.1. Назначение
     
     Процедура контроля неактивности используется в классе 4, чтобы устранить последствия, связанные с непроинформированным завершением ССУ.
     
     6.21.2 Процедура
     
     Данная процедура определена в процедурах класса 4 (см. 12.2.3.3).
     
     6.22 Обработка протокольных ошибок
     
     6.22.1 Обработка протокольных ошибок при работе с УСУ-УС
     
     6.22.1.1 Назначение
     
     Процедура обработки протокольных ошибок используется во всех классах при получении недействительных ПБДТ.
     
     6.22.1.2 Используемые ПБДТ и параметры
     
     Данная процедура использует следующие ПБДТ и параметры:
     
     а) ПБДТ ОШ
     
     - причина отказа,
     
     - недействительный ПБДТ;
     
     b) ПБДТ ЗР
     
     - код причины.
     
     6.22.1.3 Процедура
     
     Логический объект транспортного уровня, принимающий ПБДТ, который может быть логически связан с СТУ и является недействительным или представляет собой протокольную ошибку (см. 3.2.16 и 3.2.17), должен выполнить одно из перечисленных ниже действий, но так, чтобы не подвергать риску другие СТУ, не прикрепленные к этому ССУ:
     
     а) передать ПБДТ ОШ;
     
     b) сбросить или закрыть ССУ;
     
     с) привлечь процедуры разъединения в соответствии с данным классом.
     
     В некоторых ситуациях разрешается также аннулировать ПБДТ.
     
     Если ПБДТ ОШ передан в классе 0, он должен содержать октеты недействительного ПБДТ вплоть до октета, в котором была обнаружена ошибка, включительно (см. примечания 3-5).
     
     Если ПБДТ не может быть логически привязан к конкретному СТУ, то логический объект транспортного уровня должен выполнять процедуры, приведенные в 6.9.
     
     Примечания
     
     1 В общем случае для получателя ПБДТ ОШ дальнейшие действия не определены, но рекомендуется, чтобы он инициировал процедуру разъединения соответственно данному классу. Если ПБДТ ОШ получен в ответ на ПБДТ ЗС, то соединение рассматривается разъединенным (см. 6.6).
     
     2 Логический объект транспортного уровня, получивший несколько недействительных ПБДТ либо ПБДТ ОШ, должен принять меры, чтобы избежать зацикливания, если ошибка генерируется неоднократно.
     
     3 Если длина полученного недействительного ПБДТ превышает выбранную максимальную длину ПБДТ, то может оказаться невозможным включение недействительного ПБДТ в параметр ПБДТ ОШ.
     
     4 Рекомендуется, чтобы отправитель ПБДТ ОШ начинал отсчет факультативного тайм-аута ТУ2, чтобы гарантировать разъединение соединения. При истечении тайм аута логический объект транспортного уровня должен инициировать процедуру разъединения соответственно данному классу. Отсчет тайм-аута должен быть прекращен при приеме ПБДТ ЗР или примитива С-РАЗЪЕДИНЕНИЕ индикация.
     
     5 Во всех классах, кроме классов 0, рекомендуется включать недействительные ПБДТ в состав ПБДТ ОШ.
     
     
     6.22.2 Обработка протокольных ошибок при работе с УСУ-БУС
     
     6.22.2.1 Назначение
     
     Данная процедура обработки протокольных ошибок используется применительно к недействительным ПБДТ.
     
     6.22.2.2 Используемые ПБДТ и параметры
     
     Данная процедура использует следующие ПБДТ и параметры:
     
     a) ПБДТ ОШ
     
     - причина отказа,
     
     - недействительный ПБДТ;
     
     b) ПБДТ ЗР
     
     - причина.
     
     6.22.2.3 Процедура
     
     Недействительные ПБДТ и протокольные ошибки следует игнорировать (не выполнять никаких действий и аннулировать ПБДТ или передавать в ответ ПБДТ ОШ) за исключением следующего случая: получен ПБДТ ПС, в котором поле класса не определяет класс 4, а ранее переданный ПБДТ ЗС еще не подтвержден. В этом случае СТУ должно быть завершено (см. 6.7).
     
     Примечание - Рекомендуется, чтобы передатчик ПБДТ ОШ начинал отсчет факультативного тайм-аута ТУ2, чтобы гарантировать освобождение соединения. При истечении тайм-аута логический объект транспортного уровня должен инициировать процедуру освобождения соединения, соответствующую классу 4. Отсчет тайм-аута должен быть прекращен при получении ПБДТ ЗР.
     
     
     6.23 Расщепление и рекомбинация при работе с УСУ-УС
     
     6.23.1 Назначение
     
     Эту процедуру применяют только в классе 4, чтобы позволить СТУ использовать несколько ССУ для обеспечения дополнительной устойчивости при отказе сети, увеличению пропускной способности или для других целей.
     
     6.23.2 Процедура
     
     При использовании этой процедуры СТУ может быть прикреплено (см. 6.1) к нескольким ССУ (см. примечание 1). ПБДТ данного СТУ могут быть переданы по любому из прикрепленных ССУ.
     
     Если в соответствии с правилами согласования использование класса 4 не принято удаленным логическим объектом транспортного уровня, то ни одно ССУ, кроме того, по которому был передан ПБДТ ЗС, не может быть прикреплено к данному СТУ.
     
     Примечания
     
     1 Функция упорядочения в классе 4 (см. 6.20) используется для того, чтобы гарантировать обработку ПБДТ в правильной последовательности.
     
     2 Любой логический объект транспортного уровня может прикрепить СТУ и к другим ССУ, владельцем которых он является, в любое время в течение всего периода существования СТУ при соблюдении следующих ограничений:
     
     - инициатор не начинает расщепления до получения ПБДТ ПС;
     
     - как только выполнено новое прикрепление, рекомендуется передать ПБДТ по этому ССУ для информирования удаленного логического объекта об этом прикреплении.
     
     3 Логический объект транспортного уровня, выполняющий расщепление, должен обеспечить периодичность передачи ПБДТ по каждому созданному ССУ, например, посылая последовательные ПБДТ последовательно по всем ССУ из набора с циклическим их обходом.
     
     При использовании расщепления процедура управления неактивностью, определенная в 12.2.3.3, не сможет обычно обнаружить неуведомленные неисправности ССУ. Выбор метода управления ССУ для обнаружения таких неисправностей является частным вопросом.
     

     7 Классы протокола

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

     
     при наличии следующих ограничений:
     
     1) ПБДТ ЗС и ПС не должны содержать никаких полей параметров в переменной части заголовка кроме полей ИД-ПДУТУ, максимального размера ПБДТ и предпочтительного максимального размера ПБДТ;
     
     2) ПБДТ ЗС и ПС не должны содержать поля данных.
     
     

     8 Спецификация класса 0. Простой класс

     
     8.1 Функции класса 0
     
     Класс 0 обладает минимальными функциональными возможностями. Он предусматривает только те функции, которые необходимы для установления соединения с выполнением процедур согласования, передачу данных с сегментированием и отчетность о протокольных ошибках.
     
     В классе 0 СТУ обеспечивается управлением по потоку на основе управления потоком, создаваемом УСУ, а также процедурой разъединения на основе УСУ "разъединение"
     
     8.2 Процедуры класса 0
     
     8.2.1 Процедуры, применимые для всех случаев
     
     Логические объекты транспортного уровня должны использовать следующие процедуры:
     
     a) передачу ПБДТ (см. 6.2);
     
     b) логическую привязку ПБДТ к СТУ (см. 6.9);
     
     c) обработку протокольных ошибок (см. 6.22);
     
     d) разъединение по ошибке (см. 6.8).
     
     8.2.2 Установление соединения
     
     Логические объекты транспортного уровня должны использовать следующие процедуры:
     
     а) прикрепление к ССУ (см. 6.1), после чего
     
     b) установить соединения (см. 6.5) и в соответствующих случаях - отклонение соединения (см. 6.6)
     
     8.2.3 Передача данных
     
     Логические объекты транспортного уровня должны использовать процедуру сегментирования и сборки (см. 6.3).
     
     8.2.4 Разъединение
     
     Логические объекты транспортного уровня должны использовать неявный вариант процедуры нормального разъединения (см. 6.7).
     
     Примечание - Время существования СТУ непосредственно связано с временем существования ССУ.
     

     9 Спецификация класса 1. Основной класс с восстановлением при ошибках

     
     9.1 Функции класса 1
     
     В классе 1 СТУ обеспечивается управлением по потоку на основе управления потоком, создаваемом УСУ, процедурами восстановления при ошибках, передачи срочных данных, разъединения, а также возможностью поддерживать последовательные СТУ в ССУ.
     
     Этот класс обеспечивает функциональные возможности класса 0 плюс возможность восстановления при ошибках, сообщаемых УСУ, без участия пользователя УТУ.
     
     9.2 Процедуры класса 1.
     
     9.2.1 Процедуры, применимые для всех случаев
     
     Логические объекты транспортного уровня должны использовать следующие процедуры:
     
     a) передачу ПБДТ (см. 6.2);
     
     b) логическую привязку ПБДТ к СТУ (см. 6.9);
     
     c) обработку протокольных ошибок (см. 6.22);
     
     d) повторное прикрепление после отказа (см. 6.12);
     
     e) повторную синхронизацию (см. 6.14) или повторное прикрепление после отказа (см. 6.12) одновременно с повторной синхронизацией (см. 6.14);
     
     f) сцепление и разделение (см. 6.4);
     
     g) хранение ПБДТ до их подтверждения (см. 6.13); используемый вариант (ПД или уведомление о приеме) должен соответствовать варианту, выбранному при установлении соединения (см. примечания);
     
     h) блокирование указателей (см. 6.13).
     
     Примечания
     
     1 Процедура согласования конкретного варианта хранения ПБДТ до получения подтверждения, подлежащая использованию в СТУ, предусмотрена такой, что если инициатор предлагает использовать вариант ПД (т.е. обязательное использование факультативной функции), то ответчик должен принять этот вариант, а если инициатор предлагает использовать уведомление о приеме, ответчик может выбрать использование варианта ПД.
     
     2 В варианте ПД для аннулирования копий, хранимых ПБДТ ДН, используется ПБДТ ПД. Параметр КРД в ПБДТ ПД в классе 1 не является значимым и устанавливается в значение 1111.
     
     3 Вариант уведомления о приеме используется только в этом классе и его использование зависит от доступности услуги уведомления о приеме на сетевом уровне и от ожидаемого снижения стоимости.
     
     
     9.2.2 Установление соединения
     
     Логические объекты транспортного уровня должны использовать следующие процедуры:
     
     a) прикрепление к ССУ (см. 6.1.1), после чего
     
     b) установление соединения (см. 6.5) и в соответствующих случаях - отказ от соединения (см. 6.6).
     
     9.2.3 Передача данных
     
     9.2.3.1 Общие положения
     
     Передающий логический объект транспортного уровня должен использовать следующие процедуры:
     
     а) сегментирование (см. 6.3), после чего
     
     b) вариант нормальных форматов нумерации ПБДТ ДН (см. 6.10).
     
     Принимающий логический объект транспортного уровня должен использовать следующие процедуры:
     
     1) вариант нормальных форматов нумерации ПБДТ (см. 6.10), после чего.
     
     2) сборка (см. 6.3).
     
     Примечание - Решение о выдаче примитива С-СБРОС запрос для того, чтобы побудить удаленный логический объект выполнить повторную синхронизацию (см. 6.14), может быть принято локально.
     
     
     9.2.3.2 Срочные данные
     
     Логические объекты транспортного уровня должны использовать либо сетевой нормальный вариант данных, либо сетевой срочный вариант процедуры срочной передачи данных (см. 6.11), если их использование было выбрано при установлении соединения (см. примечание 1).
     
     Передающий логический объект транспортного уровня не должен назначать один и тот же НР-ПБДТ-СД последовательно передаваемым ПБДТ СД (см. примечания 2 и 3).
     
     Выполняя подтверждение ПБДТ СД посредством ПБДТ ПСД, логический объект транспортного уровня должен поместить в поле параметра НР-СПБДТ-ОТВ блока ПБДТ СПД значение, полученное им в поле параметра НР-ПБДТ-СД блока ПБДТ СД.
     
     Примечания
     
     1 Согласование варианта процедуры срочной передачи данных, которая должна быть использована в СТУ, предусмотрено таким образом, что если инициатор предлагает использовать сетевой вариант нормальных данных (т.е. обязательное использование факультативной функции), то ответчик должен принять к исполнению этот вариант. Если же инициатор предлагает использовать сетевой срочный вариант, то ответчик имеет право выбрать сетевой вариант нормальных данных.
     
     2 Такой метод нумерации позволяет принимающему логическому объекту транспортного уровня аннулировать дублирование в ходе повторной синхронизации ПБДТ СД (см. 6.14).
     
     3 Никакого другого значения параметру НР-ПБДТ-СД не придается. Рекомендуется (но не обязательно) нумерацию осуществлять последовательно по модулю 128.
     
     4 Использование ПБДТ ОТК при выполнении повторной синхронизации (см. 6.14) может привести к повторной передаче. Таким образом, возможно получение дубликата ПБДТ СД. Подобные ПБДТ СД аннулируются.
     
     
     9.2.4 Разъединение
     
     Логические объекты транспортного уровня должны использовать явный вариант процедуры разъединения (см. 6.7).
     

     10 Спецификация класса 2. Класс с мультиплексированием

     
     10.1 Функции класса 2
     
     В классе 2 СТУ может обеспечиваться либо не обеспечиваться средством индивидуального управления потоком, однако обнаружение ошибок и восстановление при ошибках в нем не предусмотрено.
     
     Если ССУ сбрасывается в исходное состояние или разъединяется, то СТУ завершается без использования процедуры разъединения СТУ с информированием пользователя УТУ.
     
     При использовании явного управления потоком определяется механизм кредита, позволяющий получателю информировать отправителя о точном объеме данных, которые он может принять, и о возможности срочной передачи данных.
     
     10.2 Процедуры класса 2
     
     10.2.1 Процедуры, применимые во всех случаях
     
     Логические объекты транспортного уровня должны использовать следующие процедуры:
     
     a) логическую привязку ПБДТ к СТУ (см. 6.9);
     
     b) передачу ПБДТ (см. 6.2);
     
     c) обработку протокольных ошибок (см. 6.22);
     
     d) сцепление и разделение (см. 6.4);
     
     e) разъединение по ошибке (см. 6.8).
     
     Кроме того, логические объекты транспортного уровня могут использовать следующую процедуру:
     
     f) мультиплексирование и демультиплексирование (см. 6.15).
     
     10.2.2 Установление соединения
     
     Логические объекты транспортного уровня должны использовать следующие процедуры:
     
     a) прикрепление к ССУ (см. 6.1), после чего
     
     b) установление соединения (см. 6.5) и в соответствующих случаях - отказ от соединения (см. 6.6).
     
     10.2.3 Передача данных при выборе варианта с использованием явного управления потоком
     
     Если при установлении соединения был выбран этот вариант, то логические объекты транспортного уровня должны использовать процедуру сегментирования (см. 6.3).
     
     Поле НР-ПБДТ в ПБДТ ДН не является значащим и может принимать любое значение.
     
     Примечание - Передача срочных данных здесь неприменима (см. 6.5).
     
     
     10.2.4 Передача данных при выборе варианта с использованием явного управления потоком
     
     10.2.4.1 Общие положения
     
     Передающий логический объект транспортного уровня должен использовать следующие процедуры:
     
     a) сегментирование (см. 6.3), после чего
     
     b) нумерацию ПБДТ ДН (см. 6.10).
     
     Принимающий логический объект транспортного уровня должен использовать следующие процедуры:
     
     1) нумерацию ПБДТ ДН (см. 6.10); поступление ПБДТ ДН с нарушением последовательности он должен рассматривать как протокольную ошибку;
     
     2) сборку (см. 6.3).
     
     Оба логических объекта транспортного уровня должны использовать тот вариант нумерации ПБДТ ДН, который был согласован при установлении соединения.
     
     10.2.4.2 Управление потоком
     
     Логические объекты транспортного уровня должны передавать начальный кредит (который может быть нулевым) в поле КРД блока ПБДТ ЗС или ПС. Этот кредит представляет собой начальное значение верхней границы окна, назначенной равноправному логическому объекту.
     
     Логический объект транспортного уровня, принимающий ПБДТ ЗС или ПС, должен рассматривать нижнюю границу своего окна, равной нулю, а его верхнюю границу как значение поля КРД в принятом ПБДТ.
     
     Для санкционирования передачи ПБДТ ДН объектом-партнером логический объект транспортного уровня в любой момент может передать ПБДТ ПД с учетом следующих ограничений:
     
     a) поле параметра НР-ОТВ не должно превышать поле НР-ПБДТ в последнем полученном ПБДТ ДН больше, чем на единицу или должно быть нулевым, если не было получено ни одного ПБДТ ДН;
     
     b) если ранее был передан ПБДТ ПД, то значение параметра НР-ОТВ не должно быть меньше, чем в этом ранее переданном ПБДТ ПД;
     
     c) сумма полей НР-ОТВ и КРД не должна быть меньше верхней границы окна, выделенного логическому объекту (см. примечание 1).
     
     Логический объект транспортного уровня, принимающий ПБДТ ПД, должен рассматривать поле НР-ОТВ как свою новую нижнюю границу окна, а сумму НР-ОТВ и КРД как свою новую верхнюю границу окна. Если какое-либо из этих полей уменьшилось, либо если нижняя граница окна больше чем на единицу превысила НР-ПБДТ последнего переданного ПБДТ ДН, он должен рассматривать это как протокольную ошибку (см. 6.22.1).
     
     Логический объект транспортного уровня не должен передавать ПБДТ с НР-ПБДТ вне границы окна передачи (см. примечания 2 и 3).
     
     Примечания
     
     1 Это означает, что уменьшение кредита не используется.
     
     2 Это означает, что логический объект транспортного уровня должен прекратить передачу, если поле НР-ПБДТ следующего подлежащего передаче ПБДТ ДН будет соответствовать верхней границе окна. Передача ПБДТ ДН может быть возобновлена, если принят ПБДТ ПД, который превысил верхнюю границу окна.
     
     3 Частота, с которой логический объект транспортного уровня превышает верхнюю границу окна, назначенную для его равноправного объекта, ограничивает пропускную способность, достижимую в данном СТУ.
     
     
     10.2.4.3 Срочные данные
     
     Логические объекты транспортного уровня должны выполнять сетевой вариант нормальных данных процедуры срочной передачи данных (см. 6.11), если его использование было согласовано во время установления соединения. ПБДТ СД и ПСД не являются объектами управления по потоку, определенным в 10.2.4.2. Поля НР-ПБДТ-СД и НР-СПБДТ-ОТВ блоков данных ПБДТ СД и ПСД соответственно не являются значащими и могут принимать любые значения.
     
     10.2.5 Разъединение
     
     Логические объекты транспортного уровня должны использовать явный вариант процедуры разъединения согласно 6.7.1.
     

     11 Спецификация класса 3. Класс с восстановлением при ошибках и с мультиплексированием

     
     11.1 Функции класса 3
     
     Класс 3 обеспечивает функциональные возможности класса 2 (с использованием явного управления потоком) плюс возможность восстановления после отказов, о которых сообщает сетевой уровень, без участия пользователя УТУ.
     
     Механизмы, используемые для достижения этих функциональных возможностей, позволяют, кроме того, реализовать более гибкое управление потоком.
     
     11.2 Процедуры класса З
     
     11.2.1 Процедуры, применимые во всех случаях
     
     Логические объекты транспортного уровня должны использовать следующие процедуры:
     
     a) логическую привязку ПБДТ к СТУ (см. 6.9);
     
     b) передачу ПБДТ (см. 6.2) и хранение до получения подтверждения ПБДТ (только вариант ПД) (см. 6.13);
     
     c) обработку протокольных ошибок (см. 6.22.1);
     
     d) сцепление и разделение (см. 6.4);
     
     e) повторное прикрепление после отказа (см. 6.12) вместе с повторной синхронизацией (см. 6.14);
     
     f) блокирование указателя (см. 6.18);
     
     Кроме того, логические объекты транспортного уровня могут использовать следующую процедуру:
     
     g) мультиплексирование и демультиплексирование (см. 6.15).
     
     11.2.2 Установление соединения
     
     Логические объекты транспортного уровня должны использовать следующие процедуры:
     
     a) прикрепление к ССУ (см. 6.1.1), затем
     
     b) установление соединения (см. 6.5) и в соответствующих случаях - отказ от соединения (см. 6.6).
     
     11.2.3 Передача данных
     
     11.2.3.1 Общие положения
     
     Передающий логический объект транспортного уровня должен использовать следующие процедуры:
     
     a) сегментирование (см. 6.3), затем
     
     b) нумерацию ПБДТ ДН (см. 6.10); после приема ПБДТ ОТК (см. 11.2.3.2) следующий подлежащий передаче ПБДТ ДН может принимать значение, не равное предыдущему значению НР-ПБДТ плюс единица.
     
     Принимающий логический объект транспортного уровня должен использовать следующие процедуры:
     
     1) нумерацию ПБДТ ДН (см. 6.10); поле НР-ПБДТ каждого принятого ПБДТ ДН должно рассматриваться как протокольная ошибка, если оно превышает наибольшее значение поля ранее принятых ПБДТ ДН более чем на единицу (см. примечание), затем
     
     2) сборку (см. 6.3); ПБДТ-дубликаты должны быть аннулированы до выполнения сборки.
     
     Примечание - Использование ПБДТ ОТК (см. 11.2.3.2) может привести к повторной передаче и уменьшению кредита. Таким образом, здесь возможно получение ПБДТ-дубликата либо ПБДТ, большего или равного верхней границе окна, назначенной равноправному логическому объекту, и поэтому получение такого ПБДТ не рассматривается как протокольная ошибка.
     
     11.2.3.2 Использование ПБДТ ОТК
     
     Логический объект транспортного уровня может в любой момент передать ПБДТ ОТК с целью инициирования повторной передачи или снижения верхней границы окна, назначенной равноправному логическому объекту (см. примечание 1).
     
     При передаче ПБДТ ОТК должны соблюдаться следующие ограничения:
     
     а) параметр НР-ОТВ не должен превышать более чем на единицу наибольшее значение НР-ОТВ, принятое в предыдущем ПБДТ ДН, или должен быть равен 0, если ПБДТ ДН еще не получен (см. примечание 2);
     
     b) если ПБДТ ПД или ОТК были переданы ранее, то параметр НР-ОТВ не должен быть меньше значения этого параметра в предыдущем ПБДТ ПД или ОТК.
     
     Если логический объект транспортного уровня получает ПБДТ ОТК (см. примечание 3), то
     
     с) следующим подлежащим передаче (в том числе повторной) ПБДТ ДН должен быть тот ПБДТ ДН, для которого значение параметра НР-ПБДТ равно значению этого параметра в ПБДТ ОТК;
     
     d) сумма значений параметров НР-ПБДТ и КРД в ПБДТ ОТК становится новой верхней границей окна (см. примечание 4).
     
     Примечания
     
     1 Передача ПБДТ ОТК может выполняться также как часть процедуры повторной синхронизации (см. 6.14) или повторного прикрепления после отказа (см. 6.12).
     
     2 Рекомендуется, чтобы параметр НР-ОТВ был равен параметру НР-ПБДТ следующего ПБДТ ДН.
     
     3 Эти правила являются подмножеством правил, определенных для ситуации, когда ПБДТ ОТК получен при выполнении процедуры повторной синхронизации (см. 6.14) или повторного прикрепления после отказа (см. 6.12).
     
     4 Это означает, что ПБДТ ОТК может быть использован для снижения верхней границы окна, назначенной равноправному логическому объекту (уменьшение кредита).
     
     
     11.2.3.3 Управление потоком
     
     Эти процедуры должны соответствовать процедурам, определенным в 10.2.4.2, за исключением:
     
     a) уменьшение кредита может привести к получению ПБДТ ДН с параметром НР-ПБДТ, значение которого не меньше, но могло быть меньше верхней границы окна, назначенной удаленному логическому объекту перед уменьшением кредита. Такая ситуация не должна рассматриваться как протокольная ошибка.
     
     b) получение ПБДТ ПД, который устанавливает нижнюю границу окна на единицу большую НР-ПБДТ последнего переданного ПБДТ ДН, не должно рассматриваться как протокольная ошибка при условии, что все ранее переданные ПБДТ ДН подтверждены (см. примечания).
     
     Примечания
     
     1 Это может иметь место только во время повторной передачи, следующей за получением ПБДТ ОТК.
     
     2 Логический объект транспортного уровня может либо по-прежнему продолжать повторную передачу, либо передать повторно только те ПБДТ ДН, которые не подтверждены ПБДТ ПД. В любом случае не обязательно сохранять копии подтвержденных ПБДТ ДН.
     
     
     11.2.3.4 Срочные данные
     
     Логические объекты транспортного уровня должны использовать сетевой нормальный вариант данных процедуры срочной передачи данных (см. 6.11.1), если использование этого варианта было согласовано при установлении соединения.
     
     Передаваемый логический объект транспортного уровня не должен присваивать один и тот же номер НР-ПБДТ-СД последовательно передаваемым ПБДТ СД.
     
     Принимающий логический объект транспортного уровня должен передать ПБДТ ПСД с тем же значением параметра НР-ПБДТ-СД. Только в том случае, если этот номер отличается от номера предыдущего принятого ПБДТ СД, он должен сгенерировать примитив Т-СРОЧНЫЕ-ДАННЫЕ индикация для передачи данных пользователя УТУ (см. примечание 2).
     
     Примечания
     
     1 Никакого другого смысла параметр НР-ПБДТ-СД не имеет. Рекомендуется, но не обязательно, присваивать значения последовательно по модулю 2, где  - число бит в данном параметре.
     
     2 Эта процедура гарантирует, что пользователь УТУ не будет получать данные, соответствующие одному и тому же ПБД СД более одного раза.
     
     
     11.2.4 Разъединение
     
     Логические объекты транспортного уровня должны использовать явный вариант процедуры разъединения (см. 6.7).
     

     12 Спецификация класса 4. Класс с обнаружением ошибок и с восстановлением

     
     12.1 Функции класса 4
     
     12.1.1. Функции класса 4 при работе с УСУ-УС
     
     Протокол класса 4 обеспечивает функциональные возможности класса 3 плюс возможности обнаружения и восстановления при таких ошибках, как потеря, дублирование или нарушение последовательности ПБДТ без участия пользователя УТУ.
     
     Обнаружение ошибок осуществляется путем использования расширенной нумерации ПБДТ ДН классов 2 и 3, механизмов тайм-аута и дополнительных процедур.
     
     Протокол класса 4 обеспечивает обнаружение сообщаемых и несообщаемых сетевых неисправностей (т.е. отказы, разъединения или неактивности) и восстановления сети при этих неисправностях путем использования механизмов тайм-аута.
     
     Протокол этого класса обеспечивает обнаружение и восстановление искаженных ПБДТ путем использования механизма контрольной суммы. Этот механизм должен обеспечиваться всегда, а его использование или неиспользование подлежит согласованию.
     
     Кроме того, протокол этого класса обеспечивает дополнительную устойчивость от сетевых отказов, а также возможность повышения пропускной способности за счет того, что одному СТУ разрешается использовать несколько ССУ.
     
     12.1.2 Функции класса 4 при работе с УСУ-БУС
     
     Класс 4 обеспечивает управление потоком между равноправными логическими объектами, обнаружение ошибок и восстановление при ошибках, которые появляются в результате низкого качества услуг, получаемых от поставщика УСУ, и устойчивость к неисправностям равноправного логического объекта. К видам обнаруживаемых ошибок относятся: потеря ПБДТ, неупорядоченная доставка ПБДТ, дублирование ПБДТ и искажение ПБДТ - эти ошибки могут воздействовать как на управляющие, так и на информационные ПБДТ.
     
     Обнаружение ошибок осуществляется путем нумерации ПБДТ ДН, механизмов тайм-аутов и дополнительных процедур типа механизма контрольной суммы. Механизм контрольной суммы должен обеспечиваться, однако его использование или неиспользование является предметом согласования.
     
     12.2 Процедуры класса 4
     
     12.2.1 Процедуры, используемые во всех случаях
     

     12.2.1.1 Тайм-ауты, используемые во всеx случаях
     
     В данном подразделе определены тайм-ауты, применимые в процедурах класса 4 во всех случаях. Перечень этих тайм-аутов приведен в таблице 7.
     
     
Таблица 7 - Параметры, относящиеся к операциям класса 4
     

     
     
     Настоящий стандарт не определяет точных значений тайм-аутов, поэтому приведенные в данном подразделе их допуски не являются обязательными. Эти значения должны выбираться таким образом, чтобы обеспечить требуемое качество услуг при известных характеристиках сети.
     
     Тайм-ауты, применимые только в конкретных процедурах, определены при рассмотрении соответствующих процедур.
     
     12.2.1.1.1 Время существования СБДС (, )
     
     Предполагается, что сетевой уровень должен обеспечить в качестве элемента обслуживания предел максимального времени существования СБДС в сети. Значения этого времени могут быть различными в каждом направлении передачи по сети между двумя логическими объектами транспортного уровня. Предполагается, что эти значения для обоих направлений передачи известны обоим объектам. Максимальное время существования СБДС в направлении от локального к удаленному () - это максимально возможное время между передачей СБДС от локального логического объекта транспортного уровня в сеть и получением любой копии СБДС из сети удаленным логическим объектом транспортного уровня. Максимальное время существования СБДС в направлении от удаленного к локальному () - это максимально возможное время между передачей СБДС от удаленного логического объекта транспортного уровня в сеть и получением любой копии СБДС из сети локальным логическим объектом транспортного уровня.
     
     12.2.1.1.2 Ожидаемое значение максимальной транзитной задержки (, )
     
     Предполагается, что сетевой уровень должен обеспечивать в сети в качестве элемента обслуживания ожидаемое значение максимальной транзитной задержки СБДС. Это значение может быть различным в каждом направлении передачи по сети между двумя логическими объектами транспортного уровня. Предполагается, что значения этой задержки для обоих направлений передачи должны быть известны логическим объектам транспортного уровня. Ожидаемое значение максимальной транзитной задержки от локального к удаленному () - это максимальная задержка, с которой все (кроме небольшой части) СБДС передаются через сеть от локального логического объекта транспортного уровня к удаленному. Ожидаемое значение максимальной задержки от удаленного к локальному () - это максимальная задержка, с которой все (кроме небольшой части) СБДС передаются через сеть от удаленного логического объекта транспортного уровня к локальному.
     
     12.2.1.1.3 Время подтверждения (, )
     
     Предполагается, что любой логический объект транспортного уровня налагает ограничение на максимальный промежуток времени между получением им ПБДТ из сетевого уровня и передачей соответствующего ответа. Это предельное значение обозначается . Соответствующее время для удаленного логического объекта транспортного уровня обозначается .
     
     12.2.1.1.4 Время локальной повторной передачи ()
     
     Предполагается, что локальный логический объект транспортного уровня будет обеспечивать предельное время ожидания подтверждения до начала повторной передачи ПБДТ. Его значение определяется следующим образом:
     
     ,
     
где - ожидаемое значение максимальной транзитной задержки в направлении от локального объекта к удаленному;
     
      - ожидаемое значение максимальной транзитной задержки в направлении от удаленного объекта к локальному;
     
      - время удаленного подтверждения;
     
      - время локальной обработки ПБДТ.
     
     Примечание - Во время установления соединения значение  неизвестно. В этом случае подходящий предел для  может быть установлен либо путем оценки (или на основе априорных знаний) , либо путем применения подходящего алгоритма к параметру КУ "Задержка установления соединения транспортного уровня".
     
     
     12.2.1.1.5 Время продолжительности повторных передач ()
     
     Предполагается, что локальный логический объект транспортного уровня устанавливает предельное значение максимального времени, в течение которого он может продолжать повторные передачи ПБДТ, требующих положительного подтверждения, и которое не выходит за рамки текущего окна передачи после снижения кредита. Эта величина обозначается .
     
     Данная величина явно связана с интервалом времени между повторными передачами, значением  и максимальным числом повторных передач . Она не меньше, чем , где  - малая величина, учитывающая дополнительные внутренние задержки, дискретность механизма, используемого для реализации  и др. Так как  представляет собой предельное значение, то точное значение  несущественно постольку, поскольку оно ограничено и граничное значение известно.
     
     12.2.1.1.6 Временные пределы указателей и порядковых номеров
     
     Предельное значение максимального времени между решением о передаче ПБДТ и получением любого относящегося к нему подтверждения  определяется следующим выражением:
     
     ,
     
где  - время существования СБДС в направлении от локального объекта к удаленному;
     
      - время существования СБДС в направлении от удаленного объекта к локальному;
     
      - время продолжительности повторных передач;
     
      - время удаленного подтверждения.
     
     Требуется некоторый период ожидания до повторного использования какого-либо указателя или порядкового номера во избежание путаницы в случае дублирования или задержки соответствующего ПБДТ.
     
     Интервал времени, в течение которого порядковые номера ПБДТ ДН должны быть заблокированы, это период , отсчитываемый от того момента, когда порядковый номер оказался ниже границы окна.
     
     Примечания
     
     1 На практике значение  может оказаться слишком большим. Кроме того оно может быть лишь статистической величиной с определенной степенью достоверности. Поэтому может быть использовано меньшее значение, если оно продолжает обеспечивать требуемое качество услуг.
     
     2 Взаимоотношения между рассмотренными выше временами показаны на рисунках 3 и 4.
     

Рисунок 3 - Взаимоотношения времен для усредненного случая в классе 4

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

     
     12.2.1.1.7 Тайм-аут неактивности (, )
     
     Предполагается, что любой логический объект транспортного уровня должен обеспечивать нижнее предельное значение времени, которое может пройти без получения ПБДТ, прежде чем он сможет инициировать процедуру разъединения для завершения СТУ. Его значение обозначается . Соответствующее время, предоставляемое удаленным логическим объектом транспортного уровня, обозначается .
     
     12.2.1.2 Общие процедуры при работе с УСУ-УС
     
     Логический объект транспортного уровня должен обеспечивать следующие процедуры:
     
     a) передачу ПБДТ (см. 6.2);
     
     b) логическую привязку ПБДТ к СТУ (см. 6.9.1);
     
     c) обработку протокольных ошибок (см. 6.22.1);
     
     d) вычисление и проверку контрольной суммы (см. 6.17);
     
     e) расщепление и рекомбинацию (см. 6.23);
     
     f) мультиплексирование и демультиплексирование (см. 6.15);
     
     g) хранение ПБДТ до их подтверждения (см. 6.13);
     
     h) блокирование указателей (см. 6.18);
     
     j) повторные передачи; если логический объект транспортного уровня не получил подтверждения на некоторые ПБДТ, он должен проверить, не истек ли тайм-аут , до получения ПБДТ, подтверждающего хотя бы один из неподтвержденных ПБДТ. Если тайм-аут истек, то осуществляется повторная передача первого ПБДТ и начинается повторный отсчет тайм-аута , кроме случая, когда повторно передаваемым ПБДТ является ПБДТ ДН и он находится вне окна передачи вследствие снижения кредита. Повторная передача ПБДТ зависит от доступности ССУ. Если нет одного ССУ и тайм-аут повторной передачи истек, значение счетчика повторной передачи может возрасти без передачи ПБДТ в зависимости от процедуры повторной передачи. После выполнения  передач (т.е.  повторных передач) считается, что эффективный двусторонний обмен данными далее невозможен, в связи с чем выполняется процедура разъединения, о чем информируется пользователь УТУ.
     
     Примечания
     
     1 Эта процедура может быть реализована различными способами, например:
     
     a) с каждым ПБДТ логически связывается один временной интервал. Если тайм-аут истек, должен быть передан соответствующий ПБДТ и начат повторный отсчет тайм-аута  для всех последующих ПБДТ, или
     
     b) временной интервал логически связывается с каждым СТУ:
     
     1) если логический объект транспортного уровня передает ПБДТ, требующий подтверждения, он начинает отсчет тайм-аута ;
     
     2) если логический объект транспортного уровня получает ПБДТ, который подтверждает один из требующих подтверждения ПБДТ, он повторно начинает отсчет тайм-аута , если только принятый ПБДТ не является ПБДТ ПД, который явно закрывает окно передачи;
     
     3) если логический объект транспортного уровня получает ПБДТ, подтверждающий последний из требующих подтверждения, он прекращает отсчет тайм-аута .
     
     При решении вопроса о способе обеспечения тайм-аута повторной передачи  - для каждого ПБДТ или для каждого СТУ, следует учитывать фактор пропускной способности.
     
     2 Вопрос о повторной передаче только первого ПБДТ ДН либо всех ожидающих подтверждения ПБДТ ДН вплоть до верхней границы окна решается локально.
     
     3 Рекомендуется, чтобы после  передач логический объект транспортного уровня находился в состоянии ожидания в течение периода времени, равного , чтобы обеспечить максимальную вероятность получения подтверждения до входа в фазу разъединения соединения. Для других типов ПБДТ, которые могут передаваться повторно, рекомендуется, чтобы после  передач логический объект транспортного уровня ожидал в течение времени, равного , с целью обеспечения максимальной вероятности получения ожидаемого ответа.
     
     4 Если использование избирательного подтверждения согласовано, то избирательное подтверждение косвенно идентифицирует неполученные ПБДТ ДН. Поскольку подобные ПБДТ ДН могут быть потерянными ПБДТ ДН или просто задержанными ПБДТ ДН, то вопрос о необходимости немедленной повторной передачи неподтвержденных ПБДТ ДН является частным.
     
     k) сцепление и разделение (см. 6.4).
     
     12.2.1.3 Общие процедуры при работе с УСУ-БУС
     
     Логический объект транспортного уровня использует следующие процедуры:
     
     a) передачу ПБДТ (см. 6.2);
     
     b) логическую привязку ПБДТ к СТУ (см. 6.9.1);
     
     c) обработку протокольных ошибок (см. 6.22.2);
     
     d) вычисление и проверку контрольной суммы (см. 6.17);
     
     e) хранение ПБДТ до их подтверждения (см. 6.13);
     
     f) блокирование указателей (см. 6.18);
     
     g) процедуры повторной передачи: если логический объект транспортного уровня не получил требуемого подтверждения на некоторые ПБДТ, он должен проверить, не истек ли тайм-аут  до получения ПБДТ, подтверждающего хотя бы один из неподтвержденных ПБДТ.
     
     При истечении тайм-аута осуществляется повторная передача первого ПБДТ и начинается повторный отсчет тайм-аута , кроме случая, когда повторно передаваемым ПБДТ является ПБДТ ДН и он находится вне окна передачи вследствие снижения кредита. После осуществления  передачи (т.е.  повторных передач) считается, что эффективный двусторонний обмен данными далее невозможен, в связи с чем выполняется процедура разъединения, о чем информируется пользователь УТУ.
     
     Примечания
     
     1 Эта процедура может быть реализована различными способами, например:
     
     a) с каждым ПБДТ логически связывается один временной интервал. Если заданный тайм-аут истек, соответствующий ПБДТ должен быть передан и начат повторный отсчет тайм-аута  для всех последующих ПБДТ или
     
     b) временной интервал логически связывается с каждым СТУ:
     
     1) если логический объект транспортного уровня передает ПБДТ, требующий подтверждения, он начинает отсчет тайм-аута ;
     
     2) если логический объект транспортного уровня получает ПБДТ, который подтверждает один из требующих подтверждения ПБДТ, он повторно начинает отсчет тайм-аута , если только принятый ПБДТ не является ПБДТ ПД, который явно закрывает окно передачи;
     
     3) если логический объект транспортного уровня получает ПБДТ, подтверждающий последний из требующих подтверждения ПБДТ, он прекращает отсчет тайм-аута .
     
     При решении вопроса: обеспечивать тайм-аут повторной передачи  для каждого ПБДТ или для его СТУ, следует учитывать фактор пропускной способности.
     
     2 Вопрос о повторной передаче только первого ПБДТ ДН либо всех ожидающих подтверждения ПБДТ ДН вплоть до верхней границы окна решается локально.
     
     3 Рекомендуется, чтобы после  передач логический объект транспортного уровня находился в состоянии ожидания в течение периода времени, равного , чтобы обеспечить максимальную вероятность получения подтверждения до входа в фазу разъединения соединения. Для других типов ПБДТ, которые могут передаваться повторно, рекомендуется, чтобы после  передач логический объект транспортного уровня ожидал в течение времени, равного , чтобы обеспечить максимальную вероятность получения ожидаемого ответа.
     
     4 Если использование избирательного подтверждения согласовано, то избирательное подтверждение косвенно идентифицирует неполученные ПБДТ ДН. Поскольку подобный ПБДТ ДН может быть потерянным ПБДТ ДН или просто задержанным ПБДТ ДН, вопрос о необходимости немедленной повторной передачи неподтвержденных ПБДТ ДН является частным вопросом.
     
     
     h) сцепление и разделение (см. 6.4).
     
     12.2.2 Процедуры при установлении соединения
     
     12.2.2.1 Тайм-ауты, используемые при установлении соединения
     
     Для фазы установления соединения специальных тайм-аутов не предусмотрено.
     
     12.2.2.2 Общие процедуры при работе с УСУ-УС
     
     Логические объекты транспортного уровня должны использовать следующие процедуры:
     
     a) прикрепление к ССУ (см. 6.1.1).
     
     Если ССУ, к которому было прикреплено СТУ, разъединяется (принят примитив С-РАЗЪЕДИНЕНИЕ.индикация), то
     
     1) если ожидается прием ПБДТ ПС, инициатор должен осуществить новое прикрепление в соответствии с КУ и выполнить процедуру повторной передачи (т.е. не передавать ПБДТ ЗС дольше периода );
     
     2) если СТУ прикреплено еще хотя бы к одному ССУ, то как инициатор соединения, так и принимающая сторона могут либо осуществить новое прикрепление, либо продолжить выполнение операций с использованием одного из оставшихся ССУ;
     
     3) если СТУ остается неприкрепленным, то ответная сторона может либо осуществить новое прикрепление либо ожидать (риск тупиковой ситуации отсутствует, поскольку функционирует тайм-аут либо , либо ); при этом инициатор должен выполнить новое прикрепление (если только окно не закрыто);
     
     b) установление соединения (см. 6.5) и если соответствующее соединение отклоняется (см. 6.6), то наряду с дополнительными процедурами:
     
     1) соединение не будет считаться установленным до успешного завершения трехстороннего обмена ПБДТ. Отправитель ПБДТ ЗС должен ответить на соответствующий ПБДТ ПС, немедленно передав ПБДТ ДН, СД, ЗР или ПД;
     
     2) вследствие дублирования или повторной передачи полученный ПБДТ ЗС может определять указатель отправителя, который уже используется передающим логическим объектом транспортного уровня. Если принимающий логический объект транспортного уровня находится в фазе передачи данных, завершив процедуру трехстороннего обмена ПБДТ, либо он ожидает от пользователя УТУ примитив Т-СОЕДИНЕНИЕ ответ, он должен проигнорировать такой ПБДТ. В любом другом случае должен быть передан ПБДТ ПС;
     
     3) вследствие дублирования или повторной передачи может быть получен ПБДТ ПС, определяющий указатель-дубликат, уже находящийся в использовании. Принимающий логический объект транспортного уровня должен лишь подтвердить дубликат ПБДТ ПС в соответствии с процедурой, изложенной в 12.2.2.2b 1);
     
     4) возможно поступление ПБДТ ПС, определяющего указатель, который находится в заблокированном состоянии. В ответ на такой ПБДТ должен быть выдан ПБДТ ЗР;
     
     5) процедуры повторной передачи (см. 12.2.1.2) используются как для ПБДТ ЗС, так и для ПБДТ ПС.
     
     Примечание - После получения ПБДТ ЗС рекомендуется, чтобы логический объект транспортного уровня установил для пользователя УТУ временное ограничение с тем, чтобы запоздалое принятие СТУ не привело к задержке в передаче необходимого ПБДТ ПС.
     
     
     12.2.2.3 Общие процедуры при работе с УСУ-БУС
     
     Логический объект транспортного уровня должен использовать процедуру установления соединения (см. 6.5), и если соответствующее соединение отклоняется (см. 6.6), то наряду с дополнительными процедурами:
     
     1) соединение не будет считаться установленным до успешного завершения трехнаправленного обмена ПБДТ. Отправитель ПБДТ ЗС должен ответить на соответствующий ПБДТ ПС, немедленно передав ПБДТ ДН, СД, ЗР или ПД;
     
     2) вследствие дублирования или повторной передачи полученный ПБДТ ЗС может указывать адрес отправителя, который уже используется передающим логическим объектом транспортного уровня. Если принимающий логический объект транспортного уровня находится в фазе передачи данных, завершив процедуру трехнаправленного обмена ПБДТ, или ожидает получения примитива Т-СОЕДИНЕНИЕ запрос от пользователя УТУ, он должен проигнорировать такой ПБДТ. В любом другом случае должен быть передан ПБДТ ПС;
     
     3) вследствие дублирования или повторной передачи может быть получен ПБДТ ПС, определяющий указатель, который уже находится в использовании. Принимающий логический объект транспортного уровня должен лишь подтвердить дубликат ПБДТ ПС в соответствии с процедурой, изложенной в 12.2.2.3.1);
     
     4) возможно поступление ПБДТ ПС, определяющего указатель, который находится в заблокированном состоянии. В ответ на такой ПБДТ должен быть выдан ПБДТ ЗР;
     
     5) процедуры повторной передачи (см. 12.2.1.3) используется как для ПБДТ ЗС, так и для ПБДТ ПС.
     
     Примечание - После получения ПБДТ ЗС рекомендуется, чтобы логический объект транспортного уровня установил для пользователя УТУ временное ограничение с тем, чтобы запоздалое принятие СТУ не привело к задержке в передаче необходимого ПБДТ ПС.
     
     
     12.2.3 Процедуры передачи данных
     
     12.2.3.1 Taйм-ауты, используемые при передаче данных
     
     12.2.3.1.1 Тайм-ауты, используемые при передаче данных при работе с УСУ-УС
     
     Процедуры передачи данных используют один дополнительный тайм-аут
     
     а) Тайм-аут окна ()
     
     Логический объект транспортного уровня обеспечивает тайм-аут, гарантирующий наличие предела максимального интервала времени между изменениями размера окна.
     
     Примечание - Приемлемое значение верхней границы для  определяется выражением: . Рекомендуется, чтобы значение  было существенно меньшим, чем  с тем, чтобы процедура управления неактивностью по 12.2.3.3 могла функционировать с учетом возможности потери ПБДТ.
     
     
     12.2.3.1.2. Тайм-ауты, используемые при передаче данных при работе с УСУ-БУС
     
     Процедуры передачи данных используют один дополнительный тайм-аут
     
     а) Тайм-аут окна ()
     
     Логический объект транспортного уровня обеспечивает тайм-аут, гарантирующий наличие предела максимального интервала времени между изменениями размера окна.
     
     Примечание - Приемлемое значение верхней границы для  определяется выражением: . Рекомендуется, чтобы значение  было существенно меньшим, чем  с тем, чтобы процедура управления неактивностью по 12.2.3.3 могла функционировать с учетом возможности потери ПБДТ.
     
     
     12.2.3.2 Общие процедуры при передаче дaнных
     
     Логические объекты транспортного уровня должны использовать следующие процедуры:
     
     a) управление неактивностью (см. 6.21);
     
     b) срочные данные (см. 6.11);
     
     c) явное управление потоком (см. 6.16).
     
     Передающий логический объект транспортного уровня должен использовать следующие процедуры в перечисляемой последовательности:
     
     1) сегментирование (см. 6.3);
     
     2) нумерацию ПБДТ ДН (см. 6.10).
     
     Принимающий логический объект транспортного уровня должен использовать следующие процедуры в перечисляемой последовательности:
     
     нумерацию ПБДТ ДН (см. 6.10);
     
     упорядочение (см. 6.20);
     
     сборку (см. 6.3).
     
     12.2.3.3 Управление неактивностью
     
     Если тайм-аут неактивности  истечет до получения ПБДТ, логический объект транспортного уровня должен инициировать процедуры разъединения. Чтобы не допустить истечения тайм-аута неактивности на удаленном логическом объекте транспортного уровня из-за отсутствия передачи данных, локальный логический объект транспортного уровня должен при отсутствии данных передавать ПБДТ ПД в удобные моменты времени, учитывая возможность потери ПБДТ. Процедуры синхронизации окна (см. 12.2.3.8) обеспечивают выполнимость этого требования.
     
     Примечание - Возможно, что процедура разъединения, инициированная вследствие истечения тайм-аута, окажется безуспешной, поскольку истечение тайм аута, в данном случае свидетельствует о возможной неисправности поддерживающего ССУ или удаленного логического объекта транспортного уровня.
     
     
     12.2.3.4 Срочные данные
     
     12.2.3.4.1 Срочные данные при работе с УСУ-УС
     
     Логические объекты транспортного уровня должны использовать сетевой вариант нормальных данных процедур передачи срочных данных (см. 6.11.1), если использование факультативной УТУ срочной передачи было согласовано во время установления соединения.
     
     ПБДТ СД должен иметь номер НР-ПБДТ-СД, назначенный ему из набора порядковых номеров, отличных от набора номеров ПБДТ ДН.
     
     Логический объект транспортного уровня должен устанавливать в ноль порядковый номер НР-ПБДТ-СД первого ПБДТ СД, передаваемого по СТУ. Для последующих ПБДТ СД, передаваемых по тому же СТУ, логический объект транспортного уровня должен назначать порядковый номер, на единицу больший предыдущего.
     
     При выборе обычного формата должен использоваться арифметический модуль 2, при выборе расширенного формата - модуль 2.
     
     Принимающий логический объект транспортного уровня должен передавать ПБДТ ПСД с тем же порядковым номером в своем поле НРСПБДТ-ОТВ. Если этот номер на единицу больше, чем в принятом перед этим ПБДТ СД, принимающий логический объект транспортного уровня должен передать данные из ПБДТ СД пользователю УТУ.
     
     Если логический объект транспортного уровня не получил ПБДТ ПСД в подтверждение переданного им ПБДТ СД, он должен выполнить процедуру повторной передачи (см. примечание и 12.2.1.2).
     
     До получения ПБДТ ПСД отправитель ПБДТ СД не должен передавать никаких новых ПБДТ ДН, вырабатываемых из примитива Т-ДАННЫЕ запрос вслед за примитивом Т-СРОЧНЫЕ-ДАННЫЕ запрос.
     
     Примечание - Эта процедура гарантирует упорядоченную доставку данных из ПБДТ СД пользователю УТУ, а также предотвращает неоднократное получение пользователем УТУ данных, относящихся к одному и тому же ПБДТ СД. Она гарантирует также доставку ПБДТ СД раньше любых данных, переданных впоследствии пользователем УТУ.
     
     
     12.2.3.4.2 Срочные данные при работе с УСУ-БУС
     
     Логические объекты транспортного уровня должны выполнять процедуры передачи срочных данных (см. 6.11.2), если использование факультативных УТУ срочной передачи было согласовано во время установления соединения.
     
     ПБДТ СД должен иметь номер НР-ПБДТ, назначенный ему из набора порядковых номеров, отличных от набора номеров ПБДТ ДН.
     
     Логический объект транспортного уровня должен устанавливать в ноль порядковый номер НР-ПБДТ-СД первого ПБДТ СД, передаваемого по СТУ. Для последующих ПБДТ СД, передаваемых по тому же СТУ, логический объект транспортного уровня должен назначать порядковый номер, на единицу больший предыдущего.
     
     При выборе обычного формата должен использоваться арифметический модуль 2, при выборе расширенного формата - модуль 2.
     
     Принимающий логический объект транспортного уровня должен передавать ПБДТ ПСД с тем же порядковым номером в своем поле НРСПБДТ-ОТВ. Если этот номер на единицу больше, чем в принятом перед этим ПБДТ СД, принимающий логический объект транспортного уровня должен передавать данные из ПБДТ СД пользователю УТУ.
     
     Если логический объект транспортного уровня не получил ПБДТ ПСД в подтверждение переданного им ПБДТ СД, он должен выполнить процедуру повторной передачи (см. примечание к 12.2.1.3).
     
     До получения ПБДТ ПСД отправитель ПБДТ СД не должен передавать никаких новых ПБДТ ДН, вырабатываемых из последнего СБДТ, полученного через границу услуг транспортного уровня после передачи ПБДТ СД, пока он не получит ПБДТ ПСД.
     
     Примечание - Эта процедура гарантирует упорядоченную доставку данных из ПБДТ СД пользователю УТУ, а также предотвращает неоднократное получение пользователем УТУ данных, относящихся к одному и тому же ПБДТ СД. Она гарантирует также доставку ПБДТ СД раньше любых данных, переданных впоследствии пользователем УТУ.
     
     
     12.2.3.5 Упорядочение
     
     Принимающий логический объект транспортного уровня должен доставлять все ПБДТ ДН пользователю УТУ в той последовательности, которая определена полем порядковых номеров.
     
     Те ПБДТ ДН, которые приняты вне установленной последовательности, но в пределах окна передачи, не должны доставляться пользователю УТУ до получения всех очередных ПБДТ. Те ПБДТ ДН, которые приняты вне установленной последовательности и вне окна передачи, должны быть аннулированы, что может привести к передаче ПБДТ ПД с обновленной информацией об окне (см. 12.2.3.8). Если во время установления соединения была согласована факультативная возможность избирательного подтверждения, то те ПБДТ ДН, которые были избирательно подтверждены, должны храниться у принимающего логического объекта транспортного уровня до их доставки пользователю УТУ. Они должны сохраняться даже в том случае, если избирательно подтвержденный ПБДТ окажется впоследствии вне окна передачи из-за последующего снижения кредита.
     
     Примечание - Рекомендуется, чтобы логический объект транспортного уровня, передающий ПБДТ ПД, обеспечил предельное значение количества избирательных подтверждений ПБДТ ДН с целью сокращения операций обработки в логическом объекте транспортного уровня, получившем ПБДТ ПД.
     
     
     ПБДТ-дубликаты могут быть обнаружены по совпадению их порядковых номеров с номерами ранее принятых ПБДТ. Порядковые номера не должны использоваться повторно в течение периода после их предыдущего использования. Иначе можно спутать новый действительный ПБДТ с ПБДТ-дубликатом, который уже был принят и подтвержден.
     
     ПБДТ ДН-дубликаты должны быть подтверждены, поскольку такие ПБДТ могут появиться в результате повторной передачи, обусловленной потерей ПБДТ ПД.
     
     Данные, содержащиеся в ПБДТ-дубликате, должны быть аннулированы.
     
     12.2.3.6 Явное управление потоком
     
     Логические объекты транспортного уровня должны передавать начальный кредит (который может иметь значение 0) в поле КРД блока данных ПБДТ ЗС или ПС. Этот кредит представляет собой начальное значение верхней границы окна равноправного логического объекта.
     
     Логический объект транспортного уровня, получивший ПБДТ ЗС или ПС, должен рассматривать нижнюю границу своего окна как нулевую, а верхнюю границу - как значение поля КРД в полученном ПБДТ.
     
     Чтобы санкционировать своему объекту-партнеру передачу ПБДТ ДН, логический объект транспортного уровня может в любой момент времени передать ПБДТ ПД.
     
     Порядковый номер любого ПБДТ ПД не должен превышать порядкового номера следующего ожидаемого ПБДТ ДН, т.е. он не должен быть выше самого большого порядкового номера полученного ПБДТ ДН плюс единица.
     
     Логический объект транспортного уровня может в любой момент передать ПБДТ ПД-дубликат, содержащий те же порядковый номер, поле КРД и следующий номер.
     
     Логический объект транспортного уровня может в любой момент увеличить или уменьшить верхнюю границу окна.
     
     При получении ПБДТ ПД логический объект транспортного уровня должен рассматривать значение его поля НР-ОТВ как новую нижнюю границу своего окна, если это значение больше любого ранее полученного значения в поле НР-ОТВ, а сумму НР-ОТВ и КРД как новую верхнюю границу своего окна в соответствии с процедурами упорядочения ПБДТ ПД (см. 12.2.3.8). Логический объект транспортного уровня не должен передавать (в том числе повторно) ПБДТ ДН с порядковым номером, выходящим за пределы окна передачи.
     
     12.2.3.7 Упорядочение принятых ПБДТ ПД
     
     Для того, чтобы принимающий логический объект транспортного уровня мог правильно упорядочить последовательность ПБДТ ПД, содержащих один и тот же порядковый номер, и тем самым использовать нужное значение кредита, ПБДТ ПД могут содержать параметр последовательности. В целях определения правильной последовательности ПБДТ ПД отсутствие параметра подпоследовательности должно быть эквивалентно нулевому его значению.
     
     Считается, что ПБДТ ПД поступает в нужной последовательности, если:
     
     a) его порядковый номер больше, чем номер любого ранее принятого ПБДТ ПД, или
     
     b) его порядковый номер равен наибольшему порядковому номеру любого ранее принятого ПБДТ ПД, а его параметр подпоследовательности больше этого параметра в любом ранее принятом ПБДТ ПД, имеющем то же значение поля НР-ОТВ, или
     
     c) порядковый номер и параметр подпоследовательности равны наибольшим соответствующим значениям в любом ранее принятом ПБДТ ПД, а поле кредита больше или равно полю кредита в любом ранее принятом ПБДТ ПД, имеющем то же значение поля НР-ОТВ.
     
     Если принимающий логический объект транспортного уровня опознал ПБДТ ПД, следующий не по порядку, он должен аннулировать такой ПБДТ.
     
     12.2.3.8 Процедуры передачи ПБДТ ПД
     
     12.2.3.8.1 Передача ПБДТ ПД
     
     Полученный по очереди ПБДТ ДН должен быть подтвержден в интервале времени  путем передачи ПБДТ ПД, параметр НР-ОТВ которого равен значению порядкового номера полученного ПБДТ ДН плюс единица. Если во время установления соединения была согласована факультативная возможность избирательного подтверждения, то те ПБДТ ДН, которые вышли из последовательности, могут быть также подтверждены в пределах времени . Параметр НР-ОТВ должен быть установлен в значение, превышающее наибольший порядковый номер следующих по порядку ПБДТ ДН, и соответствующим образом должен быть установлен параметр избирательного подтверждения.
     
     ПБДТ ПД должен быть передан с обновленной информацией окна, если:
     
     a) полученный ПБДТ ДН имеет порядковый номер, меньший нижней границы окна но больший или равный значению нижней границы окна минус максимальное значение кредита, назначенного ранее для данного СТУ, или
     
     b) полученный ПБДТ ДН имеет порядковый номер, больший текущей верхней границы окна, но после снижения кредита оказавшийся ниже верхней границы окна, которая была назначена, а затем аннулирована.
     
     Примечания
     
     1 Более простое изделие может передать ПБДТ ПД при приеме любого ПБДТ ДН вне окна передачи.
     
     2 Процедура по подпункту а) необходима для того, чтобы корректно восстановить потерянный ПБДТ ПД, т.е. когда отправитель ПБДТ ДН повторно передает его из-за неполучения подтверждения.
     
     3 Процедура по подпункту b) необходима вследствие возможности потери ПБДТ ПД, указывающего на снижение верхней границы окна; отсутствие этой процедуры могло бы привести к некорректному разъединению СТУ.
     
     4 При каждом привлечении процедур по подпунктам а), b) и при использовании факультативной возможности избирательного подтверждения должны быть соответствующим образом установлены параметры избирательного подтверждения ПБДТ ПД при их необходимости.
     
     
     Логический объект транспортного уровня предусматривает обязательную передачу ПБДТ ПД в интервале . Если он не использует эту процедуру после установления КРД в нулевое значение (см. 12.2.3.8.3) или снижения верхней границы окна (см. 12.23.8.4) и не считает нужным подтвердить получение какого-либо ПБДТ ДН, он должен обеспечить это путем повторной передачи самого последнего ПБДТ ПД с обновленной информацией окна.
     
     Примечание - Использование процедур, определенных в 12.2.3.8.3 и 12.2.3.8.4, является факультативным для любого логического объекта транспортного уровня. Протокол выполняется корректно как с использованием этих процедур, так и без них, поскольку они предназначены только для повышения его эффективности.
     
     
     12.2.3.8.2 Управление последовательности при передаче ПБДТ ПД
     
     Чтобы обеспечить возможность принимающему логическому объекту транспортного уровня обрабатывать ПБДТ ПД в правильной подпоследовательности в соответствии с изложенным в 12.2.3.7, должен быть предусмотрен параметр подпоследовательности, обуславливающий уменьшение КРД. Если значение подлежащего передаче номера подпоследовательности равно нулю, этот параметр должен быть опущен.
     
     Значением параметра подпоследовательности (если он используется) должен быть ноль (либо явно, либо в виде отсутствия параметра), если данный порядковый номер больше значения этого параметра в предыдущих ПБДТ ПД, переданных данным логическим объектом транспортного уровня.
     
     Если порядковый номер такой же, как и у ранее переданного ПБДТ ПД, а поле КРД равно или больше, чем поле КРД в ранее переданном ПБДТ ПД, то параметр подпоследовательности (если он используется) должен быть равен этому параметру в ранее переданном ПБДТ ПД.
     
     Если порядковый номер такой же, как и у ранее переданного ПБДТ ПД, а значение поля КРД меньше его значения в предыдущем переданном ПБДТ ПД, то параметр подпоследовательности (если он используется) должен быть на единицу больше, чем его значение в предыдущем ПБДТ ПД.
     
     Примечание - Если логический объект транспортного уровня никогда не снижает кредит, то нет необходимости использовать параметр подпоследовательности.
     
     
     12.2.3.8.3 Повторная передача ПБДТ ПД после установления КРД в нулевое значение
     
     Из-за возможности потери ПБДТ ПД восприятие верхней границы окна логическим объектом транспортного уровня, передающим ПБДТ ПД, может отличаться от восприятия этой границы адресуемым получателем. Чтобы исключить возможность чрезмерной задержки, может быть выполнена процедура повторной передачи (см. 12.2.1.2) для ПБДТ ПД, если он открывает окно передачи, которое ранее было закрыто передачей ПБДТ ПД с полем КРД, равным нулю.
     
     Процедура повторной передачи (если она использовалась) завершается и используется процедура, описанная в 12.2.3.8.1, если:
     
     a) принят ПБДТ ПД, содержащий параметр подтверждения управления потоком, у которого поле нижней границы окна и поле вашей подпоследовательности равны порядковому номеру и номеру подпоследовательности соответственно в хранимом ПБДТ ПД и значение кредита в котором не равно нулю;
     
     b) передан ПБДТ ПД с более высоким порядковым номером, чем у хранимого ПБДТ ПД в связи с приемом ПБДТ ДН, чей порядковый номер равен нижней границе окна;
     
     c) выполнено N передач хранимого ПБДТ ПД. В этом случае логический объект транспортного уровня должен продолжать передачи ПБДТ ПД с интервалом .
     
     ПБДТ ПД, являющийся объектом процедуры повторной передачи, не должен содержать параметр подтверждения управления потоком. Если передача этого параметра все же необходима, то следует передать дополнительный ПБДТ ПД с теми же значениями полей последовательности, подпоследовательности (если она имеет место) и кредита.
     
     12.2.3.8.4 Процедуры повторной передачи после уменьшения верхней границы окна
     
     В этом пункте определена процедура повторной передачи ПБДТ ПД после того, как логический объект транспортного уровня уменьшил верхнюю границу окна (см. 12.2.3.6). Эта процедура используется до тех пор, пока нижняя граница окна не превысит ранее переданного наибольшего значения верхней границы (т.е. значения, полученного при уменьшении кредита, если только не сохранилось еще большее значение после предыдущего уменьшения кредита).
     
     Процедура повторной передачи должна использоваться для любого ПБДТ ПД, увеличивающего верхнюю границу окна, если только не становится известно, что удаленный логический объект транспортного уровня имеет открытое окно. Это становится известным, если:
     
     - получен параметр подтверждения управления потоком, соответствующий ПБДТ ПД, переданным после последнего уменьшения кредита, и
     
     - параметр подтверждения управления потоком содержит значение верхней границы окна (т.е. сумму полей нижней границы окна и полей кредита), которая превышает значение нижней границы окна переданного ПБДТ ПД.
     
     Процедура повторной передачи для любого конкретного ПБДТ ПД должна завершиться, если:
     
     a) получен ПБДТ ПД, содержащий параметр подтверждения управления потоком, у которого поля нижней границы окна и вашей подпоследовательности равны нижней границе окна и номеру подпоследовательности соответственно в хранимом ПБДТ ПД, или
     
     b) произошло  передач хранимого ПБДТ ПД. В этом случае логический объект транспортного уровня должен продолжить передачу ПБДТ ПД с интервалом .
     
     ПБДТ ПД, подлежащий повторной передаче, не должен содержать параметр подтверждения управления потоком. Если требуется совместная передача этого параметра, следует передать дополнительный ПБДТ ПД с теми же значениями полей последовательности, подпоследовательности (если она используется) и кредита.
     
     Примечание - В нормальных условиях повторная передача ПБДТ ПД необязательна, кроме передачи после явного закрытия окна (т.е. передачи ПБДТ ПД с полем КРД, равным нулю). Если данные готовы к передаче, то процедура повторной передачи ПБДТ ДН обеспечит прием ПБДТ ПД с предоставлением дальнейшего кредита (в необходимых случаях); после уменьшения кредита ситуация может измениться, поскольку повторная передача может быть предотвращена уменьшением кредита. Правила, описываемые в данном разделе, позволяют устранять чрезмерную задержку.
     
     
     Определить необходимость применения процедуры повторной передачи к ПБДТ ПД можно на основе следующих альтернативных правил. Пусть
     
     НГО - нижняя граница окна,
     
     ВГО - верхняя граница окна,
     
     НВГО - нижний предел верхней границы окна, поддерживаемый удаленным логическим объектом транспортного уровня.
     
     Процедура повторной передачи должна быть использована всякий раз, когда
     

(ВГО>НГО) и (НВГО=НГО),

     
т.е. когда окно открыто и точно неизвестно, что логический объект транспортного уровня осведомлен об этом.
     
     НВГО обрабатывается следующим образом.
     
     При снижении кредита НВГО устанавливается в значение НГО. Затем он увеличивается только при приеме действительного подтверждения управления потоком (т.е. подтверждения, которое согласует сохраняемую нижнюю границу окна с подпоследовательностью). В этом случае НВГО устанавливается в предполагаемое значение верхней границы окна подтверждения управления потоком, т.е. в значение суммы своей нижней границы окна и полей вашего кредита. Пользуясь этим методом, можно гарантировать, что НВГО будет всегда меньше или равен фактической верхней границе окна, используемой передатчиком ПБДТ ДН.
     
     12.2.3.9 Использование параметра подтверждения управления потоком
     
     ПБДТ ПД, содержащий параметр подтверждения управления потоком, может быть передан в любое время. Нижняя граница окна, ваша подпоследовательность и ваши поля кредита должны быть установлены в те же значения, что и соответствующие поля в последнем принятом по порядку ПБДТ ПД.
     
     ПБДТ ПД, содержащий параметр подтверждения управления потоком, должен передаваться всякий раз, когда:
     
     а) получен ПБДТ ПД - дубликат с полями НР-ОТВ, КРД и подпоследовательностями, равными соответствующим полям самого последнего полученного ПБДТ ПД, но без параметра подтверждения управления потоком;
     
     b) получен ПБДТ ПД, который повышает верхнюю границу окна, но не повышает нижнюю границу окна, при этом верхняя граница окна ранее была равна нижней границе окна, или
     
     с) получен ПБДТ ПД, который повышает верхнюю границу окна, но не повышает нижнюю границу окна, а нижняя граница окна ниже наибольшего значения верхней границы окна, ранее полученной и затем уменьшенной (т.е. в результате уменьшения кредита).
     
     12.2.4 Процедуры разъединения
     
     12.2.4.1 Тайм-ауты, используемые при разъединении
     
     Тайм-аутов, которые использовались бы только для разъединения, не предусмотрено.
     
     12.2.4.2 Общие процедуры разъединения
     

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

     13 Структура и кодирование ПБДТ

     
     13.1 Действительные ПБДТ
     
     Перечень ПБДТ, действительных для каждого класса, и кодирование каждого ПБДТ приведены в таблице 8.
     
     
Таблица 8 - Коды ПБДТ

     
     Условные обозначения:
     
     ХХХХ (биты 4-1) - используются для передачи КРД (устанавливаются в значение 0000 в классах 0 и 1);
     
     ZZZZ (биты 4-1) - используются для передачи КРД в классах 2-4 и устанавливаются в значение 1111 в классе 1;
     
     ННУ - не используется при выборе факультативной функции неявного управления потоком;
     
     НУП - не используется при выборе факультативной функции уведомления о приеме.
     
     Примечание - Эти коды уже используются в соответствующих протоколах, определенных другими организациями по стандартизации (не МККТТ и не ИСО/МЭК).
     
     
     13.2 Структура
     
     Каждый ПБДТ должен содержать целое число октетов. Нумерация октетов ПБДТ начинается с 1 и возрастает в порядке их расположения в СБДС. Биты в октетах нумеруются от 1 до 8, где бит 1 - бит младшей значимости.
     
     Если для представления двоичного числа используется последовательность октетов, то октет с наименьшим номером имеет наибольшую значимость.
     
     Примечания
     
     1 Нумерация битов внутри октета определяется локальным соглашением для настоящего стандарта.
     
     2 Использование терминов "старшая значимость" и "младшая значимость" является общим как для настоящего стандарта, так и для стандартов по смежным уровням.
     
     3 Использование изложенных выше соглашений не влияет на порядок передачи битов при последовательной передаче по каналу связи.
     
     4 Как описано в 6.2.3, оба логических объекта транспортного уровня соблюдают соглашения о последовательности передачи битов и октетов, что обеспечивает возможность обмена данными.
     
     5 В данном подразделе кодирование ПБДТ представлено в следующем виде:
     
     a) октет с младшим номером расположен слева; номера октетов возрастают слева направо;
     
     b) в пределах октета бит 8 расположен слева, бит 1 - справа.
     
     
     ПБДТ должны содержать следующие элементы в указанном порядке:
     
     a) заголовок, состоящий из
     
     1) поля "указатель длины" (УД),
     
     2) фиксированной части,
     
     3) переменной части (при ее наличии);
     

     b) поле данных (при его наличии).
     
     Эта структура приведена ниже
     

     
     13.2.1 Поле УД
     
     Содержится в первом октете ПБДТ. Длина указывается двоичным числом с максимальным значением 254 (1111 1110). Указанная длина должна равняться длине заголовка в октетах, включая параметры, но исключая поле "указатель длины" и поле данных пользователя (при его наличии). Значение 255 (1111 1111) зарезервировано для возможных расширений.
     
     Если указываемая длина превышает фактическую длину принимаемого поля данных пользователя УСУ или равна ей, это означает протокольную ошибку.
     
     13.2.2 Фиксирующая часть
     
     13.2.2.1 Общие положения
     
     Фиксированная часть содержит часто встречающиеся параметры, включая код ПБДТ. Длина и структура фиксированной части определены кодом ПБДТ и в некоторых случаях классом протокола и используемым форматом (нормальным или расширенным). Если какой-то параметр фиксированной части имеет недействительное значение или если фиксированная часть не может быть размещена в заголовке (как определено УД), это означает протокольную ошибку.
     
     Примечание - В общем случае код ПБДТ однозначно определяет фиксированную часть. Однако при одном и том же коде ПБДТ возможны различные варианты (см. нормальный и расширенный форматы).
     
     
     13.2.2.2 Код ПБДТ
     
     Это поле содержит код ПБДТ и расположено в октете 2 заголовка. Оно используется для определения структуры остальной части заголовка. Это поле занимает весь октет, за исключением следующих случаев:
     
     1110 ХХХХ - запрос соединения,
     
     1101 ХХХХ - подтверждение соединения,
     
     1111 000Y - данные,
     
     0101 ХХХХ - отказ,
     
     0110 ХХХХ - подтверждение данных,
     
где ХХХХ (биты 4-1) используются для передачи КРД.
     
     Y (бит 1) используется для сообщения о ЗМП, если запрос подтверждения был согласован при установлении соединения (только в классах 1, 3 и 4).
     
     Действительны только коды, определенные в 13.1
     
     13.2.3 Переменная часть
     
     Используется для определения менее часто используемых параметров. При ее наличии она должна содержать один или несколько параметров.
     
     Примечание - число параметров, которые могут содержаться в переменной части, определяется ее длиной, которая равна значению УД минус длина фиксированной части.
     
     
     Каждый параметр, содержащийся в переменной части, имеет следующую структуру:     
     

               
     Поле "код параметра" кодируется двоичным числом.
     
     Примечание - При отсутствии расширения это поле обеспечивает максимум 255 различных параметров. Однако, как указано ниже, биты 8 и 7 не могут принимать любые возможные значения, поэтому практически максимальное число различных параметров меньше. Код 1111 1111 зарезервирован для возможных расширений кода параметра.
     
     
     Указатель длины параметра указывает длину поля "значение параметра" в октетах.
     
     Примечание - Длина указывается двоичным числом  с теоретическим максимальным значением 255. Практическое максимальное значение  ниже. Например, если в переменной части содержится один параметр, то для кода параметра и указателя длины параметра необходимы два октета. Таким образом, значение  ограничено числом 248. С увеличением длины фиксированной части заголовка и с добавлением каждого следующего параметра максимальное значение  уменьшается.
     
     
     Поле "значение параметра" содержит значение параметра, указанного в поле "код параметра".
     
     В кодах параметров биты 8 и 7 со значением 00 не используются.
     
     Параметры, определенные в переменной части, могут располагаться в любом порядке. Если какой-либо параметр продублирован, то должно использоваться его последнее значение. Параметр, не определенный в настоящем стандарте, в любом полученном ПБДТ, кроме ПБДТ ЗС, должен рассматриваться как протокольная ошибка; в ПБДТ ЗС такой параметр должен игнорироваться. Параметр "вызываемый ИД - ПДУСУ" в ПБДТ ПС с указателем длины, равным нулю, должен рассматриваться как имеющий "пустое значение селектора" (см. ИСО 7498-3, 9.5.2). Если отвечающий логический объект транспортного уровня выбрал класс, для которого параметр в ПБДТ ЗС не определен, он может игнорировать этот параметр кроме случая, когда выбран параметр "класс и факультативная функция" или параметр "альтернативный протокольный класс", которые всегда должны интерпретироваться. Параметр, который определен в настоящем стандарте, но имеет недействительное значение, должен рассматриваться в любом принятом ПБДТ, кроме ПБДТ ЗС, как протокольная ошибка. В ПБДТ ЗС он должен рассматриваться как протокольная ошибка, если это параметр "класс и факультативная функция" или "альтернативный класс"; биты 8 и 7, а также биты 6-1, если они являются незначащими для предложенного класса параметра "дополнительная факультативная возможность", должны игнорироваться; в остальных случаях он должен быть либо проигнорирован, либо воспринят как протокольная ошибка.
     
     13.2.3.1 Параметр "контрольная сумма" (только класс 4)
     
     ПБДТ всех типов могут содержать в переменной части параметр "контрольная сумма". Этот параметр должен содержаться в ПБДТ ЗС и во всех других ПБДТ, за исключением случая, когда выбрано неиспользование контрольной суммы.
     
     Код параметра - 1100 0011
     
     Длина параметра - 2
     
     Значение параметра - результат вычисления контрольной суммы;
     
     алгоритм вычисления определен в 6.17.
     
     13.2.4 Поле данных
     
     Содержит прозрачные данные пользователя. Ограничения на его длину указываются для каждого ПБДТ.
     
     13.3 ПБДТ "запрос соединения" (3С)
     
     Длина ПБДТ ЗС не должна превышать 128 октетов.
     
     13.3.1 Структура
     
     ПБДТ ЗС должен иметь следующую структуру:
                

   
       ФФ - факультативная функция
     
     13.3.2 УД
     
     См. 13.2.1.
     
     13.3.3 Фиксированная часть (октеты 2-7)
     
     Эта часть должна содержать:
     
     а) ЗС - код запроса соединения 1110. Биты 8-5 октета 2;
     
     b) КРД - позиция начального кредита (устанавливается в значение 0000 в классе 0, а также в классе 1, если он определен как предпочтительный класс); биты 4-1 октета 2;
     
     c) УКАЗ-ПОЛ - устанавливается в ноль;
     
     d) УКАЗ-ОТП - указатель, выбранный логическим объектом транспортного уровня, выдавшим ПБДТ ЗС для идентификации запрашиваемого СТУ;
     
     e) КЛАСС И ФАКУЛЬТАТИВНАЯ ФУНКЦИЯ - биты 8-5 октета 7 определяют предпочтительный класс протокола транспортного уровня, который должен использоваться в запрашиваемом СТУ. Это поле должно иметь одно из следующих значений:
     
     0000 класс 0
     
     0001 класс 1
     
     0010 класс 2
     
     0011 класс 3
     
     0100 класс 4
     
     При работе с УСУ-УС это поле должно иметь значение 0100, указывающее класс 4.
     
     В фиксированной части ПБДТ ЗС определяется первый выбор - выбор класса. Выбор второй и последующих альтернативов (если они необходимы) определяется в переменной части.
     
     Биты 4-1 октета 7 определяют факультативные функции, которые подлежат использованию в запрашиваемом СТУ следующим образом:     
     

     
     
     Биты, относящиеся к факультативным функциям конкретного класса, не имеют значения, если этот класс не предложен, и, следовательно, они могут принимать любые значения.
     
     Примечания
     
     1 Процедура установления соединения (см. 6.5) не позволяет данному ПБДТ ЗС запрашивать использование УТУ передачи срочных данных (дополнительный факультативный параметр) и неиспользование явного управления потоком в классе 2 (бит 1=1).
     
     2 В классе 0 биты 4-1 всегда равны нулю и не имеют смысла.
     
     
     13.3.4 Переменная часть (октеты 8-)
     
     В переменной части допускается использование следующих параметров.
     
     a) Идентификатор пункта доступа к УТУ (ИД ПДУТУ).
     
     Код параметра: 1100 0001 для идентификатора вызывающего ПДУТУ
     
     1100 0010 для идентификатора вызываемого ПДУТУ.
     
     Длина параметра - не определена в настоящем стандарте.
     
     Значение параметра - идентификатор вызывающего или вызываемого ПДУТУ соответственно.
     
     Если ИД ПДУТУ выдается в примитиве запроса, он может быть возвращен в примитиве подтверждения.
     
     b) Длина ПБДТ
     
     Этот параметр определяет предложенную максимальную длину ПБДТ (в октетах, включая заголовок) для использования в запрошенном СТУ и кодируется следующим образом:
     
     код параметра - 1100 0000,
     
     длина параметра - 1 октет,
     
     значения параметра - 0000 1101 (8192 октета) (не разрешено в классе 0)
     
     0000 1100 (4096 октетов) (не разрешено в классе 0)
     
     0000 1011 (2048 октетов)
     
     0000 1010 (1024 октета)
     
     0000 1001 (512 октетов)
     
     0000 1000 (256 октетов)
     
     0000 0111 (128 октетов)
     
     Рекомендуемое значение - 0000 0111 (128 октетов)
     
     c) Предпочтительная максимальная длина ПБДТ
     
     Этот параметр определяет предложенную максимальную длину ПБДТ (в октетах, включая заголовок) для использования в запрошенном СТУ и кодируется следующим образом:
     
     код параметра - 1111 0000,
     
     длина параметра - до 4,
     
     значение параметра - двоичное значение, которое указывает максимальную длину ПАБДТ, кратную 128 октетам [см. 6.5.4m и 6.5.5m]. Это значение должно быть больше или равно единице.
     
     d) Номер версии (не используется, если класс 0 является предпочтительным)
     
     Код параметра - 1100 0100.
     
     Длина параметра - 1 октет.
     
     Поле значения параметра - 0000 0001.
     
     Рекомендуемое значение - 0000 0001 (не используется в классе 0)
     
     e) Параметры защиты (не используются, если класс 0 является предпочтительным)
     
     Код параметра - 1100 0101
     
     Значение и длина параметра определяются пользователем.
     
     f) Контрольная сумма (используется только в том случае, если класс 4 является предпочтительным) (см. 13.2.3.1).
     
     Этот параметр всегда будет содержаться в ПБДТ ЗС, запрашивающим класс 4, даже если параметр выбора контрольной суммы используется для запроса неиспользования средства вычисления контрольной суммы.
     
     g) Выбор дополнительной факультативной функции (не используется, если класс 0 является предпочтительным).
     
     Этот параметр определяет выбор использования или неиспользования дополнительных факультативных функций и кодируется следующим образом:
     
     код параметра - 1100 0110,
     
     длина параметра - 1.
     
     Значения параметра - определяются следующим образом:     
     

     
     
     Рекомендуемое значение - 0000 0001.
     
     Биты 8-5 должны быть установлены в ноль при передаче ПБДТ и игнорироваться при его приеме.
     
     Биты, относящиеся к факультативным функциям конкретного класса, не имеют значения, если этот класс не предложен, и, следовательно, могут принимать любые значения.
     
     h) Альтернативный(е) класс(ы) протокола (не используются, если класс 0 является предпочтительным).
     
     Код параметра - 1100 0111.
     
     Длина параметра - .
     
     Значение параметра кодируется в виде последовательности отдельных октетов. Каждый октет кодируется аналогично октету 7, но биты 4-1 установлены в ноль (т.е. запрещен выбор альтернативных факультативных функций).
     
     j) Тайм-аут подтверждения (используется только в том случае, если класс 4 является предпочтительным).
     
     Этот параметр содержит максимальное значение времени подтверждения  для удаленного логического объекта транспортного уровня. Он представляет собой только индикацию, не является объектом согласования (см. 12.2.1.1.3) и кодируется следующим образом:
     
     код параметра - 1000 0101,
     
     длина параметра - 2,
     
     значение параметра -  (двоичное число), где  - максимальное время подтверждения, выражаемое в миллисекундах.
     
     k) Пропускная способность (не используется, если класс 0 является предпочтительным).
     
     Код параметра - 1000 1001
     
     Длина параметра - 12 или 24.
     
     Значения параметра:
     

     
     В тех случаях, когда среднее значение пропускной способности опущено, считается, что оно равно максимальному значению пропускной способности. Указанные значения выражаются в октетах в секунду.
     
     m) Коэффициент необнаруженных ошибок (не используется, если класс 0 является предпочтительным)
     
     Код параметра - 1000 0110.
     
     Длина параметра - 3.
     
     Значения параметра:
     
     первый октет - желаемое значение; степень 10;
     
     второй октет - минимальное приемлемое качество, степень 10;
     
     третий октет - интересуемая длина СБДТ, выраженная степенью 2.
     
     n) Приоритет (не используется, если класс 0 является предпочтительным)
     
     Код параметра - 1000 0111.
     
     Длина параметра - 2.
     
     Значение параметра - целое число (0 - наивысший приоритет).
     
     р) Транзитная задержка (не используется, если класс 0 является предпочтительным)
     
     Код параметра -1000 1000.
     
     Длина параметра - 8.
     
     Значения параметра:
     
     первые 2 октета - желаемое значение; направление - от вызывающего к вызываемому пользователю;
     
     вторые 2 октета - максимальное приемлемое качество; направление - от вызывающего к вызываемому пользователю;
     
     третьи 2 октета - желаемое значение; направление - от вызываемого к вызывающему пользователю;
     
     четвертые 2 октета - максимальное приемлемое качество; направление - от вызываемого к вызывающему пользователю.
     
     Значения выражаются в миллисекундах и относятся к базовой длине ПБДТ 128 октетов.
     
     q) Тайм-аут повторного прикрепления (не используется, если классы 0, 2 или 4 являются предпочтительными).
     
     Этот параметр содержит значение тайм-аута попыток повторного прикрепления (ТПП), который должен использоваться, если после отказа применяется процедура повторного прикрепления (см. 6.12).
     
     Код параметра - 1000 1011.
     
     Длина параметра - 2.
     
     Значение параметра -  (двоичное число), где  - значение ТПП, выраженное в секундах.
     
     r) Тайм-аут неактивности (используется только в том случае, если класс 4 является предпочтительным или выбранным классом). Он используется только для информирования и не является объектом согласования (см. 12.2.1.1.7).
     
     Код параметра - 1111 0010
     
     Длина параметра - 4
     
     Значение параметра - двоичное число, которое указывает прошедшее время неактивности в миллисекундах.
     
     13.3.5 Данные пользователя (октеты +1 до конца)
     
     В классе 0 не допускаются, а в других классах являются факультативными. В случае применения их длина не должна превышать 32 октета.
     
     13.4 ПБДТ "подтверждение соединения" (ПС)
     
     13.4.1 Структура
     
     ПБДТ ПС должен иметь следующую структуру:
          

     
     ФФ - факультативная функция
     
     13.4.2 УД
     
     См. 13.2.1.
     
     13.4.3 Фиксированная часть (октеты 2-7)
     
     Должна содержать:
     
     а) ПС - код подтверждения соединения 1101. Биты 8-5 октета 2;
     
     b) КРД - позиция начального кредита (устанавливается в 0000 в классах 0 и 1). Биты 4-1 октета 2;
     
     с) УКАЗ-ПОЛ - указатель, идентифицирующий запрашиваемое СТУ в удаленном логическом объекте транспортного уровня;
     
     d) УКАЗ-ОТП - указатель, выбираемый логическим объектом транспортного уровня, инициирующим ПБДТ ПС для идентификации подтвержденного СТУ;
     
     е) КЛАСС И ФАКУЛЬТАТИВНАЯ ФУНКЦИЯ - определяет выбранный класс протокола транспортного уровня и факультативную функцию, подлежащую использованию в принятом СТУ в соответствии с правилами согласования, изложенными в 6.5.
     
     13.4.4 Переменная часть (октеты 8-)
     
     Параметры определены в 13.3.4 и являются объектом ограничений, приведенных в 6.5 (установление соединения). Параметры, исключаемые при выборе альтернативных классов и факультативных функций, не должны использоваться.
     
     13.4.5 Данные пользователя (октеты от +1 до конца)
     
     Не допускаются в классе 0 и факультативны в остальных классах. При использовании их длина не должна превышать 32 октета. Данные пользователя являются объектом ограничений со стороны правил согласования (см. 6.5).
     
     13.5 ПБДТ "запрос разъединения" (ЗР)
     
     13.5.1 Структура
     
     ПБДТ ЗР должен иметь следующую структуру:
         

     
     13.5.2 УД
     
     См. 13.2.1.
     
     13.5.3 Фиксированная часть (октеты 2-7)
     
     Должна содержать
     

     
     Примечание - Причины, отмеченные звездочкой (*), могут быть указаны пользователю УТУ как устойчивые, остальные - как неустойчивые.
     
     
     13.5.4 Переменная часть (октеты 8-)
     
     Может содержать:
     
     а) Параметр, содержащий дополнительную информацию, относящуюся к освобождению соединения, кодируется следующим образом:
     
     код параметра - 1110 0000,
     
     длина параметра - любое значение при условии, что длина ПБДТ ЗР не превышает максимальной согласованной длины ПБДТ или 128 октетов, если ПБДТ ЗР используется в процессе отклонения соединения,
     
     значение параметра - дополнительная информация; содержимое этого поля определяется пользователем;
     
     b) контрольную сумму (см. 13.2.3.1).
     
     13.5.5 Данные пользователя (октеты от +1 до конца)
     
     Это поле используется для передачи данных пользователя - УТУ и его длина не должна превышать 64 октета. Протокол транспортного уровня не гарантирует успешную передачу этих данных. При использовании ПБДТ ЗР в классе 0 он не должен содержать этого поля.
     
     13.6 ПБДТ "подтверждение разъединения" (ПР)
     
     Не должен использоваться в классе 0.
     
     13.6.1 Структура
     
     ПБДТ ПР должен иметь следующую структуру:
         

     
     13.6.2 УД
     
     См. 13.2.1.
     
     13.6.3 Фиксированная часть (октеты 2-6)
     
     Должна содержать:
     
     a) ПР - код подтверждения разъединения 1100 0000;
     
     b) УКАЗ-ПОЛ - см. 13.4.3;
     
     c) УКАЗ-ОТП - см. 13.4.3.
     
     13.6.4 Переменная часть
     
     Должна содержать параметр "контрольная сумма", если соблюдены условия, определенные в 13.2.3.1.
     
     13.7 ПБДТ "данные" (ДН)
     
     13.7.1 Структура
     
     В зависимости от класса и факультативной функции ПБДТ ДН должен иметь одну из следующих структур:
     
     а) Нормальный формат для классов 0 и 1
          

               
     
     b) Нормальный формат для классов 2-4
          

              
     
     с) Расширенный формат для использования в классах 2-4, если он выбран при установлении соединения
          

     
          
     13.7.2 УД
     
     См. 13.2.1.
     
     13.7.3 Фиксированная часть
     
     Должна содержать:
     
     a) ДН - код передачи данных 1111 0000;
     
     b) ЗМП - запрос метки подтверждения. Если процедура подтверждения запроса не была согласована во время установления соединения, то во всех ПБДТ ДН бит 1 должен быть установлен в 1.
     
     Если процедура подтверждения запроса была согласована во время установления соединения, то бит 1 (ЗМП) используется для подтверждения запроса в классах 1, 3 и 4. В значении 1 ЗМП указывает, что передающий логический объект транспортного уровня запрашивает подтверждения от принимающего логического объекта транспортного уровня. В противном случае ЗМП устанавливается в ноль.
     
     с) УКАЗ-ПОЛ - см. 13.4.3;
     
     d) КС - в значении 1 указывает, что текущий ПБДТ ДН является последним блоком данных полной последовательности ПБДТ ДН (конец СБДТ). КС содержится в бите 8 октета 3 в классах 0 и 1, а также в бите 8 октета 5 в классах 2-4;
     
     е) НР-ПБДТ - ПБДТ содержат порядковый номер (равный нулю в классе 0). Может принимать любое значение в классе 2 без использования явного управления потоком. НР-ПБДТ содержится в битах 7-1 октета 3 в классах 0 и 1; в битах 7-1 октета 5 для нормальных форматов в классах 2-4 и в битах 7-1 октета 5, а также октетов 6-8 для расширенного формата.
     
     Примечание - В зависимости от класса в фиксированной части ПБДТ ДН используются следующие октеты:
     

     
     13.7.4 Переменная часть
     
     Должна содержать параметр "контрольная сумма", если выполняют условия, определенные в 13.2.3.1.
     
     13.7.5 Поле "данные пользователя"
     
     Содержит данные передаваемых СБДТ.
     
     Примечание - Длина этого поля ограничена значением согласованной длины ПБДТ для данного СТУ минус три октета в классах 0 и 1 и минус пять октетов (нормальный формат заголовка) или восемь октетов (расширенный формат заголовка) в остальных классах. Наличие переменной части может дополнительно уменьшить длину данных пользователя.
     
     
     13.8 ПБДТ "срочные данные" (СД)
     
     Не должны использоваться в классе 0, а также в классе 2, если не выбрана факультативная функция явного управления потоком или если для данного соединения не выбрана услуга передачи срочных данных.
     
     13.8.1 Структура
     
     В зависимости от формата, согласованного при установлении соединения, ПБДТ СД должен иметь одну из следующих структур:
     
     а) Нормальный формат (классы 1-4)
          

     
          
     b) Расширенный формат (для использования в классах 2-4, если он выбран при установлении соединения)
          

     
          
     13.8.2 УД
     
     См. 13.2.1.
     
     13.8.3 Фиксированная часть
     
     Должна содержать:
     
     a) СД - код срочных данных 0001 0000;
     
     b) УКАЗ-ПОЛ - см. 13.4.3;
     
     с) НР-ПБДТ-СД - номер, идентифицирующий срочный ПБДТ. НР-ПБДТ-СД используется в классах 1, 3, 4 и может принимать любое значение в классе 2. Биты 7-1 октета 5 для нормальных форматов; биты 7-1 октета 5 вместе с октетами 6-8 для расширенных форматов;
     
     d) КС - конец СБДТ всегда устанавливается в 1(бит 8 октета 5).
     
     Примечание - В зависимости от формата фиксированная часть должна содержаться в октетах 2-5 или 2-8.
     
     
     13.8.4 Переменная часть
     
     Должна содержать параметр "контрольная сумма", если соблюдены условия, определенные в 13.2.3.1.
     
     13.8.5 Поле "данные пользователя"
     
     Содержит срочный СБДТ (длиной от 1 до 16 октетов).
     
     13.9 ПБДТ "подтверждение данных" (ПД)
     
     Не должен использоваться в классе 0, в классе 2, если не выбрана факультативная функция явного управления потоком, и в классе 1, если выбрана факультативная функция сетевого уведомления о приеме.
     
     13.9.1 Структура
     
     В зависимости от согласованных класса и факультативной функции ПБДТ ПД должен иметь одну из следующих структур.
     
     а) Нормальный формат (классы 1-4)
          

     
          
     b) Расширенный формат (для использования в классах 2-4, если он выбран при установлении соединения)
          

     
              
     13.9.2 УД
     
     См. 13.2.1.
     
     13.9.3 Фиксированная часть
     
     Должна содержать (в октетах 2-5, если используется нормальный формат, и в октетах 2-10 - в остальных случаях) следующие параметры:
     
     а) ПД - код подтверждения 0110 0000;
     
     b) КРД - значение кредита (устанавливается в значение 1111 в классе 1). Биты 4-1 октета 2 для нормальных форматов и октетов 9 и 10 для расширенных форматов;
     
     с) УКАЗ-ПОЛ - см. 13.4.3;
     
     d) НР-ОТВ - порядковый номер, указывающий номер следующего ожидаемого ПБДТ ДН. Для нормальных форматов биты 7-1 октета 5; бит 8 октета 5 не является значащим и должен устанавливаться в ноль. Для расширенных форматов биты 7-1 октета 5, а также октетов 6-8; бит 8 октета 5 не является значащим и должен устанавливаться в ноль.
     
     13.9.4 Переменная часть
     
     Должна содержать следующие параметры:
     
     a) контрольную сумму, если выполнено условие 13.2.3.1;
     
     b) номер подпоследовательности при факультативном использовании в условиях, определенных в классе 4. Этот параметр используется для того, чтобы гарантировать правильную последовательность обработки ПБДТ ПД. Его отсутствие эквивалентно передаче этого параметра в значении ноль.
     
     Код параметра - 1000 1010.
     
     Длина параметра - 2.
     
     Значение параметра - номер 16-битовой последовательности;
     
     c) подтверждение управления потоком при факультативном использовании в условиях, определенных в классе 4. Этот параметр содержит копию информации, принятой в ПБДТ ПД, обеспечивающую для передатчика ПБДТ ПД точную информацию о состоянии принимающего логического объекта транспортного уровня (см. 12.2.3.9).
     
     Код параметра - 1000 1100.
     
     Длина параметра - 8.
     
     Значение параметра - определяется следующим образом:
     
     1) нижняя граница окна (32 бита). Бит 8 октета 1 поля "значение параметра" установлен в ноль, остальная часть содержит значение НР-ОТВ принятого ПБДТ ПД. При использовании нормального формата значащими являются только семь самых младших битов (биты 1-7) этого поля;
     
     2) ваша подпоследовательность (16 бит). Содержит значение параметра подпоследовательности принятого ПБДТ ПД или ноль, если этот параметр отсутствует;
     

     3) ваш кредит (16 бит). Содержит значение поля КРД принятого ПБДТ ПД. При использовании нормального формата значащими являются только четыре самых младших бита (биты 1-4 октета 2) этого поля.
     
     d) Параметры избирательного подтверждения при факультативном использовании при условиях, определенных в классе 4 для подтверждения вышедших из последовательности ПБДТ ДН, полученных логическим объектом, передавшим ПБДТ ПД. Все последовательно полученные ПБДТ ДН должны быть подтверждены одним блоком. Различные группы ПБДТ ДН, которые передаются последовательно между группами, но не среди групп, должны подтверждаться отдельными блоками (например, если ПБДТ ДН с номерами 3, 4, 5, 7, 8, 12, 13, 15 и 17 получены с номером 3 первого непоследовательного ПБДТ ДН, то блоки 3-5 формируют первую группу, 7 и 8 - вторую, 12-15 - третью, а 17 - четвертую. Соответствующими блоками будут (3, 5), (7, 8), (12, 15) и (17, 17).
     
     Код параметра - 1000 1111.
     
     Длина параметра - 2 (нормальный формат) или 8 (расширенный формат) октетов, где  - номер при избирательном подтверждении различных блоков. Эта длина ограничивается максимальной длиной заголовка 254 октета.
     
     Значение параметра - при нормальном формате первый из двух октетов должен представлять нижнюю границу, а второй - верхнюю каждого блока. Бит 8 каждого октета устанавливается в 0, остальные представляют порядковый номер границы.
     
     При расширенном формате первые четыре октета из восьми должны представлять нижнюю границу, а следующие четыре - верхнюю. Для каждой границы четырех октетов бит 8 первого октета является незначащим и устанавливается в ноль; биты 7-1 первого октета вместе со вторым, третьим и четвертым октетами представляют порядковый номер.
     
     При любом из форматов каждый набор из двух или восьми октетов может быть повторен многократно для подтверждения блоков.
     
     13.10 ПБДТ подтверждения срочных данных (ПСД)
     
     Не должен использоваться в классе 0, а также в классе 2, если выбрана факультативная функция неявного управления потоком или если для данного соединения не выбрана услуга передачи срочных данных.
     
     13.10.1 Структура
     
     В зависимости от факультативной функции (нормальный или расширенный формат) этот ПБДТ должен иметь следующую структуру.
     
     1) Нормальный формат (классы 1-4)
          

     
          
     2) Расширенный формат (для использования в классах 2-4, если он выбран при установлении соединения)
          

     
         
     13.10.2 УД
     
     См. 13.2.1.
     
     13.10.3 Фиксированная часть
     
     Должна содержать (в октетах 2-5 при использовании нормального формата или в октетах 2-8) следующие параметры:
     
     а) ПСД - код подтверждения срочных данных 0010 0000;
     
     b) УКАЗ-ПОЛ - см. 13.4.3;
     
     с) НР-СПБДТ-ОТВ - идентификатор ПБДТ СД, подлежащий подтверждению; в классе 2 может принимать любое значение. При нормальных форматах размещен в битах 7-1 октета 5; бит 8 октета 5 не является значащим и должен устанавливаться в ноль. При расширенных форматах - в битах 7-1 октета 5, а также октетов 6, 7 и 8; бит 8 октета 5 не является значащим и должен устанавливаться в ноль.
     
     13.10.4 Переменная часть
     
     Может содержать параметр "контрольная сумма" (см. 13.2.3.1)
     
     13.11 ПБДТ "отказ" (ОТК)
     
     Не должен использоваться в классах 0, 2 и 4.
     
     13.11.1 Структура
     
     ПБДТ ОТК должен иметь один из следующих форматов:
     
     а) нормальный формат (классы 1 и 3)
          

     
     b) расширенный формат (для использования в классе 3, если он выбран при установлении соединения)
          

     
     
     13.11.2 УД
     
     См. 13.2.1.
     
     13.11.3 Фиксированная часть
     
     Должна содержать (в октетах 2-5 при нормальном формате или в октетах 2-10) следующие параметры:
     
     а) ОТК - код отказа 0101; биты 8-5 октета 2;
     
     b) КРД - значение кредита (устанавливается в 1111 в классе 1); размещен в битах 4-1 октета 2 при нормальных форматах и октетов 9 и 10 при расширенных форматах;
     
     с) УКАЗ-ПОЛ - см. 13.4.3;
     
     d) НР-ОТВ - порядковый номер, указывающий следующий ожидаемый ПБДТ, с которого должна начинаться повторная передача. При нормальных форматах размещен в битах 7-1 октета 5; бит 8 октета 5 не является значащим и должен устанавливаться в ноль. При расширенных форматах размещен в битах 7-1 октета 5, а также октетов 6-8; бит 8 октета 5 не является значащим и должен устанавливаться в ноль.
     
     13.11.4 Переменная часть
     
     В этом типе ПБДТ переменной части нет.
     
     13.12 ПБДТ "ошибка" (ОШ)
     
     13.12.1 Структура
     
     ПБДТ ОШ должен иметь следующий формат
          

     
          
     13.12.2 УД
     
     См. 13.2.1.
     
     13.12.3 Фиксированная часть
     
     Должна содержать следующие параметры:
     
     а) ОШ - код ПБДТ "ошибка" 0111 0000;
     
     b) УКАЗ-ПОЛ - см. п.13.4.3;
     
     с) причина отказа - 0000 0000 причина не определена,
     
     0000 0001 недействительный код параметра,
     
     0000 0010 недействительный тип ПБДТ,
     
     0000 0011 недействительное значение параметра.
     
     13.12.4 Переменная часть
     
     Может содержать следующие параметры:
     
     а) недействительный ПБДТ
     
     Код параметра - 1100 0001
     
     Длина параметра - число октетов поля "значение параметра"
     
     Значение параметра - содержит битовую комбинацию непринятого заголовка ПБДТ, включая октет, вызвавший отказ. Этот параметр обязателен в классе 0;
     
     b) контрольную сумму. Этот параметр должен иметь место, если соблюдены условия 13.2.3.1.
     

     ЧАСТЬ 3. АТТЕСТАЦИОННЫЕ ТРЕБОВАНИЯ

     
     14 Соответствие

     
     14.1 Система, претендующая на реализацию процедур, определенных в настоящем стандарте, должна соответствовать требованиям 14.2-14.5.
     
     14.2 Система должна реализовывать либо класс 0, либо 2, либо оба эти класса. Это предполагает работу с использованием УСУ-УС.
     
     14.3 Если система реализует класс 3 или 4, она должна реализовывать также класс 2.
     
     14.4 Если система реализует класс 1, она должна реализовывать также класс 0.
     
     14.5 В каждом классе, на реализацию которого претендует система, она должна быть способна
     
     a) либо инициировать ПБДТ ЗС, либо в ответ на ПБДТ ЗС выдавать ПБДТ ПС, либо то и другое;
     
     b) отвечать на любой другой ПБДТ и обеспечивать функционирование УСУ в соответствии с процедурами данного класса;
     
     c) обеспечивать функционирование всех процедур данного класса, перечисленных как обязательные в таблице 9;
     
     
Таблица 9 - Обеспечение факультативных возможностей
     

     
     Обозначения: Н - не используется; О - обязательная; Ф - факультативная.
     
     
     d) обеспечивать функционирование тех процедур данного класса, указанных в таблице 9 как факультативные, соответствие которым заявлено;
     
     e) обрабатывать все ПБДТ, длина которых может достигать наименьшего из значений:
     
     1) максимальной для данного класса, если параметр "предпочтительная длина ПБДТ" не реализован (см. 13.3.4b);
     
     2) максимальной, соответствие которой заявлено (см. примечание 2).
     
     Примечания
     
     1 Процедуры классов 0-4 определены в разделах 8-12 соответственно. Эти процедуры ссылаются на элементы процедур, определенные в разделе 6.
     
     2 Требование 14.5е говорит о том, что длина ПДБТ 128 октетов всегда реализуема.
     
     
     14.6 В заявках на соответствие должно указываться следующее:
     
     а) какой класс или классы протокола реализованы;
     
     b) способен ли класс 4 протокола работать с УСУ-БУС;
     
     c) способна ли система инициировать ПБДТ ЗС либо отвечать на него, либо выполнять то и другое;
     
     d) какие из процедур, указанных в таблице 9 как факультативные, реализуются;
     
     e) для каждого класса максимальная длина реализуемых ПБДТ [см. 13.3.4b, с]. Если параметр "предпочтительная максимальная длина ПБДТ" не реализован, его значение следует выбирать из следующего перечня:
     
     128, 256, 512, 1024, 2048, 4096 или 8192 октетов и все значения, меньшие указанного максимального, должны быть реализуемы.
     
     Если параметр "предпочтительная максимальная длина ПБДТ" реализован, допустима любая максимальная длина ПБДТ, кратная 128 октетам. Все значения, кроме 0, кратные 128 октетам и меньшие максимальной заявленной, должны быть реализованы.
     
     14.7 Поставщик протокольной реализации, заявленной на соответствие настоящему стандарту, должен заполнить экземпляр формы ЗСРП, приведенной в приложении D, и предусмотреть в ней информацию, необходимую для идентификации поставщика и реализации.
     

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

ТАБЛИЦЫ СОСТОЯНИЙ

     
     А.1 Общие положения

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

     А.2 Соглашения

     
     А.2.1 Входящие события представлены в таблицах состояний их сокращенными наименованиями, приведенными в таблице 10.
     
     
Таблица 10 - Входящие события