Протокол защиты V5. 2

В первый раз в этой книге протокол защиты был упомянут в четвертой строке таблицы 6.2 главы б как одно из основных отли­чий интерфейса V5.2 от V5.1. Собственно говоря, суть протокола защиты (как отличительной особенности интерфейса V5.2) сфор­мулирована гораздо раньше в другой Книге: «Двоим лучше, неже­ли одному; потому что у них есть доброе вознаграждение в труде их: ибо если упадет один, то другой поднимет товарища своего. Но горе одному, когда упадет, а другого нет, который поднял бы его... И если станет преодолевать кто-либо одного, то двое устоят про­тив него: и нитка, втрое скрученная, нескоро порвется» (Екклеси­аст, гл.4, ст.9-12). Протокол защиты охраняет логические С-кана-лы от отказа одного тракта в интерфейсе V5.2, обеспечивая воз­можность другим протоколам продолжать работу, несмотря на по­явление неисправностей в оборудовании.

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

Основным событием, вызывающим необходимость защиты, является отказ тракта 2048 Кбит/с. Протокол защиты используется также в случае устойчивых отказов в звеньях уровня 2 протокола V5 (т.е. устойчивый отказ одного из звеньев, используемых протокола­ми ВСС, управления, управления трактами, ТфОП или самим про­токолом защиты). Кроме того, необходим постоянный контроль флагов всех активных и резервных С-каналов, чтобы обеспечить за­щиту от отказов, которые не обнаруживаются механизмами уровня 1. Так, если в физическом С-канале в течение 1 с не принимается комбинация флага, то этот С-канал должен рассматриваться как нерабочий. Если обнаруживается отказ резервного С-канала, то за­щитное переключение на него не должно производиться.

Рис.8.6. Структура сообщения протокола защиты

Механизм защиты применяется также и по отношению к С-пути самого протокола защиты. В отличие отлюбыхдругих про­токолов V5 сообщения протокола защиты передаются дважды, по разу в каждом из двух трактов, которые его обслуживают. Структура этих сообщений приведена на рис.8.6. Заголовок сообщений протокола защиты V5.2 начинается с дискриминатора протокола, об­щего для всех сообщений V5, а заканчивается информационным эле­ментом типа сообщения, который определяет одно из восьми воз­можных сообщений протокола защиты (таблица 8.8).

Первые пять сообщений в таблице 8.8 связаны с функциями переключения и управляют соответствием логических С-каналов и физических канальных интервалов. Оставшиеся три сообщения связаны с ошибками протокола и с перезапуском средств нумера­ции сообщений. Сообщения переключения и сообщения об ошиб­ках в протоколе последовательно нумеруются, номер сообщения содержится в информационном элементе Sequence-number (поряд­ковый-номер). Сообщения перезапуска средств нумерации пере­даются в качестве команды или подтверждения, если обнаружива­ются нарушения нумерации других сообщений. Канальный интер­вал, к которому эти сообщения относятся, идентифицируется ин­формационным элементом Physical-C-channel (физический-С-ка-нал).

Таблица 8.8. Список сообщений протокола защиты

Кодирование типа сообщения	Сообщение протокола ВСС	Направ­ление AN LE
							ЗАПРОС ПЕРЕКЛЮЧЕНИЯ	SWITCH_OVER_REQ	———>
							КОМАНДА ПЕРЕКЛЮЧЕНИЯ	SWITCH_OVER_COM	<———
							КОМАНДА ПЕРЕКЛЮЧЕНИЯ ОС	OS_SWITCH_OVER_COM	<———
							ПОДТВЕРЖДЕНИЕ ПЕРЕКЛЮЧЕНИЯ	SWTTCH_OVER_ACK	———>
							ОТКАЗ В ПЕРЕКЛЮЧЕНИИ	SWITCH_OVER_REJECT	<———>
							ОШИБКА ПРОТОКОЛА	PROTOCOL_ERROR	———>
							КОМАНДА СБРОСА ПОРЯДКОВОГО НОМЕРА	RESET_SN_COM	<———>
							ПОДТВЕРЖДЕНИЕ СБРОСА ПОРЯДКОВОГО НОМЕРА	RESET_SN_ACK	<———>

Эти информационные элементы должны содержаться во всех сообщениях переключения, а сообщения SWITCH_OVER_REJECT должны содержать также информационный элемент Rejection-cause, который указывает причину, по которой отказано в переключении.

Команды, которые переключают логические С-каналы на дру­гие физические канальные интервалы, передаются только со сторо­ны АТС, поскольку только АТС располагает сводной таблицей ото­бражения логических связей на физические. Если переключение было инициировано операционной системой (ОС) АТС, то станция передает сообщение OS_SWITCH_OVER_COM, подавая команду сети доступа переключить указанный логический С-канал на ука­занный канальный интервал. Станция может также передать сооб­щение SWITCH_OVER_COM, чтобы выполнить ту же самую функ­цию в случае, когда не нужно указывать, что переключение было инициировано операционной системой.

По мнению [83], с которым автор солидарен, нет видимой при­чины информировать сеть доступа о том, кто инициировал пере­ключение.

Примеры сценариев переключения приведены на рис.8.7.

Рис.8.7. Сценарии переключения

Сеть доступа передает сообщение SWITCH_OVER_ACK, что­бы информировать АТС о выполнении команды переключения ло­гического С-канала на новый канальный интервал. Если сеть досту­па не может выполнить команду, она отвечает сообщением SWITCH_OVER_REJECT.

Сеть доступа может использовать сообщение SWITCH_ OVER_REQ, чтобы запросить АТС переключить указанный логиче­ский С-канал на указанный канальный интервал.

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

Обе стороны интерфейса V5.2 ожидают получения сообще­ний с очередным порядковым номером. Если в получаемом одной из сторон интерфейса сообщении происходит «скачок» нумерации, то регистрируется сбой и к противоположной стороне направля­ется сообщение RESET_SN_COM, чтобы информировать ее о том, что нумерацию сообщений нужно начать заново. Сторона, кото­рая получает сообщение RESET_SN_COM, отвечает сообщением RESET_SN_ACK, подтверждающим, что соответствующие счет­чики установлены в «0». Напомним, что нумеруются сообщения переключения и ошибок в протоколе, т.е. первые шесть из восьми сообщений протокола защиты.

Сообщения перезапуска средств нумерации не содержат спе­циализированных информационных элементов и не привязаны к отдельным логическим С-каналам. Поэтому обязательный инфор­мационный элемент «Идентификатор логического С-канала» (байт 2 и байт 3 рис.8.6) в этих сообщениях имеет значение «0» (т.е. все биты должны быть установлены в «0»).

Таблица 8.9. Кодирование типа ошибки протокола

							Тип ошибки протокола
							Ошибка дискриминатора протокола
							Неопознанный тип сообщения
							Пропуск обязательного информационного элемента
							Неопознанный информационный элемент
							Ошибка в содержании обязательного информационного элемента
							Сообщение несовместимо с состоянием протокола защиты
							Повторение обязательного информационного элемента
							Слишком много информационных элементов

Протокол защиты V5.2 предусматривает один тип сообщения об ошибке в протоколе — сообщение PROTOCOL_ERROR, которое передается от сети доступа к АТС и содержит информационный элемент Protocol-error-cause (Причина-ошибки-в-протоколе), указы­вающий тип ошибки. Типы ошибок приведены в таблице 8.9. Как и все типы сообщений переключения, сообщения PRO­TOCOL_ERROR последовательно нумеруются с использованием информационного элемента «Порядковый-номер». Подобно со­общениям отказа в переключении, они должны указывать на про­исхождение проблемы, но, в отличие от сообщений отказа в пере­ключении, не должны идентифицировать канальный интервал.

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