Руководство по SDN/NFV. Глава 10. Интерфейсы

1. Введение. См. здесь.

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

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

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

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

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

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

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

9.1. Структура контроллера SDN. См. здесь.

9.2. Контроллеры SDN для дата-центров. См. здесь

9.3. Контроллеры SDN WAN. См. здесь.

9.4. SDN-контроллеры специфичных доменов. См. здесь.

10. Интерфейсы

В Главе 10 описаны основные интерфейсы архитектуры SDN/NFV. Часть из них основаны на спецификации ETSI NFV, либо введены другими организациями. Рассматриваемые интерфейсы показаны на структурной схеме SDN/NFV.

Хотя в данной главе для краткости используется термин «интерфейсы», в данном случае справедливо говорить о референсных точках (reference points).

Описание отличий референсной точки от интерфейса можно найти здесь.

Структурная схема SDN/NFV.

Vi-Ha, Vl-Ha (Virtualization Layer – Hardware Resources)

Интерфейс Vi-Ha (Vl-Ha) – это интерфейсы между уровнем виртуализации и аппаратными ресурсами, для создания среды выполнения VNF, а также для сбора информации о состоянии соответствующих аппаратных ресурсов для управления VNF, независимо от конкретной аппаратной платформы.

Интерфейc Vl-Ha обеспечивает абстрагирование оборудования, BIOS, драйверов, устройств ввода/выводы (сетевых карт NIC), ускорителей, модулей памяти и сетевых устройств. Он является частью среды внутренней выполнения в инфраструктуре NFVI. В среде OpenStack этот интерфейс обеспечивается ОС Linux, KVM и открытой программой эмуляции аппаратных платформ QEMU.

На сайте Libvirt можно найти драйверы виртуализации: https://libvirt.org/drivers.html.

Руководство QEMU можно найти на странице: http://wiki.qemu.org/Manual

2. Vn-Nf (VNF — NFVI)

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

Интерфейс Vn-Nf используется для соединения:
VNFC с другими VNFC внутри VNF
VNFC и системой хранения
VNF и PNF, а также внешними точками.

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

Несколько примеров реализации этого интерфейса:

OpenStack compute flavors: (http://docs.openstack.org/admin-guide-cloud/compute-flavors.html)
OpenStack Glance images: (http://docs.openstack.org/developer/glance/)
OpenStack Neutron (https://wiki.openstack.org/wiki/Neutron)
Libvirt CLI/API: (http://libvirt.org/html/index.html)

3. Nf-Vi (NFVI — VIM)

Это интерфейс между подсистемой администрирования и оркестрации в инфраструктуре NFVI и функциями администрирования и оркестрации в менеджере виртуальной инфраструктуры (VIM).

Оркестрация и администрирование NFVI производится строго через интерфейс Nf-Vi и включает следующее:

Назначение виртуализированных ресурсов в ответ на запросы назначения ресурсов от услуг;
Пересылка информации о состоянии виртуализированных ресурсов;
Конфигурация аппаратных ресурсов и обмен информации о состоянии (например, о событиях).

Nf-Vi также обеспечивает взаимодействие между агентами управления и оркестрации в вычислительном домене и менеджером виртуальной инфраструктуры VIM, который использует интерфейс Nf-Vi для управления и частями вычислений и хранения данных в NFVI. Примером реализации для Nf-Vi является плагин libvirt/KVM в OpenStack Nova. Кроме того, гипервизор в NFVI пересылает через Nf-Vi информацию мониторинга инфраструктуры NFVI в VIM.

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

Этот интерфейс также используется для реализации функционала NFVI.

4. Or-Vi (NFVO – VIM)

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

Интерфейс Or-Vi выполняет следующие функции:

Резервирование ресурсов и/или запросы на размещение ресурсов от оркестратора NFV;
Конфигурация ресурсов оборудования и обмен информацией о состоянии (например, событиях)
Управление образами ПО VNF
Управление каталогом визуализированных ресурсов
Управление ёмкостью визуализированных ресурсов
Управление производительностью визуализированных ресурсов
Управление при отказах визуализированных ресурсов
Администрирование установок политик
Управление интерфейсом NFP

В OpenStack этот интерфейс реализуется через API.

5. Vi-Vnfm (VIM — VNFM)

Этот интерфейс используется менеджером VNF (VNFM), через который VNFM запрашивает VIM о состоянии ресурсов, их доступности и состоянии. Через интерфейс передаются:

Запросы на выделение ресурсов от менеджера VNF
Информация о состоянии (например, события) и конфигурации ресурсов виртуализированного оборудования:
- Получение информации о резервировании ресурсов NFVI
- Выделение и освобождение ресурсов NFVI
- Обмен информации о конфигурации между модулями с общими референсными точками, и передача в менеджер VNF информации, на которую он подписан (т.е. события, результаты измерений и записей об использовании функцией VNF ресурсов NFVI).

Интерфейс Vi-Vnfm поддерживает функции:

Управление программным образом VNF
Управление каталогом виртуализированных ресурсов
Управление виртуализацией ресурсов
Управление производительностью визуализированных ресурсов
Управление при отказах визуализированных ресурсов

Для развёртывания в OpenStack, этот интерфейс также реализуется через API, либо непосредственно, либо при помощи шаблонов оркестрации Heat.

Примеры реализации:

OpenStack API: http://developer.openstack.org/api-ref.html

6. Ve-Vnfm (VNF/EM — VNFM)

Этот интерфейс используется для обмена между VNF, системами управления элементами EMS (Element Management Systems) и менеджером VNF (VNFM). Его можно разделить на следующие два интерфейса:

Ve-Vnfm-em, референсная точка между системой управления элементами EMS и Она, скорее всего, будет вендоро-специфичной и будет зависеть от функционала и интерфейсов, предоставленных менеджерами элементов в EMS
Ve-Vnfm-vnf, референсная точка между VNF и VNFM. В ближайшее время она также вероятно будет оставаться вендоро-специфичной, но также будет зависеть и от стандартов, используемых в проектах OpenStack.

Эти референсные точки используются для обмена информации между VNF/EM и VNFM и необходимы для поддержки следующих функций:

Обмена информацией о конфигурации
Запросы для управления жизненным циклом VNF.

Интерфейсы Ve-Vnfm поддерживают следующие функции:

Конфигурация VNF
Управление производительностью VNF
Управление при отказах VNF.

7. Or-Vnfm Interface (NFVO — VNFM)

Этот интерфейс используется для обмена между оркестратором NFV и менеджером VNF, и обеспечивает следующие функции:

Запросы на ресурсы, например, авторизация, подтверждение, резервирование и выделение ресурсов менеджеру VNF.
Предоставление информации о конфигурации для менеджера VNF, чтобы они соответствующим образом были сконфигурированы внутри передающего графа VNF (VNF Forwarding Graph) для создания сетевой услуги.
Сбор информации о состоянии сетевых услуг VNF, необходимых для управления их жизненным циклом.
ETSI определила следующие действия, которые должны поддерживаться на этой интерфейсе:

— Авторизация, подтверждение, резервирование и освобождение ресурсов NFVI для VNF

— Передача запроса на выделение и освобождение ресурсов NFVI для VNF

— Установка и запуск VNF

— Запрос о состоянии экземпляра VNF (т.е. извлечение информации о работе в данный момент)

— Модификация экземпляра VNF (конфигурация апдейта)

— Масштабирование экземпляра VNF, изменение производительности VNF

— Прерывание работы экземпляра VNF.

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

Интерфейс Or-Vnfm поддерживают следящие функции:

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

Хотя этот интерфейс стандартизован ETSI, пока отсутствуют стандарты для разработчиков VNF. Они могут разрабатывать кастомизированные интерфейсы, которые затем используются оркестраторами. Этот интерфейс также может использоваться API, особенно при использовании в OpenStack, например, в проекте Tacker

OpenStack Tacker: https://wiki.openstack.org/wiki/Tacker

8. Se-Ma (каталоги, репозитории и оркестрация)

Сервисы, VNF и схемы описания (дескрипторы) инфраструктуры предоставляют информацию о развёртывании шаблонов VNF, графов передачи VNF, информации о сервисах, и информационных моделях NFV-инфраструктуры. Эти шаблоны и дескрипторы используются внутри NFV MANO. Функциональные блоки MANO обрабатывают информацию, содержащуюся в шаблонах и дескрипторах, и могут предоставлять эту информацию в другие функциональные блоки при необходимости.

Хотя ETSI описал интерфейс Se-Ma, варианты его реализации пока только обсуждаются, и наиболее обсуждаемые из них – это OpenStack Heat, TOSCA and Yang/NETCONF. Информацию об этих реализациях Se-Ma можно найти по ссылкам:

Heat: https://wiki.openstack.org/wiki/Heat
TOSCA: http://docs.oasis-open.org/tosca/TOSCA/v1.0/os/TOSCA-v1.0-os.html
Yang/NETCONF: http://www.yang-central.org/

9. Re-Sa (репозитории – подсистема обеспечения услуг Service Assurance)

Этот интерфейс используется подсистемой SA для доступа к данным по обеспечению услуг (service assurance data), хранящимся в репозитории (Catalogs/Repositories).

Информацию о реализациях Re-Sa можно найти по ссылкам:

Heat: https://wiki.openstack.org/wiki/Heat
TOSCA: http://docs.oasis-open.org/tosca/TOSCA/v1.0/os/TOSCA-v1.0-os.html
Yang/NETCONF: http://www.yang-central.org/

10. Ca-Vnfm (Каталоги – VNFM)

Этот интерфейс используется VNFM для управления жизненным циклом VNF. Его реализации описаны здесь:

Heat: https://wiki.openstack.org/wiki/Heat
TOSCA: http://docs.oasis-open.org/tosca/TOSCA/v1.0/os/TOSCA-v1.0-os.html
Yang/NETCONF: http://www.yang-central.org/

11. Os-Ma (OSS/BSS – NFVM & Orchestration)

Референсная точка Os-Ma используется для обмена информацией между оркестратором NFV унаследованной (традиционной) системой OSS/BSS. Референсная точка Os-Ma-nfvo, которая является производной от Os-Ma, необходима для:

Управления дескрипторами сетевых услуг и пакетом управления VNF
Управление жизненным циклом экземпляра сетевой услуги, в т.ч.:
- Создания сетевой услуги из VNF
- Модификации сетевой услуги (то есть, модификации экземпляра VNF, которая содержится в экземпляре сетевой услуги)
- Запроса информации состояния сетевой услуги (то есть, извлечение суммирующей информации о ресурсах NFVI, связанных с экземпляром сетевой услуги, или с экземпляра VNF внутри экземпляра сетевой услуги)
- Масштабирования экземпляра сетевой услуги
- Окончание работы сетевой услуги (termination)
Управление жизненным циклом VNF:
- При этом оркестратор NFV идентифицирует менеджер VNF и передаёт соответствующий запрос (см. описание интерфейса Or-Vnfm)
Управление политиками и/или задействование экземпляров сетевой услуги, VNF и ресурсов NFVI для авторизации, контроля доступа, резервирования и выделения ресурсов, пр.)
Запрос информации об экземпляре соответствующей сетевой услуги и/или VNF от OSS/BSS
Передача событий, записей об использовании ресурсов и результатов измерении параметров экземпляров сетевой услуги, VNF ресурсов NFVI в OSS/BSS, а также информации о связи между этими экземплярами и ресурсами NFVI, в т.ч. числа виртуальных машин VM, использованных определённым экземпляром VNF.

Интерфейс Os-Ma поддерживает следующие функции :

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

Хотя этот интерфейс был описан в ETSI, какие либо стандарты или реализации пока отсутствуют. В ближайшее время, вероятно появятся зависящие от вендора реализации, которые будут определяться существующими решениями OSS/BSS, разными у разных вендоров.

12. Or-Sa (NFVO – подсистема Service Assurance)

Этот интерфейс в ETSI не описан, и ожидается, что оркестратор NFV сможет обеспечить способ взаимодействия с подсистемой Service Assurance. Для этого интерфейса требуются интерфейсы с функционалом REST API. Вместе VNF может быть использован NETCONF, где доступен агент и используется информационная модель YANG для задания конфигурации Service Assurance. Для этого должны быть разработаны трансляторы, которые могут конвертировать модели YANG в проприетарные интерфейсы.

13. Or-EMS (NFVO – EMS, Element Management Systems)

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

14. Ve-Sa (Virtual Element – подсистема Service Assurance)

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

15. Vnfm-Sa (менеджер VNF – подсистема Service Assurance)

Для тех VNF, которые не могут управляться от обычного менеджера VNF, будет использоваться обычный интерфейс, который организует протоколы, доступные через VIM и NFVI. Для этого интерфейса необходимы REST API. Там, где используется модель YANG, может также использоваться NETCONF.

16. Vi-Sa (менеджер виртуальной инфраструктуры VIM – подсистема Service Assurance)

Этот интерфейс в ETSI не описан, и, скорее всего, он будет специфичным для каждого VIM. Для этого интерфейса необходимы REST API. Там, где используется модель YANG, для конфигурации Service Assurance может также использоваться NETCONF.

Для реализации в OpenStack возможны следующие варианты:

OpenStack Ceilometer: (https://wiki.openstack.org/wiki/Ceilometer)
OpenStack Monasca: (https://wiki.openstack.org/wiki/Monasca).

17. Nfvi-Sa (Сетевые функции – подсистема Service Assurance)

Этот интерфейс в ETSI не описан, и, скорее всего, он будет специфичным. Ожидается, что сетевые функции будут использовать существующие протоколы, такие как SNMP, SYSLOG и NETCONF. В дальнейшем, вероятно, сетевые функции будут использовать общие протоколы VIM и NFVI, в дополнение к вендорским протоколам.

18. Or-Nf (оркестратор – сетевые функции)

Этот интерфейс представляет собой комбинацию NETCONF, RESTCONF и вендороспецифичных методов, (таких как интерфейс командной строки CLI или вендорские SDK). NETCONF и RESTCONF определены в IETF.

19. Or-Sdnc (оркестратор – контроллер SDN)

Этот интерфейс в ETSI пока не описан. Обычно оркестрация услуг, в частности NFVI, требуют REST API (например, в OpenDaylight). Специфичные для разных SDN-котроллеров интерфейсы делают изменения в сети сложной задачей, при использовании на сети WAN разных SDN-контроллеров. Здесь также используются NETCONF and RESTCONF, если функции SDN-котроллера определяются с помощью модели YANG.

20. Sdnc-Nf (контроллер SDN Controller – сетевая функция)

Этот интерфейс в ETSI пока не описан. Сетевые функции, такие, как программные сетевые элементы, а также виртуализированные роутеры PE/CE, часто требуют взаимодействия между контроллерами SDN WAN и контроллерами SDN внутри дата-центров. В этом интерфейсе используются протоколы OpenFlow, XMPP, NETCONF и другие.

21. Vi-Sdnc (VIM – контроллер SDN)

Этот интерфейс в ETSI пока не описан. Он предназначен для того, чтобы менеджер виртуальной инфраструктуры VIM сообщал контроллеру SDN о том, что новые виртуальные машины доступны и их нужно приписать соответствующим подсетям. Для этого интерфейса обычно используется API OpenStack Neutron, но в нем не хватает ряда важных сетевых функций, требуемых для масштабирования, управления топологией сети и составление цепочек услуг.

Дополнительную информацию о вендороспецифичных плагинах для SDN-контроллеров можно найти здесь: https://wiki.openstack.org/wiki/Neutron/ML2

22. Sdnc-Net (SDN Controller — Networks)

Этот интерфейс в ETSI пока не описан. Контроллер SDN через этот интерфейс управляет сетевыми ресурсами NFVI в дата-центре.

23. Dsc-Nf (Domain Specific Controller – сетевые функции)

Этот интерфейс в ETSI пока не описан. Интерфейсы домено-специфичных контроллеров будут использовать сочетание проприетарных расширений и стандартных протоколов, таких как NETCONF и OpenFlow.

24. Sdnc-Sa (Контроллер SDN – Service Assurance)

Этот интерфейс в ETSI пока не описан. Контроллеры SDN собирают статистику о сервисах, которыми они управляют, а затем передают эту статистику в подсистему Service Assurance через интерфейс Sdnc-Sa. Статистика, в основном, содержит информацию об использовании сети и аспектах производительности (нагрузка, задержка, потери пакетов и пр.).

25. Cf-N (Collection Function — NFVI)

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

26. Cf-Sa (Collection Function – Service Assurance)

Этот интерфейс в ETSI пока не описан. Он предназначен для сбора информации сети во время аварий и ненормальных ситуаций