Операторы связи и большие корпорации, оценившие все достоинства MPLS, вынуждены мириться с несколькими control plane протоколами в своей сети. IGP+LDP стал де-факто стандартом в ядре сети. Вместе с этим известно, что протокол OSPF расширяем за счет opaque LSA, протокол IS-IS уже много лет успешно расширяется добавлением новых TLV. А что если добавить MPLS метку непосредственно в IGP? И можно ли избавиться от не слишком гибкого RSVP? Приверженцев оптимизации прошу под кат.


В статье не рассматриваются основы MPLS, и автор рассчитывает на то, что читатель как минимум неплохо ориентируется в терминологии.

Что не так с LDP и RSVP? Во-первых, это дополнительный control plane протокол, который должен тесно и в правильном порядке взаимодействовать с IGP. Отсюда ldp igp sync в терминологии Cisco и прочие замечательные техники управления взаимодействием IGP-LDP. Неправильно сконфигурированный интерфейс может привести к сбросу трафика. Такие проблемы не всегда легко диагностировать и исправить. Во-вторых, любой control plane протокол потребляет ресурсы оборудования. В частности для классического IOS дополнительные процессы опасны еще и тем, что вся ОС работает в одном пространстве памяти. Другими словами, segfault в одном приложении может привести к крэшу всего устройства. В теории. На самом деле LDP и RSVP у большинства вендоров работают хорошо и стабильно. Но мы, как заядлые оптимизаторы, конечно же, хотели бы от них избавиться. Стоит сказать, что с точки зрения форвардинга segment routing может быть реализован с использованием протоколов MPLS и IPv6. Речь пойдет исключительно о forwarding plane с MPLS.

Избавляемся от LDP

Рабочая группа SPRING предложила переложить функции протоколов распространения меток на IGP, а LSP строить сегментами. Сегмент представляет собой часть (или весь) LSP до конкретного маршрутизатора. Для назначения меток используется выделенный диапазон, чтобы не пересекаться с классическими протоколами. Его называют SRGB — segment routing global block. Этот блок может отличаться на разных устройствах, хотя при возможности лучше использовать одинаковый, чтобы окончательно не запутаться. Однако метка для достижения конкретного PE при этом должна быть уникальной. При этом метка на всем сегменте не изменяется. Важно понимать, что операция swap производится в любом случае, просто in и out метки совпадают. По умолчанию устройства на платформе IOS XR используют значения 16000-23999 для SRGB. И, поскольку блоки могут отличаться, информация о них анонсируется через IGP.

С блоком понятно. Но как маршрутизаторы приходят к соглашению о значению метки для определенного FEC? На каждом устройстве должен быть сконфигурирован уникальный SID — segment identifier. Существуют Node SID и Adjacency SID, о последних — чуть ниже. Для определения метки, которая будет закреплена за лупбэком устройства, к нижней границе SRGB прибавляется Node SID. Например, если SRGB начинается с 16000, а устройству присвоен SID 5, то метка для достижения лупбэка устройства будет равна 16005. Эту метку будут использовать все устройства по пути следования (swap 16005 -> 16005).

Почему вдруг речь пошла о лупбэках? Дело в том, что SR — это технология для построения пути до конкретного PE устройства. Другими словами, речь идет о транспортных метках. А достичь PE устройство — значит достичь его лупбэка. Распространение и назначение сервисных меток, будь то L2VPN, L3VPN или другие технологии, не изменяется. Все тот же MP-BGP будет необходим для построения сервисов, все те же сервисные метки будут располагаться внизу стека.

Чуть выше я сказал, что SID устройства должен быть уникальным. Так вот, это наглая ложь. Adjacency SID имеет локальное значение. Маршрутизатор генерирует Adjacency SID для каждого SR соседа автоматически, и значение никак не пересекается с SRGB. Конфигурировать в этом случае ничего не нужно. Как и все остальное, такие метки распространяются протоколом IGP. Это дает возможность передавать трафик через определенный интерфейс. Как указать интерфейс, если метка может не быть уникальной? Здесь все просто: для этого используется стек меток, где верхняя метка — Node SID, а нижняя — Adjacency SID.

Избавляемся от RSVP

LDP всем хорош, вот только следует пути, который выбрал IGP, и полосу резервировать не умеет. При необходимости построить путь передачи трафика отличный от того, что выбрал IGP, на помощь приходит RSVP-TE с его explicit paths. В случае с построением пути, отличным от лучшего по мнению IGP, SR может заменить функционал RSVP прямо из коробки: достаточно просто создать стек меток, который полностью опишет путь. Например, если нам нужно, чтобы трафик отправлялся через Router A до Router B, в стеке транспортных меток будет сначала SID Router A, а затем SID Router B.


Признаться, с точки зрения конфигурации мало что изменяется: в explicit path используются все те же IP адреса. И сразу ответ на часто возникающий вопрос: да, оверхед увеличивается. Если необходимо точно определить путь из десяти маршрутизаторов, то в стеке будет 10 меток. Однако такие сценарии на практике встречаются очень редко. Обычно хватает нескольких меток, чтобы решить конкретную задачу.


А полосу-то как резервировать? С этим пока сложно. Сейчас нет проблем с тем, чтобы запустить CSPF. Проблема заключается в том, что для резервирования полосы пропускания необходимо состояние на маршрутизаторе, которое описывает значение зарезервированной ПП для каждого LSP. Поэтому концепт резервирования полосы требует введения понятия PCE.

PCE — path computation element — это контроллер, который общается с маршрутизаторами по протоколу PCEP. Этот контроллер может рассчитывать TE туннели с использованием CSPF, в том числе с атрибутом bandwidth. Замечу, что PCE и SR — это не единственная существующая комбинация. С не меньшим успехом PCE может работать с RSVP, LDP и даже статически назначать метки. В общем случае задача PCE заключается в том, чтобы установить сразу forwarding state на устройство через протокол PCEP.

Разумеется, для расчета пути PCE должен знать существующую топологию. Рассказать PCE о топологии можно сделав его частью топологии, т. е. подключив его к IGP домену. Альтернативный вариант — BGP-LS сессия с контроллером.

PCE способен отслеживать текущую загрузку интерфейсов и перестраивать путь прохождения туннелей, если это требуется. Другими словами, этот элемент можно назвать SDN контроллером поверх существующей MPLS сети. Однако даже краткое описание PCE — это тема как минимум отдельной статьи. Поэтому я оставлю здесь ссылки на популярные open source проекты, которые в том или ином виде поддерживают PCEP: это ONOS и ODL — а мы вернемся к SR.

Что в итоге?

Все выглядит очень красиво и оптимистично, но где же это применить? Давайте рассмотрим несколько сценариев.

1. Замена протоколу LDP.

Мы разобрались, что заменить RSVP без PCE будет затруднительно, когда используется bandwidth reservation. Поэтому как полноценную замену RSVP без дополнительных элементов в сети SR рассматривать не станем. А что касается LDP, то в теории этот протокол можно выключить и распространять транспортные метки через IGP. Однако этот сценарий едва ли приносит достаточно преимуществ, учитывая риски, на которые придется идти при редизайне сети. К тому же не всегда каждое устройство в сети поддерживает SR. Это можно решить с помощью дополнительной конфигурации, когда несколько устройств являются границей между SR и LDP доменом. Однако факт наличия такой конфигурации заставляет еще больше задуматься о плюсах и минусах решения. Говоря откровенно, сейчас нет причин заменять LDP на SR просто для того, чтобы заменить.

2. Topology independent LFA.

LFA или IP FRR не работает в произвольных топологиях. Например, в кольцевой топологии маршрутизатор не сможет рассчитать запасной путь, поскольку любой путь приведет к петле. Однако используя инкапсуляцию в MPLS, трафик можно сбросить не только соседу, но и удаленному устройству. Здесь SR имеет практический смысл. Разумеется, эту же задачу можно решить с помощью RSVP, но решение с SR выглядит более элегантным.

В качестве примера представьте упомянутую кольцевую топологию, где OSPF cost между всеми маршрутизаторами одинаков. Допустим, каждый маршрутизатор вычисляет LFA для определенного пути.


Как видно, единственный альтернативный путь при маршрутизации по IP приведет к образованию петли. Другими словами, в чистой IP сети LFA вычислить невозможно. Поэтому необходмо «сбросить» трафик чуть ближе к резервируемым префиксам, для чего прекрасно подойдет SR.


3. SDN.

Исопользование SR в совокупности с PCE. Здесь и RSVP заменить можно, и полосу динамически отслеживать, и API организовать для сторонних инструментов. Разумеется, этот перечень скуден и не претендует на полный список всего, чего можно добиться с внедрением PCE в сеть. Но с транспортной точки зрения во главе всего станут гибкость управления сетью, возможность конфигурации intra-AS LSP (включая TE, L2VPN и пр.), простота конфигурации и развертывания сервисов. К тому же, PCE не требует редизайна сети и может работать поверх существующего forwarding plane.

Здесь меня снова понесло немного в сторону от SR. Однако связка SR+PCE выглядит очень многообещающей. И именно в этой связке segment routing раскрывает все свои преимущества.

4. Управление трафиком в больших сетях.

У Cisco есть нетривиальный подход к построению больших операторских сетей, который называется Unified MPLS. В иной терминологии тот же подход может называться Seamless MPLS. Сети с SR смогут стать отличной и более прозрачной альтернативой этому подходу.

Если вы представляете, какие усилия необходимо приложить для проектирования и конфигурации сети с использованием Unified MPLS с нуля, SR может вам приглянуться.

Взаимодействие LDP и SR

Я намеренно оставил этот раздел напоследок. Во-первых, далеко не всегда необходимо, чтобы SR и LDP взаимодействовали. Во-вторых, неплохо бы понимать, какие задачи могут быть решены с помощью SR до того, как переходить к вопросам взаимодействия с LDP.

Наиболее часто решаемые вопросы взаимодействия возникают при миграции с LDP на SR или при отсутствии поддержки SR на части устройств в сети. В IOS XR конфигурация SR безопасна. По умолачнию метки, полученные по LDP, имеют больший приоритет. Для того чтобы LDP ушел на второй план, необходимо сказать маршрутизатору segment-routing mpls sr-prefer в IGP процессе. При этом совершенно необязательно делать SR предпочитаемым на всех маршрутизаторах сразу. Эта команда локальна, и факт предпочтения SR никак не сообщается другим устройствам сети.

При наличии устройств, которые не поддерживают SR, необходимо сконфигурировать несколько устройств в качестве Mapping server. Я говорю несколько только из соображений отказоустойчивости — для функционирования будет достаточно одного устройства на границе SR/LDP сетей.

Mapping server получает метки по LDP, а затем анонсирует SID'ы от имени устройств, которые не умеют SR. При этом data plane не должен проходить через mapping server — это control plane устройство. Все маппинги, которые придумал сервер, анонсируются его клиентам через IGP. Каждое устройство должно быть сконфигурировано как клиент, чтобы получить маппинги для LDP сетей.

Сами маппинги задаются вручную. При этом в случае использования двух и более mapping servers ожидается, что маппинги на них будут сконфигурированы идентично. Конечно, сеть не сломается от неверно сконфигурированного маппинга, но в случае аварии сходимость может пострадать.


Имея mapping server можно защищать LSP, построенные протоколом LDP, в TI LFA. Другими словами, MPLS сервисы, метки для которых сгенерированы классическими протоколами, могут защищаться с использованием SR.

Существует множество сценариев взаимодействия LDP и SR, в их числе LDPoSR и SRoLDP. Чуть более подробное описание можно найти по одной из ссылок, приведенных ниже.

На этом мое короткое повествование о segment routing завершено. Хочу заметить, что материал в статье не рассматривает все нюансы SR и оставляет многое за кадром. Многое из того, что осталось за кадром, можно найти по ссылкам ниже.

Благодарю за внимание.

Ссылки на ресурсы IETF:

» SR draft
» PCEP

Очень полезный ресурс по SR: Cisco SR
Одна из сессий на Cisco Live: Introduction to Segment Routing