Протокол управления

Напомним, что из четырех рассматриваемых в этой главе протоколов первые три относятся исключительно к интерфейсу V5.2. И только этот параграф посвящен протоколу управления, яв­ляющемуся единственным служебным протоколом, который дол­жен всегда присутствовать в обоих интерфейсах V5.1 и V5.2 и кото­рый управляет как пользовательскими портами, так и некоторы­ми общими функциями. Протокол управления позволяет блоки­ровать и разблокировать пользовательские порты, проверять иден­тификацию и конфигурацию интерфейса V5, а также осуществлять рестарт протокола ТфОП после отказа.

Сообщения протокола управления интерфейса V5 идентифи­цируются информационным элементом «тип сообщения» в общем заголовке. Предусматривается четыре типа сообщений. Два из них, PORT_CONTROL и COMMON_CONTROL, являются иниции­рующими сообщениями, которые управляют портами и общими функциями, соответственно. Два других типа сообщений — PORT_ CONTROL_ACK и COMMON_CONTROL_ACK - являются под­тверждающими. Для сообщений общего управления адрес сооб­щения в заголовке берется из общего адресного пространства V5 согласно таблице 6.3 главы 6 этой книги. Для сообщений управле­ния, ориентированных на порт, адрес определяется соответствую­щим портом ТфОП или ISDN. В заголовке сообщений управле­ния имеет место дублирование информации, поскольку как адрес уровня 3, так и информационный элемент «тип сообщения» ука­зывают, ориентировано ли сообщение на порт или оно является со­общением общего управления.

Непосредственно за общим заголовком сообщения протокола управления следует обязательный информационный элемент, идентифицирующий конкретную функцию, с которой связано инициирующее или подтверждающее сообщение. Этим информационным элементом в сообщениях PORT_CONTROL и PORT_ CONTROL_ACK является «Элемент функции управления» (Control-function-element).

Сообщения PORT_CONTROL поддерживают блокировку и разблокировку всех портов ТфОП, ISDN и арендованных линий, а также ряд функций, специфических для портов ISDN: активиза­цию и деактивизацию, индикацию ошибок и рабочих характери­стик, управление потоком сигнализации. В связи с этим в сообще­ния могут вводиться соответствующие необязательные информа­ционные элементы. Например, сообщения PORT_CONTROL: per­formance-grading содержат информационный элемент «Качество-работы».

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

Сеть доступа не всегда осведомлена о том, занят или нет поль­зовательский порт, поскольку сигнализация ISDN ею не интерпре­тируется и поскольку некоторые порты ISDN могут быть актив­ными, даже когда отсутствует сигнализация или нагрузка. Исчер­пывающие сведения о состоянии портов имеются только на АТС. Поэтому в том случае, когда инициатором блокировки порта яв­ляется сеть доступа, она запрашивает об этом АТС, передавая свой запрос в сообщении AN/PORT_CONTROL: block-request. АТС может ответить сообщением LE/PORT_CONTROL: block, указы­вающим, что она заблокировала порт, либо немедленно, либо сра­зу же после освобождения порта. Сеть доступа может затем пере­дать свое сообщение AN/PORT_CONTROL: block без опасности нарушить обслуживание вызовов портом. Если АТС не отвечает на сообщение AN/PORT_CONTROL: block-request в течение некото­рого времени, сеть доступа может передать сообщение AN/ PORT_CONTROL: block с риском нарушить текущие связи поль­зователей.

АТС не должна передавать запрос блокировки в сеть досту­па, поскольку она может блокировать порт без нарушения теку­щих связей, т.к. она знает об их состоянии. Инициируя блокиров­ку порта, АТС сразу передает сообщение PORT_CONTROL: block.

Чтобы разблокировать ранее заблокированный порт, обе сто­роны должны передать и принять сообщение PORT_CONTROL: unblock. Разблокировка отменяется, если с любой стороны передается сообщение PORT_CONTROL: block или если сеть доступа передает сообщение AN/PORT-CONTROL: block-request после приема сообщения PORT_CONTROL: unblock.

Автор вынужден отметить, что описанные процедуры блоки­ровки и разблокировки портов протоколов V5 не соответствуют рекомендации ITU-T X.731 относительно управления состояния-ми, что создает некоторые проблемы при использовании методов сети эксплуатационного управления системами связи TMN. Для согласования Х.731 с интерфейсом V5 разработан специальный «мэппинг», что несколько увеличивает сложность интерфейсов управления.

Сообщения COMMON_CONTROL и COMMON_CONT­ROL_АСК тоже содержат обязательный информационный элемент «Идентификатор-функции-управления» (control-function-ID). Некоторые сообщения общего управления, связанные с измене­нием конфигурации интерфейса, содержат информационный эле­мент «Вариант», в котором указывается номер предлагаемого ва­рианта конфигурации. Сообщения COMMON_CONTROL: not-ready-for-reprovisioning (не-готов-к-реконфигурации) и COMMON_CONTROL: cannot-reprovision (реконфигурация-не­возможна) содержат также информационный элемент Rejection-cause (Причина-отказа). Сообщения COMMON_CONTROL: vari-ant-and-interface-ID (вариант-и-идентификатор-интерфейса) со­держат информационный элемент «Идентификатор интерфейса».

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

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

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

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

Глава 9

Дата добавления: 2015-11-04