РЕФЕРАТ

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

использовано 34 источник.

Актуальность: на сегодняшний день активно развиваются сетевые

технологии использования разумных систем управления. А именно за

последние 5 лет все больше компаний предлагают пакетные решения для

организации транспорта в телекоммуникационной сети. Это становится

возможным за счет использование программно управляемых сетей(SDN) да

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

неизученными современными реализациями гипервизора сети. В этой

дипломный работе представлено да оценены некоторые функции,

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

пространства заголовков, изоляция и прозрачные возможности пересылки

трафика для арендаторов да другое. Результаты указывают на то, что

гипервизоры сети привносят гибкость SDN в процесс виртуализации

облегчающей сети сетевым администратором распределение сети между

арендаторами. Однако такая повышенная гибкость может повлечь за собой

снижение производительности, а также создает дополнительные риски

взаимодействия через отсутствие стандартизации методов виртуализации.

Цель работы: разработать рекомендации по функционированию

гипервизора NFV за счет использование ряда средств реализации контроллера

SDN что позволит обнаружить преимущества да недостатки существующих

решений да сформировать пакетное решение для конкретной задачи

построения сети.

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

1. Провести обзор существующих методов виртуализации в традиционных

сетях.

2. Провести анализ существующих методов виртуализации в программно-

конфигурированных сетях.

3. Для методов Vertigo, OVX, FlowVisor ,используя программное

обеспечение MiniNet, создать имитационную модель с целью проведения

экспериментального исследования для их оценки.

4. Развертывание физической топологии для тестирования времени

настройки потока да пропускной способности между хостами.

5. Анализ полученных результатов. Разработка рекомендации относительно

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

реализации контроллера SDN что позволит выявить преимущества и

недостатки существующих решений и сформировать пакетное решение

для конкретной задачи постройки сети.

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

программно-конфигурированных сетях.

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

использование ряда средств реализации контроллера SDN.

Методы исследования: основными методами исследования является

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

Научная новизна: Предлагали усовершенствованный способ

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

методов виртуализации да позволяет использовать преимущества каждого с

них.

Практическая новизна: разработано ряд коротких программ (скриптов)

которые позволяют проводить тестирование имитационных моделей ПКМ с

виртуализацией.

3 
 
СОДЕРЖАНИЕ 
Введение  ..................................................................................................................... 13 
РАЗДЕЛ 1  ................................................................................................................... 14 
SDN ОСНОВНЫЕ ПОЛОЖЕНИЕ, КОНЦЕПЦИЯ  ............................................... 14 
1.1 Введение и определение понятий  .................................................................. 14 
1.2 Программно-конфигурированные сети. Основные положения.  ................. 16 
1.3 Ограничение традиционных сетей  ................................................................. 21 
1.4 Преимущества NFV  ......................................................................................... 23 
1.5 Структура (Framework) NFV  ........................................................................... 27 
Выводы  .................................................................................................................... 29 
РАЗДЕЛ 2  ................................................................................................................... 30 
МЕТОДЫ ВИРТУАЛИЗАЦИИ  ............................................................................... 30 
2.4 Традиционные методы виртуализации  .......................................................... 30 
2.4.1 VLAN ........................................................................................................... 30 
2.4.2 Q-in-Q  .......................................................................................................... 31 
2.4.3 MAC-in-MAC  .............................................................................................. 33 
2.4.4 Multiprotocol Label Switching  .................................................................... 34 
2.4.6 Virtual Private Networks  ............................................................................. 35 
2.5 Виртуализация в сетях SDN  ............................................................................ 36 
2.5.1 FlowVisor  .................................................................................................... 36 
2.5.2 VeRTIGO  ..................................................................................................... 41 
2.5.3 OpenVirteX  .................................................................................................. 43 
2.5.4. FlowN .......................................................................................................... 48 
2.5.5. AutoSlice  ..................................................................................................... 48 
2.5.6. AutoVFlow  ................................................................................................. 49 
Выводы  .................................................................................................................... 49 
Раздел 3  ....................................................................................................................... 50 
Описание и постановка задачи  ................................................................................ 50 
3.1 Топология .......................................................................................................... 50 


 
1.1 Топология Mininet  ..................................................................................... 50 
1.2 Физическая топология  ............................................................................... 52 
2 Изоляция сети  ................................................................................................... 53 
3 Автономное перенаправление  ........................................................................ 55 
4 Прозрачное пересылка трафика  ...................................................................... 57 
5 Соответствие стандартам адресации  ............................................................. 58 
6 Эксперименты с производительностью  ......................................................... 59 
6.1 Время настройка потока  ............................................................................ 59 
6.2 Пропускно способность  ............................................................................ 60 
Выводы  .................................................................................................................... 61 
Раздел 4  ....................................................................................................................... 62 
Результаты да анализ полученных данных  ............................................................ 62 
1 Результаты функционального тестирование  ................................................. 62 
1.1 Изоляция сети и топологии  ....................................................................... 62 
1.2 Прозрачное пересылка трафика  ............................................................... 66 
1.3 Соответствие стандартом адресации  ....................................................... 68 
2 Результаты проверки производительности  ................................................... 70 
2.1 Время настройка потока  ............................................................................ 71 
2.2 Пропускно способность  ............................................................................ 73 
3 Результаты результатов и их анализ  .............................................................. 77 
ОБЩИЕ ВЫВОДЫ ПО РАБОТЕ  ............................................................................ 80 
РАЗДЕЛ 5 РАЗРАБОТКА СТАРТАП ПРОЕКТА  ................................................. 83 
1. Описание идеи продукта  ................................................................................ 83 
2. Технологический аудит идеи проекта  .......................................................... 87 
3. Анализ рыночных возможностей запуска стартап-проекта  ....................... 88 
4. Разработка рыночной стратегии проекта  ..................................................... 95 
5. Разработка маркетинговой программы стартап проекта  ............................ 98 
Выводы к раздела 5  .............................................................................................. 101 
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ  ....................................... 102 

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

SDN

NFV

ПКМ

software-defined networking

Network Functions Virtualization

программно-управляемая сеть

OVX

OpenVirteX

VLAN

Virtual Local Area Network

VPN

Virtual Private Network

IANA

Internet Assigned Numbers Authority

OVS

Open vSwitch

Floodlight

FlowVisor

ВВЕДЕНИЕ

В меру рост тенденции к программно-определенных сетей в последние

годы было разработано несколько контролеров виртуализации сети. Эти

контролеры, также так называемые сетевыми гипервизорами, пытаются

управлять физическими сетями на основе SDN, чтобы несколько арендаторов

могли безопасно, совместно использовать одно и то же оборудование в

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

области остаются неисследованными в текущих реализациях сетевых

гипервизоров. В этой диссертации представлены и оценены некоторые

функции, предлагаемые сетевыми гипервизорами, такие как доступность

полного пространства заголовков, изоляция и прозрачная пересылка трафика

для клиентов. Время настройки потока и пропускная способность также

измеряются и сравниваются между разными сетевыми гипервизорами.

Оцениваются три разных сетевых гипервизора: FlowVisor, VeRTIGO и

OpenVirteX. Или инструменты виртуализации оцениваются за помощью

экспериментов, что проводятся на трех разных испытательных стендах:

эмулированный сценарий Mininet, физический испытательный стенд с одним

коммутатором, а также удаленный испытательный стенд GENI. Результаты

показывают, что сетевые гипервизоры привносят гибкость SDN в

виртуализацию. сети, упрощая для сетевых администраторов точное

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

Однако такая повышенная гибкость может привести к снижению

производительности, а также к дополнительным. рисков взаимодействия через

отсутствие стандартизации методов виртуализации.

РАЗДЕЛ 1

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

1.1 Введение и определение понятий.

Традиционные телекоммуникационные сети проектировались с расчета на

использование специализированных аппаратных устройств (маршрутизаторов,

Ethernet- коммутаторов, оборудования EPC (Enhanced Packet Core), межсетевых

экранов, балансировщиков нагрузка тому подобное. Или устройства

создавались на базе специфических аппаратных и программных платформ

отдельных вендоров. Развертывание этих «монолитных» сетевых элементов

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

а, следовательно к замедление вывод на рынок новых продуктов и услуг.

Обслуживание и управление такой сетью было достаточно неэффективно и

дорого. Все это приводило к того, что рост инвестиций в развитие сети для

удовольствие запросов абонентов превышал рост доходов от предоставления

услуг в ней.

Тем нет меньше, в данный время сети телекоммуникационных операторов

состоят в основном с «монолитных» сетевых элементов, где функции

управление, администрирование и пересылка данных (трафик пользовательских

данных) выполняются на основе физических, "железных" устройств. Очень

часто сеть строится из сетевых элементов от одного производителя (вендора),

поскольку в в этом случае действительно легче обеспечить совместимость.

Политика "эксклюзивного" поставщика" является общепринятой в вендорской

среде. Развертывание новых услуг, модификации ("апгрейды") оборудования

или услуг производится по очереди на каждому сетевом элементе и требует

тесной координации внутренних и внешних ресурсов оператора Такая

монолитная организация делает операторскую сеть негибкой, усложняет

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

от специфических ( "проприетарных") решений

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

Поэтому, в настоящее время многие операторы

выбрали путь цифровой трансформации на базе технологий

SDN / NFV. Задачи такой трансформации - такие:

1. Повышение операционной эффективности:

 Достижение эластичности и масштабируемости в масштабе всей сети оператора.

 Автоматизация операций (Operation), администрирование

(Management) и обслуживание (Maintenance), ОАМ.

 Динамическое управление потоками трафика,

с соответствующим перераспределением сетевых ресурсов в

"реальном времени".

 Оперативное создание услуг с цепочек сервисов.

2. Трансформация бизнес-модели:

 Снижение времени вывод услуг на рынок .

 Устранение локальных решений, достижение возможности быстрого

внедрение инноваций в масштабе всей сети.

 Быстрое и эффективное создание и предоставление услуг (Agile).

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

 Деление плоскости управление и передачи данных.

 Виртуализация сетевых функций.

 Программируемое управление сетевыми ресурсами,

вычислительными ресурсами, и ресурсами хранения данных, а также

оркестрации услуг.

 Стандартизация протоколов и автоматизация конфигурации сетевых элементов.

 Единый механизм администрирование и выделение ресурсов сети за

запросом для разных услуг и функций.

Комплексное использование этих новых свойств позволяют реализовать

динамическое подстройка сети под потребности приложений, что повышает

операционную гибкость и упрощает развертывание услуг.

1.2 Программно-конфигурированные сети. Основные положения.

Традиционные сети – это распределенные системы, состоящие из сетевых.

устройств, отвечающих за обработку как плоскости управления, так и плоскости

пересылка данных сети. Функция плоскости управление решает, как след

обрабатывать трафик сети; она отвечает за обнаружение соседних устройств и

сетей да решение вопросы, куда след перенаправлять трафик. Протоколы

обнаружение топологии, дерева охвата и маршрутизации являются примерами

функций плоскости управление [33]. Плоскость пересылка данных использует

только таблицы пересылка, которые раньше были рассчитаны плоскостью

управление, и использует эту информацию для быстрой пересылки трафика

[33].

Программно-конфигурированная сеть (SDN, Software-defined Networking)

- сеть передачи данных, в какой уровень управление сетью отделенный от

устройств передачи данных и реализуется программно [1].

SDN – это новая концепция, какая имеет на цели снять функции

плоскости управление с сетевых устройств и разместить их в

специализированном, логично централизованном контроллере сети. Это дает

преимущество в упрощении конфигурации. сети и соблюдение правил Это

также уменьшает необходимые системные ресурсы, поскольку они больше не

нужны для запуска функций плоскости управления [33].

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

 отделить в маршрутизаторы управление сетевым оборудованием от управление

передачей данных. Управление вынести на отдельный компьютер, который

будет находиться под контролем администратора сети;

 перейти от управление отдельными экземпляром сетевого оборудование к

управление сетью в целом;

 создать интеллектуальный программно-управляемый интерфейс между сетевым

приложением и транспортным средой (Рис. 1.1) [2].

Таким образом, реализация концепции 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.

1.3 Ограничение традиционных сетей

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

«устройство - функция». В большинства случаев для того, чтобы ввести

очередную функцию, нужно установить другой устройство. Однако, такие

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

физических устройств сталкиваются с рядом ограничений.

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

Проприетарный вендорских дизайн оборудование состоит в поэтому, что

каждый сетевой устройство имеет фиксированную комбинацию оборудование

да программного обеспечение с небольшими вариациями. Это очень

ограничивает операторов в выборе функциональных комбинаций и

возможностей оборудования, которые могут быть развернуты на сети.

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

Возможности масштабирования физических сетевых устройств

ограничены как в части оборудование, да и программного обеспечение.

Оборудование требует питание и места для размещение, что часто ограниченное

в зонах плотной застройки.

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

Требования рынке растут, но рост количества функций и единиц

оборудование не всегда способны успевать по этим требованиям. Часто ввод

новых функций требует апгрейда существующего и ввода нового оборудования.

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

инфраструктурой сети.

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

Системы мониторинга используют стандартные протоколы, такие как

SNMP, NetFlow, Syslog и т.п. для сбора информации о состояние устройств.

Однако для мониторинга вендороспецифических (проприетарных) параметров,

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

сетевого домена, построенного на оборудовании определенного поставщика,

нужна проприетарная система мониторинга

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

Вендороспецифическое оборудование повышает операционные расходы,

поскольку требует наличии в штате оператора соответствующих специалистов.

Или, как вариант, требует использование «Managed services» (есть

«профессиональных услуг» от поставщика). Это приводит к

«вендорозависимости», т.е. решений конкретного поставщика.

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

Требования к рост емкости сети (как на короткие, да и на длительные

сроки) сложно спрогнозировать. Это ведет к непроизводительных капитальных

затрат. Напротив, когда ресурсы сети оказываются исчерпанными, проходит

много времени, прежде чем емкость сети удается расширить.

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

Часто бывает да, что для ускорение вывода оборудования на рынок

поставщики оснащают его новыми функциями к полного завершение процесса

их стандартизации Во многих случаях это приводит к несовместимости

разнородного оборудование на сети, необходимость испытаний сетевых

решений в лабораториях операторов и сервис-провайдеров перед тем, как

развертывать или устройства на сети.

Виртуализация - технология какая разрешает запускать несколько

операционных систем на одном физическом сервере Концепция виртуализации

серверов достаточно давно используется в дата-центрах (ЦОД, центрах

обработки данных). При этом, физические серверы заменяются их

виртуальными «копиями», работающими этаж гипервизора. Это позволяет,

кроме другого, достичь более эффективного использование физических

ресурсов дата-центр.

NFV можно определить как метод и технологию, какая дает возможность

заменить физические сетевые устройства с определенными функциями на

программные сущности, выполняют такие же функции на общедоступном

серверном оборудовании. расширяет концепцию виртуализации, кроме

серверов, также и на все сетевые типы. устройств.

Фактически, NFV отделяет программное обеспечение от оборудования и

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

стандартное оборудование COTS (Commercial Off the Шелф) для исполнение на

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

в любой момент.

1.4 Преимущества NFV

на начала были коротко описаны ограничение традиционных методов

развитию сетей связи. Рассмотрим, как виртуализация сетевых функций 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.

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

с неисправностями на сети.

1.5 Структура (Framework) NFV

Термин NFV впервые был введен ведущими операторами связи мира в

SDN OpenFlow World Congress в 2012 году. Они проанализировали ограничения

традиционного метода развития сети, указанные выше, и создали рабочую

группу по разработке спецификаций NFV ISG (Industry Specification Group) под

руководством Европейского института по разработке стандартов для

телекоммуникаций ETSI (European Telecommunications Standards Institute).

Рабочая группа NFV ISG выдвинула три основных критерия, которые

должны быть реализованы в стандартах (рекомендациях) для NFV:

 Разделение (Decoupling): полное разделение оборудование да

программного обеспечение.

 Гибкость (Flexibility): автоматизированное и масштабируемое

развертывание сетевых функций.

Динамические операции (Dynamic operations): контроль за

операционными параметрами сети за помощью точного (гранулярного)

управление и мониторинга состояния сети.

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

 Виртуализированные сетевые функции VNF (Virtualized Network Function)

 Инфраструктура виртуализации NFVI (NFV Infrastructure)

 Подсистема управление да оркестрации MA- (Management and Orchestration)

Кроме NFVI, подсистемы представляют собой программное обеспечение,

а нет оборудование. NFVI включает в себя как физическое оборудование

(вычислений, хранение, сети), да и виртуальное «оборудование»: серверы,

системы хранение, сетевые устройства. Уровень виртуализации (Гипервизор и

гостевые операционные системы) дают возможность развертывать на

физических серверах виртуальные машины VM (Virtual Machines),

выполняющие любые положенные на них функции. Для VM нет имеет

большого значение, на котором именно физическом сервере она развернута и

работает. Строго говоря, в архитектуру NFV также необходимо включить

подсистему поддержки операций и бизнеса (OSS/BSS), которая есть частью

традиционной системы оператора связи. Однако, наличие этой подсистемы в

архитектуре NFV есть временным, поскольку операторы нет могут

одномоментно отказаться от существующих OSS/BSS и сразу перейти на MA-

(такое возможно только для новых операторов). MA- должна иметь полную

видимость (операционное состояние, статистика использования и др.) всех

программных сущностей, развернутых в системе NFV, и управлять ими.

Поэтому именно MA- представляет наиболее подходящий интерфейс для

подсистемы OSS / BSS в части сбора операционных данных В будущем, по мере

трансформации сети, все функции OSS / BSS должны перейти к MA.

Выводы

В этом разделе были введены ключевые понятия, необходимые для

понимания типовой архитектуры да работы SDN, таких как разделение

плоскостей управление да данных, а также то, как контроллеры контролируют

да обнаруживают сетевые устройства.

Также была представлена обобщенная архитектура NFV которая состоит

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

подсистемы управления и оркестрации.

РАЗДЕЛ 2

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

2.4 Традиционные методы виртуализации

2.4.1 VLAN

В данный время технология виртуальной локальной сети (VLAN)

стандартизированная стандартом IEEE 802.1Q-2014 [24]. VLAN обеспечивают

надежную изоляцию трафика да уменьшение трансляции «бродкаст» доменов в

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

Основная функциональность реализована путем введение тегу VLAN (тег

802.1Q) внутрь кадров Ethernet. Например, коммутаторы, поддерживающие

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

VLAN X в портов, принадлежащих только VLAN Y. К полям в кадре уровня 2

Ethernet II, что поддерживает VLAN, входят [24]:

• Назначение MAC (6 байтов)

• Источник MAC (6 байт)

• Тег VLAN (4 байты)

• Этертип (2 байты)

• Полезное нагрузка (переменной длины)

• Проверка CRC (4 байты)

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

• Идентификатор протокола тегу (TPID, 2 байта)

- 0x8100 для базовой функциональности VLAN.

- 0x88a8 для адресации основных компонентов (Q-in-Q).

- 0x88e7 для инкапсуляции услуг (MAC-in-MAC).

• Информация о управление тегами (TCI, 2 байта)

- Приоритетная кодовая точка (PCP) - 3-битное поле, какое можно использовать для передачи

приоритетной информации о текущий кадр.

- Допустим индикатор падение (DEI) - 1-битное поле, какое можно использовать, чтобы указать, или

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

- Идентификатор VLAN (VID) – 12-битное поле, используемое для идентификации, к которой VLAN

принадлежит этот кадр.

Кроме того, использование тегов VLAN также позволяет обозначить трафик разными приоритетами.

Например, для временных кадров, сформированных IP- телефоном, поле PCP может быть настроено на

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

сети.

Некоторые проблемы возникают с использованием фреймов с одним тегом VLAN. Например, можно

создать только 2 12 виртуальных сетей, число которого нет хватает для текущих сетей ЦОД с тысячами

виртуальных машин. Кроме того, каждый клиент может использовать только подмножество с 2 12 VID. Эту

проблему частично решает Q-in-Q, что объясняется в следующем разделе.

2.4.2 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]:

• MAC-адреса клиента путешествуют по всей магистрали поставщика, и их запоминают в каждом

коммутаторе. Это влияет на масштабируемость услуги, поскольку таблицы MAC поставщика могут легко

заполниться;

• Количество служебных тегов VLAN все еще ограничена 2 12 ;

• Нету четкой точки разграничение между сетями потребителей да поставщиков по управлению

неисправностями и характеристикам.

2.4.3 MAC-in-MAC

Функционал магистральных мостов провайдера (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-адрес, изучая только адреса назначение да адрес отправителя;

• Введение четкой точки разграничение между сетями клиентов да провайдеров в.

2.4.4 Multiprotocol Label Switching

Архитектура многопротокольной коммутации меток (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 к виртуализации сети - сетевые гипервизоры.

2.5 Виртуализация в сетях SDN

2.5.1 FlowVisor

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.

2.5.2 Vertigo

VeRTIGO [15] расширяет FlowVisor концепцией абстрактных узлов или

абстрактных сетевых устройств, которые состоят с двух основных блоков:

виртуальных ссылок и виртуальных портов. Виртуальные ссылки объединяют

несколько физических узлов и ссылок, абстрагирующих их к контролеру

аренды как единственная ссылка между любыми двумя портами. Один или

несколько виртуальных портов отображаются физический порт соответственно

к количества виртуальных ссылок, которые должны использовать тот самый

физический порт. на рисунка

2.6 показано, как VeRTIGO использует виртуальные ссылки 1 и 2 между SW-A

и SW-D для создания чрезмерных соединений между физическими портами A и

B. Четыре физические коммутаторы представлены в виде единого абстрактного

узла для контроллера аренды с виртуальными портами X да Y, что

сопоставляются с физическими портами A и B соответственно.

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.

2.5.4. FlowN

FlowN [16] предлагает базу данных да облегченную виртуализацию на

основе контейнера как расширение к контроллера -X [39]. База данных

поддерживает отображение физической да виртуальной сети, тогда как каждый

виртуальный контейнер запускает одну программу-арендатора с независимым

адресным пространством. Чтобы обеспечить изоляцию трафика, FlowN

добавляет заголовки VLAN для трафика при входе в сеть и удаляет или

заголовки, когда трафик оставляет сеть, позволяя арендаторам повторно

использовать то же пространство IP-адресов несколько раз.

Вместо этого того, чтобы работать как прокси-контроллер, FlowN - это

модифицированная версия контроллера –X. Таким образом, ему не нужно

отображать сообщение протокола OpenFlow между физическим сетью да

виртуальным представлением сети. Это существенно уменьшает накладные

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

реализуется в самом -X, в то время как разные арендаторы - это программы, что

работают на одному контроллеры, но в контейнерах пространства имен. Авторы

FlowN сравнивают его с FlowVisor и показывают, что FlowN имеет отличную

производительность при наличии большого количества виртуальных сетей (100

или больше). Улучшенные результаты объясняются использованием

реляционной базы данных для хранение отображение виртуальной да

физической топологии.

2.5.5. AutoSlice

AutoSlice [9] представляет систему, какая автоматизирует Задача

распределения плоскости пересылка данных сети между несколькими

арендаторами в плоскости управление. Его главная цель – минимизировать

ручную реконфигурацию сети, чтобы поставщики субстратов могли

перепродавать срезы своих сетей арендаторам. Реализация состоит из

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

управление (MM) да нескольких прокси-серверов контроллера (CPX).ММ

отображает топологии виртуальной SDN (vSDN) в физическое сеть да назначает

каждому CPX домен сетевых ресурсов. CPX отвечает за перезапись управляющих

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

трафика, где это необходимо для обеспечение изоляции. AutoSlice также

пытается использовать такие свойства, как потоки мыши. да слона», чтобы

оптимизировать кэширование записей потока.

2.5.6. AutoVFlow

AutoVFlow [66] работает аналогично AutoSlice, но предлагает предоставить

больше контроля администратором каждой vSDN, переводя ответственность за

обработку виртуализации пространства потока на администратора каждой сети.

AutoVFlow также утверждает, что применяет технику перезаписи MAC на

границах сети, чтобы гарантировать, что каждый пространство заголовка

доступный каждому с арендаторов.

Выводы

Этот раздел коротко представил и объяснил VLAN, MPLS да VXLAN да

VPN, и было показано, что некоторые гипервизоры сети SDN все еще могут

использовать некоторые из этих традиционных технологий для реализации

виртуализации сети. Также были представлены методы виртуализации сетевых

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

предложены эксперименты для оценки некоторых с этих гипервизоров сети

РАЗДЕЛ 3

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

3.1 Топология

3.1.1 Топология Mininet

Эксперименты проводятся на виртуальном тестовом стенде на основе.

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. Схема адресации виртуальных

устройств, что используются в этой сети, была разработана для облегчения

настройки, понимание да запуска экспериментов:

• Хосты были предназначены для трех различных сетей, A, B и C. Сети A и

B (10.0.0.0/8) перекрываются с целью проверки преимуществ изоляции сети.

Сеть С (3.0.0.0/8) назначена для проверки возможных конфликтов с методом

переписка заголовка, какой характерный для OVX;

• Идентификаторы DPID коммутатора соответствуют номерам

коммутатора 00 :: NN. Например, коммутатор SW3 (NN=03) имеет DPID 00::03,

чтобы облегчить Поиск да анализ результатов;

• MAC-адреса хоста были настроены так, чтобы отображать сеть, которой

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

шаблона 02 :: XX: YY, где XX – это сеть, а YY - коммутатор.

Рисунок 3.1. также показывает, что гипервизор сети – OVX, VeRTIGO или

FlowVisor подключен к Open vSwitches через интерфейс обратной связи. Тот

самый интерфейс обратного связи используется для подключение сетевого

гипервизора к Floodlight.

Эта сеть может быть использована для демонстрации нарезки FlowVisor,

устойчивости OVX к резервных маршрутов, а также возможностей

виртуализации топологии OVX и VeRTIGO.

3.1.2 Физическая топология

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

настройка потока да пропускной способности между хостами, изображена на

рисунка 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,

которых может не хватать для более высокой пропускной способности. Это

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

пропускной способности трафика, что пересекает аппаратный коммутатор и

времени установки новых правил потока в коммутаторы.

3.2 Изоляция сети

Для этого эксперимента топология Mininet используется для проверки

изоляции сети посреди арендаторов. Во-первых, проверяется сетевой гипервизор.

FlowVisor, OVX или VeRTIGO – должен быть настроен на разделение этой сети

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

разным экземпляром Floodlight.

Ожидается, что FlowVisor разделит выходную сеть, как показано на

Рисунку 3.3. Для OVX и VeRTIGO изоляция сети должна выглядеть так, как

показано на рисунка 3.2.2., с большим коммутатором, что представляет пять

коммутаторов. Изоляция сети можно проверить, заметив, что хосты, что

принадлежат к разным фрагментам, не могут общаться. Например, хост A1 не

должен иметь возможность отправлять любые пакеты на любой из хостов C1- C5.

Кроме того, сетевой гипервизор должен обеспечить, чтобы контроллеры

арендаторов имели право контролировать только свои сетевые части.

3.3 Автономное перенаправление

И 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.

пакетов

time bandwidth

packet size (3.2)

Например, используя размер пакета 125 байт (1000 бит), пропускную

способность 1 Мбит/с и передача данных в течение 10 секунд должны привести к

N пакетов =10000 пакетов. Итак, каждый потерянный пакет отвечает 10 ⁄ 1000 = 1

миллисекунди. Подсчитать сколько времени сеть остается недоступной, просто

подсчитав количество потерянных пакетов.

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

3.4 Прозрачное пересылка трафика.

Арендаторы сети могут захотеть запускать традиционные сетевые

механизмы в собственной виртуальной сети, такие как механизм обнаружения

LLDP или протокол маршрутизации начала открытого кратчайшего пути (OSPF).

Как LLDP, так и OSPF полагаются на использование многоадресных кадров для

связи с соседними сетевыми устройствами. Виртуализация сети обычно хорошо

проверена для стандартного одноадресного трафика IP, но некоторые

многоадресные кадры и другие специальные типы кадров вряд ли когда-нибудь

проверяются на прозрачную переадресацию трафика в экспериментальных

сетевых гипервизорах. Поэтому важно проверить, что виртуальные сети могут

переадресовывать несколько разных типов трафика.

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

Один с способов проверки прозрачности переадресации движения состоит

в использовании инструмента test_packets.py [51]. Пользователь должен вводить

кадры в один сетевой порт, а затем ожидать, что кадры будут получены на

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

кадры к портов, что принадлежат к правильного фрагмента или виртуальной

сети, не сбрасывая и не изменяя их. Различные гипервизоры сети не должны

дополнительно ограничивать тип трафика, который обычно может пересылаться

только контролером Floodlight.

3.5 Соответствие стандартом адресации

FlowVisor да Vertigo нет меняют трафик в сети. Они просто нарезают

доступный пространство заголовка, чтобы разные арендаторы обрабатывали

разные контроллеры арендаторов. Однако OVX работает, переписывая заголовки

IP, чтобы сделать полный пространство заголовка IP доступным для каждого

арендатора [57].

Целью этого эксперимента является наблюдение за тем, как гипервизор

сети меняет заголовки IP да MAC под время их поступление в сеть. Трафик, что

протекает через внутренние звенья сети, фиксируется в топологии Mininet, затем

захваченные кадры анализируются, имея в виду соответствие стандартам

адресации IP и MAC и зарезервированным диапазонам адресов, как указано:

 IANA IP multicast [29] да распределение MAC-адрес ;

 распределение адрес IETF для частных сетей;

 протоколы управления мостом IEEE, такие как протокол охватывающего

дерева (STP) или общий протокол регистрации атрибутов (GARP);

 Другие общие адреса, уже назначенные поставщикам или

зарезервированные для конкретных целей

Соответствие адресам IPv4 означает, что IP-адреса, сформированные

сетевым гипервизором, есть действительными да находятся в пределах

диапазонов, назначенных частным сетям. Например, 1.0.0.1 - это общедоступна

IP-адрес, присвоена организации в Азии [63], а 224.0.0.5 принадлежит к

диапазона многоадресной передачи IP, зарезервированного IANA, и специально

используется для обмена сообщениями OSPF [53]. Ни один из этих адресов не

должна использоваться сетевыми гипервизорами во время переписки

одноадресных заголовков IP, поскольку они могут вызвать много проблем, если

когда-нибудь возникнет потребность в взаимодействия с другими IP-сетями.

3.6 Эксперименты с производительностью

Время настройка потока уже признано одним с недостатков OpenFlow (и

SDN), поскольку централизованный контроллер работает на пересылку решений

[62]. Кроме того, важно подтвердить, что методы виртуализации, что

применяются сетевыми гипервизорами, не влияющими существенно на

пропускную способность сети. Эксперименты, описаны в этом разделе, имеют

намерение измерять:

 Накладные расходы времени на настройка потока, введены

элементом виртуализации в сети;

 Снижение пропускной способности данных, вызванное методами

изоляции движения, такими как переписка заголовков пакетов.

3.6.1 Время настройка потока

Задача этого эксперимента состоит в сравнить латентности установленных

правил потока Floodlight с задержкой с добавленным гипервизором сети между

Floodlight и коммутатором OpenFlow. Этот эксперимент проводится на

физической топологии, описанной в разделе 3.1.2. Записи ARP на всех хостах

были вручную добавлены в их таблицы, чтобы избежать дополнительной

дисперсии, введенной фазой разрешение адреса.

Процедура заключается в измерении времени обратной связи (RTT) пинга

между двумя хостами. Как показано на рисунке 3.7, когда коммутатор не имеет

правил трафика между хостами А и В, запрос эхо-ответы да сообщение ответы

протокола управление Интернетом (ICMP) должен обрабатываться

контроллером.

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

сколько времени гипервизор сети да контроллер арендатора добавляют к всего

уравнение RTT 3.3.