Контроллер для T-SDN05.02.2016 15:18

Уже никого не удивишь стартапами и разработками в области software-defined networks (SDN) — тема широко исследуется как крупными мировыми корпорациями, так и open source сообществами.

Однако до недавнего времени практически все разработки были направлены на управление инфраструктурой дата-центров, и еще немногим более года назад мало кто верил, что концепция SDN сможет быть применена в транспортных сетях (transport networks).

В октябре 2015 года контроллер T-SDN (transport software-defined networks) компании NetCracker был развернут на сети одного из европейских операторов. Контроллер автоматизировал значительную часть сетевых операций и, как следствие, позволил оператору значительно экономить время — сотни часов, которые инженеры тратили на настройку сети и выделение сервиса.

Сетевые элементы внутри доменов включали платы ROADM/WSS, которые фактически являются перенастраиваемыми оптическими мультиплексорами ввода-вывода и позволяют изменять пути сигнала между сетевыми элементами. Междоменные соединения поднимались между клиентскими портами, эти порты находятся на платах, называемых транспондерами (оптический транспондер — устройство, обеспечивающее интерфейс между оборудованием оконечного доступа и линией WDM). В нашем случае использовались транспондеры с десятью 10Гбит/с (IEEE 802.3ae) клиентскими интерфейсами и агрегирующим ODU4. ODU — это контейнер с данными, обеспечивающий контроль этих данных на всем пути следования и являющийся частью технологии OTN (optical transport network). Тестовая оптическая сеть могла передавать до 80 таких контейнеров в одном физическом волокне, скорость каждого была равна 100Гбит/с.

Контроллер позволил поддержать в сети следующие функции:

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

Попробуем детальнее разобраться в том, что же вкладывают в понятие T-SDN его архитекторы и идейные вдохновители.

Основной идеей T-SDN, так же как и в SDN для дата-центров, является разделение плоскости передачи данных (data plane) и контрольной плоскости (control plane), которое реализуется через создание единого управляющего контроллера, взаимодействующего с сетевыми устройствами некоторого домена транспортной сети. Над контроллером находится уровень приложений (SDN application layer), общающийся с контроллером по определенному интерфейсу. Благодаря тому, что контроллер знает все о структуре своего домена, появляются дополнительные возможности для улучшения работы сети. Для некоторых из них уже существуют решения в различных протоколах, но T-SDN может значительно улучшить уже существующие подходы.

Итак, что же предлагает T-SDN:

Упрощение операций по работе с транспортной сетью.
Предполагается, что запросить сервис у провайдера будет так же просто, как сделать заказ в интернет-магазине. Как только заказ сделан, контроллер автоматически переконфигурирует все устройства и выделит необходимые ресурсы. Таким образом, клиент получит необходимый сервис за считанные минуты.
Оптимальное использование пропускной способности.
Оптимизация использования пропускной способности канала (или, как еще говорят, оптимальная утилизация канала) — задача далеко не новая. Однако полноценного решения для динамического распределения клиентских каналов в транспортной сети до сих пор не существует, и предполагается, что в будущем решение этой задачи возьмет на себя транспортный контроллер.
В качестве примера рассмотрим такой случай. Клиентский траффик проходит между оптическими устройствами A и B двумя путями. Голубой пунктир — оптическое волокно, черные линии — клиентский канал. Графики показывают, какая часть канала занята, а какая свободна — красный и зеленый цвета соответственно.
Теперь представим, что нужно разместить новый клиентский канал — больший по емкости, занимающий 50% пропускной способности соединения. Для этого можно, например, провести один из каналов идущих сверху по нижнему пути, и таким образом освободить 50% соединения.
Эту операцию нужно провести так, чтобы существующий клиент не заметил, что его траффик теперь идет другим путем — даже кратковременный отказ в обслуживании или ухудшение качества услуг (QoS) неприемлемы. Такое перераспределение каналов возможно, но на данный момент оно выполняется инженерами в ручном режиме, занимает немало времени и подвержено ошибкам. Контроллер же потенциально может автоматизировать этот процесс. Нужно отметить, что использование пропускной способности на 100% в реальности невозможно, цифры приведены лишь для иллюстрации проблемы. В действительности показатель утилизации обычно составляет порядка 80–90%.
Пропускная способность по запросу (bandwidth on demand) — автоматическое увеличение пропускной способности клиентского сервиса, в случае если объем траффика превышает емкость купленного им канала. Такое поведение позволит передавать данные с большей скоростью в течение небольшого промежутка времени, а также предотвратит сброс пакетов в случае пиковых нагрузок. Пропускная способность по запросу не потребует от клиента больших финансовых вложений — оплатить нужно будет только тот промежуток времени, в течение которого пропускная способность была увеличена.
Построение оптимальных маршрутов в транспортных сетях.
Централизованное управление сетью дает возможность оптимально подбирать маршрут для прокладки сервиса с учетом разнообразных метрик и требований.
Высокий уровень надежности и доступности сервиса (high availability).
Автоматическое управление позволяет быстро реагировать на сбои в сети. Контроллер поддерживает любые способы защитного резервирования маршрута для быстрого восстановления сервиса при сбоях.
Безопасное конфигурирование сети через высокоуровневые приложения.
При изменении конфигурации устройства сетевым администратором возможны ошибки, которые могут привести к серьезным последствиям, в том числе долгосрочным отказам в обслуживании. Известно немало случаев значительных сбоев в глобальной сети из-за ошибок инженеров — чего стоит только утечка маршрутов (route leak) 12 июня 2015 года, затронувшая значительную часть Интернета. Использование высокоуровневых визуальных приложений позволяет сильно снизить вероятность неправильной конфигурации — большая часть скрупулезной работы выполняется автоматически.
Возможность легко масштабировать систему (scalability).
Увеличения числа устройств и управляющих приложений выполняется без дополнительных настроек контроллера.
Эти и другие заявленные возможности T-SDN сейчас вызывают самую разную реакцию, в том числе жесткую критику и недоверие, но реальное понимание ситуации могут дать только полноценные исследования, прототипирование и пилотные запуски программно-конфигурируемых транспортных сетей.
Сотрудники компании NetCracker в Москве, Санкт-Петербурге и Нижнем Новгороде при поддержке инженеров из компании NEC в настоящий момент ведут активную работу по исследованию T-SDN и развитию функциональности контроллера T-SDN.

При разработке контроллера мы ориентируемся на поддержку следующих требований:

полное управление сильно распределенной транспортной сетью крупного провайдера;
прокладывание маршрута по всей сети провайдера;
оптимизация маршрута с учетом требований и различных метрик;
поддержка мультивендорной сети (сети, построенной на устройствах различных производителей);
пропускная способность по запросу;
высокий уровень надежности и доступности сервиса;
возможность легко масштабировать систему;
оптимальное использование пропускной способности.

В компании NetCracker ведется разработка контроллера, который мог бы в одиночку контролировать сеть провайдера любого уровня. Требования к производительности для управления такой сетью очень высоки, поэтому контроллер имеет иерархическую структуру, состоящую из контроллеров двух типов — доменный контроллер T-SDN (контроллер нижнего уровня) и собственно контроллер T-SDN (контроллер верхнего уровня). Доменный контроллер управляет только частью сети, то есть некоторым доменом, и берет на себя функции управления непосредственно транспортными сетевыми устройствами. Контроллер верхнего уровня управляет не сетевыми устройствами, а доменными контроллерами, таким образом абстрагируясь от общения с сетевой инфраструктурой, что позволяет повысить производительность системы. Задачи по управлению сетью декомпозируются и делегируются котроллерам нижнего уровня. Контроллер верхнего уровня принимает данные о работе домена, обрабатывает их и предпринимает дальнейшие действия.

На схеме ниже показаны сети, управляемые доменным контроллером T-SDN (управление одним доменом) и контроллером T-SDN верхнего уровня (управление всеми доменами).

Проще говоря, контроллер верхнего уровня «видит» целую группу устройств как одно устройство. Такая концепция, с одной стороны, позволяет избежать значительных накладных расходов и улучшить производительность, с другой — дает возможность просматривать сеть целиком, вместе с кросс-доменными соединениями, которые не могут быть проконтролированы на доменном уровне, так как не находятся в зоне видимости доменного контроллера T-SDN. Такой подход позволяет прокладывать клиентский сервис по всей сети: от точки входа в сеть провайдера, до точки выхода из нее, и, как следствие, эффективно управлять утилизацией, оптимизацией прокладки пути, надежностью и доступностью сервиса.

Компанией NetCracker совместно с NEC разработана архитектура контроллера T-SDN. Архитектура представляет собой иерархическую структуру. На нижнем уровне находится сетевая инфраструктура, устройства которой по некоторому API связываются с доменными, в том числе проприетарными контроллерами SDN. Далее идет уровень доменных контроллеров, который, в свою очередь, подключен к единому контроллеру T-SDN верхнего уровня. На самом верхнем уровне находятся приложения, предоставляющие функции мониторинга и конфигурирования.

Архитектура контроллера, разработанного компанией NetCracker, целиком вписывается в эталонную архитектуру контроллера SDN, предложенную организацией Open Networking Foundation в 2014 году (ONF Архитектура). Это подтверждает полное соответствие нашего контроллера T-SDN мировым стандартам. Жизнеспособность такой архитектуры уже неоднократно проверена в сетевой лаборатории компании NetCracker на оборудовании различных производителей.

Контроллер имеет следующие основные модули:

прокладка маршрутов (path provisioning) включает в себя операции построения маршрутов на логическом уровне, а также непосредственно взаимодействует с Медиатором (Mediation), от которого получает обработанную информацию с подключенных доменных контроллеров;

вычисление пути (path computation) отвечает за определение маршрута на сетевом графе с учетом различных критериев;

управление утилизацией (utilization management) отвечает за оптимизацию использования пропускной способности каналов;

сервисная топология (service topology) осуществляет хранение актуальных и запланированных сервисов и их параметров;

медиатор (mediation) отвечает за работу с API нижележащих устройств и осуществляет поддержку достаточно богатого набора протоколов сетевого управления, таких как RESTCONF, NETCONF, SNMP, SSH, OpenFlow, а также HTTP/HTTPS;

управление контроллером (controller management) соответствует модели FCAPS стандарта ISO и включает в себя управление конфигурацией, отказами и производительностью контроллера.

Одним из интереснейших и сложнейших модулей контроллера является модуль вычисления пути (PCE) — модуль, отвечающий за расчет конкретного пути для запрошенного клиентом сервиса. Реализация такого модуля является непростой задачей с точки зрения математического алгоритма. Знатоки протоколов маршрутизации по состоянию канала OSPF и IS-IS или протокола маршрутизации канального уровня HWMP стандарта 802.11s, возможно, скажут, что задача уже давно решена, реализована и проверена временем — достаточно использовать стандартные подходы для поиска пути на графе, например, алгоритм Дейкстры и его модификации. Однако специфика, накладываемая оборудованием различных вендоров, а также требования, представленные системе, делают задачу поиска пути принципиально новой, требующей детального анализа и небанальных подходов.

Основные требования, предъявляемые к PCE:

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

Особую сложность представляют пункты 4 и 6.

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

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

Успешный запуск пилотной версии даёт возможность разработчикам контроллера T-SDN вносить свой вклад в развитие Open Source проектов, таких как ONOS и ODENOS, участвовать в стандартизации новой технологии SDN в Open Networking Foundation и в других организациях.

Развитие проекта ведется в тесном сотрудничестве с компанией NEC — производителем современного сетевого оборудования. Таким образом, функционал контроллера тестируется в сетевой лаборатории NetCracker на новейших устройствах от NEC, а отделы разработки компаний NetCracker и NEC имеют возможность тесно сотрудничать и напрямую обсуждать технические вопросы. Такое взаимодействие позволяет лучше понимать возможности вендоров и эффективнее работать с сетевыми устройствами.

Функциональные потребности крупных провайдеров постоянно растут — компании, заинтересованные в контроллере T-SDN неустанно снабжают разработчиков компании NetCracker всё новыми, более сложными и интересными задачами. Значительное развитие получат (и уже получают) абсолютно все составляющие — от низкоуровневых сетевых интерфейсов Медиатора (Mediation) до визуализирующих и управляющих приложений. Команда контроллера T-SDN компании NetCracker, имеющая за плечами многолетний опыт работы с ведущими провайдерами в рамках OSS- и BSS-решений, уверено положила начало развитию этой непростой, но чрезвычайно интересной области.