Обзор OpenFlow. Часть 2 — Основы

2
1885

Что такое OpenFlow? В этой статье продолжаем рассказывать о возможностях протокола.

Отделение Control Plane от Data Plane

Практически каждое традиционное сетевое устройство состоит из трех независимых уровней:

  • Data plane отвечает за пересылку Protocol Data Unit (PDU) согласно определенным правилам, хранящимся в таблице. Для уровня L2 это может быть MAC-таблица, состоящая из MAC-адресов и соответствующих исходящих портов. На входящий порт приходит PDU, обрабатывается и отправляется через исходящий порт. Data plane не отвечает за формирование таблицы форвардинга (FIB);
  • Control plane отвечает за предоставление необходимой информации Data plane для обеспечения форвардинга и является «мозгом», принимающим решение о том, каким образом перенаправлять PDU. Control plane не ограничивается лишь протоколами маршрутизации. Любой протокол, контролирующий взаимодействие между смежными узлами, обычно является протоколом Control plane. Примером могут служить BFD, STP и LACP. Эти протоколы не взаимодействуют напрямую с FIB. Например, протокол BFD обнаруживает физические проблемы на канале связи между устройствами, но самостоятельно ничего не удаляет из таблицы. Он информирует другие более высокоуровневые протоколы о сбое, предоставляя им самим принять решение о изменении FIB. С другой стороны, протоколы маршрутизации OSPF или IS-IS напрямую воздействуют на таблицу маршрутизации и форвардинга;
  • И наконец, Management Plane предоставляет интерфейс управления и мониторинга, с помощью которого производится конфигурация устройства.

Идея OpenFlow заключает в выносе Control plane на отдельное устройство – OpenFlow-контроллер, оставляя сетевым устройствам лишь функции Data Plane. Это сильно снижает требования к функционалу оборудования, превращая его в «простое устройство по перенаправлению пакетов из порта в порт».

Контроллер использует OpenFlow, чтобы подключаться к коммутаторам и программировать их таблицы форвардинга, рассчитывая лучшие пути для трафика приложений. OpenFlow-агент принимает команды от контроллера и формирует таблицу flow, на основе которой коммутатор принимает решение о том, куда направить пришедший пакет. Здесь под «пакетом» понимается PDU.

Data Plane коммутатора

Итак, когда мы рассмотрели основной принцип SDN – отделение data plane от control plane, пора пояснить основные термины, которыми оперирует OpenFlow. Data Plane коммутатора состоит из следующих компонент:

  • OpenFlow-порты (Ports);
  • Потоки (Flow);
  • Таблицы потоков (Flow tables);
  • Классификаторы (Match);
  • Действия (Actions);

Приходящие пакеты на OpenFlow-порт классифицируются по Flow в таблицах потоков с помощью Match-классификаторов. Каждый Flow состоит из набора действий (Actions), которые применяются каждому пакету, который соответствует правилу.

Но обо всем по порядку…

OpenFlow-порты

OpenFlow-порты выполняют те же функции, что и порты стандартного коммутатора. С точки зрения входящих и исходящих потоков трафика, нет никакой разницы с обычным L2-коммутатором. Входящий порт одного потока может быть исходящим для другого. OpenFlow определяет набор стандартных портов – physical, logical и reserved. Physical — очевидно, физические порты коммутатора. Логические (logical) порты, как и в традиционных сетях, напрямую не привязаны к портам оборудования, например, MPLS LSP, Tunnel и Null интерфейсы. Зарезервированные порты используются для внутренней обработки трафика и для гибридных типов внедрения (OpenFlow + традиционная сеть).

Зарезервированные порты могут быть обязательными или опциональными. Обязательные порты включают порты типов ALL, CONTROLLER, TABLE, IN_PORT и ANY. В то время как опциональные порты – LOCAL, NORMAL и FLOOD.

Более подробно с функциями портов OpenFlow можно ознакомиться в спецификации OpenFlow (стр. 13)

OpenFlow – обычный протокол программирования TCAM. Если вы захотите создать туннель между двумя конечными точками, вы не сможете это сделать с помощью OpenFlow. Подобные задачи можно выполнить с помощью других протоколов, например, OF-CONFIG, который использует NETCONF для этого. Порты могут быть добавлены или удалены из конфигурации коммутатора с помощью OF-CONFIG, но не с помощью OpenFlow.

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

Таблицы Flow

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

Большинство бюджетных коммутаторов имеет ограниченный размер TCAM (1-2 тыс. записей), что вызывает серьезные ограничения применимости OpenFlow версии 1.0

При получении пакета из него извлекаются метаданные (например, incoming interface) и другие поля пакета. Затем эти поля сравниваются с записями в таблице Flow. Каждая запись в таблице имеет поле “protocol”, по которому идет сравнение. Результат с наивысшим приоритетом считается победителем. Каждая запись в таблице Flow должна иметь различный приоритет, а запись с наивысшим приоритетом определяет то, как дальше будет обработан пакет.

OpenFlow-flowtable_sdnblog.ruКак только выбрано Match-правило, к пакету применяется определенное действие (Action). Возможными действиями могут быть «отправить в порт Х», «отбросить» или «отправить на контроллер». По умолчанию OpenFlow 1.0 отправляет на контроллер все пакеты, не соответствующие ни одному правилу. В более поздних версиях протокола этот механизм был изменен, т.к. может подвергнуть DoS-атакам на контроллер со стороны злоумышленников.

Первоначальная спецификация OpenFlow 1.0 предполагала лишь возможности «перенаправить на другой порт» или «отправить на контроллер». Но позже разумно пришли к выводу, что в определенных случаях требуется модифицировать поля в пакете, например уменьшить TTL или добавить тег VLAN. Версия 1.0 была признана неполной, т.к. необходима возможность выполнения более одного действия с конкретным пакетом.

Ограничение на количество таблиц с переменным успехом удалось обойти в последующих версиях OpenFlow. Но в то же время, это разрушает первоначальную концепцию, что «OpenFlow используется на недорогих коммутаторах…» Наличие нескольких таблиц накладывает дополнительные требования к чипсетам коммутаторов, а также требует комплексного сопоставления пайплайна OpenFlow с пайплайном ASIC коммутатора.

Классификаторы

В качестве классификатора можно использовать любую комбинацию полей заголовка пакета. Например, сравнение по MAC-адресам (OpenFlow 1.0), wildcard-маскам (OF 1.1), VLAN и MPLS-меткам (OF 1.1), PBB заголовкам (OF 1.3), IPv4 адресам с wildcard-масками, DSCP битам, IPv6 адресам (OF 1.2), L4 протоколам, TCP и UDP портам.

После того как сравнение выполнено, возможно выполнение ряда действий. Кроме описанных выше, можно выполнить, например, header rewrite (изменение заголовка). Это означает, что OpenFlow может быть использован для реализации функций NAT. Правда этот кейс тоже имеет свои ограничения в связи с ограниченным количеством записей flow.

OpenFlow-группы

В завершении этой статьи, хочется рассказать об интересном механизме OpenFlow, где пакет может быть обработан с использованием, так называемых, групп (GROUP). Начиная с версий 1.1+ OpenFlow включает функционал GROUPS, которые усовершенствуют механизмы форвардинга и позволяют реализовать, например, ECMP Load Balancing.

Группа состоит из набора подмножеств, каждое подмножество — из набора Actions. В качестве одного Action может быть «перенаправить на порт», установить VLAN-тэг или выполнить операции push/pop для MPLS-меток. Группа, например, может состоять из двух подмножеств:

  • подмножество 1 (bucket 1) с действием «отправить на port1»;
  • подмножество 2 (bucket 2) с действиями «отправить на port2» и «добавить тег»;

Подобный подход расширяет возможности форвардинга. Например, «отправка на все подмножества из одной группы» может быть использована при реализации selective multicast. Или, «отправка на одно подмножество из группы» — для балансировки нагрузки в LAG или ECMP.

SDNBLOGGER
SDNBLOGGER - команда SDNBLOG, которая занимается поиском наиболее интересных новостей из мира SDN и NFV, а также публикует статьи по тематике. В команду входят ведущие российские специалисты в области технологий SDN и NFV.

2 КОММЕНТАРИИ

  1. Здравствуйте!
    Интересует один вопрос.
    На уровне Data Plane правила обработки пакетов определяются MAC-таблицей, но это, как я понял, не таблица форвардинга (FIB). В чем разница межу этими таблицами? или где о них можно почитать?

  2. Артём, здравствуйте! Правила обработки пакетов/фреймов определяются несколькими таблицами. В классической терминологии, обычно разделяют L2 и L3 Forwarding Tables (CAM и FIB). Если упрощенно, то MAC-таблицей определяются правила обработки фреймов, а не пакетов. Подробнее о различиях CAM, TCAM и FIB почитайте тут http://twistedminds.ru/2013/05/switch-operations-1/ и тут http://twistedminds.ru/2012/12/tcam/
    Касательно OpenFlow и TCAM можно почитать тут — https://www.sdxcentral.com/articles/contributed/sdn-openflow-tcam-need-to-know/2012/07/ Если у вас останутся вопросы, обращайтесь.

ОСТАВЬТЕ КОММЕНТАРИЙ