OpenFlow - the key standard of Software-Defined Networks

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

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

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

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

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

Конфигуратор, используя протокол, базирующийся на XML, может управлять свойствами свитча (к примеру, назначать соответствие между логическими внутренними портами свитча и реальными портами топологии).

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

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

Уже сейчас существует несколько программных решений с открытым исходным кодом, реализующих как свитч, так и контроллер OpenFlow.
Наверное, самое известное – это Open vSwitch³, использующийся как свитч по умолчанию в Xen Server, Xen Cloud Platform, KVM, VirtualBox, QEMU. Open vSwitch обладает отличным быстродействием и, кроме всего прочего, мощным интерфейсом командной строки: возможно как конфигурирование свитча, так и управлением правилами в OpenFlow таблице. К сожалению, текущая реализация поддерживает только OpenFlow 1.0, что делает его несколько устаревшим.

Несомненно, заслуживает внимания разработка, в которой принимает участие и наша команда, под названием LINC ⁴. “Изюминка” этого свитча в том, что он написан на языке Erlang. Обзор этого свитча и привлечение к нему внимание open source сообщества – одна из целей моего доклада.

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

¹ https://www.opennetworking.org/images/stories/downloads/white-papers/wp-sdn-newnorm.pdf
² http://www.opennetworking.org/about/onf-documents
³ http://openvswitch.org/
⁴ http://www.flowforwarding.org/, GitHub: https://github.com/FlowForwarding/LINC-Switch
⁵ http://floodlight.openflowhub.org/
⁶ http://avro.apache.org/