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

Сегодня можно выделить два главных источника стандартизации NFV – рабочую группу по NFV в европейском институте стандартизации ETSI, а также созданную крупнейшим оператором США (и мира тоже) AT&T группу из более чем 2000 сотрудников по разработке собственной архитектуры ECOMP (Enhanced Control, Orchestration, Management and Policy). ECOMP во многом сходна с архитектурой ETSI и является частью общей концепции цифровой трансформации AT&T: Domain 2.0.

Когда AT&T начинала процесс цифровой трансформации, ещё не было создано никаких руководств, которым можно было бы последовать. Поэтому AT&T сама начала создавать руководство для себя. По словам технического директора AT&T Джона Донована, «ECOMP – это масштабируемая, всеохватная, сетевая, облачная, сервисная и инфраструктурная платформа». Однако, в AT&T придают большое значение совместимости стандартов ETSI и Domain2.0/ ECOMP, а также обеспечению возможности взаимодействия обеих платформ

Хотя в стандартах ETSI пока имеются некоторые «пробелы», они быстро заполняются, по мере появления реальных имплементаций в виде пилотных, а затем коммерческих проектов трансформации сетей различных операторов. Кроме того, ETSI NFV является базисом для проекта OPNFV (Open Platform for NFV), в котором создаются средства открытой разработки (open-source) приложений для использования в NFV. Это очень важная часть трансформации бизнеса операторов. OPNFV открывает массу возможностей для софтверных стартапов, которые будут создавать приложения для развертывания на сетевой инфраструктуре операторов связи, тем самым расширяя их возможности и участвуя в разделении доходов (Revenue sharing). Это могут быть нейронные сети, которые ещё называют «искусственным интеллектом» AI (Artificial Intelligence), различные приложения с использованием анализа «больших данных» (Big Data), приложения Интернета вещей и «индустриального» Интернета, (IoT/IIoT) и многое другое.

Стандарт ECOMP, в свою очередь, сейчас гораздо более детализирован и «заточен» на операционные области работы оператора. Коммерческий оператор, особенно такой монстр, как AT&T, вряд ли может позволить себе тратить годы на обсуждения и проработку деталей интерфейсов и протоколов. Тем более, что техническое перевооружение такой компании, как AT&T, походит на замену винтового двигателя на реактивный на самолете, летящем на высоте 10 тыс. метров. Что, собственно, у AT&T неплохо получается.

С другой стороны, не так много компаний, которые практически используют именно стандарт ЕСОМР. Это может повлиять на его широкое распространение, несмотря на то, что функционал ECOMP гораздо шире, чем у стандарта ETSI NFV.

Рассмотрим каждый стандарт и сравним их. Это даст некоторое понимание, какие пробелы имеются в ETSI NFV, и как их можно ликвидировать.

Ведущим в отрасли связи (в мире) в данный момент является стандарт ETSI NFV. Практически все вендоры разрабатывают свои решения NFV в соответствии с ним, и большинство операторов также используют этот стандарт в качестве модели для развёртывания NFV на своих сетях. Основная структура (framework) стандарта ETSI NFV показана на рисунке.

Источник: http://www.etsi.org/deliver/etsi_gs/nfv/001_099/002/01.01.01_60/gs_nfv002v010101p.pdf

Структура имеет 4 основных области: инфраструктура NFVI (NFV Infrastructure), подсистема управления и оркестрации MANO (Management and Orchestration), виртуальные сетевые функции VNF (Virtual Network Functions)…и соответствующие им системы управления сетевыми элементами EMS (Element Management System), а также подсистема управления и оркестрации MANO (Management/Orchestration) и средства интеграции существующей у оператора системы поддержки операций OSS (Operations Support System) с MANO. Заметим, что это пока самая непроработанная часть «фреймворка» NFV: референсные точки Os-Ma и Se-Ma пока детально не определены (даже их линии упираются куда-то в границу подсистемы MANO, а не в определённый функциональный модуль – видимо, похоже в ETSI пока не знают, куда их воткнуть…).

Модули EMS являются своеобразным аппаратным «рудиментом», когда сетевые функции, «зашитые» в аппаратном оборудовании, управлялись от аппаратной же EMS. В процессе эволюции виртуальных сетевых функций VNF, когда они будут разрабатываться специально «под облако» (cloud native), надобность в использовании EMS постепенно отпадёт.

Очень важная часть – стек MANO, который состоит из оркестратора NFV (NFVO), менеджера VNF (VNF Manager), и менеджера виртуальной инфраструктуры VNFI — VIM (Virtual Infrastructure Manager).

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

В VNFI используются только три вида стандартного «железа»: серверы (х86), хранилища (HDD/SSD) и коммутационное сетевое оборудование. Сверху находится уровень виртуализации, который превращает эти три вида оборудования в их виртуальные образы: виртуальные машины, контейнеры и области хранения. Виртуальные сети создаются с использованием технологии SDN, которая здесь не обсуждается, тем не менее она синергетически связана с NFV (хотя теоретически NFV может обходиться и без SDN).

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

Более подробно о стандарте ETSI можно ознакомиться здесь: http://www.etsi.org/technologies-clusters/technologies/nfv .

Теперь обратимся к архитектуре ЕСОМР, которая показана на рисунке:

Пусть вас не пугает её устрашающий вид, разобраться в ней связисту, умеющему читать по-английски, несложно (http://about.att.com/content/dam/snrdocs/ecomp.pdf), здесь мы также упомянем лишь основные области этой архитектуры.

Это портал для проектирования и операционных функций (ECOMP Portal), куда входят компонент проектирования и создания услуг (Service Design&Creation), компонент создания политик (Policy Creation) и компонент проектирования приложений аналитики (Analytic Application Design). Кроме того, под управлением ECOMP-портала также находятся компонент реестра активных и доступных элементов A&AI (Active and Available Inventory), компонент сбора данных, аналитик и событий DCAE (Data Collection Analytics and Events), главный оркестратор услуг MSO (Master Service Orchestrator), а также контроллеры для различных сетей и приложений в них.

Голубым цветом на схеме выделена среда для проектирования и создания (design/creation) сервисов, политик и бизнес-правил. Желтым цветом показана среда исполнения (execution).

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

Компонент A&AI обеспечивает обзор предоставленных сервисов, а также доступных ресурсов. Он работает по заданной модели и может динамически добавлять и модифицировать услуги.

Компонент DCAE обеспечивает функционал FCAPS (управление отказами, конфигурацией, учётом, производительностью и безопасностью), при управлении сервисами и задействованными устройствами.

Компонент MSO обеспечивает полную оркестрацию всей активности в архитектуре ЕСОМР.

Хотя архитектуры ETSI и AT&T выглядят очень по-разному, их принципы работы, в целом, очень близки. Идея разработки ECOMP была в том, что чтобы расширить и детализировать идеи ETSI, особенно в части контроллеров и установки политик. По сравнению с ETSI NFV, в ECOMP также расширены возможности по учёту ресурсов и сервисов. Кроме того, функционал FCAPS, который в стандарте ETSI остался в EMS (а мы уже отмечали, что жизнь этих элементов недолга), в стандарте ECOMP выделен в отдельный компонент и достаточно хорошо проработан.

На рисунке ниже показано сравнение архитектур, выполненное самой AT&T в исходной статье о ECOMP (http://about.att.com/content/dam/snrdocs/ecomp.pdf ):

Можно сразу увидеть основное различие: EMS в архитектуре ECOMP отсутствуют, зато функционал FCAPS добавлен в область ECOMP Execution. В остальном, архитектуры сходны. По мере развития ETSI NFV, она будет все больше походить на ECOMP AT&T.

По мере того, как всё больше операторов будут реализовывать решения на базе обеих архитектур, они будут совершенствоваться, и без уроков реального мира здесь не обойтись. Модель ETSI, скорее всего, будет дополнена полнофункциональным оркестратором, по примеру AT&T. OPNFV будет расширять границы использования, от VIM/NFVI к MANO, что сейчас лишь только намечается.

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

* * *