Руководство по 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).

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

1

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

 

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

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

 

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.

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

 

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

 

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

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

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

 

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

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

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

 

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

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

 

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)

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

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

 

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

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

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

 

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 пока не описан. Он предназначен для сбора информации сети во время аварий и ненормальных ситуаций

1

Об авторе Алексей Шалагинов

Независимый эксперт
Галерея | Запись опубликована в рубрике Руководство по SDN/NFV, SDN с метками , , , , . Добавьте в закладки постоянную ссылку.

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

  1. Уведомление: Телеком и ИТ

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s