Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
part1.doc
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
376.83 Кб
Скачать

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

Модель ВОС определила не только содержание услуг каждого уровня, но и характер их взаимодействия, а именно - уровень 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 специфицируются только сервисы и протоколы. Интерфейсы рассматриваются как сущности, потенциально зависимые от методов реализации.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]