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

Рассмотрены основные протоколы распределение меток – LDP, его расширение CR-LDP, протокол RSVP-TE.

Протокол LDP

Классы эквивалентности пересылки и LDP

Понятие класс эквивалентности пересылки FEC уже обсуждалось в предыдущих главах. Там же говорилось о том, что для переноса через сеть MPLS пакетов, принадлежащих разным FEC, в сети создаются виртуальные тракты LSP, и было показано, как с помощью метки MPLS устанавливается соответствие " пакет- FEC ", определяющее, по какому LSP должен быть направлен пакет с этой меткой. В этой главе речь пойдет о том, каким образом производится распределение меток по всем LSR сети MPLS с использованием протокола LDP (Label Distribution Protocol).

В спецификации LDP к настоящему моменту установлены два типа элементов, с помощью которых может определяться FEC:

· Address Prefix – адресный префикс любой длины от нуля до полного адреса;

· Host Address – полный адрес хоста.

· Решения о назначении меток могут основываться на критериях пересылки, таких как:

· одноадресная маршрутизация к получателю;

· оптимизация распределения трафика в сети;

· многоадресная рассылка;

· виртуальная частная сеть VPN;

· механизмы обеспечения качества обслуживания QoS и др.

Спецификация же протокола LDP определяет правила, по которым устанавливается соответствие между входным пакетом и его LSR.

Для распределения меток могут использоваться разные методы:

· метод на основе топологии (topology-based method); использует стандартную обработку протоколов маршрутизации (например OSPF и BGP, рассматриваемых ниже);

· метод на основе запросов (request-based method); использует обработку управляющего протокола на основе запросов (например, протокола RSVP);

· метод на основе трафика (traffic-based method); запускает процедуру присвоения и распределения меток при получении пакета.

Во всех этих случаях архитектурой MPLS предусматривается, что назначение метки, то есть ее привязку к определенному FEC, производит LSR, который является выходным пограничным маршрутизатором для пакетов этого FEC (рис. 4.13).

Рис. 4.13. Фрагмент MPLS-сети

Таким образом, назначение меток всегда производится снизу, то есть в сторону, противоположную направлению трафика. Нижний LSR информирует соседние верхние LSR о том, какие метки он привязал к каждому FEC поступающих к нему пакетов. Этот процесс и называется распределением меток, а обеспечивает его протокол распределения меток.

Архитектура MPLS не требует обязательного применения LDP. Для распределения меток могут применяться модификации существующих протоколов маршрутизации, позволяющие использовать их для передачи информации о метках, например рассматриваемый протокол BGP, RSVP, который рассматривается ниже, также имеет расширения, обеспечивающие поддержку обмена метками с уведомлением.

Но все же протокол распределения меток LDP был признан комитетом IETF наиболее удачным и, что еще важнее, хорошо специфицирован им. Кроме того, определено расширение базового протокола LDP для поддержки явной маршрутизации с учетом обеспечения качества обслуживания я QoS и управления трафиком ТЕ – протокол LDP с учетом ограничивающих условий CR-LDP(Constraint-Based LDP). Ко всему прочему LDP устанавливает надежные транспортные соединения со смежными маршрутизаторами LSR по протоколу TCP, причем в случае, если между двумя LSR надо одновременно установить несколько LDP -сеансов, используется единственное TCP-соединение.

Имеются следующие схемы обмена метками:

LDP преобразует в метки IP-адреса получателя при одноадресной передаче;

RSVP и CR-LDP используются для оптимизации распределения трафика в сети и для резервирования ресурсов;

BGP работает с внешними метками VPN.

RSVP для MPLS

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

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

Роль RSVP и RSVP-ТЕ в MPLS

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

В расширенной версии протокола, описанной в RFC 3209 " Extensions to RSVP for LSP Tunnels" и получившей название RSVP-ТЕ, определен новый объект LABEL, который переносится в сообщении Resv. Таким образом, RSVP становится инструментом для распределения меток MPLS. Когда маршрутизатору LSR нужно передать сообщение Resv для нового потока, он выбирает из своего пула свободную метку, создает запись в своей таблице LIB, определяя выбранную метку как входящую, и затем передает сообщение Resv, содержащее эту метку в объекте LABEL. Следует отметить, что, поскольку сообщения Resv идут от получателя к отправителю, это – разновидность распределения меток снизу.

При получении сообщения Resv, содержащего метку потока, маршрутизатор записывает ее в своей базе LIB как исходящую, назначает для данной исходящей метки входящую и пересылает ее вышестоящему LSR. Таким образом, по пути распространения сообщения создается тракт LSP. Поскольку в сообщениях Resv указываются метки, каждый LSR может легко связать соответствующие ресурсы QoS с трактом LSP. Протокол RSVP, расширенный объектом LABEL, может создать тракт LSP только вдоль маршрута, вычисленного схемой традиционной маршрутизации пакетов IP. Причина в том, что при использовании обычного протокола RSVP путь, по которому идет сообщение Path, управляется парадигмой пересылки на основе пункта назначения, а маршрут, по которому идет сообщение Path, задает путь LSP. Когда маршрутизатор должен переслать сообщение Path, он для определения следующего маршрутизатора, к которому он должен переслать сообщение, использует имеющуюся у него таблицу маршрутизации, которая формируется с помощью таких протоколов, как IS-IS, OSPF, RIP или BGP, и адрес получателя, содержащийся в заголовке IP-пакета. При этом отсутствует способность " управлять" сообщением Path, отправляя его вдоль конкретного, явно заданного маршрута.

Для возможности задания явного маршрута в протокол RSVP-TE ввели еще один объект – Explicit Route Object (ERO). ERO содержит последовательность маршрутизаторов, представляющую собой явно заданный маршрут, и включается в сообщении Path. В ответ на это сообщение по данному маршруту передается сообщение Resv, благодаря чему резервируются ресурсы сети и устанавливается путь LSP.

Поскольку трафик, проходящий по LSP, определяется меткой, присвоенной на входном маршрутизаторе, то данный путь можно считать своеобразным туннелем, находящемся под уровнем IP-маршрутизации, причем трафик, идущий по нему, непрозрачен для промежуточных узлов. Таким образом, появилось понятие LSP-туннеля.

Управление трафиком в MPLS

Протокол MPLS стратегически достаточен для управления трафиком, и существует возможность автоматизировать функции такого управления. Для этого сигнальные протоколы MPLS должны переносить информацию, которая необходима для работы механизмов управления трафиком, находящихся на прикладном уровне, а также создавать LSP с явно заданными маршрутами. При этом есть возможность получить дополнительную гибкость, если маршрут может быть задан как строго, так и не строго, т.е. если группа узлов может быть задана как " абстрактный узел", в рамках которого существует известная свобода выбора маршрута.

Перед IETF, точнее, перед ее рабочей группой MPLS, возникла задача выбора такого протокола. Лучшими оказались два варианта:

· RSVP-TE;

· CR-LDP.

В первом варианте протокол RSVP должен делать в сети MPLS то же, что он делает в сетях IP, а именно – обрабатывать информацию, связанную с QoS, и резервировать ресурсы. Необходимо лишь добавить к этому возможности распределения меток. Во втором варианте в протокол LDP добавлено несколько новых объектов, обеспечивающих перенос информации о QoS.

4.5. Контрольные вопросы

1. Перечислите основные модели обеспечения качества обслуживания в сетях IP. Опишите базовые принципы модели QoS Intserv,

2. Перечислите основные модели обеспечения качества обслуживания в сетях IP. Опишите базовые принципы модели QoS Diffserv

3. Приведите пример типового механизма управления качеством в пакетных сетях.

4. Опишите базовые принципы функционирования мультипротокольной коммутации по меткам (MPLS). В чем преимущество такого подхода для обеспечения качества передаваемых данных

5. Проиллюстрируйте принципы применения RSVP в QoS Intserv, MPLS TE LSP

⇐ Предыдущая 12 13 14 15 16 171819 20 21 Следующая ⇒