42. Представление сервиса в модели OSI. Правила описания сервиса. Взаимосвязь в режиме без соединения. Описание сервисов физического и канального уровней. Граф последовательности канальных сервисных примитивов.
(N+1)-объекты могут связываться между собой только с помощью услуг, предоставляемых N-уровнем.
Объекты смежных уровней взаимодействуют друг с другом через общий интерфейс. Для локализации тех мест, в которых происходит взаимодействие, используется понятие сервисной точки доступа (СТД) N-уровня (N-СТД). Именно через N-СТД происходит предоставление сервиса N-уровнем и потребление сервиса (N+1)-уровнем.
Между (N+1)-объектами, N-объектами и N-СТД существуют определенные соотношения. Во-первых, объекты, имеющие общую СТД, находятся в одной системе. Во-вторых, (N+1)-объект может быть подключен к нескольким N-СТД, соединенным с одними и теми же несколькими N-объектами. Однако в каждый момент времени каждая N-СТД соединена только с одним N-объектом и только с одним (N+1)-объектом. Это жесткое ограничение обусловлено тем, что при обеспечении связи объектов разных уровней СТД используется как идентификатор объекта соседнего уровня.
Местоположение N-СТД определяется N-адресом.
Внутри уровня могут существовать два различных вида функций отображения N-адресов: иерархическое и отображение с помощью таблиц. В пределах каждого уровня между парой СТД, располо-женных в различных системах, может быть установлено не-сколько соединений. Например, когда каждая система в отдель-ности предоставляет более одного сервиса и необходимо разли-чать точки доступа к ним. В этом случае используют идентифи-катор конечной точки соединения (КТС).
Точка связывает три элемента: (N+1)-объект, N-объект и N-соединение. Идентификатор КТС должен быть уникальным в пределах СТД.
Данные, передаваемые через интерфейс за одно взаимодей-ствие, называются интерфейсным блоком данных. Очевидно, что в различных реализациях и на различных уровнях такой блок может иметь различный формат и длину. В связи с этим при рассмотрении сервиса используют понятие сервисного бло-ка данных (СБД). Сервисный блок данных — это данные поль-зователя (в общем случае несколько интерфейсных блоков дан-ных), идентичность которых при передаче по соединению со-храняется. Это означает, что границы, форма и содержание СБД на двух КТС идентичны и не зависят от того, какими порциями и как СБД передавался по соединению.
Правила описания сервиса.
Пусть два протокольных объекта А и Б устанавливают соединение друг с другом. Объект А передает протокольный блок REQ. Объект Б, получив блок REQ, отвечает блоком RES. При завер-шении обмена блоками соединение считается установленным.
С точки зрения вышестоящего пользователя, предоставляе-мый здесь сервис по установлению соединения заключается в том, что:
- пользователь-инициатор (на стороне А) может послать за-прос на установление соединения;
- пользователь-рецептор может получить сообщение о том, что его запрашивают, и передать ответ;
- пользователь-инициатор может получить подтверждение от рецептора о его согласии установить соединение.
Обозначим сообщения пользователей следующим образом:
- CONNECT request — запрос установления соединения, выдаваемый пользователем А;
- CONNECT indication — уведомление пользователя Б о на-личии запроса от пользователя А;
- CONNECT response — ответ пользователя Б;
- CONNECT confirmation — подтверждение установления соединения, выдаваемое пользователю А.
Сообщения не могут поступать в произвольном порядке. Наконец, необходимо задать соотношения сообщений на разных концах соединения.
Рассмотренные пользовательские сообщения получили в литературе и стандартах ВОС название сервисных примитивов.
Сервис состоит из услуг. Так, показанный ранее пример — это сервис, состоящий из одной услуги по установлению соединения. Услуги могут быть обязательными и факультативными, а также подтвержденными и неподтвержденными.
Уровень обозначается буквами А (прикладной), Р (представительный), S (сеансовый), Т (транспортный), N (сетевой), DL (канальный) и PL (физический).
Имя примитива определяется типом услуги. Например, услуга по установлению соединения описывается примитивами с именем CONNECT, по сбросу — RESET, по передаче данных — DATA и т.д.
Таким образом, примитив Р — CONNECT request есть при-митив представительного сервиса, относится к услуге по уста-новлению соединения и является запросом.
Каждая диаграмма представля ется тремя полями, разделенными двумя вертикальными линия-ми (рис. 3.11). Центральное поле представляет поставщика сер-виса, а крайние поля — пользователей сервиса. Вертикальные линии изображают точки доступа к сервису и, кроме того, тече-ние времени (сверху вниз).
Описание сервисов физического и канального уровней.
Сервисным блоком данных физического уровня является 1 бит в случае последовательной передачи и N бит при параллельной.
Биты передаются дуплексным или полудуплексным способом и доставляются потребителю в том же порядке, в каком они поступали от источника. Если внутри физического уровня обнаруживается отказ (например, нарушение физической среды), то канальные объекты оповещаются об этом.
С точки зрения пользователей, то есть сетевых объектов, сервис канального уровня позволяет обеспечить:
- независимость от используемых физических средств передачи.
- надежный обмен данными.
- прозрачную передачу данных.
- выбор качества сервиса. Качество сервиса канального соединения связано с такими параметрами, как пропускная способность, транзитная задержка, уровень ошибок, надежность. Пользователям предоставляется возможность запросить и согласовать параметры качества сервиса;
- установление соединения по требуемому адресу.
Канальный сервис состоит из следующих услуг:
Установление канального соединения. Услуга описывается следующими сервисными примитивами с параметрами (рис. 3.16):
1. DL-CONNECT request: (вызываемый адрес (Адрес вызываемой СТД), вызывающий адрес (адрес вызывающей СТД), использование срочных данных, параметры КЧС, данные пользователя).
2. DL-CONNECT indication: (вызываемый адрес, вызывающий адрес, использование срочных данных, параметры КЧС, данные пользователя).
3. DL-CONNECT response: (адрес ответчика (адрес отвечающей СТД), использование срочных данных, параметры КЧС, данные пользователя).
4. DL-CONNECT confirmation: (адрес ответчика, использование срочных данных, параметры КЧС, данные пользователя).
При установлении соединения выполняется услуга по согласованию таких параметров КЧС, как пропускная способность и транзитная задержка для каждого направления передачи.
Для этих параметров согласовываются четыре значения: желаемое, крайнее приемлемое, обеспечиваемое и выбранное. Первые два значения определяются пользователем в примитиве DL-CONNECT request. Второе и третье значения вставляются канальным уровнем в примитив DL-CONNECT indication. Наконец, четвертое значение вставляется в примитивы DL-CONNECT response и DL-CONNECT confirmation.
Два параметра КЧС не согласовываются, но выбираются пользователем — это тип защиты данных и приоритет.
Разъединение звеньевого соединения. Услуга связана с обменом следующими сервисными примитивами:
1. DL-DISCONNECT request: (инициатор, причина, данные пользователя);
2. DL-DISCONNECT indication: (инициатор, причина, данные пользователя). Эти сервисные примитивы используются в тех случаях, когда разъединение инициировано:
- одним или обоими пользователями на уже установленном соединении (рис. 3.17,а);
- канальным уровнем на уже установленном соединении (рис. 3.17,б);
- пользователем при отказе установить соединение (3.17,в);
- канальным уровнем при невозможности установить соединение (3.17,г);
- пользователем, который перед этим выдал DL-CONNECT request (3.17,д).
Использовать услугу по разъединению разрешается в любой момент. При разъединении могут быть аннулированы не доставленные данные. Используемые при разъединении параметры имеют следующий смысл:
- инициатор — указывает источник разъединения (пользователь или канальный уровень);
- причина — дает информацию о причине разъединения. Порядок использования этого поля приведен в таблице 3.2;
- данные пользователя — могут иметь ограничение на длину в 128 октетов.
Передача данных. При передаче обычных (не срочных) данных используются следующие сервисные примитивы:
DL-DATA request: (данные пользователя);
DL-DATA indication: (данные пользователя).
Данные пользователя в примитивах представляют собой КСБД. Услуга по передаче данных заключается в прозрачной передаче КСБД от одной СТД к другой с сохранением последовательности КСБД. Для каждой пары примитивов задана последовательность использования при выполнении услуги (рис. 3.18). Соотношение может быть нарушено ситуациями разъединения или возврата в исходное состояние.
Факультативной услугой является передача срочных данных, описываемая следующими сервисными примитивами:
1. DL-EXPEDITED DATA request: (данные пользователя);
DL-EXPEDITED DATA indication: (данные пользователя).
По сравнению с потоком нормальных данных поток срочных данных имеет следующие свойства:
- срочные КСБД доставляют пользователю даже в том слу-чае, когда пользователь приостанавливает прием нормальных КСБД;
- срочные КСБД могут обгонять нормальные КСБД.
Перевод в исходное состояние.
Для выполнения услуги используются следующие сервис-ные примитивы:
1. DL-RESET request: (инициатор, причина);
2. DL-RESET indication: (инициатор, причина);
3. DL-RESET response;
4. DL-RESET confirmation.
Параметры примитивов используются следующим образом:
- инициатор — указывает на источник сброса и
может
иметь два значения — «пользователь» или «канальный уро-
вень»;
- причина
— принимает значение «перегрузка соединения»
или «ошибка», если инициатором является канальный уровень,
и значение «рабочий сброс», если инициатором является поль-
зователь.
Сервис типа «без соединения» связан с передачей отдель-ных независимых КСБД. Для случая успешной передачи этот сервис описывается двумя примитивами (рис. 3.24):
1. DL-UNITDATA request: (вызываемый адрес, вызы-вающий адрес, параметры КЧС, данные пользователя);
2. DL-UNITDATA indication: (вызываемый адрес, вызы-вающий адрес, параметры КЧС, данные пользователя).
Адресные параметры имеют те же значения, что и в прими-тивах сервиса с соединением.
Использование параметров КЧС связано со следующими правилами:
- в примитиве DL-UNITDATA request разрешается указы-вать любое значение параметров КЧС из диапазона обеспечи-ваемых;
- в примитиве DL-UNITDATA indication значение параметров КЧС не может быть лучше, чем запрошенное качество сервиса.
