The 4D Network Architecture (подстрочник на русском языке)

С возвращением. На этом уроке мы будем говорить о 4D сетевой архитектуре. Мы поговорим о мотивации 4D сетевой архитектуры и определим 4Ds архитектуры. Мы также поговорим о том, как терминология 4D относится к SDN Today. И мы рассмотрим 4D в контексте нескольких приложений для управления сетями реального мира. Чтобы понять архитектуру 4D, полезно сравнить архитектуру с архитектурой обычных IP-маршрутизаторов. Мы рассмотрим, как управляются обычными IP-маршрутизаторами. Мы можем думать об управлении сетью с точки зрения трех плоскостей. Планы управления и данных , о которых мы все готовы говорили, а также плоскость управления, которая строит широкий обзор сети и используется для настройки маршрутизаторов для достижения различных целей сети. Плоскость управления, о которой говорит архитектура 4D, немного отличается от управляющей плоскости, о которой мы говорили до сих пор. И тогда он просто действительно говорит о протоколах маршрутизации, изменении топологии трека, вычислении маршрутов, а затем установке таблиц пересылки, но на самом деле не говорит о чем-то, что имело бы представление в масштабах всей сети. Таким образом, в этом смысле мы говорим о плоскости управления в строго обычном смысле, то, что бы просто вычислять маршруты, но не делать ничего более сложного, как достичь вызовов управления в масштабах всей сети. Целью архитектуры маршрутизации 4D является удаление или минимизация этого обычного плана маршрутизации. Другими словами, это очень похоже на цели документа RCA, цель которого состоит в том, чтобы удалить функции маршрутизации из самих маршрутизаторов и переместить их в отдельную программную систему. Преимущества этого заключаются в ускорении инноваций в управлении сетью за счет переноса большого объема информации в программное обеспечение и устранения зависимости от поставщиков в IETF. Еще одним следствием является упрощение систем управления. Поскольку вместо того, чтобы инвертировать операции плоскости управления, чтобы выяснить, что будет делать сеть в результате определенной конфигурации маршрутизации, система управления сетью может просто напрямую управлять формирующей таблицей сети. Взаимодействие между поставщиками становится проще, поскольку совместимость необходима только в протоколах на проводах. Например, протокол, такой как PGP, может использоваться для управления маршрутизаторами, но до тех пор, пока интеллектуальная информация о том, как заполнять таблицы маршрутизации выполняется в программном обеспечении, у нас есть гораздо больше гибкости в разработке этой аналитики. Следует надеяться, что маршрутизаторы также должны быть проще и дешевле, так как на маршрутизаторе будет мало программного обеспечения или вообще не будет. Мы видим, что такая тенденция приходит к реализации сегодня в понятии белых переключателей коробки. Одна из реализаций архитектуры 4D заключалась в том, что на самом деле можно удалить плоскость управления с маршрутизаторов. Это осознание в некотором смысле вдохновило движение открытого потока, которое последовало за архитектурой 4D. Можно удалить эту обычную плоскость управления или интеллектуальную маршрутизацию с маршрутизаторов, так как программное обеспечение управления может работать в другом месте. Состояние и вычисление разумно. Накладные расходы системы могут быть амортизированы , так как многие функции дублируются между маршрутизаторами. Плоскость управления может получить более легкий доступ к другой вспомогательной информации, которую она может использовать для принятия интеллектуальных решений о пересылке. В некоторых случаях элемент управления, может даже перейти к конечным хостам. Архитектура 4D имеет три цели. Один из них заключается в достижении целей уровня сети, а не целей уровня маршрутизатора, и сетевые операторы должны настраивать всю сеть для достижения цели, а не отдельные маршрутизаторы. Эти цели могут включать минимизацию максимального использования канала в сети и обеспечение подключения при всех сбоях второго уровня. Вторая цель архитектуры 4D заключается в достижении широкого сетевого представления. Полная видимость того, что происходит в сети, позволяет принимать более последовательные решения. Эти представления могут включать представления матрицы трафика по всей сети, топологии и состояния различного оборудования в сети. Третья цель 4D архитектуры — прямое управление. Программная подсистема, управляющая пересылкой, должна иметь прямой единственный контроль над операциями плана данных, такими как переадресация пакетов, фильтрация, маркировка и буферизация. Вот планы 4D. На самом низком уровне у нас есть план данных, который точно такой, как он существует сегодня. Ответственность плана данных заключается в том, чтобы просто пересылать трафик в соответствии с тем, что находится в таблицах пересылки. На высшем уровне у нас есть план принятия решений, который выполняет все управление и контроль. Это, по сути, мозги сети, если хотите. Она включает в себя всю логику. Это принимает решения о том, что в конечном счете должно идти в плоскости данных. Между решением и плоскостью данных, у нас есть два других самолета. Одним из них является плоскость распространения, которая просто канал управления, который позволяет плоскости принятия решений получать представление в масштабах всей сети из плоскости данных и непосредственно управлять плоскостью данных на основе решений, которые она принимает. В контексте RCP плоскостью распространения является, например, протокол маршрутизации BGP, который RCP использует для получения общего представления сети, а также для передачи решений маршрутизации отдельным маршрутизаторам. Наконец, у нас есть самолет обнаружения, который позволяет принимать решения плоскости. Обнаружение топологии, мониторинг трафика и другие сведения о сети. Плоскость принятия решений включает в себя, по сути, все функции , которые работают на представлении всей сети и выполняют любые цели уровня сети. К ним относятся выбор путей и проектирование трафика , контроль доступности, настройка VPN и т.д. Плоскость распространения включает в себя все функции, которые поддерживают создание общего вида сети, такие как обнаружение топологии и другие измерения. Он также отвечает за установку инструкций плоскости данных. Ключевое замечание 4D Architecture заключается в том, что хорошие абстракции должны уменьшить сложность или, как прежде, протокол маршрутизации содержит много сложности и много дублированных функций с вещами, которые сетевые операторы хотели бы сделать на более высоких уровнях в этом так называемом управлении самолет. В архитектуре 4D плоскость распространения становится просто каналом управления между плоскостью принятия решений и плоскостью данных. Другими словами, протоколы маршрутизации становятся не более чем управляющим каналом, и вся сложная логика находится в плоскости принятия решений. Давайте рассмотрим два приложения для управления сетью в контексте 4D. При проектировании трафика информация о топологии из плоскости распространения используется как для вычисления матрицы трафика, так и для вычисления путей, которые должны быть достигнуты на конкретном уровне сети. Проектирование трафика также принимает информацию о нагрузке трафика из плоскости данных и передает ее в плоскость принятия решений для помощи в вычислении этой матрицы трафика. После вычисления результирующих задач плоскость принятия решений использует плоскость распространения, чтобы вернуть эти решения в плоскость данных. В качестве другого примера, давайте предположим, что мы хотим использовать контроль доступа или какой-либо другой механизм для изоляции трафика. В этом случае мы имеем тот же тип взаимодействия, что и в проектировании дорожного движения, но оператор может также указать матрицу достижимости, которая определяет, кто должен быть в состоянии говорить с кем, а кто не может говорить с кем. Таким образом, в дополнение к нажатию путей, игра решения может также толкать списки управления осями. Интересная вещь в этом примере заключается в том, что, поскольку плоскость принятия решений видит как проектирование движения, так и контроль доступа, она может принимать решения, которые оптимизируют нагрузку трафика, при этом соблюдая ограничения доступности. Это резко контрастирует с обычной сетью, где эти параметры конфигурации часто выполняются независимо друг от друга. Читая документ 4D и некоторые из его мотивации, это может быть запутанным для тех из нас, кто знаком с терминологией SDN плоскости управления и плоскости данных, которая, по сути, является стандартной терминологией в настоящее время. В документе 4D говорится об устранении плоскости управления. Ну, SDN все еще имеет управляющую плоскость, но это не совсем то, что бумага 4D называла управляющей плоскостью. То, что 4D вызывает плоскость управления, на самом деле распределенные протоколы маршрутизации, реализуемые по маршрутизаторам. И то, что мы называем управляющей плоскостью сегодня , важно, что плоскость принятия решений в 4D. Другими словами, мы перенесли протоколы маршрутизации из распределенных маршрутизаторов в отдельную программную систему, которая может быть логически централизована. С точки зрения терминологии 4D, план распространения все еще жив, но мы часто просто называем его каналом управления. В RCP плоскостью распространения является BGP, а OpenFlow — это то, что изначально называлось secchan. Плоскость распространения - это не что иное, как протокол управления, используемый плоскостью управления для разговора с плоскостью данных, или в 4D терминологии, которую плоскость принятия решений использует для разговора с плоскостью данных. Таким образом, архитектура имеет четыре слоя: плоскость данных, обрабатывающая пакеты, плоскость обнаружения, собирающая топологию, и информацию о дорожном движении. План распространения, устанавливающий правила обработки пакетов, и план принятия решений, в котором логические централизованные контроллеры преобразуют общие сетевые цели в состояние, которое обрабатывает пакеты и пересылает трафик. Архитектура 4D следовала за работой RCP в качестве обобщения. И в некотором смысле вдохновил все движение SDN, потому что другие последовали за более общими реализациями, которые не только фокусировались на маршрутизации, но и достигали других целей сетевого уровня, и в конечном итоге использовали другие протоколы помимо протоколов маршрутизации в качестве плоскости распространения .