Сеть любого оператора связи состоит из множества разнообразных специализированных аппаратных устройств, причем, это разнообразие ширится год от года.  Запуск любого нового сетевого сервиса предполагает добавление все новых наборов устройств, требующих места в аппаратных комнатах, новых источников питания и климатики. Это ведёт к росту стоимости потребляемой энергии, капитальных и операционных затрат, а также необходимости найма персонала, обладающего все более разнообразной квалификацией и специализацией. Кроме того, аппаратные сетевые устройства всё быстрее устаревают, не столько физически, сколько «морально», что требует все более частых повторений цикла «закупка – проектирование – интеграция – развертывание». Причем, на доходах оператора это чаще всего не сказывается сколько-нибудь положительно. По мере ускорения развития технологий и появления инноваций, сроки службы оборудования имеет тенденцию к укорочению.

Всё это приводит к тому, что затраты на развитие сети начинают опережать рост доходов, на которые направлены эти затраты.

Стало ясно, что экстенсивный путь развития операторских сетей на базе специализированного оборудования является тупиковым. Требуются новые подходы к развитию бизнеса операторов и сервис-провайдеров. Одним из таких подходов является виртуализация сетевых функций NFV, связанная с концепцией программно-конфигурируемых сетей SDN.

Технологии NFV – разворачивающаяся на наших глазах революция в телекоме, которую можно сравнить лишь с переходом от аналоговых АТС к цифровым коммутаторам на сетях связи 40-50 лет назад.

Что-же такое SDN и NFV, в чем между ними разница, и какова их взаимосвязь?

Программно-определяемая сеть SDN (Software Defined Network) – метод администрирования компьютерных сетей, позволяющий управлять услугами сети, когда функционал управления (control plane) отделен (абстрагирован) от нижележащего уровня пересылки пакетов (data plane). Планирование сети и управление трафиком в при этом происходит программным путем. Для приложений верхнего уровня предоставляются интерфейсы прикладного программирования API. Таким образом, ввод новых услуг на сети ускоряется и облегчается.

Виртуализация сетевых функций NFV (Network Functions Virtualization) – технология виртуализации физических сетевых элементов телекоммуникационной сети, когда сетевые функции исполняются программными модулями, работающие на стандартных серверах (чаще всего х86) и виртуальных машинах (VM) в них. Эти программные модули могут взаимодействовать между собой для предоставления услуг связи, что ранее занимались аппаратные платформы.

SDN и NFV, в общем, не зависят друг от друга, хотя NFV может в значительной степени дополнять SDN.

Архитектура SDN/NFV показана на рис. 1.

Рис.1 Архитектура SDN и NFV.

SDN и NFV

SDN – это архитектурный «каркас» для создания «сетей внутри сети» с заранее определёнными параметрами и конфигурацией. Таким образом, сеть становится «программируемой», создаваемой из имеющихся ресурсов под конкретные приложения и более открытой. SDN позволяет автоматическое конфигурирование сетей под определенные приложения, или набор приложений («бизнес»). SDN позволяет приложениям запрашивать сетевые услуги и манипулировать ими, а с другой стороны, дает возможность предоставлять приложениям топологию и состояние сети. Основное свойство архитектуры SDN – отделение (абстрагирование) плоскости пересылки пакетов (data plane) от плоскости управления (control plane) при помощи стандартных протоколов между ними. В пример можно привести «коробку-автомат» в автомобиле, которая скрывает (абстрагирует) техническую сложность управления автомобилем в случае «ручной» коробки передач. Водитель не задумывается о том, какую выбрать передачу в соответствии со скоростью и оборотами двигателя, за него это делает автомат в коробке передач. Так и сервер управления SDN автоматически конфигурирует сетевые ресурсы в соответствии с запросами приложений. Цепочке «водитель – автомат – шестерни в коробке» в автомобиле соответствует цепочка «приложение – сервер SDN – сетевые элементы» в сети оператора.

Таким образом, SDN – не очередной протокол для улучшения работы сети, а новая архитектура сети с абстрагированием уровня управления.

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

Рис. 2. Управление сетью без SDN (слева) и с SDN (справа).

NFV

NFV – это способ виртуализации функций элементов сети оператора связи. Суть NFV состоит в том, чтобы реализовать функции управления сетями и предоставления услуг программным путем, вместо того, чтобы использовать специализированное оборудование. Здесь можно провести аналогию различий между театром и кино. В театре зрители видят «аппаратную реализацию» пьесы, которую играют живые актеры, используются реальные декорации и «живой оркестр». А в кино они видят «виртуализацию» пьесы на кинопленке, или в мультимедийном цифровом файле. Суть пьесы при этом не меняется, и, в общем, можно сказать, что зрители (абоненты) получают ту же услугу (переживают за героев пьесы), что и в театре. Если не вдаваться в эстетические различия разных видов искусства, то экономические преимущества кино перед театром очевидны – билет в кино стоит дешевле чем в театр, и затраты на организацию киносеанса также гораздо меньше, спектакля в театре. Таким образом, аппаратные сетевые платформы – «театр», а NFV – «кино».

Архитектура виртуализации сетевых функций (NFV), разработанная ETSI (документ ETSI GS NFV-0010 V0.1.7), показана на рис. 3.

Рис. 3. Архитектура NFV для оператора связи.

Ее основной особенностью является возможность т.н. «оркестрации услуг», т.е. выделения виртуальных ресурсов тем или иным услугам по запросу. При этом достигается наиболее оптимальное использование ресурсов оборудования: серверов, хранения и сети. Для этого в архитектуре NFV предусмотрен компонент администрирования и оркестрации MANO (Management and Orchestration), который является важнейшей частью концепции NFV.

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

Рассмотрим работу системы NFV и ее отдельных элементов подробнее.

1. Виртуальные сетевые функции VNF (Virtual Network Function):

Виртуальные сетевые функции VNF – основа архитектуры NFV. Это и есть виртуализированные функции сетевых элементов. Например, это может быть маршрутизатор (Router VNF), или базовая станция (BS VNF) и пр. VNF может представлять также одну из подфункций сетевого элемента, например, функцию пересылки пакетов (forwarding) в маршрутизаторе. Тогда несколько VNF будут соответствовать одному физическому сетевому элементу.

Другие элементы телекоммуникационной сети, например, IMS, GGSN, SGSN и пр., также могут быть реализованы программно в виде VNF.

Следует отметить разницу между похожими аббревиатурами: NFV – это технология, а VNF – это функция.

2. Система администрирования элементов EMS (Element Management System):

Система администрирования элементов EMS управляет работой VNF. Она отвечает за задание параметров, т.е. администрирование (Management) операций VNF, точно также, как физические сетевые элементы управляются от системы управления сетью NMS (Network Management System). Например, это может быть управление при отказах (fault management), управление производительностью (performance management), и другие функции системы управления сетью. Управление VNF от EMS осуществляется через закрытые (proprietary) интерфейсы, поэтому «референсная точка» между ними никак не обозначена. Скорее всего, в дальнейших релизах NFV эта точка будет детализирована. Одной VNF может соответствовать одна EMS, или одна EMS может управлять несколькими VNF. Кроме того, сама EMS также может представлять собой VNF, управляемую от другой EMS.

3. Менеджер VNFM (VNF Manager):

Менеджер VNFM управляет работой одной или нескольких VNF. Например, он управляет жизненным циклом функций VNF, т.е., запускает, обслуживает, и останавливает работу VNF. VNFM может выполнять те же функции, что и EMS, но через референсную точку, предложенную ETSI, в архитектуре NFV. Эта референсная точка называется VeNf-Vnfm. Что такое «референсная точка» (“reference point”), и чем она отличается от интерфейса, поясняется ниже.

4. Инфраструктура NFVI (Network Function Virtualization Infrastructure):

Инфраструктура виртуализации сетевых функций NFVI – это среда (инфраструктура), в которой работают VNF. Эта инфраструктура включает ресурсы физического оборудования, виртуальные ресурсы и уровень виртуализации, которые описаны ниже.

4.1 Виртуальные ресурсы: вычислительные, сетевые и ресурсы хранения:

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

4.2 Плоскость виртуализации (Virtualization Layer):

Плоскость виртуализации отвечает за абстрагирование физических ресурсов в виде виртуальных ресурсов. На этом уровне находится специальная программная платформа «гипервизор» (“Hypervisor”), которая производит отделение программных средств от аппаратных, то есть дает возможность запускать программы независимо от выбранного оборудования. Например, операционная система может работать на любом физическом сервере, который назначается для этой цели в данный момент.

4.3 Аппаратные ресурсы: вычислительные, сетевые и ресурсы хранения:

Это физическая часть инфраструктуры NFVI. Виртуальные ресурсы NFV запускаются на физических ресурсах NFVI. Это может быть любой стандартный коммутатор, или физический сервер, или устройство хранения и другие IT-ресурсы.

Предположим, что плоскость виртуализации отсутствует. В принципе, VNF могут работать непосредственно на выделенных физических ресурсах и быть жестко к ним привязаны. Однако, при этом мы не можем называть их ВИРТУАЛЬНЫМИ сетевыми функциями (VNF), в таком случае, их следует назвать PNF (Physical Network Functions). Это тоже возможно. Однако, в этом случае перенос виртуальной машины с одного физического сервера на другой (что часто бывает нужно, например, при смене местоположения пользователя виртуальной машины VM) необходимо будет выполнять вручную, а это сложно, долго и дорого.

5. Менеджер виртуализированной инфраструктуры VIM (Virtualized Infrastructure Manager):

Менеджер виртуализированной инфраструктуры VIM – это система администрирования (management) инфраструктуры NFVI. Он отвечает за управление и администрирование ресурсов NFVI внутри одного домена инфраструктуры оператора. Он также отвечает за сбор результатов измерений производительности и событий.

6. Оркестратор NFV (NFV Orchestrator):

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

Оркестратор NFV также отвечает за администрирование глобальных ресурсов NFVI. Например, он администрирует ресурсы вычислений, хранения и сети на нескольких менеджерах VIM на сети. Оркестратор не взаимодействует напрямую с VNF, а только через VNFM и VIM.

Например, имеется несколько функций VNF, из которых создана комплексная услуга. Например, это может быть виртуальная базовая станция или виртуальный домен опорной сети EPC. На сети эти элементы могут быть представлены оборудованием либо от одного, либо от разных вендоров. Тогда нужно создать комплексную (end to end) услугу с использованием нескольких VNF. При этом требуется оркестратор услуг для коммуникации со всеми VNF и создания комплексной услуги.

7. Система поддержки операций и бизнеса OSS/BSS (Operation Support System/Business Support System)

Система поддержки операций и бизнеса OSS/BSS – это физическая система OSS/BSS оператора. OSS занимается управлением сетью (network management), управлением при отказах (fault management), управлением конфигурацией (configuration management) и управлением услугами (service management). BSS отвечает за управление клиентами (customer management), управление продуктами (product management), управление заказами (order management) и др.

В архитектуре NFV, имеющаяся BSS/OSS оператора может быть интегрирована с системой NFV MANO, при помощи стандартных интерфейсов. Рассмотрим подсистему MANO более подробно, поскольку она является существенной частью архитектуры NFV.

MANO (NFV Management & Orchestration)

При знакомстве с технологией NFV MANO может возникнуть два вопроса.

В традиционных сетях связи существует только одна система управления NMS, которая может поддерживаться OSS. В сети NFV требуются еще несколько менеджеров: VIM Manager, VNF Manager и оркестратор. Есть также традиционная BSS. В итоге – пять разных административных систем. Не многовато ли?

Другая сложность в том, что описание архитектуры MANO в документе ETSI слишком расплывчато и в нем трудно разобраться, по крайней мере, новичку в технологиях виртуализации.

Тем не менее, нельзя игнорировать важность понимания модели MANO в описании ETSI, поскольку данная технология была рождена в недрах именно этой организации, которая сегодняшний день является единственной, кто работает над архитектурой и концепцией NFV. Есть еще, правда, описание архитектуры Domain 2.0, рожденное в недрах американской корпорации AT&T, однако, при ближайшем рассмотрении этой концепции внимательный читатель обнаружит практически полную аналогию с описанием NFV от европейской ETSI, только с использованием других наименований. Предубеждение прямодушных американцев перед высоколобыми европейцами – вещь общеизвестная. Поэтому стоит повнимательней изучить MANO путем понимания именно модели ETSI, что мы и попытаемся сделать.

Прежде всего, стоит задать вопрос: почему важно разбираться в модели MANO?

Во-первых, потому, что MANO является основой архитектуры NFV и понимание работы MANO прояснит всю картину NFV.

Во-вторых, если вы – оператор, это поможет разобраться и оценить решение NFV любого вендора, соотнося ее с моделью ETSI. Если вы – вендор, и ожидаете RFP от оператора, это поможет вам понять, что нужно включать в техническое предложение, а что – нет.

Чем занимается MANO можно понять из следующей картинки:

Рис. 4. Упрощенное представление о назначении MANO.

Что такое MANO в NFV?

MANO – сокращение от Management and Orchestration (администрирование и оркестрация).

Рис. 5. Подсистема MANO.

В состав MANO входят три вида менеджеров:

1. Менеджер виртуализированной инфраструктуры VIM (Virtualized Infrastructure Manager),
2. Менеджер VNF (VNFM),
3. Оркестратор NFV (NFVO),
4. Группа репозиториев.

В дополнение к четырем блокам, внутри MANO, есть также два блока вне ее: традиционная система управления сетевыми элементами EM (Element Management) (5) и традиционные системы OSS/BSS оператора (6). Хотя они не входят в состав MANO непосредственно, они обмениваются с ней информацией.

Начнем с низа.

1. VIM – менеджер виртуализированной инфраструктуры (Virtualized Infrastructure Manager):

VIM администрирует использование ресурсов в «одном домене» NFVI. Это могут быть либо физические ресурсы (серверы, хранилища, сетевые устройства), либо виртуальные ресурсы (виртуальные машины), а также программные ресурсы (гипервизоры). «Один домен» означает, что в архитектуре MANO могут быть несколько VIM, каждый из которых администрирует свой домен инфраструктуры NFVI.

Основные задачи VIM следующие:

• Управление жизненным циклом (lifecycle) виртуальных ресурсов в домене NFVI, то есть, созданием, поддержкой и прекращением работы виртуальных машин (VM) на физических ресурсах в домене NFVI.
• Учет (inventory) виртуальных машин и назначенных физических ресурсов для их работы.
• Управление FCAP (Fault, Configuration, Accounting, Performance) для программ и виртуальных ресурсов.
• Поддержка программируемых интерфейсов приложений (API) для верхнего уровня, через которые физические и виртуальные ресурсы предоставляются другим системам управления.

VIM и NFVI являются основным фокусом разработок организации OPNFV (www.opnfv.org). Цель работы OPNFV разработка открытой программной платформы для ускорения внедрения новых продуктов  и услуг NFV, а также средств предоставления NFVI, VIM и открытых API для других систем NFV.

2. VNFM – Менеджер виртуальных сетевых функций (Virtual Network Function Manager)

То, чем VIM является по отношению к NFVI, тем же самым VNFM является по отношению к функциям VNF. То есть, VNFM управляет функциями VNF, как виртуальными сетевыми элементами, например, это может быть функция виртуального маршрутизатора Router VNF, виртуального коммутатора Switch VNF и т.д.

В частности, VNFM занимается следующим:

• Определяет жизненный цикл VNF: создает, поддерживает и удаляет виртуальные сетевые элементы VNF (которые устанавливаются на виртуальных машинах VM, создаваемых и управляемых VIM).
• Отвечает за администрирование FCAP (Fault, Configuration, Accounting, Performance) для сетевых элементов и VNF.
• Масштабирует функции VNF, что выражается в росте или снижении использования процессоров физического сервера, на котором «подняты» VNF, выделенных ресурсов хранения, а также ресурсов коммутационной сети.

Несколько менеджеров VNFM, управляющих различными VNF, могут работать одновременно   или один VNFM может управлять несколькими VNF.

3. NFVO – Оркестратор виртуализации сетевых функций (NFV Orchestrator)

Как было отмечено в разделе 1, может быть несколько VIM, управляющих несколькими доменами NFVI. При этом возникают следующие вопросы:

1. Кто управляет и координирует работу ресурсов, принадлежащих различным VIM, когда в одной «точке присутствия» РоР (Point of Presence), работают несколько VIM? Или когда один VIM работает в нескольких РоР? Точно так же, как было отмечено в разделе 2, может быть несколько VNFM, управляющих многими VNF. Это порождает еще один вопрос:
2. Кто управляет и координирует создание комплексных услуг, с использованием нескольких VNF из разных доменов VNFM?

Для решения этих задач и создан оркестратор NFVO.

Оркестрация ресурсов

NFVO координирует, авторизует, занимает и высвобождает ресурсы NFVI в одной или многих РоР, при помощи VIM напрямую, или через восходящие интерфейсы API. Таким образом, решается 1-й вопрос.

Оркестрация услуг

Оркестрация услуг решает 2-й вопрос, т.е. создание комплексных услуг среди различных VNF (которые могут управляться от различных VNFM). Это делается следующим образом:

• Оркестратор услуг создаёт комплексную услугу из разных VNF, путем координации соответствующих VNFM, поэтому нет необходимости в непосредственном взаимодействии с отдельными VNF. Например, это может быть создание услуги между виртуальной базовой станцией одного вендора и виртуальным узлом опорной сети EPC другого вендора.
• В процессе оркестрации услуг по мере необходимости могут запускаться новые VNFM.
• Производится управление топологией сетевых услуг, также называемых сетевыми графами VNF (VNF Forwarding Graphs).

Образно можно представить NFVO в виде «клея», который соединяет друг с другом и создает комплексные услуги и осуществляет координацию ресурсов для таких «склеек».

4. Репозитории

Очень важно понимать назначение репозиториев (таких как файлы и списки), которые хранят различную информацию в NFV MANO. Есть четыре типа репозиториев:

Каталог сетевых услуг (network services, NS Catalog):

Это каталог (список) используемых сетевых услуг. В нем содержатся шаблоны развертывания для сетевых услуг.

Каталог VNF (VNF Catalog):

Каталог VNF – это репозиторий для всех используемых дескрипторов VNF (VNFD, VNF Descriptor).

VNFD – это шаблон развертывания, который описывает сценарий развёртывания и работы VNF. Его использует менеджер VNFM в процессе запуска и управления жизненным циклом функции VNF. Информация, содержащаяся в VNFD, также используется в оркестраторе NFVO для управления и оркестрации сетевых услуг и виртуализированных ресурсов в NFVI.

Список экземпляров NFV (NFV Instances):

Список экземпляров NFV содержит все детали о примерах (экземплярах) сетевых услуг и соответствующих экземплярах VNF.

Ресурсы инфраструктуры NFV (NFVI):

Это список ресурсов NFVI, используемых для формирования услуг.

Следующие две системы управления не являются частью NFV MANO, но они обмениваются с ней информацией, поэтому опишем и их.

5. Управление элементами EM (Element Management):

Система управления элементами EM формально не входит в MANO, но если она присутствует, то ей нужна координация с VNFM, поэтому важно знать о том, что делает система EM.

EM отвечает за управление FCAPS (Fault, Configuration, Accounting, Performance and Security management). Как отмечалось выше, VNFM также это делает. Однако, в отличие от VNFM, EM делает это через закрытые интерфейсы с VNF. Тем не менее, EM должна обмениваться информацией с VNFM через открытый интерфейс, или референсную точку (Ve-Vnfm-em). Система ЕМ может работать с виртуализированными элементами вместе с VNFM для выполнения функций, которые требуют обмена информацией о ресурсах NFVI, ассоциированных с VNF.

6. OSS/BSS:

Система OSS/BSS включает набор систем и приложений, которые оператор использует для управления и поддержки бизнеса. NFV должна работать вместе с ней, а не автономно.

В принципе, можно управлять функциями VNF и инфраструктурой NFVI от OSS/BSS непосредственно, расширением существующего функционала OSS/BSS, но это выливается в необходимость развертывания собственных (закрытых) реализаций вендора, что ведет к «вендорозависимости» оператора. По крайней мере, интерфейсы между EM и VNF пока не определены в ETSI. Поскольку NFV представляет собой открытую платформу, то управление объектами NFV через открытые референсные точки (как в MANO) является более рациональным подходом.

Существующие OSS/BBS, однако, могут предоставить для NFV MANO дополнительные функции, если они не поддерживаются в конкретной реализации NFV MANO. Такое предоставление осуществляется через стандартные открытые интерфейсы (Or-Ma-NFVO) между NFV MANO и существующими OSS/BSS.

7. Референсные точки:

Ну и наконец, стоит поговорить об открытых референсных точках.

MANO имеет множество референсных точек, например Or-Vi, NF-Vi, Or-Vnfm и др. Почему они называются именно «референсными точками», а не интерфейсами?

Термин «интерфейс» подразумевает двусторонний обмен сигнальными сообщениями между объектами, которые представляют собой законченные либо физические, либо программные объекты. Референсная точка, в отличие от интерфейса, определяет взаимодействие между функциональными архитектурными блоками, которые сами состоят из законченных программно-аппаратных объектов. А поскольку в концепции MANO мы оперируем именно функциональными блоками, а не объектами, поэтому вместо слова «интерфейс» используется термин «референсная точка» (“reference point”).

Вот вкратце все, то нужно знать об NFV MANO для первоначального знакомства.

Соотношения между SDN и NFV

Существует некоторая путаница в понимании соотношений между SDN и NFV. Иногда между ними ставят чуть ли не знак равенства. Иногда, напротив, утверждается, что между этими технологиями нет связи. Часто встречается мнение, что SDN необходима для NFV. Ни одно из этих мнений не верно на 100%.

Соотношения SDN и NFV, а также технологий открытых протоколов (например, OpenFlow), можно представить на следующей диаграмме.

Рис. 6. Соотношения между NFV, SDN и открытыми протоколами.

• Цели NFV могут быть достигнуты и без использования механизмов SDN, средствами, которые уже имеются во многих дата-центрах. Однако, разделение плоскостей управления и пересылки данных используемое в SDN, может увеличить производительность, упростить взаимодействие между различными платформами, а также операционные и обслуживающие процедуры.
• NFV может обеспечить SDN инфраструктурой, на которой работает программное обеспечение SDN. Более того, цели NFV близки к целям SDN в части использования обычных стандартных серверов и коммутаторов.
• Поэтому NFV является основной архитектурой для эволюции мобильных сетей, а в некоторых сценариях также может использоваться и SDN.

Преимущества SDN и NFV для операторов связи

• Упрощение и централизация управления, администрирования и обслуживания (OAM), повышение эффективности бизнеса, снижение операционных затрат.
• Более быстрое развертывание новых услуг, снижение показателя ТТМ (Time-To-Market).
• Создание новых рынков путем перехода к облачным услугам:
  • Сдвиг операторского бизнеса от предоставления каналов связи к предоставлению облачных услуг.
  • Операторы могут предоставлять инфраструктуру дата-центров как услугу (IaaS) с интеграцией ресурсов каналов связи и облачных IT-ресурсов.
• Более эффективное использование ресурсов телекоммуникационной сети путем централизации управления ресурсами, виртуализации ресурсов дата-центров.

Как SDN, так и NFV, используют облачные и Интернет-технологии для реконструкции сетей операторов связи. SDN позволяет конфигурировать плоскость передачи данных программным путем. NFV позволяет задавать роли виртуальных сетевых устройств также программным путем. В будущем, все сетевые элементы будут развертываться в совместно используемой облачной архитектуре дата-центров. Сетевые сценарии будут в ней храниться и развертываться согласно требованиям приложений верхнего уровня. Это дает возможность быстро внедрять и развертывать новые телекоммуникационные приложения и бизнесы.

Поэтому утверждение о том, что «бизнес операторов связи уходит в облако» является вполне справедливым.

В обобщённом виде облачную архитектуру сети оператора связи на базе SDN/NFV можно представить так:

Рис. 7. Обобщенная облачная архитектура сети оператора связи на основе NFV/SDN.

Проблемы развития NFV/SDN

Основной проблемой развития NFV/SDN и внедрения этих технологий на сетях операторов и сервис-провайдеров являются большой объем инвестиций в инфраструктуру дата-центров.

По оценке компании Infonetics, до 2018 года затраты на развитие NFV/SDN будут подразделяться следующим образом:

Рис. 8. Затраты операторов на оборудование и ПО для NFV и SDN.

Из рисунка видно, что львиная доля затрат все равно приходится на оборудование для дата-центров и их инфраструктуры. На оборудование и ПО непосредственно для NFV и MANO приходится около 36% затрат. Однако, если пойти по пути развития традиционной (аппаратной) сетевой инфраструктуры (IMS, EPC, OSS/BSS), то затраты будут в разы, если не на порядки, больше.

Показательны результаты исследования, проведенного агентством Heavy Reading на сети германского оператора Deutsche Telecom.

Рис. 9. Оценочное сравнение стоимости и производительности при различных вариантах виртуализации и на специализированном оборудовании.

Именно поэтому и внедряются технологии виртуализации на основе стандартных (commodity) серверов и систем хранения, центров обработки данных, на которых можно виртуализировать сетевую инфраструктуру, как показано на рис. 9. Такой подход дает следующие преимущества:

• Стандартизация оборудования. Применяются не специализированные устройства, а стандартные, которые при массовом производстве и использовании стоят значительно дешевле.
• Унификация процессов обслуживания, что дает значительную экономию операционных затрат.
• Сокращение сроков ввода новых сервисов и приложений от месяцев до дней.
• Гибкость использования ресурсов. Ресурсы традиционной (аппаратной) сети IMS/EPC часто бывают либо недогруженными, либо перегруженными, поскольку ситуация на сети постоянно меняется. С использованием NFV оператор может инициировать, использовать и затем удалять ровно столько виртуальных сетевых элементов, сколько ему нужно в данный момент.

К факторам, сдерживающим развитие NFV/SDN, можно отнести следующие:

• Стандарты и совместимость. Стандарты NFV еще не до конца разработаны, что привносит разнобой в вендорные реализации, вызывает проблемы совместимости реализаций NFV различных вендоров, а также риски в стратегиях операторов и сервис-провайдеров.
• Техническая зрелость. До ноября 2014 г. большинство новых NFV-технологий находились в состоянии тестирования.
• Неясность ценности для бизнеса. Первые коммерческие реализации NFV появились только в 2015 г. Ценность для бизнеса от реализации NFV пока лежит в теоретической плоскости и реальных подтверждающих кейсов все еще недостаточно.
• Проблемы миграции. Миграция традиционной сетевой инфраструктуры к архитектуре NFV и/или SDN является сложной и многоступенчатой задачей. В настоящее время операторы и вендоры оборудования пока не имеют систематического опыта подобных переходов и убедительных «историй успеха».
• Проблемы организационной структуры. В настоящий момент в структуре практически любого оператора связи, департамент информационный технологий (IT) и технический департамент сети связи оператора (СТ) организационно разделены. Между тем, NFV и SDN относятся именно к сфере IT. Поэтому, требуется не только трансформация базовой сети оператора, но и его организационной структуры. А это довольно нетривиальная и болезненная задача. Однако, после ее завершения, как внутренняя корпоративная сеть оператора, так и его базовая сеть, будут иметь единую инфраструктуру, что приведет как снижению накладных расходов, так и к повышению эффективности бизнеса.

Примеры использования технологий SDN и NFV операторами связи.

Некоторые операторы мира, которые приступили к трансформации на основе NFV или имеет планы такой трансформации показаны на рисунке:

Рис. 10. Некоторые из глобальных операторов, реализующих или разрабатывающих планы трансформации SDN/NFV.

Эти компании могут быть разделены на три категории:

• «Лидеры»: имеют хорошо разработанные концепцию и план трансформации и уже решительно взявшиеся за их осуществление.
• «Последователи»: на основе опыта лидеров осуществляют или разрабатывают собственные планы трансформации.
• «Осознавшие»: активно разрабатывают концепции и планы трансформации и продолжают исследования.

«Лидеры».

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

Таблица 2. Лидеры в проектах SDN/NFV.

• Компания AT&T: «Стать супер-оператором» (Super Carrier).

Компания AT&T разработала собственную концепцию трансформации NFV, которая несколько отличается от ETSI, под названием Domain 2.0. Ее основные принципы сходны с реализацией ETSI:

• Преобразование бизнес модели: от бизнеса, определяемого оператором («Carrier-defined Business») к бизнесу, определяемому пользователем («User-defined Business»).
• Сеть: От сетевых узлов к дата-центрам.
• Поставщики: сотрудничество со стартапами, которые будут адаптировать свои приложения для решений AT&T.
• Партнеры: сотрудничество с разработчиками ПО для различных бизнес-сценариев.

СИ – системная интеграция; ПО – программное обеспечени; COTS – Commercial Off The Shelf (поставки стандартного IT-оборудования)

Рис. 11. Трансформация бизнес-модели оператора AT&T.

• Telefonica: Цифровой экономный оператор (Digital Telco = Lean+Digital)

Основные принципы программы трансформации Digital Telco – следующие:

• Перемещение сетевых функций и системы операций в облако.
• Основные свойства:
  • Открытость
  • Распределенность функций, с унификацией сервисов в облаке дата-центров
  • Эластичность и быстрое предоставление комплексных услуг при помощи NFV
  • Одновременное использования многими арендаторами ресурсов (Multi-tenancy)
  • Гибридная поддержка бизнеса (повторное использование услуг во многих приложениях)
  • Сокращение времени вывода услуг на рынок (TTM), снижение операционных расходов (OPEX) и повышение общей эффективности.

Рис. 12. Принципы облачной трансформации инфраструктуры оператора Telefonica

В программе Lean+Digital, «Digital» означает, что доля доходов от цифровых услуг облачной платформы составит 10% к 2016 г., против 5% в 2013 г. «Lean» означает экономию затрат CAPEX & OPEX около € 1.5 млрд. с 2013 по 2016 г. Экономия достигается за счет следующих факторов:

• Унификация инфраструктуры: собственная ИТ-система оператора (IT), телекоммуникационная сеть (CT), публичное облако (Public Cloud), для услуг пользователей и частное облако (Private Cloud), для собственной корпоративной сети и корпоративных клиентов, теперь работают на основе единой инфраструктуре распределенных дата-центров.
• IT-инфраструктура становится распределенной по многим хабам. BSS всех филиалов оператора по всему миру становится стандартной.
• Экономия ТСО примерно в 400 млн. € только за счет использования NFV.
• Значительное повышение гибкости сети: если требуется перенаправление потоков трафика и перераспределение сетевых ресурсов по различным участка сети, это может быть выполнено быстро и с минимальными затратами.
• Процесс управления и обслуживания сети становится более простым и автоматизированным.
• ИТ-платформа для корпоративной сети (IT) и базовой сети (Сore) оператора становится унифицированной, поэтому данный проект получил название UNICA.

• Vodafone: сеть мирового класса с разнообразными услугами.

 

Цель трансформации Vodafone – построить «вездесущую» (ubiquitous) сеть с разнообразными услугами.

Рис. 13. Услуги сети Vodafone

Принципы трансформации сети Vodafone:

• «Вездесущий» широкополосный доступ (Ubiquitous Broadband)
• Конвергентная архитектура ИКТ с предоставлением услуг связи (СТ) и ИТ-услуг (IT) на базе единого облака.
• Использование SDN для трансформации базовой IP-сети.
• Монетизация данных сети и пользователей при помощи аналитики «больших данных».

Решение безопасности для виртуализированной архитектуры и гетерогенных М2М-устройств.

Рис. 14. Архитектура платформы SDN/NFV компании Vodafone.

Этапы проекта NFV оператора Vodafone

1. 1 квартал 2015 г.: построение ЦОД для развертывания SDN. Более быстрое развертывание сетевых сервисов: межсетевых экранов (Firewall), маршрутизаторов, балансировщиков нагрузки.
2. 1-2 кв. 2015 г.: внедрение технологии Gi-LAN для создания комплексных услуг SDN. Гибкое управление трафиком в зависимости от требований услуг.
3. 2-3 кв. 2015 г.: внедрение услуг IP VPN для предприятий на базе SDN.
4. 4 кв. 2015 г.: построение масштабной виртуальной сети IP WAN на базе SDN.

• Проект Terastream компании Deutsche Telekom.

Компания Deutsche Telekom строит новую сеть с использованием SDN, покрывающую 15 стран Европы. Сеть будет содержать 3 главных дата-центра и в Польше, Венгрии и Греции, где будет развёрнута централизованная OSS для всей сети Deutsche Telekom и реализована схема катастрофоустойчивости. Кроме того в каждой из 15 стран также будут развернуты дата-центры для лучшего кэширования и ускорения работы услуг.

Рис. 15. Схема сети SDN/NFV компании Deutsche Telekom.

Сеть будет иметь плоскую архитектуру на базе терабитных маршрутизаторов с интеграцией оптической передачи с целью упрощения архитектуры. В конце 2015 года ожидается запуск услуг IPTV с разрешением 4К, на основе которых планируется трансляция игр кубка УЕФА в апреле 2016 года.

«Последователи»

К «последователям» (followers) относятся те операторы, которые пока не имеют проработанной стратегии трансформации SDN/NFV и изучают опыт ведущих операторов (leaders).

Как правило, такие компании приглашают ведущих вендоров для того, чтобы они поделились их опытом развертывания проектов SDN/NFV, издают запросы RFI (Request For Information) об архитектуре NFV, но обычно не конкретизируют сценарии трансформации, а также могут проводить тестирование пилотных проектов с прицелом на будущее.

К таким операторам, например, можно отнести кувейтскую компанию Ooredoo, которая имеет проект UNIFY, очень похожий на проект UNICA компании Telefonica.

«Осознавшие»

К категории «осознавших» (bewildered) можно, например, отнести компанию China Telecom, которая пришла к выводу о насущной необходимости перехода к NFV, но еще не сформировала окончательного решения о путях такой трансформации. Таким компаниям, как правило требуются услуги бизнес-консультирования, чтобы экономически оценить затраты и экономию, доходы и потенциальные риски NFV-трансформации.

В мае 2015 г. портал Heavy Reading провел опрос среди 79 операторов связи мира об их планах развертывания сетей SDN/NFV. Результаты распределились следующим образом: 54% приступили к исследованиям в области NFV, 17% находятся на стадии тестирования возможностей PoC (Proof-of-Concept), 19% разворачивают опытные зоны, а 10% уже приступили к развертыванию NFV. Не заинтересованных в NFV не нашлось (0%).

Рис. 16. Результаты исследования компании Heavy Reading о состоянии проектов SDN/NFV среди 79 опрошенных операторов связи по состоянию на май 2105 г.

Состояние разработок и стандартизации NFV

ETSI. В настоящее время прием новых вкладов по NFV заморожен. Различные рабочие группы обмениваются информацией. Фаза 2 разработки стандартов NFV, стартовавшая в начале 2015г. пока не имеет четко очерченного масштаба работ.

Openstack. В настоящее время Openstack является одним из главных «центров притяжения» разработок в области SDN/NFV, достаточно сказать, что число участников саммита OpenStack в Атланте (шт. Джорджия, США) превысило 4500 чел. В апреле 2015 года была представлена новая версия программной платформы OpenStack управления облачными системами под названием Kilo (предыдущая называлась Juno). Однако, в широком распространении платформы OpenStack пока имеются много проблем, заключающихся прежде всего в том, что есть определённый разрыв между тем, что от нее ожидается и ее реальными возможностями.

Open Daylight. OpenDaylight – многопротокольная платформа управления  инфраструктурой SDN для гетерогенных сетей (т.е. содержащих оборудование разных поставщиков).  Проект разрабатывается под эгидой Linux Foundation при участии компаний IBM, Juniper Networks, Cisco, Red Hat, VMware, Citrix, Ericsson, Microsoft и NEC. Первый релиз платформы был выпущен в феврале 2014 года. Сейчас выпущен третий релиз, который называется Lithium.

ONOS. ONOS (Open Network Operating System) – проект компании Open Networking Lab (ON.LAB). Цель проекта – разработка сетевой операционной системы с открытым кодом для создания реальных сетей SDN.

OPNFV. В сентябре 2014 г. некоммерческая организация Linux Foundation объявила о создании модельной платформы с открытым кодом для разработки NFV-систем OPNFV  (Open Platform for NFV). Цель OPNFV – предоставление интегрированной платформы для операторов связи, при помощи которой они бы могли вводить новые услуги и продукты более быстро и с меньшими затратами. OPNFV намеревается тесно сотрудничать с ETSI и другими альянсами в деле разработки открытых стандартов. Основателями OPNFV являются AT&T, Brocade, China Mobile, Cisco, Dell, Ericsson, HP, Huawei, IBM, Intel, Juniper, NEC, Nokia , NTT DOCOMO, Red Hat, Telecom Italia, и Vodafone, а также (серебряный уровень): 6WIND, Alcatel-Lucent, ARM, CableLabs, Cavium, CenturyLink, Ciena, ClearPath, ConteXtream, Coriant, Cyan, Dorado Software, Ixia, Metaswitch Networks, Mirantis, Orange, Sandvine,Sprint, и Wind River.

Работы по совершенствованию SDN ведутся также в организациях ONF (Open Network Foundation), и IETF.

Выводы

Какие выводы из сказанного можно сделать?

1. Перспективы. NFV – технология будущего операторских сетей, и в этом утверждении нет никакого рекламного «хайпинга» или желания «впарить» новую технологию со стороны вендоров, чтобы увеличить свои объемы продаж. Напротив, телеком-вендоры сами находятся в затруднительной ситуации в связи с тотальным технологическим переворотом в отрасли, поскольку они будут вынуждены полностью переоснащать свои производственные мощности и переориентировать свои R&D-центры, а также в связи с конкурентным давлением со стороны ИТ-вендоров. Переход к SDN/NFV можно сравнить только с переходом от аналоговых телефонных станций к цифровым в начале 70-х годов, когда телеком-вендорам понадобилось такая же переориентация и такое же переоснащение. В то время также было много дискуссий на тему о том, «чем “цифра” лучше?». Похожую параллель можно провести относительно перехода от парового двигателя к двигателю внутреннего сгорания, от луков, стрел и мечей к огнестрельному оружию, или от конницы к танкам. Цели – одни и те же, средства – разные.

2. Преимущества. В чем преимущества и выгоды от применения NFV для операторов? Можно указать лишь основные из них:
   • Оперативность вывода новых услуг на рынок. Вместо того, чтобы проводить маркетинговые исследования, строить новую аппаратную платформу для новых сервисов, проводить тесты, делать пилотные проекты, на что обычно уходят месяцы, с NFV можно «конструировать» новые услуги программно, в дата-центрах, там же их тестировать и быстро выводить на рынок. В случае неудачи или невостребованности новой услуги (что иногда случается при просчетах маркетинга) цена неудачи будет минимальной.
   • Сокращение капитальных затрат. Реализация сетевых элементов на стандартных (commodity) серверах в дата-центрах при массовом развертывании будет обходиться значительно дешевле чем на выделенном оборудовании.
   • Сокращение операционных затрат. Обслуживание стандартных серверов в дата-центрах производится сертифицированным ИТ-персоналом, которому для работы с NFV лишь требуется пройти курсы повышения квалификации, а не специализированными инженерами по аппаратным платформам операторских сетей, требуемая квалификация которых должна быть гораздо выше, а специализация – уже. Кроме того, численность требуемого персонала также сокращается, по тем же причинам.
   • Гибкость использования ресурсов. При небольшом трафике вызовов задействуется минимальное количество виртуальных машин на серверах, при росте трафика, автоматически подключаются новые виртуальные машины, на которых работают VNF для эмуляции функций сетевого оборудования. В случае аппаратной реализации, ресурсы оборудования будут использоваться нерационально, поскольку ресурсы всегда рассчитываются на максимальный трафик в сети, а такие ситуации случаются лишь в часы максимальной нагрузки. В другое время оборудование (в случае аппаратной реализации) остается недогруженным.

3. Проблемы. Нельзя сказать, что переход на технологии SDN и NFV в сетях операторов будет гладким и безболезненным. Здесь также можно провести аналогию с переходом на цифровые станции от аналоговых. Этот процесс занял годы и даже десятилетия. Многие помнят медленный рост «процента цифровизации» для операторских сетей. Точно также и рост «NFV-зации» операторских сетей также будет постепенным. По мере выработки срока службы или морального устаревания аппаратных платформ IMS/EPC, сетей агрегации и доступа, будет происходить процесс постепенного перехода на «облачные» платформы SDN/NFV, которые будут реализовывать виртуализацию vIMS/vEPC. Основная проблема, которая здесь будет возникать – наличие собственных дата-центров у операторов, или доступность дата-центров у облачных провайдеров для аутсорсинга ресурсов стандартных серверов и систем хранения данных. Рисунок ниже показывает, насколько данная проблема актуальна для российских операторов связи:

Рис. 17. Площадь дата-центров у операторов связи в различных частях мира по данным аналитической компании Ovum на середину 2014 г.

Как видим, по наличию операторских дата-центров, Россия (в составе Eastern Europe and CIS) находится на одном из последних мест в мире (здесь Asia-Pacific – это Юго-Восточная Азия, Малайзия, Австралия и пр., но не азиатская часть России!). Поэтому и ожидать проникновения технологий NFV в России следует в последнюю очередь.

*  *  *

В целом, области и сценарии использования SDN и NFV можно подразделить следующим образом:

Технология	SDN	NFV
Основная функция	Разделение плоскости управления и плоскости пересылки данных, таким образом, что конфигурация сети становится гибко программируемой.	Перемещает сетевые функции из специализированных отраслевых устройств в стандартные промышленные устройства.
Основные сценарии	Корпоративные сети больших предприятий, университетов, дата-центры, облачные платформы	Сети телекоммуникационных операторов и сервис-провайдеров
Целевые устройства	Коммерческие серверы и коммутаторы	Специализированные серверы и коммутаторы
Основное применение	Диспетчеризация облачных ресурсов и сетей	Виртуализация сетевых устройств операторов связи и обеспечение SLA
Основной протокол	OpenFlow	Нет
Организация стандартизации	ONF	ETSI