Абстрактная модель межуровневого взаимодействия

Модель ВОС определила не только содержание услуг каждого уровня, но и характер их взаимодействия, а именно - уровень N предоставляет полный набор услуг, необходимых длясвязи объектов уровня (N+1). Поэтому вышестоящий уровень называют пользователем услуги, а нижестоящий – поставщиком услуги.

Содержание одноименных услуг разных уровней, конечно, различаются. Например, услуги обнаружения и коррекции ошибок предоставляются почти каждым уровнем, но уровень канала, например, корректирует ошибки, возникающие в процессе передачи кадров между парой непосредственно связанных устройств, а транспортный уровень обнаруживает и исправляет как ошибки доставки сегментов на всем пути, так и нарушения последовательности их доставки. Реализация N–услуги – это забота N - протокола и ее пользователь (уровень N+1) ничего об этой реализации «не знает».

Концепция взаимодействия уровней по схеме «Поставщик-пользователь» представлена на рис.2.3, где изображены объекты трех уровней, сформированные на двух хостах. Наличие двух объектов уровня N+1 может отражать, например, наличие двух независимых прикладных процессов (процесс 1 и процесс 2) на каждом хосте.

Доступ к услуге каждого уровня осуществляется через программный порт, называемый точкой доступа к N -услуге ( N-SAP ). У каждой точки доступа есть адрес, однозначно идентифицирующий ее место в сети. Каждая N-SAP соединена только с одним N -объектом и только с одним (N+1)-объектом. Такое ограничение связано с идентификацией (адресацией) объектов. Итак, каждый (N+1)-объект должен иметь "свою" N-SAP. В приведенном примере N -уровень предоставил для каждого N+1 -объекта отдельную точку доступа к своим услугам. Вообще говоря, межуровневые соединения могут устанавливаться по схемам «один к одному», «один ко многим» и «многие к одному».

В общем случае, услуга уровня N, предоставляемая определенной N+1 сущности, включает в себя прием блока данных от уровня N+1 хоста А, дополнение его заголовка полями, содержащими необходимые указания уровню N хоста Б,передачу блока данных уровню N взаимодействующего узла и доставку блока данных уровню N+1 хоста Б в соответствии с инструкциями, содержащимися в заголовке блока данных уровня N. Эти функции могут реализовываться с предварительным установлением соединения между точками доступа к N -услугам, или без такового.

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

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

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

3. Ликвидация соединения и освобождение всех зарезервированных для него ресурсов.

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

Обмен данными между объектами одного уровня управляется протоколами этого уровня. Каждая информационная единица (сегмент, пакет, кадр) содержит данные, поступающие с вышестоящего N+1 уровня (блок данных протокола, БДП- N+1), и управляющую информацию, добавляемую протоколом уровня N (рис.2.4).

Блок данных протокола N+1 уровня (БДП- N+1) отражается в блок (блоки) данных услуги N -уровня (БДУ- N). Это отображение может быть отображением 1:1, или же БДП-(N+1) может быть подвергнут сегментации, либо объединению с другими блоками БДП-(N+1). Блок БДП- N, поступающий адресату, т.е. в равноуровневый N -объект другой системы, подлежит обработке, в ходе которой будут удалены блоки управляющей информации УИП- N и проведено объединение (сегментация) БДУ- N

Следуя концепции «поставщик-потребитель», модель ВОС определила, что обращение к службе N -уровня производится посредством четырех основных примитивов (процедур, команд), а именно: запрос (request), индикация (indication), ответ (response) и подтверждение (confirm). Каждая из этих процедур может иметь набор параметров, специфицирующих адрес точки доступа к запрашиваемой услуге, тип службы, размеры блоков данных и т.п. Схематически использование этих примитив представлено на рис.2.5.

Запрос услуги установления соединения (СОЕД.) от (N+1) уровня системы А приводит к формированию блока данных протокола БДП- N A и, после доставки его равноуровневому объекту на узле B, к генерации примитива «Индикация», посредством которого N+1 -объек узла В информируется о запросе соединения с узлом А; N+1 -объек узла В отвечает примитивом «Ответ», который в конечном итоге попадает к элементу (N+1) уровня системы А в форме примитива «Подтверждение». Благодаря такому обмену инициатор соединения узнает о возможности, или невозможности, получения затребованной услуги. Конкретные примеры этих примитивов будут рассмотрены далее.

Обратим внимание на то, что примитивы Запрос и Ответ являются примитивами потребителя сервиса, а Индикация и Подтверждение – примитивы поставщика сервиса.

Модель сервиса

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

· подтверждаемый сервис (confirmed service) - использует все четыре типа примитивов: запрос, индикация, ответ, подтверждение;

· неподтверждаемый сервис (unconfirmed service) - использует примитивы запрос и индикация;

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

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

Не нашли, что искали? Воспользуйтесь поиском: