Разные подходы к балансировке трафика

Технологии MPLS сегодня стали де-факто стандартом построения сетей операторов связи. Некоторые участники начальных разработок утверждают, что работа была направлена на получение протокола с фиксированной длинной заголовка чтобы упростить процесс принятия решений маршрутизации, однако революционных изменений в этом смысле не произошло, а после после появления аппаратных реализаций коммутационных чипов проблема производительности отошла на второй план. Зато по мере того как стандарт обрастал мышцами, становилось понятно, что применение нескольких меток, названных впоследствии стеком, позволяет взглянуть на MPLS как на технологию с унифицированными методами предоставления и обеспечения сервисов. Так, метки в стеке условно поделили на сервисные и транспортные. Для больших сетей этого оказалось недостаточно и вскоре появилась собственная иерархия транспортных меток. Транзитные маршрутизаторы в общем не обязаны понимать какой именно сервис они передают, их задача в самом общем смысле ограничивается работой с верхней меткой своей иерархии, а что там находится внутри стека совершенно не их забота. Такой подход позволяет транзитным маршруитзаторам передавать трафик сотен тысяч и даже миллионов потоков разных сервисов.

Казалось бы, чего еще желать... правило «разделяй и властвуй» работает безотказно, но вот эффективно разделять как раз не очень то получалось, в том смысле, что трафик хочется балансировать как можно равномернее в рамках ограниченного количества каналов связи силами неторопливых, с точки зрения изменений, аппаратных решений. В статье вы найдете некоторые аспекты разных методов решения этой задачи.

LDP, на первый взгляд, вместе с парадигмой Hop-by-Hop destination based routing наследует ECMP возможности IGP, однако вместе с тем наследуются и некоторые особенности балансировки, присущие IP миру. IP маршрутизаторы ожидают увидеть внутри пакета то, что им хорошо знакомо, — потенциально высоко энтропийные заголовки сетевого и транспортного уровней. Их легко разобрать и, при большом количестве потоков, распределение выглядит вполне равномерным. Сложность применения этого правила в MPLS мире состоит в том, что транзитный LSR, заглянув внутрь стека, не всегда находит там IP пакет, часто под транспортной меткой находится сервисная, например VPNv4, Labeled Unicast, VPWS, VPLS или EVPN, зачастую с более низкой энтропией, поэтому такая странная идея, как инспекция транзитными маршрутизаторами всего стека меток и даже упакованного в стек пакета/фрейма, стала вынужденной необходимостью. Если коммутационный чип умеет это делать на стеке требуемой глубины — хорошо, если нет — никакой балансировки на нем не получится, надо менять или наполнение стека (дизайн сети) или чип коммутации, так как одно не соответствует возможностям другого.

Сложности, связанные с необходимостью инспекцией всего стека, можно решить другим способом. Для этого в точке предоставления сервиса в стек добавляются метки повышающие энтропийность. Стандарты Flow Aware Transport и Entropy Label как раз про это, но как будто по закону сохранения энергии, снизив требования к транзитным маршрутизаторам, стандарты повышают требований к пограничным. Любой коммутационный чип может делать операцию push конечное число раз. В стек за один проход помимо транспортных и сервисных меток нужно поместить от одной до двух энтропийных, это получается не у всех чипов и не во всех случаях, поэтому эффективность балансировки MPLS трафика в LDP домене зависит от аппаратной реализации коммутационных чипов, длинны стека и величины его энтропийности.

Distributed RSVP-TE решает задачу балансировки совсем другим методом. Равномерность распределения тут зависит не столько от возможностей транзитных маршрутизаторов, сколько от качества решения оптимизационной задачи граничными маршрутизаторами, каждый из которых рассчитывает пути до соседей с учетом текущего уровня утилизации каналов и характеристик трафика. Если расчет удается, маршрутизатор сообщает о нем соседям, чтобы те зарезервировали часть полосы соответствующих каналов и начинает использовать новый путь. Слово «если» написано не случайно, дело в том, что решение этой задачи очень сильно зависит от входных данных и динамического состояния системы. Так как каждый маршрутизатор прокладывает пути, учитывая только собственные пожелания, глобальная оптимизация вряд ли может быть достигнута. Маршрутизатор может влиять на уже установленные пути только с помощью setup и hold приоритетов, назначение приоритетов не является тривиальной задачей и есть несколько подходов к ее решению (приоритет по полосе, приоритет по типу трафика и т.д.). Так как каждый из подходов преследует узкие цели, а средства автоматизации этого процесса отсутствуют, классический RSVP-TE сложно назвать простой технологией со всеобщей применимостью. Если узлов в сети не много, а полоса некоторых путей близка к канальной емкости, легко получить сеть с фрагментированной утилизацией. Поэтому на практике обычно избегают чрезмерного раздутия путей за счет расчета нескольких параллельных путей или используют подход Sevice Transport Planes когда несколько путей между маршрутизаторами используются для разных видов и экземпляров сервисов. Это позволяет ровнее заполнять каналы и повышает вероятность успешной установки путей, но требует значительного объема ручной работы. Ни сколько не преуменьшая возможностей RSVP-TE, я все же считаю что этому подходу не хватает простоты.

Centralized RSVP-TE это шаг в светлое будущее по дороге SDN, вместо локального расчета путей в условиях ограниченной видимости появляется умный контроллер, который видит весь MPLS домен как на ладони. Контроллер может рассчитать оптимальные пути даже если для этого нужно изменить маршруты уже имеющихся путей, например перегруппировать их, освободить часть полосы. После расчета контролер по протоколу PCEP сообщает маршрутизаторам результат, и те бесшовно перестраивают состояние сети. Проблема inter-area путей тут решена окончательно и бесповоротно, контролер может получать TE информацию изо всех сегментов сети, используя BGP Link-State NLRI. Приятно наблюдать за развитием технологий, на сегодняшний момент есть несколько реализаций PCE контроллера, а вот с выбором моделей маршрутизаторов, поддерживающих PCE, дела обстоят сложнее, пока производители не спешат массово добавлять поддержку этого метода.

Centralized SPRING-TE потенциально самый функциональный, гибкий и масштабируемый подход из перечисленных, это решение еще плотнее использует контроллер, по сути весь мыслительный процесс проходит именно там. Стек меток в данном случае выполняет роль инструкций для транзитных маршрутизаторов. Получив тем или иным образом путь или пути, ingress устройство делит потоки трафика используя разное наполнение стека, а транзитные маршрутизаторы выполняют только простые операции swap/pop. Учитывая, что наполнение стека длинным набором инструкций может вызвать вопросы к аппаратным реализациям коммутационны чипов, идея Centralized SPRING-TE очень гармонично смотрится в среде DC с mpls capable серверами, где погружение меток в стек лимитировано не так жестко. На текущий момент, общего мнения по механизмам резервирования полосы еще не выработано. Будет ли это реализовано в ближайшее время, пока не понятно, разработки в этом направлении только ведутся.

Multipath LSP. Некоторое время назад, небезызвестный Kireeti Kompella попытался объединить RSVP-TE с ECMP балансировкой. Получился довольно интересный драфт [Multi-path Label Switched Paths Signaled Using RSVP-TE]. Суть метода точно описывается фразой ослика Иа, о том, как просто спущенный воздушный шарик может быть помещен в пустой горшок. Вместо того, чтобы сигнализировать один толстый путь ingress, маршрутизатор обсчитывает несколько менее требовательных к полосе путей (sub-LSP). В этом процессе текущая утилизация каналов и их топология определяет количество sub-LSP, и резервируемую под них полосу. В зависимости от типа sub-LSP трафик можно балансировать равномерно по всем путям или, в соответствии с зарезервированной полосой. Во втором случае к коммутационным чипам транзитных узлов не предъявляются какие-то серьезные требований, так как решение о выборе пути лежит исключительно на ingress маршрутизаторе. Этот подход мне видится очень полезным, так как может быть реализован на относительно скромной транзитной сети без особенной ручной работы инженеров или большого контроллера, поэтому детали драфта и его реализации будут описаны в следующей статье.