Сетевые устройства, например, коммутатор Ethernet в локальной сети предприятия, или маршрутизатор на сети оператора связи, состоят из двух основных компонентов: устройства коммутации пакетов (data plane, DP) и программного обеспечения (ПО), которое управляет передачей пакетов со входа на выход коммутатора (control plane, CP). Это ПО иногда называют firmware, т.к. только производитель (вендор) данного сетевого устройства может его изменять.

Рис. 1. Традиционная архитектура сети с уровнями передачи данных DP и управления CP в каждом сетевом устройстве. 

Когда пакет данных прибывает на входной порт коммутатора, этот порт запрашивает firmware, что делать с этим пакетом дальше. Firmware определяет направление передачи пакета, по таблице МАС-адресов соседних сетевых устройств, которые подключены к коммутатору, и определяет выходной порт, куда это пакет нужно передать. Это весьма упрощенное описание, но для дальнейшего понимания принципа работы SDN его достаточно.

Состав протоколов firmware является исключительной компетенцией вендора, поскольку только он имеет доступ к исходному коду. Оператор сети вынужден приобретать вместе с нужными ему функциями сетевого устройства и много ненужных в данный момент функций, только лишь потому, что они уже «зашиты» в стандартное firmware.

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

Рис. 2. Сравнение городского вождения с навигацией и без него.

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

При вождении с навигатором, такой проблемы у него не возникает. Он не только тратит меньше времени на решение о следующем этапе маршрута, но и прибывает в место назначения гораздо быстрее, т.к. навигатор подсказывает оптимальный маршрут, с учётом пробок, аварий, дорожных работ и пр. Однако, такой эффект возникает только тогда, когда большинство автомобилей (в идеале – все) используют облачную навигацию, например, от Яндекса или Google. Если большинство машин использует оптимизированные маршруты, уменьшается загруженность улиц и увеличивается пропускная способность всей городской уличной сети. Нельзя ли применять такой принцип к управлению маршрутизацией на сети?

Почему именно так строят сети — вопрос очень интересный исторически и требует отдельного повествования. Но строят их именно так, а не иначе. Но нельзя ли строить сети по такому же принципу, который используется в навигаторе Google Maps или Яндекс-карт?

Именно такая идея возникла у учёных Стэнфордского университета в Калифорнии. Они предложили концепцию отделения «мозгов коммутатора» (его ПО в виде firmware) от оборудования коммутатора (hardware). При этом, традиционная сеть распадается на две плоскости – управления (Control Plane) и передачи данных (Data Plane). Первая плоскость при этом уходит в централизованные серверы, а вторая – остаётся в оборудовании сетевых элементов, лишённых избыточного firmware. При этом, каждая сеть и каждый сетевой элемент используют из плоскости управления только те функции, которые в данный момент нужны. Плоскость управления (Control Plane) называется SDN-контроллером и располагается на стандартных серверах, которые располагаются в центрах обработки данных (ЦОД), или дата-центрах.

Рис. 3. Архитектура SDN-сети. Источник: networklife.net. 

SDN, Software Defined Network: программно определяемая (или конфигурируемая) сеть. Это означает не только то, что сетевые элементы управляются программно и могут быстро и эффективно перестраиваться, но и то, что на одном физическом пуле сетевых элементов могут быть развёрнуты много сетей, логически не зависящих друг от друга. Такие логические сети могут передавать потоки трафика разных бизнес-приложений, не мешая друг другу.

Приложения, которым нужны разные сетевые параметры и конфигурации сети, администрируют SDN-контроллер при помощи интерфейсов программирования приложений API (Application Programming Interface). В такой архитектуре каждое бизнес-приложение может через SDN-контроллер сконфигурировать для себя логическую сеть из общих ресурсов сетевой инфраструктуры уровня передачи данных. И каждая такая сеть будет работать независимо от других логических сетей в том же пуле ресурсов (при их достаточности).

Рис. 4. Уровень приложений и протокол OpenFlow в SDN-сети.Источник: Bigswitch.com. 

Для управления инфраструктурой сети от SDN-контроллера необходим протокол открытого управления. Такой протокол, разработанный учёными из Стэнфорда, называют OpenFlow (хотя, как будет показано, это не единственный возможный протокол для данного применения).

• Протокол OpenFlow

Работа OpenFlow заключается в модификации содержания таблицы передачи пакетов внутри маршрутизатора или коммутатора (Forwarding table). Архитектура сетевых устройств часто представляется в виде трех плоскостей: администрирования (management plane), управления (control plane) и передачи данных (data plane), рис. 3.5.

Рис. 5. Работа OpenFlow. Источник: Etherealmind.com. 

Плоскость администрирования (Management Plane) устанавливает режимы работы устройства, модифицирует версии т.н. фирменного ПО (firmware), жестко «зашитого» в сетевое устройство, выполняет команды простого протокола администрирования сети SNMP (Simple Network Management Protocol) от внешней системы администрирования сети NMS, а также команды внешней конфигурации устройства через интерфейс командной строки CLI (Command Line Interface), которые вручную может вводить системный администратор. Плоскость передачи данных (Data Plane) передает пакеты данных со входа устройства (IN) на его выход (OUT) в соответствии с таблицей передачи (Forwarding Table). На плоскости управления (Control Plane) работают протоколы маршрутизации и коммутации.

Плоскость управления использует таблицу маршрутизации (routing table) для составления таблицы передачи пакетов (forwarding table), которую использует плоскость передачи данных (data plane). Таблицы передачи пакетов доставляется на плоскость передачи от плоскости администрирования. В соответствии с таблицей передачи, пакет, прибывающий на входной порт коммутатора (IN), передается плоскостью передачи данных на выходной порт (OUT).

OpenFlow – это метод управления потоками (flow) в сети.

Дело в том, что сетевые устройства (маршрутизаторы, коммутаторы и другие) занимаются передачей пакетов и фреймов в соответствии с протоколами маршрутизации, однако, бизнес-приложения не используют определённые пакеты для предоставления услуг. Они обмениваются данными между сервером и клиентом и создают потоки пакетов от источника к получателю, который называются «Flow» (поток).

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

Ценность OpenFlow в том, что он реализуется автоматически через централизованный SDN-контроллер. При этом управление плоскостью передачи становится гораздо более эффективным и быстрым (agile), функциональные возможности устройств значительно расширяются, и достигается «гранулярность» управления потоками.

• Другие открытые протоколы для управления плоскостью передачи

В течение долгого времени, понятия OpenFlow и SDN оставались практически синонимами. Однако, понятие SDN за прошедшие годы сильно расширилось, и SDN-стратегии различных вендоров с течением времени стали различаться. Многие вендоры стали разрабатывать собственные подходы, в основном с целью защиты своих рыночных ниш.

Такие компании, как Cisco, VMware, Juniper, Brocade, Avaya, Embrane, Plexxi и PlumGrid и другие, придерживаются мнения, что SDN – это прежде всего свойство программируемости сети, а не какой-то конкретный протокол. То есть, по их мнению, протоколом управления сетью SDN совсем необязательно должен быть именно OpenFlow.

Следует, однако, заметить, что многие эти компании принимали активное участие в разработке OpenFlow в организации ONF (Open Networking Foundation), которая была основана разработчиками SDN и OpenFlow в Стэндфордском университете. Поэтому, несмотря на то, что все они продвигают собственные подходы SDN (чтобы дифференцировать собственные продукты), они все же сохраняют поддержку OpenFlow в них.

Концепция SDN сейчас имеет более широкое значение, тем в те времена, когда OpenFlow оставался первым и единственным протоколом управления сетью SDN. Этому способствует то, что сейчас делается больший упор на виртуализацию сети и её программируемость, а не просто на разделение плоскостей передачи данных и управления.

Например, компания Cisco предложила SDN-протокол для автоматической рассылки установки политик маршрутизации по сети, состоящей из «умных» сетевых устройств (CP+DP), а не простых устройств коммутации без firmware (только DP).

Распространение решений компании VMware для виртуализации VMware NSX и других показало важность протокола VXLAN для наложения логических сетей на существующие физические сети. NVGRE – аналогичный протокол виртуализации, предложенный компанией Microsoft, после чего многие компании стали использовать его для своих облачных платформ. Geneve – ещё более новый протокол, который призван унифицировать VXLAN и NVGRE. Известный протокол BGP также был недавно приспособлен для решений SDN.

Решение вопроса, какой протокол является наилучшим для каждого случая, зависит от конкретного применения SDN. Конечно, OpenFlow до сих пор имеет самую широкую «экосистему» поддержки, но, если стоящие задачи с его помощью решить не удаётся, нужно рассматривать другие варианты.