Сегментная маршрутизация

Редакция

Эдриан Фаррел (Adrian Farrel), Рон Боника (Ron Bonica)

Редакция

Сегментная маршрутизация (Segment Routing, SR) – это новая технология инжиниринга трафика, разрабатываемая рабочей группой SPRING в составе IETF. Для SR определяется две инкапсуляции плоскости передачи (forwarding plane): MLPS (Multiprotocol Label Switching) и IPv6 с заголовком расширения сегментной маршрутизации (Segment Routing Extension Header). В этой статье мы обсу­дим исторический контекст, описав протоколы плоскости передачи и плоскости управления MPLS, объясним, как работает сегментная маршрутизация, введем концепцию плоскости передачи MPLS-SR и покажем, как работает плоскость управления SR. И, наконец, мы сравним SR с традиционными системами MPLS и перечислим ее уникальные преимущества.

Передача MPLS
Технологии MPLS уже почти 20 лет. Домен MPLS пред­ставляет собой непрерывный набор маршрутизаторов LSR (Label Switching Router). Пакеты поступают в домен MPLS через входной LSR и покидают его через выходной LSR. Один и тот же LSR может служить входным для одних пакетов и выходным для других.
LSP-маршрут (Label Switched Path) осуществляет соедине­ние между входным и выходным LSR. LSP может проходить по пути наименьших затрат или по пути, определяемому путем инжиниринга трафика.
Когда входной LSR получает пакет, он назначает ему класс эквивалентности передачи (Forwarding Equivalence Class, FEC) и инкапсулирует пакет с помощью стека меток MPLS. Затем он передает пакет следующему транзитному участку, связанному с данным FEC.
Стек меток MPLS содержит одну или несколько записей. Каждая запись из стека меток содержит метку, индикатор времени жизни (TTL), индикатор класса трафика (TC) и нижнюю часть индикатора стека. Эти данные определяют то, как транзитный LSR будет обрабатывать пакет. В этом смысле каждая запись из стека меток представляет собой инструкцию для LSR.
Когда LSR получает пакет, он считывает верхнюю запись в стеке меток и уменьшает TTL. Если TTL еще не равно нулю, то LSR выполняет поиск в своей базе информации о передаче (Forwarding Information Base, FIB) записи, которая соответствует входящей метке.
Если LSR найдет запись FIB, которая соответствует входя­щей метке, то эта запись FIB будет содержать следующие данные:

• действие с меткой;
• интерфейс следующего транзитного участка.

Действия с меткой следующие:

• добавить в стек меток одну или несколько новых записей;
• снять верхнюю запись со стека меток;
• заменить метку в верхней записи.

Найдя подходящую запись FIB, LSR выполняет действие с меткой и пересылает пакет через интерфейс следующего транзитного участка. Это может быть внутренний или внешний интерфейс. Если интерфейс внутренний, то LSR пересылает пакет сам себе и обрабатывает его так, как если бы только что его получил, начиная с самого внешнего заголовка протокола. Если интерфейс внешний, то LSR пересылает пакет, куда следует.
Когда пакет достигает предпоследнего транзитного участка на одном LSP, этот LSR может снять со стека меток последнюю запись и переслать пакет полезной нагрузки вообще без инкапсуляции.
Плоскость управления MPLS
Протоколы маршрутизации
В сетях MPLS активно используются внутренние протоколы маршрутизации IGP (Interior Gateway Protocol) — OSPF или IS-IS. Они служат для изучения топологии сети, выработки путей наименьших затрат и сбора информации для вычис­ления путей инжиниринга трафика. Для рассылки сведений о соединениях и метриках используются обычные объяв­ления IGP, и эти сообщения дополняются информацией, описывающей линки (такой как пропускная способность).
Протокол LDP (Label Distribution Protocol)
LDP – это протокол на основе TCP, который может работать между соседними LSR в сети MPLS. Каждый LSR с помощью этого протокола рассылает метку, которую необходимо использовать при посылке на этот LSR пакетов с инкапсуляцией MPLS для окончательной доставки на некий IP-префикс. По мере того, как каждый LSR получает объявления от других LSR, он создает в FIB соответству­ющие записи, которые указывают, как отобразить метку полученного пакета (метку, которую этот LSP рассылал) в метку пакета, который он пересылает дальше (т.е. которую он узнал от других LSP).
В результате использования LDP трафик пересылается по пути наименьших затрат, а инжиниринг трафика не поддерживается.
Протокол RSVP-TE (Resource Reservation Protocol with TE Extensions)
При использовании RSVP-TE операторы сети админи­стративно назначают атрибуты TE интерфейсам. К числу атрибутов ТЕ относятся (но не ограничиваются ими): доступная полоса пропускания, зарезервированная полоса пропускания и административный цвет. Эти атрибуты TE массово рассылаются с помощью IGP, так что каждый узел в рамках домена IGP содержит идентичную копию базы данных состояния связей (Link State Database, LSDB) и базы данных инжиниринга трафика (Traffic Engineering Database, TED). LSDB описывает топологию IGP, а TED дополняет LSDB атрибутами связей TE.
Сетевым операторам нужны LSP, которые соответствовали бы определенным требованиям. Например, сетевой оператор может потребовать, чтобы LSP начинался с узла A, заканчивался в узле Z, резервировал 100 мегабит в секунду и проходил только по синим интерфейсам. Модуль расчета путей, расположенный в центральном контроллере – например, PCE (Path Computation Element) – или входном LSR, вычисляет путь, который соответствует всем ограниче­ниям. Чтобы создать такой SR-путь, функция расчета путей обращается к LSDB и TED.
RSVP-TE – это протокол сигнализации, работающий непосредственно поверх IP. Он использует сообщение Path, чтобы сигнализировать о пути LSP, а сообщение Resv сообщает о резервировании сетевых ресурсов и под­тверждает создание LSP. Сообщение Path содержит данные о запрошенном LSP (полоса пропускания и т.п.), а также объект ERO (Explicit Route Object), в котором перечисляются все узлы и связи, по которым должен пройти LSP. Сообще­ние Resv сообщает о зарезервированных ресурсах (полоса пропускания и т.п.) и содержит объект RRO (Record Route Object), который подтверждает путь LSP.
Каждый LSR выбирает метку, которую будет использовать для получения трафика по LSP. Он включает эту метку в отправляемое сообщение Resv. Поэтому каждый LSR может создать запись FIB для LSP, которая отображает метку, которую он рассылал, на метку, которую он получил.
RSVP-TE требует, чтобы в сети для каждого LSP поддер­живалось состояние, а протокол является «протоколом мягких состояний». Это означает, что для поддержки LSP в активном состоянии необходим периодический обмен сообщениями Path и Resv.

Сегментная маршрутизация
Терминология
Домен SR – это непрерывный набор маршрутизаторов с поддержкой SR. Путь SR (т.е. LSP, просигнализированный по SR) осуществляет соединение в рамках домена SR. Путь SR может проходить по пути наименьших затрат IGP между его начальной и конечной точками. Также он может проходить по пути, вычисленном с помощью инжиниринга трафика.
Путь SR содержит один или несколько сегментов, а сегмент содержит один или несколько транзитных участков маршрутизации. Рабочая группа SPRING предложила множество типов сегментов. Однако наиболее распростра­ненными являются следующие из них:

• соседство (Adjacency);
• префикс (Prefix);
• массовая рассылка (Anycast);
• привязка (Binding).

Сегменты соседства отражают соседские отношения IGP между двумя маршрутизаторами. Как правило, такой сегмент состоит из одного транзитного участка, но их может быть и больше. Префиксные сегменты отражают путь наименьших затрат IGP между любым маршрутизатором и указанным префиксом. Префиксный сегмент содержит один или несколько транзитных участков маршрутизации. Сегменты массовой рассылки похожи на префиксные: они также отражают путь наименьших затрат IGP между любым роутером и указанным префиксом. Разница в том, что в этом случае префикс может объявляться из нескольких точек в сети. Префиксы привязки отражают туннели в домене SR. Такой туннель может быть другим путем SR, LSP, объявленным по LDP, LSP, объявленным по RSVP-TE, либо использовать любую другую инкапсуляцию.
Каждый сегмент идентифицируется идентификатором сегмента (Segment Identifier, SID). Идентификаторы SID для префиксных сегментов и сегментов массовой рассылки используются в рамках всего домена. Поэтому сетевые операторы назначают их с помощью процедуры, похожей на процедуру выделения частных IP-адресов (см. RFC 1918). Напротив, SID сегментов соседства и привязки имеют лишь локальное значение. Эти SID назначаются маршрутизато­рами с поддержкой SR автоматически, без необходимости координации по всему домену.

Каждому SID сопоставлена метка MPLS. Как уже гово­рилось, метки MPLS имеют лишь локальное значение. Поэтому SID локального значения можно сопоставлять меткам MPLS напрямую. А вот SID доменного значения требуют специальной обработки.
Каждый SR-маршрутизатор резервирует ряд меток MPLS, называемый глобальным блоком SR (SR Global Block, SRGB). Например, маршрутизатор A может зарезервировать метки с 10 000 по 20 000, в то время как маршрутизатор B резервирует метки с 20 000 по 40 000. Оба маршрутизатора сопоставляют SID меткам MPLS, добавляя SID к наименьше­му значению SRGB. Поэтому маршрутизатор A сопоставляет SID 1 метке MPLS 10 001, а маршрутизатор B сопоставляет тот же самый SID метке MPLS 20 001.
Передача SR
Когда входной SR-маршрутизатор получает пакет, он назначает ему класс FEC и инкапсулирует пакет с помощью стека меток MPLS. Затем он передает пакет следующему транзитному участку, связанному с данным FEC.
Стек меток MPLS отражает путь SR, связанный с данным FEC. Каждая запись в стеке меток соответствует сегменту пути SR.
На рисунке 1 маршрутизатор R1 поддерживает путь SR до R4. Этот путь SR содержит пять сегментов соседства, начинающихся на маршрутизаторах R2, R3, R7, R6 и R5. Входной LSR (R1) создает стек меток с одной записью на каждый сегмент соседства. Потом R1 передает пакет R2, где начинается первый сегмент соседства. R2 обрабатывает внешнюю запись стека меток, снимает ее и пересылает пакет R3. Каждый следующий LSR вниз по потоку повторяет процедуру до тех пор, пока пакет не достигнет R4.
На рисунке 2 маршрутизаторы R1-R6 поддерживают путь SR до R7. Этот путь SR содержит один префиксный сегмент, которому соответствует SID 7. Рассмотрим путь от R4 до R7

Входной маршрутизатор (R4) создает стек меток, содержащий ровно одну запись, которая представляет префиксный сегмент (т.е. путь наименьших затрат IGP) между R4 и R7. Эта запись в стеке меток содержит метку, соответствующую SID 7. Чтобы вычислить эту метку, R4 добавляет значение SID (7) к базе SRGB, сообщенной следующим транзитным участком R5 (на нашем рисунке это 200). В результате мы получим 207. И, наконец, R4 передает пакет R5.
R5 обрабатывает метку. Для этого он определяет маршрутизатор на пути наименьших затрат IGP, ведущий к R7 (в нашем примере это R6). Затем R5 заменяет метку на значение, которое в R6 соответствует SID 7 (т.е. 307). После этого он передает пакет R6. R6 повторяет процедуру, и пакет прибывает на R7.
На рисунке 3 маршрутизатор R1 поддерживает рассчитан­ный с помощью инжиниринга трафика путь SR до R4 через R7. Этот путь SR содержит два префиксных сегмента. Один префиксный сегмент соответствует пути наименьших затрат IGP от R1 до R7, а второй соответствует пути наименьших затрат IGP от R7 до R4.
Входной LSR (R1) создает стек меток с одной записью на каждый префиксный сегмент. Он вычисляет внутреннее значение метки, прибавляя SID R4 (4) к базе SRGB R7 (300). Он вычисляет внешнее значение метки, прибавляя SID R7 (7) к базе SRGB R2. После этого R1 передает пакет R2. Все маршрутизаторы ниже по течению обрабатывают пакет так, как описано в предыдущем примере, и пакет прибывает на R4.

Расширения IGP для сегментной маршрутизации
Каждый SR-маршрутизатор выделяет SID и метку:

• каждому префиксному сегменту или сегменту массовой рассылки, который заканчивается на этом маршрутизато­ре;
• каждому сегменту соседства или привязки, который начи­нается на этом маршрутизаторе.

Сделав это, он создает запись RIB (Routing Information Base – прим. ред.) для каждого из вышеперечисленных сегментов и вносит записи RIB в FIB.
Далее SR-маршрутизатор рассылает с помощью IGP следующую информацию:

• свои характеристики SRGB;
• все префиксные сегменты и сегменты массовой рассылки, которые заканчиваются на этом маршрутизаторе;
• все сегменты соседства или привязки, которые начинают­ся на этом маршрутизаторе.

IGP рассылает эти данные, в дополнение к ранее упоминавшимся атрибутам связи TE, по всему домену IGP. Поэтому каждый узел в рамках домена IGP содержит идентичную копию базы данных состояния связей (LSDB) и базы данных инжиниринга трафика (TED). LSDB описывает топологию IGP, включая SID и данные SRGB, а TED дополняет LSDB атрибутами связей TE.
Когда рассылка завершается, каждый узел в рамках домена IGP создает по две записи RIB для каждого пре­фиксного сегмента и сегмента массовой рассылки, который не заканчивается на этом узле. Первая запись RIB указы­вает локальному устройству обрабатывать весь входящий трафик IP, направляемый на этот префикс, следующим образом:

• добавить на самый верх стека MPLS запись, чья метка соответствует данному SID;
• переслать пакет на следующий транзитный участок по пути наименьших затрат IGP, ведущему к конечной точке сегмента.

Вторая запись RIB указывает локальному устройству обра­батывать весь входящий трафик MPLS, чья самая внешняя метка соответствует сегменту, следующим образом:

• заменить внешнюю метку, пересчитав ее для SRGB следу­ющего транзитного участка;
• переслать пакет на следующий транзитный участок по пути наименьших затрат IGP, ведущему к конечной точке сегмента.

Расчет путей
Функция расчета путей рассчитывает пути SR. Получив набор ограничений TE, функция расчета путей выдает на выходе стек меток MPLS, образующих путь SR, который соответствует ограничениям. Чтобы создать такой SR-путь, функция расчета путей обращается к LSDB и TED.
Функция расчета путей может располагаться в цен­тральном контроллере или, наоборот, распределяться по входным LSR.
Анализ
LDP и RSVP-TE – сквозные протоколы сигнализации, которые создают состояния передачи для каждого LSP в LSR. Поскольку LDP и RSVP-TE поддерживают все необходи­мые состояния передачи в LSR, то LSP, обработанный по LDP или RSVP-TE, может быть представлен одной записью стека MPLS.
Напротив, методика SR перемещает часть состояний передачи (хотя только часть) из сети в пакет. Путь SR представлен стеком меток, где каждая запись соответствует сегменту на пути SR. Поэтому сеть поддерживает доста­точно состояний, чтобы пересылать пакеты от входного сегмента к выходному, а пакет – достаточно, чтобы пересы­латься от сегмента к сегменту.
Перенеся информацию о состояниях из сети в пакеты, SR снижает требования к памяти для LSR и объем вычислений, необходимый для поддержания состояний. А ведь про­блема памяти и объема вычислений остается актуальной, несмотря на то, что в последнее время маршрутизаторы стали оснащаться большим количеством вычислительных ресурсов и памяти, а также на доработки протокола RSVP-TE и его реализаций.
Еще более важно то, что перенос информации о состоя­ниях из сети в пакеты устранило потребность в сквозном протоколе сигнализации. Да, для работы SR требуется IGP и модуль расчета путей, но протокол сигнализации, подобный LDP или RSVP-TE, больше не нужен.
Однако ряд дополнительных функций RSVP-TE зависит от сквозной сигнализации и состояний LSP в сети. Это и резервирование полосы пропускания, и обнаружение ошибок, и быстрая перемаршрутизация.
В RSVP-TE функция расчета путей может быть распреде­лена по входным LSR, даже для случая, когда ограничения TE содержат резервирование полосы пропускания. Это возможно, так как в RSVP-TE каждый LSR поддерживает состояние для каждого своего LSP. По этому состоянию можно вычислить остаток пропускной способности на каждом интерфейсе с поддержкой RSVP и разослать эту информацию по IGP. Таким образом, каждый узел в IGP поддерживает LSDB и TED с достаточным количеством информации для работы функции расчета путей.
В SR такого механизма нет. Поэтому на случай, когда ограничения TE включают в себя полосу пропускания, функция расчета путей должна быть централизованной и располагаться в контроллере, обладающем глобальной информацией о распределении полосы пропускания.
В RSVP-TE сквозные механизмы сигнализации также реа­лизуют функциональность OAM (Operation, Administration, Maintenance – процессы, необходимые для управления, администрирования и обслуживания системы – прим. ред.). При отказе соседского сеанса RSVP-TE маршрутизатор LSR выше по течению от места сбоя сигнализирует входному LSR, заставляя запустить процесс восстановления. Если LSR выше по течению от места сбоя настроен соответствующим образом, он может также запустить локальные процедуры восстановления.
В SR восстановление выглядит сложнее. Если сбой проис­ходит на входном сегменте, то какой-либо механизм OAM вне SR обнаруживает сбой и информирует модуль расчета путей. Последний запускает процедуры восстановления и пересчитывает путь SR между входным SR и выходным. Локальные процедуры восстановления для SR теоретически возможны, но стандарта на этот счет пока нет.
Если сбой происходит не в конечной точке сегмента, SR вынужден полагаться на внешние механизмы восстановле­ния. Например, если сбой произошел посреди префиксного сегмента, то SR должен использовать IGP, чтобы обнаружить сбой, разослать изменения топологии и вычислить новый путь наименьших затрат IGP до конечной точки сегмента. В этом примере можно развернуть TI-LFA, чтобы снизить зависимость от сходимости IGP.
Источник: IETF Journal

Выводы
SR поддерживает инжиниринг трафика, в то же время снижая количество состояний, которые должна обрабатывать сеть. Во многих случаях SR делает ненужными протоколы сигнализации MPLS (такие как LDP и RSVP-TE). Потому IETF следует продолжить разработку SR.
В частности, IETF следует продолжить стандартизацию расширений IGP для SR, а также расширений BGP, которые могут потребоваться для того, чтобы SR могла выйти за пределы IGP. Крайне необходимо проработать ключевые функции сети, такие как OAM и возможности передачи энтропии для разрешения выборов ECMP. Кроме того, поставщики сетевого оборудования и сетевые операторы должны совместными усилиями разработать прототипы и поэкспериментировать с SR для того, чтобы IETF получила обратную связь, на основе которой можно будет усовершенствовать SR и подготовить ее к крупномасштабному внедрению.
Весьма вероятно, что сетевые операторы начнут постепенно развертывать SR в ближайшие несколько лет. По мере внедрения сообщество SR будет набирать практический опыт, стандар­ты SR будут дорабатываться, а практика внедрения – совершенствоваться. Кроме того, сетевые операторы выявят сценарии, для которых SR хорошо подойдет, а также ситуации, где лучше использовать LDP и RSVP-TE.
По этим причинам, а также для поддержки большой базы инсталляций, IETF и производители сетевого оборудования должны продолжать доработку и поддержку LDP и RSVP-TE на том же уровне усилий, на котором они сейчас развивают SR.