2. Архитектура. См. здесь.

3. Инфраструктура NFV (NFVI) и менеджер VIM. См. здесь.

4. Менеджер VNF (VNFM). См. здесь.

5. Дескрипторы VNF (VNFD). См. здесь.

6. Оркестрация услуг EEO. См. здесь.

7. Дескрипторы комплексных сетевых услуг EENSD. См. здесь.

8. Структура политик. См. здесь.

9.1  Структура контроллеров SDN (Часть 1). См. здесь.

9.3 Контроллеры SDN для дата-центров.

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

Один из примеров развёртывания SDN внутри дата-центра показан на рис. 9.2:

Рис. 9.2. Контроллер SDN дата-центра.

SDN-контроллер управляет передачей пакетов через коммутаторы  дата-центра (функция forwarder) через открытые протоколы, такие как OpenFlow, OVSDB, или NETCONF. В зависимости от применения, эти проколы требуют расширения, или дополнительной адаптации, либо выбор протокола может изменяться в конкретном случае. Функция forwarder на каждом сервере или VNF может либо состоять из имеющейся в нём функциональности (“vSwitch”), либо может дополняться дополнительным агентом передачи, который может управляться теми же протоколами. Кроме того, управление может осуществляться через через API, предоставленный вендором. От SDN-контроллера также может требоваться поддержка функции forwarder на обычном физическом коммутаторе. Например, в случае сервера «bare metal», или устройства, подключенного к коммутатору ToR (Top of Rack), SDN-контроллер должен создавать наложенный туннель между ToR и виртуальной функцией forwarder.

«Северный» интерфейс (Or-Sdnc, см. рис. 9-1 здесь) определяется в зависимости от контроллера и предоставляется как API в сторону уровня оркестрации. Интерфейс Or-Sdnc SDN-контроллера дата-центра также предоставляет API, через который задаются параметры соединения (коннективность) в абстрагированном виде. Обычно это делается через API-интерфейс REST, Openstack Neutron или vSphere. В частности, в NFV MANO эти требования коннективности могут формулироваться в информационных моделях YANG или TOSCA, которые являются частью сетевой услуги или VNF.

«Южный» интерфейс SDN-контроллера (Sdnc-Net и Sdnc-Nf, в зависимости от типа контроллера) используется для передачи команд на коммутаторы сети дата-центра. Он должен поддерживать новый функционал без проблем «обратной совместимости». Он будет описан позднее. В этом интерфейсе также используются протоколы Openflow, OVSDB, NETCONF или проприетарный API вендора. При создании виртуальной машины, контроллер SDN использует заданные общим оркестратором EEO (см. рис. 9-1) требования коннективности и создает наложенные туннели между данной VM и всеми другими виртуальными машинами, к которым данной VM требуется подключение. Обычно эти туннели используют инкапсуляцию VXLAN или GRE.

Как пример, можно рассмотреть случай управления сетевыми услугами (межсетевой экран, балансировщик нагрузки, и пр.). SDN-контроллер дата-центра создает коннективность для подключения виртуальной сетевой услуги согласно её установкам коннективности. Эта услуга либо может быть полностью виртуальной, либо частично использовать коннективность физической сети. Когда требования коннективности предусматривают использование физической сети, контроллер SDN программирует шлюзы между физической и виртуальной сетями (VXLAN to VRF mapping).

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