| Рубрикатор |  |
 |
| Блоги |  |
Алексей ЛУКАЦКИЙ | |
|
О состоянии стандартизации NFV.
| 18 января 2017 |
|
Сегодня можно выделить два главных источника стандартизации NFV – рабочую группу по NFV в европейском институте стандартизации ETSI, а также созданную крупнейшим оператором США (и мира тоже) AT&T группу из более чем 2000 сотрудников по разработке собственной архитектуры ECOMP (Enhanced Control, Orchestration, Management and Policy), во многом сходной с архитектурой с разработанной в ETSI и являющейся частью концепции AT&T Domain 2.0. Фактически, в AT&T так называют технологии SDN/NFV.
Когда 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 показана на рисунке.
Структура имеет 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, с помощью которых эмулируется работа реальной сети оператора. А также создаются новые сетевые функции и пользовательские услуги, которые раньше были либо невозможны в принципе, либо создание их было, либо слишком сложным, либо очень дорогим.
Теперь обратимся к архитектуре ЕСОМР, которая показана на рисунке:
Пусть вас не пугает её устрашающий вид, разобраться в ней связисту, умеющему читать по-английски, несложно (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 выглядят очень по-разному, их принципы работы, в целом, очень близки. Идея разработки ЕСОМР была в том, что чтобы расширить и детализировать идеи ETSI, особенно в части котроллеров и установки политик. По сравнению с ETSI NFV, в ЕСОМР также расширены возможности по учёту ресурсов и сервисов. Кроме того, функционал FCAPS, который в стандарте ETSI остался в EMS (а мы уже отмечали, что жизнь этих элементов недолга), в стандарте ЕСОМР выделен в отдельный компонент и достаточно хорошо проработан.
На рисунке ниже показано сравнение архитектур, выполненное самой AT&T в исходной статье о ЕСОМР
Можно сразу увидеть основное различие: EMS в архитектуре ECOMP отсутствуют, зато функционал FCAPS добавлен в область ECOMP Execution. В остальном, архитектуры сходны. По мере развития ETSI NFV, она будет все больше походить на ECOMP AT&T.
По мере того, как всё больше операторов будут реализовывать решения на базе обеих архитектур, они будут совершенствоваться, и без уроков реального мира здесь не обойтись. Модель ETSI, скорее всего, будет дополнена полнофункциональным оркестратором, по примеру AT&T. OPNFV будет расширять границы использования, от VIM/NFVI к MANO, что сейчас лишь только намечается.
Скорее всего, в ближайшем будущем мы увидим существенные перемены в обеих архитектурах. Но скорее всего не стоит ожидать появления каких-то других стандартов. И никто не ошибется, если выберет за основу одну из рассмотренных архитектур, поскольку, скорее всего развиваться они будут в сторону сближения.
Адрес: 105082, Россия, г. Москва, 2-й Ирининский пер, д. 3
Оставить свой комментарий:
Комментарии по материалу
Данный материал еще не комментировался.