Транспортировка сообщений защиты LSP

 

Защита LSP предполагает транспортировку сообщений в новом объекте (пакете данных) (рис. 5.61). Эти сообщения используются для описания атрибутов защиты канала, запрошенного LSP. В сообщении указывается на желательный тип защиты канала LSP. Запрашиваемый конкретный тип защиты (например, 1+1 или 1:N) мо­жет реализоваться только при наличии ресурса.

 

Сообщение указывает также, является ли данный LSP первичным или вторич­ным (резервным). Вторичный LSP считается резервным по отношению к первично­му LSP. Ресурсы вторичного LSP не используются до тех пор, пока работает пер­вичный LSP. Ресурсы, выделенные для вторичного LSP, могут использоваться дру­гими LSP до тех пор, пока первичный LSP не откажет. В такой ситуации любой LSP, который использует ресурсы вторичного LSP, должен быть отключен до уст­ранения повреждения.

Когда бит S (рис. 5.61) равен единице, то это указывает на то, что запрашивае­мый LSP вторичный. Флаги канала (6 битов) отмечают желательный тип защиты канала. Возможности защиты могут закладываться при маршрутизации. Значение ноль во всех битах флага указывает на возможность любой защиты, включая её от­сутствие.

Определены флаги следующих типов защиты:

- улучшенная защита, указывает на то, что следует использовать надежную схе­му, например, 4-волоконную схему MS-SPRing;

-выделенная защита 1+1, указывает, что для LSP следует использовать выде­ленную схему защиты канального уровня 1+1;

-выделенная защита 1:1, указывает, что для LSP следует использовать выде­ленную схему защиты канального уровня 1:1;

- совместная защита 1:N, указывает на то, что для LSP следует использовать со­вместную схему защиты канального уровня 1:N;

- не защищено, указывает на то, что LSP не должно использовать средства за­щиты;

- дополнительный трафик, указывает, что LSP должен использовать другие ка­налы, которые защищают другой первичный трафик; такие LSP могут быть разорваны, когда отказывают каналы с защищенным трафиком.

Метками может транслироваться информация административного состояния (тестирования, ликвидации соединения и т.д.).

Непосредственно механизмы сигнальных взаимодействий могут быть реализо­ваны через протоколы, например, RSVP-TE и CR-LDP.

 

 

Механизм сигнализации с использованием протокола

RSVP - TE

 

Протокол резервирования ресурсов — проектирования трафика (RSVP-TE, Re­source Reservation Protocol — Traffic Engineering) является частью спецификаций интерфейсов UNI и E-NNI. Этот протокол сигнализации используется для соедине­ний контроллера вызова в интерфейсе UNI, контроллера соединения (PC) и адми­нистратора ресурсов линии (LRM). Адресация транспортных ресурсов в этом про­токоле производится идентификаторами пункта пула подсети SNPP (Subnetwork Point Pool). Пара таких идентификаторов определяет звено связи SNPP. Имена SNPP определяются из пространства транспортных имен, к которым относятся: имена транспортных ресурсов интерфейса UNI (виртуального канала, сцепленного соединения на основе VC-X-Xv, оптического канала ОСЬ и т.д.), блоков управле­ния и ввода адреса сигнализации, подсети, контроллера соединения и т.д. При этом контроллер маршрутизации и идентификаторы управления соединением не исполь­зуются для создания имен звеньев связи.

В описание основных процедур протокола RSVP-TE входят собственно проце­дуры, сообщения и форматы объектов для передачи сигнальной информации по се­ти пакетами IP. Описание протокола RSVP-TE включает дополнительные сообще­ния (рис. 5.62).

 

Расширением протокола RSVP-TE являются объект для наращивания поля имен от А до Z и также спецификации CoS и GoS для поддержки запросов на услу­ги интерфейса UN1.

Формат сообщений GMPLS RSVP-TE основан на базовой структуре пакета дан­ных, определенной в документах RFC 2205, RFC 2961, RFC 3209, RFC 3474 (рис. 5.63). К этому формату добавляются необходимые объекты сигнальных сооб­щений (на рис. 5.63 не обозначены), например, в которых записан идентификатор оператора сети, идентификатор вызова, адрес элемента исходной транспортной сети и т.д. Сообщение RSVP состоит из заголовка и некоторого количества объектов, ха­рактерных для каждого типа сообщений. Типы сообщений кодируются: 1 — Path; 2 — Resv; 3 — Path Err; 5 — Path Tear; 7 — Resv Conf; 13 — Ack; 15 — Srefresh; 20 — Hello; 21 — Notify. В поле «версия» указывается версия протокола RSVP-TE. В поле «флаги» отмечается групповая или индивидуальная рассылка сообщения. Поле «контрольная сумма RSVP» предназначено для обнаружения ошибок. В поле «пара­метры передачи» передаётся сообщение о необходимом QoS. В поле «длина RSVP» фиксируется общее число байтов всего пакета с основной частью и объектами.

 

Типы сообщений имеют следующее назначение:

Path используется для инициирования запросов на установление соединения, на разъединение, промежуточного в направлении вызова запроса на разъединение, от­вета на сообщение Resv;

Resv используется для ответа на запрос об установлении соединения с сообщени­ем Path, при инициировании запроса на разъединение от получателя вызова и т.д.;

Resv Conf используется для ответа на запрос об установлении соединения Resv;

Path Tear используется для ответа на запрос о разъединении Resv, ответа на со­общение Path Err во время операций установки и разъединения и т.д.;

Path Err используется для ответа на запрос об установлении соединения Path, если это соединение не может быть установлено, для ответа на запрос о разъедине­нии Path, для отправки сообщения о неудачной операции установки соединения, для отправки сообщения о неудачной операции разъединения;

Notify используется для того, чтобы асинхронно уведомлять контроллер соеди­нения об ошибках при соединении;

Hello используется для обеспечения сеанса резервирования RSVP и иницииро­вания процедуры перезагрузки;

Аск используется в качестве уведомления об отправке сообщения;

Srefresh используется для обновления состояния сообщения RSVP-TE без пере­дачи сообщений Path и Resv, что приводит к уменьшению количества передаваемой информации для поддержания синхронизма вызова и соединения;

Использование рассмотренных сообщений иллюстрируется общим описанием потока сигнальных сообщений для процедуры настройки (рис. 5.64):

- сообщение о пути (Path) для запрашиваемого соединения отправлено от ис­ходного пункта к пункту назначения;

- после приема сообщения Path пунктом назначения между исходным пунктом и пунктом назначения устанавливается сеанс резервирования ресурсов RSVP;

- пункт назначения отвечает на сообщение Path одним из двух сообщений в об­ратном направлении (Resv — при нормальной настройке сети и Path Err — при ошибке процедуры настройки);

- после приема исходным пунктом сообщения Resv может быть отправлено до­полнительное сообщение Resv Conf в пункт назначения.