SDN

За последние несколько лет очень сильно изменились условия использования сетей. Взрывной рост Интернета, повсеместное внедрение облачных сервисов, доступ в Интернет с мобильных устройств буквально из каждой точки Земного шара, BigData – все это привело к изменению требований, которые в наше время предъявляются к сетям. Статические топологии уже не удовлетворяют им в полной мере. Теперь топологии должны уметь быстро адаптироваться под постоянно меняющиеся условия: многократное и разнообразное изменение трафика между узлами, непрерывное добавление новых узлов, быстрое реагирование на угрозы безопасности путем добавления новых правил фильтрации трафика т.д.

Концепция Программно-управляемых сетей (Software-Defined Networks, SDN) ¹ дает ключ к решению этих задач простым и мощным способом, разделяя собственно пересылку пакетов внутри топологии и управление топологией и делая управление полностью программируемым.

За несколько лет своего существования OpenFlow проделал большой путь от относительно примитивной версии 1.0 с одной таблицей и мало подходящим для встроенных реализаций (опубликован в 2009-м году) до версии 1.3.1 ² с поддержкой конвейера таблиц и внушительного списка возможных критериев сравнения.

Архитектура

Архитектура OpenFlow разработана таким образом, чтобы наилучшим образом удовлетворять требованиям, предъявляемым к программно-управляемым сетям, фактически определяя “язык низкоуровневого программирования” и “язык мета-программирования” для управления топологиями.
Определены три основные сущности: OpenFlow-enable switch (Свитч), OpenFlow-controller (Контроллер) и OF-Config (Конфигуратор).

Свитч представляет собой совокупность внутренних логических портов и конвейера для обработки пакетов.
Ключевое понятие для описания свитча – Flow. Это – правило, согласно которому свитч обрабатывает входящие пакеты. Эти правила объединены в таблицы, т.н. OpenFlow tables, которые, в свою очередь, объединены в конвейер. Основные составные части любого правила – критерий для сравнения (Match) и инструкция (Instruction). Любой входящий пакет попадает в нулевую таблицу. Затем его заголовок проверяется на соответствие критериям всех правил (Flows), записанных в нулевой таблице. Если какой-то из пакетов отвечает критерию, содержащемуся в отдельном правиле, то к нему применяется инструкция из данного критерия: пакет может быть отправлен в другую таблицу, в любой выходной порт или просто отфильтрован (dropped). Пакеты, не отвечающие критериям ни из одного правила, пересылаются по конвейеру в следующую таблицу.
Важно понимать, что свитч отвечает лишь за обработку и пересылку входящих пакетов, но никоим образом не влияет на содержимое своих таблиц.

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

Конфигуратор, используя протокол, базирующийся на XML, может управлять свойствами свитча (к примеру, назначать соответствие между логическими внутренними портами свитча и реальными портами топологии). Для этого он определяет две основные концепции: OF Capable Switch, представляющий собой совокупность логических свитчей и т.н. Capable ports, т. е. доступные свитчу реальные порты топологии; а также уже упомянутые Logial Switches (логические свитчи), представляющие собой в основном совокупность интерфейсов к доступным портам или Логических портов. Пользователь из точки контроля Конфигуратора может связывать логические порты и доступные порты, перераспределять Логические порты между Логическими свитчами, назначать контроллеры для свитчей и т.д.

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

Контроллер Floodlight ³

Самый известный на сегодняшний день контроллер OpenFlow – это Floodlight. В настоящий момент он также поддерживает только OpenFlow 1.0. Сообщество ведет работу по реализации поддержки версий 1.x протоколов. Однако в процессе исследования его исходного кода наша команда пришла к выводу, что некоторые изначальные недостатки архитектуры и подхода к описанию протокола OpenFlow, а также уже отмеченные большие различия между версиями 1.0 и 1.2-1.3 делают нецелесообразным реализацию версий выше 1.0 в данном контроллере. Поэтому мы стартовали новый проект контроллера, основанный на библиотеке Apache Avro ⁴, используемой для описания протоколов и сериализации/десериализации сообщений.

Свитч LINC ⁵

В настоящий момент существует множество подходов к реализации OF свитчей: hardware реализации на базе embedded решений, а так же software реализации на различных платформах и различных языках программирования. Следует заметить, однако, что несмотря на то, что OpenFlow – это открытая спецификация, большая часть реализаций OpenFlow свитчей, претендующих на звание промышленных, являются проприетарными. Пожалуй, единственным исключением из этого правила является LINC – полнофункциональный OpenFlow свитч, поддерживающий последнюю версию спецификации, 1.3.1, и выпущенный под лицензией Apache. Автор этого доклада участвовал в совместном тестировании свитчей и контроллеров от различных производителей, и должен сказать, что на общем фоне LINC выглядел весьма достойно, часто даже превосходя своих проприетарных собратьев. Более того, LINC – единственный на сегодняшний день полнофункциональный OF Capable свитч.

Что позволило небольшой команде разработчиков LINC за весьма короткие сроки (около одного года) создать ⁶ полнофункциональный, претендующий на звание промышленного, свитч? Ответ прост и сложен одновременно: Erlang.

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

¹ https://www.opennetworking.org/images/stories/downloads/white-papers/wp-sdn-newnorm.pdf

² http://www.opennetworking.org/about/onf-documents

³ http://floodlight.openflowhub.org/

⁴ http://avro.apache.org/

⁵ http://www.flowforwarding.org/

⁶ https://github.com/FlowForwarding/LINC-Switch