Как оптимизировать путь данных внутри чёрного ящика под названием «сеть» и гарантировать необходимый уровень сервиса пользователям своего приложения? Эта задача может волновать не только сетевых инженеров и архитекторов, но и разработчиков, и DevOps-команды. Для глубокого понимания вопроса потребуется разобраться, что такое Traffic Engineering и как он эволюционировал в современных сетях.
Как сетевой архитектор в Yandex Infrastructure я не раз возвращался к этой теме и в роли спикера на отраслевых конференциях, и в роли преподавателя. С 2017 года я также участвую в разработке черновиков стандартов в рабочих группах IETF и могу сказать, что за каждым черновиком стоит выдающаяся работа коллег из индустрии. Так что в этой статье я буду часто опираться на уже полюбившийся мне своей логикой RFC 9522 и другие связанные документы. А также обобщу опыт разработки, тестирования и внедрения SDN‑контроллера, который получил имя Сусанин в нашей команде, — здесь благодарю за помощь коллег Виталия Венгловского aka @AllTheThingsUndone, Артёма Денисова, Григория Соловьёва и Егора Зимина.
Весь накопленный опыт показал: чтобы лучше разобраться в теме, потребуется хорошее знание сетевых технологий и протоколов, используемых в больших сетях: это динамическая маршрутизация, туннели, VPN, в идеале — знание MPLS, а ещё лучше — РСЕР. Так что пойдём по порядку.
Краткое содержание нашей небольшой энциклопедии Traffic Engineering:
Часть 1. Основы, распределённый и централизованный расчёт туннелей, магия РСЕ
Часть 2. Основы РСЕР и Stateful PCE, Междоменный RSVP‑TE, новый взгляд на РСЕСС
Часть 3. Жизнь после MPLS (TBD)
Базовая терминология
Для начала важно сформулировать, что же это такое — Traffic Engineering (для краткости ТЕ). Наиболее подходящим я вижу определение из RFC 9522: «такой аспект инжиниринга сетей Интернет, который занимается проблемами оценки и оптимизации производительности действующих IP‑сетей».
Здесь видим две ключевые характеристики: оценка производительности и её оптимизация. Обеспечить оптимальную производительность необходимо при помощи конечных сетевых ресурсов, как в стабильном состоянии сети, так и в случае возникновения тех или иных сбоев — выхода из строя одного или нескольких линков, или узлов сети. Отсюда, дополнительно к привычным нам настройкам уровня качества обслуживания, или Quality of Service (QoS), можно выделить две стороны оптимизации производительности при помощи TE:
Проактивный ТЕ должен предпринять определённые действия заранее, т. е. до наступления отказов на сети в будущем.
Реактивный ТЕ обеспечивает оперативное реагирование на возникший сбой или отказ, его целью является устранение или минимизация последствий.
Мы видим, что обе эти стороны ТЕ тесно связаны с повышением отказоустойчивости сети в целом.
Оптимизация потоков трафика в сети достигается в ТЕ при помощи управления пропускной способностью сети (capacity) и управления самим трафиком. Для первого ТЕ использует планирование нужной пропускной способности, контроль маршрутизации, управление сетевыми ресурсами (полоса пропускания линков, размеры буферов, вычислительные ресурсы для расчета путей). Управление трафиком достигается использованием путей, отвечающих заданным ограничениям (constraints), управления очередями и планированием потоков трафика (scheduling).
Оценка производительности сети с использованием ТЕ может осуществляться различными средствами: аналитическими методами, моделированием, эмпирическими методами на основе получаемой из сети информации об использовании ресурсов, например: загрузка линков, джиттер (дисперсия задержки), Round Trip Time — RTT, процент потерь и т. д.
RFC 9522 определяет три основных компонента ТЕ: политика, управление путями, управление ресурсами. Рассмотрим задачи каждого компонента подробнее.
Политика позволяет выбрать путь на основе дополнительной информации, большей, чем просто базовая достижимость или минимальная метрика протокола маршрутизации.
Управление путями — это возможность пересылать пакеты также с использованием дополнительной информации, большей, чем знание Next Hop (NH). Примеры такого управления: Source Routing в целом и Segment Routing в частности, RSVP‑TE‑пути, BGP‑политики, в т.ч. и FlowSpec, сюда же можно отнести и Service Function Chaining (SFC). Все эти варианты управления путями используют различные механизмы для достижения своей цели: control‑plane‑протоколы, манипуляции заголовками пакета, либо их сочетание — но независимо от способа они все относятся к этой категории.
Управление ресурсами подразумевает data plane, т. е. ресурсы сети (линки), используемые для пересылки пакетов. И тут мы опять встретим ветвление на два аспекта: резервирование ресурсов и выделение ресурсов.
В контексте ТЕ резервирование ресурсов — это контроль над тем, чтобы в сети был достигнут консенсус о том, какие ресурсы будут использованы заданным потоком трафика (traffic flow). Тут важно ещё раз подчеркнуть, что мы говорим именно про плоскость управления (control plane) над ресурсами сети (forwarding plane), иными словами, резервирование ресурсов отнюдь не гарантирует их физическое выделение.
Возможно, первый подход к тому, чтобы обеспечить такое резервирование и одновременно назначение ресурсов сети — это т. н. network slicing. Но это весьма обширная тема, точно требующая отдельной статьи, поэтому я не буду рассказывать здесь ещё и про него.
Выделение ресурсов — это назначение ресурсов сети на уровне forwarding plane при помощи управления размерами буферов и очередей, policing, shaping. В оптических транспортных сетях DWDM — это может быть выделение и закрепление конкретной лямбды. Выделение ресурсов, статическое или динамическое, призвано минимизировать последствия перегрузок в сети (congestion), обеспечить гарантии качества сервисам (SLA или SLO), а также соблюсти заданный уровень задержки для сервисов, которые требуют её минимизации.
Далее сфокусируюсь как на внутридоменных аспектах ТЕ, так и на междоменных. Однако я не буду описывать варианты использования политик BGP для организации ТЕ, т.к. этот аспект уже подробно освещён в литературе и широко используется на практике.
Зачем нужен ТЕ, что вызвало его появление и почему он продолжает развиваться?
В основе появления, развития или смерти большинства технологий лежат экономические причины и потребности, которые призван удовлетворить конкретный протокол или инструмент. Потребность в ТЕ вызвана несколькими причинами:
Операторам (в широком смысле этого слова) необходимо предоставлять сервисы с гарантиями качества обслуживания, чтобы соответствовать требованиям клиентов. А клиентам, в свою очередь, критически важен доступ к ресурсам, детерминированный SLA/SLO.
Одновременно с этим операторам необходимо повышать эффективность использования, или утилизацию сетевого оборудования и ресурсов, т. е. оптимизировать затраты на капитальные вложения (CAPEX). В первую очередь, при оптимизации использования ресурсов речь идёт об имеющейся полосе пропускания — bandwidth.
Именно ТЕ позволяет уйти от жёсткой привязки к маршрутизации на основе кратчайшего пути и провести оптимизацию использования или производительности сети на основе одного или нескольких ограничений (тех самых constraints). В некоторых особо продвинутых случаях мы можем прийти к сочетанию критериев и использованию для разных сервисов — разных алгоритмов.
Одно время у традиционных операторов связи бытовало мнение о том, что полоса пропускания в их сетях бесконечна и никакой ТЕ им не нужен. Интересно, что этот тезис обсуждался ещё в 1990-х годах, но время и объективная реальность полностью его опровергли. Поэтому считаю важным рассказать про генезис и развитие ТЕ в этой статье.
Аспекты использования ТЕ
Важные аспекты использования ТЕ включают:
домены, в которых используется ТЕ;
проблематику ТЕ;
варианты реализации ТЕ;
внедрение и эксплуатация ТЕ.
Где именно используется ТЕ
Для уточнения контекста использования нам необходимо обратиться к понятию домена сети. Классическое определение называет доменом группу маршрутизаторов под общим административным управлением. Но мы также широко используем термин «IGP-домен», т.е. часть сети, которая использует определённый протокол динамической маршрутизации (IGP). Справедливости ради, домен динамической маршрутизации может быть организован и на протоколе BGP.
Более широко домен сети можно представить в виде абстракции:
Набор маршрутизаторов, связанный посредством линков, или каналов в определённую топологию (граф сети) и передающий пакеты данных от узла источника к узлу назначения.
Система генерации нагрузки на сеть (demand system), выдающая определённый объём трафика в моменте.
Система доставки трафика (response system), включающая в себя: сетевые и контрольные протоколы и механизмы, обеспечивающие движение трафика в сети.
В чём основная проблематика ТЕ
В проблематике ТЕ нужно выделить две составляющих:
выбор параметров и описание состояния сети (network state) на основе качественной оценки объёмов трафика, топологии сети и доступных ресурсов;
оценка состояния сети в моменте, в виде данных о производительности сети: как системы в целом, так и на уровне индивидуальных сетевых ресурсов, в соответствии с требованиями SLA того или иного сервиса.
С использованием метода дедукции мы можем сразу вспомнить про одну из основных проблем в сети — это перегрузка (network congestion), которая практически всегда приводит к деградации качества сервисов. На практике перегрузка возникает на одном или нескольких сетевых элементах и длится в течение определённого временного интервала. Для предотвращения перегрузок в сети традиционно используют политики ограничения трафика на входе путём снижения запросов (demand‑side) на передачу для проверки их соответствия уровню SLA. Кроме того, это сочетается с традиционными методами гарантирования QoS (scheduling, wred…), либо предоставлением больших ресурсов (полосы пропускания — supply‑side).
Именно ТЕ способен обеспечить большую полосу пропускания путём более эффективного распределения трафика в сети. Это даёт ответы на основные экономические запросы для ТЕ.
Как классифицировать методологии и варианты реализации ТЕ
Мы не будем рассматривать организацию статического ТЕ, т.к. это скорее функциональность сетевого планирования, в котором отсутствует динамическая природа ТЕ.
Согласно RFC 9522 методологически ТЕ можно поделить на три класса: зависящий от времени, зависящий от состояния сети, зависящий от событий в сети (событийный).
Разберём их по очереди.
В зависящем от времени ТЕ мы опираемся на исторические данные об изменениях трафика в сети за заданный временной интервал. Эти данные мы используем для предварительной настройки плоскости управления ТЕ (control plane) на сетевых устройствах. Дополнительно можно использовать оценочные данные (прогнозы трафика или traffic demand) от сервисов или приложений: обычно такая информация доступна при правильной организации сервиса. Ключевой момент здесь заключается в том, что мы не пытаемся привязать расчёт ТЕ к кратковременным изменениям трафика в силу тех или иных причин, а оптимизируем расчёт ТЕ на более длительный период, например, раз в сутки. Очевидно, что для практического применения зависящего от времени ТЕ нам будет необходима централизованная сущность: контроллер или РСЕ, про который подробнее поговорим дальше.
Зависящий от состояния сети ТЕ адаптирует маршрутизацию и ТЕ к конкретным условиям сети в моменте, на основе дополнительной информации о текущем объёме трафика, его вариации от обычного (исторического) объёма. Такая информация, очевидно, обеспечит оптимальный в моменте расчёт ТЕ.
Важный вопрос: а как же мы можем получить такую информацию? К счастью, у нас есть несколько вариантов для этого, и мы можем использовать либо один из них, либо какую‑то комбинацию:
стриминговая телеметрия — push‑технология, на основе тех или иных Yang‑моделей (IETF, OpenConfig) с подпиской на определённые параметры, заданные в модели (подробнее см. RFC 8639, RFC 8641);
пассивные механизмы сбора информации, такие как IPFIX, sFlow, а также зеркалирование (mirroring) трафика;
активные механизмы, такие как: старый добрый ping, Two‑Way Active Measurement Protocol (TWAMP) и его упрощенная версия TWAMP‑Light, Simple Two‑way Active Measurement Protocol (STAMP) — а также хочу обратить внимание на расширения для протокола STAMP, для технологии Segment Routing, которые позволяют использовать Segment Lists для задания пути тестового пакета вместо IP NH;
гибридные методы, например, Alternate Marking (AM) или In Situ Operations, Administration, and Maintenance (IOAM), в котором in situ подразумевает, что OAM‑данные отправляются непосредственно с пакетами данных — весьма интересный подход.
Подробное описание всех этих методов не является целью данной статьи. Необходимо лишь отметить, что при помощи стриминговой телеметрии мы можем получать оценку производительности и состояния сети непосредственно с устройств, а активные и гибридные механизмы оценки производительности (performance monitoring) позволяют использовать либо специальные тестовые пакеты для измерения задержки и потерь пакетов, либо специальным образом маркировать пакеты определённого потока трафика для этих же целей. Таким образом, при использовании либо какого‑то одного механизма, либо их комбинации мы можем собирать информацию о состоянии сети и передавать её для централизованного расчёта и оптимизации туннелей в контроллер (Path Computation Element — PCE).
Зависящий от событий в сети ТЕ отличается от двух предыдущих вариантов ТЕ тем, каким образом мы будем выбирать пути. Несмотря на название, данный метод ТЕ не отслеживает события в сети, например, изменение топологии, а использует специальные модели для расчёта пропускной способности: например, для классического MPLS они описаны в RFC 6601.
ТЕ очевидным образом требует расчёта путей, эти вычисления могут выполняться как онлайн, так и офлайн. Онлайн‑расчёт производится в реальном масштабе времени или приближенном к реальному, а офлайн‑расчёт производится в удобный момент, без привязки к состоянию сети в реальном времени. Интуитивно понятно, что офлайн‑вычисления мы можем использовать тогда, когда:
нам не нужно рассчитывать пути в реальном времени (например, мы используем зависящий от времени ТЕ с дополнением его прогнозами по трафику);
используется вычислительно сложный алгоритм, что было актуально на заре становления ТЕ (на текущий момент РСЕ может использовать сложные алгоритмы в режиме онлайн — этому есть множество публичных примеров).
И наоборот — онлайн‑вычисления путей используются тогда, когда расчёт путей должен адаптироваться к изменившемуся состоянию сети (используется зависящий от состояния ТЕ).
Как применяется ТЕ
По вариантам реализации ТЕ бывает распределённый и централизованный. Нам, сетевым инженерам, обычно наиболее привычен распределённый ТЕ, когда решение о конкретном пути трафика принимает РЕ‑маршрутизатор на основе собственного видения состояния сети. Для создания такой картины используются 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:
Мы видим несколько основных компонентов:
агент маршрутизации, формирующий базу данных маршрутной информации (routing database или Routing Information Base — RIB);
агент установки резервирования и управляющий агент совместно формируют базу управления трафиком (атрибуты для резервирования трафика);
на нижнем уровне действуют классификатор и планировщик, определяющие соответствие определённого потока этим атрибутам и помещение его в соответствующую очередь для обеспечения требуемого соответствия и уровня QoS.
Естественно, что такая система невозможна без сигнализации явным образом требований QoS от одного маршрутизатора (либо хоста как конечного узла) к другому маршрутизатору. Для решения этой задачи был придуман протокол RSVP (Resource ReSerVation Protocol). Напомню, основные принципы его работы, т.к. важно понимать, почему RSVP вплоть до недавнего времени был синонимом ТЕ.
Обзор протокола RSVP
RSVP оперирует понятием «сессия» — это поток данных (data flow) к определённому узлу назначения через транспортный протокол. RSVP‑сессия однозначно идентифицируется триплетом: Адрес узла назначения (DestAddress), Идентификатор протокола (ProtocolId) [, Порт назначения (DstPort)], где:
Адрес узла назначения — это IP‑адрес (unicast/multicast),
Идентификатор протокола — IP protocol ID (стандарт разрешает любой номер, например, 17 и 6 для UDP/TCP),
Порт назначения — опциональный параметр, содержит генерализованные номера TCP/UDP портов, служит для мультиплексирования нескольких сессий к одному IP‑адресу.
Базовые характеристики RSVP. Сразу следует прояснить, что:
RSVP — это протокол soft‑state, и резервирование ресурсов происходит только на уровне плоскости управления (control plane);
RSVP — симплексный протокол, т. е. резервирование происходит только для однонаправленного потока. Отсюда будет вытекать важное свойство ТЕ, основанного на RSVP;
RSVP ориентирован на получателя, т. е. именно он должен инициировать RSVP‑сессию;
RSVP не является протоколом маршрутизации, напротив, его работа зависит от работающей маршрутизации;
RSVP поддерживает как IPv4, так и IPv6;
RSVP позволяет сигнализировать связность как точка‑точка (P2P), так и точка‑многоточка (P2MP);
RSVP‑сообщения пересылаются от узла к узлу, как raw IP дейтаграммы с номером протокола 46.
Модель резервирования RSVP. Базовый запрос на резервирование в RSVP состоит из двух основных составляющих, образующих пару, называемую «flow description» — это «flowspec» и «filterspec». Flowspec — определяет требуемый уровень QoS, а filterspec (совместно с описанием сессии) — определяет параметры потока, получающего этот уровень QoS.
Если вспомнить базовые концепты модели Intserv, то flowspec используется для задания параметров планировщика отправки пакетов (packet scheduler), а filterspec — для задания параметров классификатора пакетов (packet classifier).
Вы скажете — неужели всё так просто? Но нет, придётся копнуть ещё глубже.
Спецификация Flowspec, передаваемая в запросе на резервирование, в свою очередь содержит:
класс сервиса;
два важных набора числовых данных: Rspec (R от резервирования), которая содержит описание нужного QoS, и Tspec (T от слова трафик), которая описывает сам поток.
Формат двух спецификаций (Tspec и Rspec) подробно описан в RFC 2210, здесь я приведу для справки лишь формат соответствующего объекта:
На этой схеме параметры [r], [b], [p] — задают Tspec, а параметры [R], [S] — Rspec. Для тех читателей, кому это будет интересно, — подробнее про выбор параметров рассказано в RFC 2212.
Формат filterspec зависит от того, используется ли IPv4 или IPv6. По сути, он определяет подмножество пакетов: номер, IP‑адрес отправителя и номер порта, либо номер более высокоуровневого протокола и номер порта и т. п.
Поведение маршрутизатора с RSVP. Как отмечалось, RSVP‑пакеты инициируются узлом назначения, или приёмником, в сторону узла‑отправителя. На промежуточных узлах (маршрутизаторах) получение RSVP пакета вызывает два действия:
Резервирование ресурсов на заданном линке. Для этого RSVP запрос должен пройти проверку контроля доступа (admission control) и проверку соответствующей политикой. Если результат любой проверки будет неуспешным, то такой запрос получит отказ с генерацией сообщения об ошибке. А если результат успешен, то узел устанавливает классификатор пакета для соответствующего потока (согласно filterspec) в соответствии с параметрами QoS, описанными во flowspec.
Передача запроса следующему узлу по направлению к узлу‑отправителю. Напомню, что запрос идет от узла к узлу в обратном направлении от узла назначения.
Варианты (стили) резервирования в RSVP. Для RSVP в RFC 2205 определены два возможных стиля резервирования:
Резервирование в рамках одной сессии для разных отправителей: либо индивидуальное (distinct) резервирование для каждого отправителя отдельно, либо общее, разделяемое (shared) резервирование для них всех;
Контроль списка отправителей: либо посредством явного (explicit) их перечисления в списке, либо использования маски (wildcard), которая неявным образом определяет отправителей в данной сессии. Надо отметить, что в первом случае должна быть отдельная filterspec на каждого отправителя, а во втором случае filterspec вообще не нужна.
Более подробно описание стилей резервирования можно посмотреть в RFC 2205.
Принцип работы RSVP. Проиллюстрирую базовый принцип работы RSVP:
Здесь мы видим абстрактную топологию сети: узлы A, B, C, D… и связывающий их маршрутизатор. Показаны два основных сообщения RSVP: Resv (reservation request) и Path.
Resv отправляется узлом назначения (приёмником) в сторону узла‑отправителя на основе решения протокола маршрутизации,
Path посылается узлом‑отправителем в сторону узла назначения (приёмника), но только в обратном направлении по отношению к Resv.
Оба этих сигнальных сообщения должны пройти точно таким путём, каким будут далее отправляться данные определённого потока, для которого мы планируем резервировать сетевые ресурсы. Ключевая особенность сообщения Path в том, что оно содержит «состояние пути», а именно: минимум один unicast IP‑адрес предыдущего узла, который использовался для маршрутизации сообщения Resv. Кроме того, в сообщении Path имеется следующие информационные конструкты:
Спецификация Tspec отправителя, которая характеризует поток данных отправителя, используется для контроля трафика;
Шаблон отправителя (sender template) описывает формат пакетов данных в форме filterspec, используется для выбора пакетов конкретного отправителя из многих других в рамках одной сессии
Adspec — опциональная спецификация, используемая для поддержки концепции One Pass With Advertising (OPWA).
Состояние 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) при прохождении пакета через них.
Надо отметить, что архитектурно 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 дополнилось следующими объектами:
LABEL_REQUEST — запрашивает MPLS‑метку для пути, в ответ на это соответствующие транзитные маршрутизаторы (LSR) и исходящий (egress) LER выделяют метки для своих частей пути.
Для нужд ТЕ необходимо иметь возможность явным образом задать путь, отличный от кратчайшего, т. н. explicit path. Для этого используется объект EXPLICIT_ROUTE, содержащий адреса узлов, через который должен пройти LSP (Label Switched Path).
Есть нюансы в том, как мы можем описать путь LSP: либо указать явным образом все узлы — такой вариант называется strict (точный или определённый), — либо указать только часть узлов, и тогда путь до следующего узла через промежуточные называется loose — неточный, неопределённый.RECORD_ROUTE — этот объект требует от всех маршрутизаторов по пути, через который проходит сообщение Path, вписывать в него свои адреса. Если транзитный маршрутизатор увидит свой адрес в объекте, в сообщении Path, то таким образом он сможет определить наличие петли (loop). Можно провести некую аналогию с BGP (path vector) и атрибутом AS_PATH.
SESSION_ATTRIBUTE — этот объект используется для идентификации и диагностики сессии, а также в нём передаются приоритеты установки и удержания LSP (setup/hold priorities).
Переиспользуются оригинальные объекты Tspec (запрос требуемой полосы) и POLICY_DATA объекты.
Прежняя логика работы RSVP в целом сохраняется. Однако Path теперь посылается Ingress PE, или Head-End к Egress PE или Tail-End. И в ответ на Path мы должны получить Resv, которое в свою очередь дополнилось следующими объектами:
LABEL — содержит MPLS‑метку, которая должна использоваться на участке пути данного LSP.
RECORD_ROUTE — аналогичным образом, как и для Path, тут записывается путь сообщения Resv, посредством этого объекта маршрутизатор также может обнаруживать петли.
После получения маршрутизатором Resv, в ответ на посланный Path, LSP считается установленным.
Резюме по модификациям для 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 добавили новое опциональное сообщение HELLO: оно используется между соседними узлами с RSVP-TE (IP TTL ==1), а его назначение — дополнительный механизм отслеживание сбоя узла. Для этого в нём используются два объекта: HELLO REQUEST и HELLO ACK.
Выше я упоминал, что главной проблемой оригинального RSVP и модели Intserv была проблема масштабируемости. Поскольку в RSVP-TE сохранилась вся машинерия оригинального RSVP, то Soft-state или, иными словами, forwarding state на маршрутизаторах также поддерживается и сохраняется, пока сохраняется двухсторонний обмен сообщениями Path, Resv, которые генерируются на каждую RSVP-TE-сессию. Таким образом, мы опять упираемся в ограничения по масштабируемости при росте количества LSP. Я ещё остановлюсь на этом моменте ниже, а пока скажу, что в качестве попытки преодоления этой проблемы была предложена концепция RSVP Refresh Overhead Reduction, при помощи в тот момент нового для RSVP сообщения Bundle, которое агрегирует набор RSVP-сообщений в один PDU.
Что мы получаем в итоге от RSVP‑TE?
Возможность организации ТЕ в MPLS‑сетях в принципе.
Задание ТЕ‑пути как точка‑точка (P2P), так и точка‑многоточка (P2MP) явным образом (explicit path) с опциями strict/loose.
Возможность резервирования полосы пропускания для ТЕ‑туннеля из конца в конец (E2E).
Различные варианты защиты ТЕ туннеля: E2E — т. н. Hot‑Standby, защита от выхода из строя линка, защита от выхода из строя узла. Про это напишу дополнительно дальше.
Количество RSVP‑TE сессий на оборудовании пропорционально количеству LSP, проходящих через данный узел. При увеличении коэффициента связности между РЕ‑маршрутизаторами (в пределе — переход к полной связности между РЕ: full mesh) это серьезно увеличивает загрузку control plane на Р‑маршрутизаторах, или промежуточных узлах. RSVP Refresh Overhead Reduction — это возможный способ минимизации такой загрузки, однако оно не устраняет её причину.
Как рассчитывать пути для 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, но вопрос их сравнения выходит за рамки этой статьи):
в ISIS это Extended IS Reachability TLV и Extended IP Reachability TLV вместе с Sub‑TLV;
в OSPF т. н. Opaque LSA (type 10) c TLV/sub‑TLV (одна Link TLV в одном LSA)
Независимо от реализации рассмотрим, какую же информацию мы будем передавать для ТЕ в 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 с дополнительными параметрами, такими как:
задержка на линке в одном направлении (Unidirectional Link Delay);
минимальная/максимальная задержка на линке в одном направлении (Min/Max Unidirectional Link Delay);
вариация задержки в одном направлении;
потери на линке в одном направлении;
используемая полоса пропускания в одном направлении;
доступная полоса пропускания в одном направлении;
утилизируемая полоса пропускания в одном направлении.
Более подробно это описано в RFC 8570 и RFC 7471, вопрос поддержки расширенной метрики на конкретном оборудовании с конкретным ПО я оставляю за скобками статьи.
IGP будет распространять эту информацию в следующих случаях:
изменение состояния линка (up/down);
периодическая рассылка (флудинг);
изменения резервируемой полосы пропускания;
после неудачной попытки создания ТЕ‑туннеля.
Всё это позволяет сформировать консистентную 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 эквивалентны.
Для информации: различие в терминологии tunnel vs. LSP стоит иметь в виду, например, когда вы изучаете характеристики того или иного маршрутизатора в части масштабирования MPLS‑TE. Также важно помнить, что туннели/LSP — симплексные (однонаправленные), т. е. для связи между двумя РЕ вам нужно два туннеля/LSP.
И вот, наконец‑то, мы начинаем подходить к решению второй ТЕ‑задачи — расчёту путей для случая распределённого ТЕ!
Для этого нам пригодятся знания о работе алгоритма CSPF, к которому вернёмся дальше. Но перед этим на Ingress‑PE‑маршрутизаторе, должно произойти ещё одно «магическое» действие. Читатель может не волноваться, никаких заклинаний произносить не нужно, всё должно произойти автоматически за счёт формирования Traffic Engineering Database (TED). Что же это такое?
По сути, это аналог LSDB, но с некоторыми отличиями:
База TED не зависит от протокола и может быть сформирована как ISIS, так и OSPF.
TED уникальна, а LSDB существует для каждого инстанса протокола IGP.
LSDB, сформированная тем или иным IGP (OSPF, ISIS), имеет информацию как об интерфейсах с MPLS, так и просто IP‑интерфейсах. В TED мы имеем только MPLS‑интерфейсы, т. е. TED в общем случае — подмножество LSDB.
TED может быть создана на основе информации, полученной из системы инвентаризации, или NMS.
В принципе, 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, то есть кратчайший путь.
Начнём с того, а какие ограничения мы можем использовать? Вот некоторые примеры:
требуемая полоса пропускания для LSP;
т.н. административные атрибуты: «цвет» линка или Shared Risk Link Groups (SRLG)-affinity bits. Соответствующему LSP можно задать ограничение в виде неиспользования того или иного цвета, тогда такие линки будут исключены из топологии сетевого ТЕ-графа, и CSPF не будет их использовать. Назначение цветов не регламентируется, можно, например, мапить цвета в какие-то характеристики типа задержки и т. п.
На маршрутизаторе мы можем иметь два типа RSVP-TE туннелей (LSP):
статические — конфигурация через CLI;
динамические — полученные извне, например, от РСЕ.
В статическом варианте в темплейте конфигурации туннеля мы должны вручную описать путь для 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 туннели? Не открою ничего нового, таких способа три:
Статическая маршрутизация.
Дать возможность IGP на Head-end (Ingress PE) использовать рассчитанный туннель/LSP для выбора кратчайшего пути (SPF).
Анонсировать туннель/LSP в LSA/LSP апдейтах другим маршрутизаторам, чтобы они также могли его добавить в LSDB и учитывать в своих расчётах SPF.
У последних двух вариантов есть разные названия у разных вендоров, поэтому я оставлю только эти функциональные описания.
Централизованный расчёт туннелей или магия РСЕ
Для начала разговора про PCE попытаемся ответить на вопрос: а зачем вообще нужен какой-то централизованный расчёт туннелей (централизованный ТЕ), если есть чудесный CSPF, который рассчитывает их на основе TED, формируемой из идентичной на всех узлах LSDB?
Для формализованного ответа, приведу выдержку из RFC 4655:
Расчёт путей, создающий большую загрузку ЦПУ (CPU-Intensive):
расчёт набора LSP внутри домена с оптимизацией целевой функции (в качестве примера: минимизация максимальной утилизации линка),
многокритериальный расчёт (например, одновременно задержка и утилизация линка, включение дополнительных ограничений),
расчёт дерева путей точка-многоточка с минимальной метрикой (cost, дерево Штейнера, P2MP LSP не рассматриваются в этой статье);
Частичная видимость, когда маршрутизатор имеет ограниченную видимость сетевой топологии, например, исходящий маршрутизатор (tail-end) находится в другом IGP-домене, соответственно в его TED отсутствует информация о другом домене:
Междоменная (inter-domain) связность. Есть варианты, которые могут помочь в этом случае, об этом поговорим в разделе про междоменные LSP.
Отсутствие TED или использование IGP без ТЕ-расширений:
отсутствие у маршрутизатора возможности создать TED по каким-то причинам (баг, отсутствие лицензии и т.п.);
использование на участке сети IGP (OSPF, ISIS) без ТЕ-расширений.
Отсутствие у сетевых элементов поддержки нужного для ТЕ control plane или вообще способности для маршрутизации. Это характерно для старых (legacy) транспортных устройств, например, работающих на MPLS-TP, когда конфигурация label forwarding state происходит с NMS/OSS. Использование таких устройств — вечный спор коллег, занимающихся транспортом и IP.
Расчёт резервных путей для обеспечения гарантированной полосы пропускания (bandwidth protection) — централизованный расчёт всех резервных путей. Это позволяет сосредоточить знание о доступной полосе в одном месте и разделить его между резервными туннелями/LSP.
Многоуровневые сети (Multi-layer) — сочетание транспортных (оптических, радиорелейных) сетей и сетей с IP-маршрутизацией. В этом случае маршрутизатор ничего не знает о реальной транспортной. Например, речь об оптической топологии, на основе DWDM, и кратчайший путь в терминах L3 может не совпадать с путём на L1 модели OSI/ISO.
Необходимость использования политики по выбору путей (Path selection policy), учитывающий различные виды ограничений и их комбинации.
Возможно, вы сможете добавить к этому списку ещё и какие-то свои сценарии. На мой взгляд, он и так уже достаточен для ответа на поставленный вопрос. На практике встречается либо одна, либо несколько причин из этого списка. И если коротко сформулировать собственный практический ответ на этот вопрос, то он будет таков: как только необходим расчёт путей (туннелей), более сложный, чем просто учёт полосы и цветов линков, и количество туннелей переходят границу по сотням, то скорее всего вам будет необходим централизованный ТЕ.
Ниже я расскажу про ещё один необычный сценарий использования централизованного ТЕ.
Кто же может осуществить на практике централизованный расчёт ТЕ, и какова будет архитектура такой сети?
Ответ на эти вопросы даёт уже упомянутое неоднократно RFC 4655. Приведу его ещё раз: «РСЕ или Path Computation Element — это сущность (компонент, приложение или сетевой узел), способная осуществлять расчёт сетевого пути или маршрута на основе графа сети с применением заданных ограничений». Ёмко и элегантно сформулировано, не правда ли?
РСЕ на практике, на момент написания статьи, встречается в нескольких видах:
функциональность сетевой операционной системы маршрутизатора (например, Cisco IOS-XR);
приложение или часть функциональность вендорского SDN-контроллера;
опенсорс-имплементации, назову лишь пару: OpenDaylight, ONOS;
имплементации т.н. гиперскейлеров (AWS, Google,…, Яндекс с контроллером Сусанин).
Независимо от варианта имплементации, РСЕ решают сформулированную выше задачу, их отличия, по большому счету, заключаются в типах используемых алгоритмов и поддерживаемых SBI (Southbound Interface), плюс разный GUI и набор дополнительных сервисов (например, провижионинг VPN и т.п.).
Вот так выглядит наиболее распространенный случай целевой архитектуры внешнего PСЕ:
Никто и ничто не может запретить нам использовать несколько РСЕ в сети, если это нужно по каким-то причинам. Как правило, это либо очень большой масштаб сети, когда надо заниматься расчётом и провижионингом в десятки тысяч устройств, в разных доменах, жёсткие требования по обеспечению отказоустойчивости, либо случай многоуровневого расчёта, как показано выше, или расчёта LSP в разных доменах по частям. Такая возможность также была сразу продумана в RFC 4655:
Хочу отметить, что может быть и другой вариант объединения РСЕ: т.н. иерархический РСЕ (H-PCE), когда РСЕ одного уровня подключаются своими северными (Northbound) интерфейсами (NBI) к РСЕ более высокого уровня.
Вообще RFC 4655 определяет четыре модели работы РСЕ:
композитная (когда РСЕ размещается на маршрутизаторе, см. пример выше с IOS-XR),
внешняя (отдельная сущность, вроде внешнего SDN-контроллера, наиболее распространенная на практике),
несколько РСЕ используются для расчёта пути (путь разделен на части, например, по разным IGP доменам),
несколько РСЕ используются для расчёта пути, РСЕ взаимодействуют друг с другом для координации расчёта и синхронизации TED.
В Яндексе при разработке Сусанина, мы решили использовать подход, похожий на рекомендуемую RFC 4655 модель с несколькими РСЕ (модель 4), но с некоторыми отличиями.
Я не буду здесь повторять свой доклад с nexthop про наш контроллер, отмечу лишь, что мы использовали распределенную модульную структуру, где каждый модуль отвечает за определённую функцию и распределённое хранилище на основе ZK.
Любопытный читатель может спросить: РСЕ — это конечно здорово, но только как другие устройства сети (маршрутизаторы), которые будут его клиентами, узнают о его существовании, чтобы отсылать ему запросы на расчёт?
Отвечу, что есть два варианта, простой и сложный:
Простой, который мы выбрали в Яндексе, — статическая конфигурация IP-адреса РСЕ на маршрутизаторах.
Более сложный — это динамическое определение наличия РСЕ в сети, путём специальных анонсов в IGP (OSPF Router Information LSA, Capability TLV ISIS).
Для последнего варианта есть ещё дополнительное подспорье — специальные 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 домене, что не всегда целесообразно с точки зрения дизайна, например, в случае внешнего РСЕ. Вопрос реальной поддержки динамического определения в сети РСЕ имеющимися вендорами, я оставляю особо заинтересованным читателям.
Очень важно отметить, что РСЕ могут быть двух типов:
Stateless — не хранят у себя рассчитанные пути и их атрибуты, запросы от клиентов на расчёт пути обрабатываются независимо друг от друга.
Stateful — сохраняет информацию о рассчитанных путях, запросы от клиентов обрабатываются с учётом уже рассчитанных туннелей/LSP.
Современные реализации РСЕ (в т.ч. и на Сусанине) являются stateful.
Надеюсь, что теперь роль и задачи РСЕ стали вам понятны. Но может быть непонятно, а каким образом взаимодействуют клиенты с РСЕ?
Если РСЕ — это, по сути, централизованный элемент или сервер, то как маршрутизаторы или клиенты должны к нему обращаться?
Тут на сцену выходит специально разработанный для этого протокол — Path Computation Element Communication Protocol (PCEP), базовая спецификация которого дана в RFC 5440.
Коль скоро термин РСЕ уже введен в оборот, будет справедливо ввести также термин РСС (Path Computation Client) — клиент, устройство (маршрутизатор), запрашивающее расчёт пути у сервера (РСЕ). Кстати, в случае взаимодействия двух РСЕ, один РСЕ будет сервером, а второй клиентом (РСС).
Перед тем, как рассмотреть структуру РСЕР, давайте остановимся на тех требованиях, которые легли в его основу:
Эквивалентность протокола, как для взаимодействия РСЕ‑PCE, так и РСС‑РСС.
Взаимодействие по типу клиент‑сервер.
Использование существующего отказоустойчивого транспорта, который не должен ограничивать размер РСЕР сообщения.
Наличие сообщения «Запрос на расчёт пути» (Path Computation Request), как минимум, оно должно содержать не менее одного адреса узла‑источника и узла‑приёмника. Адреса не обязательно представляют собой начало и конец LSP, это может быть его часть. Должно поддерживаться включение дополнительных ограничений, в т.ч. задание целевых функций, метрик, цветов линков и т. д.
Наличие сообщения «Ответ на запрос…» (Path Computation Response) c рассчитанным путём, который может быть конвертирован в ERO, поддержка как позитивного ответа, так и негативного.
Надежная и безопасная доставка сообщений.
Поддержка отправки многочисленных запросов и ответов в моменте, приоритезация запросов.
Асинхронные коммуникации: клиент не должен ждать ответа на один запрос перед отправкой следующего.
Расширяемость (в смысле функциональности).
Масштабируемость в смысле поддержки в моменте большого количества: клиентов на один РСЕ, доменов, запросов и ответов и т. д.
Полагаю, что у проницательного читателя после прочтения этих требований уже складывается картина того протокола, который получился на выходе…
Но об основах PCEP мы поговорим уже в следующий раз.