Часть X

10.1. Соглашение о спецификации протокольных сервисов

10.1.1 Основные понятия метода и нотации спецификации протокольных сервисов

Выше, отмечалось, что стандартизация взаимосвязи открытых систем включает три уровня описания средств информационного обмена, а именно: концептуальный уровень, содержание которого определяется моделью OSI RM, уровень спецификаций функциональных возможностей (или сервисов) элементов архитектуры OSI RM и уровень спецификаций протоколов информационного обмена между функциональными элементами эталонной модели.

Модель и способ описания сетевых сервисов играют ключевую роль в области стандартизации телекоммуникационных технологий. Более того, данная модель используется для построения модели адресации и идентификации в OSI RM. Поэтому модель и язык описания (соглашение о спецификации) сервисов можно считать составной частью модели OSI RM, хотя формально они определены в отдельном стандарте (ISO 8509 или X.210).

Модель сетевых сервисов, рассмотренная в данных документах, несмотря на свою простоту, носит фундаментальный для теории сетевых протоколов характер. Рассмотрим модель и соглашение о спецификации сервисов подробнее.

Первоначально введем ряд основополагающих определений.

(N)-сервис ((N)-service): функциональные возможности, которые могут быть предоставлены на границе между (N+1)- и (N)- уровнями.

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

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

(N)- сервисный примитив или примитив ((N)-service-primitive; primitive): абстрактное, не зависимое от реализации неделимое взаимодействие между пользователем (N)-сервиса и поставщиком (N)-сервиса, происходящее на границе между ними.

В случае, когда смысл понятия распространяется на все семь уровней эталонной модели, оно префексируется словом OSI, например, ((OSI)-service, (OSI)-service-user, (OSI)-service-provider, (OSI)-service-primitive). Однако, чтобы не усложнять рассматриваемую модель с терминологической точки зрения, мы такую нотацию в последствии использовать не будем.

В теории протоколов и в документации по сетевым протоколам сервисные примитивы, с помощью которых описываются межуровневые взаимодействия в модели OSI RM, называются также абстрактными сервисными примитивами или ASPs (Abstract Service Primitives).

Далее вводятся определения двух общих примитивов: запросить (submit) и доставить (deliver), а также двух общих типов пользователей сервиса, характеризующихся их ролевой функцией: инициатор запроса (requestor) и получатель (acceptor).

запросить (submit): сервисный примитив, инициируемый пользователем сервиса (направляемый от пользователя к поставщику сервиса).

доставить (deliver): сервисный примитив, инициируемый поставщиком сервиса (направляемый от поставщика сервиса к пользователю).

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

получатель (acceptor): пользователь, который получает (от поставщика сервиса нижележащего уровня) примитив доставить, в результате чего может выдать поставщику в качестве ответа один или несколько примитивов запросить.

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

(N)- сервисный примитив запроса ((N)-service-request-primitive): примитив, выдаваемый пользователем (N)-сервиса, т.е. инициатором запроса, (поставщику, например, для вызова некоторой процедуры; примитив request по существу эквивалентен requestor. submit).

(N)- сервисный примитив индикации ((N)-service-indication-primitive): примитив, выдаваемый поставщиком (N)-сервиса (например, для вызова некоторой процедуры или для информирования о том, что процедура была вызвана пользователем сервиса на удаленной точке доступа к сервису; примитив indication по существу эквивалентен acceptor. deliver).

(N)- сервисный примитив ответа ((N)-service-response-primitive): примитив, выдаваемый пользователем (N)-сервиса (пользователем-получателем) поставщику в конкретной точке доступа к сервису для завершения некоторой процедуры, предварительно вызванной посредством выдачи поставщиком примитива индикации в этой точке доступа к сервису (примитив response по существу эквивалентен acceptor. submit).

(N)- сервисный примитив подтверждения ((N)-service-confirm-primitive): примитив, выдаваемый поставщиком (N)-сервиса в конкретной точке доступа к сервису для завершения некоторой процедуры, предварительно вызванной посредством выдачи примитива запроса в этой же точке доступа (примитив confirm по существу эквивалентен requestor. deliver).

Заметим, что примитивы подтверждение и ответ, могут быть положительными или отрицательными в зависимости от обстоятельств.

Обязательное (N)-средство (mandatory (N)-facility): часть (N)-сервиса, которая должна быть обеспечена в (N)-точке доступа к сервису любой реализацией (N)-поставщика.

Факультативное (N)- средство поставщика ((N)-provider-optional-facility): часть (N)-сервиса, которая используется только в случае согласия пользователей сервиса.

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

Неподтверждаемый сервис (unconfirmed-service): сервис, который не включает в свои действия явного подтверждения о выполнении некоторой процедуры.

Сервис, инициируемый поставщиком (provider-initiated-service): сервис, который генерируется пользователю поставщиком сервиса без запроса пользователя (например, уведомление об ошибке поставщика).

OSI-local view: разделяемое (shared) поведение пользователя и поставщика сервиса при их взаимодействии на границе сервиса, по существу некоторый абстрактный интерфейс взаимодействия пользователя и поставщика.

10.1.2. Модель сервиса уровней

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

Общая модель OSI-сервиса, использующая примитивы submit и deliver, представлена на рис. 10.1.

Рис. 10.1. Общая модель OSI-сервиса

На рис. 10.2. показана модель предоставления (N)-сервиса со стороны поставщика (N)-сервиса двум равнозначным или одноранговым (N)-пользователям (peer (N)-users), т.е. (N+1)-сущностям-корреспондентам, взаимодействующим друг с другом с помощью некоторого (N+1)-протокола. Данная модель легко расширяется и для описания случаев, соответствующих множественным или широковещательным видам взаимодействия сущностей.

Рис. 10.2. Модель предоставления (N)-сервиса

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

Взаимосвязь между понятиями: сервис, сервисный примитив, одноранговые сущности и протокол взаимодействия между ними, показана на рис. 10.3.

    a - сервис
    b - сервисные примитивы
    c - протокол
    d - одноранговые сущности (протокольные автоматы)
Рис. 10.3. Взаимосвязь понятий в модели предоставления сервиса

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

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

Последняя задача, как правило, решается посредством использования специализированного языка ASN.1. В других случаях параметры примитивов могут описываться средствами языков спецификаций или языков программирования, задаваться в табличной форме или описываться на естественном языке. Использование языка ASN.1 для определения семантики примитивов будет рассмотрен далее. Первые три из указанных выше аспектов определения сервисов рассмотрим подробнее немедленно.

10.1.3. Состав и основные свойства сервисных примитивов

Первоначально рассмотрим состав типов и основные свойства сервисных примитивов.

Итак, в рассматриваемом стандарте определены четыре типа сервисных примитивов:

a) примитив запрос (request);

b) примитив индикация (indication);

c) примитив ответ (response) - ответ может быть положительным или отрицательным;

d) примитив подтверждение (confirm) - подтверждение может быть положительным или отрицательным.

Основными свойствами примитивов являются:

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

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

Для описания сервисных примитивов используется функциональная форма записи, имеющая следующий синтаксис:

ServiceType(param 1 , ..., param n),

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

Как видно из определений различаются следующие основные типы сервисов:

подтверждаемый сервис (confirmed service), в котором используются все четыре типа примитивов: запрос (request), индикация (indication), ответ (respond), подтверждение (confirm);
неподтверждаемый сервис (unconfirmed service), в котором используются два типа примитивов: запрос (request) и индикация (indication);
сервис, инициируемый поставщиком, в котором используется примитивы типа индикация (indication).

Таким образом, процесс реализации (N)-сервиса может рассматриваться в виде упорядоченного во времени набора атомарных событий, происходящих на границе (N)-уровня (а именно в точках (N)-SAP) и связанных с передачей и приемом примитивов запрос, индикация, ответ, подтверждение.

10.1.4. Наименование сервисных примитивов

Рассмотрим систему наименования сервисных примитивов. При формировании имени сервисного примитива в его состав вводится имя соответствующего типа примитива. Более точно имя каждого сервисного примитива содержит следующие три элемента:

a) обозначение уровня;

b) имя сервиса;

c) имя типа примитива.

При составлении имен примитивов конкретных уровней модели OSI RM символ уровня и имя сервиса отделяются друг от друга дефисом; а имя сервиса и имя типа примитива отделяются пробелом.

Примерами имен примитивов для (N)-сервиса, осуществляющего установление (N)-соединения (CONNECTION) с подтверждением, являются следующие конструкции:

(N)-CONNECTION request
(N)-CONNECTION indication
(N)-CONNECTION response
(N)-CONNECTION confirm

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

(N)-CONNECTION request
(N)-CONNECTION indication

Таким образом, процесс реализации (N)-сервиса может наблюдаться на границе (N)-уровня (а именно в точках (N)-SAP) как последовательность атомарных событий, связанных с передачей и приемом соответствующих данному сервису примитивов.

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

A - Прикладной (Application) - уровень 7;
P - Представительный (Presentation) - уровень 6;
S - Сеансовый (Session) - уровень 5;
T - Транспортный (Transport) - уровень 4;
N - Сетевой (Network) - уровень 3;
D - Канальный или звена данных (Data Link) - уровень 2;
Ph - Физический (Physical) - уровень 1.

Примерами имен примитивов сервисов для конкретных уровней моделиOSI являются:

P-CONNECT request - запрос представительного соединения, т.е. P-соединения;
T-DATA indication - индикация о доставке транспортного сегмента данных;
N-DISCONNECT confirm - подтверждение разрыва сетевого соединения.

10.1.5. Соглашения о временных диаграммах

Для описания логических и временных связей между примитивами сервиса используется метод диаграмм специального вида, которые будем называть TS-диаграммами (time-sequence diagrams). С помощью временных диаграмм можно отобразить:

a) последовательность событий на границе (N+1)-пользователь/(N)-поставщик в некоторой открытой системе;

b) последовательность событий между (N+1)-пользователями.

На рис. 10.4 показаны способы построения таких диаграмм.

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

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

Наличие детерминированных логических связей между двумя взаимодействующими точками доступа к сервису (точками вертикальных линий) обозначаются пунктирной линией между этими точками. Например, на рис. 3.а за примитивом request, поступившим в момент времени t1 в точку доступа к сервису, представленной вертикальной линией на диаграмме слева, должен последовать примитив indication, выдаваемый поставщиком сервиса в момент времени t2 в точке доступа к сервису, к которой подключен удаленный пользователь сервиса. При отсутствии логических связей между примитивами пунктирная линия в центральной области диаграммы между моментами проявления событий, соответствующих приему/передаче примитивов, будет отсутствовать. В этом случае для большей выразительности может использоваться знак тильда (~).

Рис. 10.3.b и 10.3.c иллюстрирует два способа реализации отрицательных подтверждений, генерируемых отвечающим пользователем. На рис. 10.3.b на протяжении всего цикла обслуживания запроса пользователя используется одно и то же имя (в данном случае - x), а на рис. 10.3.c отвечающий пользователь сервиса посылает встречный запрос с другим именем (в данном случае - y), показывая тем, самым, что предыдущий запрос на обслуживание данным пользователем отклоняется.

Рис. 10.4 Временные диаграммы

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

10.1.6. Соглашения, связанные с описанием параметров

Широко применяемый способ описания параметров примитивов основан на использовании так называемых таблиц параметров (parameter tables), в которых для обозначения свойств параметров используются следующие обозначения:

M параметр является обязательным (mandatory)
C параметр является условным (conditional)
(=) значение параметра семантически идентично значению соответствующего параметра примитива, логически связанного с текущим примитивом и непосредственно предшествующего его в последовательности событий сервиса
U использование параметра по усмотрению пользователя сервиса (OSI-service-user option).
P использование параметра по усмотрению поставщика сервиса (OSI-service-provider option).
пробел (blank) параметр не представлен в примитиве, описывающим конкретное взаимодействие поставщика и пользователя.