Программно-определяемые сети - Software-defined networking

Не путать с ISDN (цифровая сеть с интегрированными услугами).

Программно-определяемые сети (SDN) технология - это подход к управление сетью который обеспечивает динамическую, программно эффективную конфигурацию сети для улучшения производительности и мониторинга сети, делая ее более похожей на облачные вычисления чем традиционное управление сетью.[1] SDN призвана учитывать тот факт, что статическая архитектура традиционных сетей децентрализована и сложна, в то время как современные сети требуют большей гибкости и простого устранения неполадок. SDN пытается централизовать сетевой интеллект в одном сетевом компоненте, разъединяя процесс пересылки сетевые пакеты (плоскость данных) из процесса маршрутизации (плоскость управления). В плоскость управления состоит из одного или нескольких контроллеров, которые считаются мозгом сети SDN, в которую встроен весь интеллект. Однако интеллектуальная централизация имеет свои недостатки, когда дело касается безопасности.[1] масштабируемость и эластичность[1] и это основная проблема SDN.

SDN обычно ассоциировался с OpenFlow протокол (для удаленной связи с элементами плоскости сети с целью определения пути сетевые пакеты через сетевые коммутаторы ) с момента появления последнего в 2011 г. Однако с 2012 г.[2][3] OpenFlow для многих компаний больше не является эксклюзивным решением, они добавили проприетарные технологии. К ним относятся Cisco Systems 'Открытая сетевая среда и Nicira с платформа виртуализации сети.

SD-WAN применяет аналогичную технологию к Глобальная сеть (WAN).[4]

Технология SDN в настоящее время доступна для приложений промышленного управления, которые требуют чрезвычайно быстрого переключения при отказе, так называемых программно определяемых сетей (SDN) Operational Technology (OT). Технология OT SDN - это подход к управлению контролем доступа к сети и доставкой пакетов Ethernet на экологически безопасном оборудовании для критически важных инфраструктурных сетей. OT SDN абстрагирует управление плоскостью управления от коммутаторов, централизуя ее в контроллере потока, и применяет SDN в качестве базовой плоскости управления в коммутаторе. Устаревшая плоскость управления удалена, что упрощает переключение и централизует управление плоскостью управления. Общим стандартом плоскости управления, используемым в OT SDN, является OpenFlow, что делает его совместимым с другими решениями SDN, с той разницей, что OpenFlow является единственной плоскостью управления в коммутаторе и что коммутатор сохраняет потоки во время циклов включения питания, а все потоки и избыточность заранее спроектированы для трафика. поэтому коммутаторы могут выполнять переадресацию, на выполнение которой они настроены, с контроллером потока или без него в режиме онлайн. OT SDN обеспечивает преимущества для промышленных сетей в виде производительности, кибербезопасности и ситуационной осведомленности. Повышение производительности достигается за счет упреждающего управления трафиком при непредвиденных обстоятельствах с использованием групп Fast Failover в OpenFlow, что приводит к восстановлению сети при сбоях канала или коммутатора за микросекунды, а не за миллисекунды, как в технологии связующего дерева. Еще одно преимущество в производительности состоит в том, что устранение петель осуществляется посредством планирования маршрутов трафика, а не заблокированных портов, что позволяет владельцу системы активно использовать все порты. Преимущества кибербезопасности OT SDN заключаются в том, что коммутаторы по умолчанию запрещены, а потоки - это правила, позволяющие перенаправлять трафик. Это обеспечивает надежный контроль доступа к сети, при котором пакеты могут проверяться от уровня 1 до уровня 4 модели OSI на каждом шаге. Унаследованные уязвимости безопасности уровня управления устранены, поскольку устаревшая плоскость управления больше не существует. Подмена MAC-таблицы и подмена BPDU больше невозможны, потому что ни того, ни другого нет в коммутаторах OT SDN. Поворот и сетевая разведка больше не работают при правильном программировании потоков, поскольку разрешается пересылка только разрешенного трафика, сочетающего физическое местоположение и путь с виртуальной фильтрацией пакетов. Преимущества OT SDN с точки зрения ситуационной осведомленности позволяют владельцу сети видеть, какие устройства находятся в его сети, какие разговоры могут происходить и происходят, а также между кем эти разговоры могут происходить. Сетевая технология OT SDN позволяет сетям Ethernet удовлетворять жесткие требования к обмену коммуникационными сообщениями для измерения и контроля критически важной инфраструктуры и просто предоставляет владельцу системы контроль над тем, какие устройства могут подключаться к сети, где эти устройства могут подключаться и какие разговоры может выполнять каждое устройство. имеют.

Исследования SDN продолжаются столько же эмуляторы разрабатываются для исследовательских целей, например vSDNEmul,[5] EstiNet,[6] Мининет[7] и Т. Д.

История

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

В Инженерная группа Интернета (IETF) начал рассматривать различные способы разделения функций управления и пересылки в предложенном стандарте интерфейса, опубликованном в 2004 г. и получившем соответствующее название «Пересылка и разделение элементов управления» (ForCES).[8] Рабочая группа ForCES также предложила сопутствующую архитектуру SoftRouter.[9] Дополнительные ранние стандарты IETF, которые преследовали цель отделения управления от данных, включают Linux Netlink в качестве протокола IP-служб.[10] и архитектура на основе элемента вычисления пути (PCE).[11]

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

Использование программного обеспечения с открытым исходным кодом в архитектурах разделенного управления / плоскости данных уходит корнями в проект Ethane в Стэнфордском отделе компьютерных наук. Простая конструкция переключателя Ethane привела к созданию OpenFlow.[12] API для OpenFlow был впервые создан в 2008 году.[13] В том же году была создана NOX - операционная система для сетей.[14]

Работа над OpenFlow продолжалась в Стэнфорде, в том числе с созданием тестовых стендов для оценки использования протокола в одной сети университетского городка, а также в глобальной сети в качестве магистрали для соединения нескольких кампусов.[15] В академической среде было несколько исследовательских и производственных сетей, основанных на OpenFlow переключается с NEC и Hewlett Packard; а также на основе Quanta Computer whiteboxes, начиная примерно с 2009 г.[16]

Помимо академических кругов, первые развертывания были выполнены Nicira в 2010 году для управления OVS от Onix, разработанного совместно с NTT и Google. Заметное развертывание было Google развертывание B4 в 2012 году.[17][18] Позже Google признал их первым OpenFlow с развертываниями Onix в своих центрах обработки данных одновременно.[19] Другое известное крупное развертывание находится в China Mobile.[20]

В Фонд открытых сетей была основана в 2011 году для продвижения SDN и OpenFlow.

На мероприятии Interop and Tech Field Day в 2014 году программно-определяемые сети были продемонстрированы Avaya с использованием моста кратчайшего пути (IEEE 802.1aq ) и OpenStack в качестве автоматизированного кампуса, расширяющего автоматизацию от центра обработки данных до конечного устройства, исключая ручную подготовку к предоставлению услуг.[21][22]

Концепция

Архитектура SDN разделяет функции управления сетью и пересылки, позволяя напрямую программировать управление сетью, а базовую инфраструктуру - абстрагироваться от приложений и сетевых служб.[23]

В OpenFlow протокол может использоваться в технологиях SDN. Архитектура SDN:

  • Напрямую программируемый: Управление сетью программируется напрямую, поскольку не связано с функциями пересылки.
  • Гибкий: Абстрагирование управления от пересылки позволяет администраторам динамически настраивать всю сеть транспортный поток для удовлетворения меняющихся потребностей.
  • Централизованно управляемый: Сетевой интеллект (логически) централизован в программных контроллерах SDN, которые поддерживают глобальное представление сети, которое представляется приложениям и механизмам политик как единый логический коммутатор.
  • Программно настроен: SDN позволяет администраторам сети очень быстро настраивать, управлять, защищать и оптимизировать сетевые ресурсы с помощью динамических, автоматизированных программ SDN, которые они могут писать сами, поскольку эти программы не зависят от проприетарного программного обеспечения.[24]
  • На основе открытых стандартов и без учета поставщика: При реализации через открытые стандарты SDN упрощает проектирование и эксплуатацию сети, поскольку инструкции предоставляются контроллерами SDN, а не несколькими устройствами и протоколами, зависящими от производителя.

Потребность в новой сетевой архитектуре

Бурный рост мобильных устройств и контента, виртуализация серверов и появление облачных сервисов - одни из тенденций, побуждающих сетевую отрасль пересмотреть традиционные сетевые архитектуры.[25] Многие традиционные сети являются иерархическими, построенными из ярусов коммутаторов Ethernet, расположенных в древовидной структуре. Такая конструкция имела смысл, когда доминировали вычисления клиент-сервер, но такая статическая архитектура плохо подходит для динамических вычислений и потребностей хранения данных в современных корпоративных центрах обработки данных, университетских городках и средах операторов.[26] Некоторые из ключевых тенденций в области вычислений, обусловливающих потребность в новой сетевой парадигме, включают:

Изменение схемы движения
В корпоративном центре обработки данных структура трафика значительно изменилась. В отличие от клиент-серверных приложений, в которых основная часть обмена данными происходит между одним клиентом и одним сервером, современные приложения обращаются к разным базам данных и серверам, создавая поток межмашинного трафика «восток-запад», прежде чем возвращать данные в конец. пользовательское устройство в классической схеме движения «север-юг». В то же время пользователи меняют шаблоны сетевого трафика, стремясь получить доступ к корпоративному контенту и приложениям с любого типа устройства (включая собственное), подключаясь из любого места и в любое время. Наконец, многие руководители корпоративных центров обработки данных рассматривают модель служебных вычислений, которая может включать частное облако, общедоступное облако или их сочетание, что приведет к дополнительному трафику в глобальной сети.
Консьюмеризация ИТ
Пользователи все чаще используют мобильные личные устройства, такие как смартфоны, планшеты и ноутбуки, для доступа к корпоративной сети. ИТ-отделы вынуждены тщательно настраивать эти персональные устройства, одновременно защищая корпоративные данные и интеллектуальную собственность и соблюдая нормативные требования.
Рост облачных сервисов
Предприятия с энтузиазмом восприняли как общедоступные, так и частные облачные сервисы, что привело к беспрецедентному росту этих услуг. Корпоративные бизнес-подразделения теперь хотят гибкого доступа к приложениям, инфраструктуре и другим ИТ-ресурсам по запросу и по выбору. Чтобы усложнить задачу, ИТ-планирование облачных сервисов должно осуществляться в среде повышенных требований к безопасности, соответствию и аудиту, наряду с реорганизацией, консолидацией и слияниями бизнеса, которые могут изменить предположения в мгновение ока. Предоставление самообслуживания, будь то в частном или общедоступном облаке, требует эластичного масштабирования вычислений, хранилищ и сетевых ресурсов, в идеале с общей точки зрения и с помощью общего набора инструментов.
«Большие данные» означают большую пропускную способность
Обработка сегодняшних «больших данных» или мегабортов данных требует массивной параллельной обработки на тысячах серверов, каждый из которых требует прямого подключения друг к другу. Рост количества мега-наборов данных вызывает постоянный спрос на дополнительную пропускную способность сети в центре обработки данных. Операторы сетей гипермасштабируемых центров обработки данных сталкиваются с непростой задачей: масштабировать сеть до немыслимого размера и поддерживать возможность подключения «любой-к-любому» без разрушения.[27]

Архитектурные компоненты

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

Следующий список определяет и объясняет архитектурные компоненты:[28]

Приложение SDN
Приложения SDN - это программы, которые явно, напрямую и программно сообщают свои сетевые требования и желаемое сетевое поведение контроллеру SDN через северный интерфейс (NBI). Кроме того, они могут использовать абстрактное представление сети для внутренних целей принятия решений. Приложение SDN состоит из одной логики приложения SDN и одного или нескольких драйверов NBI. Приложения SDN могут сами предоставлять другой уровень абстрактного управления сетью, тем самым предлагая один или несколько NBI более высокого уровня через соответствующие агенты NBI.
SDN контроллер
Контроллер SDN - это логически централизованный объект, отвечающий за (i) перевод требований с уровня приложения SDN на каналы данных SDN и (ii) обеспечение приложений SDN абстрактным представлением сети (которое может включать статистику и события) . Контроллер SDN состоит из одного или нескольких агентов NBI, логики управления SDN и драйвера интерфейса уровня данных управления (CDPI). Определение как логически централизованная сущность не предписывает и не исключает деталей реализации, таких как объединение нескольких контроллеров, иерархическое соединение контроллеров, интерфейсы связи между контроллерами, а также виртуализацию или разделение сетевых ресурсов.
SDN Datapath
SDN Datapath - это логическое сетевое устройство, которое обеспечивает видимость и неоспоримый контроль над объявленными возможностями пересылки и обработки данных. Логическое представление может охватывать все или подмножество ресурсов физической подложки. SDN Datapath состоит из агента CDPI и набора из одного или нескольких механизмов пересылки трафика и нуля или нескольких функций обработки трафика. Эти механизмы и функции могут включать простую пересылку между внешними интерфейсами канала данных или функции внутренней обработки или завершения трафика. Один или несколько каналов передачи данных SDN могут содержаться в одном (физическом) сетевом элементе - интегрированной физической комбинации коммуникационных ресурсов, управляемых как единое целое. SDN Datapath также может быть определен для нескольких физических сетевых элементов. Это логическое определение не предписывает и не исключает деталей реализации, таких как логическое отображение на физическое, управление совместно используемыми физическими ресурсами, виртуализация или разделение SDN Datapath, взаимодействие с сетями без SDN, а также функциональные возможности обработки данных, которые могут включать Уровень OSI 4-7 функции.
Управление SDN с интерфейсом плоскости данных (CDPI)
SDN CDPI - это интерфейс, определенный между SDN Controller и SDN Datapath, который обеспечивает как минимум (i) программный контроль всех операций пересылки, (ii) объявление возможностей, (iii) статистический отчет и (iv) уведомление о событиях. Одно из преимуществ SDN заключается в ожидании того, что CDPI будет реализован открытым, независимым от поставщика и совместимым способом.
SDN северные интерфейсы (NBI)
SDN NBI - это интерфейсы между приложениями SDN и контроллерами SDN, которые обычно предоставляют абстрактные представления сети и позволяют напрямую выражать поведение и требования сети. Это может происходить на любом уровне абстракции (широта) и в различных наборах функций (долгота). Одно из преимуществ SDN заключается в том, что эти интерфейсы будут реализованы открытым, независимым от поставщика и совместимым образом.

Плоскость управления SDN

Централизованный - Иерархический - Распределенный

Реализация плоскости управления SDN может быть централизованной, иерархической или децентрализованной. Первоначальные предложения уровня управления SDN были сосредоточены на централизованном решении, в котором один объект управления имеет глобальное представление о сети. Хотя это упрощает реализацию логики управления, у него есть ограничения масштабируемости по мере увеличения размера и динамики сети. Чтобы преодолеть эти ограничения, в литературе было предложено несколько подходов, которые делятся на две категории: иерархический и полностью распределенный. В иерархических решениях[29][30] распределенные контроллеры работают с разделенным сетевым представлением, тогда как решения, требующие общесетевых знаний, принимаются логически централизованным корневым контроллером. В распределенных подходах[31][32] контроллеры работают со своим локальным представлением или могут обмениваться сообщениями синхронизации для расширения своих знаний. Распределенные решения больше подходят для поддержки адаптивных приложений SDN.

Размещение контроллера

Ключевой проблемой при разработке распределенной плоскости управления SDN является выбор количества и размещения управляющих объектов. Важным параметром, который следует учитывать при этом, является задержка распространения между контроллерами и сетевыми устройствами,[33] особенно в контексте больших сетей. Другие цели, которые были рассмотрены, включают надежность тракта управления,[34] Отказоустойчивость,[35] и требования к приложению.[36]

Перенаправление потока SDN (SDN)

Проактивный против реактивного против гибридного[37][38]
OpenFlow использует TCAM таблицы для маршрутизации последовательностей пакетов (потоки). Если потоки прибывают к коммутатору, выполняется поиск в таблице потоков. В зависимости от реализации таблицы потоков это делается в программной таблице потоков, если vSwitch используется или в ASIC если это реализовано аппаратно. В случае, если соответствующий поток не найден, отправляется запрос к контроллеру для дальнейших инструкций. Это выполняется в одном из трех различных режимов. В реактивном режиме контроллер действует после этих запросов и при необходимости создает и устанавливает правило в таблице потоков для соответствующего пакета. В проактивном режиме контроллер заранее заполняет записи таблицы потоков для всех возможных совпадений трафика, возможных для этого коммутатора. Этот режим можно сравнить с типичными в настоящее время записями в таблице маршрутизации, где все статические записи устанавливаются заранее. После этого запрос на контроллер не отправляется, поскольку все входящие потоки найдут соответствующую запись. Основным преимуществом упреждающего режима является то, что все пакеты пересылаются с линейной скоростью (с учетом всех записей таблицы потоков в TCAM), и задержки не добавляются. Третий режим, гибридный режим, соответствует гибкости реактивного режима для набора трафика и пересылки с малой задержкой (проактивный режим) для остального трафика.

Приложения

SDMN

Программно определяемые мобильные сети (SDMN)[39][40] - это подход к проектированию мобильных сетей, в котором все специфичные для протокола функции реализованы в программном обеспечении, что позволяет максимально использовать стандартное и стандартное оборудование и программное обеспечение как в базовая сеть и сеть радиодоступа.[41] Предлагается как расширение парадигмы SDN для включения Мобильная сеть специфические функции.[42] Начиная с версии 14 3GPP, в архитектуре базовой сети мобильной связи было введено разделение плоскости управляющего пользователя. PFCP протокол.

SD-WAN

An SD-WAN это Глобальная сеть (WAN) управляется с использованием принципов программно-определяемых сетей.[43] Основной движущей силой SD-WAN является снижение затрат на WAN за счет использования более доступных и коммерчески доступных арендованных линий в качестве альтернативы или частичной замены более дорогих. MPLS линий. Контроль и управление осуществляется отдельно от оборудования с помощью центральных контроллеров, что упрощает настройку и администрирование.[44]

SD-LAN

SD-LAN - это Локальная сеть (LAN) построена на принципах программно-определяемых сетей, хотя есть ключевые различия в топологии, сетевой безопасности, видимости и контроле приложений, управлении и качестве обслуживания.[45] SD-LAN разделяет управление и плоскости данных, чтобы обеспечить управляемую политиками архитектуру для проводных и беспроводных локальных сетей. Для сетей SD-LAN характерно использование системы управления облаком и возможность беспроводного подключения без физического контроллера.[46]

Безопасность с использованием парадигмы SDN

Архитектура SDN может включать, облегчать или улучшать приложения безопасности, связанные с сетью, благодаря центральному представлению контроллера о сети и его способности перепрограммировать плоскость данных в любое время. Хотя безопасность самой архитектуры SDN остается открытым вопросом, который уже пару раз изучался в исследовательском сообществе,[47][48][49][50] следующие параграфы посвящены только приложениям безопасности, которые стали возможными или пересмотрены с помощью SDN.

В нескольких исследованиях SDN уже были изучены приложения безопасности, построенные на контроллере SDN, с разными целями. Распределенный отказ в обслуживании (DDoS) обнаружение и смягчение последствий,[51][52] а также ботнет[53] и размножение червя,[54] являются некоторыми конкретными вариантами использования таких приложений: в основном идея состоит в периодическом сборе сетевой статистики из плоскости пересылки сети стандартизированным способом (например, с использованием Openflow), а затем применять алгоритмы классификации к этой статистике для обнаружения любых сетевые аномалии. Если обнаружена аномалия, приложение инструктирует контроллер, как перепрограммировать плоскость данных, чтобы смягчить ее.

Другой вид приложений безопасности использует контроллер SDN путем реализации некоторых алгоритмов защиты от движущихся целей (MTD). Алгоритмы MTD обычно используются для того, чтобы сделать любую атаку на данную систему или сеть более сложной, чем обычно, путем периодического сокрытия или изменения ключевых свойств этой системы или сети. В традиционных сетях реализация алгоритмов MTD не является тривиальной задачей, поскольку сложно создать центральный орган, способный определять - для каждой части системы, которую необходимо защитить, - какие ключевые свойства скрыты или изменены. В сети SDN такие задачи становятся более простыми благодаря центральной роли контроллера. Одно приложение может, например, периодически назначать виртуальные IP-адреса хостам в сети, а затем сопоставление виртуального IP-адреса / реального IP-адреса выполняется контроллером.[55] Другое приложение может имитировать некоторые поддельные открытые / закрытые / отфильтрованные порты на случайных хостах в сети, чтобы добавить значительный шум во время фазы разведки (например, сканирования), выполняемой злоумышленником.[56]

Дополнительную ценность в отношении безопасности в сетях с поддержкой SDN также можно получить с помощью FlowVisor.[57] и FlowChecker[58] соответственно. Первый пытается использовать одну аппаратную плоскость пересылки, разделяющую несколько разделенных логических сетей. Следуя этому подходу, одни и те же аппаратные ресурсы могут использоваться для целей производства и разработки, а также для разделения мониторинга, настройки и интернет-трафика, где каждый сценарий может иметь свою собственную логическую топологию, которая называется срезом. В сочетании с этим подходом FlowChecker[57] реализует проверку новых правил OpenFlow, которые развертываются пользователями с использованием их собственного фрагмента.

Приложения контроллера SDN в основном развертываются в крупномасштабных сценариях, что требует всесторонних проверок возможных ошибок программирования. Система для этого под названием NICE была описана в 2012 году.[59] Внедрение всеобъемлющей архитектуры безопасности требует комплексного и длительного подхода к SDN. С момента его появления разработчики ищут возможные способы защиты SDN, не ставящие под угрозу масштабируемость. Одна архитектура называется Архитектурой безопасности SN-SECA (SDN + NFV).[60]

Групповая доставка данных с использованием SDN

Распределенные приложения, которые работают в центрах обработки данных, обычно реплицируют данные с целью синхронизации, отказоустойчивости, балансировки нагрузки и приближения данных к пользователям (что снижает задержку для пользователей и увеличивает их воспринимаемую пропускную способность). Кроме того, многие приложения, такие как Hadoop, реплицируют данные в центре обработки данных на несколько стоек, чтобы повысить отказоустойчивость и упростить восстановление данных. Все эти операции требуют доставки данных с одного компьютера или центра обработки данных на несколько компьютеров или центров обработки данных. Процесс надежной доставки данных с одного компьютера на несколько компьютеров называется надежной групповой доставкой данных (RGDD).

Коммутаторы SDN могут использоваться для RGDD путем установки правил, разрешающих пересылку на несколько исходящих портов. Например, OpenFlow обеспечивает поддержку групповых таблиц начиная с версии 1.1.[61] что делает это возможным. Используя SDN, центральный контроллер может тщательно и разумно настроить деревья пересылки для RGDD. Такие деревья можно строить, обращая внимание на состояние перегрузки / нагрузки сети для повышения производительности. Например, MCTCP[62] - это схема доставки на многие узлы внутри центров обработки данных, основанная на регулярных и структурированных топологиях сетей центров обработки данных, в то время как DCCast[63] и QuickCast[64] - это подходы к быстрой и эффективной репликации данных и контента в центрах обработки данных через частные глобальные сети.

Отношение к NFV

NFV Виртуализация сетевых функций - это концепция, дополняющая SDN. Таким образом, NFV не зависит от концепций SDN или SDN. NFV отделяет программное обеспечение от оборудования, чтобы обеспечить гибкое развертывание сети и динамическую работу. В развертывании NFV обычно используются стандартные серверы для запуска версий программного обеспечения сетевых служб, которые ранее были аппаратными. Эти программные службы, работающие в среде NFV, называются виртуальными сетевыми функциями (VNF).[65] Гибридная программа SDN-NFV была предоставлена ​​для обеспечения высокой эффективности, гибкости и масштабируемости NFV, направленной на ускорение инноваций и предоставления услуг с использованием стандартных технологий виртуализации ИТ.[65][66] SDN обеспечивает гибкость управления универсальными устройствами пересылки, такими как маршрутизаторы и коммутаторы, с помощью контроллеров SDN. С другой стороны, гибкость NFV обеспечивается для сетевых приложений за счет использования виртуализированных серверов. Вполне возможно реализовать виртуализованную сетевую функцию (VNF) как автономный объект, используя существующие парадигмы сетей и оркестровки. Тем не менее, использование концепций SDN для реализации и управления инфраструктурой NFV дает неотъемлемые преимущества, особенно при рассмотрении управления и оркестровки VNF, и поэтому определяются платформы от нескольких поставщиков, которые включают SDN и NFV в согласованные экосистемы.[67]

Отношение к DPI

DPI Глубокая проверка пакетов обеспечивает сеть с поддержкой приложений, в то время как SDN предоставляет приложениям с поддержкой сети.[68] Хотя SDN радикально изменит общую сетевую архитектуру, она должна справиться с работой с традиционными сетевыми архитектурами, чтобы обеспечить высокую функциональную совместимость. Новая сетевая архитектура на основе SDN должна учитывать все возможности, которые в настоящее время предоставляются в отдельных устройствах или программном обеспечении, кроме основных устройств пересылки (маршрутизаторов и коммутаторов), таких как DPI, устройства безопасности. [69]

Смотрите также

Рекомендации

  1. ^ а б c Бензекки, Камаль; Эль-Фергуги, Абдеслам; Эльбельрхити Элалауи, Абдельбаки (2016). «Программно-конфигурируемые сети (SDN): обзор». Сети безопасности и связи. 9 (18): 5803–5833. Дои:10.1002 / сек.1737.
  2. ^ «Программно-определяемые сети - это не OpenFlow, - заявляют компании». searchsdn.techtarget.com.
  3. ^ «Лаборатория тестирования OpenFlow SDN InCNTRE работает над созданием сертифицированного продукта SDN».
  4. ^ «Прогнозирование внедрения SD-WAN». gartner.com. 2015-12-15. Получено 2016-06-27.
  5. ^ Farias, Fernando N.N .; Младший, Антониу де О .; да Коста, Леонардо Б.; Пинейро, Билли А .; Абелем, Антониу Дж. Г. (2019-08-28). «vSDNEmul: программно-определяемый сетевой эмулятор на основе виртуализации контейнеров». arXiv:1908.10980 [cs.NI ].
  6. ^ Wang, S .; Chou, C .; Ян, К. (сентябрь 2013 г.). «Сетевой симулятор и эмулятор открытого потока EstiNet». Журнал IEEE Communications. 51 (9): 110–117. Дои:10.1109 / MCOM.2013.6588659. ISSN  1558-1896. S2CID  14375937.
  7. ^ Оливейра, Р. Л. С. де; Schweitzer, C.M .; Шинода, А. А .; Лигия Родригес Прет (июнь 2014 г.). «Использование Mininet для эмуляции и создания прототипов программно-определяемых сетей». 2014 IEEE Колумбийская конференция по коммуникациям и вычислениям (COLCOM): 1–6. Дои:10.1109 / ColComCon.2014.6860404. ISBN  978-1-4799-4340-1. S2CID  17915639.
  8. ^ Л. Янг (Intel Corp.), Р. Данту (Университет Северного Техаса), Т. Андерсон (Intel Corp.) и Р. Гопал (Nokia) (апрель 2004 г.). «Структура разделения элементов управления и передачи (ForCES)».CS1 maint: несколько имен: список авторов (связь)
  9. ^ Т. В. Лакшман, Т. Нандагопал, Р. Рамджи, К. Сабнани и Т. Ву (ноябрь 2004 г.). «Архитектура SoftRouter» (PDF).CS1 maint: несколько имен: список авторов (связь)
  10. ^ Дж. Салим (Znyx Networks), Х. Хосрави (Intel), А. Клин (Suse) и А. Кузнецов (INR / Swsoft) (июль 2003 г.). "Linux Netlink как протокол IP-служб".CS1 maint: несколько имен: список авторов (связь)
  11. ^ А. Фаррел (Old Dog Consulting), Дж. Вассер (Cisco Systems, Inc.) и Дж. Эш (AT&T) (август 2006 г.). "Архитектура на основе элемента вычисления пути (PCE)".CS1 maint: несколько имен: список авторов (связь)
  12. ^ Мартин Касадо, Майкл Дж. Фридман, Джастин Петтит, Цзяньин Ло и Ник Маккеун (Стэнфордский университет) (август 2007 г.). «Этан: взятие под контроль предприятия» (PDF).CS1 maint: несколько имен: список авторов (связь)
  13. ^ Н. Маккеун, Т. Андерсон, Х. Балакришнан, Г. Парулкар, Л. Петерсон, Дж. Рексфорд, С. Шенкер и Дж. Тернер. (Апрель 2008 г.). «OpenFlow: внедрение инноваций в университетских сетях» (PDF).CS1 maint: несколько имен: список авторов (связь)
  14. ^ Н. Гуде, Т. Копонен, Дж. Петтит, Б. Пфафф, М. Касадо, Н. МакКаун и С. Шенкер. (Июль 2008 г.). «NOX: к операционной системе для сетей» (PDF).CS1 maint: несколько имен: список авторов (связь)
  15. ^ «GENI. Топология Campus OpenFlow». 2011.
  16. ^ Куанг-Чин Ван «Кей Си» (3 октября 2011 г.). «Программно-определяемые сети и OpenFlow для университетов: мотивация, стратегия и использование» (PDF).
  17. ^ Сушант Джайн, Алок Кумар, Субхасри Мандал, Джун Онг, Леон Путиевски, Арджун Сингх, Суббайя Венката, Джим Уондерер, Джунлан Чжоу, Мин Чжу, Джонатан Золла, Урс Хёльзле, Стивен Стюарт и Амин Вахдат (Google) (12–16 августа, 2013). «B4: Опыт работы с глобально развернутой программно-определяемой глобальной сетью» (PDF).CS1 maint: несколько имен: список авторов (связь)
  18. ^ Брент Солсбери (14 мая 2013 г.). "Внутри программно-определяемой сети Google".
  19. ^ Арджун Сингх, Джун Онг, Амит Агарвал, Глен Андерсон, Эшби Армистед, Рой Бэннон, Себ Бовинг, Гаурав Десаи, Боб Фельдерман, Паули Джермано, Ананд Канагала, Джефф Провост, Джейсон Симмонс, Эйити Танда, Джим Уондерер, Урс Хёльцле , Амин Вахдат (2015). "Восход Юпитера: десятилетие закрытых топологий и централизованного управления в сети центров обработки данных Google".CS1 maint: несколько имен: список авторов (связь)
  20. ^ ""MPLS-TP OpenFlow Protocol Extensions для SPTN «становится формальным стандартом ONF по единодушному одобрению». 27 июня 2017 года.
  21. ^ Камилла Кэмпбелл (6 февраля 2014 г.). «Avaya представляет сетевые инновации на« Дне технического поля »'".
  22. ^ Элизабет Миллер Койн (23 сентября 2016 г.). «Huawei Exec: SDN становятся« совершенно бессмысленным термином »'".
  23. ^ «Определение программно-определяемой сети (SDN)». Opennetworking.org. Получено 26 октября 2014.
  24. ^ Монтазеролгам, Ахмадреза; Ягмаи, Мохаммад Хоссейн; Леон-Гарсия, Альберто (сентябрь 2020 г.). «Мультимедийная сеть с зеленым облаком: энергоэффективное распределение ресурсов на основе NFV / SDN». Транзакции IEEE по экологичным коммуникациям и сетям. 4 (3): 873–889. Дои:10.1109 / TGCN.2020.2982821. ISSN  2473-2400.
  25. ^ "Белые бумаги". Opennetworking.org. Получено 26 октября 2014.
  26. ^ Montazerolghaem, Ahmadreza .; Yaghmaee, M. H .; Леон-Гарсия, А. (2017). «OpenSIP: к программно-определяемой сети SIP». IEEE Transactions по управлению сетью и услугами. PP (99): 184–199. arXiv:1709.01320. Bibcode:2017arXiv170901320M. Дои:10.1109 / tnsm.2017.2741258. ISSN  1932-4537. S2CID  3873601.
  27. ^ Висентини, Клевертон; Сантин, Альтаир; Вьегас, Эдуардо; Абреу, Вилмар (январь 2019 г.). «Механизм выделения ресурсов на основе SDN и с поддержкой нескольких арендаторов для потоковой передачи больших данных в облаке». Журнал сетевых и компьютерных приложений. 126: 133–149. Дои:10.1016 / j.jnca.2018.11.005.
  28. ^ «Обзор архитектуры SDN» (PDF). Opennetworking.org. Получено 22 ноября 2014.
  29. ^ S.H. Еганех, Ю. Ганджали, «Kandoo: структура для эффективной и масштабируемой разгрузки управляющих приложений», протоколы HotSDN, Хельсинки, Финляндия, 2012 г.
  30. ^ Р. Ахмед, Р. Бутаба, «Рекомендации по проектированию для управления глобальными программно определяемыми сетями», журнал Communications, IEEE, vol. 52, нет. 7. С. 116–123, июль 2014 г.
  31. ^ T. Koponen и др., "Onix: платформа распределенного управления для крупномасштабных производственных сетей", протоколы USENIX, сер. OSDI’10, Ванкувер, Канада, 2010 г.
  32. ^ Д. Тунсер, М. Хараламбидес, С. Клейман, Г. Павлу, "Адаптивное управление ресурсами и контроль в программно-определяемых сетях", Управление сетями и услугами, IEEE Transactions on, vol. 12, вып. 1. С. 18–33, март 2015 г.
  33. ^ Б. Хеллер, Р. Шервуд и Н. Маккеун, «Проблема размещения контроллера», материалы HotSDN’12, 2012 г.
  34. ^ Ю.Н. Ху, W.D. Wang, X.Y. Гонг, X.R. Que, S.D. Ченг, «О размещении контроллеров в программно-определяемых сетях», Journal of China Universities of Post and Telecommunications, vol. 19, Приложение 2, вып. 0, с. 92 - 171, 2012.
  35. ^ Ф.Дж. Рос, П.М. Руис, «Пять девяток надежности в программно определяемых сетях», протокол HotSDN’14, 2014 г.
  36. ^ D. Tuncer, M. Charalambides, S. Clayman, G. Pavlou, "On the Placement of Management and Control Functionality in Software Defined Networks," proceedings of 2nd IEEE International Workshop on Management of SDN and NFV Systems (ManSDN/NFV), Barcelona, Spain, November 2015.
  37. ^ "OpenFlow: Proactive vs Reactive". NetworkStatic.net. 2013-01-15. Получено 2014-07-01.
  38. ^ "Reactive, Proactive, Predictive: SDN Models | F5 DevCentral". Devcentral.f5.com. 2012-10-11. Получено 2016-06-30.
  39. ^ Pentikousis, Kostas; Ван, Ян; Hu, Weihua (2013). "Mobileflow: Toward software-defined mobile networks". Журнал IEEE Communications. 51 (7): 44–53. Дои:10.1109/MCOM.2013.6553677. S2CID  10655582.
  40. ^ Liyanage, Madhusanka (2015). Software Defined Mobile Networks (SDMN): Beyond LTE Network Architecture. UK: John Wiley. pp. 1–438. ISBN  978-1-118-90028-4.
  41. ^ Jose Costa-Requena, Jesús Llorente Santos, Vicent Ferrer Guasch, Kimmo Ahokas, Gopika Premsankar, Sakari Luukkainen, Ijaz Ahmed, Madhusanka Liyanage, Mika Ylianttila, Oscar López Pérez, Mikel Uriarte Itzazelaia, Edgardo Montes de Oca, SDN and NFV Integration in Generalized Mobile Network Architecture , в Proc. of European Conference on Networks and Communications (EUCNC), Paris, France. Июнь 2015 г.
  42. ^ Madhusanka Liyanage, Mika Ylianttila, Andrei Gurtov, Securing the Control Channel of Software-Defined Mobile Networks , в Proc. of IEEE 15th International Symposium on World of Wireless, Mobile and Multimedia Networks (WoWMoM), Sydney, Australia. Июнь 2014 г.
  43. ^ Haranas, Mark (8 October 2016). "16 Hot Networking Products Putting The Sizzle In SD-WAN". CRN. Получено 1 ноября 2016.
  44. ^ "SD-WAN: What it is and why you'll use it one day". networkworld.com. 2016-02-10. Получено 2016-06-27.
  45. ^ Serries, William (12 September 2016). "SD-LAN et SD-WAN : Deux Approches Différentes pour le Software Defined Networking". ZDNet. Получено 1 ноября 2016.
  46. ^ Керравала, Зевс (13 сентября 2016 г.). "Aerohive Introduces the Software-defined LAN". Сетевой мир. Получено 1 ноября 2016.
  47. ^ Kreutz, Diego; Ramos, Fernando; Verissimo, Paulo (2013). "Towards secure and dependable software-defined networks". Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking. С. 50–60.
  48. ^ Scott-Hayward, Sandra; O'Callaghan, Gemma; Sezer, Sakir (2013). "SDN security: A survey". Future Networks and Services (SDN4FNS), 2013 IEEE SDN for. С. 1–7.
  49. ^ Benton, Kevin; Camp, L Jean; Small, Chris (2013). "Openflow vulnerability assessment". Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking. С. 151–152.
  50. ^ Abdou, AbdelRahman; van Oorschot, Paul; Wan, Tao (May 2018). "A Framework and Comparative Analysis of Control Plane Security of SDN and Conventional Networks". IEEE Communications Surveys and Tutorials. появиться. arXiv:1703.06992. Bibcode:2017arXiv170306992A.
  51. ^ Giotis, K; Argyropoulos, Christos; Androulidakis, Georgios; Kalogeras, Dimitrios; Maglaris, Vasilis (2014). "Combining OpenFlow and sFlow for an effective and scalable anomaly detection and mitigation mechanism on SDN environments". Компьютерная сеть. 62: 122–136. Дои:10.1016/j.bjp.2013.10.014.
  52. ^ Braga, Rodrigo; Mota, Edjard; Passito, Alexandre (2010). "Lightweight DDoS flooding attack detection using NOX/OpenFlow". Local Computer Networks (LCN), 2010 IEEE 35th Conference on. С. 408–415.
  53. ^ Feamster, Nick (2010). "Outsourcing home network security". Proceedings of the 2010 ACM SIGCOMM workshop on Home networks. С. 37–42.
  54. ^ Jin, Ruofan & Wang, Bing (2013). "Malware detection for mobile devices using software-defined networking". Research and Educational Experiment Workshop (GREE), 2013 Second GENI. 81-88.CS1 maint: location (связь)
  55. ^ Jafarian, Jafar Haadi; Al-Shaer, Ehab; Duan, Qi (2012). "Openflow random host mutation: transparent moving target defense using software defined networking". Proceedings of the first workshop on Hot topics in software defined networks. С. 127–132.
  56. ^ Кампанакис, Панос; Perros, Harry; Beyene, Tsegereda. SDN-based solutions for Moving Target Defense network protection (PDF). Получено 23 июля 2014.
  57. ^ а б Sherwood, Rob; Gibb, Glen; Yap, Kok-Kiong; Appenzeller, Guido; Casado, Martin; McKeown, Nick; Parulkar, Guru (2009). "Flowvisor: A network virtualization layer". OpenFlow Switch Consortium, Tech. Представитель.
  58. ^ Al-Shaer, Ehab & Al-Haj, Saeed (2010). "FlowChecker: Configuration analysis and verification of federated OpenFlow infrastructures". Proceedings of the 3rd ACM workshop on Assurable and usable security configuration. pp. 37–44.
  59. ^ Canini, Marco; Venzano, Daniele; Peresini, Peter; Kostic, Dejan; Rexford, Jennifer; и другие. (2012). A NICE Way to Test OpenFlow Applications. NSDI. pp. 127–140.
  60. ^ Bernardo and Chua (2015). Introduction and Analysis of SDN and NFV Security Architecture (SA-SECA). 29th IEEE AINA 2015. pp. 796–801.
  61. ^ B. Pfaf; и другие. (28 февраля 2011 г.). "OpenFlow Switch Specification" (PDF). Получено 8 июля, 2017.
  62. ^ T. Zhu; и другие. (October 18, 2016). "MCTCP: Congestion-aware and robust multicast TCP in Software-Defined networks". 2016 IEEE/ACM 24th International Symposium on Quality of Service (IWQoS). IEEE. С. 1–10. Дои:10.1109/IWQoS.2016.7590433. ISBN  978-1-5090-2634-0. S2CID  28159768.
  63. ^ M. Noormohammadpour; и другие. (July 10, 2017). "DCCast: Efficient Point to Multipoint Transfers Across Datacenters". USENIX. Получено 3 июля, 2017.
  64. ^ M. Noormohammadpour; и другие. (2018). QuickCast: Fast and Efficient Inter-Datacenter Transfers using Forwarding Tree Cohorts. arXiv:1801.00837. Bibcode:2018arXiv180100837N. Дои:10.31219/osf.io/uzr24. Получено 23 января, 2018.
  65. ^ а б William, Stalling (2016). "Foundations of Modern Networking: SDN, NFV, QoE, IoT, and Cloud". Pearson Education.
  66. ^ Rowayda, A. Sadek (May 2018). "An Agile Internet of Things (IoT) based Software Defined Network (SDN) Architecture". Egyptian Computer Science Journal. 42 (2): 13–29.
  67. ^ Platform to Multivendor Virtual and Physical Infrastructure
  68. ^ Graham, Finnie (December 2012). "The Role Of DPI In An SDN World". Белая бумага.
  69. ^ Series, Y. (May 2015). "Global Information Infrastructure, Internet Protocol Aspects And NextGeneration Networks". ITU-T Y.2770 Series, Supplement on DPI Use Cases and Application Scenarios.