ГОСТ 28907-91 Системы обработки информации. Локальные вычислительные сети. Протокол и услуги уровня управления логическим звеном данных

ГОСТ 28907-91

(ИСО 8802-2-89)

МЕЖГОСУДАРСТВЕННЫЙ СТАНДАРТ

СИСТЕМЫ ОБРАБОТКИ ИНФОРМАЦИИ

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

Издание официальное

2004

Моски Стандарта нфоуш ЮМ

УДК 681.3.01:006.354

Группа 1185

М Е Ж Г О С У Д Л Р С 1 В Е Н И Ы Й С Г Л И Д А Р I

Системы обработки информации

ЛОКАЛЬНЫЕ ВЫЧИСЛИТЕЛЬНЫЕ СЕТИ.

ПРОТОКОЛ И УСЛУГИ УРОВНЯ УПРАВЛЕНИЯ ЛОГИЧЕСКИМ ЗВЕНОМ ДАННЫХ

МКС 53.100

ОКСТУ 4002

Information processing systems.

Local area networks. Logical link control protocol and service specification

ГОСТ 28907-91 (ИСО 8802-2-89)

Дата введения 01.07,91

1. ВВЕДЕНИЕ

1.1. Назначение и область применения

Настоящий стандарт — один из совокупности стандартов, разрабатываемых для обеспечения взаимосвязи ЭВМ и терминалов посредством локальной вычислительной сети (ЛВС). Его отношение к другим стандартам определено эталонной .моделью взаимосвязи открытых систем в соответствии с ГОСТ 28906.

Требования данного стандарта являются обязательными.

П р н м с ч а н н с. Точное отношение уровней, определяемых настоящим стандартом, к уровням, определенным эталонной моделью взаимосвязи открытых систем (ВОС), находится в стадии изучения.

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

В стандарте приведены спецификации услуг подуровня УЛЗ, предоставляемых сетевому уровню (уровню 3). подуровню УДС. и функции управления подуровнем УЛЗ. Спецификация услуг на интерфейсе с сетевым уровнем содержит описание различных услуг, которые подуровень УЛЗ вместе с нижерасположенпыми уровнями и подуровнями предоставляет сетевому уровню.

Спецификация услуг на интерфейсе с подуровнем УДС содержит описание услуг, которые подуровень УЛЗ требует от подуровня УДС. Эти услуги определены в виде, не зависящем от конкретных методов доступа к физической среде и от типа самой физической среды. Спецификация услуг для функции управления подуровнем УЛЗ содержит описание управляющих услуг, которые предоставляются подуровню УЛЗ. Все указанные выше спецификации услуг даны в форме примитивов, которые представляют абстрактный способ логического обмена информацией и управляющими сигналами между подуровнями УЛЗ и указанной функцией услуг (сетевым уровнем, подуровнем УДС или функцией управления подуровня УЛЗ). Они не определяют и не налагают никаких ограничений на конкретную реализацию логических объектов или интерфейсов.

Издание официальное

Перепечатка воспрещена

© Издательство стандартов. 1991 © Стандарт нформ. 2005

С. 2 ГОСТ 28907-91

Взаимоотношение ЛВС и эталонной модели

УЛЗ

уде

Уровень звена, данные

Физический уровень

Фазический уровень

Среда

Черт. 1.1

Стандарт содержит описание протокольных процедур равноправных логических объектов, которые определены для обмена информацией и управляющими сигналами между любой парой пунктов доступа к услугам уровня звена данных ЛВС. Процедуры УЛЗ не зависят от метода доступа к физической среде, используемого в конкретной ЛВС.

Для обеспечения широкого круга возможных применений введены два типа операций управления звеном данных (см. разд. 4). Первый тип операций (см. разд. 6) обеспечивает услуги звена данных без установления соединения через звено данных при минимальной сложности протокола. Этот тип операций может использоваться в тех случаях, когда вышерасположенные уровни обеспечивают все существенно необходимые услуги по восстановлению и сохранению последовательности передачи, и их не требуется повторять на уровне звена данных. Кроме того, этот тип операций может оказаться полезным в тех применениях, где гарантия доставки каждого блока данных уровня звена данных не является существенно необходимой. Такой тип услуг описан в настоящем стандарте в понятиях «логических звеньев данных». Второй тип операций (см. разд. 7) обеспечивает услуги звена данных с установлением соединения через звено данных, совместимые с существующими процедурами управления звеном данных, определенными, например ГОСТ 28080. Эти услуги обеспечивают поддержание упорядоченной доставки блоков данных уровня звена данных, а также широкий набор методов обнаружения ошибок на уровне звена данных. Этот второй тип услуг описан в настоящем стандарте в понятиях «соединений звена данных».

В настоящем стандарте определены два различных «класса» операций УЛЗ. Класс 1 обеспечивает услуги звена данных только в режиме-без-установлеиия-соелинения. Класс 2 обеспечивает услуги звена данных как в режиме-с-установлением-соелинения, так и в режи-ме-без-установления-соединения. Может обеспечиваться любой из двух классов операций.

Определенные здесь базовые протоколы — это равноуровневые протоколы, ориентированные на использование в многостанционных функциональных средах с групповым доступом. Ориентация на многостанционную среду с групповым доступом предполагает, что каждая станция должна быть способна участвовать во многих равноуровневых протокольных обменах данных со многими различными станциями через множество различных звеньев данных и/или соединений звена данных, обеспечиваемых единым физическим уровнем по единой физической среде. Каждая двухнаправленная связь между парой логических объектов на уровне звена данных должна определять отдельное логическое звено данных или соединение звена данных со своими логическими параметрами и переменными. За исключением особо оговоренных случаев определяемые в данном разделе процедуры следует относить к каждому логическому звену данных или соединению звена данных на уровне звена данных по отдельности и независимо от любого другого логического звена данных или соединения звена данных, которое может существовать в рассматриваемой станции.

1.2. Совместимость стандартов

Равноуровневые протокольные процедуры, определенные в разд. 5. используют некоторые концепции и принципы, а также команды и ответы сбалансированных процедур управления звеном данных, известных под названием «режим асинхронный сбалансированный (РАС)» и

ГОСТ 28907-91 С. 3

определенных в ГОС! 28080. Структура кадра для процедур уровня звена данных в целом определена частично в разд. 3 настоящего стандарта и частично в тех стандартах, которые определяют различные процедуры УДС. Для каждого пункта доступа к услугам уровня звена данных сочетание адресов подуровня УДС и подуровня УЛЗ является единственным во всей ЛВС.

Примечай и е. Такое разделение адресного пространства уровня звена данных на отдельные поля адресов УДС и УЛЗ нс является частью каких бы то ни было государственных стандартов по уровню звена данных.

1.3. Ссылки

ГОСТ 24402—88 Телеобработка данных и вычислительные сети. Термины и определения

ГОСТ 28080—89 Системы обработки информации. Протокол уровня звена данных. Метод синхронной побитовой передачи данных

ГОСТ 28906-91 (ИСО 7498-84. Доп. 1-84 И СО 7498-84) Системы обработки информации. Взаимосвязь открытых систем. Базовая эталонная модель

1.4. Сокращения и пояснения

1.4.1 Сокращения

(См. приложение 1).

1.4.2. Пояснения

В настоящем стандарте использованы следующие пояснения терминов:

принятие: Состояние, в котором находится УЛЗ, при приеме правильного II БД для его дальнейшей обработки.

поля адреса (ПДУП и ПДУО): Упорядоченная пара адресов пункта доступа к услугам в начальной части IIБД УЛЗ, которые идентифицируют УЛЗ. назначенный(ые) для приема IIБД, и УЛЗ, передающий 11 БД. Длина каждого поля адреса равна одному остету.

основное состояние: Состояние подуровня УЛЗ, в котором он способен передавать или принимать ПБД, содержащие поле информации.

команда: При передаче данных инструкция, содержащаяся в поле управления ПБД и передаваемая УЛЗ. Она побуждает адресуемый!ые) УЛЗ выполнить определенную управляющую функцию звена данных.

командный ПБД: Любой ПБД, передаваемый подуровнем УЛЗ. с битом К/О, установленным в значение 0.

поле управления (У): Поле, следующее непосредственно за полями адресов ПДУП и ПДУО ПБД. Содержимое поля управления интерпретируется принимающим!и) адресуемым(и) УЛЗ. указанным полем адреса ПДУП:

а) как команда УЛЗ — отправителя, указанного в поле адреса ПДУО. предписывающего выполнить некоторую конкретную функцию;

б) как ответ от УЛЗ — отправителя, указанного полем адреса ПДУО.

звено данных: Совокупность двух или более оконечных установок и соединительного канала связи, функционирующих в соответствии с конкретным методом обмена информацией; в данном контексте понятие «оконечная установка» не содержит источник данных и получателя данных.

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

особое условие: Условие, которое возникает на УЛЗ при получении командного ПБД. которое он не может выполнить из-за ошибки передачи или неправильного функционирования собственных средств обработки.

глобальный (общий) адрес ПДУП: Заранее определенный адрес ПДУП УЛЗ (все биты равны 1). используемый как общий адрес всех станций. Этот адрес никогда не может быть адресом отдельного УЛЗ в звене данных.

С. 4 ГОСТ 28907-91

групповой (многостанционный) адрес 11ДУ11: Адрес получателя, накаченный совокупности УЛЗ для упрощения их коллективной адресации. Младший бит этого адреса всегда должен быть равен 1.

вышерасположенный уровень: Концептуальный уровень управления или логических функций обработки в иерархической структуре станции, который расположен выше уровня звена данных и от которого зависит выполнимость функций уровня звена данных (например управление устройствами, распределение буферов, управление подуровнем УЛЗ станции и др.).

поле информации: Последовательность октетов между полем управления и конном ПБД УЛЗ. Содержимое поля информации протокольных блоков данных И. ГЕСТ и НИ не интерпретируется подуровнем УЛЗ.

недействительный кадр: ПБД, который либо

а) не содержит целого числа октетов, либо

б) не содержит по меньшей мере двух адресных октетов и управляющего октета, либо

в) определен физическим уровнем или подуровнем УДС как ПБД. содержащий ошибочные биты данных.

УЛЗ — та часть станнин данных, которая обеспечивает функции управления логическим звеном для двух или более логических звеньев. УЛЗ генерирует командные ПБД и ответные ПБД для передачи и интерпретирует принимаемые командные ПБД и ответные ПБД. На подуровень УЛЗ возлагаются следующие конкретные задачи:

а) инициация обмена управляющими сигналами;

б) организация потока данных;

в) интерпретация принятых командных ПБД и генерация соответствующих ответных ПБД:

г) действия, относящиеся к обработке ошибок и к функциям исправления ошибок на подуровне УЛЗ.

УДС — та часть станции данных, которая выполняет функции управления доступом к физической среде, расположенные непосредственно под подуровнем управления логическим звеном. К процедурам подуровня УДС относятся формирование кадров данных из блоков данных и их расформирование, контроль ошибок и назначение права на доступ к физической среде.

N-уровень: Часть архитектуры. образова>п<ая подсистемами одного и того же ранга (N).

N-пользователь: (N+1)-й логический объект, пользующийся услугами — уровня и ниже-расположенных уровней для взаимодействия с другими (N+D-м логическим объектом.

октет: Биториенгированный элемент, состоящий из восьми последовательных двоичных битов.

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

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

ответ: В передаче данных ответ, содержащийся в поле управления ответного ПБД. Он извещает адресуемого УЛЗ-получателя о действиях, выполненных УЛ 3-отправителем при получении одного или нескольких командных ПБД.

ответный ПБД: Любой ПБД. посланный подуровнем УЛЗ. в котором бит К/О равен I.

услуги: Возможности и средства, предоставляемые N-уровнем N-пользователю.

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

Примечание. Термины и определения — по ГОСТ 24402.

2. СПЕЦИФИКАЦИЯ УСЛУГ ПОДУРОВНЯ УЛЗ

В данном разделе определяются услуги, запрашиваемые или обеспечиваемые подуровнем УЛЗ на логических интерфейсах с сетевым уровнем, подуровнем УДС и функцией управления подуровнем УЛЗ.

ГОСТ 28907-91 С. 5

В общем случае услуги уровня (или подуровня) - это те возможности, которые он предоставляет пользователю, находящемуся в смежном вышерасположенном уровне (или подуровне). Для того, чтобы обеспечить эти услуги, уровень (или подуровень) выполняет свои функции на основе услуг, запрашиваемых от смежного нижележащего уровня (или подуровня). На черт. 2.1 показаны такая иерархия услуг и взаимоотношение двух N-пользователей-корреспондентов и связанных с ними разноуровневых протокольных логических объектов N-уровня (или подуровня).

Служебные примитивы

Пользователь услуги

ЗАПРОС------*

ПОДТВЕРЖДЕНИЕ

Поставщик услуги

Пользователь услуги

----► ИНДИКАЦИЯ

■*---ОТВЕТ

Черт. 2.1

Спецификация услуг проводится путем описания потока информации между «-пользователем и «-уровнем (или подуровнем). Поток информации моделируется дискретными мгновенными событиями, которые характеризуют обеспечение услуги. Каждое событие состоит из передачи примитива от одного уровня (или подуровня) к другому через пункт доступа к услугам «-уровня (или подуровня), связанный с «-пользователем. Служебные примитивы переносят информацию, необходимую для обеспечения конкретной услуги. Эти служебные примитивы представляют собой абстракцию, определяющую только обеспечиваемую услугу, но не средства. обеспечивающие эту услугу. Такое определение услуги не зависит от какой бы то ни было конкретной реализации интерфейса.

Спецификация услуг проводится путем описания служебных примитивов и параметров, характеризующих каждую услугу. Услуга может иметь один или несколько соответствующих примитивов, которые вызывают действия, относящиеся к конкретной услуге. Каждый служебный примитив может не иметь параметров или иметь несколько параметров, содержащих информацию. необходимую для обеспечения данной услуги.

Все примитивы подразделяют на четыре общих типа:

ЗАПРОС - примитив запроса перелается от «-пользователя к «-уровню (или подуровню) для запроса инициации услуги.

ИНДИКАЦИЯ — примитив индикации передается от «-уровня (или подуровня) к «-пользователю для информирования последнего о внутреннем событии «-уровня (или подуровня), значимого для «-пользователя. Такое событие может быть логически связано с удаленным запросом услуги или обусловлено внутренним событием «-уровня (или подуровня).

ОТВЕТ — примитив ответа передается от «-пользователя к «-уровню (или подуровню) для завершения процедуры, инициированной предыдущим примитивом индикации.

ПОДТВЕРЖДЕНИЕ - примитив подтверждения передается от «-уровня (или подуровня) к «-пользователю с целью передачи результатов выполнения одного или нескольких предыдущих запросов соответствующих услуг.

Возможные взаимоотношения между различными типами примитивов показаны в виде временной диаграммы на черт. 2.2. На нем показаны также логические взаимоотношения между типами примитивов. Те типы примитивов, которые на диаграмме появляются раньше во времени, соединены пунктирными линиями, логически предшествуют следующим во времени типам примитивов.

С. 6 ГОСТ 28907-91

2.1. Спецификация услуг на интерфейсе между сетевым уровнем и подуровнем УЛЗ

В данном разделе определены с точки зрения сетевого уровня услуги, запрашиваемые сетевым уровнем от подуровня УЛЗ с целью обеспечения обмена данными между локальным и удаленным логическим объектом сетевого уровня. Эти услуги описаны в абстрактном виде и не подразумевают какой-либо конкретной реализации или какого-либо детализированного интерфейса.

Предусмотрены два вида услуг: услуги в режиме-без-устаковдения-соединения и без подтверждения. и услуги в режиме-с-установлением-соединения.

Услуга в режиме-без-установления-соединения и без подтверждения — это услуга передачи данных, которая обеспечивает средства, с помошью которых логические объекты сетевого уровня могут обмениваться сервисными блоками данных звена (СБДЗ) без установления соединения на уровне звена данных. Передача данных может быть двухпунктовой групповой или широковещательной (глобальной).

Услуги в режиме-с-усгановлеинсм-соединення. Этот набор услуг обеспечивает средства для установления, использования, сброса и завершения соединений на уровне звена данных. Эти соединения являются двухпунктовыми между ПДУ3.

Услуга установления соединения обеспечивает средства, с помошью которых логический объект сетевого уровня может запросить установление соединений на уровне звена данных или быть проинформированным об установлении таких соединений.

Временные диаграммы

Запрос^

Запрос

Индикация

Индикация

Ответ

Индикации _ Ответ

Индикация

Запрос _ Подтверждение

д

Индикация

Запрос

Подтверждение

Запрос Подтверждение

Запрос

Индикация

Черт. 2.2

- ^ _ Индикация

Ответ

е

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

ГОСТ 28907-91 С. 7

Услуга сброса соединения обеспечивает средства, с помошью которых установленное соединение может быть возвращено в исходное состояние.

Услуга завершения соединения обеспечивает средства, с помощью которых логический объект сетевого уровня может запросить завершение соединения на уровне звена данных или может быть проинформирован о завершении такого соединения.

Услуга управления потоком по соединению обеспечивает средства управления потоком данных, относящихся к указанному соединению, на интерфейсе между сетевым уровнем и уровнем звена данных.

2.1.1. Краткое описание взаимодействий

2.1.1.1. Услуги в режиме-без-установления-соединений и без подтверждений

2.1.1.1.1. Передача данных в режиме-без-установлення-соединений н без подтверждений. В фазе передачи данных в режиме-без-установления-соединений и без подтверждений используются следующие примитивы:

ЗД-БЛОК-ДАН НЫХ. запрос

ЗД-БЛОК-ДАННЫХ. индикация

Примитив ЗД-БЛОК-ДАННЫХ. запрос передается подуровню УЛЗ для запроса передачи СБДЗ с использованием процедур режима-без-усгаиовления-соединения и без подтверждений. Примитив ЗД-БЛОК-ДАННЫХ. индикация передается из подуровня УЛЗ для информирования о поступлении СБДЗ.

2.1.1.2. Услуги режима-с-установлением-соединения

2.1.1.2.1. Установление соединения. При установлении соединения используются следующие примитивы:

ЗД-СОЕДИНЕНИЕ. запрос

ЗД-СОЕДИНЕНИЕ. индикация

ЗД-СОЕДИНЕНИЕ. ответ

ЗД-СОЕДИНЕНИЕ. подтверждение

Примитив ЗД-СОЕДИНЕНИЕ. запрос передается подуровню УЛЗ для запроса установления соединения логического звена между локальным ПДУЗ и удаленным ПДУЗ. Примитив ЗД-СОЕДИНЕНИЕ индикация передается подуровнем УЛЗ для информирования о запросе удаленного логического объекта на установление соединения с локальным ПДУЗ. Примитив ЗД-СОЕДИНЕНИЕ. ответ передается подуровню УЛЗ для сигнализации приемлемости соединения. Примитив ЗД-СОЕДИНЕНИЕ. подтверждение перелается подуровнем УЛЗ для передачи результатов выполнения предыдущего примитива ЗД-СОЕДИНЕНИЕ. запрос.

2.1.1.2.2. Передача данных в режиме-с-установлепием-соединення. К передаче данных в режиме-с-установлением-соединения относятся следующие примитивы:

ЗД-ДАННЫЕ. запрос

ЗД-ДАННЫЕ. индикация

Примитив ЗД-ДАННЫЕ. запрос передается подуровню УЛЗ для запроса передачи СБДЗ с использованием процедур режима-с-установленнем-соединения. Примитив ЗД-ДАННЫЕ. индикация передается подуровнем УЛЗ для информирования о поступлении СБДЗ.

2.1.1.2.3. Завершение соединения. При завершении соединения используются следующие примитивы:

ЗД-РАЗЪЕДИ Н ЕН И Е. запрос

ЗД- РАЗ ВЕДИ НЕН НЕ. индикация

Примитив ЗД-РАЗЪЕДИНЕНИЕ, запрос передается подуровню УЛЗ для запроса немедленного завершения соединения звена данных. Примитив ЗД-РАЗЬЕДИНЕНИЕ, индикация передается подуровнем УЛЗ для информирования сетевого уровня о том. что соединение завершено.

2.1.1.2.4. Сброс соединения. При сбросе соединения используются следующие примитивы:

ЗД-СБРОС. запрос

ЗД-СБРОС. индикация

ЗД-СБРОС. ответ

ЗД-СБРОС. подтверждение

С. 8 ГОСТ 28907-91

Примитив ЗД-СБРОС. запрос передается подуровню УЛЗ для запроса немедленного сброса соединения в исходное состояние. Примитив ЗД-СБРОС. индикация передается подуровнем УЛЗ для информирования о попытке сброса соединения удаленным логическим объектом или локальным подуровнем УЛЗ. Примитив ЗД-СБРОС. ответ передается подуровню УЛЗ для сигнализации приемлемости условия сброса. Примитив ЗД-СБРОС. подтверждение передается подуровнем УЛЗ для передачи результатов выполнения предыдущего примитива ЗД-СБРОС. запрос.

2.1.1.2.5. Управление потоком в соединении. При управлении потоком в соединении используются следующие примитивы:

ЗД- СОЕД И Н Е Н И Е - У П РА ВЛ Е Н И Е - П ОТО КО М. зап рос

ЗД-СОЕДИН ЕН 1П<УПРАВЛ ЕН ИЕ-ПОТОКОМ. индикация

Примитив ЗД-СОЕДИНЕНИЕ-УПРАВЛЕНИЕ-ПОТОКОМ. запрос передается подуровню УЛЗ для управления потоком примитивов ЗД-ДАННЫЕ. индикация, выдаваемых подуровнем УЛЗ и относящихся к соединению. Примитив ЗД-СОЕДИНЕНИЕ-УПРАВЛЕНИЕ-СОЕДИНЕНИЕ. индикация передается подуровнем УЛЗ для управления потоком примитивов ЗД-ДАННЫЕ. запрос, выдаваемых сетевым уровнем и относящихся к соединению.

2.1.2. Детальные спецификации услуг

В данном разделе приведено подробное описание примитивов и параметров, относящихся к указанным выше услугам. Следует отметить, что параметры определяются в абстрактном смысле. Параметры определяют ту информацию, которая должна поступать к принимающему логическому объект)¹. На конкретную реализацию метода получения этой информации не налагается никаких ограничении.

Параметры «адрес-отправителя» и «адрес-получателя» обеспечивают как минимум логическое объединение поля адреса УДС (АО и/или АП) с полем адреса УЛЗ (ПДУО и/или ПДУП). Реализация услуг, ориентированных на соединение, может осуществляться с использованием идентификатора соединения локальной значимости, определяющего параметры адреса отправителя и адреса получателя. Параметр «данные» может быть обеспечен фактической передачей СБДЗ, передачей соответствующего указателя или другими способами. Параметр «приоритет» определяет приоритетность передачи соответствующего блока данных и передается прозрачно нижерасположенному подуровню УДС соответствующими примитивами УЛЗ/УДС (см. п. 2.2). Параметр «причина» поясняет причину разъединения, в качестве которой может быть запрос удаленного логического объекта шли внутренняя ошибка подуровня УЛЗ. Параметр «объем» содержит информацию об объеме данных, который имеет право передавать логический объект УЛЗ:

2.1.2.1. ЗД-БЛОК-ДАННЫХ. запрос

2.1.2.1.1. Функция. Этот примитив является примитивом запроса услуги для службы передачи данных в режиме-без-устаиовления-соединения и без подтверждений.

2.1.2.1.2. Семантика сервисного примитива. Примитив должен иметь следующие параметры: ЗД-БЛОК ДАННЫХ, запрос (

адрес-отправителя;

адрес-получателя.

данные, приоритет

Параметры «адрес-отправителя» и «адрес-получателя» определяют локальный и удаленный ПДУЗ, участвующие в передаче блока данных. Параметр «адрес-получателя» может определять как индивидуальный, так и групповой адрес. Параметр «данные» определяет сервисный блок данных звена, подлежащий передаче логическим объектом уровня звена данных. Параметр •приоритет» определяет приоритетность, требуемую для передачи этого блока данных.

2.1.2.1.3. Условие генерации. Данный примитив передается сетевым уровнем подуровню УЛЗ для запроса передачи СБДЗ одному или нескольким удаленным ПДУЗ с использованием процедур режима-без-установления-соединения и без подтверждений.

ГОСТ 28907-91 С. 9

2.1.2.1.4. Результат приема. Поступление этого примитива побуждает подуровень УЛЗ сделать попытку передачи СБДЗ с использованием процедур режима-без-установления-соеди-нения и без подтверждении.

2.1.2.1.5. Дополни тельные замечания. Выполнение этого примитива не зависит от наличия соединения с удаленным ПДУЗ.

Возможная логическая последовательность примитивов при успешной передаче блока данных в режиме-без-установления-соединения и без подтверждений показана на черт. 2.2в.

2.1.2.2. ЗД-БЛОК ДАННЫХ, индикация

2.1.2.2.1. Функция. Этот примитив является сервисным примитивом индикации для услуги передачи блока данных в режиме-без-установления-соединения и без подтверждений.

2.1.2.2.2. Семантика сервисного примитива. Данный сервисный примитив должен содержать следующие параметры:

ЗД-БЛОК ДАННЫХ, индикация <

адрес-отправителя, адрес-получателя, данные.

приоритет )

Параметры «адрес-отправителя» и «адрес-получателя* определяют локальный и удаленный ПДУЗ. участвующие в передаче блока данных. .Адрес отправителя может определять адрес локального ПДУЗ. он может быть также групповым адресом, определяющим несколько ПДУЗ. включая локальный ПДУЗ. Параметр «данные» определяет сервисный блок данных звена, принятый логическим объектом подуровня УЛЗ. Параметр «приоритет» определяет приоритетность. необходимую для передачи этого блока данных.

2.1.2.2.3. Условие генерации. Данный примитив передается подуровнем УЛЗ сетевому уровню для его информирования о поступлении СБДЗ от указанного удаленного логического объекта.

2.1.2.2.4. Результат приема. Результат приема данного примитива сетевым уровнем не определен в настоящем стандарте.

2.1.2.2.5. Дополнительные замечания. Выполнение этого примитива не зависит от наличия соединения с удаленным ПДУЗ.

При отсутствии ошибок параметр «данные» имеет логически полное содержание, которое не отличается от содержания параметра «данные» соответствующего примитива ЗД-БЛОК-ДАННЫХ. запрос.

2.1.2.3. ЗД-СОЕДИНЕНИЕ. запрос

2.1.2.3.1. Функция. Данный примитив является сервисным примитивом запроса для услуги установления соединения.

2.1.2.3.2. Семантика сервисного примитива. Данный примитив должен обеспечивать следующие параметры:

ЗД-СОЕДИНЕНИЕ. запрос (

адрес-отправителя, адрес-получателя, приоритет )

Параметры «адрес отправителя» и «адрес-получателя» определяют локальный и удаленный ПДУЗ, между которыми должно быть установлено соединение. Параметр «приоритет* определяет приоритетность, требуемую для данного соединения.

2.1.2.3.3. Условие генерации. Данный примитив передается сетевым уровнем подуровню УЛЗ. когда логический объект сетевого уровня желает установить с удаленным ПДУЗ соединение логического звена с заданным приоритетом.

2.1.2.3.4. Результат приема. Прием данного примитива подуровнем УЛЗ побуждает локальный логический объект УЛЗ начать установление соединения с удаленным логическим объектом УЛЗ.

С. 10 ГОСТ 28907-91

2.1.2.3.5. Дополнительные замечания. Пример логической последовательности примитивов при успешном установлении соединения показан на черт. 2.2е.

2.1.2.4. ЗД-СОЕДИНЕНИЕ. индикация

2.1.2.4.1. Функция. Данный примитив является сервисным примитивом индикации для услуги установления соединения.

2.1.2.4.2. Семантика сервисного примитива. Данный примитив должен обеспечивать следующие параметры:

ЗД-СОЕДИНЕНИЕ. индикация (

адрес-отправителя.

адрес-получателя,

приоритет

)

Параметры «адрес-отправителя» и «адрес-получателя» определяют локальный и удаленный ПДУЗ, между которыми должно быть установлено соединение. Параметр «приоритет® указывает приоритетность, требуемую для данного соединения.

2.1.2.4.3. Условие генерации. Данный примитив передается подуровнем УЛЗ сетевому уровню для его информирования о запросе установления соединения с определенным приоритетом.

2.1.2.4.4. Результат приема. Логический объект сетевого уровня должен выдать примитив ЗД-СОЕДИНЕНИЕ. ответ для приема соединения либо примитив ЗД-РАЗЪЕДИНЕН НЕ. запрос для отклонения соединения.

2.1.2.4.5. Дополнительные замечания. Нет.

2.1.2.5. ЗД-СОЕДИНЕНИЕ. ответ

2.1.2.5.1. Функция. Этот примитив является сервисным примитивом ответа для услуги установления соединения.

2.1.2.5.2. Семантика сервисного примитива. Данный примитив должен содержать следующие параметры:

ЗД-СОЕДИНЕНИЕ. ответ (

ал рес-отп равителя,

ал рес-получателя,

приоритет

)

Параметры «адрес-отправителя» и «адрес-получателя» определяют локальный и удаленный ПДУЗ, между которыми должно быть установлено соединение. Параметр «приоритет® указывает приоритет, обеспеченный для этого соединения.

2.1.2.5.3. Условие генерации. Этот примитив выдается сетевым уровнем подуровню УЛ З для указания приемлемости запрошенного соединения.

2.1.2.5.4. Результат приема. Прием подуровнем УЛЗ этого примитива заставляет локальный логический объект УЛЗ принять соединение с удаленным логическим объектом УЛЗ.

2.1.2.5.5. Дополнительные замечания. Логический объект сетевого уровня может возвратить такой же приоритет, который был указан в примитиве ЗД-СОЕДИНЕНИЕ. индикация, или может выбрать более низкий приоритет. После выдачи примитива ЗД-СОЕДИНЕНИЕ. ответ логический объект сетевого уровня считает , что соединение установлено.

2.1.2.6. ЗД-СОЕДИНЕНИЕ. подтверждение

2.1.2.6.1. Функция. Данный примитив является сервисным примитивом подтверждения для услуги установления соединения.

2.1.2.6.2. Семантика сервисного примитива. Данный примитив должен содержать следующие параметры:

ЗД-СОЕДИНЕНИЕ. подтверждение (

адрес-отправителя, адрес-получателя. приоритет

Параметры «адрес-отправителя» и «адрес-получателя» определяют локальный и удаленный ПДУЗ. между которыми должно быть установлено соединение. Параметр «приоритет» указывает приоритет, обеспеченный для данного соединения.

ГОСТ 28907-91 С. II

2.1.2.6.3. Условие генерации. Данный примитив передается подуровнем УЛЗ сетевому уровню для передачи результатов выполнения предыдущего примитива ЗД-СОЕДИНЕНИЕ. запрос. Результаты указывают успешность попытки установить соединение и определяют полученный приоритет.

2.1.2.6.4. Результат приема. Логический объект сетевого уровня может использовать установленное соединение для передачи блока данных.

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

2.1.2.7. ЗД-ДАННЫЕ. запрос

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

2.1.2.7.2. Семантика сервисного примитива. Данный примитив должен содержать следующие параметры:

ЗД-ДАННЫЕ. запрос (

адрес-отправителя,

адрес-получателя,

данные )

Параметры «адрес-отправителя- и «адрес-получателя» определяют локальный и удаленный ПДУЗ соединения. Параметр «данные» определяет сервисный блок данных звена, подлежащий передаче логическим объектом подуровня УЛЗ.

2.1.2.7.3. Условие генерации. Данный примитив передается сетевым уровнем подуровню УЛЗ для запроса передачи СБДЗ удаленному ПДУЗ по существующему соединению.

2.1.2.7.4. Результат приема. Поступление этого примитива в подуровень УЛЗ побуждает его передать СБДЗ по указанному соединению посредством ориентированных на соединение процедур.

2.1.2.7.5. Дополнительные замечания. Примитив ЗД-ДАННЫЕ. запрос не содержит параметра -приоритет», поскольку приоритет должен быть единым для всех примитивов ЗД-ДАННЫЕ. запрос конкретного соединения. Возможная логическая последовательность передачи примитивов при успешной передаче блока данных в режиме-с-установлением-соедине-ния показана на черт. 2.2в.

2.1.2.8. ЗД-ДАННЫЕ. индикация

2.1.2.8.1. Функция. Этот примитив является сервисным примитивом индикации для услуги передачи блока данных в режиме-с-устаноюением-соелинения.

2.1.2.8.2. Семантика сервисного примитива. Данный примитив должен содержать следующие параметры:

ЗД-ДАННЫЕ. индикация (

адрес-отправителя.

адрес-получателя,

данные

)

Параметры «адрес-отправителя- и «адрес-получателя» определяют локальный и удаленный ПДУЗ данного соединения.

Параметр «данные» определяет сервисный блок данных звена, который был принят логическим объектом подуровня УЛЗ.

2.1.2.8.3. Условие генерации. Данный примитив передается подуровнем УЛЗ сетевому уровню для информирования о поступлении СБДЗ от указанного удаленного логического объекта сетевого уровня по конкретному соединению.

2.1.2.8.4. Результат приема. Результат приема сетевым уровнем данного примитива не определен в настоящем стандарте.

2.1.2.8.5. Дополнительные замечания. При отсутствии ошибок параметр «данные» не отличается от аналогичного параметра соответствующего примитива ЗД-ДАННЫЕ. запрос.

2.1.2.9. ЗД-РАЗЪЕДИНЕНИЕ, запрос

2.1.2.9.1. Функция. Данный примитив является сервисным примитивом запроса для услуги завершения соединения.

2.1.2.9.2. Семантика сервисного примитива. Данный примитив должен содержать следующие параметры:

С. 12 ГОСТ 28907-91

ЗД-РАЗЪЕДИНЕНИЕ. запрос (

адрес-отправителя, адрес-получателя )

Параметры «адрес-отправителя» и «адрес-получателя» определяют локальный и удаленный ПДУЗ соединения, которое должно быть завершено.

2.1.2.9.3. Условие генерации. Данный примитив передается сетевым уровнем подуровню УЛЗ. когда логический объект сетевого уровня желает завершить соединение.

2.1.2.9.4. Результат приема. Прием данного примитива побуждает подуровень УЛЗ немедленно завершить данное соединение.

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

Возможная логическая последовательность примитивов при успешном завершении соединения показана на черт. 2.2в.

2.1.2.10. ЗД-РАЗЪЕДИНЕНИЕ. индикация

2.1.2.10.1. Функция. Данный примитив является сервисным примитивом индикации для услуги завершения соединения.

2.1.2.10.2. Семантика сервисною примитива. Данный примитив должен содержать следующие параметры:

ЗД-РАЗЪЕДИНЕНИЕ. индикация (

адрес-отправителя.

адрес-получателя.

причина

)

Параметры «адрес-отправителя» и «адрес-получателя» определяют локальный и удаленный ПДУЗ соединения, которое должно быть завершено. Параметр «причина» указывает причину разъединения. Причиной разъединения может быть запрос со стороны удаленного логического объекта или внутренняя ошибка подуровня УЛЗ.

2.1.2.10.3. Условие генерации. Данный примитив передается подуровнем УЛЗ сетевому уровню для информирования последнего о завершении соединения.

2.1.2.10.4. Результат приема. Логический объект сетевого уровня не может более использовать данное соединение для передачи блока данных.

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

2.1.2.11. ЗД-СБРОС. запрос

2.1.2.11.1. Функция. Данный примитив является сервисным примитивом запроса для услуги сброса соединения.

2.1.2.11.2. Семантика сервисного примитива. Данный примитив должен содержать следующие параметры:

ЗД-СБРОС. запрос (

адрес-отправителя.

адрес-получателя

)

Параметры «адрес-отправителя» и «адрес-получателя» определяют локальный и удаленный ПДУЗ соединения, подлежащего сбросу.

2.1.2.11.3. Условие генерации. Данный примитив передается сетевым уровнем подуровню УЛЗ. чтобы запросить сброс соединения в исходное состояние.

ГОСТ 28907-91 С. 13

2.1.2.11.4. Результат приема. Прием данного примитива вызывает немедленный сброс соединения.

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

Возможная логическая последовательность примитивов при успешном сбросе соединения показана на черт. 2.2е.

2.1.2.12. ЗД-СБРОС. индикация

2.1.2.12.1. Функция. Данный примитив является сервисным примитивом индикации для услуги сброса соединения.

2.1.2.12.2. Семантика сервисного примитива. Данный примитив должен содержать следующие параметры:

ЗД-СБРОС. индикация (

адрес-отправителя.

адрес-получателя.

причина )

Параметры «адрес-отправителя- и «адрес-получателя» определяют локальный и удаленный ПДУЗ сбрасываемого соединения. Параметр «причина» указывает причину сброса соединения. Одна из кодовых комбинаций указывает, что сброс был запрошен удаленным логическим объектом сетевого уровня или УЛЗ (как показано на черт. 2.2е и 2.2г соответственно). Все другие кодовые комбинации указывают, что необходимость сброса установлена локальным логическим объектом подуровня УЛЗ (как показано на черт. 2.26).

2.1.2.12.3. Условие генерации. Данный примитив передается подуровнем УЛЗ сетевому уровню для информирования о том. что удаленный логический объект сетевого уровня или УЛЗ запросил сброс соединения, либо локальное УЛЗ определило необходимость повторной инициации соединения звена данных (как показано на черт. 2.2г).

2.1.2.12.4. Результат приема. При удаленном запросе сброса логический объект сетевого уровня должен выдать либо примитив ЗД-СБРОС. ответ для сигнализации приемлемости сброса. либо ЗД-РАЗЪЕДИНЕНИЕ, запрос для завершения данного соединения. При индикации локального условия сброса сетевой уровень должен выдать либо примитив ЗД-СБРОС. запрос для повторной инициации данного соединения, либо примитив ЗД-РАЗЪЕДИНЕНИЕ. запрос для завершения соединения.

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

2.1.2.13. ЗД-СБРОС. ответ

2.1.2.13.1. Функция. Этот примитив является сервисным примитивом ответа для услуги сброса соединения.

2.1.2.13.2. Семантика сервисного примитива. Этот примитив должен содержать следующие параметры:

ЗД-СБРОС. ответ (

адрес-отправителя, адрес-получателя )

Параметры «адрес-отправителя- и «адрес-получателя* определяют локальный и удаленный ПДУЗ сбрасываемого соединения.

С. 14 ГОСТ 28907-91

2.1.2.13.3. Условие генерации. Этот примитив выдается сетевым уровнем подуровню УЛЗ для указания приемлемости сброса соединения.

2.1.2.13.4. Результат приема. Прием этого примитива подуровнем УЛЗ вынуждает локальный логический объект УЛЗ завершить сброс соединения.

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

2.1.2.14. ЗД-СБРОС. подтверждение

2.1.2.14.1. Функция. Данный примитив является сервисным примитивом подтверждения для услуги сброса соединения.

2.1.2.14.2. Семантика сервисного примитива. Данный примитив должен содержать следующие параметры:

ЗД-СБРОС. подтверждение (

адрес-отправителя.

адрес-получателя )

Параметры «адрес-отправителя» и «адрес-получателя» определяют локальный и удаленный ПДУЗ сбрасываемого соединения.

2.1.2.14.3. Условие генерации. Данный примитив передается подуровнем УЛЗ сетевому уровню для информирования последнего о завершении сброса соединения.

2.1.2.14.4. Результат приема. Логический объект сетевого уровня может использовать данное соединение для передачи блока данных.

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

2.1.2.15. ЗД-СОЕДИНЕНИЕ-УПРАВЛЕНИЕ-ПОТОКОМ. запрос

2.1.2.15.1. Функция. Данный примитив является сервисным примитивом запроса управления потоком в соединении.

2.1.2.15.2. Семантика сервисного примитива. Данный примитив должен содержать следующие параметры:

ЗД-СОЕД И Н ЕН И Е- У П РА ВЛ ЕН И Е- П О ГО КО М зап рос (

адрес-отп равител я.

адрес-получателя.

объем

)

Параметры «адрес-отправителя» и «адрес-получателя» определяют локальный и удаленный ПДУ З того соединения, в котором должно осуществляться управление потоком. Параметр «объем» указывает тот объем данных, который имеет право передать логический объект подуровня УЛЗ.

2.1.2.15.3. Условие генерации. Данный примитив передается сетевым уровнем подуровню УЛЗ для запроса управления потоком примитивов ЗД-ДАННЫЕ. индикация по данному соединению.

2.1.2.15.4. Результат приема. Прием данного примитива побуждает подуровень УЛЗ согласовывать объем данных, который может быть передан сетевому уровню.

2.1.2.15.5. Дополнительные замечания. Управление потоком данных в соединении не зависит от управления потоком в других соединениях. Объем разрешенных для передачи данных динамически изменяется при каждом запросе. Если указанный объем равен нулю, то соответствующий поток должен быть остановлен. В конкретных реализациях объем данных может за-даваться в единицах, определяемых этой реализацией, и может устанавливаться в значение «бесконечность».

Возможная логическая последовательность примитивов, связанных с примитивом ЗД-СОЕДИНЕНИЕ-УПРАВЛЕНИЕ-ПОТОКОМ. запрос, показана на черт. 2.2а.

2.1.2.16. ЗД-СОЕДИ НЕН И Е-У П РАВЛ ЕН И Е- ПОТОКОМ, индикация

2.1.2.16.1. Функция. Данный примитив является сервисным примитивом индикации для услуги управления потоком в соединении.

ГОСТ 28907-91 С. 15

2.1.2.16.2. Семантика сервисного примитива. Данный примитив должен содержать следующие параметры:

ЗД-СОЕДИНЕНИЕ-УПРЛВЛЕНИЕ ПОТОКОМ. индикация (

адрес-отправителя.

адрес-получателя.

объем

)

Параметры «адрес-отправителя® и «адрес-получателя» определяют локальный и удаленный ПДУЗ управляемого по потоку соединения. Параметр «объем» определяет тот объем данных, который разрешено передавать логическому объекту сетевого уровня, чтобы избежать потери данных.

2.1.2.16.3. Условие генерации. Данный примитив передается подуровнем УЛЗ сетевому уровню с целью запроса управления со стороны сетевого уровня потоком примитивов ЗД-ДЛННЫЕ-СОЕДИНЕНИЕ. запрос по данному соединению.

2.1.2.16.4. Результат приема. Прием данного примитива побуждает сетевой уровень согласовывать объем данных, который он может передать без их потерь.

2.1.2.16.5. Дополнительные замечания. Управление потоком данных в соединении не зависит от управления потоком в других соединениях. Допустимый для передачи объем данных динамически изменяется с каждым новым запросом. Если указанный объем равен нулю, то соответствующий поток данных останавливается. В конкретных реализациях объем данных может задаваться в единицах, определяемых этой реализацией, и может устанавливаться в значение «бесконечность®.

Возможная логическая последовательность примитивов, связанных с примитивом ЗД-СОЕДИНЕНИЕ-УПРАВЛЕНИЕ-ПОТОКОМ. индикация, представлена на черт. 2.26.

2.2. Спецификация услуг на интерфейсе подуровень УЛЗ — подуровень УДС

В данном разделе определены услуги, которые запрашивает подуровень УЛЗ от подуровня УДС и которые позволят локальному логическому объекту подуровня УЛЗ обмениваться блоками данных УЛЗ с равноуровневыми логическими объектами подуровня УЛЗ. Эти услуги описаны в абстрактном виде и не предполагают какой-либо конкретной реализации или конкретного интерфейса.

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

2.2.1. Перечень взаимодействий

УДС-БЛОК-ДАННЫХ. запрос

УДС-БЛОК-ДАННЫХ. индикация

УДС-БЛОК-ДАНН ЫХ-СОСТОЯНИЕ. индикация

2.2.2. Подробная спецификация услуг

2.2.2.1. УДС-БЛОК-ДАННЫХ. запрос

2.2.2.1.1. Функция. Данный примитив обеспечивает передачу СБД УДС (СБДС) от локального логического объекта подуровня УЛ З одному разноуровневому логическому объекту УЛЗ или нескольким равноуровневым логическим объектам УЛЗ в случае групповой адресации.

2.2.2.1.2. Семантика сервисного примитива. Данный примитив имеет следующую семантику: УДС-БЛОК-ДАННЫХ. запрос (

адрес-отправителя (АО).

адрес-получателя (АП).

данные, приоритет, класс-услуг

Параметр «адрес-отправителя* должен определять индивидуальный адрес логического объекта УДС. Параметр «адрес-получателя» должен определять либо индивидуальный, либо групповой адрес логического объекта УДС. Вместе они должны содержать достаточную информацию

С. 16 ГОСТ 28907-91

для формирования полей АО и ЛИ. которые присоединяются к кадру локальным логическим объектом подуровня УДС так же. как и любую другую адресную информацию физического уровня (например частоту передачи при широкополосной передаче). Параметр «данные» определяет сервисный блок данных УС, подлежащий передаче логическим объектом подуровня УДС. который содержит поля ПДУII. ПДУО. У (управление), И «информация» (при его наличии) согласно разд. 3. а также информацию для определения длины блока данных логическим объектом подуровня УДС. Параметр «приоритет» определяет приоритет, необходимый для передачи блока данных. Параметр «класс-услуг» определяет класс услуг, необходимый для передачи блока данных.

2.2.2.1.3. Условие генерации. Этот примитив генерируется логическим объектом подуровня УЛЗ всякий раз, когда СБДС должен быть передан одному или нескольким равноуровне-вым логическим объектам УЛЗ. Это может произойти в результате запроса со стороны вышерасположенных уровней или протокола или в результате генерации СБДС внутри подуровня УЛЗ, как это требуется в операциях типа 2.

2.2.2.1.4. Результат приема. Прием данного примитива должен побудить логический объект УДС присоединить все определенные для УДС поля, включая АП. АО и любые другие поля, уникальные для конкретного данного метода доступа к среде, и направить сформированный надлежащим образом кадр нижним уровням протокола для последующей его передачи одному или нескольким равноуровневым логическим объектам подуровня УДС.

2.2.2.1.5. Дополнительные замечания. Возможная логическая последовательность примитивов. связанная с успешным выполнением услуги УДС по передаче блока данных, показана на черт. 2.2в.

2.2.2.2. УДС-БЛОК-ДАННЫХ, индикация

2.2.2.2.1. Функция. Данный примитив определяет передачу СБДС из логического объекта подуровня УДС к одному или нескольким (при групповой адресации) логическим объектам подуровня УЛЗ. При отсутствии ошибок параметр «данные» совпадает с содержимым параметра «данные» соответствующего примитива УДС-БЛОК-ДАННЫХ. запрос.

2.2.2.2.2. Семантика сервисного примитива. Данный примитив имеет следующую семантику: УДС-БЛОК-ДАННЫХ. индикация (

адрес-отправителя.

адрес-получателя, данные, приоритет, класс-услуг )

Параметр «адрес-отправителя» должен быть индивидуальным адресом, как определено полем АО поступившего кадра. Параметр «адрес-получателя» должен быть либо индивидуальным, либо групповым адресом, как определено полем АП поступившего кадра. Параметр «данные» определяет сервисный блок данных УДС, примятый локальным логическим объектом УДС. Параметр «состояние-приема» указывает на правильность или неправильность поступившего кадра. Параметр «приоритет» определяет приоритет, затребованный для передачи этого блока данных. Параметр «класс-услуг» определяет класс услуг, затребованный для передачи этого блока данных.

2.2.2.2.3. Условие генерации. Примитив УДС-БЛОК-ДАННЫХ. индикация передается логическим объектом подуровня УДС одному или нескольким логическим объектам подуровня для информирования о поступлении кадра в локальный логический объект подуровня УДС. Это информирование проводится только для тех кадров, которые правильно сформированы в подуровне УДС, приняты без ошибок, и их адрес получателя определяет локальный логический объект подуровня УДС.

2.2.2.2.4. Результат приема. Результат приема подуровнем УДС данного примитива зависит от правильности и содержимого кадра.

2.2.2.2.5. Дополнительные замечания. Если параметр «адрес»получателя* примитива УДС-БЛОК-ДАННЫХ. запрос определяет локальный логический объект подуровня УДС. то

ГОСТ 28907-91 С. 17

логически» объект подуровня УДС будет также выдавать примитив индикации для локального логического объекта подуровня УЛЗ. Такое дуплексное свойство подуровня УДС может быть следствием уникальных функциональных возможностей самого подуровня УДС или дуплексных свойств нижерасположенных уровней (например все кадры, переданные с глобальным адресом. будут вызывать примитивы УДС-БЛОК-ДАННЫХ. индикация на всех станциях сети, включая станцию, сгенерировавшую этот запрос).

2.2.2.3. УДС-БЛОК-ДАНН ЫХ-СОСТОЯНИ Е. индикация

2.2.2.3.I. Функция. Данный примитив имеет локальную значимость и должен обеспечивать подуровень УЛЗ информацией состояния предыдущего примитива УДС-БЛОК-ДАННЫХ. запрос.

2.2.2.3.2. Семантика сервисного примитива. Данный примитив имеет следующую семантику: УДС-БЛОК-ДАНН ЫХ-СОСТОЯН ИЕ. индикация

(

адрес-отправителя, адрес-получателя, состояние-передачи, обеспеченный-приоритет, обеспеченный-класс-услуг

Параметр «адрес-отправителя» должен быть индивидуальным адресом логического объекта УДС. указанным в соответствующем примитиве УДС-БЛОК-ДАННЫХ. запрос. Параметр «адрес-получателя* должен быть либо индивидуальным, либо групповым адресом логического объекта УДС. указанным в соответствующем примитиве УДС-БЛОК-ДАННЫХ. запрос. Параметр «состояние-передачи» используется для возврата информации состояния локальному запрашивающему логическому объекту подуровня УЛЗ. Виды состояния, которые могут быть связаны с этим примитивом, зависят от конкретной реализации, а также от типа используемого подуровня УДС (например логический объект подуровня УДС шины со случайным доступом (КДОН/ОК) может возвратить состояние «чрезмерное количество столкновений»). Параметр «обеспечен-ный-приоритет» указывает приоритет, который был обеспечен при передаче соответствующего блока данных. Параметр «обеспеченный-класс-услуг» указывает класс услуг, который был обеспечен при передаче блока данных.

2.2.2.3.3. Условие генерации. Примитив УДС-БЛОК-ДАННЫХ-СОСТОЯНИЕ. индикация выдается логическим объектом подуровня УДС подуровню УЛЗ в ответ на примитив УДС-БЛОК-ДАННЫХ. запрос, поступивший из локального логического объекта подуровня УЛЗ.

2.2.2.3.4. Результат приема. Результат приема данного примитива подуровнем УЛЗ зависит от типа операций, используемых на подуровне УЛЗ.

2.2.2.3.5. Дополнительные замечания. Предполагается, что для подуровня УЛЗ обеспечивается достаточный объем информации для того, чтобы увязать состояние с соответствующим запросом.

2.3. Спецификация услуг на интерфейсе подуровень УЛЗ — управляющая функция подуровня УЛЗ

(Данный вопрос является предметом дальнейшего изучения)

3. СТРУКТУРА ПРОТОКОЛЬНОГО БЛОКА ДАННЫХ УЛЗ

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

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

3.2. Формат ПДБ УЛЗ

Формат всех ПБД УЛЗ должен соответствовать черт. 3.1.

С. 18 ГОСТ 28907-91

Форма» IIБД УЛЗ

Обозначения:

Адрес ПДУП

Адрес ПДУО

Управление

Информация ♦ м

— поле адреса пункта доступа к услугам получателя;

— поле адреса пункта доступа к услугам отправителя;

— поле управления (длина 16 бит для кадров, содержащих порядковые номера, и 8 бит для кадров, не содержащих их (см. п. 5.2);

— поле информации.

— знак умножения.

- целое число, равное или большее 0. (Верхняя Гранина М является функцией используемого метода управления доступом к среде)

Черт. 3.1

3.3 Элементы II БД УЛЗ

3.3.1. Поля адреса. Каждый И БД УЛ З должен содержать два поля адреса: поле адреса ПДУП и поле адреса ПДУО в указанной последовательности. Каждое поле адреса должно содержать только один адрес. Поле адреса ПДУП должно идентифицировать один или несколько пунктов доступа к услугам, для которых предназначено поле информации УЛЗ. Поле адреса ПДУО должно идентифицировать конкретный пункт доступа к услугам, из которого было выдано поле информации УЛЗ.

3.3.1.1. Представление поля адреса. Каждое поле адреса должно иметь формат, представленный на черт. 3.2а и 3.26.

Форматы адресных нолей ПДУП и ПДУО

И/Г = 0 Индивидуальный ПДУП

И/Г = I групповой ПДУП

К/О = 0 команда

К/О = I ответ

ХОПППППП адрес ПДУП

Х0000000 адрес ПДУО

Х1ПППППП зарезервировано

X1000000 зарезервировано

Черт. 3.2а

Формат иоля глобального адреса ПДУП

Лиле адреса. ЛДУЛ

Черт. 3.26

ГОСТ 28907-91 С. 19

1) Длина каждого поля адреса должна равняться одному октету.

2) Каждое поле адреса должно содержать 7-битный собственно адрес и один бит. который в поле ПДУП квалифицирует адрес ПДУП как индивидуальный или групповой (называемый битом типа адреса получателя), а в поле ПДУО квалифицирует ПБД УЛЗ как команду или как ответ (называемый битом идентификации ко.манды/ответа).

3) Бит типа адреса получателя должен быть расположен в самой младшей значащей позиции поля адреса ПДУП. Если значение этого бита равно 0. то это должно означать, что данный адрес является индивидуальным адресом ПДУП. Если же значение этого бита равно 1. то это должно означать, что данный адрес является групповым адресом ПДУП. который может ничего не идентифицировать, идентифицировать один, несколько или все пункты доступа к услугам, обслуживаемые логическим объектом УЛЗ.

4) Бит идентификации ко.манды/ответа должен быть расположен в самой младшей значащей битовой позиции поля адреса ПДУО. Если значение этого бита равно 0. то это означает, что данный ПБД УЛЗ является командой. Если же значение этого бита равно 1. то это означает. что данный ПБД УЛЗ является ответом.

3.3.1.2. Использование адреса. Индивидуальный адрес может использоваться в качестве адреса ПДУО и адреса ПДУП; нулевой адрес может использоваться в качестве адреса ПДУО и адреса ПДУП: групповой адрес может использоваться только в качестве адреса ПДУП.

Поле адреса ПДУП со всеми битами, равными 1 (т. е. бит типа адреса получателя и все семь битов адреса равны I), предназначено для использования в качестве «глобального» адреса ПДУП. Этот адрес ПДУП означает группу из всех тех ПДУП. которые активно обслуживаются алресом(ами) пункта(ов) доступа к услугам нижерасположенного УДС.

Поле адреса ПДУП или ПДУО со всеми битами, равными 0 (т. е. бит типа адреса получателя и все семь битов адреса равны 0). предназначено для использования в качестве «нулевого» адреса. Нулевой адрес пункта доступа к услугам идентифицирует тот УЛЗ, который связан с нижерасположенным адресом пункта доступа к услугам УДС и не используется для идентификации какого-либо пункта доступа к услугам для сетевого уровня или какого-либо пункта доступа к услугам для соответствующей управляющей функции уровня.

Адреса 01000000 и 1100000 рассматриваются как индивидуальный и групповой адреса соответственно для управляющей функции подуровня УЛЗ станции. Остальные адреса с битами, равными I (кроме первого), зарезервированы.

3.3.2. Поле управления. Поле управления должно состоять из одного или двух октетов, которые должны использоваться для определения функций команд и октетов, и которые при необходимости должны содержать порядковые номера. Содержимое данного поля должно соответствовать описанию в разд. 5.

3.3.3. Поле информации. Поле информации должно содержать любое целое число (включая 0) октетов.

3.3.4. Порядок передачи битов. Адреса, команды, ответы и порядковые номера должны передаваться подуровню УДС и приниматься из этого подуровня, начиная с младших битов (т. е. первым должен передаваться бит с весом 2“). Биты пазя информации должны доставляться подуровню УДС в той же последовательности, в которой они были получены из сетевого уровня. Биты поля информации должны доставляться сетевому уровню в той же последовательности, в которой они были получены из подуровня УДС.

С. 20 ГОСТ 28907-91

3.3.5. Недействительные ПБД УЛЗ. ПБД УЛЗ считается недействительным в следующих случаях:

а) если он определен как таковой физическим уровнем или подуровнем УДС;

б) если его длина не кратна октету;

в) если он не содержит двух правильно сформатированных полей адреса, поля управления и, возможно, поля информации в надлежащей последовательности;

г) если его общая длина меньше трех октетов при 8-битном поле управления и четырех октетов — при 16-битном поле управления.

Недействительные ПБД УЛЗ должны игнорироваться.

4. типы и классы процедур УЛЗ

4.1. Общие положения. В УЛЗ предусмотрены два типа операций для обмена данными между пунктами доступа к услугам.

1) Операции типа 1. При выполнении операций типа 1 ПБД должны передаваться между УЛЗ без установления соединения звена данных. На подуровне УЛЗ эти ПБД не должны под-тверждаться и в процедурах типа I для них не должно выполняться никакого управления потоком или исправления ошибок.

2) Операции типа 2. В операциях типа 2 перед выполнением любого обмена ПБД. содержащими информацию, между двумя УЛЗ должно быть установлено соединение звена данных. Нормальный цикл обмена между двумя УЛЗ типа 2 в соединении звена данных должен состоять из передачи ПБД. содержащих информацию, от УЛ 3-отправителя к УЛЗ-получателю и передачи подтвержденного ПБД в противоположном направлении.

В операциях типа 2 следует выполнять управление трафиком данных между УЛЗ-отправи-телем и УЛЗ-получателем путем использования схемы нумерации, которая должна быть циклической по модулю 128 и применяться к ПБД. Для каждой пары УЛЗ источник-получатель должна использоваться независимая схема нумерации. Каждая такая пара должна определяться как логическое двухпунктовое соединение звена данных между ПДУЗ и должна учитывать адреса ЛИ и ЛО. которые являются частью подуровня УДС. Функция подтверждения должна выполняться УЛЗ-получателем. информирующим УЛ 3-отправителя о следующем ожидаемом порядковом номере. Эта функция должна выполняться либо посредством отдельного ПБД, не содержащего информацию, либо в рамках поля управления ПБД. содержащего информацию.

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

На черт. 4.1 изображено использование функций управления звеном данных при передаче данных между УЛЗ при операциях типа 2. Источник данных в каждом УЛЗ должен управлять получателем данных в другом УЛЗ посредством использования командных ПБД. Информация должна проходить от источника данных к получателю данных, а все подтверждения должны всегда передаваться в противоположном направлении. УЛЗ каждой станции должен использовать командные ПБД опросного типа с целью запроса от другой УЛЗ конкретных подтверждений и ответов о состоянии.

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

4.2. Классы УЛЗ (аттестационный раздел). Определены два класса УЛЗ. УЛЗ класса I должен обеспечивать только операции типа 1, УЛЗ класса II должен обеспечивать как операции типа 1, так и операции типа 2, что показано знаком X на черт. 4.2.

Это значит, что все УЛЗ в локальной вычислительной сети должны обеспечивать операции типа I. В УЛЗ класса II обеспечение операций типа 1 должно быть совершенно независимо от конкретных режимов или от изменения режимов операций типа 2 в том же УЛЗ. УЛЗ класса 11 должны быть способны при необходимости переключаться с операций типа 1 на операции типа 2 и обратно на основе передачи ПБД — ПБД в том же ПДУ.

Конфигурация сбалансированною соединения (вена данных

ГОСТ 28907-91 С. 21

Черт. 4.1

Классы УЛЗ

Гил операции

/ 2

Диасе

УДУ

X

g X X

Черт. 4.2

4.2.1. УЛЗ класса I. УЛЗ класса I должны обеспечивать только операции типа I. Услуги класса 1 должны использоваться для индивидуальной, групповой, глобальной и нулевой адресации ПДУП и для применений, не требующих подтверждения на уровне звена данных или процедур управления потоком. Набор обеспечиваемых в услугах класса I командных ПБД и ответных 11 БД должен быть следующим:

Команды

Ответы

Тип 1:

НИ

ИДС

ТЕСТ

ИДС ТЕСТ

4.2.2. УЛЗ класса II. УЛЗ класса II должны обеспечивать операции типа 1 и операции типа 2. В станции класса II выполнение процедур типа I и процедур типа 2 полностью не зависимы друг от друга. Набор командных и ответных ПБД. обеспечиваемых в услугах класса II. должен быть следующим:

Тин 1:

Тип 2:

С. 22 ГОСТ 28907-91

5. ЭЛЕМЕНТЫ ПРОЦЕДУР УЛЗ

5.1. Общие положения. В данном разделе определены элементы процедур УЛЗ локальной вычислительной сети для выполнения кодонезависимой передачи данных с использованием структуры ПБД УЛЗ (см. разд. 3).

Эти элементы процедур УЛЗ специально определены в понятиях действий, которые должны выполняться в УЛЗ при получении команд и иногда при получении ответа на команду по логическому звену данных (тип I) и по соединению звена данных (тип 2). Каждый элемент процедуры используется только одним из двух типов операций (тип I или тип 2). которые определены в разд. 4.

5.2. Форматы поля управления. Три формата, определенные для поля управления (черт. 5.1). должны использоваться с целью выполнения функций передачи нумерованной и ненумерованной информации, осуществления нумерованного и ненумерованного управления. Функция передачи нумерованной информации и управляющих передач используются только в операциях типа 2. Функции ненумерованного управления и передачи ненумерованной информации используются в операциях типа 1. либо типа 2 (ио не в обоих сразу) в зависимости от конкретной выбранной функции.

Форматы поля управления ПБД УЛЗ

Разряда/ паля управления П5Д УЛЗ

i 2 3 4 5 6 1 8 9 <0 ’ <6

команда/ответ передачи Информации (формате ПбД)

Управляющие каманды/ответы (формат УК О)

Ненумерованные команды/ответы (формат HKD Л5Д)

Нпд — порядковый номер передачи на передающей стороне (бит 2 — младший бит); Нпм — порядковый номер приема на передающей стороне (бит 10— младший бит»; У — бит управляются функции; М - бит модификатора функции; X — зарезервированный бит. устанавливается в О; 3/Л — бит «запрос» — в передачах командного ПБД УЛЗ. бит «последний» — в передачах ответного ПБД УЛЗ 11 - «запрос/послсдний»)

Черт. 5.1

5.2.1. Формат передачи информации — И. ПБД формата И должен использоваться для передачи ненумерованной информации в операциях типа 2. За исключением особо оговоренных случаев (например НИ. ГЕСТ. НПРК и ИДС) — это единственный ПБД УЛЗ. который может содержать поле информации. Функции Нпд, Нпм и 3/11 должны быть взаимонезависимы, т. е. каждый ПБД формата И должен иметь порядковый номер Нпд, порядковый номер Нпм. который может подтверждать или не подтверждать дополнительные ПБД формата И на приемной стороне УЛЗ. а также бит 3/П. который может быть установлен в 1 или 0.

5.2.2. Формат управляющих команд и ответов — У КО. ПБД формата УКО должны использоваться для выполнения управляющих функций звена данных в операциях типа 2. таких как подтверждение ПБД формата И. запрос повторной передачи ПБД формата И и запрос временной приостановки передачи ПБД формата И. Функции Нпд и 3/П должны быть взаимонезависимы, т. е. каждый ПБД формата УКО должен иметь порядковый номер Нпм. который

ГОСТ 28907-91 С. 23

должен подтверждать или не подтверждать дополнительные ПБД формата И на приемной стороне УЛЗ и бит 3/П. который может быть установлен в 1 или 0.

5.2.3. Формат ненумерованных команд н ответов — НКО. ПБД формата НКО должны использоваться в операциях типа 1 или 2, в зависимости от конкретной рассматриваемой функции, для выполнения дополнительных функций управления звеном данных и для выполнения неупорядоченной передачи информации. ПБД формата НКО не должны содержать порядковых номеров, но должны содержать бит 3/П. который может быть установлен в 1 или О.

5.3. Параметры поля управления. В последующих пунктах описаны рахчичные параметры. относящиеся к форматам поля управления.

5.3.1. Параметры операций типа 1. В операциях типа 1 используется единственный параметр — бит 3/П. В значении I бит 3/П должен использоваться в операции типа I только с функциями командного/ответного ПБД ИДС или ТЕСТ. Бит 3 в значении I должен использоваться для запроса (опроса) от адресуемого УЛЗ соответствующего ответного ПБД с битом П, равным 1. Бит П в значении 1 должен использоваться для указания ответного ПБД. который послан УЛЗ в результате получения запросного (опросного) командного ПБД (с битом 3, равным 1).

5.3.2. Параметры операций типа 2. В последующих пунктах описаны различные параметры. связанные с форматами поля управления операций типа 2.

5.3.2.1. Модули. Каждый ПБД И должен иметь порядковый номер. Номера должны принимать значения в диапазоне от 0 до модуль минус единица (где модуль — это значение порядковой нумерации). Для формата поля управления УЛЗ типа 2 модуль должен быть равен 128. Порядковые номера должны циклически изменяться во всем диапазоне.

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

5.3.2.2. Переменные и порядковые номера ПБД УЛЗ. Для каждого соединения звена данных станция УЛЗ должна поддерживать переменную передачи ПД для передаваемых ею ПБД И и переменную приема ПМ для принимаемых ею ПБД И. Операции нал переменной ПД не должны зависеть от операций над переменной ПМ.

5.3.2.2.1. Переменная передачи — ПД. Переменная передачи должна указывать порядковый номер следующего по очереди подлежащего передаче ПБД И по конкретному соединению звена данных. Она должна принимать значения в диапазоне от 0 до модуль минус единица (где модуль равен 128. а номер циклически изменяется во всем диапазоне). Значение переменной передачи должно возрастать на единицу при каждой последующей передаче ПБД И по соответствующему соединению звена данных, но оно не должно превышать значение Нпм последнего принятого ПБД больше чем на модуль минус единица.

5.3.2.2.2. Порядковый помер передачи — Нпд. Только ПБД И содержат Нпд— порядковый номер передачи передаваемого ПБД. До передачи ПБД И значение Нпд должно быть установлено равным значению переменной передачи в данном соединении звена данных.

5.3.2.2.3. Переменная приема — ПИ. Переменная приема указывает порядковый номер следующего по порядку ПБД И ожидаемого на приеме по конкретному соединению звена данных. Переменная приема должна принимать значения в диапазоне от 0 до модуль минус единица (где модуль равен 128. а номер циклически изменяется во всем диапазоне). Значение переменной приема. относящейся к конкретному соединению звена данных, должно увеличиваться на единицу каждый раз при получении безошибочного очередного ПБД И. у которого номер передачи Нпд равен значению переменной приема для данного соединения звена данных.

5.3.2.2.4. Порядковый номер приема — Нпм. Все ПБД формата И и ПБД формата УКО должны содержать Нпм — ожидаемый порядковый номер следующего принимаемого ПБД И по конкретному соединению звена данных. До передачи ПБД формата И или ПБД формата УКО значение Нпм должно быть установлено равным текущему значению соответствующей переменной приема для данного соединения звена данных. Номер Нпм должен указывать, что

С. 24 ГОСТ 28907-91

станция, передавшая Ним. приняла бет ошибок все ПБД и с номерами до (Нпм — I) включительно по конкретному соединению звена данных.

5.3.2.3. Бит «запрос/последний* — 3/11. Бит 3 должен использоваться для запроса (опроса) ответа от адресуемого УЛЗ. Бит 11 должен использоваться для указания ответного ПБД. который передан в результате получения запросной (опросной) команды.

Бит 3/П должен выполнять свои функции в режиме 2 работы как в командных ПБД. так и в ответных ПБД. В командных ПБД бит 3/П должен рассматриваться как бит 3. В ответных ПБД этот бит должен рассматриваться как бит II. Обмен битами 3/П обеспечивает более четкую взаимосвязь команда/ответ. которая используется как при нормальной работе, так и в восстановительных ситуациях.

5.З.2.З.1. Функция бига «запрос». Командный ПБД с битом 3 в значении 1 должен использоваться в соединении звена данных для запроса ответного ПБД с битом 11. равным I. от адресуемого УЛЗ этого соединения звена данных.

В конкретном направлении в любой момент времени только один ПБД с битом 3. равным I. может быть неподтвержден в соединении звена данных между любой конкретной парой УЛЗ. Прежде чем УЛЗ передаст другой ПБД с битом 3. равным 1. по тому же соединению звена данных, УЛЗ должен принять ответный ПБД с битом II. равным I, адресуемого УЛЗ. Если в течение установленного системой тайм-аута бита 3 не получено правильного ответного ПБД. то для целей исправления ошибки разрешается повторная передача командного ПБД с битом 3, равным I.

5.3.2.3.2. Функция бига «последний». Ответный ПБД с битом II, равным I, должен использоваться для подтверждения приема командного ПБД с битом 3. равным I.

После приема командного ПБД с битом 3. равным I. УЛЗ должен при первой возможности послать ответный ПБД с битом П, равным I. то соответствующему соединению звена данных.

УЛЗ должен иметь возможность передавать соответствующие ответные ПБД с битом 11. равным 0. при любой возможности доступа к среде на асинхронной основе (без необходимости получения командного ПБД).

5.4. Команды и ответы. В данном разделе определены команды и соответствующие ответы. В пп. 5.4.1 и 5.4.2 содержатся определения набора команд и ответов (перечисленных ниже) для каждого формата поля управления для операций типа I и операций типа 2 соответственно.

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

Команды передачи информации

И — информация

Управляющие команды

ГПР — готов к приему НГПР — не готов к приему НИР — неприем

Ненумерованные команды

НИ — ненумерованная информация

РЗД — разъединение

УРРАС — установить расширенный режим асинхронный сбалансированный

ИДС — идентификация станции ТЕСТ — тест

Ответы передачи информации

И — информация

Управляющие ответы

ГПР — готов к приему

НГПР - не готов к приему

НИР - неприем

Ненумерованные ответы

НН — ненумерованное подтверждение

ФРЗД — фаза разъединения

НПРК - неприем кадра

ИДС - идентификация станции ТЕСТ — тест

5.4.1. Команды н ответы операций типа 1. Все команды и ответы типа 1 представляют собой ПБД формата НКО.

ГОСТ 28907-91 С. 25

5.4.1.1. Команды операций типа I. Кодирование командных IIБД формата НКО для операций типа 1 представлено на черт. 5.2.

Битовое кодирование поля управления команд операций типа I

бит поля управления, передаваемый на подуровень УДС и принимаемый из подуровня УДС первым

2

/

3

О <

Ь

8

/

5

3

3

6 в

I

7

В

0

8 О i

I

О

0

3

I

/

/

команда НИ команда ИДС команда ТЕСТ

Черт. 5.2

5.4.1.1.1. Команда «ненумерованная информация» (НИ). Командный ПБД НИ должен использоваться для передачи информации к одному или нескольким УЛЗ. Использование командного ПБД НИ не должно зависеть от наличия соединения звена данных между УЛ 3-отправителем и УЛЗ-получателем и его передача не должна влиять на значения переменных ПД и ИМ каких-либо соединений звена данных. Для командного ПБД НИ не существует ответного ПБД УЛЗ.

На командный ПБД НИ подтверждение не выдается и порядковые номера не проверяются. Поэтому данные, содержащиеся в ПБД НИ. могут быть потеряны, если во время передачи этого командного ПБД появляется особое условие (например ошибка передачи или состояние занятости приемника).

Командный ПБД НИ должен использовать в качестве адреса ПДУП индивидуальный, групповой, глобальный или нулевой адрес, а в качестве адреса ПДУО — индивидуальный адрес.

5.4.1.1.2. Команда «идентификация станции» (ИДС). Командный ПБД ИДС должен использоваться для передачи информации об обеспечиваемых типах услуг УЛЗ (всем УЛЗ) и о размере приемного окна (для каждого отдельного соединения звена данных), а также для того, чтобы запросить у УЛЗ-получателя выдачу при первой возможности ответного ПБД ИДС (см. п. 5.4.1.2.1), Командный ПБД ИДС не должен влиять на режим работы и порядковую нумерацию. обеспечиваемую удаленным УЛЗ. Командный ПБД ИДС должен иметь в качестве адреса ПДУП либо индивидуальный, либо групповой, либо глобальный, либо нулевой адрес получателя, а в качестве адреса ПДУО — индивидуальный адрес.

Поле информации командного ПБД ИДС основного формата должно состоять из 8-битового поля идентификатора формата ИДС и 16-битового поля параметра, в котором кодируются поддерживаемые услуги УЛЗ и размер приемного окна, как показано на черт. 5.3. Размер приемного окна представляет собой максимальное число, на которое переменная передачи ПД может превышать номер Ним последнего принятого ПБД.

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

5.4.1.1.3. Команда «тест» (ТЕСТ). Командный ПБД ТЕСТ должен использоваться для того. чтобы запросить у адресуемого УЛЗ выдачу при первой возможности ответного ПБД ТЕСТ (см. п. 5.4.1.2.2). обеспечивая тем самым выполнение базовой проверки тракта передачи между двумя УЛЗ. Для командного ПБД ТЕСТ поле информации является необязательным. Но при его наличии оно должно быть по возможности возвращено адресуемым УЛЗ в ответном ПБД ТЕСТ. Командный ПБД ТЕСТ не должен влиять на режим и порядковую нумерацию, обеспечиваемую удаленным УЛЗ. Он может иметь индивидуальный, групповой, глобальный или нулевой адрес ПДУП при индивидуальном, групповом или глобальном адресе АП.

С. 26 ГОСТ 28907-91

Поле информации ИДС основного формата

Поле информации ИДС

А____________L_ Младший Sum

Младший Sum. I— Перомй Sum поля информации ИДС, лере ~ даваемый S/npu-нимаемый из подуровня УДС

Идентификатор Типы/классы Резервные Размер формата, идс ypj виты, уста- окна

1DODOOO! ~ к явлены в О приема

идентификатор основного

(К)

формата

При нулевом ЛД УЗ разряды YYYYY озна чают: WOOD -класс! УЛЗ

НОВО - класс 11 УЛЗ

Иначе, если используется ненулевой ПДУЗ, значениями YYYYYявляются:

/0000 - УЛЗ типа (

С<Л0й - УЛЗ типа 2

HOOD - УЛЗ типов!и2

Черт. 5.3

Примечая и с. Другие применения ПБД ИДС - в стадии научения, например использование неопрошенною ответного ПБД ИДС дли оповещении появления нового УЛЗ.

5.4.1.2. Ответы операций типа 1. Кодирование ответных ПБД формата НКО для операций типа 1 представлено на черт. 5.4.

Битовое кодирование поля управления ответов операций тина 1

бит поля управления передиваемыС/принимаемый на подуровне УДСпервым

I

>23^5676

/ / / t п / о < ответ НДС

f / С О Л f t f ответ ТЕСТ

Черт. 5.4

5.4.1.2.1. Ответ «идентификация станции» (НДС). Ответный ПБД ИДС должен использоваться для ответа при первой возможности на командный ПБД ИДС. Ответный ПБД ИДС должен идентифицировать отвечающий УЛЗ и должен содержать поле информации того же формата, который был определен для командного ПБД ИДС (см. п. 5.4.1.1.2), независимо от того, какая информация содержалась в поле информации принятого командного ПБД ИДС.

ГОСТ 28907-91 С. 27

Ответный ПБД ИДС должен использовать индивидуальный или пулевой адрес ПДУП. а также индивидуальный или нулевой адрес ПДУО. Ответный ПБД ИДС должен иметь бит П. установленный в го же значение, что и бит 3 в командном ПБД ИДС.

5.4.1.2.2. Ответ «тест* (ТЕСТ). Ответный ПБД ТЕСТ должен использоваться для ответа на командный ПБД ТЕСТ. Ответный ПБД ТЕСТ должен иметь бит П. установленный в то же значение, что и бит 3 в командном ПБД ТЕСТ. При наличии в командном ПБД ГЕСТ поля информации, оно должно быть возвращено в соответствующем ответном ПБД ТЕСТ. Если УЛЗ не может принять поле информации (например вследствие ограничений буферной емкости), то ответный ПБД ГЕСТ может быть возвращен без поля информации. Конкретные детали использования ответа ТЕСТ см. в п. 6.7.

5.4.2. Команды и ответы операций типа 2. Команды и ответы операций типа 2 состоят из ПБД формата И. формата У КО и формата НКО.

5.4.2.1. Команда и ответ формата «передача информации*. Функция команды и ответа «информация» (И) должна состоять в передаче через соединение звена данных последовательно пронумерованных ПБД, содержащих октетно-ориентированное поле информации. Кодирование поля управления ПБД И для операций типа 2 показано на черт. 5.5.

Биты поля управления формата передачи информации

бит поля управления, п*редм»ыыи «.''принимаемый от подуровня УДС первыи

/2 ... в 9 10 ... it>

I t | I

Формат Пор/1Вно8ый номер I ЛорядксВый номер

передачи ’ передачи Команда (запрос/ приема

информации (O-/Z7) OmBemtnoutedHuO) (0-/27)

Черт. 5.5

Поле управления ПБД И должно содержать 2 порядковых номера: Нид — порядковый номер передачи, который должен указывать порядковый номер, относящийся к данному ПБД И. и Нпм — порядковый номер приема, который должен указывать порядковый номер (во время передачи ПБД) следующего ожидаемого на приеме ПБД И и. следовательно, должен указывать. что все ПБД И с номерами до (Нпм — Г) включительно приняты правильно. Описание функций бита 3/П см. в п. 5.3.2.3.

5.4.2.2. Управляющие команды и ответы. Управляющие ПБД должны использоваться для выполнения нумерованных управляющих функций, таких как подтверждение, временная приостановка передачи информации или исправление ошибки.

ПБД формата УКО не должны содержать поля информации и. следовательно, при их передаче не должна увеличиваться переменная передачи, а при их приеме — переменная приема. Кодирование поля управления ПБД формата УКО для операций типа 2 должно соответствовать черт. 5.6.

ПБД формага УКО должен содержать Нпм — порядковый номер приема, который должен указывать во время передачи порядковый номер следующего ожидаемого на приеме ПБД И и. следовательно, должен указывать, что все полученные ПБД И с номерами до (Нпм) — I) включительно приняты правильно.

С. 28 ГОСТ 28907-91

Биты поля управления формата УКО

Бит поля управления, передшыьш в/принимаемыи из подуровня УДС первым

f 23^5678 9 >0 ... /6

НПР - неприем

НГПР- не готов к приему

О f f 0

НПР

НГПР

- неприем

- не готов к приему

Черт. 5.6

Передача ПБД ГПР или НПР должна указывать о снятии любого состояния занятости в передающем УЛЗ, которое было указано предыдущей передачей ПБД НГПР. Описание функций бита 3/П см. в п. 5.3.2.3.

5.4.2.2.1. Команда и ответ «готов к приему» (ГПР). ПБД ГПР должен использоваться УЛЗ для указания на его готовность к приему одного или нескольких ПБД И. ПБД И с номерами до (Нпм — I) включительно должны рассматриваться как подтвержденные.

5.4.2.2.2. Команда и ответ «неприем* (НПР). ПБД НПР должен использоваться УЛЗ для запроса повторной передачи ПБД И. начиная с ПБД под номером Нпм. ПБД И с номерами до (Нпм — 1) включительно должны считаться подтвержденными. После повторной передачи указанных ПБД И должна обеспечиваться возможность передачи дополнительных ожидающих передачи ПБД И.

В каждом направлении передачи соединения звена данных в любой момент времени может быть установлено только одно особое условие -перелай НПР*. Условие «передан НПР* должно сбрасываться при приеме ПБД И с номером Нпд. равным Нпм в ПБД НПР. Условие -передан НПР* может быть сброшено в соответствии с процедурами, описанными в п. 7.5.4.

5.4.2.2.3. Команда и ответ «не готов к приему* (НГПР). ПБД НГПР должен использоваться УЛЗ для указания состояния занятости (т. е. временной неспособности принимать последующие ПБД И). ПБД И с номерами до (Нпм — 1) включительно должны рассматриваться как подтвержденные. ПБД И с номерами Ним и любые последующие принятые ПБД И, если такие имеются, не должны рассматриваться как подтвержденные; состояние приема этих ПБД должно указываться при последующих обменах.

5.4.2.3. Ненумерованные команды и ответы. Ненумерованные команды и ответы (НКО) должны использоваться в операциях типа 2 с целью расширения числа функций управления соединением звена данных. Передача ПБД формата НКО не должна увеличивать переменные соединения звена ни на передающей, ни на принимающей УЛЗ. Структура поля управления ПБД команд/ответов формата НКО показана на черт. 5.7а. Кодирование поля управления команд и ответов формата НКО для операций типа 2 показано на черт. 5.76.

Описание функций бита 3/П см. в п. 5.3.2.3.

Биты ноля управления ненумерованного формата

ГОСТ 28907-91 С. 29

Бит поля управления, передаваемый втринииаемый от подуровня УДС первый

( 2 3 Ь 5 б 7 в

Черт. 5.7а

Кодирование поля управления ненумерованные команд н ответов

Бит да )ww. ге^жшл; ^тошьи от патриот УДС первым

I ( 2 3 Ь 5 6 7 8

(if I з { f б команда уррас

f f 0 О 3 й f в команда РЗД

I I 0 О П f I 0 Отдел! Уд

I f f I Л С 0 0 ОтВет ФРЗД

f ( < о л о о ( omffem впрк

Черт. 5.76

5.4.2.3.I. Команда «установить расширенный режим асинхронный сбалансированный» (УРРАС). Командный ПБД УРРАС должен использоваться для установления соединения звена данных с УЛЗ-получателем в асинхронном сбалансированном режиме. С командных» ПБД УРРАС не должно передаваться поле информации. УЛЗ-подучатель должен при первой возможности подтвердить прием командного ПБД УРРАС передачей по данному соединению звена данных ответного ПБД НП или ПБД ФРЗД в зависимости от того, какой из примитивов получен подуровнем УЛЗ от сетевого уровня: ЗД_СОЕДИНЕНИЕ. ответ или ЗД_РАЗЪЕДИНЕНИЕ, запрос. При приеме командного ПБД УРРАС переменные передачи и приема УЛ 3-получателя должны быть установлены в 0. Если ответный ПБД НП принят правильно. то инициирующий УЛЗ должен считать, что установлен асинхронный сбалансированный режим, а значения соответствующих переменных передачи и приема установлены в 0.

Ранее переданные, но еше не подтвержденные во время действия этой команды ПБД И остаются неподтвержденными. Вопрос о необходимости повторной передачи УЛЗ содержимого поля информации оставшихся неподтвержденными ПБД И должен решаться на более высоком уровне.

5.4.2.3.2. Команда «разъединение» (РЗД). Командный ПБД РЗД должен использоваться для завершения асинхронного сбалансированного режима, установленного ранее командным ПБД УРРАС. Он должен использоваться для информирования УЛЗ-получателя о том. что

С. 30 ГОСТ 28907-91

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

Ранее переданные, но еще не подтвержденные во время действия этой команды ПБД И. остаются неподтвержденными. Вопрос о необходимости повторной передачи УЛЗ содержимого поля информации оставшихся неподтвержденными ПБД И должен решаться на более высоком уровне.

5.4.2.3.3. Ответ «ненумерованное подтверждение» (НИ). Ответный ПБД НП должен использоваться УЛЗ в соединении звена данных для подтверждения приема и приемлемости командных ПБД УРРАС и РЗД. Эти принятые командные ПБД не должны выполняться до выдачи ответного ПБД НП. В ответном ПБД НП не допускается передача поля информации.

5.4.2.3.4. Ответ «фаза разъединения» (ФРЗД). Ответный ПБД ФРЗД должен использоваться для информирования о состоянии, указывающем, что УЛЗ логически отсоединен от звена данных и находится, как определено в РАР. В ответном ФРЗД не допускается передача поля информации.

5.4.2.3.5. Ответ «неприем кадра» (НПРК). Ответный ПБД НПРК должен использоваться УЛЗ в асинхронном сбалансированном режиме для информирования о том. что при получении ПБД от удаленного УЛЗ возникло одно из следующих условий, которое не может быть устранено путем повторной передачи того же ПБД:

I) получение недействительного или нереализованного командного или ответного ПБД. например:

а) ПБД формата УКО или НКО с полем информации, которое недопустимо в этом ПБД.

б) ПБД со значением бита П = 1, которое не запрашивалось,

в) ответного ПБД НП. который не ожидается;

2) получение ПБД И. поле информации которого превышает максимально установленную длину, приемлемую станцией по этому соединению звена данных;

3) получение недействительного номера Нпм от удаленного УЛЗ (под недействительным Нпм понимают такой Нпм. который указывает ранее переданный и уже подтвержденный ПБД И или ПБД И. который еше не передан и не является следующим ожидающим передачи ПБД И);

4) получение недействительного Нпд от удаленного УЛЗ (недействительным Нпд должен считаться такой Нпд. который больше и равен последнему переданному номеру Нпм + А. где к — максимальное число неподтвержденных ПБД И. Параметр к - это размер окна, указанный в ПБД ИДС).

Отвечающий УЛЗ должен при первой возможности передать ответный ПБД НПРК.

УЛЗ, получив ответный ПБД НПРК. должен нести ответственность за инициацию соответствующего режима работы или корректирующих действий сброса путем инициализации обоих направлений передачи соединения звена данных, используя соответствующие командные ПБД УРРАС или РЗД в зависимости от ситуации.

В ответном ПБД НПРК должно быть возвращено поле информации для указания причины непринятия ПДБ. Структура поля информации должна соответствовать черт. 5.8.

Указанные на черт. 5.8 поля должны означать следующее;

1) В качестве поля управления непринятого ПБД должно использоваться поле управления полученного ПБД, который вызвал особое условие НПРК в этом соединении звена данных. Если непринятым ПБД является ПБД формата НКО. то поле управления непринятого ПБД должно быть расположено в битовых позициях 1 — 8, а биты 9—16 должны быть установлены в 0.

2) ПД должно представлять собой текущее значение переменной передачи для этого соединения звена данных на приемной стороне УДЗ (бит 18 - младший биг).

3) К/О — бит, в значении I, должен указывать, что условие НПРК было вызвано ответным ПБД, а в значении 0 — условие НПРК было вызвано командным ПБД.

4) ПМ должно представлять собой текущее значение переменной приема для этого соединения звена данных на приемной стороне УЛЗ (бит 26 — младший биг).

Формат поля информации кадра НПРК

Sam raw ут^ивламж. /иредававмьи! в ^ъимаемый из лздурсвчй УДС лепным

ГОСТ 28907-91 С. 31

I ... /6 П <9 ... 2* 25 26.., 32 33... 36 37... W

Лоле управления непринятого

МД

w х у z

V МО

Черт. 5.8

5) W - в значении 1 этот бит должен указывать, что принятое и возвращенное в битах 1 16 поле управления было недействительным или нереализованным. Примеры недействительных ПБД:

а) получение управляющего или ненумерованного ПБД с недопустимым полем информации:

б) получение незапрошенного бита П в значении I;

в) получение ответного НН. который не ожидался.

6) X — в значении 1 этот бит должен указывать, что поле управления, принятое и возвращенное в битах 1 — 16, было недействительным, поскольку ПБД содержал поле информации, недопустимое с данной командой или ответом. Бит должен устанавливаться в значение 1 вместе с этим битом.

7) Y - в значении 1 этот бит должен указывать, что принятое поле информации превышает установленную максимальную длину, которая может быть приемлема для УДЗ. отклонившего кадр по этому соединению звена данных.

8) Z - в значении 1 этот бит должен указывать, что поле управления, принятое и возвращенное в битах 1 — 16. содержало недействительный Нпм.

9) V — в значении 1 этот бит должен указывать, что поле управления, принятое и возвращенное в битах 1 — 16. содержало недействительный Нпд. Бит должен устанавливаться в значение 1 вместе с этим битом.

6. ОПИСАНИЕ ПРОЦЕДУР УДЗ ТИПА 1

6.1. Режимы работы

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

6.2. Процедуры адресации

Поля адреса должны использоваться для указания отправителя (ПДУО) и получателя (ПДУП) ПБД УДЗ. Первый бит поля адреса отправителя (ПДУО) должен использоваться для того, чтобы определить: команда или ответ содержится в ПБД.

Для адресации ПДУП должны использоваться индивидуальные, групповые, глобальные и нулевые адреса. Поле адреса отправителя (ПДУО) должно содержать индивидуальный или нулевой адрес отправителя (см. п. 3.3.1.2).

6.3. Процедуры использования бита 3/11

Командный ПБД НИ должен передаваться только с битом 3 в значении 0. Если командный ПБД принят с битом 3 в значении I. то подуровень УДЗ может аннулировать его или передать вышерасположенному уровню с флагом, указывающим, что бит 3 был равен 1. Поскольку ПБД НИ не должен передаваться в качестве ответного ПБД. процедуры использования бита 11 здесь не применяются.

С. 32 ГОСТ 28907-91

Командный ПБД ИДС должен иметь бит 3 в значении либо 0. либо 1. При получении командного ПБД ИДС, принимающий УЛЗ должен передать обратно ответный ПБД ИДС с битом 11 в значении, равном значению бита 3 в принятом командном ПБД.

Командный ПБД ТЕСТ должен иметь бит 3 в значении либо 0, либо I. При получении командного ПБД ТЕСТ принимающий УЛЗ должен передать обратно ответный ПБД ТЕСТ с битом И в значении, равном значению бита 3 в принятом командном ПБД.

6.4. Процедуры установления н разьединения логического звена данных

Операции типа 1 не требуют никакого предварительного установления соединения звена данных, а следовательно, и разъединения звена данных. Как только пункт доступа к услугам стал доступен внутри УЛЗ (предположительно, по запросу функции управления уровнем), информация может передаваться или приниматься из пункта доступа к услугам удаленного УЛЗ. который также участвует в операциях типа I.

6.5. Процедуры передачи информации

6.5.1. Передача ПБД НИ. Передача информации должна осуществляться посылкой командного ПБД НИ с битом 3 в значении 0. Передача ПБД НИ с битом 3 в значении I, или ответного ПБД НИ запрещается. Должна обеспечиваться возможность передачи командного ПБД НИ в любой момент времени.

6.5.2. Прием ПБД НИ. При получении командного ПБД НИ на него не должно выдаваться подтверждения и не должны проверяться порядковые номера процедурами логического звена данных. Следовательно, при появлении во время передачи командного ПБД особого условия Алогическом звене данных ПБД НИ может быть потерян. Должна обеспечиваться возможность приема командного ПБД НИ в любой момент времени. Однако местные условия на приемной стороне могут привести к аннулированию принимающим УЛЗ правильных командных ПБД НИ. Командные ПБД НИ. полученные с битом 3 в значении I, могут быть аннулированы или переданы в вышерасположенный уровень с флагом, указывающим, что бит 3 был равен I.

Ге ПБД НИ. которые являются ответными, представляют собой неправильные передачи и должны быть аннулированы принимающим УЛЗ.

6.6. Использование командного н ответного ПБД ИДС

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

Примеры использования возможностей ИДС:

I) Командный ПБД ИДС с нулевым ПДУП и нулевым ПДУО служит способом запроса ответа от любой станции (т. е. от любого АП). Он представляет собой основу проверочной функции «кто там? ♦.

2) Командный ПБД ИДС с групповым АП или групповым адресом ПДУП может быть использован для определения членов группы. В частности, командный ПБД ИДС с глобальным адресом АП может идентифицировать все активные станции.

3) Может проводиться проверка дублирования адреса (см. табл. 6.1а).

4) Для УЛЗ класса 11 в РАС обмен кадрами ИДС может быть использован для определения размера приемного окна в каждом УЛЗ этого соединения звена данных.

Примечание. Использование обмена ИДС для этой иелн невозможно в фазе РДР*.

5) Обмен кадрами ИДС с нулевым ПДУП и нулевым ПДУО может идентифицировать каждый класс УЛЗ.

6) Обмен кадрами ДИС с конкретным ПДУП и конкретным ПДУО может идентифицировать типы услуг, поддерживаемых этими пунктами доступа к услугам.

7) УЛЗ может объявлять о своем присутствии глобальным адресом АП в ПБД ИДС.

6.7. Использование командного н ответного ПБД ТЕСТ

Функция ТЕСТ обеспечивает средство для тестирования шлейфа тракта передачи УЛЗ — УЛЗ. Функция ТЕСТ может быть инициирована администрацией или логическим эле-

ГОСТ 28907-91 С. 33

ментом управления уровня звена данных. Успешное завершение проверки состоит из передачи командного ПБД ТЕСТ с определенным полем информации, заданным администрацией или логическим элементом управления, по указанному адресу получателя УЛЗ и получения обратно точно такого же поля информации в ответном IIБД ТЕСТ.

Реализация передачи командного ПБД ГЕСТ является факультативной, но каждый УЛЗ должен быть способен ответить на принятый командный ПБД ТЕСТ ответным ПБД ТЕСТ. Длина поля информации является переменной от 0 до максимально возможного размера, который может обеспечить каждый УЛЗ данной ЛВС для нормальной передачи данных.

Допускается также передавать лаже большее по размеру поле информации. При этом нужно руководствоваться следующим. Если принимающий УЛ З может успешно принять и вернуть обратно это большее поле информации, то он выполнит эти действия. Если он не может принять все поле информации, а УДС может правильно вычислить КПК. то УЛЗ должен аннулировать частично принятое поле информации и может послать обратно ответный ПБД ТЕСТ без поля информации. Если УДС не может правильно вычислить КПК из-за слишком длинного поля информации, то УЛЗ должен аннулировать принятую часть поля информации и не выдавать никакого ответа. Любой командный ПБД ТЕСТ, принятый с ошибкой, должен аннулироваться без выдачи какого-либо ответного ПБД. В случае нарушения функции ТЕСТ ответственность за дальнейшие действия должна нести администрация или логический объект управления, инициировавший эту функцию.

6.8. Список параметров логического звена данных

Определен ряд параметров логического звена данных, диапазоны значений которых определяются пользователем на межсистемной основе во время запуска ЛВС.

Параметры логического звена данных для операций типа I должны быть следующими.

6.8.1. Максимальное число октетов в ПБД НИ. Любые ограничения на максимальное число октетов в ПБД НИ связаны с соответствующей спецификацией протокола УДС. Сам подуровень УЛЗ не налагает никаких ограничений. Однако для установления значения, которое будут учитывать все пользователи УЛ З типа I. все УДС должны быть способны размешать ПБД НИ с полем информации до 128 октетов включительно.

6.8.2. Минимальное число октетов в ПБД. Минимальная длина правильного ПБД должна включать точно два поля адреса ПДУ и одно поле управления в указанном порядке. Таким образом. минимальное число октетов в правильном ПБД должно равняться трем.

6.9. Точное описание процедур типа 1

При обнаружении различии с текстом разд. 6 данный подраздел (6.9) должен рассматриваться как определяющее описание.

6.9.1. Точная спецификация УЛЗ. Работа УЛЗ логически разделена на несколько компонентов. Каждый компонент характеризуется набором протокольных операций, выполняемых логическим объектом УЛЗ. и определяется путем описания протокольного автомата. Эти автоматы не задают конкретных методов реализации; они. скорее, предназначены для описания внешних характеристик логического объекта УЛЗ в том виде, как они воспринимаются логическим объектом УЛЗ удаленной станции или протоколом вышерасположенного уровня в локальной станции.

Работа УЛЗ описана с использованием трех типов компонентов:

I) Компонент СТАНЦИЯ. Этот компонент отвечает за обработку событий, которые влияют на логический объект УЛЗ в целом. Компонент СТАНЦИЯ обрабатывает ПБД. адресованные по нулевому адресу 11ДУП. а также обрабатывает ошибку дублирования адреса, если эта функция ревизована. Для каждого ПДУ УДС. присутствующего в ЛВС. должен существовать один компонент СТАНЦИЯ.

2) Компонент ПДУ. Этот компонент отвечает за обработку событий, которые влияют на специфические операции пункта доступа к услугам. Для каждого ПДУ в логическом объекте УЛЗ должен существовать один компонент ПДУ.

3) Компонент СОЕДИНЕНИЕ. Этот компонент отвечает за обработку событии, которые влияют только на конкретное соединение звена данных для процедур типа 2 (см. п. 7.9). Для каждого соединения звена данных, поддерживаемого логическим объектом УЛЗ. должен существовать один компонент СОЕДИНЕНИЕ.

С. 34 ГОСТ 28907-91

Работа каждого компонента описывается путем описания соответствующего автомата. При этом используются следующие принципы:

а) компоненты расположены иерархически (см. черт. 6.1), например компонент СТАНЦИЯ считается «старшим» по отношению к ПДУ. который в свою очередь считается «старшим» по отношению к компоненту СОЕДИНЕНИЕ.

б) каждый старший компонент имеет состояние, обеспечивающее условия для работы младших компонентов. Если старший компонент выходит из этого состояния, то младшие компоненты деактивизируются;

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

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

д) в операциях УЛЗ класса 1 каждый УЛЗ может иметь от 0 до нескольких одновременно активных ПДУ. не зависящих друг от друга и отличающихся адресами ПДУП. Услуги каждого ПДУ должны обеспечиваться отдельным компонентом ПДУ:

Взаимосвязь компонентов

а> Взаимосвязь компонентов УЛЗ класса I

б| Взаимосвязь компонентов УЛЗ класса 2

Черт. 6.1

е) в операциях УЛЗ класса 2 услуги каждого ПДУ могут обеспечивать от 0 до нескольких соединений звена данных одновременно. Каждое соединение идентифицируется двумя парами адресов УДС (АП—АО) и УЛЗ (ПДУП —ПДУО) и управляется отдельным компонентом СОЕДИНЕНИЕ.

Описание каждого компонента содержит:

I) общее описание компонента, где излагаются обшие принципы его работы:

2) диаграмму переходов состояний компонента, которая дает графическое представление о поведении компонента;

3) таблицу переходов состояний компонента, которая содержит колонки текущего состояния. события, действия(й) и следующего состояния. Эта таблица должна определять все действительные события для каждого состояния, а также результирующее действие компонента и изменение состояния;

4) описание состояний компонента, где поясняется каждое его состояние, указанное в таблице переходов состояний;

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

ГОСТ 28907-91 С. 35

6) описание действий компонента, где поясняется каждое действие, указанное в таблице переходов состояний.

Используются следующие основные правила конечных автоматов:

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

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

в) если поступающий ПБД адресован неактивному в данный момент ПДУП (т. е. соответствующий компонент неработоспособен), считается, что имеет место особое условие, которое обрабатывается специальным образом.

6.9.2. Описание компонента СТАНЦИЯ. Компонент СТАНЦИЯ отвечает за обработку всех событий, которые относятся к УЛЗ в целом (т. е. влияют на все ПДУ и соединения, обслуживаемые данным УЛЗ). Действия компонента начинаются с исходного состояния ВЫКЛЮЧЕНО, затем идет факультативная проверка дублирования адреса станции и последующий возможный переход в состояние ВКЛЮЧЕНО (см. черт. 6.2 и табл. 6.1а). В состоянии ВКЛЮЧЕНО обеспечиваются необходимые условия для работы компонентов ПДУ.

Диаграмма состояний компонента СТАНЦИЯ

ПДУЛ_КД£_КМД

Черт. 6.2

С. 36 ГОСТ 28907-91

Т а б л н и з 6.1а

Переходы состояний компонента СТАНЦИЯ

Компонент СТАНЦИЯ должен принимать и отвечать на командные ПБД ИДС и ТЕСТ. Способность передачи командного И БД ИДС является факультативной и используется, если в данной реализации УЛЗ проводится проверка дублирования адреса (см. табл. 6.16). Эти ПБД должны использовать нулевой адрес ПДУП. который означает его принадлежность компоненту СТАНЦИЯ.

Факультативные возможности компоненты СТАНЦИЯ

ГОСТ 28907-91 С. 37

Таблица 6.16

Выполнение проверки дублирования адреса требует от компонента СТАНЦИЯ подготовки к приему своего собственного ПБД ИДС. В определении операций УДС оговорена возможность одновременного выполнения передачи и приема. Следовательно, ПБД ИДС с АО = ЛП может быть использован для проверки дублирования адреса, поскольку подуровень УДС опознает свой собственный адрес и передает этот ПБД компоненту СТАНЦИЯ. Компонент СТАНЦИЯ выдает на командный ПБД ИДС ответный ПБД ИДС независимо от того, кем передана такая команда — удаленным УЛЗ или им самим. Компонент СТАНЦИЯ обеспечивает проверку дублирования адреса с помощью счетчика принятых ответных ПБД ИДС. Получение более одного ответного ПБД ИДС означает, что существует по крайней мере еще один идентичный ЛП УДС в этой ЛВС (более подробно см. черт. 6.2 и табл. 6.1а).

6.9.2.1. Описание состояний компонента СТАНЦИЯ

I. ВЫКЛЮЧЕНО — компонент СТАНЦИЯ выключен (без питания), не инициирован, и/или исключен из работы ЛВС.

2. И РОВЕРКАЛУБЛ И РОВАН ИЯ..АДРЕСА - компонент СТАНЦИЯ находится в процессе проверки дублирования адресов УДС в данный ЛВС. Основная цель этого состояния — дать возможность компоненту СТАНЦИЯ проверить, является ли адрес УДС этой станции уникальным в данной ЛВС. Компонент СТАНЦИЯ должен послать командный ПБД ИДС с адресом УДС АП = АО и ждать возможного ответного ПБД ИДС. указывающего на другие станнин с идентичными адресами УДС.

3. ВКЛЮЧЕНО — компонент СТАНЦИЯ включен (есть питание), инициирован и работоспособен в ЛВС. Всем ПДУ разрешается обмениваться ПБД УЛЗ по физической среде.

6.9.2.2. Описание событий компонента СТАНЦИЯ

I) ВК.ПОЧИ I Ь С П1’ОВЕ1’КОЙ .ДУБЛИРОВАНИЯ .-ХДРЕСА - пользователь компонента СТАНЦИЯ включил оборудование станции и потребовал, чтобы УЛЗ перед началом связи проверил наличие дублирования адреса ПДУ УДС.

2) ВКЛЮЧИ I Ь БЕЗ ПРОВЕРКИ ДУБЛИРОВАНИЯ .АДРЕСА - пользователь компонента СТАНЦИЯ включил оборудование станции, но проверка дублирования адреса не поддерживается или не требуется.

С. 38 ГОСТ 28907-91

3) ДА_ТАЙМ_ИСТЕК_И_СЧ_НОВТОР< МАКС ПОВТОР - истек тайм-аут положительного ответа и счет повторов меньше максимального числа повторов.

4) ДА ТАЙМ _ИСТЕК_И_СЧ JIOBTOP = МАКСJ1OBTOP - истек тайм-аут положительного ответа и счет повторов равен максимальному числу повторов.

5) ПРИНЯТ НУЛЬ.ПДУП ИДС.КМД- принят командный ПБД ИДС с нулевым адресом ПДУП.

6) ПРИНЯТ НУЛЬ ПДУП OI В И ИДС ()ГВ СЧ = 0 - Принят единственный ответный ПБД ИДС с нулевым адресом ПДУП.

7) ПРИНЯТ НУЛЬ.ПДУП. ИДС.ОТВ И ИДС ОТВ СЧ = 1 - принят второй ответный ПБД ИДС с нулевым адресом ПДУП.

8) ПРИНЯТ НУЛЬ ПДУП ТЕС’Г КМД - принят командный ПБД ТЕСТ с нулевым адресом ПДУП.

9) ЗАПРОС ВЫКЛЮЧИ ГЬ — пользователь станнин потребовал, чтобы оборудование станции было исключено из работы на физической среде.

6.9.2.3 Описание действий компонента СТАНЦИЯ

I) НАЧАТЬ_ДА_ТАЙМ — начать отсчет тайм-аута положительного ответа, который позволяет УЛЗ определять, принято или нет в течение заданного промежутка времени подтверждение от удаленной станции.

2) СЧ ПОВТОР: = 0 — сбросить счетчик повторов.

3) СЧ_ПОВТОР: = СЧ НОВ ЮР + 1 - увеличить значение счетчика повторов на 1.

4) ИДС () I В СЧ: = 0 — сбросить счетчик ответов ИДС.

5) ИДС ОТВ СЧ: = ИДС ОГВ СЧ + I — увеличить значение счетчика ответных ПБД ИДС на I.

6) ПЕРЕДАТЬ НУЛЬ ПДУП ИДС КМД - УЛЗ должен передать командный ПБД ИДС с нулевым адресом ПДУП и с адресами УДС АП = АО.

7) ПЕРЕДАТЬ_ИДС_ОТВ — УЛЗ должен передать ответ ИДС, используя адрес ПДУО принятого командного ПБД ИДС как адрес ПДУП ответного ПБД ИДС и используя нулевой адрес ПДУО.

8) ПЕРЕДАГЬ 1 ЕСТ ОГВ —УЛЗ должен передать ответный ПБД ТЕСТ, используя адрес ПДУО принятого командного ПБД ТЕСТ как адрес ПДУ ответного ПБД ТЕСТ и используя нулевой адрес ПДУО.

9) СООБЩИТЬ СОСТОЯНИЕ - УЛЗ должен сообщать об изменении состояния звена данных в следующих случаях:

а) СТАНЦИЯ-ВКЛЮЧЕНА (логический объект УЛЗ стал работоспособен);

б) СТАНЦИЯ ВЫКЛЮЧЕНА (логический объект УДЗ стал неработоспособен);

в) ОБНАРУЖЕНО ДУБЛИРОВАНИЕ АДРЕСА (логический объект УЛЗ обнаружил другой логический объект УЛЗ в этой ЛВС с адресом ПДУ УДС идентичным собственному адресу).

6.9.3. Описание компонента ПДУ. Компонент ПДУ обрабатывает весь поток ПБД УЛЗ типа I с конкретным адресом ПДУП в локальном компоненте СТАНЦИЯ. Пользователь локального ПДУ может активизировать и деактивизировать операции в каждом отдельном компоненте ПДУ в компоненте СТАНЦИЯ (см. черт. 6.3 и табл. 6.2). Компонент ПДУ. будучи активен. должен обрабатывать ПБД УЛЗ типа I. адресованные к данному ПДУП и передавать ПБД УЛЗ типа 1 либо по запросу пользователя ПДУ, либо как результат выполнения некоторого действия протокола.

Для УЛЗ класса 2 состояние АКТИВЕН компонента ПДУ является активизирующим условием для компонента СОЕДИНЕНИЕ (см. черт. 6.1). Любая попытка пользователя или удаленного УЛЗ установить соединение звена данных в состоянии АКТИВЕН компонента ПДУ должна передаваться компоненту УЛЗ СОЕДИНЕНИЕ типа 2 и игнорироваться компонентом ПДУ.

6.9.3.1. Описание состояний компонента ПДУ

1) НЕАКТИВЕН — компонент ПДУ УЛЗ неактивен, не функционирует или неработоспособен. Он не принимает и не передает никаких ПБД.

2) АКТИВЕН — компонент ПДУ УЛЗ активен, функционирует и работоспособен. Принимаются и передаются ПБД.

6.9.3.2. Описание событий компонента ПДУ

ГОСТ 28907-91 С. 39

1) ПДУ_ЗАПРОС ^АКТИВИЗАЦИЯ — пользователь ПДУ запросил активизировать данный компонент ПДУ и начал операции звена данных услуг типа I.

2) ПДУ ЗАП РОС ДЕАКТИВИЗЛ11ИЯ - пользователь ПДУ запросил деактивизировать данный компонент ПДУ и не допускать дальнейшей работы по логическому звену данных.

3) ИДС_ЗАПРОС — пользователь ПДУ запросил компонент ПДУ УЛЗ передать командный ПБД ИДС одному или нескольким удаленным ПДУ.

Диаграмма состояний компонента ПДУ

Черт. 6.3

Таблица 6.2

Переходы состояний компонента ПДУ

С. 40 ГОСТ 28907-91

4) ТЕСТ_ЗАПРОС — пользователь ПДУ запросил компонент ПДУ УЛЗ передать командный ПБД ТЕСТ одному или нескольким удаленным ПДУ.

5) ПРИНЯТ НИ - локальный компонент ПДУ принял ПБД НИ от удаленного ПДУ.

6) БЛОК _ДАННЫХ_ЗАПРОС - пользователь ПДУ запросил передать блок данных удаленному ПДУ УЛЗ посредством ПБД НИ.

7) ПРИНЯТ ИДС.КМД — локальный компонент ПДУ принял командный ПБД ИДС от удаленного ПДУ.

8) ПРИНЯТ ИДС_ОТВ— локальный компонент ПДУ принял ответный ПБД ИДС от удаленного ПДУ.

9) ПРИНЯТ ТЕСТ КМД — локальный компонент ПДУ принял командный ПБД ТЕСТ от удаленного ПДУ.

10) ПРИНЯТ.ТЕСТ.ОТВ - локальный компонент ПДУ принял ответный ПБД ТЕСТ от удаленного ПДУ.

6.9.3.3. Описание действий компонента ПДУ

1) БЛОК-ДАННЫХ.ИНДИКАЦИЯ - компонент ПДУ УЛЗ принял ПБД НИ от удаленного ПДУ. Сервисный блок данных передается пользователю ПДУ.

2) ПЕРЕДАТЬ НИ ПБД НИ передается одному или нескольким удаленным ПДУ по запросу пользователя передать сервисный блок данных.

3) ПЕРЕДАГЬ ИДС КМД — компонент ПДУ УЛЗ должен передать команду ИДС удаленному ПДУ по запросу пользователя ПДУ идентифицировать другие ПДУ.

4) ПЕРЕДАТЬ.ИДС.ОТВ - компонент ПДУ УЛЗ должен передать ответный ПБД ИДС удаленным ПДУ в ответ на принятый командный ПБД ИДС.

5) ПЕРЕДА ГЬ ТЕС Г КМД - компонент ПДУ УЛЗ должен передать командный ПБД ТЕСТ в ответ на запрос пользователя ПДУ проверить удаленный ПДУ.

6) ПЕРЕДАТЬ ТЕСЧ 0’1 В — компонент ПДУ УЛЗ должен передать ответный ПБД ТЕСТ в ответ на получение от удаленного УЛЗ командного ПБД ТЕСТ.

7) СООБЩИ I Ь СОСТОЯНИЕ — компонент ПДУ УЛЗ должен сообщать об изменениях своего состояния в следующих случаях:

а) ПДУ.АКТИВЕН — компонент ПДУ успешно обработал запрос на активизацию и теперь он работоспособен;

б) ПДУ.НЕАКТИВЕН — компонент ПДУ успешно обработал запрос на деактивизацию и теперь он неактивен.

8) ИДС.ИНДИКАЦИЯ — компонент ПДУ принял ответный ПБД ИДС от удаленного ПДУ. Об этом событии сообщается пользователю ПДУ и при этом ему может быть передано поле информации ИДС.

9) ТЕСТ-ИНДИКАЦИЯ - компонент ПДУ УЛЗ принял ответный ПБД ТЕСТ от удаленного ПДУ. Об этом событии оповещается пользователь ПДУ и ему может быть возвращено поле информации ответного ПБД ТЕСТ.

7. ОПИСАНИЕ ПРОЦЕДУР УЛЗ ТИПА 2

7.1. Режимы

В операциях типа 2 определены два режима работы: рабочий и нерабочий.

7.1.1. Рабочий режим. Рабочим режимом должен быть режим асинхронного ответа сбалансированный (РАС).

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

Режим РАС состоит из фазы соединения звена данных, фазы передачи информации, фазы сброса звена данных и фазы разъединения звена данных.

7.1.2 Нерабочий режим. Нерабочим режимом должен быть режим асинхронного разъединения (РДР).

ГОСТ 28907-91 С. 41

Режим РАР отличается от рабочего режима (РЛС) тем. что соединение звена данных логически разъединено с физической средой; т. е. информация (данные пользователя) не может передаваться или приниматься.

Режим РЛР определен для того, чтобы предохранить соединение звена данных от работы по физической среде в полностью рабочем режиме во время необычных ситуаций или особых условий, поскольку такая работа могла бы вызвать:

I) путаницу порядковых номеров между УЛЗ в соединении звена данных;

2) неопределенность в одном УЛЗ относительно состояния другого УЛЗ.

Условия входа соединения звена данных (РЛР) должны быть заранее определены системой.

Примерами возможных условий (в дополнении к приему командного ПБД РЗД), которые должны вызывать переход соединения звена данных в РЛР. являются:

а) включение питания.

б) ручной сброс логических схем уровня звена данных.

в) ручное переключение соединения звена данных из локального (оф-лайн) состояния в состояние «подключено к звену данных* (он-лайн).

УЛЗ в РЛР должно наблюдать за передачами, принимаемыми от УДС с целью:

1) приема одного из командных ПБД установления режима (УРРАС или РЗД) и выдачи на них ответа.

2) передачи (при необходимости) ответного ПБД ФРЗД при возможности доступа к среде.

Кроме того, поскольку УЛЗ может передавать командные ПБД в любое время, он может передать соответствующий командный ПБД установления режима.

Получив в РАР командный ПБД РЗД. УЛЗ должен выдать ответный ПБД ФРЗД. Получив в РЛС командный ПБД РЗД. УЛЗ должен выдать ответный ПБД «ненумерованное подтверждение* (НП), если он способен выполнить полученную команду.

УЛЗ в РАР не должен устанавливать особое условие «неприем кадра* (см. пп. 5.4.2.3.5 и 7.6). Режим РЛР состоит только из фазы разъединения звена данных.

7.2. Процедуры адресации

Поля адреса должны использоваться для указания отправителя (ПДУО) и получателя (ПДУП) ПБД. Первый бит поля адреса отправителя (ПДУО) должен использоваться для того, чтобы определить: команда или ответ содержится в ПБД.

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

7.3. Процедуры использования бита 3/П

УЛЗ. принимающий командный ПБД (УРРАС, РЗД. ГПР. НГПР. НПР или И) с битом 3. равным 1. должен послать ответный ПБД с битом П, равным I.

В качестве ПБД. выданного УЛЗ в ответ на командный ПБД УРРАС или РЗД с битом 3. равным I. должен быть ответный ПБД НП или ФРЗД с битом 11. равным !. В качестве ПБД, выданного УЛЗ в ответ на командный ПБД И. ГПР или НПР с битом 3. равным I. должен быть ответный ПБД И. ГПР. НПР. НГПР. ФРЗД или НПРК с битом II. равным 1. В качестве ПБД. выданного УЛЗ в ответ на командный ПБД НГПР с битом 3. равным I. должен быть ответный ПБД ГПР. НПР. НГПР. ФРЗД или НПРК с битом П. равным I.

Примечание. Бит 3 используется в УЛЗ при наличии условия восстановления по тайм-ауту (см. п. 7.5.9».

7.4. Процедуры установления и разьединения звена данных

7.4.1. Фаза соединения звена данных. Любой УЛЗ может начать инициацию соединения звена данных.

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

С. 42 ГОСТ 28907-91

При приеме ответного ПБД ФРЗД подуровень УЛЗ. видавший командный ПБД УРРАС. доджей остановить свой тайм-аут подтверждения, не входить в фазу передачи информации и сообщить об этом вышерасположенному уровню для принятия соответствующих действий.

Описание действий, вызываемых приемом командного ПБД УРРАС или РЗД, см. в п. 7.4.5. Другие ПБД типа 2 (командные или ответные), принятые во время установления соединения, должны игнорироваться УЛЗ.

Если тайм-аут подтверждения истек до приема ответного ПБД НИ или ФРЗД, то УЛЗ должен повторно передать командный ПБД УРРАС и начать повторно отсчет тайм-аута подтверждения. После повторной передачи командного ПБД УРРАС N2 раз, передающий УЛЗ должен прекратить передачу командных ПБД УРРАС и сообщить об этом вышерасположенному уровню для инициации соответствующих действий по исправлению ошибки. Значение N2 определяется в п. 7.8.2.

При приеме командного ПБД УРРАС подуровень УЛЗ должен послать индикацию сетевому уровню, чтобы указать на появление запроса установления соединения звена данных от удаленного УЛЗ.

Если затем УЛЗ патент уведомление из сетевого уровня о приемлемости соединения, то он должен передать удаленному УЛЗ ответный ПБД НП, установить свои переменные приема и передачи ПМ и ПД соответствующего соединения звена данных в 0 и войти в фазу передачи ин-формании. Передача ответного ПБД НП должна иметь преимущество над любым другим ответным ПБД того же соединения звена данных, которые могул ожидать передачи на подуровне УЛЗ. Вслед за ответным ПБД НП могут передаваться дополнительные ПБД УЛЗ. ожидающие передачи.

Если УЛЗ получил уведомление из сетевого уровня не входить в указанную фазу, то он должен передать удаленному УЛЗ ответный ПБД ФРЗД и остаться в разъединенном режиме звена.

7.4.2. Фаза передачи информации. После передачи ответного ПБД НП на командный ПБД УРРАС или после приема ответного ПБД НП на переданный командный ПБД УРРАС подуровень УДЗ должен принимать и передавать ПБД формата И и формата УКО в соответствии с процедурами, описанными в п. 7.5.

При приеме командного ПБД УРРАС в фазе передачи информации УЛЗ должен подтвердить процедуру сброса, как описано в п. 7.6.

7.4.3. Фаза разъединения звена данных. В фазе передачи информации любой УЛЗ может инициировать разъединение соединения звена данных, передав командный ПБД РЗД.

Если УЛЗ желает разъединить соединение звена данных, то он должен передать командный ПБД РЗД и начать отсчет тайм-аута подтверждения (см. п. 7.8.1). При приеме ответного ПБД НП или ФРЗД от удаленного УЛЗ локальный УЛЗ должен прекратить отсчет своего тайм-аута подтверждения и перейти в режим разъединения звена.

Если тайм-аут подтверждения истечет до приема ответного ПБД НП или ФРЗД, то УЛЗ должен передать повторно командный ПБД РЗД и начать повторный отсчет тайм-аута подтверждения. После передачи командного ПБД РЗД N2 раз передающий УЛЗ должен прекратить передачу командного ПБД РЗД, войти в фазу разъединенного звена данных и сообщить об этом вышерасположенному уровню для инициации соответствующего действия по исправлению ошибки. Значение N2 определяется в п. 7.8.2.

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

7.4.4. Фаза разъединенного звена данных. После приема командного ПБД РЗД от удаленного УЛЗ и передачи ответного ПБД НП либо приема ответного ПБД НП на переданный командный ПБД РЗД подуровень УЛЗ должен перейти в фазу разъединения звена данных.

В фазе разъединения УЛЗ может инициировать соединение звена данных. В этой фазе УЛЗ должен реагировать на прием командного ПБД УРРАС. как описано в п. 7.4.1. и передавать ответный ПБД ФРЗД в ответ на прием командного ПБД РЗД.

При приеме в фазе разъединения любого другого командного ПБД типа 2 с битом 3. равным 1. УЛЗ должен передать ответный ПБД РЗД с битом П. равным I. Другие ПБД типа 2, принятые в фазе разъединения. УЛ З должен игнорировать.

ГОСТ 28907-91 С. 43

7.4.5. Столкновение ненумерованных командных ПБД установления режима. Ситуация столкновения в УЛЗ должна разрешаться следующим образом.

Если переданный и принятый командные ПБД установления режима одинаковы, то каждый УЛЗ при первой возможности должен передать ответный ПБД НИ и перейти в указанную фазу либо после приема ответного ПБД НП. либо после истечения своего тайм-аута подтвер-ждения. Если переданный и принятый командные ПБД установления режима различны, то каждый УЛЗ должен перейти в фазу разъединения звена данных и выдать при первой возможности ответный ПБД ФРЗД.

7.5. Процедуры передачи информации

Ниже описаны процедуры, которые применяются для передачи ПБД И. в каждом направлении соединения звена данных.

В дальнейшем выражение «на единицу больше» означает непрерывно повторяющиеся серии последовательностей, т. е. 7 на единицу больше 6, а 0 на единицу больше 7 при нумерации по модулю 8.

7.5.1. Передача ПБД И. Если УЛЗ имеет ПБД И для передачи (т. е. ПБД И. еще не переданные или подлежащие повторной передаче, как описано в п. 7.5.5), то он должен передать ПБД И с номером Нид, равным его текущей переменной ILL и с Нпм, равным его текущей переменной ИМ для этого соединения звена данных. После передачи ПБД И подуровень УЛЗ должен увеличить на единицу свою переменную передачи ПД.

Если тайм-аут подтверждения не истек к моменту передачи ПБД И. то следует начать его отсчет.

Если переменная передачи ПД соединения звена данных равна последнему принятому значению Нпм плюс к (где к — максимальное число неподтвержденных ПБД И. см. п. 7.8.4). то УЛЗ не должен передавать каких-либо новых ПБД И по этому соединению звена данных, но должен обладать возможностью повторной передачи ПБД И в соответствии с п. 7.5.6 или п. 7.5.9.

Если локальный УЛЗ соединения звена данных находится в состоянии занятости, то он может передавать ПБД И при условии, что удаленный УЛЗ этого соединения звена данных сам не находится в состоянии занятости. Если в УЛЗ некоторого соединения звена данных имеется особое условие НПРК, то он должен прекратить передачу ПБД по этому соединению звена данных.

7.5.2. Прием ПБД И. Если УЛЗ соединения звена данных не находится в состоянии занятости и получает ПБД И с порядковым номером, равным переменной приема ПМ, то этот УЛЗ должен принять поле информации этого ПБД, увеличить на единицу свою переменную приема ПМ и действовать следующим образом:

I) При наличии ютовых к передаче ПБД И УЛЗ должен действовать в соответствии с п. 7.5.1 и подтверждать принятые ПБД И. устанавливая номер Нпм в поле управления следующего передаваемого ПБД И в значение переменной приема ПМ. УЛЗ может также подтвердить принятые ПБД И. передав ПБД ГПР с номером Нпм. равным значению переменной приема ПМ.

2) При отсутствии готовых к передаче ПБД И УЛЗ должен:

а) передать при первой возможности ПБД ГПР с номером Нпм. равным значению переменной приема ПМ, либо.

б) если принятым ПБЛ не являлся командным ПБД с битом 3. равным I. ожидать в течение некоторого периода времени, ограниченного вероятным истечением удаленного тайм-аута. подтверждения, пока не появится ПБД И, готовый к передаче, или ожидать накопления дополнительных ПБД И с целью их подтверждения одним ПБД ГПР. что является предметом ограничения размера окна.

3) Если прием ПБД И вызвал переход УЛЗ в состояние занятости по отношению к последующим ПБД И, то УЛЗ должен передать ПБД НГПР с номером Нпм, равным значению переменной приема ПМ. При наличии готовых к передаче ПБД И подуровень УЛЗ может передать их. как описано в п. 7.5.1, до или после передачи ПБД НГПР.

Если УЛЗ, связанный с некоторым соединением звена данных, находится в состоянии занятости и получает ПБД И в правильной последовательности, то он может игнорировать поле информации, содержащееся в любом принятом по этому соединению звена данных ПБД И (см. п. 7.5.8).

С. 44 ГОСТ 28907-91

7.5.3. Прием неправильных ПБД. Если УЛЗ принимает недействительный ПБД (см. п. 3.3.5) или ПБД с неправильным адресом ПДУП или ПДУО. то этот ПБД должен быть целиком аннулирован.

7.5.4. Прием ПБД с нарушением порядка следования. Если УЛЗ принимает ПБД И. чей номер передачи нарушает порядок следования, т. е. не равен текущей переменной приема ИМ. но находится внутри окна приема, то УЛЗ должен аннулировать поле информации этого ПБД И и передать ПБД НИР с Ним, равным значению ИМ. Затем УЛЗ должен аннулировать поле информации всех ПБД И до тех пор. пока не будет правильно принят ожидаемый ПБД И. При приеме ожидаемого ПБД И УЛЗ должен подтвердить ПБД. как описано в п. 7.5.2. УЛЗ должен использовать значения Нпм и бита 3 аннулированных ПБД И.

В конкретном соединении звена данных в любой момент времени от одного УЛЗ к другому УЛЗ может быть установлено только одно особое условие «передан НИР». Условие «передан НИР* должно сбрасываться при приеме запрошенного ПБД И. Условие «передан НИР» может быть сброшено по истечении функции тайм-аута «цеприем». Если УЛЗ узнает по истечению тайм-аута «неприем», что запрошенный ПБД И не будет принят, так как либо запрошенный ПБД И. либо ПБД НИР был потерян или содержал ошибку, то этот УЛЗ может повторить ПБД НИР с тем. чтобы повторно установить условие «передан НИР» вплоть до N2 раз. Значение N2 определяется в п. 7.8.2.

7.5.5. Подтверждение приема. При правильном приеме ПБД формата И или формата УКО, даже в состоянии занятости (см. п. 7.5.8), принимающий УЛЗ должен рассматривать Ним, содержащийся в этом ПБД. как подтверждение всех ПБД И. переданных по этому соединению звена данных с Нид вплоть до принятого Нпм минус I включительно. УЛЗ должен сбросить тайм-аут подтверждения при правильном приеме ПБД формата И или формата УКО с Нпм большим, чем последний принятый Нпм (действительно подтверждающий некоторые ПБД И).

Если тайм-аут сброшен, но все еще остались неподтвержденные ПБД И на этом соединении звена данных, то УЛЗ должен начать повторный отсчет тайм-аута подтверждения. Если этот тайм-аут затем истечет, то УЛЗ должен выполнять процедуры п. 7.5.9 относительно неподтвержденных ПБД И.

7.5.6. Прием ПБД НИР. При приеме ПБД НИР подуровень УЛЗ должен установить свою переменную передачу ПД. равную номеру Нпм. принятому в поле управления ПБД НИР. УЛЗ должен передать (в том числе повторно) соответствующий ПБД И. как только он появится. Если другие неподтвержденные ПБД И были уже переданы по этому соединению вслед за ПБД И. указанным в ПБД НИР, то эти ПБД И должны быть повторно переданы УЛЗ вслед за повторной передачей запрошенного ПБД И.

Если повторная передача началась с некоторого ПБД вследствие контрольной сверки (см. п. 7.5.9) и был принят ПБД НИР. который вызывал бы повторную передачу с того же самого ПБД И (как указано Нпм в ПБД НИР), то повторная передача в результате приема ПБД НИР должна быть запрещена.

7.5.7. Прием ПБД НГПР. УЛЗ. принявший ПБД НГПР. должен остановить как можно скорее передачу ПБД И по указанному соединению звена данных и начать отсчет тайм-аута «занято», если он еще не начат. По истечении тайм-аута «занято» УЛЗ должен выполнить процедуру. описанную в л. 7.5.9. В любом случае УЛЗ не должен передавать других ПБД И по этому соединению звена данных до тех пор. пока не будет принят ПБД ГПР или НИР. или ответный ПБД И с битом 11. равным 1. либо пока не завершится процедура сброса в этом соединении звена данных.

7.5.8. Состояние занятости УЛЗ. УЛЗ должен войти в состояние занятости в соединении звена данных, если он временно не способен принять, или продолжать прием ПБД И из-за внутренних ограничений, например ограничений приемных буферов. Ожидающие в этом соединении звена данных передачи ПБД И могут быть переданы до или после передачи ПБД НГПР. Находясь в состоянии занятости, УЛЗ должен принимать и обрабатывать ПБД формата УКО и выдавать ответный ПБД НГПР с битом П. равным I. в ответ на прием командного ПБД формата УКО или И с битом 3. равным I. по этому соединению звена данных.

Дзя указания сброса состояния занятости в соединении звена данных УЛЗ должен передать либо ответный ПБД И с битом 11. равным I. при наличии неподтвержденного бита 3. равного 1.

ГОСТ 28907-91 С. 45

либо ответного ПБД НПР или ГПР с номером Ним. равным текущей переменной приема ПМ. в зависимости от того, аннулирован ли УЛЗ поля информации правильно принятых ПБД И или нет. Кроме того, передача командного ПБД УРРАС или ответного ПБД НП должна указывать на сброс состояния занятости на передающем УЛЗ соединения звена данных.

7.5.9. Ожидание подтверждения. УЛЗ поддерживает внутреннюю переменную счета повторных передач для каждого соединения звена данных, которая должна устанавливаться в 0. когда УЛЗ принимает или передает ответный ПБД НП или командный ПБД УРРАС. либо когда УЛЗ принимает ПБД HI ПР. либо когда УЛЗ правильно принимает ПБД формата И или формата УКО с Нпм большим, чем последний принятый Нпм (действительно подтверждающий некоторые ПБД И).

По истечении тайм-аута подтверждения, тайм-аута «занято* или. возможно, тайм-аута бита 3 подуровень УЛЗ на этом соединении звена данных должен перейти в состояние восстановления по тайм-ауту и добавить единицу к своей переменной счета повторных передач.

Затем УЛЗ должен начать отсчет тайм-аута бита 3 и передать командный ПБД формата УКО с битом 3. равным 1.

Состояние восстановитения по тайм-ауту должно быть сброшено на соединении звена данных. когда УЛЗ примет от удаленного УЛЗ правильный ПБД формата И или формата УКО с битом П. равным I.

Если в состоянии восстановления по тайм-ауту УЛЗ принял без ошибок действительный ПБД формата И или формата УКО с битом 11. равным 1, и с номером Нпм. находящимся внутри диапазона, начинающегося со значения последнего принятого Нпм и до текущего значения переменной передачи включительно, то он должен сбросить состояние восстановления по тайм-ауту, установить свою переменную передачи, равной принятому номеру Нпм. остановить отсчет тайм-аута бита 3 и передать повторно все неподтвержденные ПБД.

Если в состоянии восстановления по тайм-ауту УЛЗ принял без ошибок действительный ПБД формата И или формата УКО с битом 3/П, равным 0, и с номером Нпм. находящимся внутри диапазона, начинающегося со значения последнего принятого Нпм и до текущего значения переменной передачи включительно, то он не должен сбрасывать состояние восстановления по тайм-ауту, а должен рассматривать принятое значение Нмп как подтверждение указанных ранее переданных ПБД И (см. п. 7.5.5).

По истечении тайм-аута бита 3 в состоянии восстановления по тайм-ауту УЛЗ должен прибавить единицу к своей переменной счета повторных передач. Если переменная счета повторных передач не равна N2, то УЛЗ должен передать повторно ПБД формата УКО с битом 3. равным I. и начать повторный отсчет тайм-аута бита 3.

Если переменная счета повторных передач равняется N2, то УЛЗ должен начать процедуру сброса (передав командный ПБД УРРАС), как описано в п. 7.6 ниже. N2 — это системный параметр (см. п. 7.8.2).

7.6. Процедуры сброса

Фаза сброса используется для инициации обоих направлений передачи информации в соответствии с описанными ниже процедурами. Фаза сброса должна применяться только во время режима асинхронного ответа сбалансированного (РАС).

Любой УЛЗ может начать сброс обоих направлений, передав командный ПБД УРРАС и начав отсчет тайм-аута подтверждения.

После приема командного ПБД УРРАС УЛЗ должен при первой возможности передать:

1) ответный ПБД НП и сбросить в 0 свои переменные ПМ и ПД для данного соединения звена данных либо

2) ответный ПБД ФРЗД. если это соединение звена данных должно быть завершено.

Передача ответного ПБД НП или ФРЗД должна иметь преимущество перед передачей любого другого ответного IIБД, который может ожидать передачи по тому же соединению звена данных. После ПБД НП могут следовать другие ПБД УЛЗ. если такие имеются. Если инициирующий УЛЗ правильно принял ПБД НП, то он должен сбросить свои переменные передачи и прием ПД и ПМ в 0 и остановить отсчет тайм-аута подтверждения. Должны быть также сброшены все особые условия, которые могли присутствовать в любом из УЛЗ. участвующем в сбросе. Этот обмен должен также указывать на сброс состояния занятости, которое могло быть в любом из УДЗ. участвующем в сбросе.

С. 46 ГОСТ 28907-91

При приеме ответного ПБД ФРЗД подуровень УЛЗ должен перейти в фату разъединенного звена данных, прекратить отсчет своего тайм-аута подтверждения и сообщить об этом вышерасположенному уровню для принятия соответствующих мер. Если тайм-аут подтверждения истек до приема ответного ПБД НП или ФРЗД. то командный ПБД УРРАС должен быть передан повторно и начат отсчет тайм-аута подтверждения. После истечения этого тайм-аута N2 раз передающий УЛЗ должен прекратить передачу командного ПБД УРРАС. сообщить об этом вышерасположенному уровню для инициирования соответствующих действий по исправлению ошибки и перейти в режим асинхронного разъединения. Значение N2 определено в п. 7.8.2.

Другие ПБД типа 2 (кроме командных ПБД УРРАС и РЗД), принятые УЛЗ до завершения процедуры сброса, должны быть аннулированы.

При некоторых особых условиях НПРК. перечисленных в п. 7.7. УЛЗ может запросить удаленный УЛЗ сбросить соединение звена данных, передав ответный ПБД НПРК.

При приеме ответного ПБД НПРК (даже во время особого условия НПРК) подуровень УЛЗ должен инициировать процедуру сброса путем передачи командного ПБД УРРАС либо инициировать процедуру разъединения путем передачи командного ПБД РЗД.

После передачи ответного ПБД НПРК подуровень УЛЗ должен ввести особое условие НПРК. Особое условие НПРК должно сбрасываться после того, как УЛЗ примет или передаст командный ПБД УРРАС или РЗД либо ответный ПБД ФРЗД. Любой другой командный ПБД типа 2. принятый во время наличия особого условия НПРК. должен вызывать в УЛЗ повторную передачу ответного ПБД НПРК с тем же полем информации, что и первоначально переданное.

При наличии особого условия НПРК дополнительные ПБД И не должны передаваться, а полученные ПБД формата И и формата УКО должны аннулироваться УЛЗ.

При передаче ответного ПБД НПРК подуровень УЛЗ может начать отсчет своего тайм-аута подтверждения. Если этот тайм-аут истечет до получения от удаленного УЛЗ командного ПБД УРРАС или РЗД. то УЛЗ может повторно передать ответный ПБД НПРК и начать повторный отсчет тайм-аута подтверждения. После истечения тайм-аута подтверждения N2 раз УЛЗ должен сбросить это соединение звена данных, передав командный ПБД УРРАС. Значение N2 определяется в п. 7.8.2.

Если во время отсчета тайм-аута подтверждения передаются дополнительные ответные ПБД НПРК. то отсчет этого тайм-аута не должен ни прекращаться, ни возобновляться.

7.7. Особые условия НПРК

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

УЛЗ должен начать процедуру сброса (путем передачи командного ПБД УРРАС). как описано в п. 7.6, если в фазе передачи информации он получит ответный ПБД НПРК.

7.8. Список параметров соединения звена данных

Определен ряд параметров соединения звена данных, диапазоны значений которых определяются на .межсистемной основе пользователями во время установки конкретной ЛВС.

Необходимы следующие параметры соединения звена данных для операций типа 2.

7.8.1. Функции тайм-аута. В операциях типа 2 в соединении звена данных могут иметь место ряд независимых событий, каждое из которых могло бы представлять временную функцию. Эти временные функции определены ниже так. как они идентифицированы в тексте описания операций типа 2. Понятно, что эти временные функции можно реализовать, используя ряд индивидуальных тайм-аутов или используя единственный тайм-аут. Если предусмотрена единственная временная функция, то разработчику необходимо будет определять при каждом обращении к тайм-ауту, когда останавливать отсчет, когда начинать сначала и когда продолжать начатый отсчет, основываясь на приоритетах конкретных обрабатываемых событии.

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

ГОСТ 28907-91 С. 47

Для нормальной работы процедуры необходимо, чтобы значение временных функций превышало максимальный интервал времени между выполнением нормальной сетевой операции с ПБД типа 2 и приемом соответствуюшего ПБД типа 2. выданного в ответ на ининниру-юший ПБД типа 2.

7.8.1.1. Тайм-аут подтверждения. Тайм-аут подтверждения является параметром соединения звена данных, который должен определять интервал времени, в течение которого УЛЗ должен ожидать приема подтверждения на один или несколько неподтвержденных ПБД И или ожидать ответного ПБД на переданный ненумерованный командный ПБД.

7.8.1.2. Тайм-аут бита 3. Тайм-аут бита 3 является параметром соединения звена данных, который должен определять временной интервал, в течение которого УЛЗ должен ожидать приема ПБД с битом П, равным 1. в ответ на переданную команду типа 2 с битом 3. равным I.

7.8.1.3. Тайм-аут «неприем». Тайм-аут «неприем» (НИР) является параметром соединения звена данных, который должен определять временной интервал, в течение которого УЛЗ должен ожидать приема ответа на переданный ПБД НИР.

7.8.1.4. Тайм-аут «занято». Тайм-аут «занято» является параметром соединения звена данных, который должен определять временной интервал, в течение которого УЛЗ должен ожидать указания сброса состояния занятости на другом УЛЗ.

7.8.2. Максимальное число передач — N2. N2 — это параметр соединения звена данных, который указывает максимальное число повторных передач ПБД после истечения тайм-аута подтверждения, тайм-аута бита 3 или тайм-аута «неприем».

7.8.3 Максимальное число октетов в ПБД И — Nl. N I — это параметр соединения звена данных, который определяет максимальное число октетов в ПБД И. Для определения точного значения М для конкретного метода доступа следует обратиться к описанию соответствуюшего УДС. УЛЗ сам по себе не налагает ограничений на значение NI. Однако в целях получения значения NI. от которого могут зависеть все пользователи УЛЗ типа 2. все УДС должны быть способны, по меньшей мере, обрабатывать ПБД И с полем информации до 128 октетов включительно.

7.8.4. Максимальное число неподтвержденных ПБД И — к. Максимальное число (к) последовательно пронумерованных ПБД И. которые в УЛЗ могут оставаться неподтвержденными в любой момент времени, должно быть параметром соединения звена данных, значение которого не должно превышать 127.

7.8.5. Минимальное число октетов в ПБД. Действительный ПБД соединения звена данных минимальной длины должен содержать в точности два поля адреса и одно поле управления, расположенные в перечисленном порядке. Таким образом, минимальное число октетов правильного ПБД соединения звена данных должно равняться трем или четырем в зависимости от формата ПБД: формат НКО либо формат И или УКО соответственно.

7.9. Точное описание процедур типа 2.

При обнаружении различий с текстом разд. 7 данный подраздел (7.9) должен рассматриваться как определяющее описание.

7.9.1. Описание компонента СОЕДИНЕНИЕ. Компонент СОЕДИНЕНИЕ обрабатывает весь поток ПБД типа 2 конкретного соединения звена данных (характеризующегося парами адресов: ЛИ. ПДУП — ЛО. ПДУО). Будучи активизирован, компонент СОЕДИНЕНИЕ должен обрабатывать все ПБД типа 2. адресованные локальному ПДУ от удаленного ПДУ. а также передавать ПБД типа 2 удаленному ПДУ либо по запросу пользователя, либо в результате выполнения протокола (см. черт. 7.1 и табл. 7).

Когда компонент ПДУ переходит в состояние АКТИВЕН (как описано в п. 6.9). все компоненты СОЕДИНЕНИЕ, связанные с этим ПДУ, переходят в состояние РАР (режим асинхронного разъединения). Когда компонент ПДУ выходит из состояния АКТИВЕН, все компоненты СОЕДИНЕНИЕ, связанные с этим ПДУ, деактивизируются, в каком бы состоянии они ни находились в этот момент.

При интерпретации таблицы переходов состояний необходимо учитывать следующие моменты:

1) Для уменьшения числа состояний используются переменные типа «флаг», которые указывают на наличие специальных условий, влияющих на работу компонента СОЕДИНЕНИЕ. Определены следующие флаги: 3_ФДАГ. П ФЛАГ. У_ФДАГ, ДАННЫЕ. ФЛАГ. УДАЛЕННАЯ/ЗАНЯТО.

С. 48 ГОСТ 28907-91

2) Некоторые события представлены в форме ПРИНЯТ_ХХХ_УУУ. Это следует понимать как прием любого командного или ответного ПБД. поскольку для этого состояния несущественно, какой именно ПБДЗ принят.

3) Для некоторых комбинаций состояний и событий в таблице представлены альтернативные действия. Они разделены горизонтальными пунктирными линиями в колонках «действия* и «следующее состояние». Выбор варианта действий осуществляется на основе: а) локального состояния, б) результата действия диспетчера, в) конкретной реализации. Не существует взаимосвязи между порядком альтернатив и событиями; не предполагается, что каждый раз при возникновении события должна выбираться одна и та же альтернатива.

Диаграмма состояний компонента СОЕДИНЕНИЕ

а) Установление звена данных, разъединение и сброс

Черт. 7Д

4) В списке действий не предполагается упорядоченности, если только одно или несколько действий зависят от значений и флагов, которые изменяются другими действиями. В этом случае проверки должны выполняться до модификации флагов.

5) Некоторые действия описаны в форме IlLPEJAIb XXX ОГВ (II = I). Это должно означать, что если некоторый другой ответный ПБД с битом П = 0 был передан ранее, то мож-

ГОСТ 28907-91 С. 49

но модифицировать бит II этого ПБД с 0 на I и передать новый ПБД с битом П = 0. Это возможно. например, если реализация УЛЗ управляет очередью ПБД. ожидающих передачи.

6) Для упрощения таблицы используются следующие четыре тайм-аута: ДА_ТАЙМ (тайм-аут подтверждения). 3_ТАЙМ (тайм-аут цикла 3/П), НПР. ТАЙМ (тайм-аут «неприем») и ЗАНЯТО.ТАЙМ (тайм-аут «занято»). Введением дополнительных флагов можно написать функционально эквивалентную таблицу переходов состояний с использованием только одного тайм-аута.

7) Любое действие НАЧАТЬ_ТАЙМ вызывает начало (в том числе повторное) отсчета указанного тайм-аута с нуля, лаже если уже шел отсчет этого тайм-аута. При достижении своего предела появляется условие ТАЙМ.ИСТЕК и отсчет тайм-аута прекращается. Условие ТАЙМ ИСТЕК сбрасывается автоматом компонента СОЕДИНЕНИЕ при его распознавании. Действие ОСТАНОВИТЬ^ТАЙМ прекращает отсчет тайм-аута, если он имел место, или сбрасывает условие ТАЙМ-ИСТЕК, если тайм-аут уже достиг своего предела.

8) Предполагается, что события, не представленные в некотором состоянии, остаются в ожидании, пока не будет изменен какой-либо маскирующий флаг или выполнен переход в состояние. где это событие представлено.

Примечание. Для правильного понимания таблицы переходов состояний необходимо одновременно читать описания се входов (см. пп. 7.9.1.1 — 7.9.13).

7.9.1.1. Описание состояний компонента СОЕДИНЕНИЕ

1) РАР — компонент находится в режиме асинхронного разьединения, в котором он может принимать ПБД УРРАС от удаленного ПДУО УЛЗ или по запросу пользователя ПДУ передавать такой ПБД удаленному ПДУП УЛЗ для установления соединения звена данных. Кроме того, компонент отвечает на командный ПБД РЗД и другие командные ПДУ с битом 3 = 1.

2) УСТАНОВ — компонент передал командный ПБД УРРАС удаленному ПДУП УЛЗ и ожидает от него ответа.

3) НОРМА — существует соединение звена данных между локальным и удаленным ПДУ. Возможен прием и передача информационных и управляющих ПБД.

4) ЗАНЯТО — существует соединение звена данных между локальным и удаленным ПДУ, по которому могут передаваться ПБД И. Местные условия делают вероятным аннулирование поля информации принятых ПБД И. Управляющие ПБД могут приниматься и передаваться.

5) НЕПРИЕМ — существует соединение звена данных между локальным и удаленным ПДУ. Местный компонент СОЕДИНЕНИЕ потребовал, чтобы удаленный компонент СОЕДИНЕНИЕ повторно передал указанный ПБД И, который был получен с нарушением последовательности. Могут передаваться и приниматься информационные и управляющие ПБД.

6) ЖДАТЬ — существует соединение звена данных между локальным и удаленным ПДУ. Локальный УЛЗ выполняет операцию восстановления по тайм-ауту, передав командный ПБД с битом 3 = 1 и ожидает подтверждение от удаленного УЛЗ: ПБД И могут быть приняты, но не могут быть переданы. Управляющие ПБД могут быть переданы и приняты.

7) ЖДАТЬ /ЗАНЯ ГО — существует соединение звена данных между локальным и удаленным ПДУ. Локальный УЛЗ выполняет операцию восстановления по тайм-ауту, передав командный ПБД с битом 3=1 и ожидая подтверждения от удаленного УЛЗ. ПБД И не могут передаваться. Местные условия делают вероятным неприем поля информации полученных ПБД И. Управляющие ПБД могут приниматься и передаваться.

8) ЖДА1Б НЕПРИЕМ — существует соединение между локальным и удаленным ПДУ. Локальный компонент СОЕДИНЕНИЕ запросил удаленный компонент СОЕДИНЕНИЕ повторно передать указанный ПБД И. который был получен с нарушением последовательности. Перед переходом локального УЛЗ в эго состояние он выполнял операцию восстановления по тайм-ауту, передав командный ПБД с битом 3=1, и все еще ожидает подтверждения от удаленного УЛЗ. ПБД И могут приниматься, но не могут передаваться. Управляющие ПБД могут приниматься и передаваться.

9) РАЗЪЕДИНЕНИЕ — по запросу пользователя ПДУ локальный УЛЗ передал командный ПБД РЗД удаленному ПДУП УЛЗ и ждет ответа.

10) СБРОС — в результате запроса пользователя ПБД или приема ответного ПБД НПРК местный компонент СОЕДИНЕНИЕ передал командный ПБД УРРАС удаленному ПДУП для сброса соединения звена данных и ждет ответа.

С. 50 ГОСТ 28907-91

II) ОШИБКА - локальный компонент СОЕДИНЕНИЕ обнаружил ошибку в принятом ПБД и передал ответный ПБД НПРК. после чего ожидает ответа от удаленного компонента СОЕДИНЕНИЕ.

12) СОЕДИНЕНИЕ-локальный компонент СОЕДИНЕНИЕ получил ПБД УРРАС от удаленного ПБД УЛЗ и ожидает, примет или отклонит локальный пользователь это соединение.

13) СБРОС ОШИБКИ - локальный компонент СОЕДИНЕНИЕ ждет, примет или отклонит локальный пользователь удаленный запрос сброса.

14) СБРОС ЖДАТЬ - локальный компонент СОЕДИНЕНИЕ ожидает от локального пользователя указания ЗД СБРОС или ЗД РАЗЪЕДИНЕНИЕ.

7.9.1.2. Описание событий компонента СОЕДИНЕНИЕ. В списке событий, приведенном ниже, значение битов 3 и II в принимаемых командах и ответах записывается в виде X. В таблице переходов состояний используются значения — 0. 1 или X. Последнее означает, что в этом событии может быть значение как 0. так и I.

I) СОЕД_ЗАПРОС — пользователь затребовал установления соединения с удаленным ПДУП УЛЗ.

2) СОЕД ОТВЕТ — пользователь согласился установить соединение.

3) ДАННЫЕ ЗАПРОС - пользователь потребовал передать блок данных удаленному ПДУП УЛЗ.

4) РАЗ ЬЕЗД ЗАП РОС — пользователь потребовал завершить соединение с удаленным ПДУП УЛЗ.

5) СБРОС-ЗАПРОС — пользователь потребовал выполнить сброс соединения с удаленным ПДУП УЛЗ.

6) СБРОС_ОТВЕТ — пользователь дат согласие на сброс соединения звена данных.

7) МЕСТНАЯ ЗАНЯТОСТЬ.ОБНАРУЖЕНА — локальная станция вошла в состояние занятости и не может принимать ПБД И от удаленного ПДУО.

8) МЕС ТНАЯ ЗАНЯ ТОСТБ.УС1 РАНЕНА — на локальной станции устранено состояние занятости, и она теперь может принимать ПБД И от удаленного ПДУО.

9) ПРИНЯТ НЕДЕЙСТВИТЕЛЬНЫЙ .ПБД - удаленный ПДУО передал локальному ПДУП командный или ответный ПБД, который не может быть реализован или имеет поле информации. которого не должно быть или длина которого больше, чем может принять локальный УЛЗ.

10) ПРИНЯТ.РЗД КМД (3 = X) - удаленный ПДУО передал командный ПБД РЗД с битом 3 в значении X. адресованный локальному ПДУП.

II) ПРИНЯТ.ФРЗД.ОТВ (П = X) - удаленный ПДУО передал ответный ПБД ФРЗД с битом П в значении X. адресованный локальному ПДУП.

12) ПРИНЯТ.НПРК.ОТВ (П = X) - удаленный ПДУО передач ответный ПБД НПРК с битом 11 в значении X. адресованный локальному ПДУП.

13) ПРИНЯТ.И КМД (3 = X) - удаленный ПДУО передал командный ПБД И с битом 3 в значении X. адресованный локальному ПДУП. Поля Нпм. Нпд — действительны, а значение Нпд — ожидаемый порядковый номер.

14) ПРИНЯТ.И.КМД (3 = X) С.Нпд г ИМ - удаленный ПДУО передач командный ПБД И с битом 3 в значении X. адресованный локальному ПДУП; поле Нпд — действительно, но не содержит ожидаемый порядковый номер, хотя он и в рамках окна; поле Нпм — действительно.

15) ПРИНЯТ. И. КМД (3 = Х)_С_НЕДЕЙСТВИТЕЛЬНЫМ_Нпд - удаленный ПДУО передач командный ПБД И с битом 3 в значении X. адресованный локальному ПДУП. Поле Нпд - недействительно, поле Нпм — действительно.

16) ПРИНЯТ. И OI В (11 = X) - удаленный ПДУО передач ответный ПБД И с битом II в значении X. адресованный локальному ПДУП. Поля Нпм и Нпд — действительные, а значение Нпд — ожидаемый порядковый номер.

17) ПРИНЯТ. И OIB (П = Х)_С_Нпд*ПМ-удаленный ПДУО передач ответный ПБД И с битом П в значении X. адресованный локальному ПДУП Поле Нпд не содержит ожидаемого порядкового номера, но находится в рамках окна приема.

ГОСТ 28907-91 С. 51

18) ПРИНЯ ЛИ. ОГВ (П = Х)_С_НЕДЕЙСТВИТЕЛЬНЫМ Нпд - удаленный ПДУО передал ответный ПБД И с битом II в значении X, адресованный локальному ПДУП. Поле Нпд — недействительно, поле Нпм — действительно.

19) ПРИНЯТ_НПР_КМД (3 = X) - удаленный ПДУО передал командный ПБД НИР с битом 3 в значении X. адресованный локальному ПДУП.

20) ПРИНЯТ_НПР_ОТВ (11 = Х) - удаленный ПДУО передал ответный ПБД НИР с битом П в значении X. адресованный локальному ПДУП.

21) ПРИНЯТДП ПР КМД (П = X) - удаленный ПДУО передал командный ПБД НГПР с битом 3 в значении X. адресованный локальному ПДУП.

22) ПРИНЯТ_НГПР_ОТВ (П = X) - удаленный ПДУО передал ответный ПБД НГПР с битом II в значении X, адресованный локальному ПДУП.

23) ПРИНЯ Г_ГПР КМД (3 = X) - удаленный ПДУО передал командный ПБД ГПР с битом 3 в значении X. адресованный локальному ПДУП.

24) ПРИНЯТ_ГПР~ОТВ (11 = X) - удаленный ПДУО передал ответный ПБД ГПР с битом II в значении X, адресованный локальному ПДУП.

25) ПРИНЯТ_УРРАС_КМД <3 = X) - удаленный ПДУО передал командный ПБД УРРАС с битом 3 в значении X. адресованный локальному ПДУП.

26) ПРИНЯТД1П ОТВ (П = X) - удаленный ПДУО передал ответный ПБД НП с битом II в значении X. адресованный локальному ПДУП.

27) ПРИНЯТ_ХХХ_КМД (3 = X) - удаленный ПДУО передал один из командных ПБД типа 2 с битом 3 в значении X. адресованный локальному ПДУП. Вид команды не имеет значения в данном состоянии.

28) ПРИНЯТ-ХХХ-ОТВ (П = X) - удаленный ПДУО передал один из ответных ПБД типа 2 с битом П в значении X, адресованный локальному ПДУП. Конкретный вид ответа не имеет значения в данном состоянии.

29) ПРИНЯТ_ХХХ_УУУ - удаленный ПДУО передал ПБД типа 2, адресованный локальному ПДУП. Этот ПБД может быть любой командой или ответом.

30) ПРИНЯТ_ХХХ_КМД (3= Х)_С_НЕДЕЙСТВИТЕЛЬНЫМ Нпм - удаленный ПДУО передал один из командных ПБД: И, ГПР. НГПР или НИР с битом 3 в значении X, адресованный локальному ПДУП. Поле Нпм недействительно.

31) ПРИНЯГ_ХХХ_ОТВ (П »XLC. НЕДЕЙСТВИТЕЛЬНЫМ Нпм - удаленный ПДУО передал один из ответных ПБД: И. ГПР. НГПР или НИР с битом 11 в значении X. адресованный локальному ПДУП. Поле Нпм недействительно.

32) 3-ТАЙМ ИСТЕК - истек тайм-аут цикла 3/11.

33) ДА_ТАЙМ ИСТЕК — истек тайм-аут подтверждения.

34) НПР_ТАЙМ_ИСТЕК - истек тайм-аут «передан НИР».

35) ЗАНЯТО_ТАЙМ_ИСТЕК — истек тайм-аут удаленный занятости.

В таблице переходов состояний некоторые из перечисленных выше событий сопровождаются дополнительными условиями. Событие считается наступившим, если дополнительные условия имеют значение «истинно».

36) ДАННЫЕ ФЛАГ = I — если ДАННЫЕ ФЛАГ имеет значение 1, то блок (и) данных, принятых ПБД И. был (и) аннулирован (ы) во время локальной занятости.

37) ДАННЫЕ ФЛАГ = 0 — если ДАННЫЕ ФЛАГ имеет значение 0. то блок (и) данных, принятых ПБД И. не был (и) аннулирован (ы) во время локальной занятости.

38) ДАННЫЕ ФЛАГ = 2 - ДАННЫЕ ФЛА1 имеет значение 2, когда переход в состояние ЗАНЯТО произошел из состояния НЕПРИЕМ. а затребованные ПБД И еше не были приняты.

39) 3. ФЛА1 = I — 3. ФЛАГ имеет значение 1. если передан командный ПБД с битом 3 = I и ожидается прием ответа с битом 11 = 1.

40) 3_ФЛАГ = 0 — З.ФЛАГ имеет значение 0, если не ожидается приема ответного ПБД с битом П = I.

41) 3_ФЛАГ = 11 — 3 ФЛАГ имеет значение, равное значению бита II в принятом ответном ПБД.

42) УДАЛЕННАЯ ЗАНЯТО = I - если УДАЛЕННАЯ_ЗАНЯТО имеет значение 1. значит, был принят ПБД НГПР от удаленного компонента СОЕДИНЕНИЕ, указывающий на не-

С. 52 ГОСТ 28907-91

возможность передачи ПБД И. События ДАННЫЕ ЗАПРОС не распознаются, пока этот флаг не будет установлен в 0.

43) УДАЛЕННАЯ ЗАНЯТО = 0 -если УДАЛ ЕН НАЯ-ЗАНЯТО имеет значение 0, то передача ПБД И возможна.

44) СЧ ПОВТОР < N2 — число повторов меньше максимального числа повторов.

45) СЧ ПОВ ТОР 2 N2 — число повторов достигло предела.

46) У_ФЛАГ= I - в состояниях УСТАНОВ. СБРОС. СБРОС.ЖДАТЬ значение I переменной У_ФЛАГ указывает, что был принят ПБД УРРАС.

47) У ФЛАГ = 0- в состояниях УСТАНОВ. СБРОС. СБРОС.ЖДАТЬ значение 0 переменной У ФЛАГ означает, что ПБД УРРАС не принят.

48) НАЧАТ 3/П ЦИКЛ — локальный УЛЗ желает инициировать цикл 3/П (это требуется только в том случае, если локальный УЛЗ по некоторым причинам не генерирует других командных ПБД).

7.9.1.3. Описание действий компонента СОЕДИНЕНИЕ. В списке действий, приведенном ниже, значения битов 3 и П в передаваемых командах и ответах указаны, как X. В списке действий таблицы переходов состояний используются значения 0. 1 или X. Последнее означает, что может использоваться 0 или I.

1) УДАЛЕННАЯ ЗАНЯТО: = 0 - УДАЛ ЕН НАЯ -ЗАНЯТО, имевшая значение I. устанавливается в 0, указывая тем самым на способность удаленного УЛЗ принимать ПБДЗИ, прекращается отсчет ЗАНЯТО ТАЙМ, инициируется СЧ ПОВТОР: = 0. информируется функция управления подуровнем посылкой ОТЧЕТ .СОСТОЯНИЕ (УДАЛЕННАЯ .НЕ_ЗАНЯТО) и начинается (повторная) передача ПБД И. ожидавших снятия удаленной занятости, при условии, что локальный УЛЗ находится в состоянии НОРМА, НЕПРИЕМ или ЗАНЯТО.

2) СОЕД ИНДИКАЦИЯ — информирует пользователя о том, что удаленный ПДУО запросил установление соединения.

3) СОЕД ПОД I ВЕРЖДЕНИЕ - компонент СОЕДИНЕНИЕ указывает, что удаленный логический объект сетевого уровня воспринял соединение.

4) ДАННЫЕ ИНДИКАЦИЯ - компонент СОЕДИНЕНИЕ передает пользователю блок данных из принятого ПБД И.

5) РАЗЬЕД ИНДИКАЦИЯ — информирует пользователя о том. что логический объект сетевого уровня начал разъединение данного соединения.

6) СБРОС-ИНДИКАЦИЯ — информирует пользователя о том. что удаленный логический объект сетевого уровня или удаленный компонент УЛЗ начал сброс соединения, или что локальный УЛЗ определил необходимость повторной инициации соединения. Действительными параметрами являются:

УДАЛ. — сброс соединения начат по инициативе удаленного логического объекта (сетевого или УЛЗ):

МЕСТ. — локальный УЛЗ определил необходимость повторной инициации соединения.

7) СБРОС-ПОДТВЕРЖДЕНИЕ - компонент СОЕДИНЕНИЕ сообщает, что удаленный логический объект сетевого уровня воспринял сброс.

8) СООБЩИТЬ_СОСТОЯНИЕ - сообщает функция управления подуровнем состояние соединения. Допустимыми значениями являются:

НПРК ПРИНЯТ-локальный компонент СОЕДИНЕНИЕ принял ответный ПБД НПРК;

ПИРК ПЕРЕДАН — локальный компонент СОЕДИНЕНИЕ принял недействительный ПБД и передал ответный ПБД НПРК;

УДАЛЕННАЯ_ЗАНЯТО — удаленный ПДУП занят; локальный компонент СОЕДИНЕНИЕ не может принимать ДАННЫЕ ЗАПРОС:

УДАЛЕННАЯ НЕ ЗАНЯТО — удаленный ПДУП более не занят: локальный компонент СОЕДИНЕНИЕ может теперь принимать ДАННЫ Е_ЗАП РОС.

9) ЕСЛИ_П= LУДАЛЕИНАЯ ЗАНЯТО: = 0- если на командный ПБД с битом 3= 1 принят ответный ПБДЗИ с битом П = 1, то выполняется действие УДАЛЕННАЯ ЗАНЯТО: =0.

10) ЕСЛИ ДАННЫЕ ФЛА1 = 2. ОСТАНОВИТЬ ННР ТАЙМ - если переменная ДАННЫЕ ФЛАГ имеет значение 2. указывая, что ПБД НИР передан, то отсчет тайм-аута «передан НИР» прекращается.

ГОСТ 28907-91 С. 53

11) ПЕРЕДАТЬ РЗД. К МД (3 = X) - передать удаленному ПДУП командный ПБД РЗД с битом 3, равным X.

12) ПЕРЕДАТЬ ФРЗД ОТВ (П = X) - передать удаленному ПДУП ответный ПБД ФРЗД с битом П. равным X.

13) ПЕРЕДАТЬ НПРК-ОТВ (11 = X) - передать удаленному ПДУП ответный ПБД НПРК с бигом П. равным X.

14) ПЕРЕДАТЬ ПОВЮРНО ННРК ОТВ (П = 0) - передать удаленному ПДУП ответный ПБД НПРК с тем же полем информации, что и переданное ранее. Бит П установить в значение 0.

15) ПЕРЕДАТЬ ПОВТОРНО НПРК OTBJH = 3) - передать удаленному ПДУП ответный ПБД НПРК с тем же полем информации, что и переданное ранее. Бит П установить равным биту 3 принятого командного ПБД.

16) ПЕРЕДАТЬ И КМД (3 = 1) — передать удаленному ПДУП командный ПБД И с битом 3=1 и с блоком данных, выданный пользователем в примитиве ДАННЫЕ_ЗАПРОС. Перед передачей скопировать переменные ПД и ПМ соответственно в поля Нпд и Ним передаваемого ПБД И и увеличить на единицу (по модулю 128) переменную ПД.

17) ПЕРЕДАТЬ ПОВТОРНО И КМД (3 = Г) - начать повторную передачу всех неподтвержденных ПБД И этого соединения, начиная с номера, равного Нпм. в принятом ПБД. Первый ПБДЗИ передать как команду с битом 3=1. Остальные ПБД И можно передавать как команды с битом 3 = 0 либо как ответы с битом П = 0.

IX) ПЕРЕДАТЬ ПОВТОРНО И КМД (3 = 1»ЕЛИ_ПЕРЕДАТЬ_ГПР - начать повторную передачу всех неподтвержденных ПБД И для этого соединения, начиная с номера, равного Нпм в принятом ПБД. Первый передать как команду с битом 3=1. Остальные ПБД И можно передавать как команды с битом 3 = 0 либо как ответы с битом П = 0. Допускается передать удаленному ПДУП командный ПБД ГПР с битом 3 = I перед началом повторной передачи ПБД И. В этом случае первый ПБД И должен передаваться как команда с битом 3 = 0 либо как ответ с битом 11=0. Если нет готовых к передаче ПБД И. то удаленному ПДУП дат-жен быть передан командный ПБД ГПР с битом 3=1.

19) НЕ РЕДД ГБ И XXX (X = 0) - передать удаленному ПДУП блок ПБД И как ответ либо как команду с битом 3/П = 0 и с блоком данных, выданным пользователем в примитиве ДАННЫЕ_ЗАПРОС. Перед передачей скопировать текущие значение переменных ПД и ПМ в поля Нпд и Нпм соответственно блока ПБД И и увеличить после этого переменную ПД на единицу (по модулю 128).

20) ПЕРЕДАГЬ ПОВТОРНО И XXX (X = 0) — начать повторную передачу всех неподтвержденных ПБД И. начиная с номера Нпм, который содержится в последнем принятом ПБД. Они должны быть переданы как команды либо как ответы с битом 3/11 =0.

21) ПЕРЕДАГЬ ПОВТОРНО И XXX (X = 0)_И.1И ПЕРЕДАГЬ П1Р - начать повторную передачу всех неподтвержденных ПБД И. начиная с номера Нпм. содержащегося в принятом ПБД. Они должны быть переданы как команды либо как ответы с битом 3/П = 0. Допускается передать удаленному ПДУП командный или ответный ПБД ГПР с битом 3/П =0 перед началом повторной передачи ПБД И. Если нет готовых к передаче ПБД И. то необходимо передать удаленному ПДУП командный или ответный ПБД ГПР с битом 3/П = 0.

22) ПЕРЕДАТЬ. ПОВТОРНО..И .ОТВ (11= I > — начать повторную передачу всех неподтвержденных для данного соединения ПБД И. начиная с номера Ним. содержащегося в принятом ПБД. Первый ПБД И должен передаваться как ответ с битом 11=1, остальные либо как команды, либо как ответы с битом 3/11 = 0.

23) ПЕРЕДАТЬ НПР_КМД (3=1)- передать удаленному ПДУП командный ПБД НПР с битом 3=1.

24) ПЕРЕДАТЬ. НПР.. ОТ В (П = I) - передать удаленному ПДУП ответный ПБД НПР с битом П = 1.

25) ПЕРЕДАТЬ НПР_ХХХ (X = 0) — передать удаленному ПДУП ответный или командный ПБД НПР с битом 3/П = 0.

26) ПЕРЕДАТЬ НГПР_КМД (3 = 1) - передать удаленному ПДУП командный ПБД НГПР с битом 3=1.

С. 54 ГОСТ 28907-91

27) ПЕРЕДАТЬ НГПР_ОТВ (П = I) - передать удаленному ПДУП ответный ПБД НГПР с битом 11 = !.

28) ПЕРЕДАТЬ НГПР XXX (X = 0) - передать удаленному ПДУП командный ПБД НГПР с битом 3 = 0 либо ответный ПБД НГПР с битом П = 0.

29) УДАЛ ЕН Н АЯ_ЗАНЯТО: = I-если УДАЛЕННАЯ ЗАНЯТО имеет значение 0. то установить ее в значение I для указания состояния занятости удаленного УЛЗ и его неспособности принимать ПБД И. Начать отсчет тайм-аута ЗАНЯТО-ТАЙМ, проинформировать об этом функцию управления подуровнем пользователя об лом посылкой ОТЧЕТ_СОСТОЯНИЕ (УДАЛЕННАЯ ЗАНЯТО) и прекратить текущую передачу ПБД И.

30) МОЖНО ПЕРЕДАТЬ HI ПР XXX (X = 0) - разрешается передать удаленному ПДУП командный или ответный ПБД НГПР с битом 3/11 = 0 в случае, если удаленный УЛЗ не принял первый НГПР. переданный во время установления состояния занятости.

31) ПЕРЕДАТЬ.ГПР_КМД (3= I)-передать удаленному ПДУП командный ПБД ГПР с битом 3=1.

32) ПЕРЕДАТЬ ДА КМД (3=1) —в любом случае разрешается передать удаленному ПДУП командный ПБД с битом 3= I. При отсутствии готовых к передаче ПБД И необходимо передать удаленному ПДУП командный ПБД ГПР с битом 3= I (выдача лого ПБД ГПР может быть ’задержана на время, ограниченное ДА_ТАЙМ в ожидании генерации ПБД И). Однако, если ПБД И готов к передаче и может быть модифицирован в команду с битом 3= 1. то передача командного ПБД ГПР не требуется.

33) ПЕРЕДАТЬ ГПР_ОТВ (П = I) - передать удаленному ПДУП ответный ПБД ГПР с битом П = I.

34) ПЕРЕДАТЬ ДА ОТВ (П = 1) — в любом случае разрешается передать удаленному ПДУП ответный ПБД ГПР с битом II = I. Если нет готовых к передаче ПБД И. то необходимо передать удаленному ПДУП ответный ПБД ГПР с битом 11=1. Однако, если ПБД И готов к передаче и может быть модифицирован в ответ с битом П = I, то передача ответного ПБД ГПР не требуется.

35) ПЕРЕДАТЬ ГПР XXX (X = 0) — передать удаленному ПДУП командный или ответный ПБД ГПР с битом 3/П = 0.

36) ПЕРЕДАТЬ ДА_XXX (X = 0) — в любом случае разрешается передать удаленному ПДУП командный или ответный ПБД ГПР с битом 3/П = 0. Если нет ПБД И. готовых к передаче, то должен быть передан удаленному ПДУП командный или ответный ПБД ГПР с битом 3/11 = 0 (лот ПБД ГПР может быть задержан на время, ограниченное значением ДА_ТАЙМ в ожидании генерации ПБД И). Однако, если ПБД И готов к передаче, то передача ПБД ГПР не требуется.

37) ПЕРЕДАТЬ УРРАС КМД (3 = X) - передать удаленному ПДУП командный ПБД УРРАС с битом 3, равным X.

38) ПЕРЕДАТЬ НП ОГВ (II = X) - передать удаленному ПДУП ответный ПБД НП с битом II. равным X.

39) У ФЛАГ: = 0 — установить У_ФЛАГ в значение 0 для указания на то. что ПБД УРРАС не получен от удаленного УЛЗ при нахождении локального компонента СОЕДИНЕНИЕ в состоянии СБРОС. УС ГАНОВ или СБРОС ЖДА ТЬ.

40) У ФЛАГ: = I — установить У_ФДАГ в значение 1 для указания на то. что ПБД УРРАС получен от удаленного УЛЗ при нахождении локального компонента СОЕДИНЕНИЕ в состоянии СБРОС. УСТА НОВ или СБРОС.ЖДАТЬ.

41) НАЧАТЬ_3_ТАЙМ — начать отсчет тайм-аута 3/П с нуля и установить СЧ_ПОВТОР в значение 0). а 3 ФЛАГ — в значение I.

42) НАЧАТЬ_ДА_ТАЙМ — начать отсчет тайм-аута подтверждения с нуля.

43) НАЧАТЬ НИР ТАЙМ — начать отсчет тайм-аута -передан НИР* с нуля.

44) НАЧАТЬ ДА ТАЙМ ЕСЛИ НЕ НАЧА1 — если отсчет тайм-аута подтверждения не начат, то начать отсчет лого тайм-аута с нуля.

45) ОСТАНОВИТЬЛА_ТАЙМ — прекратить отсчет тайм-аута подтверждения.

46) ОСТАНОВИТЬ_3_ТАЙМ — прекратить отсчет тайм-аута 3/П и установить 3_ФЛАГ в значение 0.

47) ОСТАНОВИТЬ_НПР_ТАЙМ - прекратить отсчет тайм-аута -передан НПР*.

ГОСТ 28907-91 С. 55

48) ОСТАНОВИТЬ ВСЕ.ТЛЙМ — прекратить отсчет всех тайм-аутов.

49) ОСТАНОВИТЬ_ОСТАЛЬНЫЕ_ТАЙМ - прекратить отсчет тайм-аутов: 3/П. «передан НИР» и занятости удаленной станнин.

50) ОБНОВИ ГБ Нпм — если Нпм принятого ПБД подтверждает прием одного или нескольких ранее неподтвержденных ПБД И, то обновить локальный номер Нпм. установить переменную СЧ ПОВТОР в значение 0, прекратить отсчет тайм-аута подтверждения. Если еще остаются неподтвержденные ПБД И или инициируется передача ПБД И одновременно с действием ОБНОВИТЬ Нпм. то необходимо начать отсчет тайм-аута подтверждения, если он был прекращен.

51) ОБНОВИ ГБ _3_ФЛАГ — если принятый ПБД был ответом с битом Н = 1. установить 3. ФЛАГ в значение 0 и прекратить отсчет тайм-аута 3/П.

52) ДАННЫЕ ФЛАГ: = 2 — установить ДАННЫЕ_ФЛАГ в значение 2 для указания на то. что состояние ЗАНЯ ТО было введено после состояния НЕПРИЕМ.

53) ДАННЫЕ ФЛАГ: = 0 — установить ДАННЫЕ_ФЛАГ в значение 0 для указания на то. что блоки данных из принятых ПБД И не аннулированы во время локальной занятости.

54) ДАННЫЕ ФЛАГ: = 1 — установить ДАННЫЕ_ФЛАГ в значение I для указания на то. что блоки данных из принятых ПБД И были аннулированы во время локальной занятости.

55) ЕСЛ И ЛАНН Ы Е_ФЛАГ = 0_ТОГДА ДАН Н Ы Е ФЛАГ = 1 - если ДАН Н Ы Е_ФЛАГ имел значение 0. указывая, что ни один блок данных не был аннулирован, то установить его в значение 1 для указания на то. что теперь блоки данных будут аннулированы.

56) 3 ФЛАГ: = 0 — установить 3 ФЛАГ в значение 0, указав этим, что не ожидается прием ответного ПБД с битом 11=1.

57) 3. ФЛАГ: = 3 — установить 3 ФЛАГ в значение, равное значению бита 3 переданного командного ПБД.

58) УДАЛЕННАЯ .ЗАНЯТО:» 0-установить УДАЛЕН НАЯ-ЗАНЯТО в значение 0 для указания на то. что удаленный УЛЗ способен принимать ПБД И.

59) СЧ ПОВТОР: = 0 - сбросить значение СЧ .ПОВТОР в поль.

60) СЧ_ПОВТОР: = СЧ НОВ ГОР + 1 — увеличить на единицу значение счетчика повторных передач.

61) ПМ: = 0 — инициировать переменную приема, являющуюся порядковым номером следующего ожидаемого на приема ПБД И.

62) ПМ: = ПМ + I — увеличить на единицу (по модулю 128) переменную приема, являющуюся порядковым номером следующего ожидаемого на приеме ПБД И.

63) ПД: = 0 — инициировать переменную передачи; это порядковый номер следующего ПБД И. ожидающего передачи.

64) ПД: = Нпм — установить переменную состояния передачи в значение, указанное полем Нпм в только что принятом ПБД.

65) П ФЛАГ: = 3 — установить П ФЛАГ в значение принятого бита 3. Эго значение бита П. в подлежащем передаче ответе ПБД НИ или ФРЗД.

Таблица 7

Переходы состояний компонента СОЕДИНЕНИЕ

С. 56 ГОСТ 28907-91

Продолжение табл. 7

ГОСТ 28907-91 С. 57

Продолж ение табл. 7

С. 58 ГОСТ 28907-91

Продолжение табл. 7

ГОСТ 28907-91 С. 59

Продолж ение табл. 7

С. 60 ГОСТ 28907-91

Продолжение табл. 7

ГОСТ 28907-91 С. 61

Продолж ение табл. 7

С. 62 ГОСТ 28907-91

Продолжение табл. 7

ГОСТ 28907-91 С. 63

Продолж ение табл. 7

С. 64 ГОСТ 28907-91

Продолжение табл. 7

ГОСТ 28907-91 С. 65

Продолж ение табл. 7

С. 66 ГОСТ 28907-91

Продолжение табл. 7

ГОСТ 28907-91 С. 67

Продолж ение табл. 7

С. 68 ГОСТ 28907-91

Продолжение табл. 7

ГОСТ 28907-91 С. 69

Продолж ение табл. 7

С. 70 ГОСТ 28907-91

Продолжение табл. 7

ГОСТ 28907-91 С. 71

Продолж ение табл. 7

С. 72 ГОСТ 28907-91

Продолжение табл. 7

ГОСТ 28907-91 С. 73

Продолж ение табл. 7

С. 74 ГОСТ 28907-91

Продолжение табл. 7

ГОСТ 28907-91 С. 75

Продолж ение табл. 7

С. 76 ГОСТ 28907-91

Продолжение табл. 7

ГОСТ 28907-91 С. 77

Продолж ение табл. 7

С. 78 ГОСТ 28907-91

Продолжение табл. 7

ГОСТ 28907-91 С. 79

Продолж ение табл. 7

ПРИЛОЖЕНИЕ /

Обязательное

СОКРАЩЕНИЯ. ПРИМЕНЯЕМЫЕ В НАСТОЯЩЕМ СТАНДАРТЕ

АО — адрес отправителя.

SA — Source Address.

АП — адрес получателя.

DA — Destination Address.

ВОС — взаимосвязь открытых систем.

OS) — Open Systems Interconnection.

ГПР — готов к приему.

RR — Receive Ready.

ДА — подтверждение.

АСК — AC Knowledge.

3 - биг «запрос*.

Р - Poll.

3/П — бит «запрос/последянй».

P/F - Poll/FinaL

ЗД — звено данных.

DL — Data Link.

С. 80 ГОСТ 28907-91

И — информация.

I — Information.

ИДС — идентификация станции.

ХЮ —Exchange Identification.

К — команда.

С — Command.

К/О — команза/отш.

C/R — Command/Rcsponse.

КПК — контрольная последовательность кадра.

FCS — Frame Check Sequence.

ЛВС— локальная вычислительная сеть.

LAN — Local Area Network.

M — бит «модификатор».

М — Modifier function bit.

НГПР — нс готов к приему.

RNR — Receive Not Ready.

НИ — ненумерованная информация.

UI — Unnumbered Information.

НКО — ненумерованные команды и ответы.

U — Unnumbered formal.

НП — ненумерованное подтверждение.

UА — Unnumbered Acknowledgment.

Нпд - номер передачи кадра.

N (S) — Scad sequence Number.

Нпм — номер приема кадра.

N (R) — Receive sequence Number.

НПР — неприем.

REJ - REJect.

НПРК — неприем кадра.

FRMR — FRaMe Reject.

О — ответ.

R — Response.

ООД — оконечное оборудование данных.

DTE — Data Terminal Equipment.

АКД — аппаратура окончания канала данных.

DCE — Data Circuit-terminating Equipment.

П — бит «последний».

F - Final.

ПБД — протокольный блок данных.

PDU — Protocol Data Uait.

ПД — переменная передачи.

V (S) — Send state Variable.

ПДУ — пункт доступа к услугам.

SAP — Service Access Point.

ПДУЗ — пункт доступа к услугам звена.

LSAP — Link layer Service Access Point.

ПДУО — пункт доступа к услугам отправителя.

SSAP — Source Service Access Point.

ПДУП — пункт доступа к услугам получателя.

DSAP — Destination Service Access Point.

ПМ — переменная приема.

V (R) — Receive state Variable.

PAP — режим асинхронного разъединения.

ADM — Asynchronous Disconnected Mode.

PAC — режим асинхронный сбалансированный.

ABM - Asynchronous Balanced Mode.

РЗД — разъединение.

DISC — Disconnect.

СБД — сервисный блок данных.

SDU — Service Data Unit.

СБДЗ — сервисный блок данных звена.

ГОСТ 28907-91 С. 81

LSDU — Link Layer Service Data Unil.

ТЕСТ — тест (проверка).

TEST - TEST.

У — биг «управление».

S — Supervisory function bit.

УДС — управление доступом к среде.

MAC — Medium Access Control.

УКО — управляющие команды и ответы.

S - Supervisory format.

УЛЗ - управление логическим звеном.

LLC — Logical Link Control.

УРРАС — установить расширенный режим асинхронный сбалансированный.

SABME — Set Asynchronous Balanced Mode Extended.

ФРЗД — фата разьединения.

DM — Disconnected Mode.

ПРИЛОЖЕНИЕ 2

Справочное

МЕТОДЫ УПРАВЛЕНИЯ ПОТОКОМ ДЛЯ ОБЪЕДИНЕННЫХ МОСТАМИ ЛОКАЛЬНЫХ

В Ы ЧИСЛ ИТЕЛ ЬН ЫХ СЕТЕЙ

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

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

Ниже описан методы, называемый «управление потоком путем динамического изменения окна», который позволяет управлять доставкой кадров на сетевой уровень из логического объекта УЛЗ в случае обнаружения или предлагаемого появления перегрузки. Метол наиболее аффективен в ЛВС. объединенных с помошью мостов УДС. Он предназначен для устранения, а нс для предотвращения перегрузок в объединенной ЛВС. Он не предназначен для полноценного регулирования загрузкой сети.

Данный метол манипулирует окном передачи, определенным настоящим стандартом, с целью регулирования потока между двумя УЛЗ путем использования услуг в-рсжиме-с-установленисм-сосдинсния. Перегрузка в одном направлении соединения логического звена обрабатывается независимо от перегрузки в другом направлении. Метод нс требует связи с мостами, а основан на простом алгоритме, реализуемом на подуровне УЛЗ. Протокол УДС при атом нс затрагивается.

Все действия, описываемые в настоящем приложении, выполняются станцией, передающей информацию в перегруженном направлении. Приемная станция нс участвует в этих действиях, она выполняет только нормальные процедуры УЛЗ и нс требует сведений о действиях передающей стороны. Интерфейс услуг между уровнем звена данных и сетевым уровнем остается неизменным.

2. Определение

К — текущий размер окна передачи.

Eliane ^— максимальный размер окна передачи, т. с. максимальное значение К. Значение А’_маК1. нс должно превышать 12?.

Ацш — число последовательно переданных, успешно принятых и подтвержденных ПБД формата И. достаточное для того, чтобы увеличить К.

3. Окно передачи

Алгоритм динамического окна состоит в изменении окна передачи на передающей стороне при первоначальном обнаружении перегрузки и последующих уменьшениях перегрузки. Если передающая сторона всегда использует размер окна передачи К-1, то этот алгоритм нс используется. Если передающая сторона использует большие размеры окна передачи, то в отсутствие перегрузки используется размер окна передачи К. равный максимально возможному значению A'_MUW. Таким образом, передающая сторона может иметь до К_мйкс

С. 82 ГОСТ 28907-91

неподтвержденных ПБД И в любой момент времени. Значение А_1МЫ устанавливается меньшим или равным окну приема передатчика ИДС, а К первоначально устанавливается равным значению А_и,_кс.

4. Обнаружение перегрузки

О наличии перегрузки указывает потеря ПБД формата И. (Предполагается, что потеря ПБД из-за случайных ошибок в бигах — маловероятна». Потеря ПБД формата И обнаруживается передающей стороной одним из двух способов:

I. Передающая сторона принимает ПБД ИПР. который указывает, что приемная сторона обнаружила потерю ПБД формата И.

2. В результате следующей последовательности событий:

а> истек тайм-аут подтверждения па передающей стороне:

6) передающая сторона передаст командный ПБД ГПР с битом 3. равным I;

в) передающая сторона приняла ПБД И или ПБД УКО. в котором биг П равен 1, а значение порядкового номера приема Нпм нс равно значению переменной передачи ПД па передающей стороне на момент передачи ею ПБД с битом 3. равным I.

5. Операции алгоритма

При обнаружении перегрузки одним из двух способов вступает в действие алгоритм динамического окна. При этом передающая сторона устанавливает размер своего окна передачи А' равным I. Таким образом, передающая сторона после передачи каждого ПБД И ждет подтверждения.

После этого, если определенное число А'_Ш,_1Г неподтвержденных перед этим блоков ПБД И успешно переданы и подтверждены, значение А' увеличивается на I. А'_и,.„ может быть постоянной или переменной величиной. Олин из методов изменения A_UUf — полагать его равным К. Чем больше значение A'_UUI. тем длительнее задержка управления потоком.

По мерс успешной передачи ПБД И значение К будет увеличиваться, пока нс достигнет своего максимального значения A_1U(l... После этого алгоритм заканчивает работу. Если другие ПБД И будут потеряны до тою. как К достигнет значения K,_|11W. или после того, то алгоритм начнет работу сначала, установив К равных! 1.

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

I. ПОДГОТОВЛЕН И ВНЕСЕН МИНИСТЕРСТВОМ РАДИОПРОМЫШЛЕННОСТИ СССР

РАЗРАБОТЧИКИ

В.М. Богданов, канд. техн, наук: В.К. Щербо. канд. техн, наук; В.М. Киреичев;

К).С. Объедков

2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по управлению качеством продукции и стандартам от 30.01.91 № 79.

Настоящий стандарт подготовлен методом прямого применения международного стандарта ИСО 8802-2—89 «Системы обработки информации. Локальные вычислительные сети. Протокол и услуги уровня управления логическим звеном данных» и полностью ему соответствует

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

4. ПЕРЕИЗДАНИЕ. Июнь 2005 г.

ГОСТ 28907-91 С. 83

СОДЕРЖАНИЕ

I. ВВЕДЕНИЕ.................................................................I

1.1. Назначение и область применения.............................................I

1.2. Совместимость стандартов....................................................2

1.3. Ссылки.................................................................3

1.4. Сокращения и пояснения....................................................3

1.4.1. Сокращения.........................................................3

1.4.2. Пояснения..........................................................3

2. СПЕЦИФИКАЦИЯ УСЛУГ ПОДУРОВНЯ УЛЗ.......................................4

2.1. Спецификация услуг на интерфейсе между сетевым уровнем и подуровнем УЛЗ............6

2.1.1. Краткое описание взаимодействии.........................................7

2.1.1.1. Услуги в рсжимс-бсз-установлекия-сосдинсний и без подтверждений............7

2.1.1.2. Услуги рсжима-с-ус тановлснисм-соединения..............................7

2.1.2. Детальные спецификации услуг...........................................8

2.1.2.1. ЗД-БЛОК-ДАННЫХ. запрос.........................................8

2.1.2.2. ЗД-БЛОК-ДАННЫХ. индикация......................................9

2.1.2.3. ЗД-СОЕДИНЕНИЕ. запрос..........................................9

2.1.2.4. ЗД-СОЕДИНЕНИЕ. индикация.......................................9

2.1.2.5. ЗД-СОЕДИНЕНИЕ. ответ..........................................10

2.1.2.6. ЗД-СОЕДИНЕНИЕ. подтверждение...................................10

2.1.2.7. ЗД-ДАННЫЕ. запрос..............................................11

2.1.2.8. ЗД-ДАННЫЕ. индикация..........................................11

2.1.2.9. ЗД-РАЗЪЕДИНЕНИЕ. запрос.......................................11

2.1.2.10. ЗД-РАЗЪЕДИНЕНИЕ. индикация...................................12

2.1.2.11. ЗД-СБРОС. запрос. . .............................................12

2.1.2.12. ЗД-СБРОС. индикация...........................................13

2.1.2.13. ЗД-СБРОС. ответ................................................13

2.1.2.14. ЗД-СБРОС. подтверждение........................................14

2.1.2.15. ЗД-СОЕДИНЕНИЕ-УПРАВЛЕНИЕ-ПОТОКОМ. запрос...................14

2.1.2.16. ЗД-СОЕЛИНЕНИЕ-УПРАВЛЕНИЕ-ПОТОКОМ. индикация................14

2.2. Спецификация услуг на интерфейсе подуровень УЛЗ — подуровень УДС.................15

2.2.1. Перечень взаимодействий..............................................15

2.2.2. Подробная спецификация услуг..........................................15

2.2.2.1. УДС-БЛОК-ДАННЫХ.запрос........................................15

2.2.2.2. УДС-БЛОК-ДАННЫХ. индикация....................................16

2.2.2.3. УДС-БЛОК-ДАННЫХ-СОСТОЯНИЕ. индикация.........................17

2.3. Спецификация услуг на интерфейсе подуровень УЛЗ — управляющая функция подуровня УЛЗ. 17

3. СТРУКТУРА ПРОТОКОЛЬНОГО БЛОКА ДАННЫХ УЛЗ

3.1. Общие положения.........................................................17

3.2. Формат ПБД УЛЗ.........................................................17

3.3. Элементы ПБД УЛЗ.......................................................18

3.3.1. Поля адреса........................................................18

3.3.1.1. Представление поля адреса..............;...........................18

3.3.1.2. Использование адреса.............................................19

3.3.2. Поле управления.....................................................19

3.3.3. Поле информации....................................................19

3.3.4. Порядок передачи бигов...............................................19

3.3.5. Недействительные ПБД УЛЗ............................................20

4. ТИПЫ И КЛАССЫ ПРОЦЕДУР УЛЗ..............................................20

4.1. Общие положения.........................................................20

4.2. Классы УЛЗ (аттестационный раздел)...........................................20

С. «4 ГОСТ 28907-91

4.2.1. УЛЗ класса 1........................................................21

4.2.2. УЛЗ класса II.......................................................21

5. ЭЛЕМЕНТЫ ПРОЦЕДУР УЛЗ...................................................22

5.1. Общие положения.........................................................22

5.2. Форматы поля управления...................................................22

5.2.1. Формат передачи информации — И.......................................22

5.2.2. Формат управляющих команд и ответов — УКО..............................22

5.2.3. Формат ненумерованных команд и ответов — НКО............................23

5.3. Параметры поля управления.................................................23

5.3.1. Параметры операций типа I............................................23

5.3.2. Параметры операций типа 2............................................23

5.3.2.1. Модули.....................................................23

5.3.2.2. Переменные и порядковые номера ПБД УЛЗ..........................23

5.3.2.3. Бит «запрос/послсдний» — 3/П....................................24

5.4. Команды и ответы........................................................24

5.4.1. Команда и ответы операций типа 1.......................................24

5.4.1.1. Команды операций типа 1........................................25

5.4.1.2. Ответы операций типа I.........................................26

5.4.2. Команды и ответы операций типа 2......................................27

5.4.2.1. Команда и ответ формата «передача информации»......................27

5.4.2.2. Управляющие команды и ответы...................................27

5.4.2.3. Ненумерованные команды и ответы.................................28

6. ОПИСАНИЕ ПРОЦЕДУР УЛЗ ТИПА I............................................31

6.1 Режимы работы..........................................................31

6.2. Процедуры адресации.................. 3)

6.3. Процедуры использования бита 3/П...........................................31

6.4. Процедуры установления и разьединения логического звена данных....................32

6.5. Процедуры передачи информации.............................................32

6.5.1. Передача ПБД НИ...................................................32

6.5.2. Прием ПБД НИ.....................................................32

6.6. Использование командного и ответного ПБД ИДС................................32

6.7. Использование командного и ответного ПБД ТЕСТ................................32

6.8. Слисок параметров логического звена данных....................................33

6.8.1. Максимальное число октетов в ПБД НИ...................................33

6.8.2. Минимальное число октетов в ПБД......................................33

6.9. Точное описание процедур типа 1.............................................33

6.9.1. Точная спецификация УЛЗ.............................................33

6.9.2. Описание компонента СТАНЦИЯ........................................35

6.9.2.1. Описание состояний компонента СТАНЦИЯ..........................37

6.9.2.2. Описание событий компонента СТАНЦИЯ...........................37

6.9.2.3. Описание действий компонента СТАНЦИЯ...........................38

6.9.3. Описание компонента ПДУ............................................38

6.9.3.1. Описание состояний компонента ПДУ..............................38

6.9.3.2. Описание событий компонента ПДУ................................38

6.9.3.3. Описание действий компонента ПДУ...............................40

7. ОПИСАНИЕ ПРОЦЕДУР УЛЗ ТИПА 2............................................40

7.1. Режимы................................................................40

7.1.1. Рабочий режим.....................................................40

7.1.2. Нерабочий режим....................................................40

7.2. Процедуры адресации.......... 41

7.3. Процедуры использования бита 3/П...........................................41

7.4. Процедуры установления и разьединения звена данных.............................41

7.4.1. Фаза соединения звена данных..........................................41

ГОСТ 28907-91 С. 85

7.4.2. Фаза передачи информации............................................42

7.4.3. Фаза разъединения звена данных........................................42

7.4.4. Фаза разъединенного звена данных.......................................42

7.4.5. Столкновение ненумерованных командных ПБД установления режима.............43

7.5. Процедуры передачи информации............................................43

7.5.1. Передача ПБД И....................................................43

7.5.2. Прием ПБД И......................................................43

7.5.3. Прием неправильных ПБД.............................................44

7.5.4. Прием ПБД с нарушением порядка следования..............................44

7.5.5. Подтверждение приема................................................44

7.5.6. Прием ПБД НПР....................................................44

7.5.7. Прием ПБД НГПР...................................................44

7.5.Х. Состояние занятости УЛЗ..............................................44

7.5.9. Ожидание подтверждения..............................................45

7.6. Процедуры сброса........................................................45

7.7. Особые условия НПРк....................................................46

7.S. Список параметров соединения звена данных....................................46

7.8.1. Функции тайм-аута..................................................46

7.8.1.1. Тайм-аут подтверждения........................................47

7.8.1.2. Тайм-аут бита 3...............................................47

7.8.1.3. Тайм-аут «неприсм»............................................47

7.8.1.4. Тайм-аут «занято».............................................47

7.8.2. Максимальное число передач — N2........... 47

7.8.3. Максимальное число октетов в ПБД И —Nt.................................47

7.8.4. Максимальное число неподтвержденных ПБД И —к...........................47

7.8.5. Минимальное число октетов в ПБД......................................47

7.9. Точное описание процедур типа 2............................................47

7.9.1. Описание компонента СОЕДИНЕНИЕ....................................47

7.9.1.1. Описание состояний компонента СОЕДИНЕНИЕ......................49

7.9.1.2. Описание событий компонента СОЕДИНЕНИЕ........................50

7.9.1.3. Описание действий компонента СОЕДИНЕНИЕ.......................52

ПРИЛОЖЕНИЕ 1. СОКРАЩЕНИЯ. ПРИМЕНЯЕМЫЕ В НАСТОЯЩЕМ СТАНДАРТЕ..........79

ПРИЛОЖЕНИЕ 2. МЕТОДЫ УПРАВЛЕНИЯ ПОТОКОМ ДЛЯ ОБЪЕДИНЕННЫХ МОСТАМИ

ЛОКАЛЬНЫХ ВЫЧИСЛИТЕЛЬНЫХ СЕТЕЙ...........................81

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

Редактор в.//. Кенисов Технический редактор О.Н. Власова Корректор М И. Першина Компьютерная верстка Г.Н. Мартемьяновой

Сдано и набор 11.04.2005. Подписано в печать 2 1.06.2005. Формат 60x84 'Д. Бумага офсетная.

Гарнитура Таймс. Печать офсетная. Усл. печ. л. 9.77. Уч.иаа. л. 9.90. Тираж 72 акт. Зак. 387 С 1422.

ФГУП «*. 123995 Москва. Гранатный пер.. 4.

www.poxlinfo.nl in foOpoxI i л Голи

Набрано во ФГУП -Стандартииформ*

Отпечатано в филиале ФГУП •Стаидартинформ* — тип. -Московский печатник*. 105062 Москва. Лялин лер., 6.