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

ГОСТ 28696-90

(ИСО 8886-90)

СИСТЕМЫ ОБРАБОТКИ ИНФОРМАЦИИ.
ПЕРЕДАЧА ДАННЫХ

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

 

 

 

Москва

Стандартинформ

2005

 

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

Дата введения 01.07.91

Настоящий стандарт эквивалентен стандарту Международной организации по стандартизации ИСО 8886-88 «Системы обработки информации. Передача данных. Определение услуг звена данных для взаимосвязи открытых систем» с учетом следующих уточнений:

- разд. 0 «Введение» заменен настоящей вводной частью;

- в начале разд. 1 «Назначение и область применения» введены два новых абзаца, уточняющих область применения настоящего стандарта;

- в разд. 2 «Ссылки» дополнительно включены два стандарта;

- исключены ссылки на стандарты ИСО 7498 и 7498/Доп I;

- ссылка на ИСО/ТО 8509 заменена приложением 1;

- содержимое разд. 3 «Определения» вынесено в приложение 2 с добавлением определений всех перечисленных в нем терминов на основе приводимых стандартов ИСО;

- разд. 4 «Аббревиатуры» дополнен аббревиатурами, используемыми в настоящем стандарте;

- из разд. 17 «Качество услуг в режиме-без-установления-соединения» исключена информация (подразделы, абзацы, чертежи), полностью дублирующая соответствующую информацию разд. 10 «Качество услуг режима-с-установлением-соединения», с введением соответствующих ссылок на разд. 10.

1. НАЗНАЧЕНИЕ И ОБЛАСТЬ ПРИМЕНЕНИЯ

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

Протоколы уровня звена данных определены в ГОСТ 28079 и в ГОСТ 28080.

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

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

Взаимосвязь настоящего стандарта с другими стандартами ВОС

Черт. 1

Настоящий стандарт определяет услуги уровня звена данных ВОС в понятиях:

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

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

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

Основная цель настоящего стандарта - определить характеристики концептуальных услуг уровня звена данных и тем самым дополнить базовую эталонную модель руководством по разработке протоколов уровня звена данных.

Настоящий стандарт не определяет конкретных реализаций или изделий и не налагает никаких ограничений на реализацию логических объектов звена данных и интерфейсов системы обработки информации.

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

2. ССЫЛКИ

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

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

Часть 1. ОБЩИЕ ПОЛОЖЕНИЯ

3. ОПРЕДЕЛЕНИЯ

Основные термины, используемые в стандарте, приведены в приложении 2.

4. АББРЕВИАТУРЫ

ЗД - звено данных;

ВОС - взаимосвязь открытых систем;

КНО - коэффициент необнаруженных ошибок;

КУ - качество услуг;

СБДЗД - сервисный-блок-данных-звена-данных;

СЗД - соединение-звена-данных;

ПДУЗД - пункт-доступа-к-услугам-звена-данных;

ТО - технический отчет;

УЗД - уровень звена данных;

УУЗД - услуги уровня звена данных.

5. СОГЛАШЕНИЯ

5.1. Общие соглашения

Настоящий стандарт использует соглашения, приведенные в приложении 1.

Описываемые ниже модель услуг, сервисные примитивы и временные диаграммы - это полностью абстрактные описания, которые не являются спецификацией для реализации.

5.2. Параметры

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

Параметры, применяемые для каждой группы примитивов, приведены в табл. 5, 6, 7 и 8. Знак «X» в этих таблицах указывает, что соответствующий примитив может переносить указанный в строке параметр.

Некоторые элементы таблицы уточняются элементами в скобках. К ним относятся:

а) конкретное ограничение параметра:

(=) указывает, что значение параметра в примитиве индикации или подтверждения всегда идентично значению, указанному предыдущим примитивом запроса или ответа, выданным на противоположной точке-доступа-к-услугам;

б) указание на примечание:

(прим. X) указывает, что соответствующее примечание содержит дополнительную информацию, относящуюся к данному параметру и его использованию.

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

6. ОБЗОР УСЛУГ ЗВЕНА ДАННЫХ

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

В частности, УУЗД обеспечивают следующие возможности:

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

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

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

Примечание. Обнаружение дублированных или потерянных СБДЗД могут выполнять пользователи УУЗД.

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

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

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

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

Настоящий стандарт не определяет никаких различимых классов услуг уровня звена данных.

Имеются два типа УУЗД:

а) услуги режима-с-установлением-соединения (определены в ч. 2);

б) услуги режима-без-установления-соединения (определены в ч. 3).

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

Часть 2. ОПРЕДЕЛЕНИЕ ПРИМИТИВОВ В РЕЖИМЕ-С-УСТАНОВЛЕНИЕМ-СОЕДИНЕНИЯ

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

Услуги УЗД обеспечивают их пользователю следующие возможности:

а) средства для установления СЗД с другим пользователем УУЗД с целью обмена СБДЗД;

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

в) средства передачи СБДЗД ограниченной длины по СЗД. Передача СБДЗД «прозрачна» в том смысле, что УУЗД сохраняют неизменными границы и содержимое СБДЗД и не накладывают никаких ограничений на их содержимое.

Примечание. Длина СБДЗД может быть ограничена внутренними механизмами протокола звена данных;

г) средства, с помощью которых принимающий пользователь УУЗД может, управляя потоком, регулировать скорость, с которой передающий пользователь УУЗД может выдавать СБДЗД;

д) средства возврата СЗД в определенное состояние и синхронизации деятельности двух пользователей УУЗД посредством услуги «сброс»;

е) безусловное и потому, возможно, разрушающее разъединение СЗД пользователями УУЗД либо поставщиком УУЗД.

9. МОДЕЛЬ УСЛУГ УРОВНЯ ЗВЕНА ДАННЫХ В РЕЖИМЕ-С-УСТАНОВЛЕНИЕМ СОЕДИНЕНИЯ

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

9.1. Идентификация оконечной точки СЗД

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

9.2. Модель соединения-звена-данных

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

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

Примечание. Внутренние механизмы, поддерживающие выполнение УУЗД, невидимы для пользователя УУЗД. Помимо описываемых данной моделью взаимодействий между сервисными примитивами (например выдача в ПДУЗД примитива ЗД-СБРОС. запрос может помешать равноуровневому пользователю УУЗД принять примитив ЗД-ДАННЫЕ. индикация, соответствующий ранее выданному примитиву ЗД-ДАННЫЕ. запрос) могут иметь место также:

а) местные ограничения на возможность использования примитивов;

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

Модель СЗД в виде очередей

Черт. 2

9.2.1. Концепции модели в виде очередей

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

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

Для каждого потенциального СЗД будет доступна пара очередей.

Пользователь УУЗД может помещать в очередь следующие объекты (разд. 12 - 14):

а) объект соединения, представляющий примитив ЗД-СОЕДИНЕНИЕ и его параметры;

б) объект данных, представляющий примитив ЗД-ДАННЫЕ и его параметры;

в) объект сброса, представляющий примитив ЗД-СБРОС и его параметры;

г) объект разъединения, представляющий примитив ЗД-РАЗЪЕДИНЕНИЕ и его параметры.

Поставщик УУЗД может ввести в очередь следующие объекты (разд. 12 - 14):

1) объект сброса, представляющий примитив ЗД-СБРОС и его параметры;

2) объект метки синхронизации (п. 9.2.4);

3) объект разъединения, представляющий примитив ЗД-РАЗЪЕДИНЕНИЕ и его параметры.

Определенные таким образом очереди должны иметь следующие общие свойства:

1) очередь пуста до ввода в нее объекта соединения и может быть возвращена в это состояние поставщиком УУЗД с потерей ее содержимого;

2) объекты вводятся в очередь передающим пользователем УУЗД под управлением поставщика УУЗД; объекты могут также вводиться поставщиком УУЗД;

3) объекты изымаются из очереди под управлением принимающего пользователя УУЗД;

4) объекты обычно удаляются из очереди в той же последовательности, в которой они вводились в нее (см. п. 9.2.3);

5) очередь имеет ограниченную емкость, но эта емкость не обязательно должна быть фиксированной или детерминированной.

9.2.2. Установление СЗД

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

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

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

9.2.3. Передача данных

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

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

Взаимоотношения между объектами, которыми можно манипулировать вышеизложенным способом, сведены в табл. 1.

Таблица 1

Взаимоотношения между объектами модели-очереди СЗД

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

Н/П-X не будет предшествовать Y при правильном состоянии очереди;

- - не разрушающий и не способный продвигаться далее;

РАЗР - разрушающий по отношению к предшествующему объекту.

9.2.4. Сброс

Чтобы точно смоделировать услуги сброса, необходим объект «метка синхронизации», который обладает следующими свойствами:

а) он не может быть удален из очереди пользователем УУЗД;

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

в) объект «метка синхронизации» может быть разрушен объектом разъединения (см. табл. 1);

г) если перед объектом сброса следует непосредственно объект «метка синхронизации», то оба эти объекта удаляются из очереди.

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

1) инициация процедуры сброса поставщиком УУЗД представляется введением в каждую очередь объекта сброса, за которым следует объект «метка синхронизации»;

2) процедура сброса, инициированная пользователем УУЗД, представляется как ввод поставщиком УУЗД объекта сброса в очередь от инициатора сброса к (равноуровневому) пользователю УУЗД и ввод объекта сброса с последующим объектом «метка синхронизации» в другую очередь.

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

Примечание. С инициацией процедуры сброса связаны ограничения, налагаемые на выдачу примитивов некоторых других типов. Эти ограничения приводят к ограничениям, налагаемым на ввод в очередь объектов определенного типа выполнения процедуры сброса (п. 14.2.3).

9.2.5. Разъединение СЗД

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

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

10. КАЧЕСТВО УСЛУГ В РЕЖИМЕ-С-УСТАНОВЛЕНИЕМ-СОЕДИНЕНИЯ

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

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

10.1. Определение КУ для режима-с-установлением-соединения

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

Все параметры КУ в зависимости от способа определения их значений могут быть подразделены на следующие два типа:

а) параметры КУ, которые могут быть согласованы для каждого соединения в фазе установления СЗД;

б) параметры КУ, которые не согласовываются во время установления СЗД, но их значения выбираются и/или известны из других источников.

Имеются три параметра КУ: пропускная способность, транзитная задержка и приоритет (определены в пп. 10.2.1, 10.2.2 и 10.2.6), согласуемые во время установления СЗД. Процедуры согласования этих параметров подробно описаны в п. 12.2.5. После того как СЗД установлено и в течение всего времени существования СЗД согласованные значения КУ никогда не пересогласовываются, причем сохранность первоначально согласованных значений КУ не гарантируется. Пользователи УУЗД должны также иметь в виду, что поставщик УУЗД не сообщает в явном виде об изменениях КУ данного СЗД.

Остальные характеристики КУ, которые идентифицируются как параметры, но которые не согласовываются во время установления СЗД определяются в пп. 10.2.3 - 10.2.5. Значения этих параметров для конкретного СЗД определяются другими методами (например средствами диспетчера либо на основе априорных сведений и соглашений).

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

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

10.2. Определение параметров КУ

Параметры КУ можно классифицировать следующим образом:

а) параметры, отражающие рабочие характеристики УУЗД в соответствии с табл. 2;

б) параметры, отражающие другие характеристики УУЗД в соответствии с табл. 3.

Таблица 2

Классификация параметров КУ, отражающих рабочие характеристики УУЗД

Таблица 3

Параметры КУ, не связанные с рабочими характеристиками УУЗД

Примечание. Некоторые параметры КУ определены в понятиях выдачи примитивов УУЗД. Ссылка на примитив УУЗД подразумевает полное выполнение этого примитива УУЗД в соответствующем ПДУЗД.

10.2.1. Пропускная способность

Пропускная способность определяется общим числом битов СБДЗД, успешно переданных последовательностью примитивов ЗД-ДАННЫЕ. запрос, ЗД-ДАННЫЕ. индикация, деленных на время ввода/вывода этой последовательности.

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

Время ввода/вывода для последовательности примитивов ЗД-ДАННЫЕ. запрос и ЗД-ДАННЫЕ. индикация более чем вдвое превышает следующие времена:

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

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

Пропускная способность имеет смысл только в отношении последовательности полностью переданных СБДЗД.

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

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

10.2.2. Транзитная задержка

Транзитная задержка - это время, прошедшее между выполнением примитива ЗД-ДАННЫЕ. запрос и соответствующего ему примитива ЗД-ДАННЫЕ. индикация. Это время отсчитывают только для успешно переданных СБДЗД.

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

При передаче в режиме-с-установлением-соединения транзитная задержка определяется независимо для каждого направления передачи. Каждая спецификация должна основываться на заранее установленном среднем размере СБДЗД.

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

10.2.3. Коэффициент необнаруженных ошибок

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

10.2.4 Устойчивость

Данный параметр определяет вероятность того, что в течение определенного периода времени в установленном СЗД:

а) поставщик УУЗД инициирует разъединение СЗД (т. е. выдает примитив ЗД-РАЗЪЕДИНЕНИЕ. индикация, не получив предварительно примитива ЗД-РАЗЪЕДИНЕНИЕ. запрос) или

б) поставщик УУЗД инициирует сброс (т. е. выдает примитив ЗД-СБРОС. индикация, не получив предварительно примитива ЗД-СБРОС. запрос).

10.2.5 Защита

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

а) возможность защиты отсутствует;

б) защита от пассивного наблюдения (прослушивания);

в) защита от изменений, выдачи ответа, добавлений или вычеркиваний.

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

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

10.2.6. Приоритет

Спецификация приоритета касается вопроса взаимоотношений между СЗД.

Параметр «приоритет» определяет относительную важность СЗД в части:

а) порядка, в котором СЗД должны при необходимости понижать свое КУ;

б) порядка, в котором СЗД при необходимости подлежат разъединению для восстановления ресурсов.

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

Параметр «приоритет» имеет смысл только в контексте некоторых управляющих логических объектов или структур, способных оценивать относительную важность. Число приоритетных уровней ограничено.

11. ПОСЛЕДОВАТЕЛЬНОСТИ ПРИМИТИВОВ

11.1. Концепции, используемые для определения услуг звена данных в режиме-с-установлением-соединения

При определении услуги используются следующие концепции:

а) СЗД может динамически устанавливаться или завершаться между пользователями УУЗД с целью обмена данными;

Компоненты коэффициента необнаруженных ошибок

Черт. 3

б) с каждым СЗД при его установлении связаны определенные показатели КУ, согласуемые между поставщиком УУЗД и пользователями УУЗД;

в) СЗД обеспечивает возможность передачи данных и их разделения на СБДЗД; передача этих данных регулируется управлением по потоку;

г) СЗД может быть возвращено в определенное состояние, и действия двух пользователей УУЗД синхронизируются путем использования услуги сброса;

д) пользователь УУЗД может быть проинформирован о сбоях в обеспечении запрошенных услуг. Имеются три класса сбоев:

(1) сбои, вызывающие завершение СЗД;

(2) сбои, приводящие к потере или дублированию данных пользователя, но без потери СЗД;

(3) сбои, приводящие к понижению запрошенного КУ без потери или дублирования данных пользователя и без потери СЗД.

11.2. Ограничения, налагаемые на последовательности примитивов

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

Примитивы режима с установлением соединения и их параметры приведены в табл. 4.

Таблица 4

Перечень примитивов и параметров услуг звена данных для режима-с-установлением-соединения-звена-данных

11.2.1. Взаимоотношения примитивов в двух оконечных точках СЗД

Примитив, выданный в одной оконечной точке СЗД, в общем случае вызовет некоторые последствия в другой оконечной точке СЗД. Отношения примитивов каждого типа в одной оконечной точке СЗД к примитивам в другой оконечной точке СЗД определены в разд. 12 - 14; все эти отношения представлены диаграммами на черт. 4.

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

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

Черт. 4

11.2.2. Последовательность примитивов в одной оконечной точке СЗД

Все возможные последовательности примитивов в одной оконечной точке СЗД определены диаграммой переходов состояний на черт. 5:

Диаграмма переходов состояний для последовательностей примитивов в оконечной точке СЗД

Черт. 5

а) ЗД-РАЗЪЕДИНЕНИЕ во всех случаях означает примитив типа запрос или индикация;

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

в) холостое состояние отражает отсутствие СЗД. Она является начальным и конечным состоянием любой последовательности и как только оно вводится, СЗД разъединяется;

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

12. ФАЗА УСТАНОВЛЕНИЯ СОЕДИНЕНИЯ

12.1. Функция

Для установления СЗД могут использоваться сервисные примитивы установления СЗД. Одновременно выдаваемые в двух ПДУЗД примитивы ЗД-СОЕДИНЕНИЕ. запрос приводят к установлению одного СЗД, как показано на черт. 6.

Установление СЗД

а) Инициировано одним пользователем УУЗД

б) Инициировано одновременно обоими пользователями УУЗД

Черт. 6

12.2. Типы примитивов и параметры

Типы примитивов и параметры, необходимые для установления СЗД, приведены в табл. 5.

Таблица 5

Примитивы и параметры установления СЗД

Примечания:

1. Необходимость параметра изучается.

2. Данный параметр может быть неявно связан с тем ПДУЗД, в котором выдан этот примитив.

12.2.1. Адреса

Параметры, значениями которых являются адреса (пп. 12.2.2 - 12.2.4), называются адресами ПДУЗД.

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

12.2.2. Адрес вызываемого

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

12.2.3. Адрес вызывающего

Параметр «адрес вызывающего» передает адрес того ПДУЗД, из которого было запрошено СЗД.

12.2.4. Адрес отвечающего

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

12.2.5. Набор параметров «качество услуг»

Если поставщик УУЗД предоставляет только один уровень КУ, то процедура выбора параметров КУ не требуется.

12.2.5.1. Пропускная способность

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

12.2.5.2. Выбранная защита

Этот параметр определяет конкретную степень защиты в пределах согласованного диапазона (п. 10.2.5) для СБДЗ любого последующего примитива ЗД-ДАННЫЕ. запрос, переданного по данному СЗД.

12.2.5.3. Выбранный приоритет

Этот параметр определяет конкретное значение приоритета в согласованном диапазоне (п. 10.2.6) для СБДЗ любого последующего примитива ЗД-ДАННЫЕ. запрос, переданного по данному СЗД.

12.3. Последовательность примитивов

Последовательность примитивов при успешном установлении СЗД определена временной диаграммой на черт. 6.

Процедуры установления СЗД могут оказаться безуспешными либо вследствие неспособности поставщика УУЗД установить СЗД, либо вследствие нежелания вызываемого пользователя УУЗД воспринять примитив ЗД-СОЕДИНЕНИЕ. индикация (для таких случаев см. услугу разъединения СЗД, пп. 13.4 и 13.5).

13. ФАЗА РАЗЪЕДИНЕНИЯ И СОЕДИНЕНИЯ

13.1. Функция

Примитивы услуги разъединения СЗД используются для разъединения СЗД. Разъединение СЗД может быть инициировано любой из перечисленных ниже сторон:

а) одним из пользователей либо обоими пользователями УУЗД с целью разъединения установленного СЗД;

б) поставщиком УУЗД с целью разъединения установленного СЗД; все неудачи в поддержании СЗД указываются этим способом;

в) пользователем УУЗД с целью отклонения примитива ЗД-СОЕДИНЕНИЕ. индикация;

г) поставщиком УУЗД с целью информирования о своей неспособности установить запрошенное СЗД;

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

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

13.2. Типы примитивов и параметры

Типы примитивов и параметры, необходимые для разъединения СЗД, приведены в табл. 6.

Таблица 6

Примитивы и параметры разъединения СЗД

13.2.1. Инициатор

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

13.2.2. Причина

Параметр «причина» содержит информацию, указывающую причину разъединения СЗД. Значения этого параметра определяются следующим:

а) если параметр «инициатор» указывает, что разъединение инициировал поставщик УУЗД, то параметр «причина» будет иметь одно из следующих значений:

1) разъединение - устойчивые условия;

2) разъединение - неустойчивые условия;

3) отказ от соединения - адрес ТДУЗД неизвестен;

4) отказ от соединения - ТДУЗД недоступен/устойчивые условия;

5) отказ от соединения - ТДУЗД недоступен/неустойчивые условия;

б) отказ от соединения-КУ не обеспечивается/устойчивые условия;

7) отказ от соединения-КУ не обеспечивается/неустойчивые условия;

8) причина не определена.

б) если параметр «инициатор» указывает, что разъединение инициировал пользователь УУЗД, то параметр «причина» будет иметь одно из следующих значений:

1) разъединение - нормальные условия;

2) разъединение - ненормальные условия;

3) отказ от соединения - устойчивые условия;

4) отказ от соединения - неустойчивые условия;

5) причина не определена;

в) если параметр «инициатор» указывает, что инициатор неизвестен, значением параметра «причина» является «причина не определена». Это позволяет не указывать значения параметров в тех случаях, когда протокол уровня звена данных не может передать их в явном виде.

13.3. Последовательность примитивов при разъединении установленного СЗД

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

а) инициирована одним пользователем УУЗД выдачей от него примитива запроса, который вызывает выдачу примитива индикации другому пользователю;

б) инициирована обоими пользователями УУЗД выдачей примитива запроса от каждого из пользователей УУЗД;

в) инициирована поставщиком УУЗД выдачей примитива индикации каждому пользователю УУЗД;

г) инициирована независимо одним из пользователей УУЗД и поставщиком УУЗД с выдачей примитива запроса от пользователя УУЗД - инициатора и примитива индикации другому пользователю.

Последовательность примитивов для этих четырех случаев показана в виде временных диаграмм на черт. 7 - 10.

Участие пользователя УУЗД

Черт. 7

Одновременное участие обоих пользователей УУЗД

Черт. 8

Участие поставщика УУЗД

Черт. 9

Одновременное участие пользователя УУЗД и поставщика УУЗД

Черт. 10

Последовательность примитивов при отклонении пользователем УУЗД попытки установления СЗД

Черт. 11

13.4. Последовательность примитивов при отклонении пользователем УУЗД попытки установления СЗД

Пользователь УУЗД может отклонить попытку установления соединения, выдав примитив ЗД-РАЗЪЕДИНЕНИЕ. запрос. Параметр «инициатор» в примитивах ЗД-РАЗЪЕДИНЕНИЕ будет указывать пользователя УУЗД-инициатора разъединения. Последовательность событий определена в виде временной диаграммы на черт. 11.

13.5. Последовательность примитивов при отклонении поставщиком УУЗД попытки установления СЗД

Если поставщик УУЗД не в состоянии установить СЗД, то он сообщает об этом запрашивающей стороне в примитиве ЗД-РАЗЪЕДИНЕНИЕ. индикация. Параметр «инициатор» в этом примитиве указывает поставщика УУЗД - инициатора разъединения. Последовательность событий определена в виде временной диаграммы на черт. 12.

Последовательность примитивов при отклонении поставщиком УУЗД попытки установления СЗД

Черт. 12

13.6. Последовательность примитивов при прерывании пользователем УУЗД попытки установления СЗД

Если пользователь УУЗД выдал примитив ЗД-СОЕДИНЕНИЕ. запрос, и, не получив примитива ЗД-СОЕДИНЕНИЕ. подтверждение или ЗД-СОЕДИНЕНИЕ. индикация, желает прервать попытку установления СЗД, то он должен выдать примитив ЗД-РАЗЪЕДИНЕНИЕ. запрос. Результирующая последовательность примитивов зависит от относительного временного расположения выданных примитивов и от длительностей транзитных задержек поставщика УУЗД, как показано на временных диаграммах, черт. 13 - 15. Информация о том, какой из этих вариантов имел место, в явном виде не выдается.

Оба примитива взаимоуничтожаются в очереди

Черт. 13

ЗД-РАЗЪЕДИНЕНИЕ. индикация выдается до выдачи ЗД-СОЕДИНЕНИЕ. ответ

Черт. 14

ЗД-РАЗЪЕДИНЕНИЕ. индикация выдается после выдачи ЗД-СОЕДИНЕНИЕ. ответ

Черт. 15

14. ФАЗА ПЕРЕДАЧИ ДАННЫХ

14.1. Передача данных

14.1.1. Функция

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

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

14.1.2. Типы примитивов и параметр

Типы примитивов и параметр, необходимые для передачи данных, приведены в табл. 7.

Таблица 7

Примитивы и параметр передачи данных

Нормальная последовательность примитивов услуг передачи данных

Черт. 16

14.1.2.1. Данные-пользователя УУЗД

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

14.1.3. Последовательность примитивов

Операции УУЗД по передаче СБДЗД могут быть представлены в виде очереди неопределенной длины внутри поставщика УУЗД (разд. 9). Возможности пользователя УУЗД по передаче примитива ЗД-ДАННЫЕ. запрос и поставщика УУЗД по передаче примитива ЗД-ДАННЫЕ. индикация зависят от действий принимающего пользователя УУЗД и от результирующего состояния очереди.

Последовательность примитивов при успешной передаче данных определена временной диаграммой на черт. 16.

Приведенная на черт. 16 последовательность примитивов может остаться незавершенной при появлении примитива ЗД-СБРОС или ЗД-РАЗЪЕДИНЕНИЕ.

14.2. Услуга сброса

14.2.1. Функция

Услуга сброса может быть использована:

а) пользователем УУЗД с целью восстановления синхронизации СЗД;

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

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

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

14.2.2. Типы примитивов и параметры

Типы примитивов и параметры, необходимые для услуги сброса, приведены в табл. 8.

Таблица 8

Примитивы и параметры сброса

14.2.2.1. Инициатор

Параметр «инициатор» указывает источник сброса. Он может принимать значения «пользователь УУЗД», «поставщик УУЗД» или «инициатор неизвестен».

14.2.2.2. Причина

Параметр «причина» содержит информацию о причине сброса. Значение этого параметра будет определяться следующим:

а) если параметр «инициатор» указывает, что сброс инициировал поставщик УУЗД, то значениями параметра «причина» могут быть:

1) «перегрузка» из-за управления потоком звена данных,

2) «ошибка звена данных».

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

б) если параметр «инициатор» указывает, что сброс инициировал пользователь УУЗД, то параметр «причина» имеет значение «ресинхронизация пользователя»;

в) если параметр «инициатор» указывает, что инициатор неизвестен, то параметр «причина» принимает значение «причина не определена». Это позволяет не указывать значения этих параметров в тех случаях, когда они не могут быть явно переданы протоколом звена данных.

14.2.3. Последовательность примитивов

Взаимодействие между каждым пользователем УУЗД и поставщиком УУЗД должно происходить в виде обмена указанными примитивами, а именно:

а) передача пользователем УУЗД примитива ЗД-СБРОС. запрос, после которой следует передача поставщиком УУЗД примитива ЗД-СБРОС. подтверждение;

б) передача поставщиком УУЗД примитива ЗД-СБРОС. индикация, после которой следует передача пользователем УУЗД примитива ЗД-СБРОС. ответ.

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

К свойствам повторной синхронизации услуги сброса относятся следующие:

1) никакие СБДЗД, выданные пользователем УУЗД до выдачи примитива ЗД-СБРОС. запрос (или ответ) в том же передаваемом потоке, не должны доставляться другому пользователю УУЗД после соответствующего примитива ЗД-СБРОС. индикация (или подтверждение).

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

Точно так же поставщик УУЗД должен аннулировать все СБДЗД, переданные до выдачи примитива ЗД-СБРОС. ответ и еще не доставленные инициатору примитива ЗД-СБРОС. запрос, до того как поставщик УУЗД выдаст примитив ЗД-СБРОС. подтверждение;

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

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

1) одним из пользователей УУЗД, приводя к взаимодействию:

а) с этим пользователем УУЗД и

б) с равноуровневым пользователем УУЗД;

2) обоими пользователями УУЗД, приводя к взаимодействию:

а) с обоими пользователями УУЗД;

3) поставщиком УУЗД, приводя к взаимодействию:

б) с обоими пользователями УУЗД;

4) одним из пользователей УУЗД и поставщиком УУЗД, приводя к взаимодействию:

а) с инициирующим пользователем и

б) с равноуровневым пользователем УУЗД.

Последовательность примитивов для этих четырех случаев показана в виде временных диаграмм на черт. 17 - 20.

Последовательности примитивов на черт. 17 - 20 могут остаться незавершенными при появлении примитива ЗД-РАЗЪЕДИНЕНИЕ.

Последовательность примитивов услуги сброса, инициированной пользователем УУЗД

Черт. 17

Последовательность примитивов услуги сброса, одновременно инициированной пользователем УУЗД

Черт. 18

Последовательность примитивов услуги сброса, инициированной поставщиком УУЗД

Черт. 19

Последовательность примитивов услуги сброса, одновременно инициированной пользователем УУЗД и поставщиком УУЗД

Черт. 20

Часть 3. ОПРЕДЕЛЕНИЕ ПРИМИТИВОВ В РЕЖИМЕ-БЕЗ-УСТАНОВЛЕНИЯ-СОЕДИНЕНИЯ

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

Услуги УЗД обеспечивают для пользователя УУЗД следующие функциональные возможности:

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

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

16. МОДЕЛЬ УСЛУГ ЗВЕНА ДАННЫХ В РЕЖИМЕ-БЕЗ-УСТАНОВЛЕНИЯ-СОЕДИНЕНИЯ

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

16.1. Модель передачи данных на уровне-звена-данных-в-режиме-без-установления-соединения

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

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

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

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

Модель УУЗД в режиме-без-установления-соединения

Черт. 21

В общем случае поставщик УУЗД может выполнять любое из нижеперечисленных действий или все эти действия:

а) аннулирование объектов;

б) дублирование объектов и/или

в) изменение порядка следования примитивов индикаций относительно порядка поступления примитивов запросов.

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

а) объекты не должны аннулироваться;

б) объекты не должны дублироваться;

в) порядок следования примитивов индикаций должен быть такой же, как и порядок следования примитивов запросов.

Если подобная информация становится известной пользователю УУЗД до вызова услуги УЗД режима-без-установления-соединения, он может использовать такие сведения для выбора соответствующего протокола сетевого уровня.

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

17. КАЧЕСТВО УСЛУГ В РЕЖИМЕ-БЕЗ-УСТАНОВЛЕНИЯ-СОЕДИНЕНИЯ

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

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

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

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

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

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

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

17.2. Параметры КУ в режиме-без-установления-соединения

Все параметры КУ можно классифицировать следующим образом:

а) параметры, определяющие рабочие характеристики УУЗД, приведены в табл. 9;

б) параметры, отражающие другие характеристики УУЗД, приведены в табл. 3.

Таблица 9

Классификация параметров КУ, отражающих рабочие характеристики УУЗД

17.2.1. Транзитная задержка

При передаче в режиме-без-установления-соединения транзитную задержку определяют независимо для каждой отдельной передачи. В остальном параметры транзитной задержки и их расчет в этом режиме те же, что и в режиме-с-установлением-соединения (п. 10.2.2).

17.2.2. Коэффициент необнаруженных ошибок

КНО для рассматриваемого режима определяют аналогично режиму-с-установлением-соединения (п. 10.2.3).

17.2.3. Защита

Назначение параметра «защита» и возможные варианты защиты те же, что и для режима с установлением соединения (п. 10.2.5).

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

17.2.4. Приоритет

Спецификация приоритета касается взаимоотношений между привлечениями услуг передачи данных в режиме-без-установления-соединения. Этот параметр определяет относительную значимость объектов «блок данных» в вопросе использования коллективных ресурсов. Он имеет смысл только в контексте некоторых логических объектов управления или структур, способных оценить относительную значимость. Число уровней приоритета ограничено.

18. ПОСЛЕДОВАТЕЛЬНОСТЬ ПРИМИТИВОВ В ОДНОМ ПДУЗД

Все возможные разрешенные последовательности примитивов в одном ПДУЗД определены диаграммой переходов состояний на черт. 22.

Диаграмма переходов состояний для последовательностей примитивов в режиме-без-установления-соединения в одной ТДУЗД

Черт. 22

19. ПЕРЕДАЧА ДАННЫХ

19.1. Функция

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

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

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

19.2. Типы примитивов и параметры

Типы примитивов и параметры, необходимые для услуг передачи данных в режиме-без-установления-соединения, приведены в табл. 10.

Таблица 10

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

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

19.2.1. Адреса

Адреса, указанные в табл. 10, являются адресами ПДУЗД. Услуги УЗД обоих режимов: с-установлением-соединения и без-установления-соединения могут использовать одни и те же адреса ПДУЗД.

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

19.2.2 Качество услуг

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

а) в примитиве запроса разрешено любое допустимое значение;

б) в примитиве индикации указанное значение КУ меньше или равно значению КУ соответствующего примитива запроса.

Выбор параметров КУ не требуется, если поставщик УУЗД может предоставить только одну степень КУ.

19.2.3. Данные-пользователя УУЗД

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

19.3. Последовательность примитивов

Последовательность примитивов при успешной передаче в режиме-без-установления-соединения-ЗД определена временной диаграммой на черт. 23.

Последовательность примитивов при передаче в режиме-без-установления-соединения

Черт. 23

ПРИЛОЖЕНИЕ 1

Справочное

СОГЛАШЕНИЯ ПО ОПРЕДЕЛЕНИЮ УСЛУГ

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

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

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

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

3. Каждый примитив должен состоять из трех элементов: первый указывает уровень базовой эталонной модели ВОС, являющийся поставщиком данной услуги, второй указывает имя услуги и третий определяет тип услуги. Иногда вместо полного имени примитива используют сокращенное, состоящее из одного или двух последних элементов, если это не вызывает разночтений.

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

Наличие временной упорядоченности примитивов обозначается на диаграмме пунктирной линией между вертикальными линиями. Отсутствие такой линии или знак тильда (~) означает отсутствие временной упорядоченности. Например, на черт. 24 примитив запрос, выданный пользователем услуг в момент t₁, обязательно приведет к выдаче удаленному пользователю услуг примитива индикация в момент t₂. В то же время ничего нельзя сказать о порядке появления примитивов ответ и подтверждение, изображенных на черт. 24.

Пример диаграммы, изображающей последовательность сервисных примитивов

Черт. 24

ПРИЛОЖЕНИЕ 2

Справочное

ОСНОВНЫЕ ТЕРМИНЫ, ИСПОЛЬЗУЕМЫЕ В СТАНДАРТЕ, И ИХ ПОЯСНЕНИЯ

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

1. ПОДГОТОВЛЕН И ВНЕСЕН НПО «ПЕРСЕЙ»

2. УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Государственного комитета СССР по управлению качеством продукции и стандартам от 25.10.90 № 2685 настоящий стандарт подготовлен методом прямого применения международного стандарта ИСО 8886-90 «Системы обработки информации. Передача данных. Определение услуг звена данных для взаимосвязи открытых систем» и полностью ему соответствует

3. Стандарт полностью соответствует стандарту СТ СЭВ 6782-89

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

5. ПЕРЕИЗДАНИЕ. Апрель 2005 г.

СОДЕРЖАНИЕ