Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АрхитектураБиологияГеографияДругоеИностранные языки
ИнформатикаИсторияКультураЛитератураМатематика
МедицинаМеханикаОбразованиеОхрана трудаПедагогика
ПолитикаПравоПрограммированиеПсихологияРелигия
СоциологияСпортСтроительствоФизикаФилософия
ФинансыХимияЭкологияЭкономикаЭлектроника

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

ФОРМАТЫ СООБЩЕНИЙ УРОВНЯ 3 | МУЛЬТИПЛЕКСИРОВАНИЕ ПОРТОВ ISDN | ПРОБЛЕМА ТфОП | ИНФОРМАЦИОННЫЕ ЭЛЕМЕНТЫ СООБЩЕНИЙ ПРОТОКОЛА ТфОП | СООБЩЕНИЯ ПРОТОКОЛА ТфОП | ПРОТОКОЛ ТфОП НА СТОРОНЕ СЕТИ ДОСТУПА | ПРОТОКОЛ ТфОП НА СТОРОНЕ АТС | ПРОЦЕДУРЫ ПРОТОКОЛА ТфОП | НАЦИОНАЛЬНЫЕ СПЕЦИФИКАЦИИ ПРОТОКОЛА ТфОП | ПРОТОКОЛ НАЗНАЧЕНИЯ НЕСУЩИХ КАНАЛОВ |


Читайте также:
  1. VIII. ТЕОРЕТИКО-ИНФОРМАЦИОННАЯ КОНЦЕПЦИЯ КРИПТОЗАЩИТЫ СООБЩЕНИЙ В ТЕЛЕКОММУНИКАЦИОННЫХ СИСТЕМАХ
  2. XI. Проектирование, устройство и эксплуатация молниезащиты складов взрывчатых материалов
  3. Автор Неизвестен. Протоколы Сионских Мудрецов
  4. Активные формы кислорода и система антиоксидантной защиты
  5. Антителозависимые механизмы защиты от патогена
  6. АРХИТЕКТУРА ПРОТОКОЛА Х.25
  7. АРХИТЕКТУРАПРОТОКОЛАХ.25

В первый раз в этой книге протокол защиты был упомянут в четвертой строке таблицы 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; просмотров: 98 | Нарушение авторских прав


<== предыдущая страница | следующая страница ==>
ПРОТОКОЛ УПРАВЛЕНИЯ ТРАКТАМИ ИНТЕРФЕЙСА V5.2| ПРОТОКОЛ УПРАВЛЕНИЯ

mybiblioteka.su - 2015-2024 год. (0.006 сек.)