Усовершенствованный способ функционирования гипервизора NFV в сетях SDN

РЕФЕРАТ

Работа содержит 105 страниц, 35 рисунков и 2 таблицы. Было использовано 34 источник.

Актуальность: на сегодняшний день активно развиваются сетевые технологии использования разумных систем управления. А именно за последние 5 лет все больше компаний предлагают пакетные решения для организации транспорта в телекоммуникационной сети. Это становится возможным за счет использование программно управляемых сетей(SDN) да технологии виртуализации сетевых функций. Однако много областей остаются неизученными современными реализациями гипервизора сети. В этой дипломный работе представлено да оценены некоторые функции, предоставляемые сетевыми гипервизорами, такие как полная доступность пространства заголовков, изоляция и прозрачные возможности пересылки трафика для арендаторов да другое. Результаты указывают на то, что гипервизоры сети привносят гибкость SDN в процесс виртуализации облегчающей сети сетевым администратором распределение сети между арендаторами. Однако такая повышенная гибкость может повлечь за собой снижение производительности, а также создает дополнительные риски взаимодействия через отсутствие стандартизации методов виртуализации.

Цель работы: разработать рекомендации по функционированию гипервизора NFV за счет использование ряда средств реализации контроллера SDN что позволит обнаружить преимущества да недостатки существующих решений да сформировать пакетное решение для конкретной задачи построения сети.

Задачи исследование:

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

Предмет исследование: функционирование гипервизора NFV за счет использование ряда средств реализации контроллера SDN.

Методы исследования: основными методами исследования является математическое и имитационное моделирование.

Научная новизна: Предлагали усовершенствованный способ функционирования гипервизора NFV в сетях SDN, основанный на группе методов виртуализации да позволяет использовать преимущества каждого с них.

Практическая новизна: разработано ряд коротких программ (скриптов) которые позволяют проводить тестирование имитационных моделей ПКМ с виртуализацией.

СОДЕРЖАНИЕ

ПЕРЕЧЕНЬ СОКРАЩЕНИЙ

ВВЕДЕНИЕ

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

Оцениваются три разных сетевых гипервизора: FlowVisor, VeRTIGO и OpenVirteX. Или инструменты виртуализации оцениваются за помощью экспериментов, что проводятся на трех разных испытательных стендах: эмулированный сценарий Mininet, физический испытательный стенд с одним коммутатором, а также удаленный испытательный стенд GENI. Результаты показывают, что сетевые гипервизоры привносят гибкость SDN в виртуализацию. сети, упрощая для сетевых администраторов точное определение того, как сеть делится на две части и делится между клиентами. Однако такая повышенная гибкость может привести к снижению производительности, а также к дополнительным. рисков взаимодействия через отсутствие стандартизации методов виртуализации.

РАЗДЕЛ 1

SDN ОСНОВНЫЕ ПОЛОЖЕНИЕ, КОНЦЕПЦИЯ

Традиционные телекоммуникационные сети проектировались с расчета на использование специализированных аппаратных устройств (маршрутизаторов, Ethernet- коммутаторов, оборудования EPC (Enhanced Packet Core), межсетевых экранов, балансировщиков нагрузка тому подобное. Или устройства создавались на базе специфических аппаратных и программных платформ отдельных вендоров. Развертывание этих «монолитных» сетевых элементов приводило к длительных циклов проектирование и запуско-наладочных работ, а, следовательно к замедление вывод на рынок новых продуктов и услуг. Обслуживание и управление такой сетью было достаточно неэффективно и дорого. Все это приводило к того, что рост инвестиций в развитие сети для удовольствие запросов абонентов превышал рост доходов от предоставления услуг в ней.

Тем нет меньше, в данный время сети телекоммуникационных операторов состоят в основном с «монолитных» сетевых элементов, где функции управление, администрирование и пересылка данных (трафик пользовательских данных) выполняются на основе физических, "железных" устройств. Очень часто сеть строится из сетевых элементов от одного производителя (вендора), поскольку в в этом случае действительно легче обеспечить совместимость. Политика "эксклюзивного" поставщика" является общепринятой в вендорской среде. Развертывание новых услуг, модификации ("апгрейды") оборудования или услуг производится по очереди на каждому сетевом элементе и требует тесной координации внутренних и внешних ресурсов оператора Такая монолитная организация делает операторскую сеть негибкой, усложняет введение новых услуг и функций, а также увеличивает зависимость оператора от специфических ( "проприетарных") решений

конкретных вендоров.

14

Поэтому, в настоящее время многие операторы выбрали путь цифровой трансформации на базе технологий SDN / NFV. Задачи такой трансформации - такие:

Основные свойства сети, построенной на принципах SDN / NFV:

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

Традиционные сети – это распределенные системы, состоящие из сетевых. устройств, отвечающих за обработку как плоскости управления, так и плоскости пересылка данных сети. Функция плоскости управление решает, как след обрабатывать трафик сети; она отвечает за обнаружение соседних устройств и сетей да решение вопросы, куда след перенаправлять трафик. Протоколы обнаружение топологии, дерева охвата и маршрутизации являются примерами функций плоскости управление [33]. Плоскость пересылка данных использует только таблицы пересылка, которые раньше были рассчитаны плоскостью управление, и использует эту информацию для быстрой пересылки трафика [33].

Программно-конфигурированная сеть (SDN, Software-defined Networking) - сеть передачи данных, в какой уровень управление сетью отделенный от устройств передачи данных и реализуется программно [1].

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

Концепция SDN предполагает:

Таким образом, реализация концепции SDN – разделение управления сетью. (плоскости управление) и механизма продвижение данных (плоскости данных), перенос функций управление в отдельные вычислительные устройства, которые называются SDN-контроллерами, приводит к замене традиционной распределенной модели маршрутизации централизованной моделью, превращая процесс управление сетью, что включает создание маршрутов, в процесс программирование сети в целом [3].

В архитектуре SDN точкой отсчета, как правило, есть централизованная платформа контроллера, изображенная в центре Рисунка 1.1. Сетевые приложения – это программные модули, взаимодействующие с платформой контроллера через интерфейс программирование приложений (API), программный интерфейс. Типичными сетевыми приложениями есть «MAC learning», балансировка нагрузка да алгоритмы маршрутизации API программного интерфейса нет очень хорошо стандартизированные, и есть

множество различных вариантов по выбору [33]. Поэтому платформа контроллера и сетевые программы часто интегрированы в единое программное обеспечение, которое называется контроллером. POX, Floodlight да Beacon - это примеры контроллеров, которые предлагают стандартную программу "MAC learning".

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

OpenFlow разрешает контроллеру манипулировать трафиком в плоскости пересылка данных путем установка правил потока в таблицах потоков OpenFlow коммутаторы. Каждое правило потока состоит из пар, совпадений и действий. Например, пакет может быть сопоставлен за MAC-адресом назначение, IP- адресом источника и/или многими другими типичными полями заголовка. Если пакеты соответствуют правилу потока, тогда их можно переадресовать контроллеру, пропустить, перезаписать заголовки, отправить со всех портов коммутаторов и т.п. [33].

Ключевой функцией виртуализации сети в SDN является исследование топологии. Для успешной реализации переадресации трафика контроллеру необходимо знать топологию плоскости переадресации данных – как физически взаимосвязаны сетевые устройства. Обычно контроллеры OpenFlow обнаруживают плоскость пересылка данных, сначала присылая сообщение OpenFlow PACKET OUT с просьбой сетевых устройств залить кадры протокола обнаружение уровня связи (LLDP) с всех портов. Затем контроллер ждет сообщений OpenFlow PACKET IN, несущие сообщение LLDP. Сообщения PACKET IN содержат информацию о том, какой порт получил какие сообщения LLDP, что позволяет контроллеру строить график сети. Этот процесс объясняется Pakzad et al. [47] иизображено на рисунке 1.2. Контроллер полностью обнаруживает топологию, повторяя этот процесс для всех сетевых устройств

Идентификация устройства также играет важную роль в виртуализации сети на основе SDN. Каждый коммутатор OpenFlow, что поддерживает сеть, однозначно идентифицируется за помощью идентификатора пути передачи данных (DPID), 64-битового поля, состоящего из 48 битов реальной уникальной MAC-адреса сетевого устройства плюс 16 битов, которые остаются как дополнительное поле идентификации. Поставщики могут использовать это доп. битовое поле любым способом, каким они желают [8]. Например, в коммутаторе Hewlett-Packard, каждый экземпляр OpenFlow ассоциируется с номером VLAN в коммутаторе. Дополнительное 16-битное поле в DPID используется для перенос номера VLAN, соответствующий экземпляру OpenFlow. Это позволяет легко различить, какими портами коммутатора можно управлять через определенный DPID - любые порты, принадлежащие к данного VLAN.

Виртуализация на основе SDN обычно реализуется путем введение контроллеров прокси-серверов, действующих как гипервизоры сети между плоскостью пересылка данных да многими контролерами-арендаторами, которые совместно используют контроль над одной и той же инфраструктурой. Как показано на рисунку 1.3, гипервизоры сети могут изменить способ видение сети контролерами арендатора. Контроллер арендатора 1 имеет прозрачный контроль над всеми. сетевыми устройствами; Контроллер аренды 2 видит абстракцию всей сети, представленную одним большим коммутатором; Контроллер аренды 3 видит только часть сети, что содержит три из пяти коммутаторов.

Примерами сетевых гипервизоров, работающих по принципу прокси- контроллер, есть: FlowVisor, OpenVirteX, Vertigo , AutoVFlow да AutoSlice.

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

Традиционные методы развития сетей состоят в «аппаратном» принципе:

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

Ограничение гибкости

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

Ограничение масштабируемости

Возможности масштабирования физических сетевых устройств ограничены как в части оборудование, да и программного обеспечение. Оборудование требует питание и места для размещение, что часто ограниченное в зонах плотной застройки.

Длинный время вывод услуг на рынок

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

Ограничение администрирование

Системы мониторинга используют стандартные протоколы, такие как SNMP, NetFlow, Syslog и т.п. для сбора информации о состояние устройств. Однако для мониторинга вендороспецифических (проприетарных) параметров, стандартных систем может быть недостаточно. В этом случае, для каждого сетевого домена, построенного на оборудовании определенного поставщика, нужна проприетарная система мониторинга

Операционные расходы

Вендороспецифическое оборудование повышает операционные расходы, поскольку требует наличии в штате оператора соответствующих специалистов. Или, как вариант, требует использование «Managed services» (есть «профессиональных услуг» от поставщика). Это приводит к «вендорозависимости», т.е. решений конкретного поставщика.

Плавность рост емкости сети

Требования к рост емкости сети (как на короткие, да и на длительные сроки) сложно спрогнозировать. Это ведет к непроизводительных капитальных затрат. Напротив, когда ресурсы сети оказываются исчерпанными, проходит много времени, прежде чем емкость сети удается расширить.

Взаимодействие

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

Виртуализация - технология какая разрешает запускать несколько операционных систем на одном физическом сервере Концепция виртуализации серверов достаточно давно используется в дата-центрах (ЦОД, центрах обработки данных). При этом, физические серверы заменяются их виртуальными «копиями», работающими этаж гипервизора. Это позволяет, кроме другого, достичь более эффективного использование физических ресурсов дата-центр.

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

Фактически, NFV отделяет программное обеспечение от оборудования и предоставляет возможность использовать любое коммерчески доступное, стандартное оборудование COTS (Commercial Off the Шелф) для исполнение на нем специализированных сетевых функций, которые можно изменять быстро и в любой момент.

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

Свобода выбора оборудование

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

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

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

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

Скорость и оперативность

на противовес физического оборудование, сетевые функции VNF могут создаваться и удаляться «на лету», по большей части автоматизировано, без необходимости привлечения работы технического персонала

Такое свойство носит название «эджайл» (agile – гибкий, оперативный, моторный, эффективный), срок, какой укоренился в технической литературе в английской транскрипции, поскольку его невозможно перевести на русский язык одним словом.

Масштабируемость и эластичность

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

Эта проблема решается в NFV, какая разрешает получать нужны ресурсы очень быстро, разворачивая новые VNF на виртуальных машинах VM с имеющегося пула ресурсов

Поскольку эти VNF не ограничены параметрами специализированного физического оборудование, они могут обеспечить свойство «эластичности», то есть они могут быть развернутые, когда они нужны, и свернутые, когда они нет нужны.

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

Использование стандартных ИТ-средств

Поскольку NFV использует ту же инфраструктуру, что и стандартные дата-центры, она может использовать все наработанные в них приемы

развертывание и управление. Это дает возможность использовать существующие методы и средства ИТ для телекоммуникационных сетей.

Быстрое развертывание и лишение от вендорозависимости

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

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

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

Упрощение обслуживание да технической эксплуатации

Обслуживание и поддержка операций с помощью NFV позволяет снизить возможны периоды недоступности услуг. Например, выход с лада виртуальной машины, на которой работает функция сети немедленно повлечет за собой собой запуск резервной виртуальной машины, которая будет выполнять VNF точно с того же места, на котором произошел сбой активной VM.

Это разрешает также достигать модификации программного обеспечение в процессе работы, ISSU (In-Service Software Upgrade) в режиме 24/7.

Все это значительно снижает и даже полностью устраняет потери, связанные с неисправностями на сети.

Термин NFV впервые был введен ведущими операторами связи мира в SDN OpenFlow World Congress в 2012 году. Они проанализировали ограничения традиционного метода развития сети, указанные выше, и создали рабочую группу по разработке спецификаций NFV ISG (Industry Specification Group) под руководством Европейского института по разработке стандартов для телекоммуникаций ETSI (European Telecommunications Standards Institute).

Рабочая группа NFV ISG выдвинула три основных критерия, которые должны быть реализованы в стандартах (рекомендациях) для NFV:

Динамические операции (Dynamic operations): контроль за операционными параметрами сети за помощью точного (гранулярного) управление и мониторинга состояния сети.

Архитектура NFV складывается с трех основных подсистем:

Кроме NFVI, подсистемы представляют собой программное обеспечение, а нет оборудование. NFVI включает в себя как физическое оборудование (вычислений, хранение, сети), да и виртуальное «оборудование»: серверы, системы хранение, сетевые устройства. Уровень виртуализации (Гипервизор и гостевые операционные системы) дают возможность развертывать на физических серверах виртуальные машины VM (Virtual Machines), выполняющие любые положенные на них функции. Для VM нет имеет большого значение, на котором именно физическом сервере она развернута и работает. Строго говоря, в архитектуру NFV также необходимо включить подсистему поддержки операций и бизнеса (OSS/BSS), которая есть частью традиционной системы оператора связи. Однако, наличие этой подсистемы в архитектуре NFV есть временным, поскольку операторы нет могут одномоментно отказаться от существующих OSS/BSS и сразу перейти на MA- (такое возможно только для новых операторов). MA- должна иметь полную видимость (операционное состояние, статистика использования и др.) всех программных сущностей, развернутых в системе NFV, и управлять ими. Поэтому именно MA- представляет наиболее подходящий интерфейс для подсистемы OSS / BSS в части сбора операционных данных В будущем, по мере трансформации сети, все функции OSS / BSS должны перейти к MA.

Выводы

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

Также была представлена обобщенная архитектура NFV которая состоит из виртуализированных сетевых функций, инфраструктуры виртуализации да подсистемы управления и оркестрации.

РАЗДЕЛ 2

МЕТОДЫ ВИРТУАЛИЗАЦИИ

В данный время технология виртуальной локальной сети (VLAN) стандартизированная стандартом IEEE 802.1Q-2014 [24]. VLAN обеспечивают надежную изоляцию трафика да уменьшение трансляции «бродкаст» доменов в локальных сетях, и это одна из самых основных форм виртуализации сети. Основная функциональность реализована путем введение тегу VLAN (тег 802.1Q) внутрь кадров Ethernet. Например, коммутаторы, поддерживающие VLAN не позволяют пересылать кадры, отмеченные определенным тегом VLAN X в портов, принадлежащих только VLAN Y. К полям в кадре уровня 2 Ethernet II, что поддерживает VLAN, входят [24]:

4 байты тегу VLAN разделяются следующим образом [24]:

Кроме того, использование тегов VLAN также позволяет обозначить трафик разными приоритетами. Например, для временных кадров, сформированных IP- телефоном, поле PCP может быть настроено на более высокое значение, что указывает на то, что этот кадр следует пересылать с большим приоритетом в сети.

Некоторые проблемы возникают с использованием фреймов с одним тегом VLAN. Например, можно создать только 2 12 виртуальных сетей, число которого нет хватает для текущих сетей ЦОД с тысячами виртуальных машин. Кроме того, каждый клиент может использовать только подмножество с 2 12 VID. Эту проблему частично решает Q-in-Q, что объясняется в следующем разделе.

Использование двух тегов VLAN на кадры разрешает клиентам использовать полное пространство заголовка VLAN, преодолевая ограничение VID. Использование двух тегов VLAN в одному кадры, как правило, поставщики сетевого оборудование называют Q-in-Q [31] и сначала было указано стандартом IEEE 802.1ad-2005 [26]. Стандарт описывает изоляцию множества клиентских сетей в пределах одного провайдера, присваивая один VID каждому клиенту в первом теге VLAN кадра, и клиент может свободно использовать любой из 2 12 VID во втором тэге VLAN. Название Q-in-Q является ссылкой на тот факт, что тег 802.1Q снова используется в рамках 802.1Q. Затем оригинальный стандарт 802.1ad был включен в стандарт IEEE 802.1Q-2014 [24].

На рисунке 2.4.1 показаны разные типы кадров для иллюстрации и сравнения различных вариантов тегирования и инкапсуляции, возможных для VLAN - чистый кадр Ethernet, кадр с одним тегом VLAN – позволяет 2 12 различных VID – и кадр с двумя VLAN теги - разрешая 2 12 *2 12 = 2 24 комбинаций VID.

Однако, MAC-адрес заказчика всегда отображается в этих кадрах,

независимо от количества тегов VLAN, что используются для полезного погрузки.

на рисунка 2.2, пример использование Q-in-Q показывает двух разных клиентов, которые могут использовать один и тот же тег VLAN – тег клиента VLAN (C-VLAN) номер 10 - и оставаться изолированными друг от друга при совместном использовании сетевой инфраструктуры Однако Q-in-Q все еще не обеспечивает полное разделение между доменами клиента и поставщика через следующие возможные проблемы [7]:

Функционал магистральных мостов провайдера (PBB) поставщики сетевого оборудование обычно называют "MAC-in-MAC" какой расширяет концепцию Q-in-Q, позволяя полную инкапсуляцию трафика клиента, включая MAC-адрес клиента (C-MAC ). Стандарт IEEE 802.1ah-2008 [27] ввел концепцию PBB, которая впоследствии была включена в стандарт IEEE Std 802.1Q-2014 [24].

Рис.2.3 Кадр MAC-in-MAC.

На рисунке 2.3 показан кадр MAC-in-MAC, в котором находятся основные адреса назначения и адреса источника (B-DA и B-SA соответственно). На рисунке показано, что в кадре PBB, MAC-адрес клиента (в более светлом сером цвете) не можно узнать за помощью коммутаторов на магистрали поставщика. Это становится понятным при сравнить кадра PBB с одинарными да двойными обозначенными кадрами на рисунка 2.1. Магистрально VLAN (B-VLAN) представляет собой VLAN в магистрали, которая не зависит от других тегов VLAN во фрейме клиента. Тег экземпляра серверной службы (I-TAG) содержит 24-битное поле, которое называется идентификатором экземпляра серверной службы (I-SID), какое используется для идентификации уникального клиента в мостовой сети магистрали поставщика. Это позволяет 2 24 разным клиентам использовать 2 24 разных комбинации тегов VLAN каждому [7].

Поэтому решение MAC-in-MAC решает основные проблемы, возникающие из Q-in-Q, путем:

(224);

клиентских MAC-адрес, изучая только адреса назначение да адрес отправителя;

Архитектура многопротокольной коммутации меток (MPLS) вводит концепцию разделение наборов пакетов на классы эквивалентности пересылка (FEC) и сопоставление каждого набора с определенным набором хопов в сети. Затем FEC обозначаются метками или путями с коммутацией меток (LSP) по сети. Затем метки могут быть легко использованы маршрутизаторами коммутации меток. (LSR) для принятия решений по переадресации, поскольку сетевой уровень анализируется только один раз - на сетевом маршрутизаторы[54].

Пути, которые проходят FEC в сети, обычно назначаются алгоритмами маршрутизации, которые уже работают в сети, например, кратчайший путь сначала. Затем отображение LSP к FEC обычно выполняется протоколом распределения меток (LDP) [4] или протоколом резервирование ресурсов (RSVP) с расширениями для туннелей LSP [6], разрешающее разным LSR согласовывать значение меток да способы пересылка их через сеть.

Кроме всего другого, MPLS разрешает сети с коммутацией пакетов работать почти как сеть с коммутацией каналов. Много сетевых служб базируются на MPLS, таких как услуги виртуальных частных каналов (VPWS) да услуги виртуальной частной локальной сети (VPLS) [5].

2.4.6 Virtual Private Networks

Виртуальные частные сети (VPN) достигают виртуализации таким образом, что сетевой клиент обычно видит только часть всей сети, которой может быть Интернет или любая другая общая сетевая инфраструктура. Только пользователи, находящиеся в одной сети, могут отправлять и получать трафик в сети VPN [34].

Хотя VPN часто считают виртуализацией сети с добавленными механизмами. безопасности, такими как шифрование и аутентификация, нет точного определения того, что VPN должна включать. В некоторых случаях шифрование да аутентификация вообще нет используются (например, провайдеру сети доверяют MPLS VPLS VPN). Льюис [34] да Джаха [30] попробовали классифицировать некоторые с существующих типов VPN разными способами. Некоторые с этих критериев обобщены в следующих параграфах.

В надежных сетях VPN клиент верит, что сеть поставщика есть безопасной и недоступной для общественности. Не требуется аутентификация или шифрование. Примерами надежных VPN являются VPN уровня 2 на базе MPLS, такие как виртуальная служба приватных каналов (VPWS) и служба виртуальной приватной локальной сети (VPLS) [5]. В защищенных VPN клиентские данные должны быть аутентифицированы да зашифрованы через сеть провайдера. Примерами надежных VPN является уровень защищенных сокетов (SSL) на основе приложений (например, OpenVPN) , и безопасность интернет-протоколов (IPSec) [32].

VPN, ориентированы на соединение, используют виртуальные схемы или тоннели для передачи данных. Например, VPN уровня 2 MPLS или общая Инкапсуляция маршрутизации (GRE) является ориентированной на соединение [18]. VPN без подключение полагаются на распределение данных клиента на границы провайдера (PE)[30], [34]. Использование тегов VLAN для достижения связи второго уровня между двумя клиентскими сайтами можно считать бессвязным, поскольку в основном для пересылки он полагается на «чистый» Ethernet [23].

Сети VPN, что предоставляются поставщиком, должны быть полностью сконфигурированы и развернуты провайдером сети. Это позволяет поставщику точнее контролировать, как обрабатывается трафик клиента. VPWS, VPLS и VRF - это все VPN-сети, предоставляемые поставщиком услуг [30], [34]. VPN что обеспечены клиентом конфигурируются да разворачиваются полностью сетью клиента, а поставщик может даже не знать о существовании этих VPN. GRE и SSL, основаны на приложениях VPN, что обеспечены клиентами [30], [34].

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

FlowVisor [60] – один из первых подходов к виртуализации сетей SDN, который был реализован на основе OpenFlow. Он складывается с прозрачного прокси- сервера, какой действует между контролером OpenFlow и коммутаторами, разрешая нескольким контролером совместно использовать одну и ту же сетевую инфраструктуру.

Чтобы изолировать топологию, FlowVisor может ограничить видящие порты. контроллеры пользователя в реальной физической топологии, чтобы скрыть ограниченные участки сети от пользователей[60]. На рисунке 2.4 показан пример, когда только Пользователь 1 видит коммутаторы SW1 и SW2 с всей сети, а Пользователь 2 видит только часть портов от коммутаторов SW3 и SW4.

Изоляция потокового пространства реализуется путем переписывания правил потока, отправленных от контроллера пользователя на коммутатор, ограничивая поток, на какой они воздействуют. Например, если контроллер пытается создать правило, что ограничивает весь трафик, и FlowVisor знает, что этот контроллер имеет доступ только для установка правил для TCP-порта 80, тогда OpenFlow правило перезаписывается в FlowVisor перед отправкой коммутаторам и влияет только на TCP-порт 80 трафика [60].

Чтобы защитить центральный процессор сетевых устройств, FlowVisor действует ограничивая скорость сообщений, какими обмениваются контроллеры пользователя да коммутаторы. Если с сетевого устройства на контроллер поступает слишком много сообщений о пропущение таблицы OpenFlow PACKET IN, FlowVisor также действует путем установления правила временного падение скорости в соответствующем сетевом устройстве при пересылке первого пробела таблицы PACKET IN на контроллер. Это защищает не только центральный процессор сетевого устройства, но и центральный процессор контроллера, поскольку дает время контроллеру обработать новый запрос о пропуске таблицы PACKET IN, нет мешая дальнейшим повторным сообщением PACKET IN, поступающие с той же сети устройство [60].

FlowVisor также обеспечивает защита таблиц потоков выключателей, чтобы гарантировать, что один контроллер не исчерпывает все записи потока в устройстве. Это достигается путем подсчета правил потока, установленных каждым контроллером пользователя, и ограничение количества разрешенных правил потока в заранее определенного значение [60]. Чтобы ограничить пропускную способность сети, OpenFlow нет поддерживает прямой способ управление пропускной способностью или QoS. Поэтому он может использовать для этого разные метки VLAN, сконфигурированы с разными битами PCP.

SW1 пересылает этот запрос FlowVisor внутри сообщения OpenFlow PACKET IN. на шаги 1 FlowVisor анализирует сообщение PACKET IN да передает этот запрос ARP контроллеру A (шаг 2), поскольку MAC-адрес хоста A1 принадлежит пространства потока фрагмента A (это настроено администратором сети в базе данных (FlowVisor). Контроллер, запускающий простую программу MAC Learning, посылает FlowVisor поток PACKET OUT с запросом ARP (Шаг 3). При необходимости FlowVisor переписывает сообщение PACKET OUT перед тем, как отправить его назад в сеть (шаг 4), гарантируя, что ARP-запрос будет заполнено только для членов среза A. SW1 получил PACKET OUT, пересылает запрос ARP на SW2, какой, в свою очередь, повторяет те сами шаги 1-4, чтобы переслать запрос ARP на хост A (шаг 5). A2 получает запрос ARP, отвечает на него, и начинается обратный процесс достижение A1. Когда контроллер A получает сообщение ответы "PACKET IN ARP" от A2, контроллер имеет достаточно информации, чтобы приказать коммутаторам начать переадресацию движения между A1 и A2 независимо (шаг 6). На шаге 7 контроллер A отправляет сообщение FLOW MOD FlowVisor. FlowVisor проверяет, не нарушают ли эти сообщения ни одного пространства потока, не принадлежащего контроллеру A, а затем программирующего SW1 и SW2 по новым правилам потока. Кроме того, контроллер A заканчивает отправка ответа PACKET OUT ARP назад на SW1, чтобы убедиться, что завершается фаза раздельного адреса. Программирование аппаратной части SW1 и SW2 выполнено, и хосты A1 и A2 могут обмениваться данными через плоскость данных без дальнейшего взаимодействия с плоскостью управления. Этапы 8-10 показывают, как FlowVisor обрабатывает случай, когда и хост, и контроллер пользователя пытаются

«вторгнуться» в часть пространства потока, какая нет принадлежит их фрагмента. FlowVisor блокирует попытки контроллера B установить потоки в срезы контроллера A.

Рис.2.5 Обработка потока FlowVisor.

VeRTIGO [15] расширяет FlowVisor концепцией абстрактных узлов или абстрактных сетевых устройств, которые состоят с двух основных блоков: виртуальных ссылок и виртуальных портов. Виртуальные ссылки объединяют несколько физических узлов и ссылок, абстрагирующих их к контролеру аренды как единственная ссылка между любыми двумя портами. Один или несколько виртуальных портов отображаются физический порт соответственно к количества виртуальных ссылок, которые должны использовать тот самый физический порт. на рисунка

VeRTIGO построен поверх FlowVisor, поэтому он автоматически предоставляет все функции разделения сети, предоставляемые FlowVisor. Здесь кратко описаны новые модули, разработаны специально для VeRTIGO.

Модуль классификатора определяет, которые сообщение, что поступают с сети, обрабатываемые контроллерами арендатора OpenFlow Некоторые сообщения обрабатываются непосредственно внутренним контроллером VeRTIGO, чтобы он мог скрыть детали сети от контролеров пользователей, контролирующих только часть. Например, на рисунке 2.6 сообщения OpenFlow, генерируемые путем движения трафика в SW-A с виртуального порта X, обрабатываются контролером пользователя, в то время как любые сообщения OpenFlow, связанные с трафиком между SW-B и SW-D - внутренняя часть виртуальной сети, скрытые VeRTIGO - обрабатываются да маршрутизируются внутренним контроллером[15].

Когда один физический порт используется многими разными виртуальными ссылками, то портовщик портов обрабатывает отображение виртуальных к физическим портам. Это также происходит для абстрактных портов узлов, которые должны иметь физические номера портов, переназначены к номеров виртуальных портов [15].

Планировщик виртуальной топологии (VT) отвечает за ассоциирование экземпляров виртуальной сети с реальными сетевыми ресурсами. Например, когда существует несколько путей для соединения точек A и B, этот модуль отвечает за Поиск лучшего пути внутри абстрактного узла. Лучший путь зависит от требований программы и может быть выбран на основе доступной пропускной способности или общей задержки. Планировщик VT контролирует сетевую статистику для определение текущей пропускной способности да задержки, чтобы определить, какой самый лучший путь для текущей программы.

2.5.3 OpenVirteX

OpenVirteX (OVX) – обеспечивает структуру, какая разрешает контролером пользователей создавать экземпляры, снимки, мигрировать или удалять виртуальные сети, являющиеся аналогом гипервизоров, обрабатывающих виртуальные машины (ВМ) в средах облачных вычислений. Подобно к FlowVisor, OVX выступает как прокси-сервер между сетевой операционной системой (-S) да сетью, что поддерживает OpenFlow. Основными усовершенствованиями, что он обеспечивает есть:

Образец виртуализированной сети больших коммутаторов показан на рисунке. 2.6., также может быть реализован с помощью OVX, с разницей, что OVX может обеспечить почти полное пространство заголовков MAC и IPv4 каждому из своих арендаторов. Это потенциально позволяет арендаторам использовать адреса. которые перекрываются. Это достигается с помощью методов перезаписи заголовков на пределах сети, переписывая MAC или IP-адреса в заголовки пакетов с дополнительной информацией, включая глобально-уникальные идентификаторы пользователя. Если контроллер пользователя передает правила потока уровня 2 на сетевые устройства, то OVX удается к перезаписи заголовка MAC. Если установленные правила потока уровня 3, OVX использует перезапись IP [57].

Аль-Шабиби и другие. [57] заявляют, что виртуализация ссылок также может быть реализована с помощью меток MPLS вместо переписки заголовка, хочет это нет делается в текущей версии OVX.

OVX работает, сохраняя две отдельные логические представление сети, как показано на рисунке 11 [45]. Одним из них есть физическая сеть, иллюстрированная коммутаторами внутри облака и их виртуальные аналоги, хранящиеся в базе данных OVX – SW1-SW5 в сером поле. Виртуальные сети представлены синими полями в верхний части архитектуры. Как физическое, да и виртуальное представления сети хранятся на глобальной карте, представленной зеленым полем на Рис. 2.7, которое в настоящее время использует MongoDB как серверную базу данных[46].

Чтобы обеспечить представление разных виртуальных топологий, OVX перехватывает сообщения LLDP, поступающие от контроллеров пользователя, и создает ответы LLDP, предназначенные для представления к основной топологии физической сети разными способами. Эта манипуляция с обнаружением топологии изображена на рисунка 2.8, где виртуальный коммутатор X сопоставляется с коммутатором A, виртуальный коммутатор Y сопоставляется с коммутатором B, а коммутатор C скрыт от контроллера пользователя. OVX получает PACKET OUT от контроллера пользователя, требуя залить кадры LLDP, чтобы обнаружить основную топологию. Вместо того чтобы отправить кадр LLDP через порты 1 и 2 SW-A, OVX создает поддельный кадр LLDP как ответ, чтобы предоставить контроллеру пользователя иллюзию, что есть только два коммутатора, X и Y, подключены между собой через порты X1 и Y1 соответственно.

Дополнительной функцией, какую обеспечивает OVX, есть устойчивость благодаря использованию резервных маршрутов в сети. При построении абстрактных узлов с несколькими путями между хостами OVX может планировать прямые да резервные маршруты. Если ссылка в пределах прямого маршрута падает, OVX обнаруживает это и автоматически устанавливает правила резервного маршрута в коммутаторах[57].

На рисунке 2.9 показано, как OVX работает для обеспечения виртуализации. сети. С OVX два коммутатора SW1 и SW2 представлены в виде единого большого коммутатора (BIGSW) для пользователей контроллеров. На шаге 1 OVX обращается к своей базе данных (предварительно настроенной администратором), чтобы определить, какие хосты принадлежат к каким виртуальным сетям. Затем OVX пересылает сообщение PACKET IN контроллеру аренды A на основе этой базы данных. на шаги 2 OVX использует буферы для локального хранение сообщений PACKET IN, таким образом избегая отправка ненужных данных о полезное нагрузка контролером пользователя. Идентификатор буфер используется для идентификации буферов, чтобы те же данные могли быть возвращены в сеть, как показано на шаги 3. на шаги 4, на отличие от FlowVisor, сообщение PACKET OUT немедленно доставляется в SW2, а не из SW1 на SW2 и только потом доставляется на хост A2. Затем OVX заполняет запрос ARP всем хостам, относящимся к виртуальной сети A. После получения второго PACKET IN, соответствующего сообщению ARP-ответа от A2 до A1, OVX передает его контроллеру A. В этот момент (шаг 7) контроллер A отправляет два сообщение FLOW MOD для настройка большого коммутатора для соединение хостов A1 и A2 . OVX переводит два сообщения FLOW MOD в четыре сообщения FLOW MOD для программирования SW1 и SW2. Этот шаг есть важным для работы реализации большого коммутатора, поскольку контроллер А видит и программирует сеть да, будто это единственный коммутатор. Также на этом шаги важно указать, что правила FLOW MOD нет только пересылают трафик, но также переписывают IP-адреса источники да назначение на пределах большой коммутационной сети.

Рисунок 2.9 Обработка потока пакетов OVX.

FlowN [16] предлагает базу данных да облегченную виртуализацию на основе контейнера как расширение к контроллера -X [39]. База данных поддерживает отображение физической да виртуальной сети, тогда как каждый виртуальный контейнер запускает одну программу-арендатора с независимым адресным пространством. Чтобы обеспечить изоляцию трафика, FlowN добавляет заголовки VLAN для трафика при входе в сеть и удаляет или заголовки, когда трафик оставляет сеть, позволяя арендаторам повторно использовать то же пространство IP-адресов несколько раз.

Вместо этого того, чтобы работать как прокси-контроллер, FlowN - это модифицированная версия контроллера –X. Таким образом, ему не нужно отображать сообщение протокола OpenFlow между физическим сетью да виртуальным представлением сети. Это существенно уменьшает накладные расходы на память нескольких контроллеров, поскольку виртуализация реализуется в самом -X, в то время как разные арендаторы - это программы, что работают на одному контроллеры, но в контейнерах пространства имен. Авторы FlowN сравнивают его с FlowVisor и показывают, что FlowN имеет отличную производительность при наличии большого количества виртуальных сетей (100 или больше). Улучшенные результаты объясняются использованием реляционной базы данных для хранение отображение виртуальной да физической топологии.

AutoSlice [9] представляет систему, какая автоматизирует Задача распределения плоскости пересылка данных сети между несколькими арендаторами в плоскости управление. Его главная цель – минимизировать ручную реконфигурацию сети, чтобы поставщики субстратов могли перепродавать срезы своих сетей арендаторам. Реализация состоит из распределенной архитектуры гипервизора, состоящей из одного модуля управление (MM) да нескольких прокси-серверов контроллера (CPX).ММ отображает топологии виртуальной SDN (vSDN) в физическое сеть да назначает каждому CPX домен сетевых ресурсов. CPX отвечает за перезапись управляющих сообщений из контрольной сети на плоскость пересылки данных, используя теги трафика, где это необходимо для обеспечение изоляции. AutoSlice также пытается использовать такие свойства, как потоки мыши. да слона», чтобы оптимизировать кэширование записей потока.

AutoVFlow [66] работает аналогично AutoSlice, но предлагает предоставить больше контроля администратором каждой vSDN, переводя ответственность за обработку виртуализации пространства потока на администратора каждой сети. AutoVFlow также утверждает, что применяет технику перезаписи MAC на границах сети, чтобы гарантировать, что каждый пространство заголовка доступный каждому с арендаторов.

Выводы

Этот раздел коротко представил и объяснил VLAN, MPLS да VXLAN да VPN, и было показано, что некоторые гипервизоры сети SDN все еще могут использовать некоторые из этих традиционных технологий для реализации виртуализации сети. Также были представлены методы виртуализации сетевых функций в программно-управляемых сетях. В следующем разделе будут предложены эксперименты для оценки некоторых с этих гипервизоров сети

РАЗДЕЛ 3

ОПИСАНИЕ ТА ПОСТАНОВКА ЗАДАЧИ

Эксперименты проводятся на виртуальном тестовом стенде на основе. Mininet [36] для оценки функциональных аспектов виртуализации сети да физическом тестовом стенде с одним коммутатором для анализа основных аспектов производительности виртуализации сети.

Во всех экспериментах контроллером OpenFlow используется Floodlight [19], поскольку это простой в настройке контроллер и содержит все функции, необходимые для эксперимента с тестируемыми сетями, а именно выявление топологии да «обучение» MAC.

Исходный код доступны для FlowVisor [1], VeRTIGO [12] и OpenVirteX [2]. Исходный код AutoSlice, AutoVFlow и FlowN не найден в открытом доступе, следовательно в этой работе освещено только первые три подхода.

Mininet - это сетевой эмулятор, и он работает, управляя экземпляром сетей виртуальных хостов, коммутаторов да ссылок. Виртуальные хосты создаются как отдельные пространства имен в Linux, а виртуальные коммутаторы обычно работают на Open vSwitches (OVS). Mininet разрешает пользователю использовать внешний контроллер OpenFlow для управления коммутаторами OVS с поддержкой OpenFlow.

Топология на основе Mininet, изображенная на рисунке 3.1, используется для всех функциональных экспериментов К каждому коммутатору подключено 3 хоста, хотя хосты, подключенные к коммутаторам SW2-SW4, не отображаются для ясности. Кроме того, DPID и MAC-адреса были сокращены с помощью двойных двоеточий для выражения последовательности нулей. Например, DPID SW3 (00: 00: 00: 00: 00: 00: 00: 03) представлен 00 :: 03, а MAC-адрес хоста C1 (02: 00: 00: 00: 03:01) отображается как 02::03:01. Схема адресации виртуальных устройств, что используются в этой сети, была разработана для облегчения настройки, понимание да запуска экспериментов:

Рисунок 3.1. также показывает, что гипервизор сети – OVX, VeRTIGO или FlowVisor подключен к Open vSwitches через интерфейс обратной связи. Тот самый интерфейс обратного связи используется для подключение сетевого гипервизора к Floodlight.

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

Физическая топология, какая используется для тестирование времени настройка потока да пропускной способности между хостами, изображена на рисунка 3.2. Компьютеры подключены к коммутатора HP OpenFlow, какой управляется контроллером Floodlight, а также любым тестируемым гипервизором сети – OVX, FlowVisor или VeRTIGO. Тестовые компьютеры от A до D имеют два сетевые интерфейсы, каждый с которых подключен к коммутатора HP OpenFlow, что используется в тестах производительность, а другой интерфейс подключен к стандартному коммутатору уровня 2 для облегчения управления лабораторным оборудованием. VLAN 10 был настроенный для управление контроллером Floodlight. VLAN 40 был сконфигурирован для управления сетевым. гипервизором плюс Floodlight для измерение влияния на производительность добавление этого уровня виртуализации сети к плоскости управление. Поэтому компьютеры A и B используются тогда, когда нужно протестовать только производительность Floodlight, а компьютеры C и D используются, когда тестируется сетевой гипервизор и производительность Floodlight.

Для экспериментов, проведенных в этой локальной физической топологии, аппаратный коммутатор OpenFlow подключен к сетевому гипервизору, который в свою очередь, подключается к одному экземпляру контролера арендатора Floodlight на порта TCP 10 000.

Основной целью этой физической тестовой топологии есть тестирование производительности, не ограничиваясь потреблением ресурсов ЦБ Mininet, которых может не хватать для более высокой пропускной способности. Это более простая топология, поскольку она предназначена только для измерения пропускной способности трафика, что пересекает аппаратный коммутатор и времени установки новых правил потока в коммутаторы.

Для этого эксперимента топология Mininet используется для проверки изоляции сети посреди арендаторов. Во-первых, проверяется сетевой гипервизор. FlowVisor, OVX или VeRTIGO – должен быть настроен на разделение этой сети на три отдельных виртуальных подсети, каждая из которых контролируется разным экземпляром Floodlight.

Ожидается, что FlowVisor разделит выходную сеть, как показано на Рисунку 3.3. Для OVX и VeRTIGO изоляция сети должна выглядеть так, как показано на рисунка 3.2.2., с большим коммутатором, что представляет пять коммутаторов. Изоляция сети можно проверить, заметив, что хосты, что принадлежат к разным фрагментам, не могут общаться. Например, хост A1 не должен иметь возможность отправлять любые пакеты на любой из хостов C1- C5. Кроме того, сетевой гипервизор должен обеспечить, чтобы контроллеры арендаторов имели право контролировать только свои сетевые части.

И OVX, и Vertigo утверждают, что могут обеспечить автономное перенаправление внутри абстрактных узлов. Предположим, что сетевой гипервизор маршрутизирует трафик между хостами А1 и А2 через коммутаторы SW1 и SW2, как изображен рисунок 3.3. Если связь между SW1 и SW2 не поддерживается, сетевой гипервизор должен поддерживать функционирование сети путем перенаправление трафика через резервный маршрут, возможно, через коммутаторы SW1-SW3-SW4-SW2.

Время прерывания движения может быть измерено с помощью генератора движения, такого как iperf. Генератор трафика должен быть настроенный на передачу пакетов UDP, чтобы убедиться, что уровень программы не будет повторно отправляться потеряны пакеты. Отправляя пакеты с известным размером и с фиксированной скоростью, можно измерить время прерывания, подсчитав количество потерянных пакетов. Уравнение 3.1 показывает, как рассчитать пропускную способность на основе объема полученных данных (data rx ) и времени, что прошел.

data rx

bandwidth = (3.1)

time

Учитывая, что data rx = размер пакета N packets и известен размер пакета, пропускную способность да время, уравнение 3.1 можно переписать как уравнение 3.2.

N пакетов =

time bandwidth packet size

(3.2)

Например, используя размер пакета 125 байт (1000 бит), пропускную способность 1 Мбит/с и передача данных в течение 10 секунд должны привести к N пакетов =10000 пакетов. Итак, каждый потерянный пакет отвечает 10 ⁄ 1000 = 1 миллисекунди. Подсчитать сколько времени сеть остается недоступной, просто подсчитав количество потерянных пакетов.

Рис.3.5 Функция быстрого перенаправление OVX.

Арендаторы сети могут захотеть запускать традиционные сетевые механизмы в собственной виртуальной сети, такие как механизм обнаружения LLDP или протокол маршрутизации начала открытого кратчайшего пути (OSPF). Как LLDP, так и OSPF полагаются на использование многоадресных кадров для связи с соседними сетевыми устройствами. Виртуализация сети обычно хорошо проверена для стандартного одноадресного трафика IP, но некоторые многоадресные кадры и другие специальные типы кадров вряд ли когда-нибудь проверяются на прозрачную переадресацию трафика в экспериментальных сетевых гипервизорах. Поэтому важно проверить, что виртуальные сети могут переадресовывать несколько разных типов трафика.

Рис.3.6 Эталонное прозрачное пересылка трафика.

Один с способов проверки прозрачности переадресации движения состоит в использовании инструмента test_packets.py [51]. Пользователь должен вводить кадры в один сетевой порт, а затем ожидать, что кадры будут получены на любому другому хосты назначение в сети. Ожидается, что сеть переадресовывает кадры к портов, что принадлежат к правильного фрагмента или виртуальной сети, не сбрасывая и не изменяя их. Различные гипервизоры сети не должны дополнительно ограничивать тип трафика, который обычно может пересылаться только контролером Floodlight.

FlowVisor да Vertigo нет меняют трафик в сети. Они просто нарезают доступный пространство заголовка, чтобы разные арендаторы обрабатывали разные контроллеры арендаторов. Однако OVX работает, переписывая заголовки IP, чтобы сделать полный пространство заголовка IP доступным для каждого арендатора [57].

Целью этого эксперимента является наблюдение за тем, как гипервизор сети меняет заголовки IP да MAC под время их поступление в сеть. Трафик, что протекает через внутренние звенья сети, фиксируется в топологии Mininet, затем захваченные кадры анализируются, имея в виду соответствие стандартам адресации IP и MAC и зарезервированным диапазонам адресов, как указано:

Соответствие адресам IPv4 означает, что IP-адреса, сформированные сетевым гипервизором, есть действительными да находятся в пределах диапазонов, назначенных частным сетям. Например, 1.0.0.1 - это общедоступна IP-адрес, присвоена организации в Азии [63], а 224.0.0.5 принадлежит к диапазона многоадресной передачи IP, зарезервированного IANA, и специально используется для обмена сообщениями OSPF [53]. Ни один из этих адресов не должна использоваться сетевыми гипервизорами во время переписки одноадресных заголовков IP, поскольку они могут вызвать много проблем, если когда-нибудь возникнет потребность в взаимодействия с другими IP-сетями.

Время настройка потока уже признано одним с недостатков OpenFlow (и SDN), поскольку централизованный контроллер работает на пересылку решений [62]. Кроме того, важно подтвердить, что методы виртуализации, что применяются сетевыми гипервизорами, не влияющими существенно на пропускную способность сети. Эксперименты, описаны в этом разделе, имеют намерение измерять:

Задача этого эксперимента состоит в сравнить латентности установленных правил потока Floodlight с задержкой с добавленным гипервизором сети между Floodlight и коммутатором OpenFlow. Этот эксперимент проводится на физической топологии, описанной в разделе 3.1.2. Записи ARP на всех хостах были вручную добавлены в их таблицы, чтобы избежать дополнительной дисперсии, введенной фазой разрешение адреса.

Процедура заключается в измерении времени обратной связи (RTT) пинга между двумя хостами. Как показано на рисунке 3.7, когда коммутатор не имеет правил трафика между хостами А и В, запрос эхо-ответы да сообщение ответы протокола управление Интернетом (ICMP) должен обрабатываться контроллером.

Сравнивая RTT первого пинга с следующими RTT, можно определить, сколько времени гипервизор сети да контроллер арендатора добавляют к всего уравнение RTT 3.3.