Файл: Book2 Full.doc

Более детальная информация о протоколе ВСС и его процедурах содержится в приложении Е стандарта ETS 300 347-1.

8.2. Протокол управления трактами интерфейса v5.2

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

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

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

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

В сообщениях протокола управления трактами интерфейса V5.2 имеется единственный специализированный обязательный информационный элемент «Функция управления трактом» (Linkcontrol-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-identificationrelease. Получив такое сообщение, другая сторона удаляет маркировку. Удаляется маркировка присвоением биту 7 нулевого канального интервала значения 1.

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

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

При разблокировке ранее заблокированного тракта применяется процедура координированной разблокировки, поскольку сеть доступа и АТС автономны и могут независимо выполнять функции техобслуживания, а протоколы V5 не дают возможность одной стороне информировать об этом другую. Когда одна из сторон предполагает разблокировать тракт, она передает другой стороне сообщение LINK_CON7 ROL: 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. В случае подобных отказов, соединения пользователей, организованные через эти несущие каналы, будут нарушены, что считается приемлемым, поскольку вероятность подобных отказов мала.

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