Классы эквивалентности пересылки и 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 – нижний или нижестоящий LSR, а расположенный "выше по течению" LSR – верхний или вышестоящий LSR (рис. 11.1).
Рис. 11.1. Фрагмент 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.
Основы протокола LDP
В связи с тем, что протокол LDP тесно взаимодействует с протоколами внутренней маршрутизации IPG, его часто называют протоколом пересылки по участкам.
Протокол распределения меток LDP представляет собой набор процедур и сообщений, при помощи которых LSR организует тракты коммутации по меткам, обмениваясь информацией о привязке меток в FEC с "соседними" LSR, поддерживает и прекращает LSP-сеансы (двусторонний диалог взаимодействующих LSR, являющихся в данном контексте одноранговыми узлами LDP, в ходе которого каждый из взаимодействующих LSR получает сведения о привязке меток к FEC в другом LSR).
Также в протоколе определен механизм передачи уведомлений и обнаружения в LSP закольцованных маршрутов, уже обсуждавшийся ранее.
Процедуры протокола LDP позволяют LSR, выполняющему этот протокол, создавать тракты LSP. Конечной точкой такого тракта является либо смежный LSR, имеющий прямую связь с данным LSR, либо выходной LSR, доступный этому LSR через некоторое количество транзитных LSR. Процессы обнаружения конечных точек этих двух типов называются соответственно процессом базового обнаружения и процессом расширенного обнаружения. LDP создает двустороннюю связь двух смежных LSR, которые становятся одноранговыми узлами LDP, взаимодействующими друг с другом посредством LDP-сеанса.
При обмене между LSR информацией, связанной с привязкой "метка-FEC", используются четыре категории сообщений LDP:
сообщения обнаружения (discovery messages), используемые для того, чтобы объявить и поддерживать присутствие LSR в сети; сеансовые сообщения (session messages), предназначенные для создания, поддержки и прекращения LDP-сеансов между LSR; сообщения-объявления (advertisement messages), используемые для создания, изменения и отмены привязки метки к FEC; уведомляющие сообщения (notification messages), содержащие вспомогательную информацию и информацию об ошибках.
Хотя "раздает" метки всегда нижний LSR, инициатором их распределения не обязательно должен быть он; процесс может инициировать и верхний LSR, направив к нижнему LSR соответствующий запрос; такой режим называется downstream on-demand.
В той или иной сети может использоваться распределение меток либо только по запросам сверху, либо только по инициативе нижнего LSR (unsolicited downstream), либо и то и другое вместе.
распределение меток может быть независимым или упорядоченным. В первом случае LSR может уведомить вышестоящий LSR о привязке метки к FEC до того, как получит информацию о привязке от нижестоящего LSR. Во втором случае высылать подобное уведомление "наверх" разрешается только после получения таких сведений "снизу".
Нижний LSR распределяет метки не только по тем верхним LSR, которые имеют с ним прямые связи. Протокол распределения меток может быть использован и для диалога двух LSR, между которыми существует лишь коммутируемая связь, однако результат распределения в этом случае зависит от того, в каком из двух режимов, либеральном или консервативном, работает верхний LSR.
Консервативный режим распределения меток – в этом режиме сообщения-объявления о привязке "метка-FEC", получаемые от несмежных LSR, не принимаются и отбрасываются. LSR привязывает метку к FEC только в том случае, если он является выходным маршрутизатором или если он получил сообщение о привязке от смежного с ним LSR. Такой режим позволяет LSR обслуживать меньшее число меток.
Либеральный режим распределения меток – в этом режиме привязка метки, выданная тем нижним LSR, с которым нет прямой связи, запоминается и используется. Такой режим удобен тем, что при реконфигурации сети соответствие между меткой и FEC сохраняется, даже если связь с LSR, определившим это соответствие, стала не коммутируемой, а прямой. Недостаток либерального режима состоит в том, что в верхнем LSR приходится хранить и обрабатывать заметно больше информации о соответствии между метками и FEC.
Как уже говорилось, метка всегда локальна, то есть обозначает некоторый FEC только для пары маршрутизаторов, между которыми имеется прямая или коммутируемая связь, и используется при пересылке пакетов этого FEC от того из маршрутизаторов данной пары, который является в ней верхним (upstream LSR), к тому, который является нижним (downstream LSR).
Для пересылки пакетов того же FEC к следующему маршрутизатору используется другая метка, идентифицирующая этот FEC для новой пары маршрутизаторов, в которой маршрутизатор, бывший в предыдущей паре нижним, приобретает статус верхнего, а статус нижнего получает второй маршрутизатор этой новой пары. Отсюда ясно, что каждый маршрутизатор MPLS-сети должен хранить соответствие между входящими и исходящими метками для всех FEC, которыми он оперирует.
Одной из важнейших функций протокола LDP является обнаружение петель. Для этой цели можно использовать два поля в сообщениях Label Request и Label mapping, а именно Path Vector и Hop Count.
Поле Path Vector содержит список LSR-идентификаторов (первые 4 октета LDP-идентификатора), принадлежащих тем LSR, через которые прошло содержащее его сообщение. Если LSR получает сообщение и обнаруживает в поле Path Vector свой собственный LSR-идентификатор, он "понимает", что возникла петля. В протоколе LDP предусматривается возможность задать максимально допустимое значение поля Path Length, по достижении которого тоже принимается решение о возникновении петли.
Второй вариант — поле Hop Count, которое содержит счетчик LSR, пройденных сообщением LSR. Каждый пройденный LSR увеличивает его значение на единицу. Маршрутизатор, обнаруживший, что счетчик достиг максимально допустимой величины, обрабатывает сообщение как сделавшее петлю.
Протокол CR-LDP
Протокол LDP может следовать только таблицам маршрутизации IP. Чтобы преодолеть ограничение, было предложено расширение LDP, названное CR-LDR.
Протокол 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 и 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-туннеля.
RSVP для MPLS
RSVP, как и DiffServ, не найдя широкого самостоятельного применения, успешно влился в технологию MPLS, способствуя, наряду с CR-LDP, улучшению ее характеристик. Протокол RSVP был изучен в предыдущих лекциях, а здесь рассмотрим применение протокола RSVP и его расширения RSVP-TE в MPLS.
Первой из двух функций, возложенных на RSVP технологией MPLS, является распределение меток (вместо протокола LDP). Вторая, традиционная для RSVP роль заключается в поддержании QoS в сети MPLS. Вне зависимости от используемого протокола распределения меток, маршрутизаторы LSR должны согласовать между собой параметры QoS для каждого FEC. Метки позволяют определить огромное число классов QoS, но реально в типичных мультисервисных сетях, даже при очень большом количестве классов FEC, будут существовать, как правило, всего несколько классов QoS.
Управление трафиком в MPLS
Протокол MPLS стратегически достаточен для управления трафиком, и существует возможность автоматизировать функции такого управления. Для этого сигнальные протоколы MPLS должны переносить информацию, которая необходима для работы механизмов управления трафиком, находящихся на прикладном уровне, а также создавать LSP с явно заданными маршрутами. При этом есть возможность получить дополнительную гибкость, если маршрут может быть задан как строго, так и не строго, т.е. если группа узлов может быть задана как "абстрактный узел", в рамках которого существует известная свобода выбора маршрута.
Перед IETF, точнее, перед ее рабочей группой MPLS, возникла задача выбора такого протокола. Лучшими оказались два варианта:
RSVP-TE;CR-LDP.
В первом варианте протокол RSVP должен делать в сети MPLS то же, что он делает в сетях IP, а именно – обрабатывать информацию, связанную с QoS, и резервировать ресурсы. Необходимо лишь добавить к этому возможности распределения меток. Во втором варианте в протокол LDP добавлено несколько новых объектов, обеспечивающих перенос информации о QoS.
На сегодняшний день оба протокола достаточно развиты.
Механизмам ТЕ (Traffic Engineering) в MPLS будет посвящена часть лекции 13, в которой будут рассмотрены варианты и примеры использования разных механизмов управления трафиком в MPLS.
