Файл: 8.doc

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

В главах 3 и 4 подробно отмечалось, что каждый пользова­тель базового доступа ISDN имеет свой D-канал сигнализации 16 Кбит/с. Это может привести к ситуациям, когда большое коли­чество пользовательских портов пытаются использовать один и тот же сигнальный канал 64 Кбит/с в интерфейсе V5.

Чтобы предотвратить перегрузку С-канала, содержащего С-пути типа Ds, нужно, чтобы станция могла запросить в сети дос­тупа блокировку сигналов по D-каналу определенного пользователь­ского порта ISDN. С этой целью АТС передает сообщение LE/ PORT_CONTROL: D-channel-block(6AOKHpoBKa-D-KaHana), а по­сле окончания ситуации перегрузки - сообщение LE/PORT_CON-TROL: D-channel-unblock (разблокировка-D-канала).

254 Глава 8 __________________________________

Для активизации и деактивизации портов базового доступа ISDN предусматриваются следующие сообщения. Если активиза­ция происходит по инициативе пользователя, на станцию переда­ется сообщение AN/PORT_CONTROL: activation-initiated-by-user (активизация-по-инициативе-пользователя). Как правило, АТС отвечает сообщением LE/PORT_CONTROL: activate-access (активизировать-доступ), которое инициирует передачу соответствую­щего сигнала от сети к пользователю. Пользователь получает и так­товый синхросигнал, после чего к АТС передается сообщение AN/PORT_CONTROL: access-activated (доступ-активизирован). Если активизация осуществляется по инициативе АТС, то от нее передается сообщение LE/PORT_CONTROL: activate-access.

Деактивизацию АТС запрашивает с помощью сообщения LE/PORT_CONTROL: deactivate-access (деактивизировать-доступ). После деактивизации доступа к АТС передается сообщение AN/PORT_CONTROL: access-deactivated (доступ-деактивирован).

Сообщения COMMON_CONTROL обеспечивают проверку согласованности обеих сторон интерфейса V5, рестарт протокола ТфОП, а также внесение изменений в конфигурацию на любой стороне интерфейса. Предусматриваются следующие виды сооб­щения COMMON_CONTROL: запрос-варианта-и-идентификато-ра-интерфейса, вариант-и-идентификатор-интерфейса, верифика­ция-реконфигурации, не-готов-к-реконфигурации, готов-к-ре-конфигурации, переключение-на-новый-вариант, реконфигура­ция-невозможна, блокировка-начата, реконфигурация-начата, рестарт-ТФОП и подтверждение-рестарта-ТФОП.

Повышенное внимание, уделяемое в этой книге протоколу ТфОП, вызывает необходимость дополнительных пояснений к двум последним функциям управления. В ряде случаев может по­надобиться принудительно возвратить протокол ТфОП в исходное состояние. Для самого протокола ТфОП это более сложная про­блема, чем для других протоколов V5, поскольку сообщения про­токола ТфОП отображаются на сигналы конкретных пользователь­ских портов, которые не предусматривают общего рестарта самого протокола. Если любая сторона интерфейса V5 инициирует рестарт протокола ТфОП, она выдает сообщение COMMON_CON-TROL: restart. Принимающая сторона должна подтвердить его при­ем передачей в обратном направлении сообщения СОМ-MON_CONTROL: restart-acknowledge. Оба этих сообщения, СОМ-MON_CONTROL: restart и COMMON_CONTROL: restart-acknowl-

Служебные протоколы V5.2 255

edge, являются управляющими сообщениями, поэтому подтвержда­ются, соответственно, сообщениями COMMON_CONTROL_ACK:

restart и COMMON_CONTROL_ACK: restart-acknowledge. Такая из­быточность подтверждений (на уровне 2 плюс двойное квитирова­ние на уровне 3) обуславливается тем, что сброс протокола ТфОП может повлиять на обслуживание нескольких тысяч пользователей. Внимательный читатель, вероятно, заметил противоречия между этим подходом и техническими решениями протокола защиты, рас­смотренного в предыдущем параграфе. Функция рестарта протоко­ла ТфОП включена в протокол управления, хотя ее можно было бы включить в протокол ТфОП точно таким же образом, как функция рестарта протокола защиты непосредственно встроена в этот про­токол. Естественным также могло бы быть использование сообщения PROTOCOL_ERROR протокола защиты и для других протоко­лов [83] либо путем введения его в каждый из этих протоколов, либо включением соответствующих функций общего управления в про­токол управления. Логичным было бы использовать в обоих случаях одинаковый подход, но идеальных протоколов, как известно, не бывает.

Глава 9

ПРОТОКОЛ Х.25

Ты старомоден. Вот расплата

За то, что в моде был когда-то.

С.Я. Маршак

9.1. Модель взаимодействия открытых систем

Несколько странным может показаться введение отдельного параграфа в конце второго тома для обсуждения неоднократно упоминавшейся ранее модели взаимодействия открытых систем OSI. Но, во-первых, автор давно обещал это сделать, во-вторых, этого требует специфика рассматриваемого в данной главе прото­кола Х.25, а в-третьих, книга подходит к концу, и другого случая может и не быть.

Многоуровневый комплект протоколов, известный как мо­дель взаимодействия открытых систем (OSI — Open Systems Inter­connection), разработан в 1984 году Международной организацией по стандартизации ISO совместно с Сектором стандартизации электросвязи 1TU-T, называвшимся в те времена Международным консультативным комитетом по телеграфии и телефонии (МККТТ), для обеспечения обмена данными между компьютер­ными сетями. Структура модели OSI представлена на рис. 9.1.

Применительно к системам электросвязи модель OSI служит для того, чтобы четко определить структуру множества функций, поддерживающих информационный обмен между пользователя­ми услугами системы электросвязи, которая, в общем случае, со­держит в себе сеть связи. Подход, использованный в модели OSI, предусматривает разделение этих функций на семь «слоев» (layers) или «уровней», расположенных один над другим. С точки зрения любого уровня все нижележащие уровни предоставляют ему «ус­лугу транспортировки информации», имеющую определенные ха­рактеристики. То, как реализуются нижележащие уровни, для вы­шележащих уровней не имеет значения. С другой стороны, для нижних уровней безразличны как смысл поступающей от верхних уровней информации, так и то, с какой целью она передается.

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

Протокол Х.25 ___ _________ 257

Рис. 9.1. Структура модели OSI

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

Уровень 2 (или уровень звена данных) формирует двусторон­ний канал связи (то есть прямое звено связи между смежными уз­лами сети), используя для этого два предоставляемых уровнем 1 цифровых канала с противоположными направлениями передачи. Важнейшие функции уровня 2 — обнаружение и исправление оши­бок, которые могут возникнуть на уровне 1, что делает независи­мым качество услуг этого уровня от качества получаемых «снизу» услуг передачи битов.

Уровень 3 (или сетевой уровень) формирует так называемые сетевые услуги, маршрутизацию и коммутацию соединений, обес­печивающие перенос через сеть информации, которой обмениваются