Правила описания сервиса

Рассмотрим пример(рис.2.11.).

Протокольные объекты А и В устанавливают соединение друг с другом. Объект А передает протокольный блок REQ. Объект В, получив REQ, отвечает блоком RES.

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

CONNECT request – запрос установления соединения

CONNECT indication – уведомление о наличии запроса

CONNECT response – ответ пользователя на запрос

CONNECT confirmation – подтверждение установления соединения

Рис.2.11

Для рассматриваемого случая упрощенно будем иметь следующие помеченные графы для протокола установления соединения (см. рис.2.12.).

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

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

Элементы описания сервиса стандартизованы МОС в документе IS 8509. Согласно этому стандарту сервис уровня определяется через следующую абстрактную модель:

Обозначение каждого сервисного примитива состоит из трех элементов: обозначение уровня ВОС; имя примитива; тип примитива.

Уровни обозначаются следующим образом: А — прикладной; Р — представления; S — сеансовый; T — транспортный; N — сетевой; DL — канальный; PL — физический.

Имя примитива определяется видом услуги. Например,

CONNECT – установление соединения;

RESET – сброс;

DATA – передача данных.

Сервисные примитивы разделяются на 4 типа(рис.2.14.):

запроса – request; индикации – indication;

ответа – response; подтверждения – confermation.

Таким образом, например, примитив P-CONNECN request – это примитив представительного сервиса, относится к услуге по установлению соединения и является запросом.

Стандартом оговариваются также формальные правила составления диаграмм последовательности примитивов.

Вертикальные линии изображают точки доступа к сервису (N)-ТДС и, кроме того, течение времени (сверху-вниз).

При явной причинно-временной зависимости между сервисными примитивами они соединяются прямыми линиями. При отсутствии явной зависимости - используется "тильда".

Уточненная модель поставщика сервиса, показанная на рисунке, включает две очереди (А-В) и (В-А).

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

В исходный момент очередь пуста. Элементы передаются посредством очереди FIFO по соединению. На другом конце извлекаются из очереди в порядке следования (рис.2.15.).

3.Верхние уровни модели OSI

В рамках общей концепции OSI разработаны рекомендации по внутреннему содержанию уровней. В основном эту работу проводили следующие международные организации:

q CCITT (МККТТ) – международный консультативный комитет по телеграфии и телефонии;

q ISO (МОС) – международная организация по стандартизации;

Прикладной уровень

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

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

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

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

· имеют стандартную форму для задач одного класса приложений;

· нейтрализуют для пользователей различия хост-систем.

Прикладные протоколы подразделяются на 2 класса:

Системно-ориентированные (базовые). Это, например:

· Протокол обмена управляющей информацией CMIP (Common Management Information Protocol);

· протокол услуг каталогов DS (Directory Services), разработанный на базе рекомендации Х.500 МККТТ.

Проблемно-ориентированные. К ним относятся, например:

· удаленный ввод, передача и обработка заданий JTM (Job Transfer and Managemant);

· обработка сообщений MHS (Massage Handling Systems);

· передача и управление файлами FTAM (File Transfer, Access and Management);

· распределенная обработка документов ODIA (Office Document Interchange Architecture);

· доступ к распределенной базе данных DBAM (Database Access and Management);

· обмен сообщениями в распределенной среде MIDA (Distributed Application for Message Interchange) и т.д.

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

- SASE – специальные прикладные сервисные элементы;

- CASE – стандартные прикладные сервисные элементы;

- UE – элемент пользователя;

- SAP – точка доступа к услугам.

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

- сервисный элемент управления ассоциацией (Association Control Service Element – ACSE);

- сервисный элемент получения доступа к операциям отдаленного устройства (Remote Operations Service Element – ROSE);

- сервисный элемент надежной передачи (Reliable Transfer Service Element –- RTSE).

Рис.3.1. Рис.3. 2.