(Унесено с хабра, где было опубликовано 2024-02-15; автор — Борис Хасанов, сетевой архитектор в Яндексе)

Как оптимизировать путь данных внутри чёрного ящика под названием «сеть» и гарантировать необходимый уровень сервиса пользователям своего приложения? Эта задача может волновать не только сетевых инженеров и архитекторов, но и разработчиков, и DevOps-команды. Для глубокого понимания вопроса потребуется разобраться, что такое Traffic Engineering и как он эволюционировал в современных сетях.

Как сетевой архитектор в Yandex Infrastructure я не раз возвращался к этой теме и в роли спикера на отраслевых конференциях, и в роли преподавателя. С 2017 года я также участвую в разработке черновиков стандартов в рабочих группах IETF и могу сказать, что за каждым черновиком стоит выдающаяся работа коллег из индустрии. Так что в этой статье я буду часто опираться на уже полюбившийся мне своей логикой RFC 9522 и другие связанные документы. А также обобщу опыт разработки, тестирования и внедрения SDN‑контроллера, который получил имя Сусанин в нашей команде, — здесь благодарю за помощь коллег Виталия Венгловского aka https://habr.com/ru/users/AllTheThingsUndone, Артёма Денисова, Григория Соловьёва и Егора Зимина.

Весь накопленный опыт показал: чтобы лучше разобраться в теме, потребуется хорошее знание сетевых технологий и протоколов, используемых в больших сетях: это динамическая маршрутизация, туннели, VPN, в идеале — знание MPLS, а ещё лучше — РСЕР. Так что пойдём по порядку.

Краткое содержание нашей небольшой энциклопедии Traffic Engineering:

Часть 1. Основы, распределённый и централизованный расчёт туннелей, магия РСЕ

Часть 2. Основы РСЕР и Stateful PCE, Междоменный RSVP‑TE, новый взгляд на РСЕСС

Часть 3. Жизнь после MPLS

Базовая терминология

Для начала важно сформулировать, что же это такое — Traffic Engineering (для краткости ТЕ). Наиболее подходящим я вижу определение из RFC 9522: «такой аспект инжиниринга сетей Интернет, который занимается проблемами оценки и оптимизации производительности действующих IP‑сетей».

Здесь видим две ключевые характеристики: оценка производительности и её оптимизация. Обеспечить оптимальную производительность необходимо при помощи конечных сетевых ресурсов, как в стабильном состоянии сети, так и в случае возникновения тех или иных сбоев — выхода из строя одного или нескольких линков, или узлов сети. Отсюда, дополнительно к привычным нам настройкам уровня качества обслуживания, или Quality of Service (QoS), можно выделить две стороны оптимизации производительности при помощи TE:

Мы видим, что обе эти стороны ТЕ тесно связаны с повышением отказоустойчивости сети в целом.

Оптимизация потоков трафика в сети достигается в ТЕ при помощи управления пропускной способностью сети (capacity) и управления самим трафиком. Для первого ТЕ использует планирование нужной пропускной способности, контроль маршрутизации, управление сетевыми ресурсами (полоса пропускания линков, размеры буферов, вычислительные ресурсы для расчета путей). Управление трафиком достигается использованием путей, отвечающих заданным ограничениям (constraints), управления очередями и планированием потоков трафика (scheduling).

Оценка производительности сети с использованием ТЕ может осуществляться различными средствами: аналитическими методами, моделированием, эмпирическими методами на основе получаемой из сети информации об использовании ресурсов, например: загрузка линков, джиттер (дисперсия задержки), Round Trip Time — RTT, процент потерь и т. д.

RFC 9522 определяет три основных компонента ТЕ: политика, управление путями, управление ресурсами. Рассмотрим задачи каждого компонента подробнее.

В контексте ТЕ резервирование ресурсов — это контроль над тем, чтобы в сети был достигнут консенсус о том, какие ресурсы будут использованы заданным потоком трафика (traffic flow). Тут важно ещё раз подчеркнуть, что мы говорим именно про плоскость управления (control plane) над ресурсами сети (forwarding plane), иными словами, резервирование ресурсов отнюдь не гарантирует их физическое выделение.

Выделение ресурсов — это назначение ресурсов сети на уровне forwarding plane при помощи управления размерами буферов и очередей, policing, shaping. В оптических транспортных сетях DWDM — это может быть выделение и закрепление конкретной лямбды. Выделение ресурсов, статическое или динамическое, призвано минимизировать последствия перегрузок в сети (congestion), обеспечить гарантии качества сервисам (SLA или SLO), а также соблюсти заданный уровень задержки для сервисов, которые требуют её минимизации.

Далее сфокусируюсь как на внутридоменных аспектах ТЕ, так и на междоменных. Однако я не буду описывать варианты использования политик BGP для организации ТЕ, т.к. этот аспект уже подробно освещён в литературе и широко используется на практике.

Зачем нужен ТЕ, что вызвало его появление и почему он продолжает развиваться?

В основе появления, развития или смерти большинства технологий лежат экономические причины и потребности, которые призван удовлетворить конкретный протокол или инструмент. Потребность в ТЕ вызвана несколькими причинами:

Именно ТЕ позволяет уйти от жёсткой привязки к маршрутизации на основе кратчайшего пути и провести оптимизацию использования или производительности сети на основе одного или нескольких ограничений (тех самых constraints). В некоторых особо продвинутых случаях мы можем прийти к сочетанию критериев и использованию для разных сервисов — разных алгоритмов.

Одно время у традиционных операторов связи бытовало мнение о том, что полоса пропускания в их сетях бесконечна и никакой ТЕ им не нужен. Интересно, что этот тезис обсуждался ещё в 1990-х годах, но время и объективная реальность полностью его опровергли. Поэтому считаю важным рассказать про генезис и развитие ТЕ в этой статье.

Аспекты использования ТЕ

Важные аспекты использования ТЕ включают:

Где именно используется ТЕ

Для уточнения контекста использования нам необходимо обратиться к понятию домена сети. Классическое определение называет доменом группу маршрутизаторов под общим административным управлением. Но мы также широко используем термин «IGP-домен», т.е. часть сети, которая использует определённый протокол динамической маршрутизации (IGP). Справедливости ради, домен динамической маршрутизации может быть организован и на протоколе BGP.

Более широко домен сети можно представить в виде абстракции:

В чём основная проблематика ТЕ

В проблематике ТЕ нужно выделить две составляющих:

С использованием метода дедукции мы можем сразу вспомнить про одну из основных проблем в сети — это перегрузка (network congestion), которая практически всегда приводит к деградации качества сервисов. На практике перегрузка возникает на одном или нескольких сетевых элементах и длится в течение определённого временного интервала. Для предотвращения перегрузок в сети традиционно используют политики ограничения трафика на входе путём снижения запросов (demand‑side) на передачу для проверки их соответствия уровню SLA. Кроме того, это сочетается с традиционными методами гарантирования QoS (scheduling, wred…), либо предоставлением больших ресурсов (полосы пропускания — supply‑side).

Именно ТЕ способен обеспечить большую полосу пропускания путём более эффективного распределения трафика в сети. Это даёт ответы на основные экономические запросы для ТЕ.

Как классифицировать методологии и варианты реализации ТЕ

Мы не будем рассматривать организацию статического ТЕ, т.к. это скорее функциональность сетевого планирования, в котором отсутствует динамическая природа ТЕ.

Согласно RFC 9522 методологически ТЕ можно поделить на три класса: зависящий от времени, зависящий от состояния сети, зависящий от событий в сети (событийный).

Разберём их по очереди.

Как применяется ТЕ

По вариантам реализации ТЕ бывает распределённый и централизованный. Нам, сетевым инженерам, обычно наиболее привычен распределённый ТЕ, когда решение о конкретном пути трафика принимает РЕ‑маршрутизатор на основе собственного видения состояния сети. Для создания такой картины используются TE‑расширения для протоколов динамической маршрутизации (OSPF, ISIS).

В случае централизованного ТЕ решение о пути для трафика принимается специальным элементом, либо по запросам РЕ, либо полностью самостоятельно. Для этого периодически собирается информация о состоянии сети, например, через BGP‑LS.

ТЕ‑алгоритмы различают по степени использования информации о состоянии сети, в зависимости от того, используют ли они:

ТЕ может быть как без обратной связи (open‑loop), так и с обратной связью (closed‑loop), где обратной связью будет выступать информация о состоянии сети (в т.ч. и результаты измерений, перечисленных выше). Практически же более оптимальным (но и более затратным) выглядит именно вариант с обратной связью.

Ну и последнее, про что хотелось бы сказать в этом разделе, — это то, что применение ТЕ в сети может быть тактическим и стратегическим. Задача тактического ТЕ — решать конкретные, локальные проблемы или задачи: перегрузка определённого линка или узла, локальная защита линка или узла и т. п. Стратегический ТЕ — решает проблемы на более организованной и системной основе с учётом как краткосрочных, так и долгосрочных задач, прогнозов по росту трафика, требований сервисов, политик по управлению трафиком и т. д.

На практике, как правило, ТЕ в сети сочетает перечисленные выше варианты методологий ТЕ и вариантов реализаций, т. е. представляет собой гибридную систему, мы подробнее поговорим про это дальше.

Экскурс в историю механизмов ТЕ

Здесь необходимо напомнить про важные механизмы, без которых классический ТЕ не появился бы. Большинство из них разрабатывались в IETF в течение длительного времени, так что перечислю лишь самые основные.

Модель Integrated Services

Практическая реализация ТЕ была бы невозможна без разработки модели Integrated Services (Intserv). Её суть в том, что сетевые ресурсы, такие как полоса пропускания и буферы, резервируются заранее для данного потока трафика, чтобы обеспечить требуемый уровень качества обслуживания (QoS). Иными словами, сетевые ресурсы должны быть зарезервированы априори. Дополнительными компонентами модели Intserv являются классификаторы пакетов (packet classifiers), планировщики отправки пакетов (packet schedulers) и контроль доступа в сеть (admission control).

Задача классификатора пакетов — идентификация нужного потока, для которого нужно получить тот или иной уровень качества обслуживания. Планировщик отправки пакетов обрабатывает «привязку» определённого сервиса к различным потокам для подтверждения нужного качества обслуживания путём использования различных очередей. Контроль доступа в сеть (admission control) позволяет маршрутизатору решить (accept или reject) — есть ли у него доступные ресурсы для обработки нового потока с требуемым качеством обслуживания или нет.

Как предполагалась на практике работа модели Intserv: Источник: RFC 1633, секция 2.2 Источник: RFC 1633, секция 2.2

Мы видим несколько основных компонентов:

Естественно, что такая система невозможна без сигнализации явным образом требований QoS от одного маршрутизатора (либо хоста как конечного узла) к другому маршрутизатору. Для решения этой задачи был придуман протокол RSVP (Resource ReSerVation Protocol). Напомню, основные принципы его работы, т.к. важно понимать, почему RSVP вплоть до недавнего времени был синонимом ТЕ.

Обзор протокола RSVP

RSVP оперирует понятием «сессия» — это поток данных (data flow) к определённому узлу назначения через транспортный протокол. RSVP‑сессия однозначно идентифицируется триплетом: Адрес узла назначения (DestAddress), Идентификатор протокола (ProtocolId) [, Порт назначения (DstPort)], где:

Базовые характеристики RSVP

Сразу следует прояснить, что:

Модель резервирования RSVP

Базовый запрос на резервирование в RSVP состоит из двух основных составляющих, образующих пару, называемую «flow description» — это «flowspec» и «filterspec». Flowspec — определяет требуемый уровень QoS, а filterspec (совместно с описанием сессии) — определяет параметры потока, получающего этот уровень QoS.

Если вспомнить базовые концепты модели Intserv, то flowspec используется для задания параметров планировщика отправки пакетов (packet scheduler), а filterspec — для задания параметров классификатора пакетов (packet classifier).

Вы скажете — неужели всё так просто? Но нет, придётся копнуть ещё глубже.

Спецификация Flowspec, передаваемая в запросе на резервирование, в свою очередь содержит:

Формат двух спецификаций (Tspec и Rspec) подробно описан в RFC 2210, секции 3.

На этой схеме параметры [r], [b], [p] — задают Tspec, а параметры [R], [S] — Rspec. Для тех читателей, кому это будет интересно, — подробнее про выбор параметров рассказано в RFC 2212.

Формат filterspec зависит от того, используется ли IPv4 или IPv6. По сути, он определяет подмножество пакетов: номер, IP‑адрес отправителя и номер порта, либо номер более высокоуровневого протокола и номер порта и т. п.

Поведение маршрутизатора с RSVP

Как отмечалось, RSVP‑пакеты инициируются узлом назначения, или приёмником, в сторону узла‑отправителя. На промежуточных узлах (маршрутизаторах) получение RSVP пакета вызывает два действия:

Варианты (стили) резервирования в RSVP

Для RSVP в RFC 2205 определены два возможных стиля резервирования:

Более подробно описание стилей резервирования можно посмотреть в RFC 2205.

Принцип работы RSVP

Проиллюстрирую базовый принцип работы RSVP: Источник: RFC 2205, секция 2

Здесь мы видим абстрактную топологию сети: узлы A, B, C, D… и связывающий их маршрутизатор. Показаны два основных сообщения RSVP: Resv (reservation request) и Path.

Оба этих сигнальных сообщения должны пройти точно таким путём, каким будут далее отправляться данные определённого потока, для которого мы планируем резервировать сетевые ресурсы. Ключевая особенность сообщения Path в том, что оно содержит «состояние пути», а именно: минимум один unicast IP‑адрес предыдущего узла, который использовался для маршрутизации сообщения Resv. Кроме того, в сообщении Path имеется следующие информационные конструкты:

Состояние Soft‑state, создаваемое RSVP. Я уже отмечал выше, что RSVP создаёт т. н. soft‑state на маршрутизаторе, а в контексте ТЕ также можно говорить и про forwarding state. Это состояние создаётся и поддерживается периодическими сообщениями Resv и Path. Таймер обновления (refresh time/period) рекомендуется устанавливать в 30 сек.

Soft‑state удаляется, если не было принято сообщений Resv и Path в течение определённого промежутка времени, задаваемого т. н. cleanup timeout. Удаление состояния значит и удаление всех ассоциированных с ним структур данных в т.ч. и в FIB. Это особенно критично для MPLS‑TE.

Состояние на маршрутизаторах может быть также удалено отправкой специального сообщения «teardown». Если быть точным, есть два типа таких сообщений: PathTear and ResvTear.

Естественно, что у RSVP есть также сообщения об ошибках, вы могли догадаться, что их тоже два: ResvErr и PathErr. Они посылаются в случае возникновения критических проблем с резервированием ресурсов.

Узел‑приёмник может запросить явное (explicit) подтверждение резервирования ресурсов включением специального confirmation‑request‑объекта. В ответ он получит ResvConf‑сообщение. 

         0             1              2             3
         +-------------+-------------+-------------+-------------+
         |Vers|Flags| Msg Type |   RSVP Checksum   |
         +-------------+-------------+-------------+-------------+
         |Send_TTL|(Reserved)|      RSVP Length      |
         +-------------+-------------+-------------+-------------+

Формат заголовка RSVP сообщений (RFC 2005, секция 3.1.1)

Здесь Msg Type (8 bits) = 1 (Path), 2 (Resv), 3 (PathErr), 4 (ResvErr), 5 (PathTear), 6 (ResvTear), 7 (ResvConf)

Зачем нам это?

Тут читатель может спросить: зачем автор потратил столько времени на текст про модель Intserv и протокол RSVP?

Общеизвестно, что основной проблемой Intserv стала проблема масштабируемости. Красивой идее о резервировании ресурсов на пути следования пакета при помощи RSVP было бы суждено отправиться на «кладбище технологий», если бы не появление технологии Multiprotocol Label Switching (MPLS) — многопротокольной коммутации по меткам. Кстати, ей уже более 20 лет: первый вариант черновика стандарта по архитектуре MPLS появился в марте 1998.

В этой статье мы не будем давать подробное описание принципов работы MPLS: я предполагаю, что читатель знаком с принципом передачи пакетов на основе меток. Напомню лишь кратко: суть MPLS в том, что к пакету добавляется т. н. метка фиксированной длины — 4 байта, из которых сама метка занимает 20 бит. Решение о назначении метки (операция label push) принимает маршрутизатор, который находится на входе в MPLS‑домен (Label Edge Router — LER, или Ingress PE) в соответствии с т. н. FEC (Forwarding Equivalence Class). Это пакеты, имеющие одинаковый узел назначения (Egress LER или PE), идущие по одинаковому пути и с одинаковой обработкой, принадлежат одному FEC (например, к одному BGP NH). Метка определяет транспортный туннель для трафика (Label Switched Path — LSP) между LER. Промежуточные маршрутизаторы (Label Switching Router — LSR или Р‑маршрутизатор) делают операцию по замене метки (label swap) при прохождении пакета через них. Формат метки в MPLS (см. секцию 2 RFC 3052) Формат метки в MPLS (см. секцию 2 RFC 3052)

Надо отметить, что архитектурно RFC 3031 лишь упоминает о механизмах распространения меток, но при этом явно говорит, что их может быть несколько, в том числе: Label Distribution Protocol (LDP), RSVP (ба, наш старый знакомый) — точнее теперь это RSVP‑TE и BGP.

В докладе на Nexthop-2020 я делал краткое сравнение различных технологий MPLS. Тут же стоит напомнить, что LDP жестко привязан к работе IGP и ориентируется на его решения о выборе кратчайшего пути, соответственно, не пригоден для ТЕ. Были попытки развить его в т. н. CR‑LDP, пригодный для ТЕ, но они были остановлены консенсусом в IETF. Запрос на понятный и надежный ТЕ никуда не исчез. Требования к ТЕ в случае использования MPLS были сформулированы в RFC 2702, и ТЕ обрел, что называется, «второе дыхание».

Трансформация RSVP в RSVP‑TE. Протокол RSVP имеет функциональность резервирования ресурсов, поддерживает задания пути в виде списка узлов, а поскольку архитектура MPLS предполагала его к использованию в качестве механизма распространения меток и построения LSP, то логичным образом возникла идея расширить его возможности и использовать для организации ТЕ в MPLS‑сетях. Группа инженеров взялась за проработку вопроса в IETF, а результатом работы стали RFC 3209 и сам термин RSVP‑TE (часто также используется MPLS‑TE).

Что в результате появилось нового в протоколе RSVP. Как вы уже могли понять, было необходимо обогатить имеющиеся возможности сообщений Resv, Path путём насыщения их новыми объектами, специально разработанными для задач ТЕ с учётом использования технологии MPLS. Остановимся на них подробнее.

Сообщение Path дополнилось следующими объектами:

Прежняя логика работы RSVP в целом сохраняется. Однако Path теперь посылается Ingress PE, или Head-End к Egress PE или Tail-End. И в ответ на Path мы должны получить Resv, которое в свою очередь дополнилось следующими объектами:

После получения маршрутизатором Resv, в ответ на посланный Path, LSP считается установленным. Сигнализация RSVP-TE LSP, где LSP является однонаправленным (simplex) Сигнализация RSVP-TE LSP, где LSP является однонаправленным (simplex)

Резюме по модификациям для RSVP-TE из RFC 3209: 

      Object name         Applicable RSVP messages
      --------------      ------------------------
      LABEL_REQUEST       Path
      LABEL               Resv
      EXPLICIT_ROUTE      Path
      RECORD_ROUTE        Path, Resv
      SESSION_ATTRIBUTE   Path

Надо отметить пару важных моментов:

Что мы получаем в итоге от RSVP‑TE?

Как рассчитывать пути для RSVP‑TE?

Читатель может задать вопрос: это, конечно, всё здорово — придумали расширения для RSVP‑TE, наконец‑то сделали возможным ТЕ в MPLS‑сети с явным заданием пути для туннеля/LSP — но каким же образом можно посчитать эти пути, какие ограничения могут учитываться, как распространить информацию об этом в сети и тому подобное?

Этот вопрос весьма важен, т.к. необходимо описать и понять имеющиеся варианты, перед тем как идти далее. Итак, мы имеем две связанные задачи:

Для простоты изложения я начну с модели распределённого ТЕ. В этой модели вторая задача решается на каждом маршрутизаторе при помощи алгоритма Constrained Shortest Path First (CSPF), для которого информация о состоянии сети будет служить базисом для расчёта.

Сигнализация информации о состоянии сети

Для распространения информации о сети есть только две опции: либо придумывать какой‑то новый протокол, либо использовать что‑то из уже имеющихся. Выбор пал на второй вариант. Какие же протоколы есть в наших сетях, которые уже используют информацию о состоянии сети, на которые можно возложить эту нагрузку? Ответ очевиден: это протоколы динамической маршрутизации (IGP), такие как ISIS и OSPF. Оба этих протокола являются протоколами Link State (состояния каналов), на основе флудинга (flooding) LSA/LSP все маршрутизаторы сети рассылают информацию о себе, подключенных линках и т. д. С её помощью формируется база данных о состоянии линков (Link State Database или LSDB), на основе которой формируется единая топология на всех устройствах сети и рассчитывается граф кратчайших путей. Необходимые расширения для ТЕ в ISIS описаны в RFC 5305, а для OSPF — в RFC 3630.

Они одинаковы для обоих протоколов, различаются только их реализации (как отличаются и форматы структуры OSPF vs. ISIS, но вопрос их сравнения выходит за рамки этой статьи):

Независимо от реализации рассмотрим, какую же информацию мы будем передавать для ТЕ в IGP. Смотреть будем на примере ISIS по RFC 5305, за аналогичной информацией для OSPF также отсылаю в RFC 3630: 

    Extended IS Reachability TLV (тип 22)
        Administrative Group (color, resource class)
        IPv4 Interface Address
        IPv4 Neighbor Address
        Maximum Link Bandwidth
        Maximum Reservable Link Bandwidth
        Unreserved Bandwidth
        Traffic Engineering Default Metric

    Extended IP Reachability TLV (тип 135)
        metric
        up/down Bit
        Traffic Engineering Router ID TLV

Пример Extended IS Reachability TLV на оборудовании одного вендора: 

Packet: LSP ID: lab1.00-00, Length: 404 bytes, Lifetime : 65530 secs
    Checksum: 0x4b72, Sequence: 0x625, Attributes: 0x3 <L1 L2>
    NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes
    Packet type: 20, Packet version: 1, Max area: 0

  TLVs:
    Area address: 01 (1)
    LSP Buffer Size: 1492
    Speaks: IP
    Speaks: IPV6
    IP router id: 192.168.200.24
    IP address: 192.168.200.24
    Hostname: lab1
    Extended IS Reachability TLV, Type: 22, Length: 99
    IS extended neighbor: test1.00, Metric: default 6000 SubTLV len: 88
      IP address: 192.168.160.85
      Neighbor's IP address: 192.168.160.84
      Local interface index: 332, Remote interface index: 563
      Current reservable bandwidth:
        Priority 0 : 200Gbps
        Priority 1 : 200Gbps
        Priority 2 : 200Gbps
        Priority 3 : 200Gbps
        Priority 4 : 200Gbps
        Priority 5 : 200Gbps
        Priority 6 : 200Gbps
        Priority 7 : 200Gbps
      Maximum reservable bandwidth: 200Gbps
      Maximum bandwidth: 200Gbps
      Administrative groups:  0 <none>

Для некоторых сценариев в сети весьма важно использовать расширенную метрику, а не просто число, отражающее полосу пропускания линка. Для этого коллеги придумали сделать «обогащённую» метрику в IGP с дополнительными параметрами, такими как:

Более подробно это описано в RFC 8570 и RFC 7471, вопрос поддержки расширенной метрики на конкретном оборудовании с конкретным ПО я оставляю за скобками статьи.

IGP будет распространять эту информацию в следующих случаях:

Всё это позволяет сформировать консистентную LSDB с ТЕ‑информацией по каждому из линков маршрутизатора, на котором включен MPLS.

Для случая распределённого ТЕ мы конфигурируем туннели на Ingress PE (Head End) или LER. Темплейты конфигурирования RSVP‑TE достаточно хорошо описаны для нескольких вендоров в СДСМ, MPLS Fund, MPLS SDN и так далее, поэтому не буду останавливаться на этом в статье.

Стоит отметить один важный терминологический вопрос: когда мы говорим про RSVP‑ТЕ‑туннель, например, про его конфигурацию, то возможен случай, когда один туннель будет иметь внутри себя несколько LSP (например, один основной LSP и один резервный), либо только один LSP (например, LSP, пересигнализированный после изменения полосы или после реоптимизации). Разные вендоры исторически используют разные термины (туннель/LSP). Один вендор также использует название CR‑LSP (Constraint Based LSP). В моей статье термины туннель/LSP эквивалентны.

И вот, наконец‑то, мы начинаем подходить к решению второй ТЕ‑задачи — расчёту путей для случая распределённого ТЕ!

Для этого нам пригодятся знания о работе алгоритма CSPF, к которому вернёмся дальше. Но перед этим на Ingress‑PE‑маршрутизаторе, должно произойти ещё одно «магическое» действие. Читатель может не волноваться, никаких заклинаний произносить не нужно, всё должно произойти автоматически за счёт формирования Traffic Engineering Database (TED). Что же это такое?

По сути, это аналог LSDB, но с некоторыми отличиями:

В принципе, TED можно сконфигурировать непосредственно на устройстве. Правда, очевидно, что это не масштабируемое и чреватое различными ошибками и побочными действиями решение.

Возможность посмотреть именно TED на маршрутизаторе зависит от вендора, у некоторых есть специальная команда для этого, а у некоторых — нет. В таком случае её можно увидеть косвенным образом, например, просмотрев LSDB c большим уровнем детализации и выбрав оттуда нужные параметры по соответствующим узлам или интерфейсам.

Пример просмотра TED на маршрутизаторе Juniper: 

lab1> show ted database extensive
TED database: 115 ISIS nodes 111 INET nodes 0 INET6 nodes
NodeID: lab1.00(192.168.200.24)
  Type: Rtr, Age: 46248 secs, LinkIn: 4, LinkOut: 4
  Protocol: IS-IS(2)
   192.168.200.24
    To: lab2.00(192.168.247.180), Local192.168.213.97, Remote: 192.168..213.96
      Local interface index: 450, Remote interface index: 409
      Color: 0 <none>
      Metric: 2000
      IGP metric: 2000
      Static BW: 100Gbps
      Reservable BW: 100Gbps
      Available BW [priority] bps:
          [0] 100Gbps      [1] 100Gbps     [2] 100Gbps     [3] 100Gbps
          [4] 100Gbps      [5] 100Gbps     [6] 100Gbps     [7] 100Gbps
      Interface Switching Capability Descriptor(1):
        Switching type: Packet
        Encoding type: Packet
        Maximum LSP BW [priority] bps:
          [0] 100Gbps      [1] 100Gbps     [2] 100Gbps     [3] 100Gbps
          [4] 100Gbps      [5] 100Gbps     [6] 100Gbps     [7] 100Gbps
      P2P Adjacency-SID:
        IPV6, SID: 154498, Flags: 0xb0, Weight: 0
        IPV4, SID: 154497, Flags: 0x30, Weight: 0    
[SNIP]

Пример просмотра TED на маршрутизаторе Huawei: 

[~lab2]disp mpls te cspf tedb all igp-type isis
Current Total Node Number: 142
Current Total Link Number: 690
Current Total SRLG Number: 0
Id     Router-Id        IGP      Process-Id     Area            Link-Count
1      192.168.200.24      ISIS     1              Level-2         4
 [SNIP]

[~lab2]display mpls te cspf tedb node 192.168.200.24
 Router ID: 192.168.200.24
 IGP Type: ISIS      Process ID: 1      IGP Area: Level-2
  Loopback Address:
    192.168.200.24
  MPLS-TE Link Count: 4
  Link[1]:
    ISIS System ID: 1921.6820.0024.00:00     Opaque LSA ID: 1921.6820.0024.00:00
    Interface IP Address: 172.16.1.1
    Peer  IP Address: 172.16.1.2
    Peer  Router  ID: 192.168.233.233
    Peer  ISIS System ID: 1921.6823.3233.00:00
    IGP Area: Level-2
    Link  Type: point-to-point  Link Status: Active
    IGP Metric: 6000            TE Metric: 6000        Color: 0x0
    TE Enabled: Yes
    Bandwidth Allocation Model : -
    Maximum Link-Bandwidth: 200000000 (kbps)
    Maximum Reservable Bandwidth: 200000000 (kbps)
    Operational Mode of Router: TE
    Bandwidth Constraints:         Local Overbooking Multiplier:
        BC[0]:            - (kbps)           LOM[0]:          1
    BW  Unreserved:
        Class  ID:
        [0]:     200000000 (kbps),            [1]:     200000000 (kbps)
        [2]:     200000000 (kbps),            [3]:     200000000 (kbps)
        [4]:     200000000 (kbps),            [5]:     200000000 (kbps)
        [6]:     200000000 (kbps),            [7]:     200000000 (kbps)

Constrained Shortest Path First (CSPF)

Задача CSPF — вычисление пути согласно заданным ограничениям (constraints), который затем будет помещён в ERO сообщения Path. Без заданных ограничений на выходе мы получим результат, идентичный обычному SPF по алгоритму Дейкстра — Dijkstra, то есть кратчайший путь.

Начнём с того, а какие ограничения мы можем использовать? Вот некоторые примеры:

На маршрутизаторе мы можем иметь два типа RSVP-TE туннелей (LSP):

В статическом варианте в темплейте конфигурации туннеля мы должны вручную описать путь для ERO (strict/loose), требуемую полосу пропускания, а также другие характеристики, вроде приоритетов на установку и удержание туннеля (setup and hold priorities). При помощи них мы можем иметь дополнительный механизм для приоритезации туннелей (т.н. admission control).

В динамическом варианте путь для туннеля будет посчитан CSPF на основе заданных ограничений.

Результаты работы CSPF помещаются в TED, которая формируется на основе LSDB, — т.е. результаты вычисления ограничены одним IGP-доменом. Для междоменного ТЕ нужны дополнительные механизмы.

Результаты расчётов CSPF для динамических ТЕ-туннелей остаются актуальными, пока остаются актуальными данные в TED. После их изменения, например, флапа или выхода из строя линка либо узла, изменения параметра туннеля, изменения параметров core-линка, нужен новый пересчёт, называемый реоптимизацией. Цель реоптимизации — пересчитать туннель/LSP и снова сделать его путь оптимальным с учётом заданных ограничений.

Реоптимизация бывает двух видов: ручная (команда в CLI) и автоматическая (либо вызванная событиями в сети — event-driven, либо по таймауту — периодическая).

Реоптимизация может привести к нежелательным последствиям в сети на время пересчета и пересигнализации туннеля/LSP, до начала форвардинга сервисного трафика (L2 или L3VPN поверх него). Последствия возможны в виде «проливания» трафика, увеличения задержек для сервиса, изменения профиля трафика (traffic pattern) и т.д., что сказывается на стабильности сети. Поэтому она обычно выключена для ТЕ по умолчанию в вендорских имплементациях и требует дополнительного конфигурирования (либо ручного запуска). Некоторые вендоры предлагают концепцию make before break: т.е. сначала пересчета и сигнализации нового туннеля/LSP и лишь затем перевода на него трафика. Такая функциональность нуждается в тщательном тестировании перед использованием в реальной сети.

И ещё, результатом работы CSPF будет только один туннель/LSP, даже если есть несколько возможных вариантов, из них выберется только один. Ну и для того чтобы трафик мог форвардится по этому пути — туннель/LSP должен быть просигнализирован через сообщения Path/Resv.

Как отправить трафик в рассчитанные RSVP-TE туннели? Не открою ничего нового, таких способа три:

У последних двух вариантов есть разные названия у разных вендоров, поэтому я оставлю только эти функциональные описания.

Централизованный расчёт туннелей или магия РСЕ

Для начала разговора про PCE попытаемся ответить на вопрос: а зачем вообще нужен какой-то централизованный расчёт туннелей (централизованный ТЕ), если есть чудесный CSPF, который рассчитывает их на основе TED, формируемой из идентичной на всех узлах LSDB?

Для формализованного ответа, приведу выдержку из RFC 4655:

Возможно, вы сможете добавить к этому списку ещё и какие-то свои сценарии. На мой взгляд, он и так уже достаточен для ответа на поставленный вопрос. На практике встречается либо одна, либо несколько причин из этого списка. И если коротко сформулировать собственный практический ответ на этот вопрос, то он будет таков: как только необходим расчёт путей (туннелей), более сложный, чем просто учёт полосы и цветов линков, и количество туннелей переходят границу по сотням, то, скорее всего, вам будет необходим централизованный ТЕ.

Ниже я расскажу про ещё один необычный сценарий использования централизованного ТЕ.

Кто же может осуществить на практике централизованный расчёт ТЕ, и какова будет архитектура такой сети?

Ответ на эти вопросы даёт уже упомянутое неоднократно RFC 4655. Приведу его ещё раз: «РСЕ или Path Computation Element — это сущность (компонент, приложение или сетевой узел), способная осуществлять расчёт сетевого пути или маршрута на основе графа сети с применением заданных ограничений». Ёмко и элегантно сформулировано, не правда ли?

РСЕ на практике, на момент написания статьи, встречается в нескольких видах:

Независимо от варианта имплементации, РСЕ решают сформулированную выше задачу, их отличия, по большому счету, заключаются в типах используемых алгоритмов и поддерживаемых SBI (Southbound Interface), плюс разный GUI и набор дополнительных сервисов (например, провижионинг VPN и т.п.).

Вот так выглядит наиболее распространенный случай целевой архитектуры внешнего PСЕ: Внешний РСЕ (Fig.2, RFC 4655) Внешний РСЕ (Fig.2, RFC 4655)

Никто и ничто не может запретить нам использовать несколько РСЕ в сети, если это нужно по каким-то причинам. Как правило, это либо очень большой масштаб сети, когда надо заниматься расчётом и провижионингом в десятки тысяч устройств, в разных доменах, жёсткие требования по обеспечению отказоустойчивости, либо случай многоуровневого расчёта, как показано выше, или расчёта LSP в разных доменах по частям. Такая возможность также была сразу продумана в RFC 4655: Использование нескольких РСЕ (Fig.3, RFC 4655) Использование нескольких РСЕ (Fig.3, RFC 4655)

Хочу отметить, что может быть и другой вариант объединения РСЕ: т.н. иерархический РСЕ (H-PCE), когда РСЕ одного уровня подключаются своими северными (Northbound) интерфейсами (NBI) к РСЕ более высокого уровня.

Вообще RFC 4655 определяет четыре модели работы РСЕ:

В Яндексе при разработке Сусанина, мы решили использовать подход, похожий на рекомендуемую RFC 4655 модель с несколькими РСЕ (модель 4), но с некоторыми отличиями.

Я не буду здесь повторять свой доклад с nexthop про наш контроллер, отмечу лишь, что мы использовали распределенную модульную структуру, где каждый модуль отвечает за определённую функцию и распределённое хранилище на основе ZK.

Любопытный читатель может спросить: РСЕ — это конечно здорово, но только как другие устройства сети (маршрутизаторы), которые будут его клиентами, узнают о его существовании, чтобы отсылать ему запросы на расчёт?

Отвечу, что есть два варианта, простой и сложный:

Для последнего варианта есть ещё дополнительное подспорье — специальные TLV, описывающие возможности (capabilities) РСЕ, например IP-адрес РСЕ или домен, в котором РСЕ будет работать. А также дополнительные флаги, описанные в RFC 5088 (OSPF) и RFC 5089:

Bit Capabilities

0 Path computation with GMPLS link constraints 1 Bidirectional path computation 2 Diverse path computation 3 Load‑balanced path computation 4 Synchronized path computation 5 Support for multiple objective functions 6 Support for additive path constraints (max hop count, etc.) 7 Support for request prioritization 8 Support for multiple requests per message 9–31 Reserved for future assignments by IANA.

Флаги базовых возможностей (capabilities) PCE

Для этого, естественно, РСЕ должен находиться в IGP домене, что не всегда целесообразно с точки зрения дизайна, например, в случае внешнего РСЕ. Вопрос реальной поддержки динамического определения в сети РСЕ имеющимися вендорами, я оставляю особо заинтересованным читателям.

Очень важно отметить, что РСЕ могут быть двух типов:

Современные реализации РСЕ (в т.ч. и на Сусанине) являются stateful.

Надеюсь, что теперь роль и задачи РСЕ стали вам понятны. Но может быть непонятно, а каким образом взаимодействуют клиенты с РСЕ?

Если РСЕ — это, по сути, централизованный элемент или сервер, то как маршрутизаторы или клиенты должны к нему обращаться?

Тут на сцену выходит специально разработанный для этого протокол — Path Computation Element Communication Protocol (PCEP), базовая спецификация которого дана в RFC 5440.

Коль скоро термин РСЕ уже введен в оборот, будет справедливо ввести также термин РСС (Path Computation Client) — клиент, устройство (маршрутизатор), запрашивающее расчёт пути у сервера (РСЕ). Кстати, в случае взаимодействия двух РСЕ, один РСЕ будет сервером, а второй клиентом (РСС).

Перед тем, как рассмотреть структуру РСЕР, давайте остановимся на тех требованиях, которые легли в его основу:

Полагаю, что у проницательного читателя после прочтения этих требований уже складывается картина того протокола, который получился на выходе…

Но об основах PCEP мы поговорим уже в следующий раз.

LecturesCMC/LinuxNetwork2026/Six/YandexTEEvolution/01_Basics (последним исправлял пользователь ArsenyMaslennikov 2026-06-30 00:35:49)