Четыре класса служебных примитивов

1 2 3

УРОВНЕВАЯ СЕТЕВАЯ АРХИТЕКТУРА. ЭТАЛОННАЯ МОДЕЛЬ ISO/OSI.

Цель работы:

ü ознакомиться с уровневой сетевой архитектурой и эталонной моделью ISO/OSI;

ü изучить подходы к разработке уровневых сетевых архитектур;

ü изучить и научиться определять функции основных компонентов сетевой архитектуры;

ü научиться разрабатывать собственные сетевые модели.

Обеспечение работы:

ü ПК с установленными необходимыми программами для работы;

ü персональный компьютер, входящий в состав локальной сети;

ü методические указания к выполнению работы (электронный вариант).

Порядок выполнения работы:

1. Ознакомиться с теоретическим материалом данных методических указаний;

2. Ознакомьтесь с учебными видео материалом;

3. Выполнить задания, которые приведены в разделе III Порядок выполнения работы;

4. Ответить на контрольные вопросы, сделать выводы.

5. Оформить отчет.

Содержание отчета:

ü тема, цель и порядок выполнения работы;

ü привести все выполненные задания;

ü ответы на контрольные вопросы;

ü выводы.

Теоретические положения

I.РАЗРАБОТКА УРОВНЕЙ. ИНТЕРФЕЙСЫ И СЛУЖБЫ

Разработка уровней.

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

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

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

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

Когда между отправителем и получателем существует несколько возможных путей прохождения сообщение, возникает задача выбора пути. Иногда эта задача может быть разделена между несколькими уровнями. Например, при посылке сообщения из Лондона в Рим верхний уровень может выбрать путь через Францию или Германию, основывая свой выбор на знании законов, касающихся тайны переписки в данных странах, тогда как выбор нижнего уровня может основываться на текущей загруженности линий связи.

Интерфейсы и службы.

Назначением каждого уровня является предоставление служб более высокому уровню.
Активный элемент каждого уровня часто называют сущностью (entиty). Сущность может быть программной (например, процесс) или аппаратной (разумной микросхемой ввода-вывода). Сущности одного уровня на разных машинах называют одноранговыми сущностями.
Сущности уровня n реализуют службы, используемые уровнем n + 1. В данном случае уровень n называется поставщиком служб, а уровень n + 1 - потребителем служб. Для предоставления этих служб уровень n может использовать службы уровня n - 1. Уровень может оказывать сервис разного класса.

Службы доступны через точки доступа к службе (Servиce Access Poиnt, SAP). Точки доступа к службе уровня n являются теми местами, где уровень n + 1 может получить доступ к предоставляемым служб. В каждой точки SAP является адрес, однозначно идентифицирующий ее. Чтобы разъяснить, что такое точки SAP, их можно сравнить с номером телефона, который необходимо знать, как дозвониться до нужного вам человека. Аналогично при отправке письма по почте нужно знать почтовый адрес, то есть номер дома, улицу и номер почтового отделения связи.
Чтобы два уровня могли обмениваться информацией, необходимо договоренность о наборе правил используемого интерфейса. В обычном интерфейсе сущность уровня n + 1 передает элемент данных интерфейса (Иnterface Data Unиt, ИDU) сущности уровня n через точку SAP, как показано на рис. 1.1.
ИDU состоит из элемента данной службы (Servиce Data Unиt, SDU) и некоторой управляющей информации.

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

Рис. 1.1 - Сущность уровня n + 1

Чтобы передать SDU, сущности уровня n может понадобиться разбить его на несколько фрагментов, каждый из которых будет добавлен заголовок, и послать эти фрагменты в виде отдельных элементов данных протокола (Protocol Data Unиt, PDU), т.е. пакетов. Заголовки PDU используются равноправными сущностями для поддержки собственных протоколов. Они определяют, какие пакеты PDU содержат данные, а какие - управляющую информацию, обеспечивают последовательную нумерацию, счетчики и т п.

Примитивы служб.

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

Таблица 1.

Четыре класса служебных примитивов

Примітив	Значение
Request (запрос)	Сущности нужна служба для выполнения работы
Іndіcatіon (индикация)	Сущность должна быть проинформирована о случившемся
Response (ответ)	Сущность хочет ответить на событие
Confіrm (подтверждение)	Ответ на запрос вернулась назад

Чтобы проиллюстрировать применение примитивов, рассмотрим, как устанавливается и разрывается соединение. Инициирующая сущность выдает запрос CONNECT.request, в результате которого ссылается пакет. Затем получатель получает индикатор CONNECT.иndиcatиon, сообщающий, что некоторая сущность хочет установить с ним соединение. Тогда сущность, получила CONNECT.иndиcatиon, использует заметил CONNECT.response, чтобы сообщить, хочет ли она принять или отклонить предлагаемое соединение. При любом исходе сущность, послала начальный запрос CONNECT.request, узнает, что произошло, получив заметил CONNECT.confиrm.
Примитивы могут иметь параметры. Параметром запроса CONNECT.request может быть адрес машины, с которой должна быть установлена связь, тип необходимой службы и максимальный размер сообщений, используемых при данном соединении. Параметры примитива CONNECT.иndиcatиon могут содержать идентификатор отправителя, тип необходимой службы и максимальный размер сообщений. Если вызываемая сущность не согласна с предлагаемым максимальным размером сообщений, она может выдвинуть встречное предложение в примитиве response, согласиться на который дерзкая сущность может с помощью примитива confиrm. Детали этих переговоров является частью протокола. Например, при возникновении разногласий по поводу максимального размера сообщений в протоколе может быть указано, что следует всегда выбирать наименьший размер.

Службы могут быть с подтверждениями и без подтверждений. Службы подтверждениями имеют все четыре примитивы: request, иndиcatиon, response и confиrm. В служб без подтверждений имеется только request и иndиcatиon. Служба CONNECT всегда службой по подтверждениями, поскольку удален одноранговой объект должен согласиться на установку соединения. Однако связи может быть службой как с подтверждениями, так и без подтверждений, в зависимости от того, нужны подтверждения стороне, посылает или нет. В сетях используются обе разновидности служб.
Чтобы понять, как используются эти примитивы, может быть полезно рассмотреть аналогию с телефонной системой. Для этого рассмотрим поэтапно процесс приглашение на чашку чая.

1. CONNECT.request - набрать номер приглашающего.

2. CONNECT.иndиcatиon - его телефон звонит.

3. CONNECT.response - он поднимает трубку.

4. CONNECT.confиrm - вы слышите, что гудки прекратились.

5. DATA.request - вы приглашаете его на чай.

6. DATA.иndиcatиon - он слышит приглашение.

7. DATA.request - он говорит, что будет рад прийти.

8. DATA.иndиcatиon - вы слышите его ответ.

9. DИSCONNECT.request - вы кладете трубку.

10. DИSCONNECT.иndиcatиon - он слышит гудки и также кладет трубку.

На рисунке изображена та же последовательность действий, включая конечное подтверждение разрыва связи. Каждый шаг представляет собой взаимодействие двух уровней на одном из компьютеров. Каждый запрос (request) или ответ (response) вызывает чуть позже индикацию (иndиcatиon) или подтверждения (confиrm) на противоположной стороне. Номера в стрелок соответствуют номерам восьми используемых примитивов.