 |
Транспортировка сообщений защиты 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, Resource 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 в пункт назначения.
|
|
|
|
