Мультисервисные сети2

Каждый логический коммутатор OpenFlow содержит одну или несколько таблиц потоков (рис. П2.6).

Коммутатор SDN. Согласно спецификации OpenFlow каждый коммутатор состоит из следующих компонентов (рис. П2.6) [5]:

одной или нескольких таблиц потоков (flow table);

безопасного канала (secure channel), использующегося для управления коммутатором внешним «интеллектуальным» устройством (контроллером) при помощи OpenFlow;

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

Рис. П2.6. Основные компоненты коммутатора OpenFlow [3]

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

Порядок работы коммутатора SDN показан на рис. П2.7 и состоит из следующих шагов [6]:

1. Первый пакет нового потока прибывает на входящий порт коммутатора.

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

Рис. П2.7. Порядок работы коммутатора SDN

3.Если записи в таблицах потоков не найдены, пакет может быть передан контроллеру SDN по защищенному каналу связи.

4.Согласно алгоритму маршрутизации контроллер SDN добавляет соответствующую запись в коммутатор и остальные коммутаторы по тракту передачи данного потока.

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

Между контроллером и коммутатором возможны три типа сообще-

ний [7]:

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

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

сообщения, инициируемые как контроллером, так и коммутатором.

Сообщения, инициируемые контроллером, могут возникать в следующих случаях:

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

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

Сообщения, инициируемые коммутатором, могут возникать в следующих случаях:

для извещения контроллера об изменениях в состоянии коммутатора SDN;

для отправки контроллеру SDN полученных пакетов;

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

Сообщения, инициируемые как контроллером, так и коммутатором, могут возникать в следующих случаях:

для проверки состояния канала связи между контроллером и коммутатором;

при (начале) установлении соединения между контроллером и коммутаторам;

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

SDN.

П2.3. Виртуализация сетей NFV

Идея виртуализации сетевых функций (Network Function Virtualization, NFV), в отличие от SDN, созданной исследователями и разработчиками центров обработки данных (ЦОД), изначально продвигавшаяся крупными европейскими операторами, предполагала перенос сетевых сервисов со специализированных устройств на стандартные компьютерные платформы в виртуализированные среды [9] (рис. П2.8).

После ряда неудачных попыток сервис-провайдеров увеличить скорость внедрения новых услуг пришло понимание того, что аппаратное решение не позволяет это сделать. Более того, услуги, зависимые от оборудования быстро устаревают, требуя повторения цикла «закупка–планирование–внедрение–использование» с небольшой прибылью или вообще без прибыли. B октябре 2012 г. группа по промышленной спецификации NFV представила официальный документ на конференции посвященной SDN и OpenFlow в Германии [8]. Сегодня работой по стандартизации NFV занимается европейский ин-

ститут ETSI (European Telecommunications Standards Institute).

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

Рис. П2.8. Принцип NFV

Технология NFV используется в маршрутизаторах, межсетевых экранах и шлюзах, устройствах CDN, акселераторах WAN, контроллерах доставки приложений (ADC) в сетях операторов и сервиспровайдеров.

NFV не потребует отказа от уже развернутой сетевой инфраструктуры при развертывании новых сервисов, так что «новое» может мирно сосуществовать со «старым». Таким образом, внедрить NFV проще, чем SDN, поскольку в NFV используется стандартная аппаратная среда. Кроме того, NFV позволяет вернуться при необходимости к прежней сетевой инфраструктуре, а это снижает риски.

Сегодня основными направлениями NFV являются [10]:

Виртуальные соединения (Virtual Switching) – физические порты, соединенные с виртуальными портами на виртуальном сервере с виртуальными маршрутизаторами, используя виртуализированные

IPsec и SSL VPN шлюзы.

Виртуализированные сетевые устройства (Virtualized Network Appliances) – сегодня сетевым функциям необходимы отдельные устройства, которые могут быть заменены их виртуальными аналогами. Например, функции защиты, такие как межсетевые экраны (firewalls) и шлюзы, маршрутизатор широкополосного удалённого доступа (BRAS) и ядро пакетной сети LTE (EPC).

Виртуализированные сетевые услуги (Virtualized Network Services), например, приложения по управлению сетью, такие как анализаторы трафика и оборудование по мониторингу сети, перераспределители нагрузки и ускорители.

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

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

луг [9].

Сравнение SDN и NFV. Сейчас давайте вернемся к взаимосвязи

SDN и NFV.

Как показано на рис. П2.9, NFV дополняет SDN, но не зависит от SDN (и наоборот). NFV может быть реализована без SDN, хотя эти два решения могут быть объединены, и тогда потенциальная эффективность будет увеличена [11].

Рис. П2.9. Соотношение между NFV и SDN

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

Рассмотрим пример того, как SDN и NFV могут работать вместе. На рис. П2.10 показано, как сегодня осуществляется маршрутизация за счет использования маршрутизатора на стороне клиента.

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

П2.4. Стандартизация ПКС

Общие положения. Исследованием общих вопросов и стандартизацией SDN занимаются ONF, IETF, Исследовательская группа ин-

тернет-технологий (Internet Research Task Force, IRTF), Европейский институт по стандартизации в области телекоммуникаций (European Telecommunications Standards Institute, ETSI) и МСЭ-Т. Представители Форума широкополосных сетей (Broadband Forum, BBF) изучают некоторые частные вопросы построения и эксплуатации сетей SDN.

В рамках рабочей группы «Инновационные услуги и рыночные требования» (Service Innovation & Market Requirements) выделен про-

ект SD-313 – коммерческие требования и структура SDN в широкополосных телекоммуникационных сетях (Business Requirements and Framework for SDN in Telecommunication Broadband Networks). Проект предполагает проведение исследований в области сценариев перехода к сетям SDN, включая варианты поддержки SDN частью оборудования, а также внедрение функциональности SDN в оборудование при обновлении ПО. Частные вопросы применительно к SDN рассматриваются и участниками Форума оптического межсетевого взаи-

модействия (Optical Internetworking Forum, OIF). Эта некоммерческая организация, разрабатывающая соглашения по реализации (Implementation Agreement, IA) для оборудования оптических сетей, оценивает концепцию SDN как перспективную и занимается разработкой требований к SDN в части транспортных сетей со стороны операторов (оптических) сетей и поставщиков услуг, структуры SDN и ее соотносимости с архитектурой оптических сетей с автоматической коммутацией (Automatically Switched Optical Network, ASON), а также демонстрацией и тестированием SDN (рис. П2.13) [12].

Рис. П2.13. Распределение стандартизирующих организаций по направлениям разработки архитектуры SDN

Стандарты ONF. В 2011 г. компании Facebook, Deutsche Telekom, Microsoft, Verizon и Yahoo! организовали консорциум ONF с целью развития технологий SDN в целом и протокола OpenFlow в частности. Сегодня членами ONF являются практически все основные поставщи-

ки сетевого оборудования, включая Alcatel-Lucent, Brocade, Ciena, Cisco, Dell, Ericsson, Extreme Networks, HP, Huawei, IBM, Infinera, Intel, Juniper Networks, Mellanox, Netgear, Nokia Solutions and Networks, ZTE,

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

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

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