From Forces to Ethan

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

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

Начнем с рассмотрения протокола FORCES, который был разработан в инженерной группе Интернета который эффективно определил пользовательский отдельный канал управления для управления переключателями или элементами пересылки.

Затем мы рассмотрим платформу управления маршрутизацией, которая использовала существующий протокол, в частности BGP, чтобы  принимать решения о маршрутизации или решения о передаче данных , которые были приняты маршрутизаторами.

Далее мы рассмотрим, как появление Open Source оборудования обеспечило гораздо более широкое внедрение раздельного управления сетями с коммутацией пакетов.

Итак, почему отделение управления от передачи - хорошая идея?

Во-первых, это обеспечивает более быстрые инновации, так как логика управления напрямую не связана с конкретным оборудованием.

Во-вторых, он позволяет контроллеру потенциально видеть общесетевое представление, тем самым упрощая вывод и объяснение поведения сети.

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

Давайте рассмотрим три различных способа , которые были разработаны для управления сетями с коммутацией пакетов.

Первый экземпляр отдельного канала управления для сетей с коммутацией пакетов вышел из рабочей группы по разработке Интернета. В виде протокола FORCES.

Протокол был впервые стандартизирован в 2003 году. И было три реализации этого конкретного стандарта.

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

В некоторых случаях это выглядит очень похоже на стандарт OpenFlow, который мы знаем сегодня. Но проблема, связанная с этим подходом, заключалась в том , что он требовал стандартизации, принятия поставщиками и развертывания нового оборудования. И эти конкретные препятствия были теми же препятствиями, которые были мотивацией для некоторых из предыдущих работ, таких как активные сетевые проекты, которые мы рассматривали.

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

Такой подход был принят платформой управления маршрутизацией. Идея заключалась в том, что каждая автономная система или независимая сеть может иметь платформу управления маршрутизацией или RCP (Routing Control Platform), которая будет вычислять маршруты от имени маршрутизаторов, а затем использовать существующие протоколы BGP для передачи этих маршрутов маршрутизаторам. Вычисления должны происходить в  RCP, но после вычисления маршрутов результаты этих вычислений будут перенесены в таблицы передачи маршрутизаторов стандартными протоколами маршрутизации.

Таким образом, эти маршрутизаторы как бы "думали" что они просто "разговаривали" с неким старым маршрутизатором, но на самом деле они "разговаривали" с умной коробкой , которая фактически вычисляла маршруты от их имени.

Использование существующих протоколов In-Band для управления сетью с коммутацией пакетов эффективно облегчало  ситуацию. Там где все управление централизовано, в определенной сети, RCP эффективно использовал BGP в качестве канала управления, так что элементы пересылки "думали", что они "разговаривают" только с другим маршрутизатором, но на самом деле весь ум  сети был сконцентрирован в одной точке.

Этот подход несколько упрощает развертывание, так как он не требует принятия новых стандартов протоколов управления.

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

В конечном счете, архитектура все еще оказалась полезной. И версия RCP в настоящее время работает по крайней мере в одной большой сети back bone сегодня, чтобы сделать такие вещи, как автоматическое перенаправление трафика для инцидентов безопасности или очистки трафика, но тем не менее, спектр приложений, которые могут поддерживать что-то вроде RCP  по-прежнему ограничен по сравнению с тем, что может быть возможно с общей отдельной плоскостью управления.

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

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

Ethane требовал развертывания пользовательских коммутаторов. И некоторые из них были реализованы на основе OpenWRT, NetFPGA и Linux.

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

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

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

Итак, что мы узнали об управлении сетью в этом уроке?

Один из уроков заключается в том, что плоскость управления и плоскость данных обязательно должны быть разделены, потому что вертикально интегрированные коммутаторы очень затрудняют внедрение новых плоскостей управления. В некотором смысле FORCES выглядит очень похожим на OpenFlow. Но поскольку это потребовало новой стандартизации и принятия, а также изменений в аппаратном обеспечении, развертывание в конечном итоге стало очень сложным.

Второй урок заключается в том, что использование существующих протоколов упрощает развертывание. Но это также ограничивает то, что можно сделать, и мы видели это в RCP.

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