eng
С появлением нового поколения сетей передачи данных аббревиатура SDN (Software Defined Networks) и связанные с этим термином вопросы будоражат умы специалистов и рядовых пользователей. Что нас не устраивает в существующих сетях, какие технологии необходимо использовать для построения сетей будущего и какие новые возможности они нам предоставят? Попробуем разобраться.
Теги: data network sdn
MPLS – стандарт де-факто
Сегодня в сетях передачи данных стандартом де-факто признана технология MPLS (MultiProtocol Label Switching), использующая принцип высокоскоростной коммутации пакетов с использованием меток. Данная архитектура получила широкое распространение не только у операторов связи, но и у большинства корпоративных клиентов, а также в крупных центрах обработки данных. Секрет успеха технологии MPLS прост: вам достаточно один раз на первом пограничном маршрутизаторе (Ingress PE) определить необходимый набор (стек) меток – и дальше ваши пакеты передаются по сети с его использованием, без дополнительного анализа IP-заголовков в изначальном пакете на промежуточных узлах сети.
При помощи технологии MPLS можно реализовать практически любую услугу на сети оператора связи: построить наложенные сети из L2 / L3 VPNов, прозрачно передавать данные различных протоколов (например ATM, Frame Relay, Ethernet, PPP, HDLC) и, наконец, объединять и организовывать взаимодействие между сетями различных операторов (услуги InterAS VPN и Carrier Supporting Carrier). С точки зрения работы маршрутизатора достаточно выполнить всего лишь три действия: push (инкапсулировать определенный набор меток), pop (деинкапсулировать стек меток) и swap (заменить одну метку на другую). Указанный набор инструкций может быть достаточно просто реализован, как программно, с использованием процессоров общего назначения, так и аппаратно, с применением специализированных сетевых процессоров и микросхем. На текущий момент практически любой крупный производитель сетевого оборудования смог реализовать в своем портфолио продукты с поддержкой данной технологии.
Однако у каждой технологии помимо плюсов всегда есть и существенные минусы. Так, корректная работа технологии MPLS требует настройки и внедрения определенного набора сетевых протоколов для распространения маршрутной информации (Link-State протоколы OSPF / IS-IS), обмена метками (LDP / RSVP), а также организации сервисного уровня (MP-BGP / Target-LDP). Иначе сказать, мы имеем классическую проблему взаимодействия человека и машины: с одной стороны – простая организация data-plane, взаимодействия маршрутизаторов, в которых используются три стандартных операции манипуляции с метками MPLS; с другой – cложная организация control-plane, не всегда удобная для восприятия человеком.
Помимо этого, с эволюцией и развитием приложений меняются как требования к сетям передачи данных, так и сама модель взаимодействия приложений с сетью. Если раньше основным требованием и предназначением сети было обеспечение надежной передачи данных приложения из точки А в точку Б, то сейчас необходимо обеспечить передачу данных с определенными характеристиками, например гарантировать определенную полосу пропускания либо минимально допустимую задержку, и, что самое главное, сами приложения зачастую хотят определять путь прохождения пакета по сети, руководствуясь своей внутренней логикой, а не решением промежуточных маршрутизаторов. То есть, если раньше уровень приложений / сервисов и уровень сети существовали независимо друг от друга, и сети было, по сути, не важно, как устроено приложение, а приложению – не важно, как функционирует сеть, то сейчас подход в корне изменился. Между приложениями и сетью требуется наладить взаимодействие для того, чтобы приложение могло отслеживать изменения, происходящие в сети, и своевременно на них реагировать, а сеть – отслеживать новые требования и задачи приложений и адаптироваться к ним.
Новые задачи и решения
Перед инженерами и проектировщиками при разработке новых стандартов для организации сетей передачи данных стояла задача учесть все описанные факты, взять от технологии MPLS все самое лучшее, сохранить простой data-plane и упростить control-plane, при этом обеспечить обратную совместимость, а также учесть новые требования от уровня приложений и сервисов. В 2013 году компания Cisco Systems выступила с инициативой и предложениями по созданию новой архитектуры построения сетей передачи данных, которая получила название Segment Routing.
Технология Segment Routing использует принципы source routing – возможность задать на источнике (например, Ingress PE) путь прохождения пакетов по сети с помощью последовательности сегментов в заголовке самих пакетов. При этом под сегментом понимается описание или инструкция по передаче пакетов из одной точки сети в другую. Например, инструкцией может служить требование доставить трафик до узла N в сети кратчайшим путем, либо используя определенный путь, отвечающий необходимым SLA. Другими словами, весь путь прохождения пакетов изначально определен и описан в заголовке самого пакета, и маршрутизаторы в сети могут передавать трафик, оперируя этим заголовком. Для обеспечения обратной совместимости при формировании нового заголовка в качестве сегментов можно использовать хорошо всем знакомые MPLS-метки (при передаче трафика в сетях МPLS) либо дополнительные заголовки IPv6 Routing Header, определенные стандартом для передачи трафика в сетях, полностью построенных на IPv6. Таким образом, необходимость в разработке, формировании и описании дополнительных новых заголовков отсутствует, а значит, никаких существенных изменений в логике работы маршрутизаторов (в программной и аппаратной части) не требуется, что позволяет маршрутизаторам использовать привычные принципы простого data-plane (операции push, pop и swap) для передачи пакетов.
А как же быть со сложным control-plane? Чтобы ответить на этот вопрос, давайте разберемся, что же представляют собой сегменты. Итак, мы определили, что сегмент – это инструкция по передаче пакета из одной точки сети в другую, и сегменты представляют собой хорошо знакомые нам MPLS-метки. Но для распределения меток в сети должны быть дополнительные протоколы, аналоги LDP и RSVP. Попробуем обойтись без них. Для того чтобы описать любой возможный путь прохождения пакетов в сети оператора связи, нам необходимо знать всего две вещи: идентификаторы узлов (маршрутизаторов), через которые должны пройти пакеты, и идентификаторы интерфейсов на маршрутизаторе, которые связывают друг с другом узлы в сети. Всей этой информацией уже обладают IGP-протоколы маршрутизации. Например, протоколы OSPF и IS-IS хранят полную базу всех элементов сети и связей между этими элементами. Почему бы не использовать эту существующую информацию, добавив к ней только идентификаторы узлов и идентификатор связей между узлами?
В терминологии Segment Routing идентификатором узла в сети является Prefix/Node SID. Этот параметр задается администратором при настройке маршрутизатора, и с точки зрения инструкции при передаче трафика использование Prefix/Node SID будет означать "доставить пакет к узлу кратчайшим путем". Как правило, кратчайший путь определяется в результате работы протоколов маршрутизации IGP. Для data-plane промежуточного маршрутизатора получение метки, содержащей Prefix/Node SID, операция будет равносильна операции swap. Для определения конкретного интерфейса на маршрутизаторе в архитектуре Segment Routing используется значение Adjacency SID. Этот параметр имеет локальное значение в пределах одного маршрутизатора, а значит, может быть рассчитан и назначен автоматически без участия персонала. Применение данного типа сегментов определяет выходной интерфейс на маршрутизаторе, через который необходимо передать пакет. С точки зрения data-plane работы маршрутизатора эта операция будет идентична операции pop.
И Prefix/Node SID, и Adjacency SID – это метки, которые могут быть сигнализированы при использовании IGP-протоколов маршрутизации, драфт стандарта описывает необходимые дополнения для протоколов IS-IS и OSPF. А это значит, что при использовании технологии Segment Routing отсутствует необходимость в дополнительном протоколе распространения меток по сети. Сетевым инженерам не нужно больше настраивать дополнительные протоколы и заботиться об их синхронизации с IGP-протоколами. Меньше ошибок и строчек в конфигурации и существенное снижение человеческого фактора положительным образом сказываются на стабильной работе сети.
Итак, мы определили все необходимые сегменты для передачи данных и разобрались, как распространять данные сегменты в сети оператора. Давайте попробуем построить необходимый путь из одной точки сети в другую. Для построения пути прохождения пакетов нам необходимо определенным образом выстроить сегменты в заголовке и каждый маршрутизатор в сети, чтобы исполнять полученную инструкцию – либо передавая пакет кратчайшим путем до указанного в сегменте узла, либо используя определенный интерфейс для передачи пакета. Таким образом, комбинируя сегменты, мы можем адресовать любой путь прохождения пакетов в сети оператора (рис.1). При этом инструкция Prefix/Node SID (передать пакет до адреса кратчайшим путем) вовсе не означает, что в рассматриваемой топологии данный путь будет определен в единственном экземпляре. Если в рамках определенной топологии либо на определенном участке сети с точки зрения маршрутизатора будет существовать несколько кратчайших путей с одинаковыми метриками (ECMP), то данный маршрутизатор при использовании технологии Segment Routing будет автоматически осуществлять балансировку трафика. Это очень актуально в современных сетях, так как, несмотря на существующие стандарты по передаче трафика в сотни Гбит/с, объемы передаваемой информации неуклонно растут год от года, и автоматическая балансировка нагрузки является неоспоримым премуществом архитектуры Segment Routing. Использование традиционных MPLS-технологий для достижения подобного эффекта потребовало бы устанавливать в сети дополнительные тоннели RSVP TE, которые необходимо отслеживать и периодически проверять их актуальность.
Сценарии применения
Одно из основных преимуществ архитектуры Segment Routing – ее изначальная ориентированность на применение в сетях SDN / NFV. Рассмотрим простой пример. Допустим, имеем сеть оператора связи с 500 маршрутизаторами, каждый из которых имеет по пять интерфейсов для связи с соседями. Если нам требуется описать все возможные пути прохождения трафика в данной сети (Full Mesh), то при использовании Segment Routing таблица коммутации (forwarding table) на каждом из маршрутизаторов будет составлять всего 505 записей (500 идентификаторов соседей Prefix / Node SID и пять идентификаторов интерфейсов Adjacency SID). И данная таблица на каждом из маршрутизаторов будет конечна и постоянна, ведь она не зависит от числа возможных путей прохождения трафика, а определяет лишь число маршрутизаторов в сети и число связей между ними. Разные потоки трафика в сети будут иметь различный размер стека и значения сегментов, но таблица коммутации не будет зависеть от количества потоков в сети. Если решать похожую задачу при помощи протоколов OpenFlow, то каждый отдельный поток трафика необходимо будет программировать на каждом из маршрутизаторов. Это немасштабируемое решение. Похожая ситуация будет возникать при использовании и RSVP TE, и классического MPLS-подхода с Full Mesh RSVP TE. Каждый TE-тоннель будет программировать на промежуточных маршрутизаторах сети отдельную запись в таблице коммутации (TE Midpoint), что в конечном итоге скажется на масштабируемости сети и стоимости промежуточных маршрутизаторов. Не говоря уже о том, что при обрыве какого-то из линков между маршрутизаторами и хаотическом перестроении RSVP-тоннелей какое-то время в сети будет существовать "шторм", вызванный обменом сигнальными сообщениями протокола RSVP, и control-plane ресурсы маршрутизатора всецело будут заняты расчетом оптимальных топологий.
Рассмотрим еще один сценарий применения архитектуры Segment Routing в сетях SDN. Допустим, имеем определенную топологию (рис.2) и приложение, которому необходимо гарантировать определенную полосу (например, 2 Гбит/с) при прохождении через сеть оператора связи. Промежуточным звеном для связи приложения с сетью выступает контроллер SDN, который, с одной стороны, анализирует требования SLA, предъявляемые приложением, а с другой – имеет представление об использованной сетевой топологии и загрузке каналов. В качестве данного контроллера может выступать как OpenSource-решение, так и специализированный контроллер Wan Automation Engine производства компании Cisco Systems, который предоставляет необходимые API для сервисов и приложений заказчика.
Проанализировав требование приложений и текущую ситуацию в сети оператора связи (допустим, канал между маршрутизаторами С и D перегружен и не может обеспечить необходимый SLA), SDN-контроллер может рассчитать оптимальный путь прохождения трафика в сети и сигнализировать необходимый стек меток, который маршрутизатор A сможет назначить для требуемого потока данных от приложения. Для разных приложений набор требований, а следовательно, и путь прохождения трафика могут отличаться, и контроллер сможет каждый раз гибко формировать требуемый набор сегментов. При этом никакие дополнительные изменения внутри сети производить не нужно. Нам не требуется программировать каждый из маршрутизаторов отдельно для пропуска трафика от того или иного приложения, и обмен сигнальной информацией между узлами сети также будет минимален. Простота решения достигается за счет того, что весь необходимый набор сегментов, который и будет адресовать путь прохождения пакета по сети, изначально содержится в самом заголовке пакета. В этом и заключается красота и гибкость архитектуры Segment Routing.
Как и любая другая новая технология, Segment Routing активно развивается. На текущий момент сформирована отдельная рабочая группа в IETF, которая занимается вопросами стандартизации и адаптации данной технологии. В настоящее время в работе данной группы находится более 25 драфтов со сценариями использования Segment Routing и более 75% этих драфтов написаны и представлены инженерами Cisco Systems, и весь необходимый функционал в полном объеме присутствует во флагманских маршрутизаторах ASR9000, предназначенных для операторов связи и крупных корпоративных клиентов.
В заключение
Хотелось бы добавить, что сами по себе сегменты, описанные в Segment Routing, лишены собственной семантики и лишь определяют набор действий или инструкций по доставке пакетов. Это может быть как указание передать пакет по сети кратчайшим путем, так и любое другое действие. В рамках статьи описаны возможности Segment Routing по отношению к сетям передачи данных и взаимодействие в рамках IGP-протоколов. Один из драфтов, определенных в рамках рабочей группы IETF, описывает применения Segment Routing и сегментов для уровня взаимодействия между различными автономными системами и протокола BGP. При использовании Segment Routing мы можем гибко формировать политику прохождения трафика через все участки сети, и если каждый из участков (центр обработки данных, сеть агрегации, ядро сети, пиринг-периметр) требовал применения специализированных технологий и протоколов, то при использовании Segment Routing достаточно будет определить корректный набор сегментов в изначальном пакете, чтобы правильно сформировать путь прохождения пакета (рис.3).
Помимо этого, сегментом может быть описан определенный сервис или же виртуализированная сетевая функция (NFV), и порядок сегментов, представленный в стеке, будет определять порядок прохождения пакета и порядок применения сетевых функций к данному пакету в рамках концепции SDN/NFV. Это открывает широкие возможности для использования Segment Routing при организации цепочки сервисов (service chain) на пути прохождения трафика и появления сервисов и приложений нового типа (рис.4).
Одна из задач SDN-cетей нового поколения – убрать барьеры на пути между приложениями, абонентскими сервисами и конечными пользователями, сделать их взаимодействие более удобным, простым и понятным. Ведь наша жизнь не стоит на месте, и для того чтобы идти в ногу с прогрессом, требуется порой по-новому взглянуть на старые вещи и технологии, стряхнуть с них пыль и вдохнуть новую жизнь в классические подходы передачи данных. Архитектура Segment Routing – одно из ярких проявлений подобного подхода.
Сегодня в сетях передачи данных стандартом де-факто признана технология MPLS (MultiProtocol Label Switching), использующая принцип высокоскоростной коммутации пакетов с использованием меток. Данная архитектура получила широкое распространение не только у операторов связи, но и у большинства корпоративных клиентов, а также в крупных центрах обработки данных. Секрет успеха технологии MPLS прост: вам достаточно один раз на первом пограничном маршрутизаторе (Ingress PE) определить необходимый набор (стек) меток – и дальше ваши пакеты передаются по сети с его использованием, без дополнительного анализа IP-заголовков в изначальном пакете на промежуточных узлах сети.
При помощи технологии MPLS можно реализовать практически любую услугу на сети оператора связи: построить наложенные сети из L2 / L3 VPNов, прозрачно передавать данные различных протоколов (например ATM, Frame Relay, Ethernet, PPP, HDLC) и, наконец, объединять и организовывать взаимодействие между сетями различных операторов (услуги InterAS VPN и Carrier Supporting Carrier). С точки зрения работы маршрутизатора достаточно выполнить всего лишь три действия: push (инкапсулировать определенный набор меток), pop (деинкапсулировать стек меток) и swap (заменить одну метку на другую). Указанный набор инструкций может быть достаточно просто реализован, как программно, с использованием процессоров общего назначения, так и аппаратно, с применением специализированных сетевых процессоров и микросхем. На текущий момент практически любой крупный производитель сетевого оборудования смог реализовать в своем портфолио продукты с поддержкой данной технологии.
Однако у каждой технологии помимо плюсов всегда есть и существенные минусы. Так, корректная работа технологии MPLS требует настройки и внедрения определенного набора сетевых протоколов для распространения маршрутной информации (Link-State протоколы OSPF / IS-IS), обмена метками (LDP / RSVP), а также организации сервисного уровня (MP-BGP / Target-LDP). Иначе сказать, мы имеем классическую проблему взаимодействия человека и машины: с одной стороны – простая организация data-plane, взаимодействия маршрутизаторов, в которых используются три стандартных операции манипуляции с метками MPLS; с другой – cложная организация control-plane, не всегда удобная для восприятия человеком.
Помимо этого, с эволюцией и развитием приложений меняются как требования к сетям передачи данных, так и сама модель взаимодействия приложений с сетью. Если раньше основным требованием и предназначением сети было обеспечение надежной передачи данных приложения из точки А в точку Б, то сейчас необходимо обеспечить передачу данных с определенными характеристиками, например гарантировать определенную полосу пропускания либо минимально допустимую задержку, и, что самое главное, сами приложения зачастую хотят определять путь прохождения пакета по сети, руководствуясь своей внутренней логикой, а не решением промежуточных маршрутизаторов. То есть, если раньше уровень приложений / сервисов и уровень сети существовали независимо друг от друга, и сети было, по сути, не важно, как устроено приложение, а приложению – не важно, как функционирует сеть, то сейчас подход в корне изменился. Между приложениями и сетью требуется наладить взаимодействие для того, чтобы приложение могло отслеживать изменения, происходящие в сети, и своевременно на них реагировать, а сеть – отслеживать новые требования и задачи приложений и адаптироваться к ним.
Новые задачи и решения
Перед инженерами и проектировщиками при разработке новых стандартов для организации сетей передачи данных стояла задача учесть все описанные факты, взять от технологии MPLS все самое лучшее, сохранить простой data-plane и упростить control-plane, при этом обеспечить обратную совместимость, а также учесть новые требования от уровня приложений и сервисов. В 2013 году компания Cisco Systems выступила с инициативой и предложениями по созданию новой архитектуры построения сетей передачи данных, которая получила название Segment Routing.
Технология Segment Routing использует принципы source routing – возможность задать на источнике (например, Ingress PE) путь прохождения пакетов по сети с помощью последовательности сегментов в заголовке самих пакетов. При этом под сегментом понимается описание или инструкция по передаче пакетов из одной точки сети в другую. Например, инструкцией может служить требование доставить трафик до узла N в сети кратчайшим путем, либо используя определенный путь, отвечающий необходимым SLA. Другими словами, весь путь прохождения пакетов изначально определен и описан в заголовке самого пакета, и маршрутизаторы в сети могут передавать трафик, оперируя этим заголовком. Для обеспечения обратной совместимости при формировании нового заголовка в качестве сегментов можно использовать хорошо всем знакомые MPLS-метки (при передаче трафика в сетях МPLS) либо дополнительные заголовки IPv6 Routing Header, определенные стандартом для передачи трафика в сетях, полностью построенных на IPv6. Таким образом, необходимость в разработке, формировании и описании дополнительных новых заголовков отсутствует, а значит, никаких существенных изменений в логике работы маршрутизаторов (в программной и аппаратной части) не требуется, что позволяет маршрутизаторам использовать привычные принципы простого data-plane (операции push, pop и swap) для передачи пакетов.
А как же быть со сложным control-plane? Чтобы ответить на этот вопрос, давайте разберемся, что же представляют собой сегменты. Итак, мы определили, что сегмент – это инструкция по передаче пакета из одной точки сети в другую, и сегменты представляют собой хорошо знакомые нам MPLS-метки. Но для распределения меток в сети должны быть дополнительные протоколы, аналоги LDP и RSVP. Попробуем обойтись без них. Для того чтобы описать любой возможный путь прохождения пакетов в сети оператора связи, нам необходимо знать всего две вещи: идентификаторы узлов (маршрутизаторов), через которые должны пройти пакеты, и идентификаторы интерфейсов на маршрутизаторе, которые связывают друг с другом узлы в сети. Всей этой информацией уже обладают IGP-протоколы маршрутизации. Например, протоколы OSPF и IS-IS хранят полную базу всех элементов сети и связей между этими элементами. Почему бы не использовать эту существующую информацию, добавив к ней только идентификаторы узлов и идентификатор связей между узлами?
В терминологии Segment Routing идентификатором узла в сети является Prefix/Node SID. Этот параметр задается администратором при настройке маршрутизатора, и с точки зрения инструкции при передаче трафика использование Prefix/Node SID будет означать "доставить пакет к узлу кратчайшим путем". Как правило, кратчайший путь определяется в результате работы протоколов маршрутизации IGP. Для data-plane промежуточного маршрутизатора получение метки, содержащей Prefix/Node SID, операция будет равносильна операции swap. Для определения конкретного интерфейса на маршрутизаторе в архитектуре Segment Routing используется значение Adjacency SID. Этот параметр имеет локальное значение в пределах одного маршрутизатора, а значит, может быть рассчитан и назначен автоматически без участия персонала. Применение данного типа сегментов определяет выходной интерфейс на маршрутизаторе, через который необходимо передать пакет. С точки зрения data-plane работы маршрутизатора эта операция будет идентична операции pop.
И Prefix/Node SID, и Adjacency SID – это метки, которые могут быть сигнализированы при использовании IGP-протоколов маршрутизации, драфт стандарта описывает необходимые дополнения для протоколов IS-IS и OSPF. А это значит, что при использовании технологии Segment Routing отсутствует необходимость в дополнительном протоколе распространения меток по сети. Сетевым инженерам не нужно больше настраивать дополнительные протоколы и заботиться об их синхронизации с IGP-протоколами. Меньше ошибок и строчек в конфигурации и существенное снижение человеческого фактора положительным образом сказываются на стабильной работе сети.
Итак, мы определили все необходимые сегменты для передачи данных и разобрались, как распространять данные сегменты в сети оператора. Давайте попробуем построить необходимый путь из одной точки сети в другую. Для построения пути прохождения пакетов нам необходимо определенным образом выстроить сегменты в заголовке и каждый маршрутизатор в сети, чтобы исполнять полученную инструкцию – либо передавая пакет кратчайшим путем до указанного в сегменте узла, либо используя определенный интерфейс для передачи пакета. Таким образом, комбинируя сегменты, мы можем адресовать любой путь прохождения пакетов в сети оператора (рис.1). При этом инструкция Prefix/Node SID (передать пакет до адреса кратчайшим путем) вовсе не означает, что в рассматриваемой топологии данный путь будет определен в единственном экземпляре. Если в рамках определенной топологии либо на определенном участке сети с точки зрения маршрутизатора будет существовать несколько кратчайших путей с одинаковыми метриками (ECMP), то данный маршрутизатор при использовании технологии Segment Routing будет автоматически осуществлять балансировку трафика. Это очень актуально в современных сетях, так как, несмотря на существующие стандарты по передаче трафика в сотни Гбит/с, объемы передаваемой информации неуклонно растут год от года, и автоматическая балансировка нагрузки является неоспоримым премуществом архитектуры Segment Routing. Использование традиционных MPLS-технологий для достижения подобного эффекта потребовало бы устанавливать в сети дополнительные тоннели RSVP TE, которые необходимо отслеживать и периодически проверять их актуальность.
Сценарии применения
Одно из основных преимуществ архитектуры Segment Routing – ее изначальная ориентированность на применение в сетях SDN / NFV. Рассмотрим простой пример. Допустим, имеем сеть оператора связи с 500 маршрутизаторами, каждый из которых имеет по пять интерфейсов для связи с соседями. Если нам требуется описать все возможные пути прохождения трафика в данной сети (Full Mesh), то при использовании Segment Routing таблица коммутации (forwarding table) на каждом из маршрутизаторов будет составлять всего 505 записей (500 идентификаторов соседей Prefix / Node SID и пять идентификаторов интерфейсов Adjacency SID). И данная таблица на каждом из маршрутизаторов будет конечна и постоянна, ведь она не зависит от числа возможных путей прохождения трафика, а определяет лишь число маршрутизаторов в сети и число связей между ними. Разные потоки трафика в сети будут иметь различный размер стека и значения сегментов, но таблица коммутации не будет зависеть от количества потоков в сети. Если решать похожую задачу при помощи протоколов OpenFlow, то каждый отдельный поток трафика необходимо будет программировать на каждом из маршрутизаторов. Это немасштабируемое решение. Похожая ситуация будет возникать при использовании и RSVP TE, и классического MPLS-подхода с Full Mesh RSVP TE. Каждый TE-тоннель будет программировать на промежуточных маршрутизаторах сети отдельную запись в таблице коммутации (TE Midpoint), что в конечном итоге скажется на масштабируемости сети и стоимости промежуточных маршрутизаторов. Не говоря уже о том, что при обрыве какого-то из линков между маршрутизаторами и хаотическом перестроении RSVP-тоннелей какое-то время в сети будет существовать "шторм", вызванный обменом сигнальными сообщениями протокола RSVP, и control-plane ресурсы маршрутизатора всецело будут заняты расчетом оптимальных топологий.
Рассмотрим еще один сценарий применения архитектуры Segment Routing в сетях SDN. Допустим, имеем определенную топологию (рис.2) и приложение, которому необходимо гарантировать определенную полосу (например, 2 Гбит/с) при прохождении через сеть оператора связи. Промежуточным звеном для связи приложения с сетью выступает контроллер SDN, который, с одной стороны, анализирует требования SLA, предъявляемые приложением, а с другой – имеет представление об использованной сетевой топологии и загрузке каналов. В качестве данного контроллера может выступать как OpenSource-решение, так и специализированный контроллер Wan Automation Engine производства компании Cisco Systems, который предоставляет необходимые API для сервисов и приложений заказчика.
Проанализировав требование приложений и текущую ситуацию в сети оператора связи (допустим, канал между маршрутизаторами С и D перегружен и не может обеспечить необходимый SLA), SDN-контроллер может рассчитать оптимальный путь прохождения трафика в сети и сигнализировать необходимый стек меток, который маршрутизатор A сможет назначить для требуемого потока данных от приложения. Для разных приложений набор требований, а следовательно, и путь прохождения трафика могут отличаться, и контроллер сможет каждый раз гибко формировать требуемый набор сегментов. При этом никакие дополнительные изменения внутри сети производить не нужно. Нам не требуется программировать каждый из маршрутизаторов отдельно для пропуска трафика от того или иного приложения, и обмен сигнальной информацией между узлами сети также будет минимален. Простота решения достигается за счет того, что весь необходимый набор сегментов, который и будет адресовать путь прохождения пакета по сети, изначально содержится в самом заголовке пакета. В этом и заключается красота и гибкость архитектуры Segment Routing.
Как и любая другая новая технология, Segment Routing активно развивается. На текущий момент сформирована отдельная рабочая группа в IETF, которая занимается вопросами стандартизации и адаптации данной технологии. В настоящее время в работе данной группы находится более 25 драфтов со сценариями использования Segment Routing и более 75% этих драфтов написаны и представлены инженерами Cisco Systems, и весь необходимый функционал в полном объеме присутствует во флагманских маршрутизаторах ASR9000, предназначенных для операторов связи и крупных корпоративных клиентов.
В заключение
Хотелось бы добавить, что сами по себе сегменты, описанные в Segment Routing, лишены собственной семантики и лишь определяют набор действий или инструкций по доставке пакетов. Это может быть как указание передать пакет по сети кратчайшим путем, так и любое другое действие. В рамках статьи описаны возможности Segment Routing по отношению к сетям передачи данных и взаимодействие в рамках IGP-протоколов. Один из драфтов, определенных в рамках рабочей группы IETF, описывает применения Segment Routing и сегментов для уровня взаимодействия между различными автономными системами и протокола BGP. При использовании Segment Routing мы можем гибко формировать политику прохождения трафика через все участки сети, и если каждый из участков (центр обработки данных, сеть агрегации, ядро сети, пиринг-периметр) требовал применения специализированных технологий и протоколов, то при использовании Segment Routing достаточно будет определить корректный набор сегментов в изначальном пакете, чтобы правильно сформировать путь прохождения пакета (рис.3).
Помимо этого, сегментом может быть описан определенный сервис или же виртуализированная сетевая функция (NFV), и порядок сегментов, представленный в стеке, будет определять порядок прохождения пакета и порядок применения сетевых функций к данному пакету в рамках концепции SDN/NFV. Это открывает широкие возможности для использования Segment Routing при организации цепочки сервисов (service chain) на пути прохождения трафика и появления сервисов и приложений нового типа (рис.4).
Одна из задач SDN-cетей нового поколения – убрать барьеры на пути между приложениями, абонентскими сервисами и конечными пользователями, сделать их взаимодействие более удобным, простым и понятным. Ведь наша жизнь не стоит на месте, и для того чтобы идти в ногу с прогрессом, требуется порой по-новому взглянуть на старые вещи и технологии, стряхнуть с них пыль и вдохнуть новую жизнь в классические подходы передачи данных. Архитектура Segment Routing – одно из ярких проявлений подобного подхода.
Отзывы читателей
