Файл: 8.doc

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

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

В дополнение к проверке ярлыков и целостности самих трак­тов, должна обеспечиваться возможность перевода трактов в со­стояния «рабочее» и «нерабочее».

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

Структура сообщения протокола управления трактами интер­фейса V5 представлена на рис. 8.3. Информационный элемент «Тип сообщения» в заголовке определяет сообщение как управляющее — LINK_CONTROL или как подтверждающее - LINK_CONT-ROL_ACK. Строго говоря, сообщения второго типа LINK_CONT-ROL_ACK не являются, по мнению автора, необходимыми (даже при разблокировке тракта, о чем будет сказано в конце этого пара­графа), поскольку эту функцию выполняет уровень 2 протокола.

Рис. 8.3. Структура сообщения протокола управления трактами

244 Глава 8 ___________

В сообщениях протокола управления трактами интерфейса V5.2 имеется единственный специализированный обязательный информационный элемент «Функция управления трактом» (Link-control-function).

Операцию идентификации тракта может инициировать лю­бая сторона интерфейса с помощью передачи сообщения LINK_ CONTROL: Link-identification-request (запрос-идентификации-тракта). Если сигнал маркировки принимается стороной, запро­сившей идентификацию, по тракту с ярлыком, который соответ­ствует ярлыку передающей стороны, маркировка считается верной, тракт идентифицирован, его целостность проверена. Так как за­просить идентификацию может любая сторона интерфейса, воз­можны конфликтные ситуации при передаче одного и того же сиг­нала более чем по одному тракту одновременно. В идеале, для раз­ных интерфейсов следовало бы применять разные сигналы мар­кировки во избежание путаницы при одновременном тестирова­нии нескольких интерфейсов, но в интерфейсе V5.2 это не реали­зовано, поскольку вероятность случайного возвращения сигнала маркировки по исправному тракту другого интерфейса незначи­тельна.

Сторона, которая принимает запрос идентификации, может отказать в удовлетворении запроса. Это может произойти, если, например, продолжается обработка предыдущего запроса иденти­фикации тракта, поскольку спецификации интерфейса V5 не предусматривают идентификацию более одного тракта одновремен­но. Отказ удовлетворить запрос производится путем передачи со­общения LINK_CONTROL: Link-identification-rejection (отказ-в-идентификации-тракта). Сценарий идентификации тракта пред­ставлен на рис. 8.4.

Если запрос принимается приемной стороной для выполне­ния, то она маркирует указанный тракт и отвечает сообщением LINK_CONTROL: Link-identification-acknowledgement, подтвер­ждающим выполнение запроса. Маркировка тракта производится присвоением значения 0 биту 7 в нулевом канальном интервале этого тракта.

Когда сторона, давшая запрос, получила подтверждение и проверила маркировку, она может запросить удаление маркиров­ки с помощью сообщения LINK_CONTROL: Link-identification-release. Получив такое сообщение, другая сторона удаляет марки­ровку. Удаляется маркировка присвоением биту 7 нулевого каналь­ного интервала значения 1.

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

Рис. 8.4. Сценарий обмена сообщениями идентификации тракта

Сеть доступа может запросить у станции блокировку тракта путем передачи сообщения LINK_CONTROL: Deferred-link-block-ing-request (запрос-блокировки-тракта-с-отсрочкой) или сообщения LINK_CONTROL: Non-deferred-link-blocking-request (запрос-блоки-ровки-тракта-без-отсрочки). Сообщение LINK_CONTROL: De­ferred-link-blocking-request менее срочное, оно указывает, что сеть доступа готова ждать, пока АТС переключит С-каналы на другой тракт и пока завершатся текущие связи пользователей. Сообщение LINK_CONTROL: Non-deferred-link-blocking-request более срочное, оно указывает, что сеть доступа не может ждать, пока завершатся текущие связи и пока станция переключит С-каналы на другой тракт (рис. 8.5). Если в тракте нет С-каналов, вместо сообщения LINK_CONTROL: Non-deferred-link-blocking-request можно исполь­зовать сообщение LINK_CONTROL: Link-block, но это не рекомен­дуется, т.к. безопаснее дать АТС некое предупреждение о намере­нии, прежде чем указывать, что тракт недоступен.

Рис. 8.5. Сценарий запроса блокировки тракта

246 Глава 8_______________________________________

АТС не должна запрашивать блокировку тракта у сети досту­па, поскольку станции известно, происходит ли обслуживание вы­зовов, и она может управлять использованием канальных интерва­лов интерфейса V5. Если АТС принимает решение заблокировать тракт, она может использовать рассматриваемый в следующем па­раграфе протокол защиты для переключения С-каналов на каналь­ные интервалы другого тракта, а также может использовать рассмот­ренный в предыдущем параграфе протокол назначения несущих каналов ВСС, чтобы гарантировать, что никакие пользовательские порты не используют несущие канальные интервалы тракта, кото­рый предполагается заблокировать. После завершения всех текущих связей пользователей АТС может передать сообщение LIN K_CONT-ROL: Link-block, информирующее сеть доступ а о том, что тракт за­блокирован.

При разблокировке ранее заблокированного тракта приме­няется процедура координированной разблокировки, поскольку сеть доступа и АТС автономны и могут независимо выполнять функции техобслуживания, а протоколы V5 не дают возможность одной стороне информировать об этом другую. Когда одна из сто­рон предполагает разблокировать тракт, она передает другой сто­роне сообщение LTNK_CONTROL: Link-unblock. Если другая сто­рона согласна разблокировать тракт, она отвечает таким же сооб­щением LINK_CONTROL: Link-unblock.

8.3. ПРОТОКОЛ ЗАЩИТЫ V5.2

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

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

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

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

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

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