Обзор OpenFlow. Часть 3 – Table Type Patterns (TTP)

0
1789

<< Предыдущая часть

Один из экономических драйверов применения концепции Software Defined Networking (SDN) связан с «возможностью использования недорогих bare-metal коммутаторов, управляемых централизованно с помощью SDN-контроллера». OpenFlow – наиболее популярный на данный момент протокол, используемый SDN-контроллерами для программирования сетевых устройств. Но он имеет несколько важных технических недостатков, тормозящих развитие подхода – небольшие размеры TCAM в оборудовании, сложность реализации функционала OpenFlow 1.3 с использованием нескольких таблиц в пайплайне коммутаторов и др.

В этой статье расскажем об интересном подходе OpenFlow Table Type Patterns (TTP), предложенным сообществом ONF для решения проблем совместимости SDN-контроллеров и оборудования, а именно – как «уложить принципы работы OpenFlow (версии > 1.0) в логику, зашитую в ASIC коммутаторов»?

Попытаемся объяснить как можно проще, пусть даже в ущерб точности определений.

Немного теории…

Для того, чтобы понять, что такое TTP, нужно освежить в памяти несколько базовых понятий. Как вы знаете, основная задача сетевого устройства – принять пакет/фрейм на одном порту и перенаправить в другой, при этом обработать его определенным образом. За этой обработкой скрывается множество более примитивных действий – назначение VLAN-меток, уменьшение TTL и др., которые должны быть определены в коммутирующей матрице (ASIC) для поддержки специфичного «пайплайна» коммутатора.

«Пайплайн» (от англ. “Pipeline”) – термин, которым принято описывать определенную последовательность действий, совершаемых с пакетом внутри сетевого устройства до момента его отправки через исходящий порт. Эта последовательность жестко определена в ASIC.

ttp-abstract-switch-pipeline
Абстрактный пайплайн для функций L2 Bridging и L3 Routing

Проектирование коммутирующих матриц всегда зависит от логики работы L2/L3 протоколов для реализации соответствующего пайплайна. Из этого следует, что так часто используемый в SDN термин “Data Plane” всегда зависит от реализации логики в “железе”. Плюс ко всему, в каких-то чипсетах может быть реализована и проприетарная логика выполнения примитивных действий.

Изначально, в OpenFlow попытались сделать эти примитивы вендоро-независимыми путем использования понятия таблиц (TABLES). Теоретически, если коммутатор поддерживает OpenFlow, он должен иметь возможность сконфигурировать плоскость передачи данных с использованием лишь примитив OpenFlow. Каждое действие может быть определено как таблица. Версия 1.0 протокола поддерживала только одну таблицу, и логику OF1.0 было достаточно легко вписать в пайплайн коммутаторов.

Однако, в OpenFlow 1.3 появилась поддержка нескольких таблиц! Например, одна – для назначения VLAN-меток, другая – для ECMP и так далее. В OF1.3 также специфицировано, каким образом эти таблицы могут взаимодействовать друг с другом. В результате, появилось множество пайплайнов OpenFlow, которые очень сложно сопоставить с пайплайном, заложенным в ASIC коммутатора. С программными коммутаторами все гораздо проще, т.к. их логику можно адаптировать каким угодно образом.

ttp-openflow-pipeline-example
Пример таблиц в OpenFlow 1.3 (и старше)

Вписать множество пайплайнов OpenFlow 1.3 в логику работы ASIC в коммутаторах – одна из основных проблем OpenFlow (на момент написания статьи в апреле 2016).

Для понимания Table Type Patterns, сначала нужно обозначить два важных момента.

Во-первых, мы знаем, что OpenFlow-агент на коммутаторе конфигурирует Data Plane исходя из инструкций, полученных от контроллера. Какие-то инструкции агент не сможет выполнить, например, если ASIC не поддерживает необходимое количество таблиц или не имеет нужного количества ресурсов. Эти проблемы могут быть обнаружены лишь на этапе инициализации – добавлении коммутатора под управление контроллера. Каждый пайплайн OpenFlow должен быть сопоставлен с ASIC с учетом поддерживаемого функционала чипсета. На данный момент, у контроллеров нет механизма определения того, какие пайплайны поддерживаются в ASIC коммутатора.

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

Во-вторых, на этапе инициализации необходимо четкое определение функционала OpenFlow, который поддерживается контроллером и OF-коммутатором – типы сообщений (они называются FlowMod сообщения), количество таблиц и др. Затем, если контроллер и свитч смогли «договориться», они начинают использовать лишь ограниченный функционал OpenFlow для реализации поддерживаемого пайплайна. Подобный подход исключает неожиданное поведение сетевого устройства в ответ на получение неподдерживаемого типа сообщения.

Во многих случаях нет необходимости поддерживать все возможные пайплайны OpenFlow. Можно определить какой-то ограниченный, с понятным описанием OF-сообщений, таблиц и т.д. Если контроллер и сетевое устройство оба его поддерживают, можно сказать, что они совместимы. Этот «ограниченный pipeline» и получил название Table Type Patterns (TTP).

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

Для того, чтобы избежать получения коммутатором непонятных ему директив от контроллера, сначала должен быть определен поддерживаемый TTP с обеих сторон, после чего происходит перевод коммутатора в рабочий режим и обновление flow-записей. Процесс согласования происходит с помощью протокола OF-Config. Но откуда SDN-разработчики и вендоры коммутаторов возьмут эти TTP? Сообщество ONF предполагает, что процесс создания TTP будет происходить приблизительно следующим образом:

  • Инициатор процесса (вендор оборудования, сообщество ONF или разработчик SDN-приложения), желая получить поддержку логики работы своего продукта от других участников рынка, создает новое описание TTP;
  • Делится этим TTP либо только с партнерами, либо со всеми, выкладывая его на Github;
  • Далее, вендоры оборудования и SDN-разработчики, добавляют поддержку нового TTP в свой продукт. Сама реализация остается на откуп каждой из сторон;
  • При добавлении коммутатора под управление контроллера, оба устройства определяют поддерживаемые TTP и начинают работать только в рамках этих TTP.
ttp-onf-formation
Процесс создания TTP. Источник: Сайт ONF

Такой подход по идеи должен принести несколько преимуществ. Во-первых, это повышение совместимости SDN-контроллеров и различного коммутационного оборудования. Во-вторых, – независимость разработки SDN-приложений и логики Data Plane, при этом TTP используется как референсный документ. В-третьих, упрощение тестирования OpenFlow устройств.

Заключение

Дополняя и резюмируя вышесказанное, приведем несколько важных моментов относительно TTP:

  • TTP не добавляют никакого нового функционала! Они лишь описывают функции OpenFlow, нужные для реализации конкретных кейсов применения (L2 Switch, VXLAN Gateway и др.);
  • Для описания TTP на данный момент используется формат JSON (Update 01.2017: в будущих спецификациях предполагается описание в виде YANG);
  • Поддержка TTP определяется до того момента как коммутатор и SDN-контроллер начинают работать вместе;
  • Во время работы будут использоваться только OF-сообщения, определенные в TTP и никакие другие;
  • Как говорит ONF, каждый «логический» коммутатор может поддерживать только один тип TTP. Если свитч поддерживает разбиение на несколько логических инстансов, то он может поддерживать несколько TTP – по одной на каждый логический коммутатор;
  • SDN-контроллеры могут поддерживать несколько TTP;
  • За развитие TTP отвечает группа Forwarding Abstractions Working Group (FAWG) в ONF (Update 01.2017: ныне FAWG объединена с группой Extensibility и на их основе сформирована новая рабочая группа – Open Datapath Working Group (ODWG));
  • Процесс согласования TTP между контроллером и коммутатором осуществляется с помощью протокола OF-Config.

Ресурсы:

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

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

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