Фазы и услуги сеансового сервиса

Сеансовый сервис включает 3 фазы, показанные на рисунке 3.8.

Рис.3.8.

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

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

Фаза завершения может иметь следующие формы:

· упорядоченное завершение;

· безусловное завершение, инициированное пользователем;

· безусловное завершение, инициированное поставщиком сеансового сервиса.

Функциональные группы и сервисные подмножества

Более 20 услуг этого уровня объединяются в 12 функциональных групп. Все открытые системы должны иметь возможность реализации хотя бы одной функциональной группы, которая называется базовой.

Базовая группа включает:

§ S-CONNECT – установление сеансового соединения;

§ S-DATA – передача нормальных данных;

§ S-RELEASE – завершение сеансового соединения;

§ S-U-ABORT – безусловное завершение по инициативе пользователя;

§ S-P-ABORT – безусловное завершение по инициативе поставщика сервиса.

К дополнительным относятся функциональные группы:

· согласованного завершения;

· большой синхронизации;

· управления активностью

· малой синхронизации

· дуплекса;

· полудуплекса;

· ресинхронизации;

· оповещения об ошибках;

· передачи срочных данных и т.д.

При установлении соединения согласовывается сервисное подмножество – сервисный профиль сеансового соединения. Это комбинация: базовая группа + ряд дополнительных групп.

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

Переговоры.

На фазе установления соединения партнеры согласуют ряд параметров сеансового соединения. Сначала выбирается некоторый сервисный профиль как пересечение указанных партнерами профилей (т.е. А Ù B). Затем согласуется качество сеансового сервиса. Оно определяется следующими параметрами:

1. защита сеансового соединения;

2. приоритет сеансового соединения;

3. темп остаточных ошибок;

4. полоса пропускания;

5. задержка передачи для каждого направления.

Для параметров 3 ¸ 5 указываются 2 значения:

¨ желаемая величина параметра;

¨ наименьшая приемлемая величина параметра.

Если поставщик не может обеспечить наименьшую приемлемую величину, то он сообщает об отказе в установлении соединения.

Семантика используемых параметров качества следующая.

«Защита сеансового соединения» показывает степень защиты от несанкционированного доступа. Имеются значения:

· без защиты;

· с защитой от пассивного вмешательства;

· с защитой от активного вмешательства;

· с защитой как от пассивного, так и от активного вмешательства.

«Приоритет» – означает приоритет по отношению к другим сеансовым соединениям.

«Темп остаточных ошибок» рассчитывается как отношение числа некорректных и потерянных блоков к общему числу переданных блоков данных.

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

«Задержка передачи» – интервал между моментом инициализации сервисного запроса и моментом его индикации на удаленной стороне. Указывается для блока стандартного размера.

Использование маркеров

Маркер данных применяется при полудуплексном обмене. Он указывает на партнера, который имеет право передавать данные (т.е. играет роль эстафетной палочки).

Маркер освобождения дает право его владельцу завершить сеансовое соединение.

Маркеры малой и большой синхронизации позволяют их владельцу использовать контрольные точки в потоке данных. Точкам присваиваются последовательные номера от 0 до 999999. Точки малой синхронизации могут использовать групповое подтверждение (т.е. подтверждаются и все точки с меньшими номерами). Для точек большой синхронизации требуется явное подтверждение.

Транспортный уровень OSI

Транспортный уровень предназначен для оптимизации передачи данных от отправителя к получателю, управления потоком данных и реализации запрошенного сеансовым уровнем качества обслуживания. На этом уровне определяется требуемый размер пакета (сегмента) для данной сетевой архитектуры. Уровень отвечает за сегментацию данных и их сборку в пункте назначения. Транспортный уровень гарантирует, что данные получены в правильном порядке, он же удаляет дубликаты и пересылает потерянные пакеты.

Данный уровень обеспечивает передачу данных с той степенью надежности, которая требуется приложениям. В качестве примеров транспортных протоколов можно привести TCP и UDP стека TCP/IP (они рассмотрены в соответствующей части курса), а также протокол SPX стека Novell. В рамках модели OSI были также разработаны соответствующие рекомендации МОС и МККТТ. Это:

¨ ISO 8072 и МККТТ Х.214, определяющие требования к транспортному сервису;

¨ ISO 8073 и МККТТ Х.224, – процедуры транспортного протокола.

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

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

Фактически транспортный сервис и транспортный протокол, предложенный OSI, включают в себя 5 разных сервисов и протоколов, именуемых классами и ориентированными на разный сетевой сервис.

Определено 3 типа сетевого сервиса:

q А – с приемлемым для пользователя уровнем необнаруженных ошибок и приемлемой частотой сообщений об обнаруженных ошибках;

q В – с приемлемым уровнем необнаруженных ошибок, но неприемлемой частотой сообщений об обнаруженных ошибках;

q С – с неприемлемым уровнем необнаруженных ошибок и неприемлемой частотой сообщений об обнаруженных ошибках.

Каждый класс транспортного протокола имеет разный функциональный состав (см. рис.3.9.).

Рис.3.9.

Классы 2 и 3 отличаются от классов 0 и 1 наличием процедур мультиплексирования транспортных соединений в сетевые. Такое мультиплексирование снижает затраты на использование сетевых соединений.

Транспортный протокол предоставляет пользователю следующие возможности.

· Адресация партнера.

· Выбор качества сервиса.

· Использование самых различных (и разнородных) сетевых ресурсов. Уровень скрывает от пользователя особенности сетевых средств.

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

Услуги транспортного уровня

Установление соединения

В примитиве T-CONNECT request указываются: вызываемый адрес, использование срочных данных, параметры качества сервиса, данные пользователя (32 байта).

В поступающем обратно примитиве T-CONNECT confirmation содержатся согласуемые партнером значения параметров качества сервиса: пропускной способности, транзитной задержки, коэффициента необнаруженных ошибок и вероятности отказа.(см рис.3.10.)

Рис.3.10.

Разъединение

В поле " причина" сообщается источник разъединения – удаленный пользователь или транспортный уровень.(см.рис.3.11.)

Рис.3.11.

3) Передача данных

Длина поля " данные пользователя" в примитиве не ограничивается, т.к. сам транспортный уровень осуществляет разбиение на протокольные блоки данных (ПБД).(см.рис.3.12.)

Рис.3.12.

4) Передача срочных данных

Объем поля " данные" не превышает 16 байт. Следующий примитив T-EXPEDITED-DATA не может передаваться, пока не завершится передача предыдущего (3.13.).

Рис.3.13.

⇐ Предыдущая 1 2 3 456 7 8 9 10 Следующая ⇒