Роль 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 для нового потока, он выбирает из своего пула свободную метку, создает запись в своей таблице LFIB, определяя выбранную метку как входящую, и затем передает сообщение 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-туннеля.