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

Роль 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.

На сегодняшний день оба протокола достаточно развиты.

Механизмам ТЕ (Traffic Engineering) в MPLS будет посвящена часть "Инжиниринг трафика. Виртуальные частные сети" , в которой будут рассмотрены варианты и примеры использования разных механизмов управления трафиком в MPLS.