Сообщения протокола OpenFlow

Протокол OpenFlow поддерживает три типа сообщений:

1) Контроллер-коммутатор. Сообщения этого типа отправляются контроллером, используются для управления и отслеживания за состоянием коммутатора. Также могут использоваться для установки параметров конфигурации коммутатора, добавления, удаления и изменения записей в таблицах потоков, сбора статистики.

2) Асинхронные. Сообщения отправляются коммутатором для оповещения контроллера о событиях в сети: прибытие пакетов, удалении записи из таблицы по истечению времени, об изменениях состояния коммутатора, об ошибках.

3) Симметричные. Сообщения могут отправляться как контроллером, так и коммутатором без запроса. Используются при установке соединения, для проверки живучести соединения, при измерении задержек, пропускной способности соединения контроллер-коммутатор.

2.4.6
Сценарий работы OpenFlow

1) Коммутатор инициирует стандартный TCP (или TLS) соединение с контроллером. Когда соединение OpenFlow устанавливается, каждый объект должен передать сообщение OFPT_HELLO с версией протокола.

2) После успешного установления сеанса, контроллер посылает сообщение OFPT_FEATURES_REQUEST. Это сообщение содержит только заголовок OpenFlow и не содержит тело.

3) Переключатель отвечает соответствующим сообщением OFPT_FEATURES_REPLY.

4) Далее, контроллер посылает сообщение OFPT_SET_CONFIG к коммутатору. Это сообщение включает в себя набор флагов и максимальный размер пакета, которое необходимо отправить в контроллер.

5) Сообщение Vendor используется для частных сообщений в рамках протокола.

6) Сообщение об ошибке(«Error») может быть отправлено либо коммутатором, либо контроллером и указывает на отказ операции. Отказ может быть, если отправлено недопустимое сообщение, используется не согласованная версия протокола или же случилась ошибка в изменении состояния на коммутаторе.

7) FlowMod- одно из основных сообщений, которое позволяет контроллеру изменить состояние коммутатора OpenFlow.

Основные компоненты SDN

Основными компонентами программно-коммутируемых сетей на базе протокола OpenFlow являются:

1) Коммутатор OpenFlow

2) Контроллер OpenFlow

3) Защищенный канал, с помощью которого осуществляется взаимодействие контроллера и коммутатора. Как правило, для защиты передаваемых сообщений используется TLS(Transport Layer Security, безопасность транспортного уровня), но возможна передача по стандартному TCP без шифрования.

Рис. 14. Схема взаимодействия коммутатора с контроллером по протоколу OpenFlow.

Коммутаторы OpenFlow

Коммутатор является важнейшей составляющей сети. В состав коммутатора OpenFlow входят следующие сущности: таблица(-ы) потоков (flow); таблица(-ы) групп (forward).

Основные управляющие команды контроллера, которые передаются на коммутатор: добавить поток; обновить поток; удалить поток.

Основные режимы работы: реактивный (в ответ на пришедшие по сети пакеты); проактивный (заранее, до прихода пакетов).

Каждая таблица потоков на коммутаторе содержит одну или несколько записей, соответствующих определенным потокам данных. Каждая запись состоит из: поля признаков; счетчика; набора инструкций, применяемых к пакету данных.

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

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

Набор действий коммутатора OpenFlow: переслать пакет; модифицировать заголовок пакета; отправить на обработку в таблицу групп; отправить на обработку в конвейер.

Пересылка пакета может указать на отправку пакета:

1) В физический порт коммутатора. Порт, соответствующий аппаратному сетевому интерфейсу(hardware).

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

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

Обработка в таблице групп используется для выполнения дополнительных действий с пакетом. Сами группы содержат наборы действий для широковещательной рассылки, а также наборы действий для пересылки с более сложной семантикой (например, multipath, быстрое изменений маршрута (fast reroute), агрегирование каналов). Каждая групповая запись содержит список контейнеров действий со специальной семантикой, в зависимости от типа группы. Действия, описанные в этих контейнерах, применяются ко всем пакетам, отправляемым в группу.

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

Контроллер OpenFlow

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

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

Сетевая операционная система формирует данные о состоянии всех ресурсов сети и обеспечивает доступ к ним для приложений управления.

API сетевой операционной системы имеет следующие основные особенности:

1) API сетевой операционной системы предоставляет возможность создавать приложения на основе централизованной модели программирования, то есть приложения пишутся так, как будто вся сеть представлена на одной машине (то есть, можно использовать алгоритм Дейкстры для вычисления кратчайшего пути, а не Беллмана-Форда). Это требует поддержки централизованного состояния сети.

2) API сетевой операционной системы предоставляет возможность создавать приложения в терминах высокоуровневых абстракций (например, имя пользователя и имя хоста), а не низкоуровневых параметров конфигурации (например, IP и MAC-адресов). Это позволяет выполнять управляющие команды вне зависимости от базовой топологии сети, но это требует, чтобы сетевая операционная система поддерживала отображения между высокоуровневыми абстракциями и низкоуровневыми конфигурациями.

Таким образом, сетевая операционная система позволяет создавать приложения как централизованные программы с высокоуровневыми именами в отличие от разработки распределенных алгоритмов, использующих низкоуровневые адреса, которые используются в настоящее время. Однако переход от распределенных алгоритмов к централизованному программированию может вызвать значительные технические трудности при значительных масштабах сети.

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

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

Одновременная работа нескольких контроллеров OpenFlow в одной SDN сети пока не поддерживается.

Виртуализация в SDN

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

Рис. 15. Виртуализация в программно-коммутируемой сети.

Виртуализация сети предоставляет возможность:

1) увеличить эффективность распределения сетевых ресурсов, сбалансировать нагрузку на них;

2) изолировать потоки разных пользователей и приложений в рамках одной физической сети;

3) администраторам разных срезов использовать свои политики маршрутизации и правила управления потоками данных;

4) проводить эксперименты в сети, используя реальную физическую сетевую инфраструктуру;

5) использовать в каждом срезе только те сервисы, необходимые конкретным приложениям.

⇐ Предыдущая 1 2 3 456 7 8 9 Следующая ⇒