Кратко

  • Без барьера OpenFlow допускает переупорядочивание сообщений ради производительности. Barrier Reply сообщает, что в этом же соединении предыдущие сообщения полностью обработаны вместе с ответами или ошибками до начала последующих.
  • Это не квитанция плоскости данных. Спецификация прямо предупреждает: полностью обработанный Packet-Out может не выйти из коммутатора из-за перегрузки, QoS, заблокированного или неверного порта.
  • Nick McKeown важен как один из соавторов и сооснователей архитектурной идеи, а не как единственный изобретатель. Точность этой архитектуры требует отдельных подтверждений намерения, канала, порядка, состояния, совпадения, выхода, пути и результата.

Зелёный индикатор до прохождения трафика

После FlowMod контроллер отправляет Barrier Request и получает ожидаемый ответ. Между тем правило могло попасть не в ту таблицу, получить неверную маску или оказаться в тени записи с большим приоритетом. Group способен выбрать другой bucket, meter — отбросить пакет, порт — остаться заблокированным. На следующем участке может не работать канал или устройство.

Ни один из этих исходов не опровергает Barrier Reply. Они опровергают лишь слишком широкую подпись «изменение успешно».

OpenFlow 1.3.5 определяет барьер как границу последовательности. Когда барьера нет, коммутатор вправе менять порядок сообщений для повышения производительности. В одном соединении все сообщения до Barrier Request должны быть полностью обработаны, включая порождённые ответы и ошибки; затем обрабатывается сам барьер и отправляется ответ; лишь после этого можно начать последующие сообщения.

Так разрешаются конкретные зависимости: сначала создать group, затем установить ссылающийся на неё flow; сначала изменить порт, затем использовать его в Packet-Out; сначала добавить flow, затем отправить пакет через таблицу. Граница относится к управляющему соединению, а не к сетевой доставке.

Интерфейс, созданный коллективно

Статью OpenFlow 2008 года подписали Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker и Jonathan Turner. Они предложили ограниченный программный интерфейс к flow tables реальных коммутаторов: контроллер добавляет и удаляет записи, а последующие пакеты обрабатываются быстрым трактом. В примере Amy-OSPF программа выбирает путь и настраивает каждый коммутатор.

McKeown — один из создателей OpenFlow и SDN, а не единственный автор. Более поздняя семантика Barrier развивалась благодаря операторам, исследователям, производителям и Open Networking Foundation. Его роль в этой теме архитектурная: разделение программного решения и исполнения сделало границу достаточно явной, чтобы точно назвать доказательства по обе стороны.

История внедрения, опубликованная в 2014 году, связывает полевой опыт с появлением команды Barrier в OpenFlow 0.9. Тот же материал описывает разброс задержек установки flows, слабые CPU коммутаторов, проблемы in-band control и диагностику, совмещающую трассы управления с RTT, загрузкой CPU, скоростью установки и прикладными измерениями. Барьер появился внутри многослойной диагностики, а не вместо неё.

«Полностью обработано» не означает «вышло»

Спецификация 1.3.5 сама проводит решающую черту: полная обработка Packet-Out не гарантирует выход пакета из коммутатора. Перегрузка, QoS, заблокированный или неверный порт могут привести к молчаливой потере уже после обработки OpenFlow. Пакеты в сторону контроллера тоже могут исчезнуть под policing или перегрузкой без ожидаемого Packet-In.

Flow entry — объект конвейера с полями match, priority, counters, instructions, timeouts и cookie. Обработка начинается с table 0 и может продолжаться в других таблицах. В каждой побеждает совпадение с наибольшим приоритетом; инструкции изменяют metadata и action set, обращаются к groups и meters, выбирают выход.

Чтение ожидаемого cookie после барьера сильнее одного ответа, но ещё не показывает, что производственный пакет выбрал эту запись. Изменение счётчика подтверждает локальное совпадение, но не следующий линк. Счётчик исходящего порта не равен записи принимающего приложения.

Сфера соединения столь же узка. OpenFlow не синхронизирует разные соединения. Если зависимая операция ушла по auxiliary connection, а барьер — по main connection, ответ на главном канале не покрывает вспомогательный. После reconnect необходимо заново установить роль контроллера, поколение соединения и фактически сохранённое состояние.

Почему в проверке соответствия два теста

Тест ONF OpenFlow 1.3.4 Basic Single Table добавляет до 10 000 flows, удаляет их и отправляет Barrier Request по одному управляющему соединению. Barrier Reply должна появиться после всех запрошенных сообщений Flow-Removed. Соседний тест Packet-Out отдельно использует соединение плоскости данных и проверяет получение пакета.

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

Bundles в OpenFlow 1.5.1 усиливают атомарность конфигурации. Несколько изменений можно подготовить и применить вместе; если одно не проходит commit, набор не должен применяться. Поддержка необязательна и ограничена возможностями устройства. Успешный commit даёт более сильное свидетельство состояния, но не показывает, какой производственный заголовок победил и ответил ли удалённый сервис.

VeriFlow проверяет общесетевые инварианты при изменении правил, поскольку доверия к сложному коду контроллера недостаточно. Он способен найти петлю, black hole или нарушение политики в модели. Но модель не является датчиком на линии и журналом приложения. Модельная проверка и физический результат дополняют, а не заменяют друг друга.

Восемь квитанций одной операции

Проверяемое изменение хранит следующую цепочку:

  1. Намерение: версия политики и желаемый набор правил.
  2. Транспорт: правильные Datapath ID, роль и соединение.
  3. Порядок: Barrier Reply в этом соединении с учётом прежних ошибок.
  4. Состояние: чтение таблицы, приоритета, маски, cookie, group, meter и порта.
  5. Совпадение: репрезентативный контрольный пакет меняет нужные счётчики.
  6. Выход: порт или очередь подтверждает отправку без локальной причины потери.
  7. Путь: наблюдение ниже по тракту или активная проба подтверждает маршрут.
  8. Результат: конечный узел или приложение фиксирует ожидаемую транзакцию.

Общие ключи — версия изменения, коммутатор, поколение соединения, OpenFlow transaction ID, cookie, заголовок пробы и временное окно — не дают склеить старое чтение с новой пробой и получить успех, которого не было.

Источники