Este artículo ha sido aceptado para su publicación en un número futuro de esta revista, pero no ha sido editado en su totalidad.

El contenido puede cambiar antes de su publicación

final. Información de citas: DOI 10.1109/COMST.2015.2477041, IEEE Communications Surveys & Tutorials
ENCUESTAS Y TUTORIALES DE Suscríbete a DeepL Pro para poder editar este documento. 1
COMUNICACIONES DEL IEEE
Entra en www.DeepL.com/pro para más información.

Virtualización de la función de red: Estado del

arte y desafíos de la investigación
Rashid Mijumbi, Joan Serrat, Juan-Luis Gorricho, Niels Bouten, Filip De Turck, Raouf Boutaba

La virtualización de la función de red abstracta (NFV) ha aprendido

atraído una atención considerable tanto de la industria como del
mundo académico como un cambio importante en la prestación R. Mijumbi, J. Serrat y J.L. Gorricho trabajan en el Departamento de Ingeniería
de servicios de telecomunicaciones. Al desvincular las Funciones de Redes de la Universidad Politécnica de Cataluña, 08034 Barcelona, España.
de Red (NF) de los dispositivos físicos en los que se ejecutan, la N. Bouten y F. De Turck trabajan en el Departamento de Tecnología de la
NFV tiene el potencial de conducir a reducciones significativas de Información de la Universidad de Gante - iMinds, B-9050 Gante, Bélgica.
los gastos de explotación (OPEX) y de los gastos de capital R. Boutaba trabaja en la Escuela de Informática D.R. Cheriton, Universidad de
Waterloo, Waterloo, Ontario, N2L 3G1, Canadá.
(CAPEX) y facilitar el despliegue de nuevos servicios con mayor
agilidad y rapidez. El paradigma del NFV está todavía en sus
comienzos y existe un amplio espectro de oportunidades para que
la comunidad de investigadores desarrolle nuevas arquitecturas,
sistemas y aplicaciones, y evalúe alternativas y compensaciones
en el desarrollo de tecnologías para su despliegue exitoso. En este
documento, después de discutir el NFV y su relación con los
campos complementarios de Software Defined Networking
(SDN) y la computación en nube, estudiamos el estado de la
técnica en NFV, e identificamos direcciones de investigación
prometedoras en esta área. También hacemos un repaso de los
proyectos clave de NFV, los esfuerzos de estandarización, las
primeras implementaciones, los casos de uso y los productos
comerciales.
Índice de términos: Virtualización de la función de red,
funciones de red virtual, Internet del futuro, red definida por
software, computación en nube.

I. INTRODUCCIÓN
La prestación de servicios en la industria de las
telecomunicaciones se ha basado tradicionalmente en que los
operadores de redes desplieguen dispositivos y equipos físicos
patentados para cada función que forma parte de un servicio
determinado. Además, los componentes del servicio tienen un
encadenamiento y/o ordenamiento estricto que debe reflejarse
en la topología de la red y en la localización de los elementos
del servicio. Esto, unido a los requisitos de alta calidad,
estabilidad y estricta observancia de los protocolos, ha dado
lugar a largos ciclos de producto, a una agilidad de servicio
muy baja y a una gran dependencia del equipo especializado.
Sin embargo, siguen aumentando las necesidades de los
usuarios de servicios más diversos y nuevos (de corta
duración) con altas tasas de datos. Por consiguiente, los
proveedores de servicios de telecomunicaciones (PST) deben,
en consecuencia y de manera continua, adquirir, almacenar y
hacer funcionar nuevo equipo físico. Esto no sólo requiere
competencias elevadas y rápidamente cambiantes para los
técnicos que operan y gestionan este equipo, sino que también
requiere despliegues densos de equipo de red, como las
estaciones de base. Todo esto conduce a un alto CAPEX y
OPEX para los TSP [1], [2].
Además, incluso con estas altas demandas de los clientes, el
aumento resultante de los costos de capital y operacionales no
puede traducirse en mayores cuotas de suscripción, ya que los
proveedores de servicios de telecomunicaciones han
1553-877X (c) 2015 IEEE. El uso personal está permitido, pero la reedición/redistribución requiere el permiso del
IEEE. Véase http://www.ieee.org/publications_standards/publications/rights/index.html para más
Este artículo ha sido aceptado para su publicación en un número futuro de esta revista, pero no ha sido editado en su totalidad. El contenido puede cambiar antes de su publicación
final. Información de citas: DOI 10.1109/COMST.2015.2477041, IEEE Communications Surveys & Tutorials
ENCUESTAS Y TUTORIALES DE
COMUNICACIONES DEL IEEE
2
que debido a la gran competencia, tanto entre ellos como de
los servicios que se prestan por encima de sus canales de
datos, el aumento de los precios sólo conduce a la pérdida
de clientes. Por lo tanto, los proveedores de servicios de
telecomunicaciones se han visto obligados a encontrar
formas de construir redes más dinámicas y conscientes de
los servicios con el objetivo de reducir los ciclos de los
productos, los gastos de explotación y de capital y mejorar
la agilidad de los servicios.
NFV [3], [4] se ha propuesto como una forma de abordar
estos retos aprovechando la tecnología de virtualización
para ofrecer una nueva forma de diseñar, desplegar y
gestionar los servicios de red. La idea principal de NFV es
la disociación de los equipos de red físicos de las funciones
que se ejecutan en ellos. Esto significa que una función de
red -como un cortafuegos- puede ser enviada a un TSP
como una instancia de software simple. Esto permite la
consolidación de muchos tipos de equipos de red en
servidores de gran volumen, conmutadores y
almacenamiento, que podrían estar ubicados en centros de
datos, nodos de red distribuidos y en las instalaciones del
usuario final. De esta manera, un servicio determinado
puede descomponerse en un conjunto de Funciones de
Red Virtual (VNFs), que podrían luego implementarse en
un software que se ejecuta en uno o más servidores físicos
estándar de la industria. Las VNF pueden entonces
reubicarse e instanciarse en diferentes lugares de la red (por
ejemplo, con el fin de introducir un servicio dirigido a los
clientes en una ubicación geográfica determinada) sin que sea
necesario adquirir e instalar nuevo equipo informático.
La NFV promete a los proveedores de servicios de
telecomunicaciones una mayor flexibilidad para abrir aún
más sus capacidades y servicios de red a los usuarios y a
otros servicios, y la capacidad de desplegar o prestar apoyo
a nuevos servicios de red de manera más rápida y barata a
fin de lograr una mayor agilidad en el servicio. Para lograr
estos beneficios, la NFV allana el camino a una serie de
diferencias en la forma en que se realiza la prestación de
servicios de red en comparación con la práctica actual. En
resumen, estas diferencias son las siguientes [5]:
Desacoplando el software del hardware. Como el
elemento de la red ya no es una composición de entidades
integradas de hardware y software, la evolución de ambos
es independiente de cada uno. Esto permite separar los
plazos de desarrollo y mantenimiento del software y el
hardware.
Despliegue flexible de la función de red. La separación
del software del hardware ayuda a reasignar y compartir los
recursos de la infraestructura, por lo que juntos, el hardware
y el software, pueden realizar diferentes funciones en
distintos momentos. Esto ayuda a los operadores de red a
desplegar nuevos servicios de red más rápidamente sobre la
misma plataforma física. Por lo tanto, los componentes
pueden instanciarse en cualquier dispositivo habilitado para
NFV en la red y sus conexiones pueden establecerse de
manera flexible.
Escala dinámica. El desacoplamiento de la funcionalidad
de la función de la red en componentes de software
instantáneos pro-

1553-877X (c) 2015 IEEE. El uso personal está permitido, pero la reedición/redistribución requiere el permiso del
IEEE. Véase http://www.ieee.org/publications_standards/publications/rights/index.html para más
 IP pública... Servicio
Propiedad intelectual privada Propiedad
Servicios s
Servicios intelectual
Públicos
privada
de
Servicios
Propied
Proveedor de servicios ad
Intelect
ual
El router del núcleo

Proveedor de
servicios
vCore Router
Sitios de clientes Funciones virtuales
CPE 1CPE 2
EnrutamientoEnrutamiento vRouting UPnP

vNAT vUPnP
RadioRadio vFirewall

UPnPUPnP

UPnPUPnP
FirewallFirewall

NAT NAT Sitios de clientes

Modem Modem
CPE 1 CPE 2CPE 3CPE N
Cambiar Cambiar

Radio
Radio Radio Radio

Cambiar Cambiar Cambia

... Cambia
r r

Modem Modem Modem Modem

Fig. 1. Implementaciones tradicionales de CPE Fig. 2. Posible implementación de CPE con NFV

ofrece una mayor flexibilidad para escalar el rendimiento real mundo escribieron conjuntamente un libro blanco [4] en el que
de la FNV de una forma más dinámica y con una granularidad se pedía una acción industrial y de investigación. En noviembre
más fina, por ejemplo, según el tráfico real para el que el de 2012 siete de estos operadores (AT&T, BT, Deutsche
operador de la red necesita suministrar capacidad. Telekom, Orange, Telecom Italia, Tele- fonica y Verizon)
Cabe señalar que el concepto general de desvincular las FN seleccionaron al Instituto Europeo de Normas de
de los equipos dedicados no requiere necesariamente la Telecomunicaciones (ETSI)[6] para que fuera la sede del Grupo
virtualización de los recursos. Esto significa que los de Especificaciones Industriales para NFV (ETSI ISG NFV)1.
proveedores de servicios técnicos podrían seguir comprando o
1En
desarrollando programas informáticos (NF) y ejecutarlos en el resto de este documento, las siglas ETSI y ETSI ISG NFV se utilizan
como sinónimos.
máquinas físicas. La diferencia es que estos NF tendrían que
ser capaces de ejecutarse en servidores de productos básicos.
Sin embargo, los beneficios (como la flexibilidad, el
escalamiento dinámico de los recursos, la eficiencia
energética) que se derivan de la ejecución de estas funciones
en recursos virtualizados son puntos de venta muy fuertes del
NFV. Huelga decir que también es posible tener escenarios
híbridos en los que las funciones que se ejecutan en recursos
virtualizados coexisten con las que se ejecutan en recursos
físicos. Esos escenarios híbridos pueden ser importantes en la
transición hacia el NFV.

A. Historia de la virtualización de la función de red

El concepto y el trabajo de colaboración en NFV nació en
octubre de 2012 cuando varios de los principales TSP del
Ahora, más de dos años después, una gran comunidad de
expertos está trabajando intensamente para elaborar las
normas requeridas para el VNL, así como para compartir
sus experiencias sobre su desarrollo y su pronta aplicación.
El número de miembros del ETSI ha aumentado a más de
245 empresas individuales, entre ellas 37 de los principales
proveedores de servicios del mundo, así como
representantes tanto de las telecomunicaciones como de los
proveedores de tecnologías de la información [6]. El ETSI
ha completado con éxito la Fase 1 de su trabajo con la
publicación de 11 Especificaciones de Grupo del ETSI [7].
Estas especificaciones se basan en la primera versión de los
documentos del ETSI publicados en octubre de 2013 e
incluyen una visión general de la infraestructura, un marco
arquitectónico actualizado y descripciones de los dominios
de computación, hipervisor y red de la infraestructura.
También cubren la Gestión y Orquestación (MANO), la
seguridad y la confianza, la resistencia y la métrica de la
calidad del servicio.
al equipo de las instalaciones del cliente (CPE), y a una red de
Evolved Packet Core (EPC).
1) Equipo de las instalaciones del cliente
(CPE): En las figuras 1 y 2, utilizamos un ejemplo de un
CPE para ilustrar las economías de escala que puede
lograr el VNF. En la figura 1 se muestra una
implementación típica (actual) de un CPE que se
compone de las funciones: Protocolo de configuración
dinámica del anfitrión (DHCP), Traducción de
direcciones de red (NAT), enrutamiento, Plug and Play
universal (UPnP), cortafuegos, módem, radio y
conmutación. En este ejemplo, un solo servicio (el CPE)
está compuesto por ocho funciones. Estas funciones
pueden tener requisitos de precedencia. Por ejemplo, si
las funciones forman parte de una cadena de servicios2,
puede ser necesario realizar funciones de cortafuegos
antes de la NAT. Actualmente, es necesario tener estas
funciones en un dispositivo físico ubicado en los locales
de cada uno de los clientes 1 y
2. Con esa aplicación, si es necesario hacer cambios en el
CPE, por ejemplo, añadiendo, eliminando o actualizando una
función, puede ser necesario que un técnico del ISP hable o
vaya individualmente a cada uno de los clientes. Incluso puede
requerir un cambio completo del dispositivo en caso de
adiciones. Esto no sólo es costoso (operacionalmente) para los
ISP, sino también para los clientes.
En la figura 2, mostramos una posible implementación
basada en NFV en la que algunas de las funciones del CPE se
transfieren a una infraestructura compartida en el ISP, que
también podría ser un centro de datos. Esto facilita los
cambios descritos anteriormente ya que, por ejemplo, la
actualización del DHCP para todos los clientes sólo implicaría
cambios en el ISP. De la misma manera, la adición de otra
función como los controles parentales para todos o un
subconjunt o de clientes puede hacerse de una sola vez.
Además de ahorrar en los gastos de funcionamiento del
proveedor de servicios de Internet, esto puede dar lugar a que
los CPEs sean más baratos si se consideran a gran escala.
2) El núcleo del paquete evolucionado: La
virtualización del EPC es otro ejemplo de NFV que ha
Dado que el ETSI no es un organismo de normalización, su
objetivo es producir requisitos y posibles especificaciones que
los proveedores de servicios de telecomunicaciones y de
equipo puedan adaptar a sus entornos individuales, y que
puedan ser desarrollados por una organización de desarrollo
de normas (SDO) apropiada. Sin embargo, dado que los
organismos de normalización como el 3GPP [8] están en
contacto con el ETSI, podemos esperar que estas
propuestas sean generalmente aceptadas y aplicadas como
normas. El grupo de trabajo de gestión de telecomunicaciones
del 3GPP (SA5) también está estudiando la gestión de las
funciones de la red virtualizada del 3GPP.
B. Ejemplos de NFV
El ETSI ha propuesto una serie de casos de uso para el NFV
[9]. En esta subsección, explicaremos cómo se puede aplicar
el VNF
atraído mucha atención de la industria. El EPC es la red
central para la Evolución a Largo Plazo (LTE) como se
especifica en el 3GPP [8]. En el lado izquierdo de la Fig. 3,
mostramos una arquitectura básica de LTE sin NFV. El
Equipo de Usuario (UE) se conecta al EPC a través de la
red de acceso LTE (E-UTRAN). El NodoB evolucionado
(eNodeB) es la estación base para la radio LTE. El EPC
realiza funciones esenciales como el seguimiento de los
abonados, la gestión de la movilidad y la gestión de la
sesión. Está compuesto por cuatro NF: Pasarela de servicio
(S-GW), Pasarela de red de datos en paquetes (PDN) (P-
GW), Entidad de gestión de la movilidad (MME) y
Función de política y reglas de cobro (PCRF). También
está conectada a redes externas, que pueden incluir el
subsistema de red central multimedia IP (IMS). En la
actual EPC, todas sus funciones se basan en equipos
patentados. Por lo tanto, incluso cambios menores en una
función determinada pueden requerir la sustitución del
equipo. Lo mismo se aplica a los casos en que hay que
cambiar la capacidad del equipo.
A la derecha de la Fig. 3, mostramos la misma arquitectura en
la que el EPC está virtualizado. En este caso, o bien todas las
funciones
2La
cadena de funciones que conforman un servicio para el cual el orden de la
conectividad es importante se conoce como VNF Forwarding Graph (VNFFG)
[9]. Además de los requisitos de secuenciación, los enlaces de un VNFFG
pueden dividirse (es decir, a partir de una función, los paquetes pueden tomar uno
de los muchos caminos que conducen a una funcionalidad similar), o pueden
unirse.

Fig. 3. Virtualización del EPC
en el EPC, o sólo unos pocos de ellos se transfieren a una
infraestructura compartida (nube). La virtualización del
EPC podría dar lugar a una mayor flexibilidad y a un
escalamiento dinámico, y por lo tanto permitiría a los TSP
responder de manera fácil y barata a los cambios en las
condiciones del mercado. Por ejemplo, como se representa
en la Fig. 3 por el número de servidores asignados a cada
función, podría ser necesario aumentar los recursos del
plano de usuario sin afectar al plano de control. En este caso,
las FNV, como un EMM virtual, pueden escalar
los desafíos de fiabilidad de las infraestructuras de NFV se
examinan en [12]. Sin embargo, todos los esfuerzos de la
literatura actual se reducen al menos en una de las siguientes
formas principales: (1) con respect o al alcance, no
consideran aspectos importantes de la VNF, como su relación
con la SDN y la computación en nube, (2) revisión y análisis
limitados de las actividades de estandarización, y
3) Descripciones incompletas de las investigaciones en curso
y de los esfuerzos y retos de investigación más recientes.
Este documento examina el estado de la técnica en NFV e
identifica las áreas de investigación clave para la exploración
futura. Además, exploramos la relación entre NFV y dos
campos estrechamente relacionados, SDN [13] y la
computación en nube [14]. También describimos las diferentes
iniciativas y proyectos de investigación e industriales sobre
NFV, así como la implementación temprana, prueba de
conceptos y casos de productos. Hasta donde sabemos, este
documento presenta el estudio más completo del estado del
arte sobre NFV hasta la fecha.
D. Organización
El resto de este documento está organizado de la siguiente
manera: En la sección II se presenta la arquitectura del VFN
que ha sido propuesta por el ETSI, y se discuten sus
limitaciones. Proponemos un modelo de negocio de referencia e
identificamos importantes consideraciones de diseño en la
independientemente según sus necesidades específicas de
recursos. Del mismo modo, las FNV que se ocupan del plano
de datos podrían requerir un número diferente de recursos que
las que se ocupan únicamente de la señalización. Esta
flexibilidad permitiría una utilización más eficiente de los
recursos. Por último, también permite actualizar más fácilmente
los programas informáticos de las funciones de la red de EPC,
lo que permitiría, por lo tanto, un lanzamiento más rápido de
servicios innovadores.
C. Trabajo relacionado y preguntas abiertas
Mientras que tanto la industria como el mundo académico
adoptan el NFV a una velocidad sin precedentes, el desarrollo
se encuentra todavía en una etapa temprana, con muchas
preguntas abiertas. A medida que los proveedores y los
proveedores de servicios de telecomunicaciones examinan los
detalles de la aplicación del NFV y el logro de sus objetivos
previstos, existen preocupaciones sobre la realización de
algunos de estos objetivos y si la aplicación se traduce en los
beneficios previstos inicialmente. Existen importantes
desafíos de investigación no explorados, como las pruebas y la
validación [10], la gestión de recursos, la interoperabilidad, la
instanciación, el rendimiento de las FNV, etc., que deben
abordarse. Incluso las esferas que se están explorando, como la
MANO, siguen teniendo cuestiones pendientes, especialmente
en lo que respecta al apoyo a la heterogeneidad.
Recientemente se han realizado esfuerzos para introducir el
VNF, explicar sus requisitos de rendimiento, su arquitectura,
los casos de uso y los posibles enfoques de los desafíos [3]. En
[11] se presenta un análisis de los desafíos para la
introducción de NFV en las redes móviles, centrándose en el
núcleo de paquetes virtualizados evolucionados, mientras que
sección
III. En la sección IV, presentamos la SDN y la
computación en nube, describiendo la relación entre ellas y
Gestión y orquestación
el NFV, así como los esfuerzos actuales para implementar
entornos que las involucren a todas. En la sección V,
estudiamos los principales proyectos sobre NF V así
como las primeras implementaciones, casos de uso y
productos comerciales. Sobre la base de un análisis
cualitativo del estado de la técnica, en la sección VI se
identifican las principales esferas de investigación que
deben seguir explorándose, y en la sección VII se concluye
el presente documento.
II. ARQUITECTURA NFV
Según el ETSI, la arquitectura del NFV se compone de tres
elementos clave: Infraestructura de Virtualización de Funciones
de Red (NFVI), VNFs y NFV MANO [15]. Los representamos
gráficamente en la Fig. 4. En esta sección se definen estos
elementos [5], [15], [16].
A. Infraestructura del NFV (NFVI)
El NFVI es la combinación de recursos de hardware y
software que conforman el entorno en el que se despliegan los
VNF . Los recursos físicos incluyen hardware de computación
comercial, almacenamiento y red (compuesta por nodos y
enlaces) que proporcionan procesamiento, almacenamiento y
conectividad a los VNF. Los recursos virtuales son
abstracciones de los recursos de computación, Funciones de la red virtual
almacenamiento y red. La ab- stracción se logra mediante una
VNF 1VNF 2VNF 3 ...

Gestión y orquestación
capa de virtualización (basada en un hipervisor), que disocia VNF n
los recursos virtuales de los recursos físicos subyacentes. En un
Servicios
entorno de centro de datos, los recursos de computación y
almacenamiento pueden representarse en términos de una o
más Máquinas Virtuales (VM), mientras que las redes Recursos de computación, almacenamiento y redes
virtuales se componen de enlaces y nodos virtuales. Un nodo
virtual es un componente de software con funcionalidad de Recursos virtuales
alojamiento o de enrutamiento, por ejemplo, un sistema
operativo encapsulado en una VM. Un enlace virtual es una
Recursos de computación, almacenamiento y redes
interconexión lógica de dos nodos virtuales, que les aparece
como un enlace físico directo con propiedades que cambian Recursos físicos
dinámicamente [17]. Infraestructura de virtualización de la función de red

Fig. 4. Arquitectura de virtualización de funciones de red

B. Funciones y servicios de la red virtual

Un NF es un bloque funcional dentro de una infraestructura
de red que tiene interfaces externas bien definidas y un
comportamiento funcional bien definido [15]. Ejemplos de NF
son los elementos de una red doméstica, por ejemplo, la
pasarela residencial (RGW); y las funciones de red
convencionales, por ejemplo, los servidores DHCP, los
cortafuegos, etc. Por lo tanto, una FNV es una implementación
de una FN que se despliega en recursos virtuales como una
máquina virtual. Un único VNF puede estar compuesto de
múltiples componentes internos y, por lo tanto, podría
desplegarse en múltiples VM, en cuyo caso cada VM alberga
un único componente del VNF [5]. Un servicio es una oferta
proporcionada por un TSP que se compone de una o más FN.
En el caso de las FN, las FN que componen el servicio se
virtualizan y−despliegan en recursos virtuales como un VM.
Sin embargo, desde el−punto de vista de los usuarios, los
servicios, ya sea que se basen en funciones que ejecuten
equipos dedicados o en máquinas virtuales, deben tener el
mismo rendimiento. El número, el tipo y el orden de los VNF
que lo componen están determinados por la especificación
funcional y de comportamiento del servicio. Por lo tanto, el
comportamiento del servicio depende del de las VNF que lo
componen.

C. Gestión y orquestación del NFV (NFV MANO)

Según el marco MANO del ETSI [18], NFV MANO
proporciona la funcionalidad necesaria para el
aprovisionamiento de VNF, y las operaciones relacionadas,
como la configuración de los VNF y la infraestructura en la
que se ejecutan estas funciones. Incluye la orquestación y la
gestión del ciclo de vida de los recursos físicos y/o
informáticos que respaldan la virtualización de la
infraestructura, y la gestión del ciclo de vida de las FNV.
También incluye bases de datos que se utilizan para
almacenar la información y los modelos de datos que definen
tanto el despliegue como las propiedades del ciclo de vida de
las funciones, servicios y recursos. NFV MANO se centra en
todas las tareas de gestión específicas de la virtualización
necesarias en el marco de NFV. Además, el marco define las
interfaces que pueden utilizarse para las comunicaciones
entre los diferentes componentes de la NFV MANO, así
como la coordinación con los sistemas tradicionales de
gestión de redes como Operaciones
Sistema de Apoyo (OSS) y Sistemas de Apoyo Comercial
2
(BSS) para permitir la gestión tanto de los VNF como de las
Servidor
funciones que se ejecutan en los equipos heredados. VNF
Proveedor (SP)
Proveedor (VNFP) 2 Proveedor de Infraestructura (InP)

datos públicos como los de Amazon, o servidores privados

Discusión: La arquitectura de referencia NFV propuesta por propiedad de los TSPs. Si un determinado InP no es capaz
el ETSI especifica los requisitos funcionales iniciales y esboza de proporcionar
Corredoresrecursos en Recursos
su totalidad o en parte a un
de computación, almacenamiento y redes
1
las interfaces requeridas. Sin embargo, el ámbito de trabajo determinado TSP, se pueden formar negociaciones y, por lo
del ETSI es bastante limitado, excluyendo aspectos como el tanto, coaliciones
3 con otros InP para proporcionar VNF de
control y la gestión de los equipos heredados [5]. Esto podría dominio múltiple [21].
dificultar la especificación del funcionamiento y la gestión de
3 De
El hecho,
Servicioincluso
de Telecomunicaciones
un servicio de extremo a extremo que incluya tanto las el hecho de que se puedan
4
utilizar contenedores para
Usuario
albergar FV yProveedor
el correspondiente
(TSP) ecosistema todavía necesita ser investigado
funciones heredadas como las NFV. Además, todavía no se [19].
dispone de normas y/o mejores prácticas de facto ni de
implementaciones de referencia de las FNV, la infraestructura,
la MANO y las definiciones detalladas de las interfaces
requeridas.
En particular, se puede ver en las soluciones actuales de
NFV que los vendedores tienen ideas diferentes sobre lo que
constituye un NFVI y un VNF, y cómo se pueden modelar
ambos. Quedan varias preguntas abiertas como: 1) qué NFV
deben desplegarse en los nodos del centro de datos y cuáles en
los nodos del operador; 2) qué funciones deben desplegars e
en los VM dedicados y cuáles en los contenedores3; 3) qué
cantidad y tipos de recursos de NFVI se necesitarán para
ejecutar funciones específicas; y 4) los requisitos operativos
de los entornos que implican tanto VNF como los que
funcionan con equipo heredado. Si bien muchas de estas
cuestiones, como la interoperabilidad y la definición de la
interfaz, se abordarán en la segunda fase de la labor del
Instituto Europeo de Normas de Telecomunicaciones (ETSI),
el tiempo es esencial. Dado que tanto los proveedores como
los proveedores de servicios de telecomunicaciones ya están
invirtiendo significativamente en las VNF, podríamos llegar a
un punto en el que sea imposible revertir las soluciones
específicas de los proveedores.

III. CONSIDERACIONES DE MODELO DE NEGOCIO Y

DISEÑO Usando la arquitectura representada en la Fig. 4, y

basada en
modelos de negocio para la virtualización de redes [20] y la
computación en nube [14], identificamos cinco actores
principales en un entorno NFV y proponemos un modelo de
negocio de referencia que ilustra las posibles relaciones
comerciales entre ellos, como se muestra en la Fig. 5. También
discutimos importantes consideraciones de diseño del sistema
NFV.

A. Modelo de negocio
1) Proveedor de Infraestructura (InP): Los InPs
despliegan y administran recursos físicos en forma de
centros de datos y redes físicas. Es sobre estos recursos
que los recursos virtuales pueden ser aprovisionados y
arrendados a través de interfaces de programación a uno
o más TSPs. Los InPs también pueden determinar cómo
el conjunto de los recursos disponibles se asignan a los
TSPs. En NFV, ejemplos de InPs podrían ser centros de

Fig. 5. Modelo comercial propuesto para el VNL
2) Proveedor de Servicios de Telecomunicaciones
(TSP): Los TSP4 alquilan recursos de uno o más InP, que
utilizan para el funcionamiento de las VNF. También
determinan el encadenamiento de estas funciones para crear
servicios para los usuarios finales. En un caso más general,
los TSP pueden subarrendar sus recursos virtuales a otros
TSP. En tal caso, el TSP revendedor asumiría el papel de un
InP. En los casos en que el InP sea privado o interno, por
ejemplo, proporcionado por nodos o servidores de la red de
TSP, entonces el InP y el TSP pueden ser una sola entidad.
3) Proveedores de VNF (VNFP) y Proveedores de
Servidores (SP): NFV divide el papel de los proveedores
tradicionales de equipos de red (como Cisco, Huawei, HP y
Alcatel-Lucent) en dos: VNFPs y SPs. Los VNFP
proporcionan implementaciones de software para las FN.
Estas funciones pueden proporcionarse directamente a los
proveedores de servicios de telecomunicaciones (a través de
la interfaz 1), o bien las APNFV podrían proporcionarlas a
los proveedores de servicios de telecomunicaciones (a través
de la interfaz 2), que a su vez proporcionarían tanto la
un servicio al TSP. Este papel sólo se incluye en el modelo
para completarlo ya que puede no ser requerido en todos los
casos del ecosistema del VNL.
5) Usuario final: Los usuarios finales son los
consumidores finales de los servicios prestados por los
proveedores de servicios de telecomunicaciones. Son
similares a los usuarios finales de la Internet actual, con
la salvedad de que la existencia de múltiples servicios de
los proveedores de servicios de telecomunicaciones que
compiten entre sí les permite elegir entre una amplia
gama de servicios. Los usuarios finales pueden
conectarse a múltiples proveedores de servicios de
telecomunicaciones para obtener diferentes servicios.
Por último, las flechas de la Fig. 5 indican las relaciones
comerciales o interfaces entre las diferentes entidades. Por
ejemplo, las APNV y/o los SP utilizan las interfaces 1 y 2 para
negociar y/o proporcionar APNV y servidores de productos
básicos, respectivamente, a los TSP e InP, mientras que los
TSP utilizan las interfaces 3 y 4 para sus interacciones con los
corredores y los usuarios, respectivamente.
B. Consideraciones de diseño del NFV
A medida que el NFV madura, es importante señalar que no
sólo basta con desplegar NF sobre infraestructuras
virtualizadas. Por lo general, a los usuarios de la red no les
preocupa la complejidad (o cualquier otra) de la red
infraestructura como las APNFV a los proveedores de
servicios de telecomunicaciones. También es posible que los
TSP desarrollen (algunos de) sus propias FN (software). En
este caso, las FNV y los PTS serían una sola entidad.
De la misma manera, los SP proporcionan servidores
estándar de la industria en los que se pueden desplegar VNF.
Estos servidores pueden proporcionarse a los InP (en caso de
que las funciones se ejecuten en una nube), o a los TSP (en
caso de que las funciones se ejecuten en los nodos de la red de
los TSP). Cabe señalar que estas entidades (APNV y PSP)
pueden ser de hecho una sola empresa. La principal diferencia
es que las funciones que ofrecen no están vinculadas a la
ejecución en equipos con funcionalidad especializada o
fabricados por un proveedor específico. En otras palabras, un
proveedor de servicios técnicos podría adquirir las VNF de
una entidad y los servidores de otra distinta.
4) Corredores: En algunos casos, un proveedor de
servicios técnicos puede necesitar adquirir funciones que
constituyen un único servicio de varias APNFV, y/o desplegar
y gestionar los servicios integrales resultantes que funcionan
con los recursos de varias APNF. En este caso, puede ser
necesario desempeñar una función de intermediación. Los
intermediarios recibirían las necesidades de recursos y/o
funciones de los proveedores de servicios técnicos y luego
descubrirían, negociarían y agregarían los recursos y
funciones de múltiples proveedores de servicios técnicos,
APNFD y proveedores de servicios específicos para ofrecerlos
como
4 En
este documento, utilizamos el término TSP para referirnos en general a
todos los proveedores de servicios. Esto incluye proveedores de servicios
como Netflix que despliegan servicios con cachés en diferentes lugares, así
como los TSP tradicionales como Telefónica y Deutsche Telecom.
subyacente. Lo único que necesitan los usuarios es que la red les
permita acceder a las aplicaciones que necesitan, cuando las
necesitan. Por lo tanto, la NFV sólo será una solución aceptable
para los proveedores de servicios de telecomunicaciones si
cumple las consideraciones fundamentales que se indican a
continuación.
1) Arquitectura de la red y el rendimiento: Para
poder ser aceptadas, las arquitecturas NFV deben ser
capaces de lograr un rendimiento similar al que se obtiene
de las funciones que se ejecutan en un hardware dedicado.
Esto requiere que todos los posibles cuellos de botella en
todas las capas de la pila sean evaluados y mitigados. Por
ejemplo, si los VNF pertenecientes al mismo servicio se
colocan en diferentes VM, entonces debe haber una
conexión entre estos dos VM, y esta conexión debe
proporcionar un tráfico de red sostenido y agregado de gran
ancho de banda a los VNF. Para ello, puede ser importante
que la red pueda aprovechar las conexiones a las interfaces
de red que tienen un gran ancho de banda y una baja
latencia debido a las técnicas de descarga del procesador,
como el acceso directo a la memoria (DMA)[22] para el
movimiento de datos y la asistencia del hardware para el
cálculo del CRC [23], [24].
Además, algunos VNF como la Inspección Profunda de
Paquetes (DPI) son intensivos en red y computación, y pueden
requerir alguna forma de aceleración de hardware [25] que debe
proporcionar el NFVI para seguir cumpliendo sus objetivos de
rendimiento [26]. En algunos esfuerzos recientes [27] se han
estudiado las consecuencias de la utilización de los kits de
desarrollo de planos de datos (DPDK) para la ejecución de
VNF y se ha demostrado que se puede lograr un rendimiento
casi nativo (es decir, similar al no virtualizado) para el
procesamiento de paquetes pequeños y grandes. Además, se
ha demostrado que los conjuntos de puertas programables en
el terreno (FPGAs) mejoran el rendimiento de los VNF [28],
[29]. Por último, a los VNF sólo se les debe asignar los
recursos de almacenamiento y comunicación que necesitan. De
lo contrario, los despliegues de VNF podrían terminar
requiriendo más recursos, y por lo tanto no habría justificación
para transitar a los VNF.
2) Seguridad y resistencia: La naturaleza
dinámica del NFV exige que las tecnologías, políticas,
procesos y prácticas de seguridad se integren en su tejido
genético [30]. En particular, hay dos importantes riesgos
de seguridad que deben ser considerados
en los diseños del NFVI: 1) las funciones o servicios de los
diferentes abonados deben ser protegidos/aislados entre sí.
Esto ayuda a garantizar que las funciones sean resistentes a los
fallos y ataques, ya que un fallo o una violación de la
seguridad en una función/servicio no afectaría a otra. 2) los
NFVI (recursos físicos y virtuales) deben protegerse de los
servicios de abonado suministrados. Una forma de asegurar el
NFVI es desplegar cortafuegos internos dentro del entorno
virtual [24]. Estos permitirían que el NFV MANO acceda a los
VNF sin dejar que el tráfico malicioso de las redes de los
clientes entre en el NFVI. Por último, para que el despliegue
del servicio sea resistente, puede ser necesario que las
funciones que componen el mismo servicio no estén alojadas
por recursos físicos en el mismo dominio de fallo o seguridad
durante el despliegue.
3) Fiabilidad y disponibilidad: Mientras que en el dominio
de la tecnología de la información las interrupciones que
duran segundos son tolerables y un usuario suele iniciar
reintentos, en las telecomunicaciones existe una expectativa
de servicio subyacente de que las interrupciones estarán por
debajo del nivel reconocible (es decir, en el orden de los
milisegundos), y la recuperación del servicio se realiza
automáticamente. Además, las interrupciones que afectan al
servicio deben limitarse a un determinado número de usuarios
(por ejemplo, una determinada geografía) y las interrupciones
en toda la red no son aceptables [31]. Estas necesidades de alta
fiabilidad y disponibilidad no sólo son una expectativa de los
clientes, sino a menudo un requisito reglamentario, ya que se
considera que los proveedores de servicios de
telecomunicaciones forman parte de la infraestructura
nacional crítica, y existen las respectivas obligaciones legales
de garantía de servicio y continuidad del negocio. Sin
embargo, no todas las funciones tienen los mismos requisitos
de resistencia: Por ejemplo, mientras que la telefonía suele
tener los mayores requisitos de disponibilidad, otros servicios,
por ejemplo, el servicio de mensajes cortos (SMS), pueden
tener menores requisitos de disponibilidad. Así pues, pueden
definirse múltiples clases de disponibilidad que deberían estar
respaldadas por un marco de VAN [31]. Una vez más, las
funciones pueden desplegarse con redundancia para
recuperarse de los fallos de software o hardware.
4) Apoyo a la Heterogeneidad: El principal punto de venta
de NFV se basa en romper las barreras que resultan de la
prestación de servicios basados en hardware propio. Por lo
tanto, no es necesario mencionar que la apertura y la
heterogeneidad serán el núcleo del éxito de NFV. Las
soluciones de NFV específicas de los proveedores con
capacidades de hardware y plataformas específicas de los
proveedores derrotan el concepto y el propósito original de
NFV. Por lo tanto, cualquier plataforma aceptable de NFV
debe ser un entorno abierto y compartido capaz de ejecutar
aplicaciones de diferentes proveedores. Los InPs deben ser
libres de tomar sus propias decisiones de selección de
hardware, cambiar de proveedor de hardware y tratar con
hardware heterogéneo. Además, esas plataformas deben ser
capaces de proteger a los VNF de las especificidades de las
tecnologías de red subyacentes (por ejemplo, ópticas,
inalámbricas, de sensores, etc.) [32]. Por último, e igualmente
importante, las plataformas deberían permitir la creación de
un servicio de extremo a extremo sobre más de un dominio de
infraestructura sin restricciones y sin necesidad de funciones de software internas y da lugar a oportunidades de
soluciones tecnológicas específicas. Mientras que la crecimiento de los ingresos [33]. Por ejemplo, si un usuario
virtualización dentro de un solo InP reduce el costo, el NFV móvil abonado a un determinado PSV se desplaza a la
entre proveedores permite la "producción" de las mismas cobertura de otro PSV, el usuario no debe ser restringido
a servicios de voz, datos y mensajería simple. El verdadero esta sección, presentamos dos conceptos de este tipo que están
poder de NFV se realizaría si ese usuario puede elegi r un estrechamente relacionados con la NFV: la computación en nube
cortafuegos o un servicio de seguridad del TSP actual, o y la SDN. También discutimos la relación entre NFV y cada uno
utilizar una combinación de funciones del TSP anfitrión y de ellos, así como los intentos actuales de permitir que los tres
otras del que tiene cobertura. trabajen juntos.
5) Apoyo al legado: La compatibilidad
retroactiva siempre será un tema de gran preocupación A. Computación en la nube
para cualquier nueva tecnología. NFV no es una
excepción. Es aún más importante para la industria de Según el NIST [35], la computación en nube es "un modelo
las telecomunicaciones, dado que incluso para un para permitir el acceso ubicuo, conveniente y a la carta a un
operador determinado que decida hacer la transición a conjunto compartido de recursos informáticos configurables (por
NFV, puede tomar tiempo para que esto se complete, sin ejemplo, redes, servidores, almacenamiento, aplicaciones y
mencionar el hecho de que algunos operadores lo harán servicios) que se pueden aprovisionar y liberar rápidamente con
más rápido que otros. Por lo tanto, el apoyo a las FN un mínimo de esfuerzo de gestión o de interacción con el
tanto físicas como virtuales es importante para los proveedor de servicios". En un entorno de computación en nube,
operadores que hacen la transición a las FN, ya que la función tradicional del proveedor de servicios se divide
pueden necesitar gestionar durante algún tiempo los
activos físicos heredados junto con las funciones
virtualizadas. Para ello puede ser necesario contar con
una estrategia de orquestación que cierre la brecha entre
los servicios heredados y el NFV. Es importante
mantener una trayectoria de migración hacia el NFV, al
tiempo que se mantienen las inversiones actuales de los
operadores en la red [34]. Los InP deben poder funcionar
en un entorno en el que las funciones de red virtual y
física funcionen en la red simultáneamente.
6) Escalabilidad y automatización de la red:
Para lograr todos los beneficios de NFV, es necesario
contar con una solución de red escalable y con capacidad
de respuesta. Por lo tanto, al tiempo que se cumplen las
consideraciones de diseño mencionadas, el NFV debe
ser aceptablemente escalable para poder dar soporte a
millones de abonados. Para dar un ejemplo, la mayoría
de las pruebas de concepto actuales de NFV se basan en
el despliegue de una máquina virtual para alojar un VNF.
De la misma manera que una sola máquina virtual puede
no ser capaz de cumplir los requisitos de una función
determinada, no resulta económico desplegar una
máquina virtual por cada NFV, ya que la huella resultante
de la máquina virtual sería demasiado grande y daría
lugar a problemas de escalabilidad en la capa de
virtualización. Sin embargo, el NFV sólo se escalará si
todas las funciones pueden ser automatizadas. Por lo
tanto, la automatización de los procesos es de suma
importancia para el éxito del NFV [4]. Además, la
necesidad de entornos dinámicos exige que las NFV
puedan desplegarse y eliminarse a petición y escalarse
para adaptarse a los cambios del tráfico.

IV. CONCEPTOS RELACIONADOS

La necesidad de innovación, agilidad e intercambio de
recursos no es nueva. En el pasado, la industria de las
comunicaciones ha inventado y desplegado nuevas tecnologías
para ayudarles a ofrecer nuevos y múltiples servicios de una
manera más ágil, rentable y eficaz en cuanto a recursos. En
en dos: los proveedores de infraestructura que gestionan las
formas de la nube y alquilan recursos según un modelo de
precios basado en el uso, y los proveedores de servicios,
que alquilan recursos de uno o varios proveedores de
infraestructura para servir a los usuarios finales [14]. El
modelo de nube se compone de cinco características
esenciales y tres modelos de servicio [35]. En las siguientes
subsecciones se presentan brevemente.
1) Características esenciales de la computación en la
nube: Autoservicio a demanda. Un consumidor puede
proporcionar unilateralmente capacidades de computación,
como tiempo de servidor y almacenamiento en red, según
sea necesario de forma automática sin necesidad de
interacción humana con cada proveedor de servicios.
Amplio acceso a la red. Las capacidades (por ejemplo,
los recursos informáticos, la capacidad de almacenamiento)
están disponibles a través de la red y se accede a ellas
mediante mecanismos estándar que promueven el uso de
plataformas heterogéneas de clientes finos o gruesos (por
ejemplo, teléfonos móviles, tabletas, computadoras
portátiles y estaciones de trabajo).
La puesta en común de recursos. Los recursos
informáticos del proveedor se ponen en común para atender
a múltiples consumidores mediante un modelo de
multiarrendamiento, con diferentes recursos físicos y
virtuales asignados y reasignados dinámicamente según la
demanda del consumidor. Elasticidad rápida. Las
capacidades pueden ser suministradas y liberadas
elásticamente, en algunos casos automáticamente, para
escalar rápidamente
...hacia afuera y hacia adentro de acuerdo a la demanda.
Servicio medido. Los sistemas en nube controlan y
optimizan automáticamente el uso de los recursos
aprovechando una capacidad de medición a un cierto nivel
de abstracción apropiado para el tipo de servicio (por
Recursos por capas
Software
Aplicaciones de negocios,
Servicios Web
Infraestr
Marco de software
uctura de la
Máquinas virtuales
plataforma
CPU, almacenamiento, ancho de banda
Hardware
Fig. 6. Modelos de servicios de computación en la nube y su mapeo como parte de la arquitectura de referencia del NFV
TABLA I
COMPARACIÓN DE NFV EN REDES DE TELECOMUNICACIONES Y COMPUTACIÓN EN NUBE
Edición NFV (Redes de Telecomunicaciones)
Acercamiento Abstracción de servicio/función
Formalizació ETSI NFV Grupo de Estándares Industriales
n DMTF [36]
ejemplo, almacenamiento, procesamiento, ancho de banda y
cuentas de usuario activas).
2) Modelos de servicios de computación en la nube: Los
tres modelos de servicio de la computación en la nube se
muestran en la Fig. 6, y se definen a continuación [35].
Software as a Service (SaaS). El usuario puede utilizar las
aplicaciones del proveedor que se ejecutan en una
infraestructura de nube. Se puede acceder a las aplicaciones
desde varios dispositivos cliente a través de una interfaz de
cliente ligero, como un navegador web (por ejemplo, correo
electrónico basado en la web), o una interfaz de programa.
Plataforma como un Servicio (PaaS). El usuario puede
desplegar en la infraestructura de la nube aplicaciones creadas
o adquiridas por el consumidor, creadas con lenguajes de
programación, bibliotecas, servicios y herramientas apoyadas
por el proveedor.
La infraestructura como servicio (IaaS). El usuario es
capaz de pro- procesamiento de la visión, almacenamiento,
redes y otros recursos informáticos fundamentales donde el
consumidor puede desplegar y ejecutar software arbitrario,
que puede incluir sistemas operativos y aplicaciones.
3) Relación entre la computación en nube y el NFV: En
general, el NFV no se restringe a las funciones de los servicios
de telecomunicaciones. De hecho, muchas aplicaciones
informáticas ya se ejecutan en servidores de productos básicos
en la nube [40]. Sin embargo, dado que la mayoría de los casos
de uso prometedores para NFV se originan en la industria de
las telecomunicaciones, y dado que los requisitos de
rendimiento y fiabilidad de las funciones de grado de operador
son más altos que los de las aplicaciones de TI, los debates en
este documento consideran que el rendimiento aceptable de
NFV debe ser de clase de operador. En la Fig. 6, hemos
mapeado los modelos de servicio de nubes a parte de la
arquitectura de NFV. Se puede observar que la IaaS
corresponde tanto a los recursos físicos como virtuales en
Modelo Ejemplo Mapeo de la
arquitectura
del NFV
Facebook, Google Apps, Twitter,
Sa VNF 1VNF n
ZenDesk, Saleforce.com, Zoho
aS
Office
VNFs / Servicios
Heroku, Azure, Google
Pa
AppEngine, RedHat
aS
OpenShift, force.com
OpenStack, Azure, Amazon Web NFVI
Services (EC2, S3, DynamoDB), GoGrid, Físico y
Ia Rackspace Recursos virtuales
aS
Centros de datos
Computación en la nube
Abstracción por ordenador
Grupo de Trabajo de Gestión de Nubes del
 Latencia Expectativas de baja latencia
Infraestructur Transporte heterogéneo (Óptico, Ethernet, Inalámbrico)
a
Protocolo Múltiples protocolos de control (por ejemplo, OpenFlow
[37], SNMP [38])
Fiabilidad Requisitos de disponibilidad de los NINES estrictos 5 [39]
Reglamento Requisitos estrictos, por ejemplo, NEBS [41]
el NFVI, mientras que los servicios y VNF en NFV son
similares al modelo de servicio SaaS en la computación en
nube.
Siendo la opción más barata para las pruebas y la
implementación, la mayoría de las pruebas de conceptos e
implementaciones tempranas de NFV se han basado en el
despliegue de funciones en máquinas virtuales dedicadas en la
nube. La flexibilidad de la computación en nube, incluyendo
el rápido despliegue de nuevos servicios, la facilidad de
escalabilidad y la reducción de la duplicación, la convierten en
el mejor candidato que ofrece la posibilida d de lograr la
eficiencia y la reducción de gastos que motivan a los TSP
hacia el NFV.
Sin embargo, el despliegue de NF en la nube probablemente
cambiará todos los aspectos de la forma en que los servicios y
aplicaciones son desarrollados y entregados. Si bien se sigue
trabajando en lo que respecta a las nubes en red y las redes
entre nubes [42], [43], las redes de telecomunicaciones
difieren del entorno de la computación en nube al menos en
tres aspectos: 1) las cargas de trabajo de los planos de datos en
las redes de telecomunicaciones implican una gran presión
sobre el rendimiento,
(2) las topologías de las redes de telecomunicaciones imponen
duras exigencias a la red y la necesidad de una visión global
de la red para la gestión [44], (3) la industria de las
telecomunicaciones requiere escalabilidad, disponibilidad de
cinco nueves y fiabilidad. En las redes de telecomunicaciones
tradicionales, estas características son proporcionadas por la
infraestructura del sitio. Si el VNF debe basarse en la
computación en nube, es necesario que la infraestructura de la
nube reproduzca estas características de manera que puedan
ser orquestadas, ya que las características orquestadas pueden
exponerse mediante abstracciones apropiadas, además de estar
acopladas con
Es aceptable una cierta latencia
Transporte homogéneo (Ethernet)
OpenFlow
Requisitos de fiabilidad menos estrictos [40]
Todavía diversa y cambiante
apoyo avanzado para el descubrimiento y la trazabilidad [45].
Por lo tanto, vale la pena subrayar que el NFV requerirá más
consideraciones que la simple transferencia de funciones de
red de clase portadora a la nube. Es necesario adaptar los
entornos de las nubes para obtener un comportamiento de
clase portadora [44]. En el cuadro I se resume la relación entre
el VNF de las redes de telecomunicaciones y la computación
en la nube.
4) Investigación sobre el NFV basado en la nube: Para que
el NFV tenga un rendimiento aceptable en los entornos de
computación en nube, la infraestructura subyacente debe
proporcionar un cierto número de funcionalidades que van
desde la programación a la creación de redes y desde la
orquestación a las capacidades de supervisión. Si bien se ha
identificado a OpenStack como uno de los principales
componentes de un marco arquitectónico de NFV basado en la
nube, actualmente no cumple algunos requisitos de NFV. Por
ejemplo, mediante un análisis de las deficiencias en [46], se
observó que, entre otras deficiencias, OpenStack no
proporciona una descripción detallada de los recursos de red,
incluidos los requisitos de calidad de servicio (QoS), ni
respalda un servicio de reserva de recursos y, por consiguiente,
no proporciona ninguna interfaz para la reserva de recursos.
Además, mediante mediciones se ha informado de cierta
degradación del rendimiento [47]. Ya se han dedicado algunos
esfuerzos a estudiar los requisitos necesarios para que el
rendimiento de los portadores de nubes sea de grado [48],
[49], [50]. En particular, OpenANFV [28] propone un marco
basado en OpenStack que utiliza la aceleración de hardware
para mejorar la
 Aplicaciones de red/empresa

Equilibrio de la carga Enrutamiento . . .MAC Learning

APIs

Capa de aplicación

Servicios de red

Controlador SDN
Interfaz, por
ejemplo,
Openflow
Capa de control

Reenvío
Interruptores

Capa de infraestructura

Fig. 7. Control distribuido y cajas intermedias (por ejemplo,

cortafuegos, detección de intrusos, etc.) en redes tradicionales Fig. 8. Capas lógicas en una red definida por el software

el rendimiento de los VNF. Los esfuerzos del autor están implementan protocolos SDN sin necesidad de hardware
motivados por la observación de que, en el caso de algunas especializado.
funciones (por ejemplo, DPI, deduplicación de red (Dedup) y SDN tiene el potencial de simplificar dramáticamente la
NAT), es posible que los servidores estándar de la industria no gestión de la red y permitir la innovación y la evolución [57].
alcancen los niveles de rendimiento requeridos. Por lo tanto, Según la Fundación de Red Abierta (ONF) [58], SDN aborda el
OpenANFV tiene por objeto proporcionar un hecho de que la arquitectura estática de la red convencional
aprovisionamiento elástico y automatizado para la aceleración
de hardware a los VNF en OpenStack. Para ello, se permitió a
los VNF probados (DPI, Dedup y NAT) acceder a un conjunto
predefinido de comportamiento acelerado y comunicarse a
través de una interfaz independiente de hardware con el
hipervisor para configurar el acelerador. Los autores
reportaron desempeños 20, 8 y 10 veces mejores para DPI,
Dedup y NAT respectivamente.

B. Redes definidas por software (SDN)

El SDN [51] está atrayendo actualmente una atención
significativa tanto del mundo académico como de la industria
como una arquitectura importante para la gestión de redes
complejas de gran escala, que pueden requerir re-policía o
reconfiguraciones de vez en cuando. Como se muestra en las
figuras 7 y 8, la SDN desacoplará las funciones de control y
reenvío de la red. Esto permite que el control de la red sea
directamente programable a través de una interfaz abierta (por
ejemplo, ForCES [52], OpenFlow [53], etc.) y que la
infraestructura subyacente se convierta en simples dispositivos
de reenvío de paquetes (el plano de datos) que puedan ser
programados.
Mientras que el plano de control SDN puede ser
implementado como puro software que se ejecuta en un
hardware estándar de la industria, el plano de control para el
warding requiere un agente SDN [54], y por lo tanto puede
requerir ser implementado en un hardware especializado. Sin
embargo, en función de las necesidades de rendimiento y
capacidad del elemento de red de la SDN, y dependiendo de si
se requieren interfaces de transporte de hardware
especializado, el plano de retransmisión también puede
implementarse en servidores de productos básicos [55]. Por
ejemplo, la plataforma NSX de VMware [56] incluye un
conmutador virtual (vSwitch) y un controlador, los cuales
no es adecuada para las necesidades de computación
dinámica y almacenamiento de los centros de datos, campus
y entornos de transporte de hoy en día. La arquitectura SDN
es [59]:
Programable. SDN hace que el control de la red sea
directamente programable ya que el control está
desacoplado de las funciones de reenvío. Esta
programabilidad puede ser utilizada para automatizar la
configuración de la red de tal manera que los
administradores de la red puedan ejecutar "aplicaciones
SDN" que ayuden a optimizar servicios particulares como
VoIP para asegurar una alta calidad de experiencia (QoE) en
las llamadas telefónicas.
Ágil. Absorbiendo el control del reenvío permite a los
administradores ajustar dinámicamente el flujo de tráfico de
toda la red para satisfacer las necesidades cambiantes. Esto
hace que la red sea más ágil ya que la lógica se implementa
ahora en un software que se ejecuta en un hard ware de
productos básicos, que tiene ciclos de lanzamiento más
cortos que el firmware del dispositivo. Administrado
centralmente. La inteligencia de la red está (lógicamente)
centralizada en controladores SDN basados en software que
mantienen una visión global de la red, que aparece a las
aplicaciones y
los motores de la política como un único y lógico cambio.
Basado en estándares abiertos y neutralidad del
vendedor. Cuando se implementa a través de estándares
abiertos, SDN simplifica la firma y el funcionamiento de la
red porque las instrucciones son proporcionadas por los
controladores SDN en lugar de múltiples dispositivos y
protocolos específicos del vendedor.
1) Relación entre SDN y NFV: NFV y SDN
tienen mucho en común, ya que ambos abogan por un paso
hacia el software abierto y el hardware de red estándar.
Específicamente, de la misma manera que la NFV apunta a
ejecutar NFs en hardware estándar de la industria, el plano
de control SDN puede ser implementado como puro
software ejecutado en hardware estándar de la industria.
Además, tanto NFV como SDN buscan aprovechar la
automatización y la virtualización para lograr sus
respectivos objetivos. De hecho, NFV y SDN pueden ser
altamente complementarios, y por lo tanto, combinarlos en
una solución de red puede llevar a un mayor valor. Por
ejemplo, si es capaz de funcionar en una VM, un
controlador SDN puede ser implementado como parte de
una cadena de servicios. Esto significa que las aplicaciones
centralizadas de control y gestión (como el equilibrio de la
carga, la vigilancia y el análisis del tráfico) utilizadas en la
SDN pueden realizarse, en parte, como VNF y, por lo tanto,
beneficiarse de las características de fiabilidad y elasticidad
de la NFV.
 TABLA II
COMPARACIÓN DE LOS CONCEPTOS DE REDES DEFINIDAS POR EL SOFTWARE Y DE VIRTUALIZACIÓN DE LA FUNCIÓN DE RED

Edición NFV (Redes de Telecomunicaciones) Red definida por el software

Acercamiento Abstracción de servicio/función Abstracción en red
Formalización ETSI ONF
Promete traer un control programable unificado y
AdvantagePromesa de aportar flexibilidad y reducción de costes interfaces
abiertas
ProtocoloProtocolos de control múltiple (por ejemplo SNMP, NETCONF) OpenFlow es estándar de facto
Servidores de productos para el avión de control y la
Las aplicaciones ejecutan servidores y conmutadores de productos básicos
posibilidad
para el hardware especializado para el
avión de datos
LíderesProveedores de servicios de telecomunicacionesProveedores de software y hardware de redes principalmente
Iniciador de negociosProveedores de servicios de telecomunicacionesNacidos en el campus, madurados en el centro de datos

De la misma manera, SDN puede acelerar el despliegue de ellos propietarios [63]. Hay dos aspectos importantes de la
NFV ofreciendo una forma flexible y automatizada de SDN que tal vez sea necesario mejorar para cumplir los
encadenar funciones, aprovisionamiento y configuración de la requisitos de la NFV: la API de Southbound
conectividad de la red y el ancho de banda, automatización de (principalmente OpenFlow), y los diseños de los
las operaciones, seguridad y control de políticas [60]. Sin controladores. A continuación se examinan los avances en
embargo, cabe destacar que la mayoría de las ventajas que se cada uno de estos dos aspectos.
esperan tanto de la NFV como de la SDN son promesas que
aún no han sido probadas.
Sin embargo, el SDN y el NFV son conceptos diferentes,
destinados a abordar diferentes aspectos de una solución de red
basada en software. NFV tiene como objetivo disociar las NF
de los elementos de hardware especializados, mientras que
SDN se centra en separar el manejo de paquetes y conexiones
del control general de la red. Como afirma la ONF en la
descripción de la arquitectura SDN [54], "el concepto de NFV
difiere del concepto de virtualización tal como se utiliza en la
arquitectura SDN. En la arquitectura SDN, la virtualización es
la asignación de recursos abstractos a clientes o aplicaciones
particulares; en NFV, el objetivo es abstraer las NF de un
hardware dedicado, por ejemplo, para permitir que se alojen
en plataformas de servidores en centros de datos en nube". Se
puede observar que los mayores esfuerzos en la promoción y
estandarización de SDN se dan en las áreas de centros de datos
y computación en nube, mientras que los operadores de
telecomunicaciones están impulsando esfuerzos similares para
NFV. Finalmente, una distinción importante es que mientras
NFV puede trabajar en redes existentes porque reside en
servidores e interactúa con el tráfico específico que se les
envía, SDN requiere una nueva construcción de la red donde
los datos y los planos de control están separados. Resumimos la
relación entre SDN y NFV en la Tabla II.
2) Investigación sobre NFV basada en SDN:
Actualmente hay mucho trabajo que implica la
combinación de SDN y NFV para mejorar cualquiera de
ellos; incluyendo: un marco basado en ForCES [61],
monitoreo basado en NFV para SDN [62], un modelo de
abstracción tanto para el modelo de reenvío como para
las funciones de la red [61]. Como muestran estos
esfuerzos, las demandas únicas de NFV requerirán
potencialmente un plano de reenvío masivamente
complejo, mezclando aparatos virtuales y físicos con un
extenso software de control y aplicación, algunos de
 a) API en dirección sur: OpenFlow es la
implementación de hecho de una API con dirección sur para
SDN. Sin embargo, antes de considerar el soporte de NFV,
incluso en los entornos actuales de SDN, OpenFlow no es
de ninguna manera una solución madura [64]. Dado que
Open- Flow tiene como objetivo el manejo de flujo L2-L4,
no tiene soporte de protocolo de capa de aplicación y
control de flujo orientado al interruptor. Por lo tanto, los
usuarios tienen que disponer de un mecanismo adicional
para el control de flujo de la capa superior. Además, la
ejecución de una gran cantidad de correspondencia de flujo
en un solo interruptor (o interruptor virtual) puede causar
dificultades en el rastreo de la red y la degradación del
rendimiento general [65].
Por lo tanto, OpenFlow tendrá que ampliarse para incluir
las capas L5-L7 para poder soportar NFV. Basta y otros [66]
investigaron la actual implementación de OpenFlow en
términos de las operaciones básicas del núcleo como la
calidad de servicio, la clasificación de datos, la creación de
túneles y la carga, concluyendo que es necesario un
OpenFlow mejorado para poder soportar algunas funciones
en un entorno NFV. En una implementación de una función
EPC virtual [9], [67] se amplía OpenFlow 1.2 definiendo
puertos virtuales para permitir la encapsulación y para
permitir el enrutamiento del flujo utilizando el Identificador
de punto final del túnel GTP (TEID).
la comunicación entre los controladores y los VNF. Por
último,
[73] propone una arquitectura que considera el control tanto
de SDN como de NFV.
OpenDaylight [74] es una de las pocas formas de control
SDN que soporta una integración más amplia de tecnologías
en una sola plataforma de control [75]. Un proyecto de
colaboración auspiciado por la Fundación Linux,
OpenDaylight es un marco de código abierto dirigido por la
comunidad y apoyado por la industria para acelerar la
adopción, fomentar la innovación y crear un enfoque más
abierto y transparente para SDN y NFV. El objetivo de la
iniciativa OpenDaylight es crear un marco de referencia para
la programabilidad y el control a través de una solución de
código abierto SDN y NFV. El argumento de OpenDaylight es
que construir sobre un controlador SDN y NFV de código
abierto permite a los usuarios reducir la complejidad operativa,
extender la vida de su infraestructura de hardware existente y
habilitar nuevos servicios y capacidades que sólo están
disponibles con SDN.
C. Resumen: NFV, SDN y Cloud Computing
Para resumir la relación entre NFV, SDN, y la computación en
nube, usamos la Fig. 95. Observamos que cada uno de estos
campos es una abstracción de diferentes recursos:
computación para la computación en nube, red para SDN, y
funciones para NFV. Las ventajas que se derivan de cada uno
de ellos son similares; agilidad, reducción de costos,
dinamismo, automatización, escalamiento de recursos, etc.
La pregunta no es si los NFs serán migrados a la nube, ya
que esta es de hecho la idea general del NFV. Es si la nube
será una pública como Amazon, o si los TSPs preferirán usar
las privadas distribuidas en su infraestructura. En cualquier
Por último, mientras que OpenFlow asume un controlador
lógicamente centralizado, que idealmente puede ser
distribuido físicamente, la mayoría de los despliegues actuales
se basan en un único controlador. Esto no se escala bien y
puede afectar negativamente a la fiabilidad. Además, los
dispositivos de red en un NFVI requieren colaboración para
poder proporcionar servicios, que actualmente no pueden ser
proporcionados por SDN. Por lo tanto, todavía hay una
necesidad de mejorar SDN considerando las arquitecturas
distribuidas [68], [69]. También puede ser importante para los
TSP, los InP y el ETSI considerar otras posibles soluciones
como NETCONF [70].
b) Diseño del controlador: Si bien existen múltiples
controladores que pueden utilizarse en un entorno SDN, todos
ellos requieren mejoras para poder soportar los requisitos de
NFV, especialmente en lo que respecta a la gestión y la
escalabilidad de la red distribuida. OpenNF [71], [65] propone
un plano de control que permite que el procesamiento de
paquetes sea redistribuido a través de una colección de
instancias de NF, y proporciona una ruta de comunicación
entre cada NF y el controlador para la configuración y la toma
de decisiones. Utiliza una combinación de eventos y
actualizaciones de reenvío para hacer frente a las condiciones
de la carrera, la sobrecarga limitada, y acomodar una variedad
de NFs. [72] también diseñó un protocolo para implementar el
caso, habrá que trabajar para que la nube tenga un grado de
portador en términos de rendimiento, fiabilidad, seguridad,
comunicación entre funciones, etc.
Por otro lado, los objetivos del NFV pueden alcanzarse
usando mecanismos no SDN, y confiando en las técnicas
actualmente en uso en muchos centros de datos. Sin embargo, los
enfoques que se basan en la separación de los aviones de control
y de envío de datos, tal y como propone SDN, pueden mejorar el
rendimiento, simplificar la compatibilidad con los despliegues
existentes y facilitar los procedimientos de operación y
mantenimiento. De la misma manera, la NFV es capa z de
apoyar a SDN proporcionando la infraestructura sobre la cual el
software de SDN puede ser ejecutado. Finalmente, la variante
moderna de un centro de datos (la nube y su aspecto de
autoservicio) se basa en la gestión automatizada que se puede
obtener de SDN y NFV. En particular, aspectos como la red
como servicio, balanceo de carga, cortafuegos, VPN, etc., todos
corren en un software instanciado a través de APIs
V. ESTADO DE LA TÉCNICA
A medida que el Instituto Europeo de Normas de
Telecomunicaciones (ETSI) continúa trabajando en el NFV, otras
organizaciones de normalización, proyectos de investigación
académica e industrial y proveedores están trabajando en
paralelo con diversos objetivos, y algunos de ellos en estrecha
colaboración con el ETSI. En esta sección, exploramos estas
actividades de NFV.
5 Cabe destacar
que OpenFlow no es el único protocolo SDN. De la misma
manera, OpenStack no es la única plataforma de computación en la nube. La
razón por la que presentamos sólo estos dos en la Fig. 9 es que, como ya se ha
mencionado, han recibido más atención en general, y con respecto a NFV.
 encadenamiento de funciones de servicio que incluya los
Desvincula las funciones del hardware
protocolos necesarios o extensiones
para reducir el CAPEX y el OPEX del operador de la red, y aumentar la agilidad del servicio
de protocolo para
transmitir la información de la cadena de funciones de servicio
(SFC) y la ruta de la función de servicio
78] a los nodos que intervienen en la ejecución de las
funciones de servicio y a los SFC, así como a los mecanismos
NFV
para dirigir el tráfico a través de las funciones de servicio.
Abstracción de la función
2) Grupo de Investigación del IRTF NFV (NFVRG): El
Grupo de Investigación de Internet (IRTF) ha creado un grupo
AutomatizaciónOrquestación
AislamientoPuesta en común de recursos
de investigación, NFVRG [79], para promover la
Agilidad Virtual- Elasticidad
investigación
zación sobre el NFV. El grupo tiene por objeto organizar
reuniones y talleres en las principales conferencias e invitar a
la publicación de números especiales en publicaciones
conocidas. El grupo se centra en los problemas de
SDN
Abstracción en red
Red de contactos
investigación
APIs Nuberelacionados con los temas de NFV y en reunir a
Abstracción de la computación
una comunidadOpenStack de investigación que pueda abordarlos
OpenFlow conjuntamente, concentrándose en los problemas que se
Crea abstracciones de red paraPermite compartir recursos, permite relacionan no sólo con la creación de redes sino también con
permiten una innovación más rápida, la redla flexibilidad y la puesta en común de recursos, por lo tanto,
los aspectos dela flexibilidad
computación y la gestión
y holísticabeneficios
almacenamiento de lasen
economías
esos de escala
entornos.
Fig. 9. Relación entre NFV, SDN y Cloud Computing 3) Foro ATIS NFV: El ATIS NFV Forum [33] es un grupo
industrial creado por la Alianza para Soluciones Industriales
de Telecomunicaciones (ATIS), un grupo de normas de
A. Actividades de normalización del NFV telecomunicaciones de América del Norte. El grupo tiene
1) Grupo de trabajo de encadenamiento de funciones de como objetivo desarrollar especificaciones para NFV,
servicio de la IETF: Las funciones en un servicio centrándose en aspectos de NFV que incluyen la
determinado tienen requisitos estrictos de encadenamiento interoperabilidad entre operadores y nuevas descripciones de
y/o ordenamiento que deben ser considerados cuando se servicios y procesos automatizados. El Foro ATIS NFV tiene
toman decisiones para colocarlas en la nube. El Grupo de previsto elaborar los requisitos técnicos, el catálogo de las
Tareas de Ingeniería de Internet (IETF) [76] ha creado el capacidades necesarias y el encadenamiento de servicios
Grupo de Trabajo de Encadenamiento de Funciones de necesarios para que un proveedor de servicios o una empresa
Servicios (GT SFC del IETF) [77] para trabajar en el terceros puedan integrar las funciones en una aplicación
encadenamiento de funciones. El GT SFC del IETF tiene comercial. Se espera que este proceso dé lugar a la creación de
como objetivo producir una arquitectura para el especificaciones

que se complementan con los productos de trabajo existentes
en la industria y que amplían el entorno actual para el NFV
interproveedor. El foro también lleva a cabo actividades de
código abierto para la aplicación de estas capacidades en el
software.
4) Foro de la banda ancha: El Foro sobre la banda ancha
(Foro BB)
80] es un consorcio industrial dedicado a desarrollar las
especificaciones de la red de banda ancha. Entre sus miembros
se encuentran empresas de redes de telecomunicaciones y
proveedores de servicios, vendedores de dispositivos y
equipos de banda ancha, consultores y laboratorios de pruebas
independientes (ITL). BB Forum colabora con el ETSI tras
acordar una relación de enlace formal en 2013. El Foro BB
está trabajando en la forma de utilizar la NFV en la aplicación
de la red de banda ancha multiservicio (MSBN). Para ello, el foro
tiene muchos temas de trabajo en curso, entre ellos: la
migración a NFV en el contexto de TR-178 (WT-345), la
introducción de NFV en la MSBN (SD-340), la pasarela
virtual de negocios (WT-328), el encadenamiento flexible de
servicios (SD-326) [81].
5) Estandarización de los paradigmas
relacionados: Además de los esfuerzos de normalización
de la NFV, otros órganos siguen trabajando en la
normalización de campos relacionados, SDN y computación
en nube, que también pueden desempeñar un papel
importante en el éxito de la NFV. El DMTF definió el
Formato de Virtualización Abierta (OVF)
82] para abordar la portabilidad y el despliegue de máquinas
físicas, máquinas virtuales y aparatos. OVF permite el
empaquetamiento y la distribución segura de máquinas o aparatos
virtuales, proporcionando portabilidad entre plataformas y un
despliegue simplificado a través de múltiples plataformas,
incluyendo entornos de nube. OVF ha sido adoptado por la
ANSI como norma nacional y por la ISO como la primera norma
internacional de virtualización y nube. Aprovecha el Modelo
Común de Información (MCI) del DMTF [83], cuando procede,
para permitir que el software de gestión comprenda claramente y
mapee fácilmente las propiedades de los recursos mediante el uso
de un estándar abierto. El OVF y el CIM pueden utilizarse como
una opción para capturar parte o la totalidad del paquete VNF
y/o el descriptor de la Unidad de Despliegue Virtual (VDU) [18],
[84]. Aunque OVF hace un gran trabajo al permitir el
aprovisionamiento de cargas de trabajo a través de varias nubes,
sigue siendo insuficiente para las aplicaciones de la nueva era de
la nube y la gestión del tiempo de ejecución.
De la misma manera, la ONF está normalizando el protocolo
OpenFlow y las tecnologías relacionadas. ONF define OpenFlow
como la primera interfaz de comunicaciones estándar definida
entre las capas de control y reenvío de una arquitectura SDN.
La ONF cuenta con más de 123 empresas miembros, entre las
que se incluyen proveedores de equipos, empresas de
semiconductores, empresas de informática, empresas de
software, proveedores de servicios de telecomunicaciones, etc.
En el cuadro III se resumen todas las actividades de
normalización del VNM y las tecnologías conexas. En
general, puede decirse que hay suficiente participación de los
organismos de normalización en las actividades de VNIF. Si
bien muchos de ellos trabajan en colaboración con el ETSI,
algunos de ellos, como ATIS y 3GPP SA5, han identificado y
están trabajando en aspectos específicos de la VFN que aún no
han sido suficientemente desarrollados por el ETSI. Lo que
queda por ver es si el resultado en términos de normas
coincidirá con la velocidad con la que los vendedores y los
proveedores de servicios de telecomunicaciones proponen
soluciones de NFV.
B. Proyectos de colaboración del NFV
1) Zoom: Zero-time Orchestration, Operations and Man-
agement (ZOOM) [85] es un proyecto del TM Forum que tiene
como objetivo definir un entorno de operaciones necesario para
permitir la desagregación y la gestión de las FNV, e identificar
nuevos enfoques de seguridad que protejan a las FNV y las
FNV. Para lograr esos objetivos, el proyecto realiza
periódicamente una serie de demostraciones prácticas de
tecnología, cada una de las cuales se desarrolla a partir de lo
que llaman un proyecto catalizador. Cada proyecto catalizador
es patrocinado por uno o más operadores de red y proveedores
de equipo y software en una demostración del mundo real. El
proyecto actualmente ejecuta alrededor de 9 catalizadores con
un enfoque en aspectos NFV como la gestión automatizada de
extremo a extremo, la orquestación de seguridad, el modelado
de funciones y servicios, y el uso de grandes tecnologías de
datos y principios de software abierto para la colocación de la
carga de trabajo.
2) Plataforma abierta para el NFV (OPNFV): OPNFV [86] es
un proyecto de código abierto fundado y alojado por la
Fundación Linux, y compuesto por TSPs y vendedores. Su
objetivo es establecer una plataforma de referencia de código
abierto, integrada y de grado de operador para avanzar en la
evolución del NFV y garantizar la coherencia, el rendimiento
y la interoperabilidad entre los múltiples componentes de
código abierto. El primer resultado del proyecto se denomina
OPNFV Arno [87], y fue publicado en junio de 2015. El
lanzamiento proporciona una construcción inicial de los
componentes del NFVI y del Gestor de Infraestructura Virtual
(VIM) de la arquitectura del ETSI. Está enfocado al
desarrollador, y por lo tanto puede ser usado para explorar
despliegues de NFV, desarrollar aplicaciones VNF, o para
evaluar el rendimiento de NFV y para usar pruebas basadas en
casos. En particular, Arno tiene capacidades de integración,
despliegue y prueba de componentes de otros proyectos como
Ceph, KVM, OpenDaylight, OpenStack y Open vSwitch.
Además, los usuarios finales y los desarrolladores pueden
desplegar sus propios VNF o los de terceros en Arno para
probar su funcionalidad y rendimiento en diversos escenarios
de tráfico y casos de uso.
3) OpenMANO: OpenMANO [88] es una fuente abierta
proyecto dirigido por Telefónica, que tiene como objetivo la
aplicación del marco NFV MANO del ETSI. En concreto,
intenta abordar aspectos relacionados con el rendimiento y la
portabilidad aplicando los principios de la Enhanced Platform
Awareness (EPA) [89]. La arquitectura de OpenMANO está
compuesta por tres componentes principales: openmano,
openvim y una interfaz gráfica de usuario (GUI). OpenMANO
tiene una interfaz con dirección norte (API de openmano),
basada en REST, en la que se ofrecen servicios MANO que
incluyen la creación y eliminación de plantillas VNF,
instancias VNF, plantillas de servicio de red y servicio de red
en posiciones. Openvim es una implementación de un
administrador de infraestructura virtual ligero y específico de
NFV que interactúa directamente con los nodos de
computación y almacenamiento en el NFVI, y con un
controlador de flujo abierto para crear la topología de la red de
infraestructura. Ofrece una interfaz de dirección norte basada
en REST (API openvim) donde se ofrecen servicios de nube
mejorados que incluyen la gestión del ciclo de vida de
imágenes, sabores, instancias y redes. La interfaz REST de
openvim es una versión extendida de la API de OpenStack
para acomodar a la EPA.
4) Redes de nubes móviles (MCN): MCN [90] es un con-
sorcio compuesto por operadores de redes, proveedores de
nubes, ven- dores, institutos universitarios y de
investigación, así como PYMES. El objetivo es nublar
todos los componentes de una red móvil
 TABLA III
RESUMEN DE LOS ESFUERZOS DE NORMALIZACIÓN DE LA FUNCIÓN DE LA RED

DescripciónÁrea de enfoqueDescripción del trabajo relacionado con el NFV

Grupo de normas del ETSI
dirigido por la Marco arquitectónico NFV, descripción de la infraestructura, MANO,
ETSI
industria NFV seguridad y confianza, resistencia y métricas de calidad de servicio.
El grupo de trabajo de gestión
Banda Trabajando en colaboración con el ETSI. Estudiando la gestión de las
3GPP SA5 de telecomunicaciones
ancha funciones de la red 3GPP virtualizada.
del 3GPP
móvil
Proponer un nuevo enfoque para la prestación y el funcionamiento de los
IETF SFC servicios, un
Grupo de Trabajo de la IETF NFV arquitectura para el encadenamiento de funciones de servicio, la gestión
WG y las implicaciones de seguridad.
Organizar actividades de investigación relacionadas con el VNL tanto en
IRTF el mundo académico como en el industrial mediante talleres, reuniones
NFVRG Grupo de Investigación del IRTF NFV
de grupos de investigación, etc. en conferencias de primer orden.
ATIS NFV
Desarrollando especificaciones para el NFV, centrándose en la
Foro Grupo de Normas Dirigido por la IndustriaNFV
intertransportación la
interoperabilida
Estandarización del protocolo OpenFlow y tecnologías conexas. Define
Consorcio liderado por la
ONF SDNOpenFlow como la primera interfaz de comunicaciones estándar definida
industria para la
entre las capas de control y reenvío de una arquitectura SDN.
estandarización de
OpenFlow
El OVF del DMTF y el CIM pueden utilizarse como una opción para
DMTF OVF Consorcio liderado por la industria capturar parte o todo el paquete VNF y/o el Descriptor VDU [18].
Nube
Consorcio liderado por la industria que desarrolla las especificaciones
NFV en las redes
de la
dered
banda
de banda
anchaancha
Colaborar con el Instituto Europeo de Normas de Telecomunicaciones (ETSI) para lograr un enfoque coherente y una arquitectura común para la in
Foro de BB

de acceso - Red de Acceso Radioeléctrico (RAN); el núcleo - e implementar una plataforma de gestión/orquestación para
EPC; los servicios - Subsistema Multimedia IP (IMS), Redes la provisión, configuración, monotorización y optimización
de Entrega de Contenido (CDN) y Señalización Digital (DSS); automatizada de las Funciones de Red como Servicio
los Sistemas de Apoyo Operacional (OSS) y los Sistemas de (NFaaS) sobre infraestructuras virtualizadas de red/TI.
Apoyo Empresarial (BSS). 7) CONTENIDO: CONTENIDO [93] es un
5) UNIFY: UNIFY [91] tiene como objetivo proyecto financiado por la UE que tiene como objetivo
investigar, desarrollar y evaluar los medios para ofrecer una arquitectura de red y una solución de
orquestar, verificar y observar la prestación de servicios infraestructura general para facilitar el despliegue de la
de extremo a extremo desde los hogares y las redes de computación en nube convencional así como la computación en
empresas a través de la agregación y las redes básicas a nube móvil. Los principales objetivos del proyecto
los centros de datos. Con este fin, el proyecto planea incluyen:
desarrollar una plataforma de creación de servicios
automatizada y dinámica, aprovechando una arquitectura
de encadenamiento de servicios finos. También crearán
un modelo de abstracción de servicios y un lenguaje de
creación de servicios para permitir la colocación
dinámica y automática de componentes de redes,
computación y almacenamiento a través de la
infraestructura. Por último, desarrollarán un orquestador
global con algoritmos de optimización para asegurar la
colocación óptima de los componentes de servicio
elementales a través de la infraestructura.
6) T-NOVA: T-NOVA [92] tiene como objetivo
promover el con- cepto de VFV, proponiendo un marco
habilitador, que permita a los operadores no sólo
desplegar VNF para sus propias necesidades, sino
también ofrecerlos a sus clientes, como servicios de
valor añadido. Para este propósito, T-NOVA aprovecha las
arquitecturas de SDN y de gestión de nubes para diseñar
(1) proponiendo una solución de virtualización de dominio
y tecnología cruzada que permita la creación y el
funcionamiento de cortes de infraestructura, incluidos
subconjuntos de la red y recursos físicos computacionales,
y (2) apoyando el aprovisionamiento dinámico de servicios
de extremo a extremo a través de los segmentos de la red,
ofreciendo garantías de calidad de servicio variables, en toda
la red integrada.

Resumen: Para resumir, en el cuadro IV presentamos todos

los proyectos con su objetivo principal, su enfoque con
respecto al VAN y las áreas relacionadas, y las entidades
que los dirigen o financian. Todos estos proyectos se guían
por las propuestas derivada s de la normalización descrita
anteriormente, en particular el ETSI, el 3GPP y el DMTF.
Es interesante observar que los tres proyectos industriales
(ZOOM, OPNFV y OpenMANO) estudiados se centran en
MANO. Esto subraya la importancia de MANO en NFV.
MANO es un aspecto crítico para asegurar el correcto
funcionamiento del NFVI así como de los VNF. Al igual
que las funciones desacopladas, el NFV exige un cambio
de los modelos de gestión de redes impulsados por
dispositivos a los que son conscientes de las necesidades de
orquestación de las redes que no sólo contienen equipos
heredados, sino también VNF. Los modelos mejorados
deberían haber mejorado las operaciones, la administración,
el mantenimiento y el aprovisionamiento centrándose en la
creación y la gestión del ciclo de vida de las funciones tanto
físicas como virtualizadas. Para que los VNF tengan éxito,
todos los probables desafíos de la MANO deben abordarse
en la actual fase inicial de especificación, definición y
diseño, en lugar de hacerlo más tarde, cuando comiencen los
despliegues reales a gran escala.

C. Implementación del NFV

Con el fin de demostrar la posibilidad de implementar las
ideas propuestas por el NFV, y para determinar el
rendimiento char-
 TABLA IV
RESUMEN DE LOS PROYECTOS DE VIRTUALIZACIÓN DE LA FUNCIÓN DE RED

Líder y/o
Tipo de proyecto Áreas de interésObjetivo principal
Financia
ción
Asociación de Permitir un despliegue más rápido de los servicios mediante
ZOOM Foro TM NFV
SPs la automatización del proceso de aprovisionamiento y la
modernización de los modelos de OSS/SEV.
Proyecto de colaboraciónFundación Linux Construir una plataforma de referencia de código abierto para avanzar en la evolución del NF
OPNFV NFV
OpenMANO Proyecto VendorTelefonicaSDN , NFVIimplementación del marco MANO del ETSI.
La Unión Europea
MCN Proyecto de investigación SDN, NFV Nublar todos los componentes de la operación de una red móvil.
Europeo Desarrollar una plataforma de creación de servicios
Proyecto de investigación de la UNIFY Unión NFV automatizada y dinámica, aprovechando el encadenamiento
de servicios finos.
La Unión Europea
T-NOVA Proyecto de investigación SDN, NFV Diseñar e implementar una plataforma MANO para el NFV.

Proyecto de investigación de CONTENTROS Redes Proporcionar una plataforma tecnológica que interconecte
Europeo Móviles, recursos computacionales distribuidos geográficamente y que
Unión Nube pueda soportar una variedad de servicios en la nube y en la
nube móvil.
Fundación
Identificar
OpenStack los requisitos necesarios para desplegar, gestionar y ejecutar servicios de telecomunicaciones so
OpenStack Grupo de Trabajo Nube, NFV
Colaboración Fundaci
OpenDaylight SDN, NFV Desarrollar una plataforma abierta para SDN y NFV.
Proyec ón Linux
to

acterísticas, ya se han puesto en práctica varios casos de uso al decidir la ampliación o la reducción de la escala. También
del VNF, en su mayoría basados en los definidos por el ETSI incluye una plataforma en nube Helion OpenStack para el
[9]. Estos se han basado principalmente en la implementación funcionamiento de las FNV.
de funciones virtuales únicas como el enrutamiento [94], el 2) Laboratorio abierto de la NFV de Huawei: El laboratorio
Servidor de Acceso Remoto de Banda Ancha [95], el servidor abierto de la NFV de Huawei
de políticas [96], la inspección profunda de paquetes [97], [112] tiene como objetivo proporcionar un entorno
EPC [98], [73], RAN [99], [100], [101], [102], monitoreo para garantizar que las soluciones de NFV y la
[62], CPE [103], [104], [105], [106], [107], [108], GPRS infraestructura de grado de portador sean compatibles con
y control de acceso [110], en ambientes de nubes. Todo esto
se origina en la comunidad de investigación. Tal vez no sea
sorprendente que las mayores implementaciones hayan
surgido de los proveedores de equipos. En el resto de esta
sección, presentamos algunas implementaciones clave de
NFV y productos de la industria.
1) HP OpenNFV: El HP OpenNFV [111] es una
plataforma, basada en la arquitectura de referencia NFV
de HP, sobre la que se pueden construir dinámicamente
servicios y redes. La Arquitectura de Referencia HP NFV
está alineada para proporcionar soluciones a cada uno de
los bloques funcionales definidos en la arquitectura
ETSI, como punto de partida. Las partes de la
arquitectura NFVI y VNF incluyen principalmente
servidores HP y productos de virtualización, mientras
que MANO se basa en tres soluciones: NFV Director,
NFV Manager y Helion OpenStack. El NFV Director es
un orquestador que gestiona automáticamente el servicio
de extremo a extremo, mediante la gestión de sus VNF
constituyentes. También lleva a cabo la gestión global de
los recursos, asignando recursos de un fondo común
apropiado basado en las políticas de gestión global de
recursos. Los directores de las FNV son responsables de
las acciones del ciclo de vida de las FNV, por ejemplo,
las nuevas normas del NFV y con el OPNFV [86]. El
laboratorio se dedica a ser abierto y colaborativo,
expandiendo las innovaciones de servicios conjuntos con
los socios, y desarrollando el ecosistema abierto de NFV
para agregar valores y ayudar a los clientes a lograr el éxito
comercial. También planean colaborar con la comunidad de
código abierto para innovar en las tecnologías de NFV para
proporcionar casos de uso para la interoperabilidad de
múltiples proveedores en torno a NFVI, y los servicios
basados en VNF.
3) Plataforma de Red Abierta de Intel (Intel ONP): Intel
ONP
[113] es un ecosistema compuesto por varias iniciativas
para avanzar en soluciones abiertas para NFV y SDN. Las
iniciativas se centran en el desarrollo de productos Intel
(como el servidor Intel ONP), la participación en
actividades de desarrollo y estandarización de código
abierto y la colaboración con la industria para la prueba de
con- ceptos y ensayos.
El principal resultado de la ONP hasta ahora es el
resiente todos los aspectos de los servicios, funciones y
recursos. El orquestador VNF tiene reglas de política que,
combinadas con las órdenes de servicio y el estado de los
recursos disponibles, determinan la ubicación de las funciones
que componen el servicio, así como las conexiones entre ellas.
El gestor del VNF utiliza un modelo de datos/recursos
estructurado de acuerdo con las reglas del TMF y se utiliza el
concepto de "operaciones derivadas" para gestionar los VNF.
Las operaciones derivadas se utilizan para integrar el estado
de los recursos disponibles con los compromisos de recursos
para las funciones de un determinado servicio de VNF. La
principal diferencia entre la MANO de VFN del ETSI y la
Nube de VFN es que, a diferencia de la primera, la segunda
considera tanto la gestión como la orquestación como
aplicaciones que pueden ejecutarse a partir de un modelo de
datos unificado.
5) Alcatel-Lucent CloudBand: La banda de nubes de
Alcatel-Lucent
[115] es una plataforma de dos niveles que implementa el
NFV. Primero, incluye nodos que proveen recursos como
VMs y almacenamiento, y luego, el Sistema de
Administración CloudBand que es el corazón funcional del
proceso. Funciona como un disco de trabajo que toma
decisiones de alojamiento y conexión basada s en políticas,
actuando a través de las API de gestión de la nube. Las
funciones virtuales se despliegan utilizando recetas que
definen paquetes de componentes desplegables e instrucciones
para su conexión. Las recetas se pueden utilizar para
establecer políticas y determinar cómo se instancian y
conectan componentes específicos. La plataforma utiliza la
tecnología SDN de Nuage [116] y sus enlaces relacionados
para crear un marco de conexión ágil para el conjunto de
nodos y funciones, y para facilitar la gestión del tráfico.
Alcatel-Lucent se asoció recientemente con RedHat [117]
para que este último pudiera llenar los vacíos requeridos para
usar CloudBand y OpenStack para promover la inclusión de
más requisitos de NFV en el OpenStack aguas arriba y, por lo
tanto, construir una solución optimizada para los entornos de
Servidor Intel ONP. Esta es una arquitectura de referencia que
integra ingredientes de código abierto y hardware optimizado
para SDN/NFV. Su objetivo es permitir la manejabilidad
exponiendo la salud, el estado y la disponibilidad de recursos,
para una colocación y configuración óptima de la carga de
trabajo. Su pila de software consiste en software de código
abierto liberado basado en el trabajo realizado en proyectos de
la comunidad, incluidas las contribuciones proporcionadas por
Intel. Algunos de los ingredientes clave del software de
código abierto que forman la pila de software del servidor Intel
ONP son OpenStack, OpenDaylight, DPDK, Open vSwitch y
Linux KVM.
4) CloudNFV: CloudNFV [114] es una plataforma de
computación en nube, NFV y SDN que resulta de la
cooperación entre seis compañías (6WIND, CIMI
Corporation, Dell, EnterpriseWeb, Overture Networks, y
Qosmos). CloudNFV propuso su propia arquitectura NFV
[114] que se compone de 3 elementos principales: la
virtualización activa, el orquestador de NFV, y el
administrador de NFV. La virtualización activa es un modelo
de datos que representa
NFV de las empresas de telecomunicaciones. Dentro de esta
colaboración, el nodo CloudBand utiliza la plataforma
OpenStack de RedHat Enterprise Linux como VIM.
6) Broadcom Open NFV: La forma de placa de
Broadcom Open NFV [118] tiene como objetivo acelerar la
creación de aplicaciones NFV a través de los pro- cesores
de sistemas múltiples en chip (SoC) [119], y permitir a los
proveedores de sistemas ser capaces de migrar funciones
virtuales entre plataformas basadas en soluciones de varios
proveedores. La plataforma de Broadcom soporta
estándares abiertos de API como el Open Data Plane
(ODP) de Linaro[120] para acceder a los componentes de
aceleración para escalar la funcionalidad crítica y reducir el
tiempo de comercialización. El ETSI ha aceptado
recientemente un concepto de prueba de migración e
interoperabilidad del estado VNF en el que Broadcom está
demostrando una implementación de un EPC y migrando el
estado de función virtual de operar en una arquitectura de
conjunto de instrucciones (ISA) a una ISA diferente.
7) Estrategia de Red Abierta de Cisco: La
Estrategia de Red Abierta (OPN) de Cisco [121] incluye
una Plataforma de Servicios Evolutivos (ESP) y una Red
Programable Evolutiva (EPN). La ESP y la EPN incluyen
un orquestador de servicios, un gestor de VNF y un
controlador de SDN, todos ellos destinados a proporcionar
implementaciones para algunos de los bloques funcionales
del marco MANO del ETSI. El orquestador de servicio es
responsable de proporcionar la gestión del ciclo de vida
global a nivel de servicio de la red. El gestor de VNF
proporciona una gestión del ciclo de vida de VNF escalable
y automatizada, que incluye la creación, el suministro y la
supervisión de VNF tanto de Cisco como de terceros. El
El gestor del FVN también es responsable de la ampliación en el borde de servicio. Permite a los TSP desplegar
y reducción de los FVN en función de las demandas de instantáneamente VNF bajo demanda en las instalaciones del
servicio dinámicas y fluctuantes. Utiliza gestores de cliente. Combina el acceso a la portadora Ethernet con los
recursos de cloud computing como OpenStack y VMware beneficios de la virtualización, la apertura y los servicios
en la capa de VIM para configurar y aprovisionar recursos definidos por software. El resultado es una plataforma única
de computación y almacenamiento en las redes de centros tanto para los servicios como para el acceso a la red, que
de datos de varios proveedores. Por último, el controlador permite subir, bajar, expandir y eliminar VNF de manera
SDN es responsable de conectar los servicios virtualizados dinámica para que los recursos de computación y
(un VNF o un conjunto de VNF encadenados) a las VPN almacenamiento se utilicen sólo cuando se necesiten. Además,
del proveedor de servicios, a Internet o a ambos. Está admite múltiples conexiones por cable y sin cable a la WAN,
diseñado en torno a estándares abiertos y API y utiliza un lo que permite el acceso a todos los extremos
enfoque holístico basado en sistemas para gestionar centros
de datos de múltiples proveedores y arrendatarios, así como
un modelo operativo común basado en políticas para reducir
los costes.
8) F5 Software Defined Application Services: F5
Software Defined Application Services (F5 SDAS) [122],
[123], [124] proporciona capacidades de Capa 4-7 para
complementar la red existente de Capa 2-3 y computar
iniciativas como SDN. Permite la inyección de servicios, el
consumo, la automatización y la orquestación a través de un
marco operativo unificado de recursos mancomunados. Está
compuesto por tres componentes clave: (1) La plataforma de
servicio de aplicación apoya la programabilidad de las rutas
de control y de datos. Es extensible y permite la creación de
nuevos servicios.
(2) El tejido de servicios de aplicación proporciona
servicios básicos como escalabilidad, aislamiento de
servicios, multiarrendamiento e integración con la red, y (3)
Los servicios de aplicación, que son el corazón del SDAS
F5, son un rico catálogo de servicios en todo el espectro de
entrega de aplicaciones.
9) ClearWater: ClearWater [125] es una
implementación de código abierto de un IMS construido
usando métodos de desarrollo web para proveer servicios
de voz, video y mensajería a los usuarios. Se apoya en gran
medida en los patrones de diseño establecidos para la
construcción y despliegue de aplicaciones web escalables,
adaptando estos patrones de diseño para que se ajusten a las
restricciones de SIP e IMS. En particular, todos los
componentes se escalan horizontalmente usando un simple
balanceo de carga sin estado. Además, el estado de larga
vida no se almacena en los nodos del clúster, evitando la
necesidad de esquemas complejos de replicación de datos.
En cambio, el estado de larga vida se almacena en nodos de
servicio de fondo utilizando tecnologías de almacenamiento
optimizadas para la nube, como Cassandra. Por último, las
interfaces entre los componentes SIP del front-end y los
servicios del back-end utilizan API de servicios web
RESTful. Las interfaces entre los diversos componentes
utilizan el agrupamiento de conexiones con el reciclado
estadístico de las conexiones para asegurar que la carga se
distribuya uniformemente a medida que se añaden y
eliminan nodos de cada capa.
Metaswitch [126] contribuyó con el código base inicial
del proyecto ClearWater a los desarrolladores de software e
integradores de sistemas, y continúa impulsando la
evolución del código base.
10) Overture Virtual Service Edge (vSE): Obertura vSE
24] es una plataforma abierta de Ethernet para alojar VNF
 TABLA V
RESUMEN DE LAS IMPLEMENTACIONES DEL ESTADO DEL ARTE DE LA NFV

FuncionalidadPlataformaEstándares de conducción
HP
OpenNFV Arquitectura de referencia de NFV basada en estándares abiertos,
OpenStackETSI
laboratorios como una caja de arena en la que los portadores y los
vendedores de equipos pueden probar el vEPC.
Laboratorio abierto de
Apoya
la NFV
el desarrollo de la infraestructura, plataformas y servicios del NFV.
OpenStack, OpenDaylight ETSI
Proporciona a los desarrolladores una plantilla validada para
Intel ONP desarrollar y mostrar rápidamente la próxima generación de OpenStack, OpenDaylight3GPP o TMF
soluciones de red con conocimiento de la nube.
Proporciona una plataforma para la creación, implementación y administración de servicios de redes virtuales.
CloudNFV OpenStack TMF y ETSI
Alcatel Se puede utilizar para las necesidades estándar de TI, así como Plataforma OpenStack de
CloudBand ETSI
para los CSP que están moviendo las redes móviles a la nube. Red Hat Linux
NFV Migrar
de banda
las ancha
funciones virtuales entre plataformas basadas en soluciones de varios proveedores.
ETSI
Entrega de servicios automatizados, mejora del uso de la red y
Cisco ONS del centro de datos, rápido despliegue de ofertas personalizadas. OpenStack, OpenDaylightETSI

Sistema extensible, contextualizado y multiarrendatario para la prestación de servicios

OpenStack, BIG-IP, BIG-IQ [122]
IETF, 3GPP, GSMA, ETSI, ONF
F5 SDAS
Control de llamadas basado en SIP para comunicaciones de voz Apache Cassandra, 3GPP IMS, ETSI
ClearWater y video y para aplicaciones de mensajería basadas en SIP. Memcached TS
Aloja múltiples VNF en una caja, acelera la creación del servicio,
Linux Overture Ensemble OSA [
Obertura vSEactivación y aseguramiento, Disminuir el inventario y los costos de administración, Optimizar la flexibilidad del servicio, Eliminar los rollos d

de los clientes. establecerse. En esta sección se analizan las direcciones

La plataforma implementa un acceso Ethernet como VNF, y cruciales de investigación que serán invaluables a medida que el
se basa en una plataforma de virtualización que comprende un VNIF madure.
hipervisor KVM/QEMU de Linux, un conmutador virtual
optimizado, e incluye soporte para la integración de
OpenStack con otro producto - el Ensemble Service
Orchestrator.

Resumen: En la Tabla V resumimos las diferentes

implementaciones de última generación indicando su
funcionalidad, los organismos de estándares que siguen de
cerca y las plataformas en las que funcionan. Cabe señalar que,
aunque el NFV está cobrando impulso, sigue siendo una
tecnología emergente y soluciones basadas en especificaciones
finales, y las implementaciones generalizadas para los
usuarios finales pueden tardar unos años en aparecer. Como
muestra la encuesta anterior, muchas organizaciones están
invirtiendo y están dispuestas a probar soluciones basadas en
NFV. Además, se puede observar a partir de estas primeras
implementaciones y plataformas, que dos aspectos reaparecen
en un gran número de ellas: (1) la gran atención que se presta al
código abierto, y (2) la capacidad de las actuales tecnologías
SDN y de nube para soportar NFV.

VI. RETOS DE INVESTIGACIÓN

Incluso con todos los beneficios previstos, y a pesar de la

inmensa velocidad con la que está siendo aceptado tanto por el
mundo académico como por la industria, el VNL está todavía
en sus primeras etapas. Aún quedan aspectos importantes que
deben investigarse y prácticas estándar que deben
A. Gestión y orquestación
El despliegue del NFV supondrá un gran desafío para los
sistemas de gestión actuales y requerirá cambios
significativos en la forma en que se despliegan, operan y
gestionan las redes. Esos cambios son necesarios, no sólo
para proporcionar soluciones de red y de servicio como
antes, sino también para aprovechar el dinamismo y la
flexibilidad que permite el NFV [127], [128]. Es probable
que se den situaciones en las que las funciones que prestan
un servicio a un cliente determinado estén dispersas en
diferentes grupos de servidores. El reto será entonces tener
un nivel aceptable de orquestación para asegurarse de que, a
nivel de cada servicio (o usuario), todas las funciones
necesarias se instancien de manera coherente y a demanda,
y para garantizar que la solución siga siendo manejable
[129].
El ETSI está trabajando en un marco MANO [18]
necesario para el aprovisionamiento de FNV y las
operaciones conexas, como la configuración de las FNV y
la infraestructura en que se ejecutan estas funciones. En un
esfuerzo relacionado, Cloud4NFV [130],
131] ha propuesto una plataforma de gestión de extremo a
extremo para los VNF, que se basa en la especificidad
arquitectónica del ETSI. Clayman y otros [132] describen
una arquitectura basada en un orquestador que asegura la
colocación automática de los nodos virtuales y la asignación
de los servicios de red en ellos con el apoyo de un sistema
de vigilancia que recoge e informa sobre el
comportamiento de los recursos. NetFATE [133] propone
un enfoque de orquestación para las funciones virtualizadas,
teniendo en cuenta las cadenas de servicios que necesitan los
flujos de tráfico y la QoE deseada. Además, se han
propuesto otros marcos y arquitecturas MANO en [134],
[135], [136], [137], [138], [139], [140].
 TABLA VI
RESUMEN DE LOS CAMBIOS EN EL CONSUMO DE ENERGÍA A PARTIR DE LA VIRTUALIZACIÓN DE LAS FUNCIONES DE LA RED

Tráfico Eficiencia Potencia Ahorro de energíaAhorro acumulativo

total total
(EXABYTES/MES) (MBITS/J) (MWAT (MWATTS) (2013 - 2018) GJ
TS)
Red de base 1, 153.05 0.0328510 116, 203 0.0
9
EPC virtual 1, 153.05 0.0422222 92, 159.8 24, 044. 15.0 × 10
9
CPE virtual 1, 205.11 0.0352130 113.500 2, 703.635.5 × 10
9
RAN virtual 1, 227.88 0.0463708 89, 599.5 26, 604. 47.5 × 10
9
CDN de video 810.22 0.0346562 80, 029.3 36, 174. 67.5 × 10
virtual
Banda ancha virtual 7
Puerta de enlace de 1, 169.69 0.0333016 116.260 −76.794 −1.7 × 10
la red 6
1, 151.91 0.0328255 116, 180 22.95173.8 × 10
Borde de proveedor
virtual

Sin embargo, todavía hay algunas cuestiones abiertas. Los físicos que operan en cualquier punto, y por lo tanto reducir sus
enfoques actuales se centran en la gestión de NFV, sin dejar facturas de energía. Sin embargo, el NFV probablemente hará de
de lado los desafíos de gestión en SDN [141]. Mientras que los centros de datos una parte integral de las redes de
los enfoques de gestión tradicionales deben ser mejorados telecomunicaciones. De acuerdo con un análisis en el informe
para poder comercializar cada uno de ellos, las demandas de SMARTer 2020 de la GeSI [144], la nube, si fuera un país,
gestión son aún mayores en los entornos que incluyen ambos. ocuparía el 6º lugar en el mundo en términos de su demanda
En estos casos, ya no sólo es necesario crear flujos de tráfico de energía, y sin embargo se espera que esta demanda aumente
dinámicos, sino que los puntos de conmutación (ubicación de en un 63% para el año 2020 [145]. Mientras que algunos
las funciones) también están cambiando di- namante. Por lo progresos en la computación en nube eficiente en energía han
tanto, una solución de gestión completa debe combinar los sido
requisitos de SDN y NFV.
Además, el apoyo a la interoperabilidad es un requisito
clave para el NFV. Sin embargo, si observamos el trabajo del
marco del ETSI MANO, la mayor parte de los esfuerzos se
han centrado en la definición de las inter faces
intraoperadoras, sin directrices claras sobre la
interoperabilidad. Por eso, aunque los productos de los
proveedores actuales están "basados en el marco MANO del
ETSI", la mayoría de ellos utilizan modelos personalizados y/o
representación para funciones y servicios. Además, la
necesidad de dinamismo en la función significa que es
probable que las funciones se trasladen de una VM a otra. Esto
subraya la importancia de prestar mayor atención a las
posibilidades de un mecanismo de vigilancia de la
disponibilidad como parte de la solución de gestión de extremo
a extremo. Por último, si bien el marco de la MANO de VFN
propuesto por el ETSI tiene en cuenta las necesidades de
gestión y orquestación de las funciones tanto virtualizadas
como no virtualizadas mediante interfaces con las funciones
tradicionales de gestión de red OSS/BSS, la relación entre
ellas aún no está plenamente definida [142].

B. Eficiencia energética
Dado que las facturas de energía representan más del 10%
del OPEX de los TSP [143], la reducción del consumo de
energía es uno de los puntos fuertes de venta de NFV. El
argumento es que con la flexibilidad y la capacidad de escalar
las asignaciones de recursos hacia arriba y hacia abajo, a
medida que las demandas de tráfico van y vienen, los PST
podrían reducir potencialmente el número de dispositivos
las crecientes necesidades energéticas de los centros de
datos siguen recibiendo mucha atención [146], [147]. Por lo
tanto, ha y una necesidad urgente de estudiar si el NFV
cumplirá con sus expectativas de ahorro de energía, o si al
igual que los NFs el consumo de energía sólo se transferirá
a la nube.
China Mobile publicó recientemente [148] sus
experiencias en el despliegue de una Red de Acceso a la
Radio en la Nube (C-RAN). Una de las pruebas se realizó
en sus redes 2G y 3G, donde se observó que al centralizar la
RAN, el consumo de energía podría reducirse en un 41%
debido al aire acondicionado compartido. Además, Shehab y
otros [149] analizaron el potencial técnico de ahorro de
energía asociado al cambio
software de negocios de EE.UU. a la nube. Los resultados
sugirieron un potencial sustancial de ahorro de energía. De
hecho, los autores señalaron que si todos los usuarios
empresariales de EE.UU. trasladaran su correo electrónico,
software de productividad y software de CRM a la nube, la
huella de energía primaria de estas aplicaciones de software
podría reducirse hasta en un 87%.
Con el fin de determinar el posible efecto del consumo de
energía en la evolución a los VNF, Bell Labs ha ampliado
recientemente su herramienta G.W.A.T.T. [143]. La
herramienta es capaz de mostrar el efecto de la
documentación técnica detallada. Por ejemplo, el índice de
redes visuales de Cisco [150] pronostica que el tráfico global
anual de IP alcanzará los 1000 exabytes en 2016. Sobre esta
base, los valores de tráfico (mensual, 2015) del Cuadro VI
parecen ser demasiado elevados, pero actualmente no es
posible saber cómo se derivan estos valores. Por lo tanto,
esperamos que la eficiencia energética de las NF basadas en la
nube siga recibiendo atención. Las NFV pondrán a las InPs
bajo una presión aún mayor para gestionar el consumo de
energía
138] no sólo para reducir los gastos de energía, sino también
para cumplir con las normas reglamentarias y ambientales.
Serán importantes los temas relacionados con el hardware de
eficiencia energética que podrían permitir reducir la velocidad
de la CPU y apagar parcialmente algunos componentes del
hardware, la colocación de funciones más conscientes de la
energía, la programación y los algoritmos de encadenamiento.
Un ejemplo podría ser el seguimiento de los precios más
baratos de los costos de la energía y la adaptación de la
topología de la red y/o los parámetros de funcionamiento para
reducir al mínimo el costo de funcionamiento de la red [60]. Sin
embargo, todo esto debería considerarse cuidadosamente para
asegurar que haya un equilibrio en la compensación entre la
eficiencia energética y el rendimiento de la función o los
acuerdos de nivel de servicio.
C. Rendimiento del NFV
El concepto de NFV es ejecutar las NF en servidores
estándar de la industria. Esto significa que los proveedores de
servidores deben producir equipos sin conocer las
características de las funciones que podrían funcionar en ellos
en el futuro. De la misma manera, los proveedores de NFV
deben asegurarse de que las funciones puedan ejecutarse en un
servidor estándar. Esto plantea la cuestión de si las funciones
virtualización de diferentes funciones de red basadas en las
previsiones de crecimiento del tráfico. G.W.A.T.T. divide la red
en seis dominios (Hogar y Empresa, Acceso y Agregación,
Metro, Edge, Núcleo y Núcleo de Servicio y Centros de
Datos). Cada dominio de la red − puede ser editado para
seleccionar diferentes modelos y tecnologías de red y así
analizar su impacto energético. Basándose en la configuración
predeterminada de la herramienta y utilizando los modelos de
red EPC para 2015, la herramienta muestra que la eficiencia
energética total de la red es de 0,0422222 MBITS/J, el
consumo total de energía es de 92, 159,8 MWATTS, y que el
ahorro de energía resultante de la virtualización del EPC sería
de 24, 044,1 MWATTS. Para el mismo caso de uso, la
herramienta mostró que el ahorro total de energía en un
período de cinco años (usando 2013 como línea de base) sería
5,0 ×109 GJ, y que la eficiencia energética de la red básica
1,86393 MBITS/J. Los resultados de algunos otros casos de
utilización del VNF, incluidos los de la red básica6 , se
resumen en el cuadro VI. Sin embargo, si bien la herramienta
es un paso importante para asignar cifras al ahorro de energía
que se espera obtener del VNF, todavía puede mejorarse. En
particular, todavía no tiene un
6Una
red de base es aquella en la que todas las funciones se ejecutan en un
equipo físico, utilizando las tecnologías y ajustes predeterminados de la
herramienta.
que se ejecutan en los servidores estándar de la industria
alcanzarían un rendimiento comparable al de las que se ejecutan
en equipos especializados, y si estas funciones serían portátiles
entre los servidores [60]. Encontrar respuestas a estas preguntas
ha sido otro de los objetivos del Instituto Europeo de Normas de
Telecomunicaciones (ETSI), y ha dado lugar a una especificación
de "Mejores prácticas de rendimiento y portabilidad" [151]. La
especificación da los resultados de las pruebas de rendimiento en
los casos de uso de NFV como DPI, C-RAN, BRAS, etc. Los
resultados demostraron que si se seguían las "mejores prácticas"
no sólo era posible lograr un alto rendimiento (hasta 80 Gbps
para un servidor) en un entorno totalmente virtualizado, sino que
el rendimiento era predecible, consistente y de manera agnóstica
para el vendedor, aprovechando las características comúnmente
disponibles en los servidores actuales de última generación [60].
En un esfuerzo relacionado, los resultados del despliegue de
C-RAN de China Mobile [148] indicaron que la Radio Pública
Común en el Terreno (CPRI) [152] sobre una solución de
transporte de transporte frontal con multiplexación por división
de longitudes de onda (WDM) ofrece un rendimiento ideal, sin
que ello afecte al rendimiento de la radio. Las pruebas también
verificaron la viabilidad de utilizar una plataforma de propósito
general (GPP) y la implementación de NFV. En particular, se
desarrolló un prototipo de C-RAN basado en GPP con capacidad
para soportar hasta 90 portadoras TD-LTE, 15 portadoras FDD-
LTE y 72 portadoras GSM. El prototipo demostró un nivel de
rendimiento similar al de los sistemas tradicionales basados en
DSP/FPGA.
Sin embargo, el rendimiento a altas velocidades es un
problema incluso en las NF no virtualizadas [29], [153]. Por lo
tanto, las técnicas como la aceleración por hardware también
serán importantes para los NFV. De hecho, se ha demostrado que
la aceleración por hardware mejora el
el rendimiento de algunos VNF. Ge y otros [28] determinan
que, en el caso de algunas funciones (por ejemplo, DPI,
Dedup y NAT), es posible que los servidores estándar de la
industria no alcancen los niveles de rendimiento requeridos.
Según las pruebas de los autores, un Dedup virtualizado
sólo podría alcanzar un rendimiento de 267 Mbps en cada
núcleo como máximo. También lo demostraron Yamazaki y
otros [154], quienes informaron de que lograron un mejor
rendimiento y eficiencia energética al desplegar un DPI
virtualizado en el procesador de conjuntos de instrucciones
específicas de la aplicación (ASIP) en lugar de los
servidores básicos.
Por lo tanto, hay algunas FN de alto rendimiento que
pueden ser difíciles de virtualizar sin degradación en el
rendimiento. Si bien la aceleración por hardware puede
utilizarse para esas funciones, esa especialización va en
contra del concepto de NFV que apunta a una gran
flexibilidad. Debería haber formas definidas de gestionar el
equilibrio entre rendimiento y flexibilidad. También será
conveniente realizar migraciones por etapas a la NFV en las
que las funciones que tienen un rendimiento aceptable se
virtualicen primero y se permita que se ejecuten junto con
otras no virtualizadas o físicas.
D. Asignación de recursos
Para lograr las economías de escala que se esperan del
VNF, los recursos físicos deben utilizarse de manera
eficiente. Se ha demostrado que el despliegue por defecto
de algunos casos de uso actual puede dar lugar a una
asignación y un consumo de recursos que no sean óptimos
[10].
Esto requiere algoritmos eficientes para determinar en
qué recursos físicos (servidores) se colocan las funciones de
la red, y poder trasladar las funciones de un servidor a otro
Sin embargo, cuando se formula como un problema de
optimización, la colocación de funciones y el encadenamiento
se reducirían a un programa binario in- teger, que es NP-Duro
[162], y por lo tanto intratable para las grandes instancias del
problema. Esto requiere heurísticos como los propuestos en
[163], [164], [165], [132]. Por ejemplo, Xia y otros [163]
formulan el problema de colocación y encadenamiento como
programación entera binaria (BIP), y proponen una heurística
codiciosa para mejorar la eficiencia de los cálculos. El
algoritmo codicioso propuesto clasifica primero las FNV de
acuerdo con su desorden de recursos y, a continuación, se da
prioridad a las FNV con mayores exigencias de recursos para
su colocación y encadenamiento.
Además, los sistemas de VFN deben permitir la migración
de uno o un grupo de VNF a servidores físicos dispares. Los
servidores físicos pueden estar en diferentes dominios de InP
y, por lo tanto, utilizar diferentes direcciones de tunelización o
ser administrados por diferentes protocolos. Esto no sólo exige
algoritmos eficientes para determinar a dónde pueden
trasladarse las funciones, sino que también requerirá una
gestión integral de los estados de las funciones y los
servidores, así como el mantenimiento de las comunicaciones.
ViRUS [166] permite al sistema en tiempo de ejecución
cambiar entre bloques de código que realizan una
funcionalidad equivalente en diferentes niveles de calidad de
servicio cuando el sistema está bajo tensión, mientras que
para objetivos tales como el equilibrio de la carga, el ahorro de
energía, la recuperación de fallos, etc. La tarea de colocar
funciones está estrechamente relacionada con la incorporación
de redes virtuales [155] y la incorporación de centros de datos
virtuales [156] y, por lo tanto, puede formularse como un
problema de optimización, con un objetivo concreto. Este
enfoque ha sido seguido por [157], [158], [159], [160],
[161].
Por ejemplo, Basta y otros [157] investigaron la influencia
de la virtualización de las funciones S-GW y P-GW en la carga
de la red de transporte y el retraso del avión de datos. En el
caso de esas dos funciones, los autores mostraron diferencias
de rendimiento (de hasta 8 veces) cuando las funciones
estaban totalmente virtualizadas y cuando sus datos y planos
de control estaban separados. Los autores propusieron un
modelo para colocar las funciones de manera que se redujeran
al mínimo los gastos generales de carga de la red introducidos
por las interacciones de los aviones de control de la SDN.
Además de la colocación, Mehraghdam [160] propone un
modelo para formalizar el encadenamiento de las NF. Para
ello, para cada solicitud de despliegue de servicios, su enfoque
construye un VNFFG que luego se asigna a los recursos
físicos, considerando que los recursos de la red son limitados y
que las funciones tienen requisitos específicos. El mapeo se
formula como un Pro- grama entero mixto cuadráticamente
restringido (MIQCP). Los autores llegaron a la conclusión de
que, para obtener un uso eficiente de los recursos, la
colocación de las funciones debe ser diferente según el
objetivo de colocación deseado (es decir, la velocidad de datos
restante, la latencia, el número de nodos de red utilizados).
Finalmente, Moens y otros [158] formulan el problema de
colocación como un Programa Lineal Entero (ILP) con el
objetivo de asignar una cadena de servicios en la red física
minimizando el número de servidores utilizados.
[167] presenta un modelo que puede utilizarse para derivar
algunos indicadores de rendimiento, como el tiempo total de
inactividad del servicio y el tiempo total de migración, a fin de
tomar decisiones de migración de funciones.
Por último, para garantizar la escalabilidad de las
implementaciones del VNF, las funciones sólo deben asignarse a
los recursos que necesitan. Contrariamente a la mayoría de las
implementaciones de prueba de concepto actuales, no es factible
desplegar una VM por abonado o por función, ya que la huella
resultante de la VM sería demasiado alta. Esto se debe a que
cada máquina virtual es como una computadora que tiene su
propio sistema operativo, y está destinada a estar aislada de otras
máquinas virtuales y, por lo tanto, es independiente a nivel de
red. Este enfoque podría convertirse en un desperdicio de
recursos por dos razones: 1) algunas de las funciones como el
DHCP en un CPE son tan ligeras que no justificarían un sistema
operativo dedicado a la escala de múltiples funciones por
usuario, 2) algunas funciones no necesitan estar estrictamente
aisladas unas de otras. Por consiguiente, según los requisitos de
una función determinada, los contenedores podrían ser una form
a más eficiente de utilizar los recursos. Los contenedores de
Linux [168] son una alternativa a las máquinas virtuales
dedicadas en las que se puede utilizar un Docker [169] para
lograr el aislamiento automatizado de recursos y el
espaciamiento de nombres que permite la partición de la
memoria, la red, los procesos, etc. El uso de contenedores evita
la sobrecarga de iniciar y mantener máquinas virtuales ya que
no requieren una duplicación completa de un sistema operativo.
El uso de contenedores podría suponer un ahorro de hasta un
30% en los costes de los servidores para soportar el mismo
número de puntos de alojamiento virtual [170].
Moreover, even if given functions must utilize the same
resources in a VM’s operating system, it is possible to use
scheduling techniques to allow the functions to share the
resources. To this end, the proposals in [171], [172], [173]
formulate the problem as a Resource Constrained Project
Scheduling Problem (RCPSP) [174] and solve it using a job
shop scheduling approach [175]. Specifically, Mijumbi et. al
[171] formulate an online VNF mapping and scheduling prob-
lem and propose a set of greedy algorithms and a Tabu Search
(TS) [176] heuristic for solving it. The greedy algorithms
TABLE VII
perform the mapping and scheduling of VNFs based on a
greedy criterion such as available buffer capacity for the node
or the processing time of a given VNF on the possible nodes,
while the TS algorithm starts by creating an initial solution
randomly, which is iteratively improved by searching for
better solutions in its neighborhood.
In addition, existing scheduling tools such as Google’s Borg
[177] and Apache Mesos [178] may be considered for
schedul- ing of VNFs. Borg uses task-packing, over-
commitment, and machine sharing with process-level
performance isolation to run multiple jobs, from many
applications, across a number of clusters. Users of the Borg
system submit jobs consisting of one or several tasks that are
run from the same executable. The scheduler in Borg monitors
queues and schedules jobs considering the resources available
on individual machines. The jobs may have requirements such
as CPU and OS. However, unlike the functions in NFV, the
tasks in Borg are run directly on hardware not in a virtualized
environment. In addition, while Borg may have the scalability
(cells usually contain 10K servers) that would be required in
an NFV environment, it would have to be improved to meet
carrier class requirements. For example, unlike the functions
that make up a service in NFV, the tasks considered in Borg do
not have ordering requirements. Finally, a task start up latency
of 25s, and the 4 nines (99.99%) availability that Borg is able
to give may need to be enhanced for NFV.
Therefore, it can be observed that there are still many open
areas with regard to how physical resources are shared among
the VNFs. First of all, the results in each of the above areas
may still be improved. In particular, the efficiency and
applica- bility of containers needs to be studied more, just like
there is need to study and propose more efficient function
scheduling algorithms. In addition, given the dynamic
requirements of NFV, there is need for resource allocation
proposals that are able to find solutions online, consider
multi-domain and distributed VNFs [179], [180], network
survivability [181], dynamic resource management [182] etc.
E. Security, Privacy and Trust
Despite the enormous potential of cloud computing, con-
sumer uncertainty and concern regarding issues of privacy,
security and trust remain a major barrier to the switch to cloud
models [183]. Therefore, cloud privacy issues will be among
the key concerns for TSPs if they have to move to public
clouds. Because the functions to be virtualized represent
subscriber services, personally identifiable information may
be transferred to the cloud. This will present unique challenges
especially as the functions will be distributed, making it hard
to know where this data is and who has access to it. In the case
where the functions are deployed in third party clouds, users
and Telecom service providers would not have access to the
physical security system of data centers. Even if the service
providers do specify their privacy and security requirements,
it may still be hard to ensure that they are fully respected.
Emphasizing its importance, ETSI constituted a security
expert group to focus on this concern. The group started by
identifying potential security vulnerabilities of NFV and
POTENTIAL SECURITY THREATS IN NFV [184]
 Security Threat
Topology Validation & Enforcement
Availability of Management Support Infrastructure
Secured Boot
Secure Crash
Performance Isolation
User/Tenant Authentication, Authorization and Accounting
Authenticated Time Service
Private Keys within Cloned Images
Back-Doors via Virtualized Test & Monitoring Functions
Multi-Administrator Isolation
establishing whether they are new problems, or just existing
problems in different guises [184]. The evaluation confirmed
that indeed NFV creates new security concerns as shown in
Table VII. After identifying the possible threats, the group
proposed some solutions. In particular, they have provided a
security and trust guidance that is unique to NFV
development, architecture and operation [30]. However, this
does not consist of prescriptive requirements or specific
implementation details.
However, it was noted that while solutions for these threats
are available, there are currently no processes to take advan-
tage of these solutions and, once in place, they will add proce-
dural complexity [60], [184]. Moreover, for some of the
threats (such as topology validation, network performance
isolation and multi-administrator isolation), the group
determined that solutions are not yet available [60]. As NFV
gets deployed and more important functions virtualized, we
can expect it to attract even more security and privacy threats.
More than ever, there will be threats based on data interception
(whether lawful or otherwise). Therefore, security, privacy and
trust are other important research directions in NFV.
F. Modeling of Resources, Functions and Services
NFV’s potential is based on its ability to deliver high levels
of automation and flexibility. However, the resources and
func- tions in NFV will be provided by different entities.
Therefore, the availability of well understood, open and
standardized descriptors for these multi-vendor resources,
functions and services will be key to large-scale NFV
deployments. Models should consider both initial deployment
as well as lifecycle management - reconfiguration. As part of
the MANO spec- ification [18], the ETSI provided a possible
set of models that may be useful in NFV. These include OVF,
TOSCA, YANG and SID. OVF was introduced in section V-
A5. In what follows, we introduce the other three models.
1) Topology & Orchestration Standard for
Cloud Applica- tion (TOSCA): TOSCA [185] is an
OASIS standard language to describe a topology of
cloud based web services, their components,
relationships, and the processes that manage them. It
describes what is needed to be preserved across
service deployments in different environments to enable inter-
operable deployment of cloud services and their management
when the applications are ported over alternative cloud envi-
ronments [18]. TOSCA may be used for VNF definition, node
monitoring and active policies like healing and scaling.
2) NETCONF/YANG: NETCONF [186] is a protocol de-
fined by the IETF to “install, manipulate, and delete the
configuration of network devices”. NETCONF operations are
realized on top of a Remote Procedure Call (RPC) [187] layer
using an XML encoding and provide a basic set of operations
to edit and query configuration on a network device.
NETCONF is based on the YANG data modeling language.
YANG is used to model both configuration and state data of
network elements. Furthermore, YANG can be used to define
the format of event notifications emitted by network elements
and it allows data modelers to define the signature of remote
procedure calls that can be invoked on network elements via
the NETCONF protocol.
3) Information Framework (SID): SID [188] is a
component of TM Forum’s Frameworx aimed at providing
an information model and common vocabulary for all the
information shared among things of interest (entities) to an
enterprise such as customer, location and network element,
and relationships (associations) between these entities, such
as a network element is situated at a location. Entities are
further characterized by facts (attributes) that describes them
and their behavior (operations) that describe how the entities
work. SID was originally based on Unified Modeling
Language (UML) [189], but was extended to include XML
Schema Definition (XSD) representations.
Discussion: Table VIII summarizes the information and data
modeling possibilities for NFV. All the models defined above
have relatively wide adoption, and may therefore be
considered for modeling of resources and functions in NFV.
For example, to enable simple and scalable gradual
deployment of VNFs and other NFV concepts, VNFs need to
co-exist with traditional non NFV-based NFs. To provide an
integration with existing OSS/BSS systems, end-to-end
network services that include VNFs or VNF Forwarding
Graphs may be able to be mapped to the SID service model
[18].
However, these models were not initially developed with
explicit considerations for some of the more specific require-
ments expected by NFV deployments and can therefore only
be used as starting points and should continue to evolve for
this purpose. For example, portability of data models and
support for federated services have been identified [190],
[191] as outstanding improvements for TOSCA. TOSCA also
needs im- provement to support run-time management of
services. With regard to NETCONF/YANG, there is need to
improve them to be able to cope with situations when multiple
administrators (multi-domain environment) are present [192].
A lot of work is ongoing to extend some of the models for
NFV. For example, SID has been extended using the ZOOM
information model
[193] to define four concepts (VirtualResource, NetworkFunc-
tion, NetworkService, and Graph) aimed at modeling NFV-
based systems. In addition, The TOSCA TC recently formed
a workgroup focused on creating a “TOSCA Simple Profile
 TABLE VIII
SUMMARY OF CHOICE OF INFORMATION AND DATA MODELS FOR NFV

OVF TOS NETCONF/YANG SID

CA
Organización DTMF OAS IET TM
IS F F
Standardize interaction Identify the business entities
Describe the packaging and
between cloud platforms Install, manipulate, and delete that play role in the business
Objective distribution of software to be
and to provide cross- the configuration of network processes of a
run in one or more VMs
platform compatibility for devices telecommunications service
applications and services. provider.
Configuration of network Identification and modelling of
Roots Server IT applications
services, TSP
Virtualization
devices business processes
Data Model CIM YAML / XML YA UM
NG L
May be used on the interface
Capturing some or all of the Function template modelling between OSS/BSS and NFV
Applicability to Runtime configuration of
VNF package and/or VDU for deployment MANO and also on the
NFV VNFs
descriptor interface
between OSS/BSS and EM.
Encoding XSD XM XS
L D
Language Declarative, Imperative Procedural (Yang)
NFV Project Using ClearWater, Multi-vendor
ON ZO
Model PoCs
F OM
[199], ExperiaSphere [200]
As SID is fundamentally an
Support for runtime Portability of data models, Capability to support easier
information model with a
Research management, possibly more support for federated modelling/deployment template
defined data model, it still
Challenges stringent requirements of services, runtime designs, protocol
lacks protocol
VNFs management independence and implementation details

for NFV.” unbelievable scale and complexity with tremendous

As the models continue to improve, it may be important to implications on network management. It will lead to
have solutions that combine them so as to avoid some of their security, scalability and resource management challenges in
disadvantages. For example, A TOSCA template can install a networks that should simultane- ously transport, process
virtual router, but it cannot subsequently create/modify/delete and act on this data in real time.
configuration on demand on the same router during run-time. NFV has been proposed as a key enabler of the IoT [195],
Therefore, fulfilling VNF requirements requires more than [196]. The idea in [195] is to limit the functionality embedded
TOSCA. In the same way, YANG is designed for writing
machine readable schema, and is hence difficult to use for
design of templates for initial service deployment. In this case,
TOSCA may be combined with NETCONF/YANG where the
file-based templates in TOSCA may be used for deploying
VNFs on cloud infrastructure, while NETCONF can be used
to provide a runtime API both for configuring VNFs after they
have been installed, bringing VNFs to a state of operational
readiness, and while they are running in the cloud, fulfilling
the service requirements of a particular customer [142].

G. Research Directions in Selected NFV Use Cases

1) The Internet of Things: Like NFV, the
Internet of Things (IoT) [194] paradigm has recently
drawn a lot of industrial attention. The IoT is a network
of physical objects or “things” into which sensors with
unique identifiers are embedded. Such sensors may
collect and transfer various kinds of (big) data over a
network without requiring human-to-human or human-
to-computer interaction. Inevitably, by networking
zillions of devices, the IoT will lead to networks of
in deployed sensors, and provide virtualized functions such
as security, intelligence, computation and storage to the
devices. These would take advantage of the scalable
distribution capa- bilities of NFV as well as the
configuration flexibility of SDN. On the other hand, Omnes
et. al [196] propose multi-layered IoT architecture
involving SDN and NFV, and illustrate how the proposed
architecture is able to cope with some of the challenges in
IoT.
However, there are serious questions on the management
of big amounts of IoT-generated data with better network
efficiency. It is therefore critical to study efficient ways of
transporting (big) data over such sofwarized networks, and
whether current cloud data management applications such
as Hadoop and Cassandra would be able to support the real
time requirements in such environments.
2) Information-Centric Networking: Motivated by the
fact that the Internet is increasingly used for information
dis- semination rather than for pair-wise communication
between end hosts, Information-Centric Networking (ICN)
[197] has emerged as a promising candidate for the
architecture of the Future Internet. ICN addresses named
data rather than named hosts. This way, content distribution
is implemented directly into the network fabric rather than
relying on the complicated mapping, availability, and
security mechanisms currently used to map content to a
single location.
The separation between information processing and
forwarding in ICN is related to both the decoupling of
functions from devices in NFV, and to the decoupling of
control from data plane in SDN. While the relationship
between NFV, SDN and cloud computing has already
received some attention, that between NFV and ICN has
not. Yet, ICN may be used in NFV to determine the best
position to place network functions. For example,
Arumaithurai et al. [198] propose a function-centric service
chaining (FCSC) approach
 TABLE IX
SUMMARY OF STATE-OF-THE-ART AND RESEARCH CHALLENGES

Challeng Description Refere Contribution / Objective Research Opportunities

e nce
ETSI MANO Specifies a management and
[18]
Framework orchestration framework for NFV
Traffic and function
Vendor specific products for monitoring,
Vendor Products different [111], [114], [115], [121] components or inter-operability and
Managem specifications of the interfacing, programmability
ent and ETSI MANO framework and Intelligence, distributed
Orchestrat management, combined
ion management of cloud, SDN
[85], [86], [88], [91], [92], Implementation and/or proposals
Projects and NFV, autonomic (self)
based [130], [131] on the ETSI MANO framework
management technologies in
NFV
[132], [133], [134], [135],
Managements and orchestration (e.g., processing of alarms)
Research Papers [136], [137], [138], [139],
frameworks and architectures
[140]
Defines the "best practices" that
ETSI need to followed to obtain
Performance & [151] acceptable performance in NFV.
Portability Also gives performance test results More studies on the
Best Practices on on NFV use cases such as DPI, applicability of hardware
NFV
C-RAN, BRAS, etc acceleration to some NFs, and
Performa
on the resulting trade-off
nce Practical experiences in deploying a C-RAN
[148] on between performance and
Measurements
a 2G and 3G network
Various proposals for applying flexibility
Hardware hardware acceleration to enhance
Acceleration [26], [28], [29], [154]
the
performance of some VNFs such as
DPI, dedup and NAT
Measurements on the effect of Still limited number of real
Practical
[148], [149] transferring network and user world deployments to give
Measurements
Energy functions actual vales, energy efficient
Efficiency to the cloud hardware, energy-
aware function placement
Vendor tool that simulates
Simulation [143] chaining, consideration of
possible energy saving resulting
inter- data center
from NFV
communications
Deciding the optimal placement of
[157], [158], [159], [160], functions in the operator’s network
Placement
or Use of containers, function
[161] the cloud, following specific scheduling, multi-domain
Resource functions requirements and function placement and
Allocation resource constraints chaining,
Allow for one or a group of VNFs survivability of VNFs in case
Migration [166], [167]
to be migrated to disparate physical of network failures, dynamic
servers resource
Allow multiple VNFs to be hosted allocation (scaling up and
down)
Scheduling [171], [172], in a single VM and schedule their
[173] efficient
utilization of resources
ETSI Security Defines the security, trust and
[184] Topology validation,
Problem privacy threats in NFV
Security, Statement network performance
Privacy, isolation, multi-
Trust Provides guidance on how administrator isolation, data
ETSI Security
[30] security, privacy and trust may interception
Guidance
be achieved in NFV.
Architecture combining NFV and
IoT [195], [196] IoT, and an application scenario
involving a virtualized sensor Monitoring and metering of
function
carrier‐scale virtualized
exploits ICN to provide flexibility networks.
NFV Use ICN [198]
and Application of big data
 Cases dynamism in placing VNFs approaches, ICN-based
placement
[62], [73], [94], [95], [96], of VNFs, proof of concepts
[97], [98], [100], [101], Implementation, demonstrations and and implementations
ETSI Use Cases [102], [103], [104], [105], proofs of concepts based on the involving chains of VNFs
ETSI
[106], [107], [108], [109], use cases
[110]

which exploits ICN to provide flexibility and dynamism in as defined by ETSI, proposed a reference business model, and
placing VNFs. explored important design considerations. We then compared
NFV with closely related fields, SDN and cloud computing,
discussing current research for combining them. We have also
Summary: In Table X, we summarize the state-of-art in each presented major specification and standardization efforts,
of the identified research challenges, as well as specific open research projects, commercial products and early NFV proof
questions in each one of them. We have noted that despite the
significant and rapidly increasing activity on NFV, there are
still major gaps especially with regard to standardization that
may slow down NFV deployment and undermine the
possibilities to fulfill its anticipated business case. While the
ETSI-defined reference architecture covers most of the aspects
needed to operationalize NFV, current specifications are still
too general to envelope all the essential pillars of required
evolution such as inter-operability, legacy support, and
management of both legacy and NFV-based systems.
For example, currently, different vendors depend on dif-
ferent languages to model resources and functions in NFV.
TOSCA has been used in modeling services for a multi-
vendor E2E proof of concept [199], for ClearWater, and
ExperiaSphere [200]. On the other hand, the descriptors in
the HP NFV Director are not based on TOSCA, and ONF has
chosen YANG as the modeling language. Similar examples
can be given for vendor implementations of the NFVI, VNFs
and MANO. This could result into inter-operability challenges
where vendor-specific Command Line Interfaces (CLIs) re-
quire manual configuration or expensive integration by service
providers themselves or systems integrators with their own
proprietary tools and equipment-specific adapters. Therefore,
though there are many options for modeling of functions and
resources, the techniques remain generally in their infancy.
With regard to performance, most current PoCs are based
on a rather limited list of use cases proposed by the ETSI.
While these PoCs are important to prove technical principles
unique to NFV, they do not give a complete view of
performance and benefits for a wide range of end-to-end
services. Finally, research on possible enablers of NFV such as
ICN, and on the application areas such as IoT are still largely
unexplored.

VII. C ONCLUSION
Due to user demands for real-time, on-demand, online,
inexpensive, short-lived services, TSPs have been forced to
look for new ways of delivering these services in ways that are
agile, and with OPEX and CAPEX savings. NFV has emerged
as a possible approach to make network equipment more open,
and hence allow TSPs to become more flexible, faster at ser-
vice innovations and reduce operation & maintenance (O&M)
costs. It is clear that NFV, together with the closely related and
complementary fields of SDN and cloud computing may be
big parts of future telecommunication service provision.
In this paper, we introduced NFV, described its architecture
of concept implementations. Finally, we discussed the key
research areas that will be pivotal to the success of NFV as
well as to its application to ICN and IoT, and summarized
the findings of the survey. We believe that before these
areas are explored, TSPs who deploy NFV may end up
being reliant on vendor-proprietary solutions to solve these
gaps, which would be against the original objective of
NFV.
We have noted that many current NFV solutions,
especially from the industry, have been mainly about
pooling vendor specific resources hosted in a cloud rather
than real support for flexibility, inter-operability, integrated
management, orchestra- tion and service automation all of
which are core requirements for NFV. It is expected that
such implementations will continue to increase before NFV
gets completely standardized. As NFV moves from labs and
PoCs to trials and commercial deploy- ments, vendors are
investing significant resources to develop these NFV
solutions. It is therefore urgent for specification and
standardization bodies to complete specifications before it
becomes too late for the standards to change or influence
what has already been deployed.

ACKNOWLEDGME
NT
The authors are indebted to the Editor-in-Chief for
coordi- nating the review process, and to the anonymous
reviewers for their insightful comments and suggestions.
This work was partly funded by FLAMINGO, a Network of
Excellence project (318488) supported by the European
Commission un- der its Seventh Framework Programme,
and project TEC2012- 38574-C02-02 from Ministerio de
Economia y Competitivi- dad.