Протоколы распределения меток

Протокол CR-LDP

Протокол LDP может следовать только таблицам маршрутизации IP. Чтобы преодолеть ограничение, было предложено расширение LDP, названное CR-LDP.

Протокол CR-LDP является вариантом LDP, в котором определены механизмы создания и поддержания трактов LSP с явно заданным маршрутом. Для создания тракта CR-LSP используется больше информации, чем можно получить от традиционных протоколов внутренней маршрутизации. CR-LDP применяется для таких приложений MPLS, как ТЕ (Traffic Engineering) – управление трафиком и QoS, где требуется дополнительная информация о маршрутах. В этом протоколе запрос метки может не следовать слепо вдоль дерева маршрутизации для данного адресата, т.к. предусмотрена возможность точно сообщить, как он должен следовать, включив в сообщение явно заданный маршрут. При этом программное обеспечение CR-LDP не использует для маршрутизации таблицы пересылки, а маршрутизирует запрос в соответствии с содержащимися в сообщении инструкциями.

Протокол CR-LDP не поддерживает динамического вычисления явно задаваемых маршрутов, поэтому сведения о динамическом резервировании пропускной способности должны включаться в вещательную информацию протоколов OSPF или IS-IS, или в извещения о состоянии каналов LSA. Используя эти механизмы, CR-LDP может занимать и резервировать пропускную способность. Доступная пропускная способность изменяется в соответствии с запросом, и ее новое значение рассылается другим узлам с помощью расширений протоколов OSPF и IS-IS, которые будут рассмотрены ниже.

В результате протокол CR-LDP получает в свое распоряжение явный маршрут для организации LSR. Тракт создается посредством сообщения запроса метки, содержащего динамически вычисляемый явный маршрут.

Протокол CR-LDP имеет также другие, новые по сравнению с базовой версией LDP функциональные возможности:

• явная маршрутизация с точно определенными и свободными маршрутами, при которой маршрут задается в виде последовательности групп узлов. В том случае, если в группе указано более одного маршрутизатора, при создании явного маршрута возможна определенная гибкость;
• спецификация параметров трафика (например пиковая скорость передачи, гарантированная скорость передачи и допустимая вариация задержки);
• закрепление маршрута (route pinning), которое может использоваться в тех случаях, когда изменять трассу LSP нежелательно, например, в сегментах со свободной маршрутизацией, когда в этом сегменте становится доступным лучший маршрут;
• механизм приоритетного вытеснения LSP с помощью системы приоритетов создания и удержания. Ранжируются существующие тракты LSP (приоритет удержания) и новые тракты LSP (приоритет создания) с тем, чтобы определить, может ли новый LSP вытеснять существующий LSR. Для приоритетов предложен диапазон значений от 0 (высший приоритет) до 7 (низший приоритет);
• введены новые коды состояний LSR;
• введен LSPID – уникальный идентификатор тракта CR-LSP в сети;
• введены классы (цвета) сетевых ресурсов, назначаемые администратором сети.

Хотя CR-LDP обладает довольно широкими возможностями инжиниринга трафика (ТЕ – Traffic Engineering) в сетях MPLS и не требует реализации в оборудовании дополнительного протокола, а лишь расширения уже существующего, но в самое последнее время по ряду косвенных данных прослеживается сворачивание работ над CR-LDP в IETF в пользу протокола RSVP-TE.

RSVP для MPLS

RSVP, как и DiffServ, не найдя широкого самостоятельного применения, успешно влился в технологию MPLS, способствуя, наряду с CR-LDP, улучшению ее характеристик. Протокол RSVP был изучен в предыдущих лекциях, а здесь рассмотрим применение протокола RSVP и его расширения RSVP-TE в MPLS.

Первой из двух функций, возложенных на RSVP технологией MPLS, является распределение меток (вместо протокола LDP ). Вторая, традиционная для RSVP роль заключается в поддержании QoS в сети MPLS. Вне зависимости от используемого протокола распределения меток, маршрутизаторы LSR должны согласовать между собой параметры QoS для каждого FEC. Метки позволяют определить огромное число классов QoS, но реально в типичных мультисервисных сетях, даже при очень большом количестве классов FEC, будут существовать, как правило, всего несколько классов QoS.