Контроллер для T-SDN

    image
    Уже никого не удивишь стартапами и разработками в области 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Гбит/с.
    image

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

    • автоматическая прокладка сервиса в сети по запросу клиента;

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

    • мониторинг ошибок и уведомлений.

    T-SDN


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

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

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

    • Упрощение операций по работе с транспортной сетью.

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

    • Оптимальное использование пропускной способности.

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

      В качестве примера рассмотрим такой случай. Клиентский траффик проходит между оптическими устройствами A и B двумя путями. Голубой пунктир – оптическое волокно, черные линии – клиентский канал. Графики показывают, какая часть канала занята, а какая свободна – красный и зеленый цвета соответственно.
      image

      Теперь представим, что нужно разместить новый клиентский канал – больший по емкости, занимающий 50% пропускной способности соединения. Для этого можно, например, провести один из каналов идущих сверху по нижнему пути, и таким образом освободить 50% соединения.
      image

      Эту операцию нужно провести так, чтобы существующий клиент не заметил, что его траффик теперь идет другим путем – даже кратковременный отказ в обслуживании или ухудшение качества услуг (QoS) неприемлемы. Такое перераспределение каналов возможно, но на данный момент оно выполняется инженерами в ручном режиме, занимает немало времени и подвержено ошибкам. Контроллер же потенциально может автоматизировать этот процесс. Нужно отметить, что использование пропускной способности на 100% в реальности невозможно, цифры приведены лишь для иллюстрации проблемы. В действительности показатель утилизации обычно составляет порядка 80-90%.

    • Пропускная способность по запросу (bandwidth on demand) – автоматическое увеличение пропускной способности клиентского сервиса, в случае если объем траффика превышает емкость купленного им канала. Такое поведение позволит передавать данные с большей скоростью в течение небольшого промежутка времени, а также предотвратит сброс пакетов в случае пиковых нагрузок. Пропускная способность по запросу не потребует от клиента больших финансовых вложений – оплатить нужно будет только тот промежуток времени, в течение которого пропускная способность была увеличена.

    • Построение оптимальных маршрутов в транспортных сетях.

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

    • Высокий уровень надежности и доступности сервиса (high availability).

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

    • Безопасное конфигурирование сети через высокоуровневые приложения.

      При изменении конфигурации устройства сетевым администратором возможны ошибки, которые могут привести к серьезным последствиям, в том числе долгосрочным отказам в обслуживании. Известно немало случаев значительных сбоев в глобальной сети из-за ошибок инженеров – чего стоит только утечка маршрутов (route leak) 12 июня 2015 года, затронувшая значительную часть Интернета. Использование высокоуровневых визуальных приложений позволяет сильно снизить вероятность неправильной конфигурации – большая часть скрупулезной работы выполняется автоматически.

    • Возможность легко масштабировать систему (scalability).

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

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

      Сотрудники компании NetCracker в Москве, Санкт-Петербурге и Нижнем Новгороде при поддержке инженеров из компании NEC в настоящий момент ведут активную работу по исследованию T-SDN и развитию функциональности контроллера T-SDN.

    Контроллер T-SDN компании NetCracker




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

    • полное управление сильно распределенной транспортной сетью крупного провайдера;

    • прокладывание маршрута по всей сети провайдера;

    • оптимизация маршрута с учетом требований и различных метрик;

    • поддержка мультивендорной сети (сети, построенной на устройствах различных производителей);

    • пропускная способность по запросу;

    • высокий уровень надежности и доступности сервиса;

    • возможность легко масштабировать систему;

    • оптимальное использование пропускной способности.

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

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


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

    Архитектура контроллера T-SDN компании NetCracker


    Компанией 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:

    1. нахождение пути при условии его существования;

    2. гибкая поддержка метрик;

    3. учет желательных или нежелательных для посещения узлов;

    4. учет обязательных для посещения узлов;

    5. учет запрещенных для посещения узлов;

    6. независимость от производителя оборудования.

    Особую сложность представляют пункты 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-решений, уверено положила начало развитию этой непростой, но чрезвычайно интересной области.
    Netcracker
    международная компания-разработчик IT-решений

    Похожие публикации

    Комментарии 6

      +1
      Огласите GPL пожалуйста на 10 устройств и 480 портов 10G
        +1
        DoMoVoY, здравствуйте.
        По данному вопросу можно обратиться по контактам, указанным на нашем официальном сайте.
        0
        Очень интересно.
        Для организации полосы по требованию, кто это требование выдвигает? Контроллер понимает только оптических транспортную сеть или и уровень выше? На рисунке он у вас нарисован но относится или нет — не ясно.
        Как быстро у вас происходит расчет и перерасчет пути?
        А оптимизировать трафик оно может на сети? Т.е. перераспределить после анализа более оптимальным способом?

          +1
          Здравствуйте.
          Нам очень приятно, что тема T-SDN интересна. Это подталкивает нас рассказать о сетях и контроллерах больше и детальней. Ниже позвольте нам ответить на Ваши вопросы по порядку.

          Запросы сервисов «bandwidth on demand» осуществляется со стороны Сервисного Оркестратора (Service Orchestrator), который архитектурно относится к уровню приложений для Контроллера.

          Контроллер на основании данных, получаемых от нижележащей инфраструктуры, может создавать многоуровневые виртуальные топологии, которые включают все уровни существующих транспортных сетей:
          1) L0 (WDM ROADM),
          2) L1 (OTN),
          3) L2/L3+ (IP/MPLS).
          Более детально об этом мы хотели бы рассказать в следующих статьях, равно как и о следующем вопросе.

          Вся работа контроллера должна быть максимально приближена к «реальному времени». Существует понятие Active Real-Time.
          В первую очередь время вычисления пути определяется размером топологии, формируемой на основании сети. Однако существенный вес имеет технологическая специфика (например, для DWDM). Опираясь на опыт, полученный нашей командой в результате внедрения, можно сказать, что расчет пути на одном сегменте сети провайдера (управляемом контроллером нижнего уровня) занимает менее чем 50 мс. Время, затрачиваемое контроллером верхнего уровня на расчет пути, может значительно отличаться. Это обусловлено тем, что он агрегирует внутри себя разные сетевые домены. Так, например, расчет пути при нагрузочном тестировании на топологии, состоящей из 10 000 элементов, занял порядка 2 секунд.
          В рамках предложенной системы кластеризация может стать одним из способов ускорения прокладки пути, а также оптимизации нагрузки на контроллеры нижнего уровня.
          Очень важно также отметить, что время, затрачиваемое контроллером на расчет пути, пренебрежимо мало по сравнению со временем, которое может потребоваться для прокладки или перепрокладки этого пути на уровне оптического оборудования.

          Изначально контроллер верхнего уровня отвечает за обеспечение оптимальной прокладки сервиса согласно критериям, полученным со стороны Сервисного Окрестратора (Service Orchestrator). Оптимизация трафика осуществляется как на контроллерах верхнего, так и контроллерах нижнего уровней. Этот процесс затрагивает не только основные маршруты (Main), но и резервные (Protection).
          Контроллеры могут осуществлять мониторинг параметров сети (таких как пропускная способность, балансировка трафика и загруженность развернутых VNF) как самостоятельно, так и посредством сторонних систем.
          0
          Действительно пропущен MPLS уровень.
          Вы поддерживаете RFC 5440? Или решили пойти 'своим' путем?
            0
            Здравствуйте, ayurtaykin!

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

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое