Архитектура

В архитектуре SDN можно выделить три уровня (рис. 1):

Рис. 1. Архитектура программно-конфигурируемых сетей

• инфраструктурный уровень, предоставляющий набор сетевых устройств (коммутаторов и каналов передачи данных);

• уровень управления, включающий в себя сетевую операционную систему, которая обеспечивает приложениям сетевые сервисы и программный интерфейс для управления сетевыми устройствами и сетью;

• уровень сетевых приложений для гибкого и эффективного управления сетью.

Наиболее перспективным и активно развивающимся стандартом для SDN является OpenFlow (OpenFlow версия 1.3) – открытый стандарт, в котором описываются требования, предъявляемые к коммутатору, поддерживающему протокол OpenFlow для удаленного управления.

С помощью современных маршрутизаторов обычно решаются две основные задачи: передача данных (forwarding) – продвижение пакета от входного порта на определенный выходной порт и управление данными – обработка пакета и принятие решения о том, куда его передавать дальше, на основе текущего состояния маршрутизатора. Это соответствует уровню передачи данных, на котором собраны средства передачи (линии связи, каналообразующее оборудование, маршрутизаторы, коммутаторы), и уровню управления состояниями средств передачи данных (рис. 2). Развитие маршрутизаторов до сих пор шло по пути сближения этих уровней, однако с уклоном на передачу (аппаратное ускорение, совершенствование ПО и внедрение новых функциональных возможностей для увеличения скорости принятия решения по маршрутизации каждого пакета), тогда как уровень управления оставался достаточно примитивным и опирался на сложные распределенные алгоритмы маршрутизации и замысловатые инструкции по конфигурированию и настройке сети. Разумеется, ПО маршрутизаторов, реализующее уровень управления, было проприетарным и закрытым.

Рис. 2. Традиционные сети и SDN

Согласно спецификации 1.3 стандарта OpenFlow, взаимодействие контроллера с коммутатором осуществляется посредством протокола OpenFlow – каждый коммутатор должен содержать одну или более таблиц потоков (flow tables), групповую таблицу (group table) и поддерживать канал (OpenFlow channel) для связи с удаленным контроллером – сервером. Спецификация не регламентирует архитектуру контроллера и API для его приложений. Каждая таблица потоков в коммутаторе содержит набор записей (flow entries) о потоках или правила. Каждая такая запись состоит из полей-признаков (match fields), счетчиков (counters) и набора инструкций (instructions).

Механизм работы коммутатора OpenFlow достаточно прост. У каждого пришедшего пакета «вырезается» заголовок (битовая строка определенной длины). Для этой битовой строки в таблицах потоков, начиная с первой, ищется правило, у которого поле признаков ближе всего соответствует (совпадает) заголовку пакета. При наличии совпадения, над пакетом и его заголовком выполняются преобразования, определяемые набором инструкций, указанных в найденном правиле. Инструкции, ассоциированные с каждой записью таблицы, описывают действия, связанные с пересылкой пакета, модификацией его заголовка, обработкой в таблице групп, обработкой в конвейере и пересылкой пакета на определенный порт коммутатора. Инструкции конвейера обработки позволяют пересылать пакеты в последующие таблицы для дальнейшей обработки и в виде метаданных передавать информацию между таблицами. Инструкции также определяют правила модификации счетчиков, которые могут быть использованы для сбора разнообразной статистики.

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

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

Записи о потоках могут также указывать на группы, в которых определяется дополнительная обработка. Группы представляют собой наборы действий для широковещательной рассылки, а также наборы действий пересылки с более сложной семантикой, например быстрое изменение маршрута или агрегирование каналов. Механизм групп позволяет эффективно изменять общие выходные действия для потоков. Таблица групп содержит записи о группах, содержащие список контейнеров действий со специальной семантикой, зависящей от типа группы. Действия в одном или нескольких контейнерах действий применяются к пакетам, отправляемым в группу.

Разработчики коммутаторов могут быть свободны в реализации их внутренней начинки, однако процедура просмотра пакетов и семантика инструкций должны быть для всех одинаковы. Например, в то время как поток может использовать все группы для пересылки в некоторое множество портов, разработчик коммутатора может выбрать для реализации этого единую битовую маску внутри аппаратной таблицы маршрутизации. Другой пример – это процедура просмотра таблиц: конвейер физически может быть реализован с помощью различного количества аппаратных таблиц. Установка, обновление и удаление правил в таблицах потоков коммутатора осуществляются контроллером. Правила могут устанавливаться реактивно (в ответ на пришедшие пакеты) или проактивно (заранее, до прихода пакетов).

Управление данными в OpenFlow осуществляется не на уровне отдельных пакетов, а на уровне их потоков. Правило в коммутаторе OpenFlow устанавливается с участием контроллера только для первого пакета, а затем все остальные пакеты потока его используют.

Имеющиеся на сегодняшний день физические коммутаторы SDN соответствуют пока спецификации OpenFlow 1.0 и содержат только одну таблицу потоков.