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

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

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


Читайте также:
  1. CONGESTION_CONTROL. Это сообщение используется для управления потоком сообщенийUSER_INFORMATION.
  2. III. Электронный блок управления
  3. Quot;Звезда Смерти", капитанский мостик, центр управления
  4. Quot;Звезда Смерти", капитанский мостик, центр управления
  5. Quot;Звезда Смерти", капитанский мостик, центр управления
  6. Quot;Звезда Смерти", капитанский мостик, центр управления
  7. Quot;Звезда Смерти", сектор "тета", пост управления суперлазером

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

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

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

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

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

В сообщениях протокола управления трактами интерфейса 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.

Рис. 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. Сценарий запроса блокировки тракта

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

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


Дата добавления: 2015-11-04; просмотров: 70 | Нарушение авторских прав


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

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