ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO.

1, PRIMER TRIMESTRE 2015 27

Una Encuesta sobre el Software de fi nida Redes

Wen Feng Xia, Yonggang Wen, Senior Member, IEEE, Chuan Heng Foh, Senior Member, IEEE,
Dusit Niyato, Miembro, IEEE, y Haiyong Xie, Miembro, IEEE

Abstracto -Emerging mega-tendencias (por ejemplo, móvil, social, nube, I. INTRODUCCIÓN

y datos grandes) en las tecnologías de la información y la comunicación (TIC) están ordenando nuevos retos

mi
para el futuro de Internet, para los que la accesibilidad ubicua, gran ancho de banda, y agement

hombre-dinámico son cruciales. Sin embargo, los enfoques tradicionales basados ​en el manual con fi cular,
FUSIÓNgrandes
grandesvolúmenes deeldatos
tendencias en móvil,
ámbito de lassocial,
TIC [1],nube [2] y [3], [4], están
en parti-
guración de los dispositivos patentados son engorrosos y propenso a errores, y no pueden utilizar instando a las redes informáticas de gran ancho de banda, la accesibilidad en
plenamente la capacidad de la infraestructura de red físi- cas. Recientemente, el software de fi nida en red
todas partes, y la gestión dinámica. En primer lugar, la creciente popularidad de
(SDN) ha sido considerada como una de las soluciones más prometedoras para el futuro de Internet. SDN se
los contenidos multimedia ricos y el aumento de la demanda de analítica de
caracteriza por sus dos características distinguidos, incluyendo desacoplar el plano de control desde el plano

de datos y la disponibilidad de programación para el desarrollo de aplicaciones de red. Como resultado, SDN
está en condiciones de proporcionar más e fi ciente con fi guración, un mejor rendimiento y una mayor
flexibilidad para adaptarse a los diseños de red innovadoras. Este trabajo se analizan últimos avances en esta
área de investigación activa de SDN. Primero se presenta una aceptación general de fi nición de SDN con los
dos rasgos característicos antes mencionadas y los posibles beneficios de la SDN. a continuación, nos
detenemos en su arquitectura de tres capas, incluyendo una capa de infraestructura, una capa de control, y
grandes datos de un conjunto diverso de fuentes de datos, están exigiendo una
mayor velocidad de conexión de red que nunca. Por ejemplo, la televisión social
[5] - [7] y ultra alta de fi nición (UHD) de televisión traer “norte-sur” tráfico
cliente-servidor fi co tsunami a los centros de datos, y grande de análisis de
datos de aplicaciones, como MapReduce [8], provocan grandes “ este-oeste”de

una capa de aplicación, y justificar cada capa con los esfuerzos de investigación existentes y sus áreas de
investigación relacionadas. Seguimos de que con una visión general de la aplicación de facto SDN (es decir,
OpenFlow). Por último, concluimos este trabajo encuesta con algunos retos de investigación abiertas
sugeridas. a continuación, nos detenemos en su arquitectura de tres capas, incluyendo una capa de
infraestructura, una capa de control, y una capa de aplicación, y justificar cada capa con los esfuerzos de
investigación existentes y sus áreas de investigación relacionadas. Seguimos de que con una visión general
servidor a servidor de trá fi co en los centros de datos para dividir los datos de
entrada y combinar los resultados de salida. En segundo lugar, una gran
penetración de los dispositivos móviles y las redes sociales es exigente
comunicaciones ubicuas a fi ll cumplir las necesidades sociales de la población
en general.

de la aplicación de facto SDN (es decir, OpenFlow). Por último, concluimos este trabajo encuesta con algunos

retos de investigación abiertas sugeridas. a continuación, nos detenemos en su arquitectura de tres capas,

incluyendo una capa de infraestructura, una capa de control, y una capa de aplicación, y justificar cada capa 1.4 dispositivos móviles per cápita [9]. Las redes sociales también han
con los esfuerzos de investigación existentes y sus áreas de investigación relacionadas. Seguimos de que con una visión general de la aplicación de facto SDN (es decir, OpenFlow). Por último, concluimos este trabajo encuesta con algunos ret
experimentado un crecimiento espectacular en los últimos años. Por ejemplo,
Términos del Índice -Software de fi nida en red, SDN, vir- red Facebook amplió de 1 millón de usuarios en diciembre de 2004 a más de 1 mil
tualization, OpenFlow. millones de usuarios activos en octubre de 2012 [10]. Por último, el cloud
computing ha añadido nuevas exigencias a la flexibilidad y agilidad de las
redes informáticas. Específicamente, una de las características clave de
infraestructura como servicio (IaaS), Plataforma como servicio (PaaS) y
Software como Servicio (SaaS) es el servicio autogestivo [2], dictando un alto
nivel de automática con fi guración en el sistema . Al mismo tiempo, con más
Manuscrito receivedMay 31, 2013; revisado 07 de diciembre 2013 andMarch 19, 2014; Aceptado 15 de
mayo de 2014. Fecha de publicación 13 de junio de, 2014; fecha de la versión actual 13 de marzo de 2015. La recursos de cálculo y almacenamiento colocados de forma remota en la nube,
obra de H. Xie fue apoyado en parte por la Fundación Nacional de Ciencias Naturales de China bajo la ef acceso deficiente a estos recursos a través de una red se está convirtiendo
subvención 61073192, por el Programa de Investigación Fundamental Gran China (973 programas) bajo la
en fundamental para las necesidades informáticas de hoy ful fi ll. Como tal,
subvención 2011CB302905, por la Nueva Programa siglo talentos excelentes, y por los Fondos de
investigación Fundamental para las universidades centrales en virtud de concesión WK0110000014. El trabajo
de Y. Wen fue apoyado en parte por NTU bajo una puesta en marcha Grant, por el Ministerio de Educación de
Singapur bajo el Ministerio de Educación de Nivel-1 Grant (RG 31/11), por Singapur EMA bajo un EIRP02
Grant, y por la Investigación Nacional de Singapur Fundación bajo su iniciativa de financiación de futuros IDM y
administrado por el Programa de medios de Comunicación interactiva y digital O fi cina, Autoridad de En respuesta a los requisitos antes mencionados para las redes de ordenadores, una
Desarrollo de Medios. La obra de W. Xia fue apoyada por SNCF bajo la subvención 61073192, por 973 solución inmediata sería hacer una inversión adicional en la infraestructura de red para
Programa bajo la subvención 2011CB302905, y por Singapur EMA bajo un EIRP02 Grant.
mejorar la capacidad de las redes informáticas existentes, tal como se practica en la
realidad. Se ha informado de que la infraestructura de la red en todo el mundo se
adaptará a casi tres dispositivos conectados en red y 15 gigabytes de datos per cápita
W. Xia es con la Facultad de Ciencias de la Computación de la Universidad de Ciencia
en 2016, por encima de más de un dispositivo conectado en red y 4 gigabytes de datos
y Tecnología de China, Hefei 230026, China, y también con la Escuela de Ingeniería Informática,
Universidad Tecnológica de Nanyang, Singapur 639798 (e-mail: wenfeng_xia@ntu.edu.sg). per cápita en 2011 [11]. Sin embargo, la expansión de la infraestructura de red de este
tipo se traduciría en un aumento de la complejidad. En primer lugar, las redes son de
Y. Wen y D. Niyato son con la Escuela de Informática Engineer-
tamaño enorme. Incluso la red de una organización de tamaño medio, por ejemplo, una
ING, Universidad Tecnológica de Nanyang, Singapur 639798 (e-mail: @ ygwen ntu.edu.sg;
dniyato@ntu.edu.sg). red de campus, podría estar compuesto por cientos o incluso miles de dispositivos [12].
CH Foh es con el Centro de Investigación de Sistemas de Comunicación en el En segundo lugar, las redes son muy heterogéneas, especialmente cuando los equipos,
Universidad de Surrey, Guildford GU2 7XH, Reino Unido (e-mail: c.foh@surrey.ac.uk).
aplicaciones, y los servicios son proporcionados por diferentes fabricantes, vendedores y
H. Xie es con el ciberespacio y el Laboratorio de Ciencias de datos, chino
Academia de Electrónica y Tecnología de la Información, Beijing 100846, China, y también con la Facultad proveedores. En tercer lugar, las redes son muy difíciles de gestionar. Factores humanos
de Ciencias de la Computación y Tecnología de la Universidad de Ciencia y Tecnología de China, Hefei
230026, China (correo electrónico: @ haiyong.xie acm.org).

Objetos Digitales identi fi cador 10.1109 / COMST.2014.2330903

1553-877X © 2014 IEEE. Se permiten traducciones y la minería de contenido sólo para la investigación académica. También se permite el uso personal, pero republicación / redistribución
requiere el permiso del IEEE. Ver http://www.ieee.org/publications_standards/publications/rights/index.html para más información.
28 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 1, PRIMER TRIMESTRE 2015
se informó a ser el mayor contribuyente a la red el tiempo de inactividad, responsable del 50
al 80 por ciento de las interrupciones de dispositivos de red [13]. Esta creciente complejidad
exige además nuevos enfoques para las futuras redes de ordenadores, en los que la
complejidad puede ser controlada.
Debido a su tamaño, la heterogeneidad y complejidad de la actual y, posiblemente, las futuras redes
de ordenadores, los enfoques tradicionales para la con fi guración, optimización y resolución de
problemas se convertirían en ine fi ciente, y en algunos casos, insu fi ciente. Por ejemplo, del sistema
autónomo (AS) basados ​enfoques a menudo se centran en la gestión de un subconjunto de las redes y
optimizar el rendimiento o la calidad de la experiencia del usuario para algunos servicios de red, como en
el caso de aplicaciones en la red ajena P2P [14] y la tasa de transmisión de vídeo recogiendo [ 15].
Como resultado, a menudo conducen a un rendimiento subóptimo con una ganancia de rendimiento
mundial marginal. Por otra parte, la aplicación de optimizaciones locales en un único dominio, sin
coordinación entre dominios, puede causar operaciones innecesarias conflictivas con resultados
indeseables. La situación podría empeorar como plataformas de red antiguas no tiene capacidad de
programación incorporado, flexibilidad y apoyo para implementar y probar nuevas ideas de redes sin
interrumpir los servicios en curso [16]. Incluso cuando se desarrollan nuevas con fi guración de red,
optimización, o métodos de recuperación, implementación y pruebas pueden tardar años, desde el
diseño a la normalización ante un posible despliegue. Un protocolo puede tardar años en ser
estandarizado como un RFC [17], [18]. Estas observaciones han exigido un enfoque novedoso para las
futuras redes para apoyar la implementación, prueba y despliegue de ideas innovadoras. implementación
y las pruebas pueden tardar años, desde el diseño a la normalización ante un posible despliegue. Un
protocolo puede tardar años en ser estandarizado como un RFC [17], [18]. Estas observaciones han
exigido un enfoque novedoso para las futuras redes para apoyar la implementación, prueba y despliegue
de ideas innovadoras. implementación y las pruebas pueden tardar años, desde el diseño a la
normalización ante un posible despliegue. Un protocolo puede tardar años en ser estandarizado como un
RFC [17], [18]. Estas observaciones han exigido un enfoque novedoso para las futuras redes para
apoyar la implementación, prueba y despliegue de ideas innovadoras.
De hecho, la creación de redes comunidad de investigación y la industria hace
mucho han notado los problemas antes mencionados. Anteriormente algunas ideas
nuevas se han introducido para un mejor diseño de las futuras redes [19], incluyendo
nombre de red de datos (NDN) [20], las redes programables [21], “HTTP como la
estrecha cintura” [22] y software de fi nida Networking (SDN) [23]. En particular, SDN
se promociona como una solución más prometedora. La idea clave de la SDN es
disociar el plano de control desde el plano de datos y permitir la gestión fl exible fi
ciente y e y operación de la red a través de programas de software. Específicamente,
los dispositivos (por ejemplo, conmutadores y routers) en el plano de datos realizan el
reenvío de paquetes, basado en reglas instaladas por los controladores. Controladores
en el plano de control supervisan la red subyacente y proporcionan una plataforma
flexible fi ciente y e fl para implementar diversas aplicaciones y servicios de red. Bajo
este nuevo paradigma, soluciones innovadoras para los propósitos especí fi cos (por
ejemplo, seguridad de red, virtualización de red y redes verde) pueden implementarse
rápidamente en forma de software y desplegados en redes con tráfico real, c. Por otra
parte, SDN permite la centralización lógica de control de realimentación con mejores
decisiones basadas en una vista de la red global y la información de capa cruzada.
En este artículo, analizamos la literatura SDN y tienen por objeto presentar la
definición de SDN y su principio de arquitectura, que proporciona una visión general
de los acontecimientos recientes en SDN, y discutir acerca de los problemas de
investigación y enfoques para futuros desarrollos SDN. El resto de este artículo se
organiza como sigue. Primero se presenta la definición de SDN y sus principales
beneficios y desafíos en la Sección II. Las tres secciones siguientes describen la
arquitectura SDN con tres capas en detalle. Específicamente, la Sección III se
centra en la capa de infraestructura,
que analiza los enfoques para construir dispositivos y los retos de la utilización de
diferentes medios de transmisión de conmutación con capacidad de SDN. La
sección IV trata la capa de control, que introduce las operaciones de un controlador
y de rendimiento SDN problemas del controlador. Sección V se ocupa de cuestiones
en la capa de aplicación. Esta sección presenta algunas aplicaciones desarrolladas
en plataformas SDN, incluyendo encaminamiento adaptativo, la movilidad sin
límites, gestión de red, seguridad de red, virtualización de redes, redes verde, y un
caso especial el uso SDN con el cloud computing. Sección VI cubre OpenFlow, que
se considera como la aplicación de facto de la SDN. Una breve conclusión con un
poco de discusión sobre las implementaciones actuales y desarrollos adicionales de
SDN se presenta en la Sección VII.
II. SDN: D DEFINICIÓN, segundo ENEFICIOS, Y do ESAFÍOS
Últimamente SDN se ha convertido en uno de los temas más populares en el ámbito de
las TIC. Sin embargo, al ser un nuevo concepto, un consenso todavía no se ha alcanzado en
su exacta definición. De hecho, una gran cantidad de diferentes fi niciones [23] - [28] han
surgido en el último par de años, cada uno de los cuales tiene sus propios méritos. En esta
sección, presentamos una primera generalmente aceptada definición de SDN, y luego
delinear un conjunto de ts y desafíos de la SDN bene fi clave, y finalmente introducimos un
modelo de referencia SDN como el ancla de este documento encuesta.
A. Definición de SDN
La Fundación Redes abierto (ONF) [29] es un consorcio sin ánimo de lucro fi
cio dedica al desarrollo, la estandarización y comercialización de SDN. ONF ha
proporcionado la definición más explícita y bien recibido del SDN de la siguiente
manera:
Software-De definido Networking (SDN) es una arquitectura de red emergente
donde el control de la red se desacopla de reenvío y es directamente programable
[23]. Por esta definición, SDN se define por dos características, a saber, el
desacoplamiento de planos de control y de datos, y capacidad de programación en
el plano de control. Sin embargo, ninguna de estas dos firmas de SDN es
totalmente nueva en la arquitectura de la red, como se detalla a continuación.
En primer lugar, se han hecho varios esfuerzos anteriores para promover la capacidad
de programación de la red. Un ejemplo es el concepto de red activa que intenta controlar
una red en un tiempo real de manera usando el software. SwitchWare [30], [31] es una
solución de red activo, permitiendo que los paquetes fl debido a través de una red para
modificar las operaciones de la red dinámicamente. Del mismo modo, suites de
enrutamiento software en el hardware de PC convencional, tales como Haga clic en [32],
XORP [33], Quagga [34], y el pájaro [35], también intentar crear routers de software
extensibles al hacer dispositivos de red programable. Comportamiento de estos dispositivos
de red puede ser modificado mediante la carga de ed diferente o modificando el software de
encaminamiento existente.
En segundo lugar, el espíritu de desacoplamiento entre los planos de control y de
datos se ha proliferado en la última década. César et al.
primera presenta una plataforma de control de enrutamiento (RCP) en 2004 [36], en el que
Border Gateway Protocol (BGP) de enrutamiento entre dominios se sustituye por control de
encaminamiento centralizado para reducir la complejidad de cálculo de ruta totalmente
distribuida. En el mismo
XIA et al .: Una encuesta sobre Software-Defined Networking
años, IETF liberado marco de Separación Forwarding y Control Element (fuerzas),
que separa los elementos de control y reenvío de paquetes en una red de fuerzas
[37] - [40]. En 2005, Greenberg et al. propuesto un enfoque 4D [41] - [43], la
introducción de un diseño pizarra limpia de toda la arquitectura de red con cuatro
planos. Estos planos son “decisión”, “difusión”, “descubrimiento”, y “datos”,
respectivamente, que se organiza de arriba a abajo. En 2006, el Elemento de
Cálculo (PCE), la arquitectura Path se presentó para calcular etiqueta Switched
Paths por separado de inMPLS reenvío de paquetes reales y las redes GMPLS
[44]. En 2007, Casado et al. presentó etano, donde conmutadores Ethernet
basado-ow sencilla fl se complementan con un controlador centralizado para
gestionar la admisión y el encaminamiento de los flujos [45] - [48]. En este último
desarrollo, el principio de la separación de control de datos avión ha sido declarado
explícitamente. dispositivos de redes comerciales también han adoptado la idea de
la separación de planos datacontrol. Por ejemplo, en los routers de la serie Cisco
ASR 1000 y conmutadores de la serie Nexus 7000, el plano de control se
desacopla del plano de datos y modular, lo que permite la coexistencia de una
instancia de plano de control activo y un uno espera para alta tolerancia a fallos y
actualización de software transparente.
En el contexto de SDN, su singularidad reside en el hecho de que
proporciona capacidad de programación a través de desacoplamiento de
planos de control y de datos. Específicamente, SDN ofrece dispositivos de red
programable simples en lugar de hacer los dispositivos de red más compleja
que en el caso de redes activas. Por otra parte, SDN propone separación de
planos de control y de datos en la red de diseño arquitectónico. Con este
diseño, el control de la red se puede hacer por separado en el plano de control
sin afectar los flujos de datos. Como tal, la inteligencia de la red puede ser
sacado de los dispositivos de conmutación y se coloca en los controladores. Al
mismo tiempo, los dispositivos de conmutación ahora pueden controlarse
externamente por software sin inteligencia a bordo.
bene fi cios B. SDN
SDN, con su desacoplamiento inherente del plano de control del plano de datos,
ofrece un mayor control de una red a través de la programación. Esta característica
combinada traería potenciales beneficios de una mayor con fi guración, rendimiento
mejorado, y alentó la innovación en la arquitectura y las operaciones de la red, como se
resume en la Tabla I. Por ejemplo, el control abrazado por SDN puede incluir no sólo el
reenvío de paquetes a un nivel de conmutación, sino también vincular sintonizando a un
nivel de enlace de datos, rompiendo la barrera de la estratificación. Por otra parte, con
una capacidad de adquirir estado de la red instantánea, SDN permite un control
centralizado en tiempo real de una red basada en ambas estado de la red y el usuario
de fi nidas las políticas instantáneos. Esto nos lleva aún a Bene fi cios en la optimización
de con fi guraciones de red y mejorar el rendimiento de la red. El potencial de beneficio
de SDN se evidencia por el hecho de que SDN ofrece una plataforma conveniente para
experimentaciones de nuevas técnicas y anima a nuevos diseños de red, atribuido a su
capacidad de programación de la red y la capacidad de de redes virtuales aislados fi ne
a través del plano de control. En este apartado, nos detenemos en estos mencionados
beneficios de la SDN.
29
1) Mejora de Con fi guración: En la gestión de la red, con fi guración es una de las
funciones más importantes. Específicamente, cuando se añade un nuevo equipo en una
red existente, se requiere con fi guraciones adecuadas para lograr un funcionamiento
coherente de la red en su conjunto. Sin embargo, debido a la heterogeneidad entre los
fabricantes de dispositivos de red y las interfaces con fi guración, red actual con fi
guración típicamente implica un cierto nivel de procesamiento manual. Este
procedimiento con fi guración manual es tedioso y propenso a errores. Al mismo
tiempo, también se requiere signi fi esfuerzo no puede solucionar una red con errores
con fi guración. En general se acepta que, con el diseño actual de la red, automática y
dinámica reconfiguración de una red inalámbrica sigue siendo un gran desafío. SDN le
ayudará a remediar una situación tal en la gestión de redes. En SDN, unificación del
plano de control sobre todos los tipos de dispositivos de red [50], incluyendo
conmutadores, enrutadores, traductores de direcciones de red (NAT), rewalls fi, y los
equilibradores de carga, hace que sea posible para con los dispositivos de red fi gura
desde un único punto, de forma automática a través de control de software. Como tal,
una red completa puede ser mediante programación con fi gurado y dinámicamente
optimizado basado en estado de la red.
2) Mejora del rendimiento: En las operaciones de red, uno de los objetivos
fundamentales es maximizar la utilización de la infraestructura de red invertido. Sin
embargo, debido a la coexistencia de las diferentes tecnologías y las partes interesadas
en una sola red, optimizando el rendimiento de la red en su conjunto ha sido
considerado difícil. Los enfoques actuales a menudo se centran en optimizar el
rendimiento de un subconjunto de redes o la calidad de la experiencia del usuario para
algunos servicios de red. Obviamente, estos enfoques, basados ​en la información local,
sin consideración cross-layer, podría dar lugar a un rendimiento subóptimo, si no la
estafa de operaciones de red infligir. La introducción de la SDN ofrece una oportunidad
para mejorar el rendimiento de la red a nivel mundial. Específicamente, SDN permite un
control centralizado con una vista de la red global y un control de retroalimentación con
la información intercambiada entre las diferentes capas en la arquitectura de red. Como
tal, muchos problemas difíciles de optimización del rendimiento se convertirían
manejable con algoritmos centralizados diseñados adecuadamente. De ello se
desprende que las nuevas soluciones para los problemas clásicos, como el tráfico de
datos fi c programación [51], el control de extremo a extremo congestión [52], el
equilibrio de carga de enrutamiento de paquetes [53], operación ef energía deficiente
[54], y calidad de servicio (QoS ) de apoyo [55], [56], se puede desarrollar y desplegar
fácilmente para verificar su eficacia en la mejora de rendimiento de la red.
3) Fomento de la innovación: En presencia de la evolución de las aplicaciones
de red continua, futura red debe fomentar la innovación en lugar de intentar
predecir con precisión y perfectamente satisfacer las necesidades de futuras
aplicaciones [57]. Por desgracia, cualquier nueva idea o diseño de las caras de
inmediato desafíos en la implementación, la experimentación y el despliegue en
las redes existentes. El obstáculo principal surge de hardware propietario
ampliamente utilizado en los componentes de red convencionales, evitando fi
cación modi para la experimentación. Además, incluso cuando son posibles
experimentaciones, a menudo se llevan a cabo en un banco de pruebas
simplificada separada. Estos experimentos no dan su fi ciente con fi anza para la
adaptación industrial de estas nuevas ideas o diseños de red. La idea detrás de
los esfuerzos de la comunidad como PlanetLab [58] y [59 GENI]
experimentaciones a gran escala habilitados,
30 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 1, PRIMER TRIMESTRE 2015

TABLA I
C OMPARISONS E ntre SDN Y C ONVENTIONAL N ETWORKING

En comparación, SDN fomenta la innovación al proporcionar una plataforma de red

programable para poner en práctica [60], el experimento [61], e implementar nuevas
ideas, nuevas aplicaciones y nuevos servicios de ingresos ganando con comodidad y
fl exible. Alta con fi gurability de SDN ofrece una clara separación entre las redes
virtuales que permiten la experimentación en un entorno real. progresivo despliegue
de nuevas ideas se puede realizar a través de una transición sin problemas desde
una fase experimental a una fase operativa.

C. Desafíos SDN

Teniendo en cuenta las promesas de una mayor con fi guración, mejorar el rendimiento, la
innovación y alentado, SDN está todavía en su infancia. Muchas cuestiones fundamentales
permanecen todavía no resueltos completamente, entre las cuales la estandarización y la
adopción son los más urgentes.

Aunque la ONF definición de SDN es más recibió uno, OpenFlow patrocinado por la
Fig. 1. SDN Modelo de referencia: un modelo de tres capas, que van desde una capa de la infraestructura a una capa de
ONF es de ninguna manera el único estándar SDN y de ninguna manera una solución control a una capa de aplicación, de una manera de abajo hacia arriba.

madura. Un OpenFlow controlador de código abierto sigue ausente para el desarrollo del
controlador SDN, una API con rumbo al norte estándar o un lenguaje de programación de estadísticas, y usos de la red. En segundo lugar, que son responsables de procesar paquetes

alto nivel que aún falta para el desarrollo de aplicaciones SDN. Un ecosistema saludable basados ​en reglas proporcionadas por un controlador.

combinación de proveedores de red de dispositivos, desarrolladores de aplicaciones SDN, y
los consumidores de dispositivos de red, aún no ha aparecido.
SDN ofrece una plataforma para las técnicas innovadoras de red, sin embargo, el cambio
de las redes tradicionales a SDN puede ser perjudicial como dolorosa. Las preocupaciones
comunes incluyen la interoperabilidad SDN con los dispositivos de red antiguas, el
rendimiento y las preocupaciones de privacidad de control centralizado, y la falta de expertos
para el apoyo técnico. implementaciones existentes de SDN a menudo se limitan a pequeñas
banco de pruebas de prototipos de investigación. Prototipos para fines de investigación siguen
siendo prematuro ofrecer con fi anza para el despliegue en el mundo real.
La capa de control cierra la capa de aplicación y la capa de infraestructura,
a través de sus dos interfaces. Para interactuar hacia abajo con la capa de
infraestructura (es decir, la interfaz sur-unido), TI específicas funciones ES FI
para los controladores de acceso a las funciones proporcionadas por los
dispositivos de conmutación. Las funciones pueden incluir la presentación de
informes de estado de red y la importación de reglas de reenvío de paquetes.
Para interactuar hacia arriba con la capa de aplicación (es decir, la interfaz
norte-unido), que proporciona puntos de acceso de servicio en diversas
formas, por ejemplo, una interfaz de programación de aplicaciones (API). SDN
aplicaciones pueden acceder a información sobre el estado de la red
informado de dispositivos de conmutación a través de esta API, tomar
decisiones de optimización del sistema en base a esta información, y llevar a
cabo estas decisiones mediante el establecimiento de reglas de reenvío de
paquetes a los dispositivos de conmutación utilizando esta API.

D. Modelo de Referencia SDN

ONF también ha sugerido un modelo de referencia para SDN, como se ilustra en la

Fig. 1. Este modelo consiste en tres capas, a saber una capa de infraestructura, una
capa de control, y una capa de aplicación, apilar uno sobre el otro.
La capa de infraestructura consiste en dispositivos de conmutación (por ejemplo,
conmutadores, routers, etc.) en el plano de datos. Funciones de estos dispositivos de
conmutación son en su mayoría dos veces. En primer lugar, ellos son responsables de la
recogida de estado de la red, almacenarlos temporalmente en dispositivos locales y enviarlos a
La capa de aplicación contiene aplicaciones SDN diseñadas para los requisitos del
usuario ll ful fi. A través de la plataforma programable proporcionado por la capa de control,
las aplicaciones SDN son capaces de acceder y controlar los dispositivos de conmutación
en la capa de infraestructura. Ejemplo de aplicaciones SDN podría incluir un control
dinámico de acceso, movilidad sin interrupciones y la migración, balanceo de carga del
servidor y virtualización de la red.

los controladores. El estado de la red puede incluir información tal como la topología de red, En esta encuesta, se adopta este modelo de referencia como un hilo para organizar los

tráfico c esfuerzos de investigación existentes en SDN en tres secciones.

XIA et al .: Una encuesta sobre Software-Defined Networking 31

Fig 2. SDN Infraestructura Arquitectura:. Dispositivos de conmutación están conectados a formular una topología de malla a través de varios medios de transmisión, incluidos los cables de cobre, la radio inalámbrica y fi bra óptica.

arquitectura) de Netronome, familia Xelerated HX de Marvell, procesadores de la serie

OCTEON (arquitectura MIPS64) forman Cavium y las CPU de propósito general de
Intel y AMD. En el plano de control, el dispositivo de conmutación se comunica con los
controladores en la capa de control para recibir reglas, incluyendo reglas de reenvío
de paquetes a un nivel de conmutación y las reglas de ajuste de vínculo a un nivel de
enlace de datos, y almacena las reglas en su memoria local. Ejemplos de memoria
incluyen TCAM y SRAM.

Este nuevo principio arquitectónico presta ventajas competitivas SDN. A diferencia de los

dispositivos de conmutación convencionales, que también se ejecutan los protocolos de

Fig 3. Dispositivo de conmutación de Modelo en SDN:. Un modelo lógico de dos capas que consiste en un procesador enrutamiento que decidir cómo reenviar paquetes, tomas de decisiones de enrutamiento se eliminan
para el reenvío de datos y onboardmemory para información de control. de los dispositivos de conmutación en SDN. Como resultado, los dispositivos de conmutación son

simplemente responsable de reunir y presentación de informes de estado de red, así como procesar
III. yo NFRAESTRUCTURA L AYER
paquetes en base a las reglas de reenvío impuestas. De ello se desprende que la SDN dispositivos

En la capa más baja en el modelo de referencia SDN, la capa de infraestructura consiste de conmutación son más simples y será más fácil de fabricar. La complejidad reducida a su vez

en dispositivos de conmutación (por ejemplo, conmutadores, enrutadores, etc.), que están conduce a una solución de bajo costo.

interconectados para formular una sola red. Las conexiones entre los dispositivos de
conmutación son a través de diferentes medios de transmisión, incluidos los cables de cobre, Esta nueva arquitectura, sin embargo, requiere nuevo diseño de hardware para dispositivos

la radio inalámbrica, y también fibras ópticas. En la Fig. 2, se ilustra una red de referencia de conmutación compatibles con SDN. En este apartado, se describen las investigaciones

SDNenabled. En particular, las principales preocupaciones de investigación asociados con la recientes que avanza en el cambio de diseño de hardware del dispositivo, centrándose tanto en

capa de infraestructura incluyen tanto las operaciones de fi cientes de dispositivos y la el plano de control y el plano de datos. También vamos a clasificar las plataformas de

utilización de los medios de transmisión de conmutación, como se detalla en los siguientes dispositivos de conmutación más populares, y discutir la prueba y evaluación de estos

dos subsecciones. dispositivos de conmutación.

1) Plano de Control: En el plano de control de los dispositivos de conmutación SDN, uno de

los principales retos de diseño reside en el uso e fi ciente de memoria interna.
A. dispositivos de conmutación
Fundamentalmente, el uso de memoria en un dispositivo de conmutación depende de la escala

En la Fig. 3, se ilustra el diseño arquitectónico de un dispositivo de conmutación de de la red. Específicamente, los dispositivos de conmutación en una red de escala más grande

SDN, que consta de dos componentes lógicos para el plano de datos y el plano de necesitaría un espacio de memoria más grande; de lo contrario, pueden necesitar

control. En el plano de datos, el dispositivo de conmutación, en particular, a través de actualizaciones de hardware constantes para evitar el agotamiento de memoria. En caso de insu

su procesador, realiza el reenvío de paquetes, basándose en las reglas de reenvío fi espacio de memoria ciente, los paquetes se caen o se dirigen a los controladores para nuevas

impuestas por la capa de control. Los ejemplos de procesadores de red incluyen XLP decisiones sobre cómo procesar ellos, dando como resultado un rendimiento de la red

familia de procesadores (arquitectura MIPS64) de Broadcom, el procesador XScale degradada [64].

(arquitectura ARM) de Intel, NP-x NPU de EZCHIP, PowerQUICC Procesadores de

Comunicaciones (arquitectura de alimentación) de Freescale, procesadores de la serie técnicas de gestión de memoria en el diseño del interruptor tradicional se pueden ampliar

PFN (ARM para optimizar el diseño del interruptor SDN para el almacenamiento regla con el fin de reducir
el uso de memoria y utilizar la limitada
32 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 1, PRIMER TRIMESTRE 2015
TABLA II quipos SDN S
WITCHING D
ef fi ciente memoria. Específicamente, para hacer frente a registros de encaminamiento masivas,
routers convencionales utilizan técnicas tales como la ruta de agregación o resumen y política de
reemplazo de caché apropiadas [65], [66]. la ruta de agregación o la sumarización pueden
reducir el uso de la memoria mediante la agregación de varios registros de encaminamiento con
un común de enrutamiento pre fi x a un único registro de encaminamiento nueva con el fi pre
común x. Una política de reemplazo de caché adecuado puede mejorar regla de reenvío de
paquetes tasa de todos los paquetes de golpe, por lo que la memoria limitada se puede utilizar e
fi ciente. Estas técnicas se pueden adoptar para mejorar la SDN diseño del dispositivo de
conmutación.
Otro principio importante en la mejora de conmutación SDN diseño del dispositivo es
juiciosa combinación de diferentes tecnologías de almacenamiento para lograr la deseada
tamaño de memoria, velocidad de procesamiento, y la flexibilidad con el precio y la
complejidad razonable. hardware de almacenamiento diferente exhibe características
diferentes [67], [68]. Por ejemplo, la memoria estática de acceso aleatorio (SRAM) se puede
escalar fácilmente y es más flexible; Contenido ternaria de memoria direccionable (TCAM)
ofrece una velocidad más rápida para buscar paquetes clasi fi cación. SRAM y TCAM se
pueden utilizar conjuntamente para equilibrar el compromiso entre el rendimiento de
cationes de paquetes clasi fi y flexibilidad.
2) plano de datos: La función principal del plano de datos de un dispositivo de
conmutación de SDN es el reenvío de paquetes. Específicamente, después de recibir de un
paquete, fi el dispositivo de conmutación primera identifica la regla de reenvío que coincide
con el paquete y a continuación, reenvía el paquete al siguiente salto en consecuencia. En
comparación con el reenvío de paquetes en redes tradicionales basados ​en direcciones IP o
MAC, SDN reenvío de paquetes también se puede basar en otros parámetros, por ejemplo,
puerto TCP o UDP, la etiqueta de red de área local virtual (VLAN), y puertos de conmutación
de entrada. El uso de un vector largo para la transmisión de la decisión, sin duda, aumenta la
complejidad de procesamiento de cómputo, dando como resultado un equilibrio fundamental
entre el costo y la e fi ciencia en el procesamiento de paquetes SDN. Se han propuesto varias
soluciones concebidas para el procesamiento de paquetes ruta de datos rápido, entre los
cuales dos se explican como sigue.
En primer lugar, en dispositivos de conmutación basados ​en PC, utilizando el software
para el procesamiento de paquetes puede resultar en un rendimiento ineficientes. Como
mejora, Tanyingyong et al. sugerir el uso de hardware clasi fi cación para aumentar el
procesamiento de rendimiento [69], [70]. En este diseño, los paquetes entrantes se dirigen a
un controlador a bordo de interfaz de red (NIC) para clasi fi cación de hardware basado en
firmas de fluencia. Como resultado, una CPU está exento del proceso de búsqueda.
En segundo lugar, la distinta naturaleza para el “elefante” y “ratones” flujos puede ser
explotado. Al contrario de “elefante” flujos “ratones” flujos son numerosos, pero cada uno de
ellos tiene unos paquetes. página web de la recuperación de los flujos son ejemplos de
“ratones” flujos. De hecho,
“Ratones” flujos contribuir primaria a los eventos frecuentes que ser manejados por los
dispositivos de conmutación, pero tienen poca influencia en el rendimiento global de la
red. Tomando esta observación, Lu et al. sugerir de fl oading “elefante” fluye a un ASIC,
dejando “ratones” fluye a ser manipulados por una CPU con relativamente más lenta la
velocidad de procesamiento [71].
3) clasi fi y evaluación de dispositivos de conmutación de: Actualmente, los dispositivos
de conmutación SDN pueden clasificarse a tres categorías principales, según sus hardware
especí fi caciones, como se muestra en la Tabla II, incluyendo:
• Implementación en hardware de PC en general: SDN interruptores pueden ser
implementados como software que se ejecuta en un sistema operativo anfitrión (OS),
por lo general Linux. El sistema operativo anfitrión puede ejecutarse en hardware x86 /
x64 PC estándar u otro hardware compatible. Ejemplos de conmutadores de software
incluyen Pantou [72] y OpenFlowClick [73]. Pantou se basa en OpenWRT, que es una
distribución de Linux para dispositivos empotrados, especialmente los routers.
OpenFlowClick se basa en Haga clic en [32], que se implementa en hardware de PC
de uso general como una extensión del núcleo de Linux. interruptores de software
proporcionan una densidad de puertos limitado al número de tarjetas de red de a
bordo y relativamente lenta velocidad de procesamiento de paquetes utilizando
procesamiento de software. Una ventaja significativa de software implementado
interruptores SDN es que pueden proporcionar conmutación virtual para máquinas
virtuales en el paradigma popular de la virtualización de servidores y cloud computing.
Software implementado interruptores SDN como Open vSwitch [74], [75] pueden
proporcionar visibilidad y control de la red de una manera directa. Traf fi c entre las
máquinas virtuales alojados por el mismo servidor físico se mantiene en el servidor,
mientras que en la conmutación de horquilla, todo tráfico c se redirige al conmutador
físico conectado con el servidor, entonces salta.
• Implementación en hardware de red abierta: plataforma de hardware de red
abierta ofrece una plataforma independiente y programable proveedor para
construir redes para experimentos de investigación y del aula. La industria
también está prestando más atención a abrir plataformas de hardware de red.
Ejemplos de conmutación SDN basado plataforma de hardware de red abierta
implementaciones de dispositivo incluye NetFPGA [76] implementaciones
basadas tales como SwitchBlade [77] y ServerSwitch [78], y Advanced
Telecommunications Computing Architecture (ATCA) implementaciones basadas
tales como ORAN [79]. conmutadores basados ​en la plataforma de hardware de
red abierta son los más comúnmente utilizados para construir prototipos SDN en
laboratorios [80], [81], ya que son más flexibles que los interruptores de
proveedores y proporcionan un mayor rendimiento que el de los software
implementado.
XIA et al .: Una encuesta sobre Software-Defined Networking
• Implementación de encendido del proveedor: Hoy en día, más y más fabricantes de
hardware de redes están liberando sus estrategias y soluciones SDN, junto con
una amplia variedad de conmutadores habilitados para SDN, incluyendo NEC
PF5240, IBM G8264, y Pica8 3920. También hay proyectos, por ejemplo, Indigo
[82] , para permitir SDN Las funciones que utilizan actualizaciones de fi rmware en
los interruptores de proveedores que no admiten SDN cuenta originalmente.
referencia de rendimiento juega un papel importante en la innovación en los
dispositivos de conmutación. Por ejemplo, la prueba y la evaluación de los dispositivos
de conmutación se puede garantizar el funcionamiento correcto y facilitar a la mejora
del rendimiento. En este aspecto, la comparación empírica llevada a cabo por Bianco et
al. muestra un mayor rendimiento de reenvío y mejor equidad de Linux software SDN
de conmutación que el de software de conmutación Ethernet de capa 2 Linux y
enrutamiento de capa 3 IP [83]. Este resultado da confianza en el rendimiento de SDN
conmutación de conmutación no SDN convencional. Para facilitar la referencia de
rendimiento, Rotsos et al.
presentar el marco de operaciones OpenFlow por segundo (OFLOPS) que soporta la
generación de paquetes múltiples, la captura, y los mecanismos de sellado de tiempo con
diferentes precisiones e impactos [84]. OFLOPS mide los parámetros de rendimiento de
las operaciones de plano de control como el retraso de inserción regla y tráfico de retardo
consulta c estadística. OFLOPS permite operaciones detalladas de medición del
desempeño del plano de control tanto para las implementaciones de software y hardware
de las implementaciones de dispositivos de conmutación de SDN y será útil para evaluar
el rendimiento de los dispositivos de conmutación SDN.
B. La transmisión de medios
Como se ilustra en la Fig. 2, SDN debe abarcar todos los posibles medios de
transmisión, incluidos los entornos alámbricos, inalámbricos y ópticos, con el fin de fi
ful ll una cobertura ubicua. Al mismo tiempo, diferentes medios de transmisión tienen
sus características únicas, que a su vez dan lugar a menudo tecnologías fi co con fi
guración y de gestión específicos. Como tal, SDN debería integrarse con estas
tecnologías en las redes inalámbricas y ópticas. Por ejemplo, Software-De fi ne Radio
(SDR) [85] apoya la evolución rentable de dispositivos de radio y Generalizado
conmutación de etiquetas multiprotocolo (GMPLS) [86] es el plano de control de facto
para la longitud de onda de conmutación de redes ópticas. La integración de estas
tecnologías da a los controladores SDN una gran oportunidad de tener un amplio
control sobre todos los comportamientos de la red, incluyendo el envío de paquetes, el
modo inalámbrico o canal, y longitud de onda óptica. De ello se desprende que la SDN
puede obtener un control más adecuado de la infraestructura de red y lograr la
utilización de recursos de infraestructura más e fi ciente.
1) de radio inalámbrica: Muchas tecnologías de transmisión inalámbricas avanzadas
se han desarrollado para maximizar la utilización del espectro en las redes inalámbricas.
Entre ellos, Software-de fi nido Radio (SDR) permite el control de la estrategia de
transmisión inalámbrica a través de software [85]. Dada su naturaleza similar, la
tecnología SDR se puede integrar fácilmente con la SDN. Por ejemplo, Bansal et al.
señalan que muchos bloques de procesamiento de cálculo complejas son comunes en la
capa física de todos los sistemas inalámbricos modernos, que sólo difieren en Con fi
guración [87]. Un ejemplo es que casi todos los sistemas inalámbricos utilizan
Transformada Rápida de Fourier
33
(FFT) con probablemente diferentes FFT-longitudes. Esta observación motiva a
proponer OpenRadio para desacoplar inalámbrica protocolo de definición del hardware
y utilizar una interfaz declarativa para programar protocolos inalámbricos. En otro
estudio, Murty et al. presente Dyson donde un controlador NIC inalámbrica es modi fi
para apoyar la recolección estadística y Dyson comando API [88]. Los clientes y los
puntos de acceso (APs) pasivamente reportan información de medición, incluyendo el
número total de paquetes, el tamaño total del paquete, y la utilización total de tiempo en
el aire, a un controlador central. El controlador central puede gestionar asociación
enlace, selección de canal, velocidad de transmisión y tráfico c conformación para los
clientes y los puntos de acceso a través de la API se basa en información de medición
actuales e históricos.
Esencialmente, tanto OpenRadio y Dyson permiten funciones de la capa física para
ser controlados por software. En este sentido, son los sistemas de DEG. Por otra parte, la
arquitectura de software de comunicaciones (SCA) [89], [90] ha sido diseñado por el
sistema de radio táctica conjunta del Ejército de los EE.UU. (JTRS) y ha sido patrocinado
por el proponente principal de DEG, es decir Foro de Innovación Wireless [91]. recon
Software fi gurability de un sistema de SDR como SCA da controladores SDN una interfaz
para controlar el sistema de SDR. De hecho, SDR puede beneficiarse de la central de
control y visión global de SDN, como se usa en Dyson [88]. A cambio, los controladores
SDN pueden controlar sistemas de DEG y tener un control generalizado y precisa de
todos los dispositivos de red.
2) Fibras ópticas: fibras ópticas ofrecen una alta capacidad con un bajo consumo de
energía. Son ampliamente utilizados en redes troncales para agregada trá fi co. La idea de
la recon fi guración de software utilizado en las redes inalámbricas también se puede
adoptar en las redes ópticas mediante el empleo de Recon fi gurable óptico de inserción /
extracción multiplexores (ROADMs) [92]. La integración de estas tecnologías en el plano
de control SDN ayuda a lograr el control fi ciente más precisa y ef del plano de datos [93].
Uni fi ed acerca con un solo plano de control SDN tanto sobre la conmutación de
dominios y dominios de conmutación de circuitos de paquetes se consideran fi rstly, como
se muestra en la Fig. 2 donde “Controller B” gestiona un circuito óptico de dominio y la
“conmutación de paquetes de dominio A” de conmutación. Das et al. sugerir que se extiende
parámetros utilizados en coincidencia de regla de reenvío de la capa 2, 3, y 4 cabeceras de
un paquete para incluir la capa 1 tecnologías de conmutación, tales como intervalo de
tiempo, longitud de onda, y la conmutación de fibra. Por lo tanto, proporciona un único plano
de control unificado sobre paquetes y redes ópticas [94] - [97]. El esquema propuesto
proporciona un modelo de control simplificada, pero necesita para actualizar dispositivos de
conmutación de circuitos ópticos para apoyar esta extensión. Liu et al. proponer utilizar un
conmutador virtual en cada nodo de conmutación óptica para obtener uni fi de control ed
plano [98] - [103]. Cada interfaz física de un nodo de conmutación óptica se asigna a una
interfaz virtual correspondiente. Los mensajes entre el controlador y el conmutador virtual se
convierten en comandos aceptable por los dispositivos de conmutación óptica. Una idea
similar se aplica a reutilizar e integrar equipos antiguos con dispositivos de conmutación
SDN. Durante el despliegue, habrá una capa adicional a los controladores de puentes e
interruptores de legado [104]. Aunque estos enfoques pueden volver a utilizar los equipos
de red legado, que provocan la latencia de comunicación adicional mediante el uso de
mensajes proxy.
Dada su naturaleza de larga distancia en una red óptica, una ruta de datos de extremo a
extremo desde el origen al destino puede ser controlado por
34 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 1, PRIMER TRIMESTRE 2015
Fig. 4. Controlador Diseño lógico: un lenguaje de alto nivel para aplicaciones SDN para definir sus políticas de
operación de la red; un proceso de actualización regla para instalar reglas generadas a partir de dichas políticas; un
proceso de recolección de estado de la red para recopilar información de infraestructura de la red; un proceso de
sincronización de estado de red para construir una vista de red global utilizando estado de la red recogida por cada
controlador individual.
múltiples grupos de interés, cada uno de los cuales los controles de elementos de la ruta de
datos. En este caso, puede que no sea práctico tener un único plano de control a lo largo de la
ruta de datos. enfoques de control de Split, como se muestra en la Fig. 2 donde “Controller B”
gestiona un circuito óptico de conmutación de dominio y “Controller C” gestiona la
“conmutación de paquetes de dominio B”, puede ser una elección natural y puede volver a
utilizar técnicas avanzadas en la conmutación de circuitos óptico . Por ejemplo, un plano de
Aprovechando estos principios de la arquitectura, el diseño lógico para los controladores
control GMPLS que gestiona la red óptica. A lo largo de esta línea de la lógica, Casado et al. sugerir
SDN se puede desacoplar en cuatro componentes del edificio, es decir, un lenguaje de alto nivel,
borde de desacoplamiento de transporte y el núcleo [105], [106]. Presentan “tejido” donde
un proceso de actualización regla general, un proceso de recolección de estado de la red, y un
regulación de bordes de manejar los requisitos del operador; de borde de entrada conmuta
proceso de sincronización de estado de la red. En este apartado, se adopta esta estructura para
junto con sus requisitos de host mango controladores; Interruptores de la “tejido” sólo
explicar los esfuerzos de investigación existentes en el diseño del controlador en los grupos
forwardpackets. Del mismo modo, Azodolmolky et al.
antes mencionados.
proponer para integrar el plano de control GMPLS a un controlador SDN para unificar
la conmutación de paquetes y conmutación de circuitos dominios ópticos [107] -
[109]. El plano de control GMPLS gestiona el dominio óptico núcleo e interactúa con
un controlador SDN extendido que gestiona el dominio de conmutación de paquetes.
IV. do CONTROL L AYER
Como se ilustra en la Fig. 1, la capa de control cierra la capa de aplicación y la capa de
infraestructura. En esta sección, primero presentamos un diseño lógico para SDN capa de
control, que consiste en cuatro componentes principales, a saber un lenguaje de alto nivel,
un proceso de actualización regla general, un proceso de recogida de estado de la red y un
proceso de sincronización de estado de red, como se ilustra en la Fig. 4. Después de eso,
nos concentramos en dos temas críticos en la capa de control, a saber, la validación de
políticas y reglas, y los problemas de rendimiento y las posibles soluciones para la capa de
control.
Diseño del controlador A.
El controlador es el componente más importante en la arquitectura SDN, donde
reside la complejidad. En esta subsección, se adopta una estrategia de “divide y
vencerás” para presentar una arquitectura de controlador lógico. . Nuestra arquitectura
propuesta, como se representa en la figura 4, se basa en dos principios, incluyendo:
• Objetos: las ofertas controlador SDN con dos tipos de objetos. Uno se
utiliza para la red de control, incluyendo las políticas impuestas por la capa
de aplicación y de paquetes for-
la guardia de reglas para la infraestructura. El otro tiene que ver con
supervisión de la red, en el formato de estado de la red local y global. Se
deduce que la arquitectura lógica tiene dos información del
contador-direccional flujos, como se ilustra en la Fig. 4. En el de flujo hacia
abajo, el controlador traduce la política de aplicación en las reglas de reenvío
de paquetes, con respecto al estado de la red. La preocupación principal de
este proceso es garantizar la validez y consistencia de las reglas de reenvío.
En el de flujo ascendente, el controlador sincroniza estado de la red recogido
de la infraestructura de red para la toma de decisiones.
• Interfaces: el controlador SDN tiene dos interfaces. La interfaz sur de ruedas, que
está marcado como la interfaz controllerinfrastructure en la Fig. 1, se ocupa de las
operaciones con la capa de infraestructura, es decir, la recogida de estado de la
red y las actualizaciones de reenvío de paquetes reglas para los dispositivos de
conmutación en la capa de infraestructura en consecuencia. La interfaz con rumbo
al norte, que está marcado como la interfaz de aplicación-controlador en la Fig. 1,
se ocupa de las transacciones con la capa de aplicación, es decir, la recepción de
políticas descritas en lenguajes de alto nivel de las aplicaciones SDN y
proporcionando una visión global sincronizada.
1) lenguaje de alto nivel: Una de las funciones del controlador clave es
traducir los requisitos de aplicación en las reglas de reenvío de paquetes. Esta
función dicta un protocolo de comunicación (por ejemplo, un lenguaje de
programación) entre la capa de aplicación y la capa de control. Un enfoque
sencillo es adoptar algunas lenguas con fi guración común, por ejemplo, la
interfaz de línea de comandos (CLI) de Cisco Internetwork Operating System
(IOS). Sin embargo, estas lenguas con fi guración común sólo ofrecen
abstracciones primitivas derivados de capacidades del hardware subyacente.
Dado que están diseñados para con fi guraciones de hardware, por lo general
son insuficientes para dar cabida estado de la red dinámico y con estado.
Además, son propensas a errores y exigir un esfuerzo adicional en el proceso
de programación. Por lo tanto, es imprescindible para proporcionar un lenguaje
de alto nivel para aplicaciones SDN para interactuar con los controladores. Tal
lenguaje de alto nivel debe abarcar una sintaxis expresiva y comprensiva para
aplicaciones SDN para describir fácilmente sus necesidades y estrategias de
gestión de red.
Estrategias para el diseño de lenguajes de alto nivel cuali fi cados para los controladores
SDN toman por lo menos dos formatos. Una estrategia es utilizar lenguajes de alto nivel
maduros existentes, como por ejemplo, C ++, Java y Python, para desarrollo de
aplicaciones. Este enfoque normalmente proporciona un kit de desarrollo de software (SDK)
con las bibliotecas de características deseables, tales como la seguridad, ancho de banda
garantizado y aprovisionamiento On-Demand. Un ejemplo en la categoría es la PlatformKit
(onePK) de Cisco [110]. La otra estrategia adopta un diseño de estado limpio para proponer
nuevos lenguajes de alto nivel con características especiales para lograr e fi ciente
comportamiento de la red
XIA et al .: Una encuesta sobre Software-Defined Networking
control para SDN. En comparación con el enfoque de primera, pocos trabajos
publicados o liberados implementos de SDK se pueden encontrar en la actualidad, ni
tampoco un nuevo lenguaje de alto nivel dominante existe. En los siguientes párrafos,
se revisan varios lenguajes de alto nivel para la SDN, incluyendo el trabajo anterior en
este dominio llamado Flowbased lenguaje para la gestión (FML) [111], un lenguaje de
programación bien desarrollado para SDN llamado frenético [112], [113] , y otro
lenguaje de alto nivel llamado ortiga [114] - [117].
Lenguaje basado en el flujo de Gestión (FML) [111], anteriormente conocido como
lenguaje basado en el flujo de Seguridad (FSL) [118], es un lenguaje para la descripción
conveniente y expresiva de las políticas de conectividad de red en SDN. FML ofrece
operaciones de fi ne granulares en red flujos unidireccionales y es compatible con las
limitaciones expresivas en permitir / denegar trá fi co y la limitación de ancho de banda,
latencia y jitter. irrelevancia orden de FML hace que sea fácil de combinar un conjunto de
políticas independientes. Por otra parte, un código de política a largo fácilmente se puede
entender sin conocimiento del contexto. Ferguson et al. presente PANE que se extiende
FML con consultas y sugerencias para estado de la red y una dimensión de tiempo [55].
Tal extensión puede de fi nir la duración de una solicitud de ancho de banda garantizado
podría ser veri fi có. PANEL mejora la expresividad política con el conocimiento y las
predicciones de estado de la red precisa. PANEL también introduce fl ujo jerárquica
mesas para darse cuenta de las políticas jerárquicas para una mejor policymanagement
[119].
Frenetic [112], [113] que se propone para eliminar complicado asíncrono y las
interacciones basadas en eventos entre aplicaciones SDN y dispositivos de conmutación.
En particular, frenético introduce un lenguaje de consulta de red declarativa similar a SQL
para la clasificación y agregación de las estadísticas de trá fi co de red. Por otra parte, se
introduce una biblioteca de gestión de políticas de red reactiva funcional para manejar los
detalles de la instalación y desinstalación reglas de nivel interruptor. El lenguaje de
consulta incluye un rico patrón de álgebra, por ejemplo, configurar las operaciones, lo
que proporciona una manera conveniente para describir conjuntos de paquetes. Después
de la aparición de la frenética, se introducen varias mejoras funcionales y de rendimiento.
Monsanto et al. introducir el uso de reglas comodín y la generación proactiva. Como
resultado, más paquetes puede ser igualada por reglas de tarjeta salvaje que la de reglas
coincidencia exacta, y los paquetes se pueden procesar en los dispositivos de
conmutación sin peticiones a los controladores [120]. gutz et al. añadir sintaxis para
describir aislados rebanadas de red y permitir la virtualización de red utilizando Frenetic
[121]. Pyretic [122] introduce composición secuencial que permite que una regla para
actuar sobre los paquetes ya procesados ​por otra regla, y la abstracción de topología que
mapea entre los conmutadores físicos y conmutadores virtuales.
Voellmy et al. presente ortiga para mejorar la capacidad de respuesta a cambios en la
red dinámicas. Ortiga utiliza idiomas reactivos para describir las políticas mediante la
combinación de programación funcional reactivo (FRP) y los idiomas de
dominio-específico C (DSL) [114] - [117]. FRP permite la programación para el control de
la red interactiva en tiempo real de una manera declarativa. Un pedazo de programa ortiga
toma eventos de red como entrada, por ejemplo, la detección de un nuevo usuario.
Entonces, el programa emite actualizaciones de reglas para el uso especí fi co, por
ejemplo, la autenticación de usuarios. Uno solo de tamaño ts-fi todo lenguaje puede no ser
posible, dada la diversidad de problemas de gestión de red. DSL permiten ortiga para
proporcionar una familia extensible de DSL, cada uno de los cuales está diseñado para
una cuestión específica, por ejemplo, autenticación de usuarios y tráfico c en-
35
gineering. Ortiga utiliza Haskell como la lengua de acogida debido a su notable
flexibilidad en el apoyo a los DSL embebidos. Más tarde, Voellmy et al. presente
“Maple” para simplificar la programación SDN al permitir a un programador
para usar un lenguaje de programación estándar para diseñar un algoritmo
centralizado arbitraria para cada paquete entra en la red, eliminando por lo
tanto, detalles de bajo nivel [123]. Arce consta de dos componentes
principales, a saber, un “optimizador” y un “programador”. El optimizador utiliza
una estructura de datos “árbol traza” para grabar la invocación del algoritmo
programmersupplied en un paquete específico, entonces se generaliza reglas
en la tabla de flujo de interruptores individuales. Un árbol traza captura la
reutilización de los cálculos anteriores y, por tanto, reduce sustancialmente el
número de invocaciones del mismo algoritmo. El optimizador utiliza varias
técnicas para mejorar la e fi ciencia, incluyendo el aumento del rastro árbol,
árbol de la compresión de seguimiento, y la minimización prioridad de la regla.
2) reglas de actualización: Un controlador SDN también es responsable de generar las
reglas de reenvío de paquetes que describe las políticas y la instalación de ellos en
dispositivos de conmutación adecuada para su funcionamiento. Al mismo tiempo, las reglas
de reenvío en dispositivos de conmutación necesitan ser actualizados debido a los cambios
con fi guración y control dinámico, tales como dirigir tráfico c de una réplica a otro para la
carga dinámica de equilibrio [124], la máquina virtual (VM) la migración [125], y recuperación
de la red después de un fallo inesperado. En presencia de la dinámica de la red, la
consistencia es una característica básica que regla de actualización debe preservar para
garantizar las operaciones de red adecuadas y propiedades de red preferidas, tales como,
bucle libre, ningún agujero negro, y la seguridad.
consistencia regla puede establecerse en diferentes sabores. En la literatura, se
discuten dos de fi niciones de consistencia alternativa, incluyendo:
• La consistencia estricta: asegura que se utiliza ya sea el conjunto de reglas original o el
conjunto de reglas actualizado. consistencia estricta podría ser ejecutada en un nivel
por paquete, donde se procesa cada paquete, o en un per- flujo nivel, donde todos los
paquetes de un de flujo se procesan ya sea por la regla original establecer o el conjunto
de reglas actualizado.
• La consistencia eventual: asegura que los paquetes posteriores utilizan la regla actualizada
establecer el tiempo después de la actualización acabados procedimiento y permite que los
anteriores paquetes de la misma de flujo para utilizar la regla original establecido antes o durante
el procedimiento de actualización. En la primera categoría, Reitblatt et al. proponer una aplicación
estricta consistencia que combina el control de versiones con los tiempos de espera de reglas
[126], [127]. La idea es sellar cada paquete con un número de versión en su interruptor de
entrada que indica qué conjunto de reglas se debe aplicar. Entonces, el paquete se procesará en
función del número de versión. Los paquetes posteriores serán estampados para tomar el
conjunto de reglas actualizado. Por lo tanto, no hay más paquetes tomarán la regla original
establecido después de un tiempo lo suficientemente largo. A continuación, el conjunto de reglas
original será eliminado. Sin embargo, tanto los conjuntos de reglas originales y actualizadas se
mantienen en los dispositivos de conmutación antes de que el conjunto de reglas originales
expira y se retira.
36 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 1, PRIMER TRIMESTRE 2015
En esta última categoría, McGeer et al. aplicar consistencia eventual para conservar
espacio de memoria del conmutador asegurando que sólo un único conjunto de reglas se
presenta en un dispositivo de conmutación en cualquier momento [128]. Cuando una nueva
política está a punto de ser implementado, todos los dispositivos de conmutación
correspondientes son de primera informado dirigir paquetes afectadas a un controlador.
Entonces, el controlador genera nuevas reglas de reenvío de paquetes en base a la política y
reemplaza las reglas en los dispositivos de conmutación con estas nuevas reglas
correspondiente. Cuando se hayan completado los reemplazos, los paquetes afectados
tamponadas en el controlador anterior se liberan de nuevo en los dispositivos de
conmutación para su procesamiento. Una de flujo se llevará a la regla original establecido
antes de la de flujo se dirige al controlador y el estado actualizado establecido después de la
de flujo se libera de nuevo a los dispositivos de conmutación. Esta es una condición no
deseada que puede ocurrir en consistencia eventual. Sin embargo,
3) Colección Estado de la red: En el de flujo hacia arriba, los controladores recogen
estado de la red para construir una visión global de toda una red y proporcionar la capa
de aplicación con la información necesaria, por ejemplo, gráfico de topología de la red
[129], para las decisiones de operación de la red. Un estado de la red principal es la
estadística trá fi co, como por ejemplo, el tiempo de duración, número de paquete, el
tamaño de los datos, y la cuota de ancho de banda de un fl ujo. Normalmente colección
estado de la red funciona de la siguiente manera. Cada dispositivo de conmutación
recoge y almacena las estadísticas de tráfico c locales dentro de su propio
almacenamiento. Estas estadísticas c tráfico locales pueden ser recuperados por los
controladores (es decir, un modo “pull”), o de forma proactiva informado a los
controladores (es decir, un modo “push”). el modo y la estrategia diferentes tienen
características diferentes en gastos generales de medición y precisión. De esta manera,
un objetivo clave de la investigación es encontrar un “punto dulce” (es decir,
Una forma útil y de uso común para los datos de estado de la red es Traf fi c Matrix
(TM). TM re volumen refleja de tráfico c que fluye entre todos los posibles pares de
fuentes y destinos en una red [130]. Tootoonchiane et al. presente OpenTM que lee los
contadores de bytes y de paquetes mantenidos por los dispositivos de conmutación (es
decir, un modo “pull”) para flujos activos para estimar el TM [131]. Consulta del último
dispositivo de conmutación en una trayectoria desde la fuente a los resultados de destino
en la medición más precisa de tráfico c del origen al destino, ya que típicamente el
receptor tendrá la imagen más completa de la trayectoria. Sin embargo, este enfoque
puede resultar en una sobrecarga del último dispositivo de conmutación en el camino.
OpenTM utiliza estrategias de consulta selectivos con diferentes distribuciones de
consulta a lo largo de la ruta de acceso para equilibrar el compromiso entre la precisión de
la medición y la carga de consulta en dispositivos de conmutación individuales. Basado en
la observación de que la cantidad de datos observado en buffers TCP anfitriones se eleva
mucho más rápido que el observado en la capa de red para un ow fl. Curtis et al. proponer
Mahout para detectar “elefante” fluye a los anfitriones. Tipo de Servicio de bytes (TOS)
está marcada por el anfitrión para notificar “elefante” fluye al controlador [132].
Además de la estrategia mencionada anteriormente, haciendo caso omiso de “ratones” fluye
en la medición puede ser otra estrategia para aliviar sobrecarga mientras que causan pocos
efectos secundarios. Por ejemplo, José et al.
sugerir el uso de un algoritmo de pesos pesados ​jerárquica para identificar “elefante” flujos
e ignorar “ratones” flujos [133]. Dispositivos de conmutación de paquetes de partido contra
una pequeña colección de reglas y
actualizar los contadores de trá fi co para el partido de más alta prioridad. Por lo tanto sólo las
estadísticas de trá fi co del “elefante” flujos se actualizarán y se recogen.
algoritmos Streaming muestran bajo uso de memoria, error de estimación
delimitada, y alta velocidad de procesamiento con capacidad de alta llegar
velocidad de datos de entrada en los vapores de datos de procesamiento de
[134], [135]. Son naturalmente adecuado para la red de tráfico c flujo
monitoreando [136] - [138]. Yu et al. presente OpenSketch, que es una
arquitectura de medición fi c tráfico de red para SDN apalancamiento las
ventajas de los algoritmos de transmisión [139]. El plano de datos de
OpenSketch consiste en una tubería de tres etapas, a saber hashing, ltrado fi,
y contando. En primer lugar, los campos de interés de un paquete entrante son
ordenadas para ahorrar espacio en la memoria, el código hash entonces se
filtró para decidir si el paquete debe ser contado, últimos contadores
correspondientes se actualizan. OpenSketch también proporciona una
biblioteca de medición en el plano de control que figuras automáticamente la
estafa de la tubería y asigna recursos para diversas tareas de medición,
incluyendo fuente única y el recuento de destino, los pesos pesados, la
distribución de tamaño de flujo.
4) Estado de la sincronización de red: La delegación de control a un controlador
centralizado puede causar cuello de botella en el controlador centralizado. Una solución
común para superar este cuello de botella está desplegando varios controladores que
actúan por pares, copia de seguridad, o replicar controladores [140]. El mantenimiento de
una visión global coherente entre todos los controladores es esencial para garantizar las
operaciones de red adecuados. estados inconsistentes o rancios pueden resultar en la
capa de aplicación tomar decisiones incorrectas, que a su vez conduce a operaciones
inadecuadas o subóptimos de la red [141].
Publicación / suscripción sistemas son ampliamente utilizados para lograr un
NetworkView synchronizedglobal. Por ejemplo, Tootoonchian et al.
introducir HyperFlow que permite el intercambio de una vista de toda la red consistente
sincronizada entre múltiples controladores [142]. HyperFlow utiliza un mecanismo de
publicación de mantener una visión global consistente a través de los controladores. Cada
vez que se detecta un cambio de estado del sistema, cada controlador publica
selectivamente un evento sobre el cambio a través de un sistema de publicación /
suscripción. Nuevo estatus continuación se empuja a los controladores suscritos para la
actualización inmediata.
La comunicación entre varios controladores es otro método que puede lograr
sincronizada vista de la red global. En esta categoría, Yin et al. proponer “SDNi”
para la interconectividad y el mensaje de cambio entre múltiples dominios SDN
[62], [63]. Un dominio de SDN se define como la porción de la red que se está
gestionado por un controlador SDN particular. Específicamente, “SDNi” es una
interfaz más de propósito general con una función dual. Se puede utilizar para
compartir y sincronizar la información de estado de la red, y coordinar los
procesos de toma de decisiones controladores.
aplicaciones SDN también juegan un papel importante en cuanto a que pueden
tener diferentes requisitos de durabilidad y consistencia de la vista de la red global.
Usando esta observación, Koponen et al. presente Onix permitiendo a los
programadores para determinar un equilibrio entre la aplicación fi ed potencialmente
simplificada y durabilidad estricto y garantizar la coherencia [143]. Con Onix, una
aplicación SDN puede elegir y utilizar un persistente transaccional
XIA et al .: Una encuesta sobre Software-Defined Networking
base de datos de respaldo de una máquina de estado replicado que asegura la durabilidad y
consistencia. Como resultado, esta aplicación puede ser simple sin tener en cuenta la
consistencia. Las aplicaciones SDN también pueden optar por una de un salto, con el tiempo,
consistente, memoria de sólo Distribuir tabla hash (DHT) que tiene capacidad de alta velocidad
de actualización; sin embargo, estas aplicaciones necesitan para manejar las inconsistencias sí
mismos.
B. Políticas y Regla de validación
La consistencia en las políticas y normas se destaca como un problema de diseño
importante para estabilizar la elección de encaminamiento en redes SDN. Esto se debe al
hecho, en las redes SDN, varias aplicaciones pueden conectar al mismo controlador, y
varios controladores podrían ser fi gurada para la mejora del rendimiento. Como resultado,
conflictivos estafadores configuraciones fi podrían surgir, exigiendo una coordinación
interna entre las diferentes unidades participantes. Específicamente, las políticas y las
reglas deben ser validados para identificar conflictos potenciales. Además, muchos
métodos bien desarrollados, por ejemplo, autenticación del origen basado en roles con
prioridad [144], se pueden adoptar para resolver estos conflictos. En este apartado,
examinamos varios esfuerzos de investigación existentes para garantizar la validez de las
políticas entre dominios e intra-switch, así como las reglas de reenvío de paquetes.
La verificación de modelos, que es ampliamente utilizado para verificar automáticamente la
corrección de un sistema de estado finito, se puede adoptar fácilmente para la política y la
validación regla. A lo largo de esta línea de investigación, se propone FlowChecker para identificar
intra-interruptor configuraciones Miscon fi e inconsistencias entre conmutadores aprovechando
modelo comprobación [145], [146]. Específicamente, FlowChecker utiliza diagrama de decisión
binario (BBDs) para codificar configuraciones y modelos de comportamiento global de una red en
una sola máquina de estados fi estafadores red de “qué pasaría si” análisis. FlowChecker
proporciona, además, una interfaz basada en propiedad genérica para verificar las propiedades de
accesibilidad y de seguridad escritas en Computational árbol lógico (CTL), utilizando el análisis de
modelo simbólico basado en BDD y la lógica temporal. El uso del lenguaje CTL hace que sea más
fácil de escribir consultas para validar ciertas propiedades o extraer estadísticas que se han
utilizado para su posterior análisis. En otro ejemplo, Canini et al. presente NICE (No hay errores en
el controlador de ejecución), que también adopta modelo de comprobación para comprobar las
propiedades de corrección en SDN [147] - [149]. AGRADABLE toma una aplicación SDN, topología
de la red y la corrección propiedades, por ejemplo, entradas libres de bucles, como, a continuación,
realiza una búsqueda de espacio de estado y produce trazas de violaciónes de propiedad. Utiliza la
verificación de modelos para explorar las rutas de ejecución del sistema, la ejecución simbólica
para reducir el espacio de las entradas y las estrategias de búsqueda para reducir el espacio de
estados. En la práctica, a menudo (OpenFlow entorno de pruebas) construido en base a
AGRADABLE utilizando dispositivos de conmutación físicas cuyos estados están sincronizados con
los modelos de conmutación utilizados en AGRADABLE [150]. A menudo puede ser utilizado para
el dispositivo de conmutación física pruebas de recuadro negro.
Desde otra perspectiva, las reglas pueden ser validados de forma estática o dinámica. Por
un lado, las reglas se pueden comprobar de forma estática para ciertos invariantes red, tales
como la accesibilidad, libre de bucles, y la consistencia, basado en Topología de red [151]. Por
otro lado, también es útil para verificar las reglas en tiempo real, como evoluciona el estado de
la red. Sin embargo, el logro de una latencia extremadamente baja durante estos controles es
en última instancia importante. Khurshid et al. presente
37
VeriFlow para mostrar que el objetivo de latencia extremadamente baja durante los controles en
tiempo real se puede lograr [152] - [154]. En su diseño, se introduce un proxy entre un
controlador y los dispositivos de conmutación para comprobar violaciónes invariantes en toda la
red de forma dinámica a medida que cada regla de reenvío se actualiza. Se primer divide reglas
en clases de equivalencia en base a pre fi x superposición y utiliza pre estructura de datos de
árbol fi x para encajar rápidamente reglas nd superpuestas. A continuación, el proxy genera
gráficos de desvío individuales para todas las clases equivalentes. Como resultado, las consultas
de bucles o agujeros negros se pueden respondieron rápidamente por la que atraviesa un gráfico
de reenvío correspondiente.
Rendimiento Capa C. Control
El rendimiento de las redes SDN depende altamente de la capa de control, que, a su
vez, está limitada por la escalabilidad de controladores centralizados. De hecho, todas las
transacciones en el plano de control están involucrados con controladores. Equipos de
conmutación necesitan solicitar controladores para reglas de reenvío de paquetes de forma
reactiva cuando el primer paquete de cada fl llega ow. actualización de la regla y la recogida
de estado de la red también se involucran en una comunicación frecuente entre los
controladores y dispositivos de conmutación. En este aspecto, el consumo de ancho de
banda y la latencia de comunicación frecuente afectan de control de capa escalabilidad
significativamente.
Para abordar el problema de escalabilidad con un controlador SDN, los investigadores
han propuesto anteriormente varios controladores con la colocación geográfica adecuada
[155], que sería necesario sincronización estado de la red. los esfuerzos de investigación
alternativos también son buscados desde un aspecto de diseño para aumentar la capacidad
de procesamiento de un único controlador o disminuir la frecuencia de las solicitudes de ser
procesada. Describimos estos esfuerzos de investigación en este apartado, y técnicas de
referencia actual de rendimiento para los controladores de SDN.
1) El aumento de la capacidad de procesamiento: Un controlador es esencialmente una pieza de
software. Como tales técnicas de optimización de software, convencionales como paralelismo y de
dosificación se pueden utilizar para mejorar el rendimiento del controlador en el procesamiento de
solicitudes, que se utiliza en Maestro [156], [157], NOX-MT [158], y McNettle [159], [160 ].
Específicamente, Maestro [156], [157] es una implementación controlador basado en Java. Se explota de
paralelismo junto con técnicas de optimización de rendimiento adicionales, tales como, entrada y salida
de dosificación, el núcleo y la rosca de unión. Está demostrado que este diseño conduce a un mejor
rendimiento y escalabilidad casi lineal desempeño en procesadores multi-núcleo. En otro caso, NOX-MT
es un controlador multi-hilo basado en el único hilo C aplicación ++ de sistema operativo de red (NOX)
[158]. Benchmarking sobre diferentes controladores, incluyendo NOX, NOX-MT, Maestro, y Beacon
[161], muestra ventajas de rendimiento de NOX-MT sobre los otros en términos de tiempo mínimo y
máximo de respuesta, así como el máximo rendimiento. McNettle es un controlador SDN escrito en
Haskell, el aprovechamiento de las instalaciones de múltiples núcleos de la Haskell Compiler Glasgow
(GHC) y el sistema de tiempo de ejecución [159], [160]. McNettle controladores de eventos horarios,
asigna memoria, optimiza el análisis de mensajes y la serialización, y reduce el número de llamadas al
sistema con el fin de optimizar el uso de la caché, el procesamiento del sistema operativo, y la
sobrecarga del sistema en tiempo de ejecución. Los experimentos muestran que McNettle puede servir
hasta 5000 interruptores usando un único controlador con el aprovechamiento de las instalaciones de
múltiples núcleos de la Haskell Compiler Glasgow (GHC) y el sistema de tiempo de ejecución [159],
[160]. McNettle controladores de eventos horarios, asigna memoria, optimiza el análisis de mensajes y la
serialización, y reduce el número de llamadas al sistema con el fin de optimizar el uso de la caché, el
procesamiento del sistema operativo, y la sobrecarga del sistema en tiempo de ejecución. Los
experimentos muestran que McNettle puede servir hasta 5000 interruptores usando un único controlador
con el aprovechamiento de las instalaciones de múltiples núcleos de la Haskell Compiler Glasgow (GHC)
y el sistema de tiempo de ejecución [159], [160]. McNettle controladores de eventos horarios, asigna memoria, optimiza el a
38 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 1, PRIMER TRIMESTRE 2015
46 núcleos, logrando el rendimiento de más de 14 millones de flujos por segundo.
2) La reducción de Solicitud de frecuencia: carga de solicitudes pesado en un controlador
podría resultar en un retraso más largo en los controladores SDN [162]. Como tal, muchas
estrategias se pueden adoptar para disminuir la frecuencia de solicitud. Uno de ellos es para
modificar los dispositivos de conmutación con el fin de manejar las peticiones en el plano de
datos o cerca del plano de datos. Otra estrategia es volver a definir la estructura en la que se
organizan los dispositivos de conmutación. Se discuten estos dos estrategias en los siguientes
párrafos.
Siguiendo la estrategia de manejo de peticiones en el plano de datos, Yu et al. sugerir la
distribución a través de reglas de autoridad “interruptores” [163]. Los paquetes se desvían a través
de “autoridad interruptores” como sea necesario para acceder a las reglas apropiadas, por tanto,
todos los paquetes se pueden manejar en el plano de datos sin necesidad de pedir a los
controladores. Sin embargo, algunos paquetes pueden tener que ser dirigido a través de un
camino largo para conseguir reglas apropiadas. Del mismo modo, Curtis et al.
presente DevoFlow para manejar la mayoría “ratones” flujos en los dispositivos de conmutación
[164]. DevoFlow proactivamente instala un pequeño conjunto de posibles reglas de reenvío de
paquetes en los dispositivos de conmutación. Como resultado de ello, de igual costo Multi-Path
(ECMP) de enrutamiento y cambio de ruta rápida después del puerto de salida designado baja se
puede apoyar sin solicitar controladores. DevoFlow también utiliza el muestreo, lo que provocó
informe después de una condición de umbral se ha cumplido, y se aproxima a los contadores que
sólo un seguimiento de las estadísticas de las láminas superior k
mayores “ratones” flujos. Como resultado, se reduce la cantidad de datos en la comunicación
con los controladores durante la recolección estadística.
organización adecuada y la división del trabajo de los dispositivos de
conmutación también puede mejorar el rendimiento global capa de control. Por
ejemplo, Yeganeh y Ganjali proponen Kandoo, un marco para preservar la
escalabilidad sin cambiar los dispositivos de conmutación [165]. Específicamente,
Kandoo tiene una arquitectura de dos capas para manejar la mayoría de los
eventos frecuentes a nivel local. La capa inferior es un grupo de controladores sin
una vista de toda la red que manejar la mayoría de los eventos frecuentes.
“Elefante” detección de flujo, que necesita consultar constantemente cada
dispositivo de conmutación para ver si una de flujo tiene datos suficientes para ser
un “elefante” flujo, se puede hacer a la capa inferior. Al mismo tiempo, la capa
superior es un controlador de lógica centralizada que mantiene una visión de toda
la red y gestiona los eventos raros, por ejemplo, solicitando para decisiones de
enrutamiento. Como resultado de la arquitectura de dos capas,
3) Estudio comparativo del rendimiento: Controlador de pruebas de rendimiento se puede
utilizar para identificar los cuellos de botella y es esencial para aumentar la capacidad de
procesamiento de un controlador. Cbench (benchmarker controlador) [166] y OFCBenchmark
[167] son ​dos herramientas diseñadas para la evaluación comparativa controlador. Cbench
[166] prueba el rendimiento del controlador mediante la generación de solicitudes de reglas
de reenvío de paquetes y viendo para las respuestas desde el controlador. Cbench ofrece
estadísticas agregadas de rendimiento del controlador y el tiempo de respuesta para todos los
dispositivos de conmutación. estadísticas agregadas pueden no ser suficiente suficiente para
explorar el comportamiento detallado del controlador. En esta consideración, Jarschel et al. presente
OFCBenchmark con fi estadísticas de grano fino para dispositivos de conmutación
individuales [167]. OFCBenchmark proporciona estadísticas de tasa de respuesta, tiempo de
respuesta y el número de paquetes sin respuesta para cada dispositivo de conmutación.
V. Un OLICITUD L AYER
Como se ilustra en la Fig. 1, la capa de aplicación reside por encima de la capa
de control. A través de la capa de control, las aplicaciones SDN pueden acceder
convenientemente una vista red global con el estado instantáneo a través de una
interfaz northbound de controladores, por ejemplo, la capa de aplicación Traf fi c
Optimization (ALTO) Protocolo [168], [169] y el Protocolo de Sesión extensible (XSP
) [170]. Con esta información, aplicaciones SDN pueden implementar estrategias de
programación para manipular las redes físicas subyacentes utilizando un lenguaje de
alto nivel proporcionada por la capa de control. En este aspecto, SDN ofrece
“plataforma como servicio” modelo de trabajo en red [171]. En la sección,
describimos varias aplicaciones SDN construidas sobre esta plataforma.
Enrutamiento adaptativo A.
La conmutación de paquetes y el enrutamiento son las principales funciones de una
red. Tradicionalmente, los diseños de conmutación y enrutamiento se basan en enfoques
distribuidas para robustez. Sin embargo, tales diseños distribuidos tienen muchas
deficiencias, incluyendo la implementación compleja, lenta convergencia [180], y la
capacidad limitada para lograr el control adaptativo [181]. Como solución alternativa, SDN
ofrece un control de bucle cerrado, la alimentación de las aplicaciones con información de
estado de la red mundial oportuna y permitiendo aplicaciones para controlar de forma
adaptativa una red. Al ver esta oportunidad, se han hecho varias propuestas para utilizar
la plataforma SDN por mejores diseños de enrutamiento. En los siguientes párrafos, se
describen dos aplicaciones SDN populares en este dominio, es decir, el equilibrio de
carga y diseño cross-layer.
1) de equilibrio de carga: El balanceo de carga es una técnica ampliamente utilizada para
lograr un mejor uso de los recursos. Una práctica común de equilibrio de carga en los centros
de datos está desplegando equilibradores de carga front-end para dirigir la petición de cada
cliente para una réplica servidor en particular para aumentar el rendimiento, reducir el tiempo
de respuesta, y evitar la sobrecarga de la red. equilibradores de carga dedicados, sin
embargo, suelen ser muy caros. SDN permite un enfoque alternativo. En los párrafos
siguientes, que primero discutimos algoritmos para equilibrar la carga usando reglas de
reenvío de paquetes y, a continuación presente usos casos en varios escenarios.
Wang et al. hacer esfuerzos iniciales para construir un modelo y desarrollar algoritmos para
el equilibrio de carga utilizando las reglas de reenvío de paquetes de SDN [124]. Ellos asumen
tráfico uniforme fi co de todos los clientes con diferentes direcciones IP y proponen utilizar un
árbol binario para organizar IP pre fi jos. El tráfico c se divide entonces usando reglas de tarjeta
salvaje, de modo que una réplica del servidor manejará un tráfico c cuyo volumen es
proporcional a la capacidad de procesamiento de la réplica del servidor. Aunque la suposición
puede no ser cierto en la mayoría de los casos, este trabajo establece una base para futuras
investigaciones sobre las reglas de reenvío de paquetes apalancamiento de balanceo de carga
de SDN. Además de calcular una ruta para cada tráfico c flujo de forma proactiva para lograr
carga equilibrada, otra metodología es migrar tráfico c de dispositivos de conmutación cargadas
pesadas a ligeramente cargado los reactivamente [182].
Si bien el desarrollo de algoritmos es esencial, otros hacen esfuerzos para
desplegar equilibrio de carga con NEE en varios escenarios. Diferentes servicios o
inquilinos pueden necesitar sus propias carga dedicada y especializada de equilibrio
de las implementaciones del algoritmo y no quieren que se afectan entre sí, incluso si
alguna carga
XIA et al .: Una encuesta sobre Software-Defined Networking
implementaciones de equilibrio se descomponen. En esta consideración, Koerner et al. introducir dispositivos se mueven de un lugar a otro, las conexiones pueden ser entregados
algoritmos de balanceo de carga diferenciadas para los distintos tipos de trá fi co, por ejemplo,
el tráfico web fi co y el tráfico de correo electrónico fi co, para lograr implementaciones del
algoritmo de equilibrado dedicados y especializados en función de los requisitos de los
servicios y cargas de trabajo [183]. En otra situación, un equilibrador de carga frontal tiene
que dirigir todas las solicitudes y puede llegar a ser el cuello de botella de un centro de datos.
Para resolver este problema, Handigol et al.
presente Plug-n-Serve (ahora llamado Aster * x [53]), que equilibra la carga sobre una red
no estructurada arbitraria usando una implementación de SDN [172]. Controla
directamente caminos tomados por nuevas peticiones HTTP para minimizar el tiempo de
respuesta promedio de los servicios web.
2) Diseño Cruz-capa: Un enfoque cross-layer es una técnica muy promocionado para
mejorar la integración de las entidades en diferentes capas en una arquitectura de capas,
por ejemplo, el modelo de referencia OSI, permitiendo a las entidades en diferentes capas
para intercambiar información entre sí. Como SDN ofrece una plataforma de aplicaciones
para acceder fácilmente a la información de estado de red, los enfoques crosslayer se
pueden desarrollar fácilmente en esta plataforma. En los párrafos siguientes, se presentan
casos de uso para proporcionar QoS garantizados y la mejora de rendimiento de las
aplicaciones que aprovechan la técnica de diseño de capa cruzada.
Muchas aplicaciones de red requieren un cierto nivel de soporte de QoS.
Utilizando información de QoS para una reserva adecuada de recursos de red
representa un enfoque cross-layer eficaz para lograr calidad de servicio
garantizada. Por ejemplo, Ferguson et al.
demostrar mejor calidad de servicio para videoconferencias mediante la recuperación de
programación de ancho de banda disponible de un controlador SDN. A continuación, la hora más
temprana a la que una llamada de vídeo o, alternativamente, una llamada de audio se pueden
hacer con la garantía de calidad se calcula [55]. Como otro ejemplo, Jeong et al. presentes
compatibles con QoS de red del sistema operativo (QNOX) para ofrecer servicios de calidad de
servicio garantizados, como la evaluación de calidad de servicio QoS cuenta virtual de la
incrustación de la red y de extremo a extremo de la red [56]. Para una solicitud exigentes una red
virtual con requisitos de QoS en el ancho de banda de enlace virtual y el retardo entre los nodos
virtuales, QNOX hará QoSaware asignación para la red virtual en la red de sustrato. QNOX
también supervisa la QoS de extremo a extremo que ofrecen resultados medidos para ayudar a
hacer cambios operacionales.
Del mismo modo, encaminamiento adaptativo puede también mejora el rendimiento
de las aplicaciones. Por ejemplo, Wang et al. proponer un enfoque cross-layer para con fi
gura red subyacente en tiempo de ejecución basado en la dinámica de grandes
aplicaciones de datos [184], teniendo ventajas de la alta recon fi gurability de dispositivos
de conmutación SDN así como de alta velocidad y recon fi gurability de conmutadores
ópticos. Utilizan Hadoop como un ejemplo y el diseño de estrategias de planificación de
tareas de Hadoop para acomodar red dinámica con fi guración de una red híbrida con
Ethernet y conmutadores ópticos. Sus informes de análisis preliminares mejoraron
rendimiento de la aplicación y utilización de la red con relativamente baja sobrecarga con
fi guración.
B. Roaming sin límites
Los teléfonos inteligentes y las tabletas se están convirtiendo en dispositivos que dominan en el
acceso a Internet. Estos dispositivos móviles acceder a Internet de forma inalámbrica. Para garantizar
la conectividad continua, mientras que éstos
39
desde una estación base a otra, o incluso de una red inalámbrica a otra.
Uniformidad de traspaso es crítico para aplicaciones para proporcionar un servicio
ininterrumpido. Handover en la literatura actual es a menudo limitada a las redes
de una sola portadora con la misma tecnología. En SDN, redes de diferentes
portadoras con diferentes tecnologías podrían tener un plano de control ed fi uni
común. Esto permite la movilidad ilimitada con seamless handover conexión
inalámbrica entre diferentes tecnologías y portadores, como se muestra en la Fig.
2.
Varios esquemas de transferencia se han desarrollado sobre la base de SDN.
Por ejemplo, Yap et al. proponer algoritmos de traspaso entre redes Wi-Fi y
WiMAX, incluyendo Hoolock, que explota varias interfaces en un dispositivo, y norte-
casting, que duplica tráfico c a través norte caminos distintos [173] - [175]. Estos
esquemas de transferencia se pueden implementar fácilmente con NEE para
reducir la pérdida de paquetes y mejorar el rendimiento TCP durante el traspaso.
Otro caso de uso es Odin, que es un marco SDN prototipo para redes WLAN
empresariales [176]. Odin asigna una única fi cación identi conjunto de servicios
básicos (BSSID) para cada cliente conectado. Traspaso se realiza retirando el
BSSID de un punto de acceso inalámbrico física (AP) y el desove a otro. Odin
exhibe bajo retardo en re-asociación, sin degradación de rendimiento y el mínimo
impacto de descarga HTTP, ya sea en una sola o múltiples traspasos.
Mantenimiento C. Red
errores guración fi estafadores son causas comunes de fallas en la red. Se ha
informado de que más del 60% de inactividad de la red se debe a errores con fi
guración humanos [185]. Lo peor es que las herramientas de red existentes que tienen
que ver con el diagnóstico individual como ping, traceroute, tcpdump, y NetFlow, no
pueden proporcionar una solución de mantenimiento de la red automatizado e integral.
A modo de comparación, la gestión centralizada y automatizada y aplicación de
políticas coherentes, inherente a las redes SDN, ayudar a reducir los errores con fi
guración. Por otra parte, con una visión global y el control central de la con fi guración,
SDN ofrece oportunidades para diseñar mecanismos integrales de diagnóstico y
pronóstico de la red para el mantenimiento de la red automatizado, como se describe
en los siguientes párrafos.
herramientas de diagnóstico de red como NDB [ 186] y OFRewind [177] son ​cruciales
para detectar causas de fallo en la red. Inspirado por
GDB, NDB es un depurador de red que proporciona traza de eventos de red. Cada vez que un
paquete visita un dispositivo de conmutación, un pequeño “postal” se envía de vuelta a un
controlador. El controlador entonces construir una traza inversa para la depuración de la red.
Tomando una estrategia similar, OFRewind registra constantemente eventos de red que
aparecen en una red. Una característica novedosa de OFRewind es que repeticiones eventos
registrados más adelante para solucionar problemas de la red.
Una clave beneficio de mecanismos de pronóstico basado-SDN es que el control central
de una implementación SDN puede resolver directamente fallos de la red con más corto
tiempo de convergencia de encaminamiento [180]. Por ejemplo, Sharma et al. proponer un
mecanismo de restauración rápida para SDN [187]. Después de la detección de fallo, el
controlador calcula nuevos caminos de reenvío para las rutas afectadas y reglas de reenvío
actualizaciones paquete inmediatamente sin esperar a que las reglas de reenvío viejos de
expirar.
40 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 1, PRIMER TRIMESTRE 2015

D. Seguridad de Red

seguridad de la red es una parte importante de la seguridad cibernética y está

ganando atención. prácticas de seguridad de red tradicionales despliegan rewalls fi y
servidores proxy para proteger una red física. Debido a la heterogeneidad en las
aplicaciones de red, asegurando accesos exclusivos de las aplicaciones de red
legítimos implica la aplicación de una política de toda la red y tedioso con fi guración
de rewalls fi, servidores proxy y otros dispositivos. En este aspecto, SDN ofrece una
plataforma conveniente para centralizar, combinar y revisar las políticas y con fi
guraciones para asegurarse de que la aplicación cumple con la protección requerida
evitando así las brechas de seguridad de manera proactiva.

Por otra parte, SDN proporciona mejores maneras de detectar y defensa de

ataques de forma reactiva. Capacidad de recoger el estado de la red de SDN
permite el análisis de los patrones de trá fi co de posibles amenazas a la
seguridad. Ataques, tales como ataques de ráfaga de baja velocidad y los
ataques de Distributed Denialof-Service (DDoS), se pueden detectar
simplemente mediante el análisis de patrón de tráfico c [71], [188]. Al mismo
tiempo, SDN proporciona control programático sobre tráfico c flujos. En
consecuencia, tráfico c de interés se puede dirigir de manera explícita a los
sistemas de prevención de intrusiones (IPSS) para inspección profunda de
paquetes (DPI) [189], [190]. Si se detectan ataques, SDN puede instalar reglas
de reenvío de paquetes a los dispositivos de conmutación para bloquear el
ataque tráfico c entren y que se propaga en una red [55], [119].
Por último, SDN es más capaz de proporcionar un control directo y de grano fino a
través de redes, y le da la oportunidad de poner en práctica nuevas estrategias de
protección de seguridad. Por ejemplo, Jafarian et al. desarrollar Moving Target Defensa
(MTD) basado en el control ef fi ciente de SDN. Un IP virtual se asocia con cada host
para la transmisión de datos y está mutado aleatoriamente con alta imprevisibilidad y la
tasa mientras que un IP real del anfitrión es estática. Controladores especificarán
traducción entre la dirección IP virtual e IP real, mientras que el mantenimiento de la
integridad con fi guración [178]. Como otro ejemplo, Mendonca et al. AnonyFlow
presente, un servicio de forma anónima dentro de la red de punto final diseñada para
proporcionar privacidad a los usuarios. AnonyFlow realiza la traducción entre AnonID,
red IP e IP de la máquina usando una implementación de SDN [179].
La figura 5. virtualización de red:. Redes virtuales múltiples pueden ser creados en la misma red física,
compartiendo los recursos de infraestructura. Una aplicación SDN sólo puede supervisar y recursos de los
usuarios de su propia red virtual.
en una red desde un controlador, por ejemplo, libNetVirt [199], [200]. Con esta plataforma,
diferentes estrategias se pueden desarrollar en la capa de aplicación para automatizar la
configuración inalámbrica con la red para cortar en rodajas.
En la investigación SDN, FlowVisor es un ejemplo líder que proporciona funciones
para rebanar los recursos de red, incluyendo el ancho de banda, topología, fl ow espacio,
la conmutación de la CPU del dispositivo, espacio tabla de reenvío, y canal de control
[201], [202]. FlowVisor se encuentra entre los controladores de huéspedes y dispositivos
de conmutación que actúan como un proxy transparente a FI mensajes de control de filtro
de tal manera que un controlador huésped sólo puede ver y manipular su propia red
virtual. FlowVisor es una herramienta útil para crear redes virtuales desde una red física
para los experimentos de investigación [203] y para compartir una red física con varios
usuarios con el aislamiento clara [204]. En otro enfoque, Gutz et al. introducir un enfoque
de virtualización de red, proporcionando el aislamiento a un nivel de idioma [121]. En este
enfoque, teniendo una colección de Definiciones rebanada DE y sus aplicaciones
asociadas como una entrada, se genera una lista de reglas de envío de paquetes para
cada dispositivo de conmutación para crear una red virtual correspondiente para cada
aplicación.
F. verde Networking

establecimiento de una red verde se ha convertido en importante en el diseño de la red y el

despliegue de beneficios económicos y ambientales. Diferentes enfoques han sido considerados

para lograr una red verde, incluyendo, pero no limitado a, la adaptación de enlace de datos bajo

consumo energético, consciente de la energía de trá fi co proxy, infraestructura de energía y

E. virtualización de redes
cuenta con reconocimiento de aplicaciones de energía, como se sugiere en [205].

virtualización de la red es una técnica popular para permitir múltiples arquitecturas de

red heterogénea a cohabitan en una infraestructura compartida [198] y desempeña un Resulta que los dispositivos de conmutación SDN no pueden ofrecer directamente bene fi

papel significativo en el modelo IaaS. Una práctica común de virtualización de la red es cios en la reducción de energía en el funcionamiento de la red [206]. Sin embargo, SDN podría

para cortar una red físico en múltiples instancias virtuales y asignarlos a los diferentes ofrecer promesas significativas en el apoyo a la minimización del consumo de energía de toda

usuarios, controladores o aplicaciones SDN, como se ilustra en la Fig. 5. Métodos de la red. Como prueba, Heller et al. demostrar la adaptación de enlace de datos-consciente de

virtualización convencional usando túneles y etiquetas VLAN o MPLS requieren energía con SDN [54]. Proponen un mecanismo para determinar enlaces de datos mínimos y

configuraciones fi tediosas en todos los dispositivos de red implicados. A modo de dispositivos de conmutación para una red de centro de datos basado en las cargas tráfico c y

comparación, SDN ofrece una plataforma que permite con fi guración de todos los dinámicamente apagar enlaces redundantes y dispositivos de conmutación para las

dispositivos de conmutación operaciones de fi cientes energía.

XIA et al .: Una encuesta sobre Software-Defined Networking
TABLA III
E Xperiment S ETUP DE SDN A plicaciones
G. SDN para Cloud Computing
La computación en nube está cambiando la forma de hacer la computación y de negocios.
disposiciones, los recursos de computación y almacenamiento en la demanda y cargas sobre
el uso con servidores y virtualización de la red. SDN proporciona oportunidades para extender
el modelo de aprovisionamiento de servicios de IaaS más allá de los recursos de cálculo y
almacenamiento para incluir un rico conjunto de acompañar a los servicios de red para
obtener más flexible y e fi ciente cloud computing [207].
redes de centros de datos para la computación en la nube tienen unos requisitos clave,
incluyendo escalabilidad para el despliegue a gran escala, la independencia de la ubicación
para la provisión de recursos dinámica, la diferenciación de QoS para diferentes inquilinos,
y la visibilidad de la red y de grano fino de control [208]. Como se ha mencionado en el
apartado anterior, SDN puede satisfacer plenamente estos requisitos. En los párrafos
siguientes, se discuten dos problemas únicos para la computación en la nube, es decir, la
conmutación virtual y la migración VM.
conmutación virtual se utiliza para la comunicación entre las máquinas virtuales en el
mismo huésped. conmutación virtual convencional provisto de hipervisores, sin embargo,
no proporciona visibilidad fi ciente y control. Como solución, vSwitch abierto proporciona
conmutación borde virtual para máquinas virtuales con visibilidad y control el
aprovechamiento de la idea de SDN [74], [75]. Estos vSwitch también informan de estado
de la red a y recibir regla de reenvío de paquetes de controladores SDN, al igual que SDN
dispositivos de conmutación. Sin embargo, vSwitch ofrecen recursos de almacenamiento y
de procesamiento limitadas en comparación con los conmutadores físicos. Moshref et al. presentar
los investigadores descubrieron que la implementación de una red controlable software
una nube virtual de la regla de base de información (vCRIB) para superar estas
limitaciones de recursos [209]. vCRIB Fi automáticamente nds la colocación regla óptima
entre conmutadores físicos y virtuales y reducir al mínimo tráfico c gastos generales y
adaptarse rápidamente a la dinámica de la nube como tráfico c cambios y migraciones VM.
migración VM se utiliza ampliamente en los centros de datos para la multiplexación
estadística o patrón de comunicación dinámico cambiando para lograr mayor ancho de
banda para hosts fuertemente acoplados [210]. migración VM convencional es a menudo
limitada a un único dominio de difusión, ya que las direcciones IP deben ser conservados a
través de dominios de difusión. Sin embargo, los mensajes Address Resolution Protocol
(ARP) no pueden ir más allá de un dominio de difusión. soluciones basadas en IP móvil y /
Identi fi cador del Protocolo de separación Locator (LISP) [211] - [213] pueden fi jar este
tema y han inspirado SDN solu-
41
ciones. Específicamente, la OpenDaylight [214] controlador SDN ha añadido un servicio de
mapas basado LISP. SDN puede preservar la conectividad VM durante intra e inter centro
de datos VM migración [182], [215] - [221] mediante la inserción de reglas adecuadas
reenvío de paquetes en los dispositivos de conmutación para dirigir tráfico c a la nueva
ubicación VM. Como ejemplo de los centros de datos inter VMmigration, Mann et al.
presentes CrossRoads migren VM a través de los centros de datos sin problemas usando una
implementación de SDN [218]. CrossRoads se extiende la idea de la independencia de la
ubicación basada en seudo direcciones propuestas en la creación de redes en la nube para
trabajar con los controladores que regulan su red de centros propios datos. Cruz resolución
subred ARP se utiliza para distinguir una dirección IP fuera una subred después de la
migración inter centro de datos. La resolución será entonces dirigir paquetes con esta dirección
IP a su destino en un centro de datos externo. Como resultado, las conexiones de máquinas
virtuales se pueden mantener durante la migración del centro de datos entre otras.
VI. do ASE EN PAG OINT: O BOLÍGRAFO F BAJO
OpenFlow es primero propuso byMcKeown et al. con el objetivo de permitir
experimentos fácil de la red en una red de campus [222] y se utiliza actualmente en la
mayoría de las prácticas SDN como se muestra en la Tabla III. experimentos fase
temprana utilizando OpenFlow apuntan principalmente a la creación de una red
controlable software separado se centra en controlar el reenvío de paquetes. Más tarde,
por separado usando OpenFlow es en realidad un habilitador práctica del llamado
“software-de fi nido en red”.
OpenFlow toma ventajas del hecho de que la mayoría de los conmutadores Ethernet y
routers modernos contienen tablas de fluencia para funciones de red esenciales, tales como
enrutamiento, subredes, protección cortafuego, y el análisis estadístico de los flujos de datos.
En un interruptor de OpenFlow, cada entrada en la tabla de flujo tiene tres partes, “cabecera”
para hacer coincidir los paquetes recibidos, “acción” para de fi nir qué hacer para los
paquetes coincidentes, y “estadísticas” de la emparejado trá fi co flujo. Como se ilustra en la
Fig. 6, el protocolo OpenFlow ofrece servicios de manipulación de mesa convenientes flujo
para un controlador a insertar, eliminar, modificar, y la búsqueda de las entradas de la tabla
de flujo a través de un canal TCP segura remota.
OpenFlow puede ser visto como un protocolo especí fi cación utilizado en dispositivos de
conmutación y los controladores de interfaz. Su idea de
42
Fig. 6. Interruptor OpenFlow. La tabla de flujo es controlado por un controlador remoto a través del canal
seguro [222].
la creación de una red separada exclusivamente para el control de la red se
manifiesta el concepto clave de SDN y sienta las bases para la programación
de la red y el control centralizado lógicamente. En el desarrollo de la SDN y
OpenFlow, sus conceptos y enfoques de diseño van de la mano con la otra.
Por un lado, muchos conceptos en SDN se basan en el diseño de OpenFlow.
Por otra parte, como el concepto de NEE se vuelve más clara y más maduro,
entonces influye en el desarrollo futuro de OpenFlow. En otras palabras,
OpenFlow de fi ne el concepto inicial de la SDN y SDN rige el desarrollo futuro
de OpenFlow. En las siguientes subsecciones, que primero presente proceso
de normalización y casos de implementación de OpenFlow. A continuación,
presentamos algunos proyectos de software ampliamente utilizado OpenFlow,
y por último comparamos con las fuerzas OpenFlow,
A. Normalización y despliegue
El OpenFlow especí fi cación está evolucionando continuamente con nuevas
características en cada nueva versión. Con más y más vendedores de la liberación de sus
productos y soluciones OpenFlow habilitado, más proyectos de software están
desarrollando en OpenFlow y más organizaciones desplegar redes OpenFlow habilitado,
un ecosistema completo y bien funcionado-está siendo construido alrededor de
OpenFlow.
El OpenFlow Interruptor Consortium [223] libera la aplicación primer OpenFlow
referencia, versión 0.1.0, con el código fuente, el 30 de noviembre de 2007. A
continuación, publicó la versión OpenFlow 1.0 el 31 de diciembre de 2009, que
añade múltiples colas por puerto de salida para mínimo garantías de ancho de
banda. La próxima versión 1.1 fue lanzado el 28 de febrero de 2011, que introdujo
varias tablas de procesamiento de tubería. Después de eso, el papel de la
normalización de OpenFlow especí fi cación se trasladó a la ONF [29]. En diciembre
de 2011, la junta aprobó la ONF OpenFlow versión 1.2 y lo publicó en febrero de
2012, que ha añadido soporte para IPv6. Más tarde el 19 de abril de 2012, ONF
aprobó además OpenFlow versión 1.3 y el 25 de junio, una versión fi ed rectos fue
lanzado con DE-Con fi g 1.1, que es un protocolo para con fi gura y gestionar
interruptores OpenFlow y controladores.
Junto con el proceso de OpenFlow normalización, muchos interruptores
OpenFlow y controladores de superficie. El primer OpenFlow
ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 1, PRIMER TRIMESTRE 2015
interruptores se construyen utilizando hardware de red abierta, por ejemplo,
NetFPGA [80], [81]. Después de la primera aparición, vendedores, incluyendo
NEC, IBM, Juniper, HP, Cisco, Huawei, Pica8 / Pronto, Centec, Dell / Force10,
Detalle, Mellanox, NoviFlow, Arista, Brocade, NetGear y muchos más, empezar a
lanzar su OpenFlow interruptores. Para los controladores, hay controladores
comerciales, tales como ProgrammableFlow controlador de NEC y controlador de
red grande de Big Switch, así como controladores de código abierto, como OMNI
[224], Trema [225], Ryu [226], Reflector [227] , NOX [228], [229], y OpenDaylight
[214], que se enumeran en la Tabla IV. Otros proyectos relacionados con redes
también comienzan a utilizar OpenFlow, por ejemplo, OpenStack Quantum para
redes de computación en la nube.
Con tantos conmutadores de OpenFlow y controladores disponibles, redes OpenFlow han sido y
están siendo desplegados, tanto para fines de investigación y producción. La primera gran red OpenFlow
escala fi se despliega por el proyecto OpenRoads Stanford [230]. El despliegue de Stanford OpenRoads
consta de cinco conmutadores Ethernet 1GE OpenFlow 48 puertos, 30 Wi-Fi puntos de acceso y 1
estación base WiMAX. En este banco de pruebas, los SSID son utilizados para identificar las rebanadas
de la red. Un servidor DHCP se utiliza para asignar direcciones IP a los clientes móviles. OpenRoads
también tiene un sistema de registro, herramientas de gráficos y visualización de datos en tiempo real
para controlar el sistema. Estas herramientas han sido cuidadosamente diseñados para ser
complementarios pero independientes, y que son reutilizables para otras implementaciones. El
despliegue OpenRoads abre el camino para desplegar OpenFlow en redes de campus con ambas
conexiones cableadas e inalámbricas. Aparte de las implementaciones de propósito de investigación en
redes de campus, OpenFlow también se ha desplegado en las redes de producción. Google ha
implementado un software definida WAN llamado “B4” que conecta los centros de datos de Google en
todo el planeta durante tres años [231]. B4 es un enfoque híbrido con el apoyo simultáneo de los
protocolos de enrutamiento existentes y enfoque novedoso OpenFlow SDN. Para el plano de datos,
Google construye sus propios conmutadores de OpenFlow habilitado de múltiples chips de silicio
interruptor comerciante. Para soportar los protocolos de legado de enrutamiento como BGP e IS-IS, B4
se ejecuta un código abierto Quagga [34] pila en el plano de control. paquetes de protocolo de
enrutamiento son redirigidos a Quagga desde el plano de datos. actualizaciones de la tabla de
enrutamiento de Quagga se traducen luego a actualizaciones de la tabla de fluencia en los interruptores.
Con técnicas como la ingeniería tráfico centralizado fi co para compartir el ancho de banda entre las
aplicaciones con posibilidad de usar varias rutas, notablemente, B4 muestra cerca de la utilización del
enlace 100%. B4 soportes existentes protocolos de enrutamiento y OpenFlow, por lo tanto ofrece una
solución menos perjudicial y más económico para el despliegue OpenFlow en las redes de producción
para las empresas. OpenFlow redes se han expandido rápidamente, desde su primera implementación.
Ahora, los productos de OpenFlow están permeando en laboratorios, aulas [232], las redes de bancos de
pruebas [58], [59], [233] - [237], centros de datos y redes de proveedores de servicios [238]. OpenFlow
redes se han expandido rápidamente, desde su primera implementación. Ahora, los productos de
OpenFlow están permeando en laboratorios, aulas [232], las redes de bancos de pruebas [58], [59], [233]
- [237], centros de datos y redes de proveedores de servicios [238]. OpenFlow redes se han expandido
rápidamente, desde su primera implementación. Ahora, los productos de OpenFlow están permeando en
laboratorios, aulas [232], las redes de bancos de pruebas [58], [59], [233] - [237], centros de datos y
redes de proveedores de servicios [238].
B. OpenFlow Proyectos de Software
Hoy en día existen muchos proyectos de software OpenFlow. Entre ellos controlador
de NOX [228], [229] y MiniNet simulador [239] son ​las herramientas más utilizadas en
investigaciones relacionadas SDN.
NOX es el controlador de primer OpenFlow. Permite que las aplicaciones que se ejecutarán
sobre la base de una visión centralizada de la red utilizando
XIA et al .: Una encuesta sobre Software-Defined Networking
TABLA IV O PEN F LOW C
ONTROLLERS
Fig. 7. IETF fuerzas Arquitectura. Un elemento de red fuerzas consiste de dos tipos de
componentes, a saber, los elementos de control (CEs) y los elementos de reenvío (FES). Administrador
de CE y FE Manager, que residen fuera de las fuerzas de NE, proporcionan con fi guración a la CE
correspondiente o Fe en la fase de pre-asociación.
nombres de niveles altos en comparación con los algoritmos distribuidos en las direcciones
de bajo nivel. Las aplicaciones se escriben ya sea Python o C ++ y se cargan de forma
dinámica. funciones de infraestructura y speedcritical centrales de NOX se implementan en
C ++.
MiniNet es un simulador de red para el prototipado rápido de una gran red de
OpenFlow. Una red virtual se crea de acuerdo con enlaces fi cado, hosts, dispositivos y
controladores de conmutación. Una interfaz de línea de comandos (CLI) se
proporciona para interactuar con la red virtual, por ejemplo, comprobar la conectividad
entre dos hosts usando ping. Desde MiniNet proporciona un entorno simulado para la
experimentación, las nuevas ideas pueden ser desarrolladas y probadas en MiniNet
antes de desplegarse en un entorno real de una manera directa. Uso de características
de peso ligero de virtualización a nivel de sistema operativo, incluyendo procesos y
espacios de nombres de red, para crear redes virtuales permite MiniNet para escalar a
cientos de nodos en un solo equipo.
C. OpenFlow y fuerzas
OpenFlow tiene como objetivo separar el plano de control desde el plano de datos.
Otro esfuerzo bien conocido para separar el plano de control desde el plano de datos y
normalizar el intercambio de información entre los planos de control y de datos es
fuerzas [37] - [40] propuesto por IETF. Como se muestra en la Fig. 7, un elemento de
red fuerzas (NE) se compone de múltiples elementos de reenvío (FES) y múltiples
elementos de control (CEs). FE proporciona un procesamiento por paquete y es
instruido por CEs sobre cómo procesar los paquetes.
43
TABLA V
C OMPARISONS E ntre O PEN F LOW Y F O CES
Fuerzas utiliza Capa fuerzas Protocolo (fuerzas PL) para definir el protocolo entre FE
y CEs, y la Capa fuerzas protocolo de asignación de Transporte (fuerzas TML) para
transportar los mensajes de PL. Por lo tanto, las fuerzas permite la coexistencia de
múltiples TMLS de diferentes proveedores y la interoperabilidad está garantizada
siempre que ambos extremos apoyan la misma TML. El reenvío de paquetes en FE
se basa en la abstracción de bloques funcionales lógicas (LFBs) [240], cada uno de
los cuales tiene una única función específico de paquetes de procesamiento. En los
párrafos siguientes, se presenta una comparación completa entre OpenFlow y
fuerzas en términos de sus objetivos, la arquitectura, el modelo de reenvío y el
protocolo de la interfaz, tal como se resume en la Tabla V [241], [242]:
• Gol: Fuerzas no está diseñado con una visión a largo plazo para implementar
SDN. El objetivo de las fuerzas es separar el plano de datos del plano de
control, mientras que OpenFlow está diseñado para SDN;
• Arquitectura: Fuerzas NE son funcionalmente equivalentes a los routers convencionales y que
todavía se ejecutan los protocolos de enrutamiento al igual que los routers convencionales. A
diferencia de fuerzas, interruptores OpenFlow serán controlados por un controlador y pueden
funcionar sin ningún tipo de protocolos de enrutamiento;
• Reenvío de modelo: OpenFlow modelo reenvío proporciona programabilidad que está
restringida a prede fi capacidades definidas de interruptores OpenFlow. Por ejemplo,
acciones sólo prede fi nida pueden ser elegidos para procesar un paquete con
OpenFlow. Fuerzas lógica de envío es más flexible, ya que la función de cada LFB y
la topología LFB puede ser dinámicamente especi fi. Por lo tanto, las nuevas
acciones de procesamiento de paquetes pueden ser creados;
• Interfaz de protocolo: En términos de mensajes de protocolo, las fuerzas soporta más
características que OpenFlow, tales como lotes de mensajes, la selección del modo
de ejecución, y la canalización de comandos.
44 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 1, PRIMER TRIMESTRE 2015

TABLA VI SDN R
ELACIONADAS R ESEARCHES

En resumen, las fuerzas proporciona más fl exible modelo de reenvío y funciones de
los protocolos más ricos. Sin embargo, debido al modelo de negocio disruptivo
interpuesto por el modelo de reenvío LFB y falta de apoyo de código abierto, las fuerzas
no es tan ampliamente adoptados como OpenFlow. OpenFlow todavía puede aprender
mucho de ambas ventajas y deficiencias de fuerzas para un mayor éxito.
mejorar el rendimiento, la innovación y alentado. Por otra parte, hemos proporcionado
un estudio de la literatura de investigaciones recientes SDN en la capa de
infraestructura, la capa de control, y la capa de aplicación, tal como se resume en la
Tabla VI. Por último, hemos introducido OpenFlow, la aplicación de facto SDN.

VII. do CONCLUSIÓN, re DISEÑO GRAMO IRECTRICES
Y F UTURO R NVESTIGACIONES
Para concluir, primero presentamos un breve resumen de todo el artículo. A continuación
enumeramos los principios de diseño que se han adoptado en las investigaciones relacionadas SDN.
Por último, señalamos unos SDN algunos aspectos relacionados que necesitan los futuros esfuerzos
de investigación.
B. Pautas de diseño
El éxito de SDN requiere mejoras y desarrollos en todas las tres capas,
incluyendo la capa de infraestructura, la capa de control, y la capa de aplicación. Se
necesita la colaboración de diferentes organizaciones, incluyendo proveedores,
instituciones académicas y las comunidades, y el conocimiento interdisciplinario que
cubren tanto de hardware como de software. En los párrafos siguientes,
describimos algunas pautas de diseño para el desarrollo y la investigación futura en
SDN:

A. Resumen y conclusión
• Un dispositivo de conmutación de SDN es relativamente simple, con un plano de control

Los recientes desarrollos en ámbito de las TIC, por ejemplo, móvil, multimedia, separado. El dispositivo de conmutación de SDN puede ser más fácil de fabricar y su costo

nube, y los datos grandes, están exigiendo para un acceso más cómodo a Internet, más será más barato utilizar el silicio comercial. Sin embargo, las cuestiones sobre el cambio de

ancho de banda de los usuarios, así como una gestión más dinámica de los diseño de hardware del dispositivo están todavía abiertas. Específicamente, los dispositivos

proveedores de servicios. SDN se considera como una solución prometedora para de conmutación SDN necesita más espacio de memoria y una mayor velocidad de

satisfacer estas demandas. En el presente trabajo, hemos presentado el concepto de procesamiento con un coste económicamente viable. La integración de diversas tecnologías

NEE y destacó bene fi cios de SDN en ofrecer una mayor con fi guración, de hardware nuevos es necesario.
XIA et al .: Una encuesta sobre Software-Defined Networking
TABLA VII C ACTUAL I
NVESTIGACIÓN P ROYECTOS
• SDN se desarrolló originalmente para las redes basadas en IP en los
campus. Por lo tanto, la ampliación de cobertura ubicua de SDN requiere uni
fi cación y la integración con tecnologías avanzadas en la transmisión
inalámbrica y óptica (es decir, SDR y GMPLS, respectivamente). Estas
tecnologías dan oportunidades para un controlador SDN para tener un control
generalizado de todos los parámetros y el comportamiento de la red.
Integrado con estas tecnologías, SDN obtendrá un control más adecuado de
la infraestructura para lograr la utilización de recursos de infraestructura más
e fi ciente.
• Para mejorar ventajas de desacoplar el plano de control desde el plano de datos,
un expresivo y completa interfaz de alto nivel para el acceso y los dispositivos de
conmutación de control debe ser proporcionado para facilitar aún más con la red
fi configuración y gestión. Habilidades de diversas áreas de la informática, como
la teoría del lenguaje de programación, métodos formales y sistemas distribuidos,
se deben aplicar para permitir la generación automática de lenguaje de alto nivel
de las políticas descritas en las normas de bajo nivel y sin conflictos y garantizar
la consistencia durante el procedimiento de actualización de reglas.
• técnicas de medición de la red también son útiles para la recolección de estado de
la red. Para las redes a gran escala, varios controladores son necesarios.
algoritmos de sincronización estudiados en sistemas distribuidos y sistemas de
bases de datos pueden ser adoptados para sincronizar el estado de la red
percibidas entre múltiples controladores.
• Un controlador SDN tiene que manejar una enorme cantidad de eventos de
interacción con sus dispositivos de conmutación asociados. Para garantizar la e fi
ciencia de las operaciones de la red, los métodos de optimización de software y
análisis algoritmo se pueden utilizar para mejorar el rendimiento del controlador, y
debidamente arquitectura diseñada puede ayudar a disminuir la frecuencia de
solicitud.
• SDN proporciona una plataforma para implementar diversas aplicaciones SDN. SDN
aplicaciones pueden acceder a una vista de red y la capa cruzada mundial de
información para tomar mejores decisiones de operación de la red. SDN
controladores aseguran que éstos de-
45
cisiones se llevan a cabo adecuadamente en la capa de infraestructura. Sin embargo, se
requiere la participación de los desarrolladores de software para convertir las ideas
innovadoras de soluciones que pueden traer beneficios económicos, sociales y
medioambientales.
C. Investigación Future
Muchos de los retos SDN todavía necesitan más atención de la investigación y muchas
organizaciones han iniciado proyectos de investigación en varios aspectos de la SDN
como se muestra en la Tabla VII. En los párrafos siguientes se indican las cuestiones
abiertas que cubren todo el ciclo de vida de SDN de la normalización, implementación,
despliegue:
• La estandarización de SDN: Siendo la aplicación de facto del concepto
SDN, OpenFlow es de ninguna manera la única aplicación SDN. IETF
también ha lanzado un marco SDN [255]. El ETSI Industria Speci fi
cación Group (ISG) para las funciones de red de virtualización (NFV) se
ha formado recientemente para promover NFV, que es altamente
complementaria a SDN [256]. Al vencimiento de las implementaciones
SDN, una comparación exhaustiva entre todas las aplicaciones posibles
del SDN debe llevarse a cabo. En la capa de control, hemos sido
testigos de muchos proyectos dirigidos a problemas similares que
utilizan enfoques similares. Sin embargo, una solución hablaba aún no
ha surgido. La fragmentación en funciones del controlador y API
proporcionadas por los controladores puede ser una barrera de potencial
para el desarrollo comercial de SDN. Además, OpenFlow especí fi
cación evoluciona rápidamente y permite diferentes interpretaciones. Por
lo tanto,
• Implementación de SDN: El enfoque actual SDN de desacoplamiento de plano de
control completamente de plano de datos sugiere una eliminación total de cualquier
protocolos de enrutamiento a bordo de los dispositivos de conmutación. Este
enfoque puede ser demasiado idealista, lo que puede impedir SDN de la
adaptación generalizada. Una inmediata y directa a transformar idealista SDN se
46 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 1, PRIMER TRIMESTRE 2015
necesitará una inversión de riesgo mucho para reemplazar todos los dispositivos de red
convencionales. En la fase de transición de los dispositivos de conmutación
convencionales para desacoplado totalmente dispositivos de conmutación SDN,
dispositivos de conmutación semi-desacoplado, que se ejecutan los protocolos de
enrutamiento y también se puede controlar de forma remota son útiles para suavizar la
evolución a SDN idealista. Existen algunos otros inconvenientes de diseño en la
aplicación SDN actual. Por ejemplo, en OpenFlow, un largo de cabecera se utiliza para
hacer coincidir para permitir un control más granular, es decir, doce tuplas en OpenFlow
1,0 y más en OpenFlow 1.1. Esto puede requerir más espacio de almacenamiento en
regla y más tiempo en las operaciones de búsqueda. Además, el diseño de proxy
ampliamente utilizado entre los dispositivos de conmutación y el controlador ya ha
demostrado un efecto negativo en el rendimiento [152], [204].
• El despliegue de SDN: El estudio adicional de SDN en redes de operadores con
los requisitos de grado carrier [258], redes de malla inalámbrica con movilidad
rápida cliente [259], y las redes de sensores inalámbricos que requieren alta
fiabilidad y asequibilidad [260], [261] es también necesario para el despliegue
de ancho de SDN.
Por último, cabe destacar que estas cuestiones señaladas aquí no pretenden ser
exhaustivas. Sin embargo, muchos más problemas aún no se han atendido en esta zona
activa y prometedora de la SDN.
R EFERENCIAS
[1] Las predicciones de IDC 2013: competir en la plataforma tercero, IDC,
Framingham, MA, EE.UU., noviembre de 2012, Libro Blanco. [En línea]. Disponible:
http://www.idc.com/research/Predictions13/downloadable/238044.pdf [2] P. Mell y T. Grance, “El
NIST definición de computación en la nube (borrador),”
NIST Special Publication, vol. 800-145, p. 7, 2011.
[3] J. Gantz y D. Reinsel, “extraer valor de caos,” IDC,
Framingham, MA, EE.UU., Libro Blanco, Jun. 2011. [En línea]. Disponible:
http://www.emc.com/collateral/analyst-reports/idc-extracting-valuefrom-chaos-ar.pdf [4] J.
Manyika et al., “Big data: La próxima frontera de la innovación,
la competencia y la productividad “, McKinsey Global Inst., Mumbai, India, pp. 1-137, 2011.
[5] P. y D. Cesar Geerts, “Pasado, presente y futuro de la televisión social: una cate-
gorization,”en Proc. IEEE CCNC, 2011, pp. 347-351.
[6] Y. Jin, X. Liu, Y. Wen, y J. Cai, “interacción de pantalla Inter para la sesión
reconocimiento y transferencia basada en la red multimedia nube centrada”en Proc. IEEE ISCAS, 2013,
pp. 877-880.
[7] Y. Jin, Y. Wen, G. Shi, G. Wang, y A. Vasilakos “, CoDaaS:
Una plataforma experimental nube centrada de entrega de contenido para el contenido generado por el
usuario,”en Proc. En t. Conf. Comput. Netw. Commun., 2012, pp. 934-938.
[8] J. Dean y S. Ghemawat, “MapReduce: Simpli fi procesamiento de datos ed en
racimos grandes,” Commun. ACM, vol. 51, no. 1, pp 107-113, enero de 2008. [9] “Cisco Visual
Networking Index:. Global móvil tráfico de datos fi c pronóstico UP-
fecha, 2013-2018 “, San José, CA, EE.UU., Libro Blanco, febrero de 2014. [10] Facebook
línea de tiempo. [En línea]. Disponible: http://newsroom.fb.com/
Cronología
[11] “Cisco Visual Networking Index: El Tiempo y la metodología,
2011-2016 “, San José, CA, EE.UU., Libro Blanco, mayo de 2012. [En línea]. Disponible:
http://www.cisco.com/en/US/solutions/collateral/ns341/
ns525 / ns537 / ns705 / ns827 / white_paper_c11-481360.pdf [12] H. Kim, T. Benson, A.
Akella, y N. Feamster, “La evolución de NET
con fi guración de trabajo: La historia de dos campus,”en Proc. ACM SIGCOMM Conf. Meas de
Internet. Conf., 2011, pp. 499-514.
[13] “¿Qué hay detrás de la red de inactividad?” Sunnyvale, CA, EE.UU., mayo de 2008,
Papel blanco. [En línea]. Disponible: https://www-935.ibm.com/services/ sg / GTS / pdf /
200249.pdf
[14] H. Xie, Y. Yang, A. Krishnamurthy, Y. Liu, y A. Silberschatz, “P4P:
portal de proveedores de aplicaciones” ACM SIGCOMM Comput. Commun. Rdo., vol. 38, no. 4, pp.
351-362, agosto de de 2008.
[15] T.-Y. Huang, N. Handigol, B. Heller, N. McKeown, y R. Johari, “Con-
fusionada, tímida, e inestable: Escoger un vídeo de velocidad de transmisión es duro “, en
Proc. ACM Conf. Meas de Internet. Conf., 2012, pp. 225-238.
[16] X. Chen, ZM Mao, y J. Van Der Merwe, “ShadowNet: Una plataforma para
evolución de la red rápida y segura “, en Proc. Conf. USENIX Annu. Tech. Conf., 2009, p. 3.
[17] R. Perlman, “RBridges: enrutamiento transparente”, en Proc. 23 Annu. Articulación
Conf. IEEE INFOCOM, 2004, vol. 2, pp. 1211-1218.
[18] R. Perlman, D. Eastlake, III, S. Gai, D. Dutt, y A. Ghanwani, Routing
(puentes): RBridges. Protocolo Base especí fi cación, jul 2011, RFC 6325. [En línea].
Disponible: http://tools.ietf.org/rfc/rfc6325.txt [19] J. Pan, S. Pablo, y R. Jain, “Un estudio de la
investigación sobre el futuro In-
arquitecturas Ternet” IEEE Commun. Revista., vol. 49, no. 7, pp. 26-36, Jul. 2011. [20] L.
Zhang et al., “Proyecto denominado Redes de Datos (NDN),” Relatório
Técnico NDN-0001, Xerox Palo Alto Research Center-PARC, Palo Alto, CA, EE.UU., 2010.
[21] A Campbell et al., “Un estudio de las redes programables,” ACM
SIGCOMM Comput. Commun. Rdo., vol. 29, no. 2, pp. 7-23, abril de 1999. [22] L. Popa, A.
Ghodsi, y I. Stoica, “HTTP como el estrecho de la cintura de la
Internet del futuro “, en Proc. Noveno ACM SIGCOMM Workshop Hotnets-IX,
2010, pp. 6: 1-6: 6.
[23] “fi nida en red Software-de: La nueva norma para redes”, Palo Alto,
CA, EE.UU., Libro Blanco, abril de 2012. [En línea]. Disponible: https: // www.
opennetworking.org/images/stories/downloads/white-papers/wp-sdnnewnorm.pdf
[24] T. Nadeau y P. Pan, Software Dirigido Redes planteamiento del problema,
De octubre de 2011, Proyecto de Internet. [En línea]. Disponible: http://www.cisco. com / es / es /
soluciones / garantía / ns341 / ns525 / ns537 / ns705 / ns827 / white_paper_c11-481360.pdf [25]
Open Networking Summit.
[En línea]. Disponible: http: // www.
opennetsummit.org/archives/oct11/site/tutorials.html [26] Temas de actualidad en Software de fi
nido en red (HotSDN). [En línea]. Aprovechar-
poder: http://conferences.sigcomm.org/sigcomm/2012/hotsdn.php [27] Taller Europeo de
Software de fi ne Redes. [En línea]. Aprovechar-
poder: http://www.ewsdn.eu/previous/ewsdn12.html [28] “El software de fi nida de redes: Un
nuevo paradigma para el virtual, dinámico,
flexible networking,” Hopewell Junction, NY, USA, White Paper, Oct. 2012. [Online].
Available: http://ict.unimap.edu.my/images/doc/ SDN%20IBM%20WhitePaper.pdf
[29] Open Networking Foundation (ONF). [Online]. Available: https://www.
opennetworking.org/ [30] J. Smith et al., “Switchware: Accelerating network evolution,” CIS
Dept., Univ. Pennsylvania, Philadelphia, PA, USA, White Paper, 1996. [31] D. Alexander et
al., “The SwitchWare active network architecture,”
IEEE Netw., vol. 12, no. 3, pp. 29–36, May/Jun. 1998. [32] E. Kohler, R. Morris, B. Chen, J.
Jannotti, and M. Kaashoek, “The click
modular router,” ACM Trans. Comput. Syst., vol. 18, no. 3, pp. 263–297, Aug. 2000.
[33] M. Handley, O. Hodson, and E. Kohler, “XORP: An open platform for
network research,” ACM SIGCOMM Comput. Commun. Rev., vol. 33, no. 1, pp. 53–57, Jan.
2003.
[34] Quagga Routing Software Suite. [Online]. Available: http://www.
nongnu.org/quagga/
[35] The BIRD Internet Routing Daemon. [Online]. Available: http://bird.
network.cz/
[36] N. Feamster, H. Balakrishnan, J. Rexford, A. Shaikh, and J. van der
Merwe, “The case for separating routing from routers,” in Proc. ACM SIGCOMM Workshop
FDNA, 2004, pp. 5–12.
[37] L. Yang, R. Dantu, T. Anderson, and R. Gopal, Forwarding and Con-
trol Element Separation (ForCES) Framework, Apr. 2004, RFC 3746. [Online]. Available:
http://www.cisco.com/en/US/solutions/collateral/
ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360.pdf [38] T. Lakshman, T.
Nandagopal, R. Ramjee, K. Sabnani, and T. Woo, “The
softrouter architecture,” in Proc. ACM SIGCOMMWorkshop Hot Topics Netw., 2004, pp. 1–6.
[39] W. Wang et al., “Design and implementation of an open programmable
router compliant to IETF ForCES specifications,” in Proc. 6th ICN,
2007, pp. 1–6.
[40] A. Doria et al., Forwarding and Control Element Separation (ForCES)
Protocol Specification, Mar. 2010, RFC 5810. [Online]. Available:
http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/
ns705/ns827/white_paper_c11-481360.pdf [41] J. Rexford et al., “Network-wide decision
making: Toward a wafer-thin
control plane,” in Proc. HotNets, 2004, pp. 59–64.
[42] A. Greenberg et al., “A clean slate 4D approach to network control
and management,” SIGCOMM Comput. Commun. Rev., vol. 35, no. 5, pp. 41–54, Oct. 2005.
[43] H. Yan et al., “Tesseract: A 4D network control plane,” in Proc. 4th
USENIX Conf. NSDI, 2007, p. 27.
XIA et al.: A SURVEY ON SOFTWARE-DEFINED NETWORKING
[44] A. Farrel, J.-P. Vasseur, and J. Ash, A Path Computation Element
(PCE)-Based Architecture, Aug. 2006, RFC 4655. [Online]. Available:
http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/
ns705/ns827/white_paper_c11-481360.pdf [45] M. Casado et al., “SANE: A protection
architecture for enterprise net-
works,” in Proc. 15th Conf. USENIX-SS, Berkeley, CA, USA, 2006, vol. 15, p. 10.
[46] J. Luo, J. Pettit, M. Casado, J. Lockwood, and N. McKeown, “Prototyp-
ing Fast, Simple, Secure Switches for Etha,” in Proc. 15th Annu. IEEE Symp. HOTI, 2007, pp.
73–82.
[47] M. Casado et al., “Ethane: Taking control of the enterprise,” in Proc.
Conf. SIGCOMM Appl., Technol., Archit., Protocols Comput. Commun.,
2007, pp. 1–12.
[48] M. Casado et al., “Rethinking enterprise network control,” IEEE/ACM
Trans. Netw., vol. 17, no. 4, pp. 1270–1283, Aug. 2009. [49] S. Shenker, M. Casado, T.
Koponen, and N. McKeown, “The future of
networking, and the past of protocols,” presented at the Open Networking Summit, Stanford,
CA, USA, 2011. [Online]. Available: http://www.
opennetsummit.org/archives/apr12/site/talks/shenker-tue.pdf [50] A. Gember, P. Prabhu, Z.
Ghadiyali, and A. Akella, “Toward software-
defined middlebox networking,” in Proc. 11th ACM Workshop Hot Topics Netw., 2012, pp.
7–12.
[51] M. Al-Fares, S. Radhakrishnan, B. Raghavan, N. Huang, and A. Vahdat,
“Hedera: Dynamic flow scheduling for data center networks,” in Proc. 7th USENIX Conf.
NSDI, 2010, p. 19.
[52] M. Ghobadi, S. Yeganeh, and Y. Ganjali, “Rethinking end-to-end con-
gestion control in software-defined networks,” in Proc. 11th ACMWorkshop Hot Topics Netw., 2012,
pp. 61–66.
[53] N. Handigol, S. Seetharaman, M. Flajslik, R. Johari, and N. McKeown,
“Aster ∗ x: Load-balancing as a network primitive,” in Proc. 9th GENI Eng. Conf. (Plenary), 2010,
pp. 1–2.
[54] B. Heller et al., “ElasticTree: Saving energy in data center networks,” in
Proc. 7th USENIX Conf. NSDI, 2010, p. 17.
[55] A. Ferguson, A. Guha, J. Place, R. Fonseca, and S. Krishnamurthi,
“Participatory networking,” in Proc. Hot-ICE, San Jose, CA, USA,
2012, p. 2.
[56] K. Jeong, J. Kim, and Y. Kim, “QoS-aware network operating system
for software defined networking with generalized OpenFlows,” in Proc. IEEE NOMS, 2012, pp.
1167–1174.
[57] T. Koponen et al., “Architecting for innovation,” ACM SIGCOMM
Comput. Commun. Rev., vol. 41, no. 3, pp. 24–36, Jul. 2011. [58] PlanetLab. [Online].
Available: http://www.planet-lab.org/ [59] Global Environment for Network Innovations (GENI).
[Online]. Avail-
able: http://www.geni.net/
[60] A. Sharafat, S. Das, G. Parulkar, and N. McKeown, “MPLS-TE and
MPLS VPNS with OpenFlow,” ACM SIGCOMM Comput. Commun. Rev., vol. 41, no. 4, pp.
452–453, Aug. 2011. [61] N. Blefari-Melazzi, A. Detti et al., “An OpenFlow-based testbed for
information centric networking,” in Proc. Future Netw. Mobile Summit,
2012, pp. 4–6.
[62] H. Yin et al., SDNi: AMessage Exchange Protocol for Software Defined
Networks (SDNS) across Multiple Domains, Jun. 2012, Internet draft. [Online]. Available:
http://www.cisco.com/en/US/solutions/collateral/
ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360.pdf [63] H. Xie et al., “Software-defined
networking efforts debuted at IETF 84,”
IETF J., Oct. 2012. [Online]. Available: http://www.internetsociety.org/ fr/node/45708 [64] R.
Birke et al., “Partition/aggregate in commodity 10G ethernet
software-defined networking,” in Proc. IEEE 13th Int. Conf. HPSR,
2012, pp. 7–14.
[65] E. Karpilovsky, M. Caesar, J. Rexford, A. Shaikh, and J. van der
Merwe, “Practical network-wide compression of IP routing tables,”
IEEE Trans. Netw. Serv. Manage., vol. 9, no. 4, pp. 446–458, Dec. 2012.
[66] T. Pan, X. Guo, C. Zhang, W. Meng, and B. Liu, “ALFE: A replacement
policy to cache elephant flows in the presence of mice flooding,” in Proc. IEEE ICC, Jun.
2012, pp. 2961–2965. [67] O. Ferkouss et al., “A 100 Gig network processor platform for
OpenFlow,” in Proc. 7th Int. CNSM, 2011, pp. 1–4.
[68] J. C. Mogul and P. Congdon, “Hey, you darned counters!: Get off my
ASIC!” in Proc. 1st Workshop HotSDN, 2012, pp. 25–30.
[69] V. Tanyingyong, M. Hidell, and P. Sjodin, “Improving PC-based
OpenFlow switching performance,” in Proc. ACM/IEEE Symp. ANCS,
2010, pp. 1–2.
[70] V. Tanyingyong, M. Hidell, and P. Sjodin, “Using hardware classification
to improve pc-based OpenFlow switching,” in Proc. IEEE 12th Int. Conf. HPSR, 2011, pp.
215–221.
47
[71] G. Lu, R. Miao, Y. Xiong, and C. Guo, “Using CPU as a traffic co-
processing unit in commodity switches,” in Proc. 1st Workshop HotSDN,
2012, pp. 31–36.
[72] Pantou: OpenFlow 1.0 for OpenWRT. [Online]. Available: http://www.
openflow.org/wk/index.php/Pantou_:_OpenFlow_1.0_for_OpenWRT [73] Y. Mundada, R.
Sherwood, and N. Feamster, “An OpenFlow switch
element for click,” presented at the Symposium Click Modular Router, Ghent, Belgium, 2009.
[74] B. Pfaff et al., “Extending networking into the virtualization
layer,” in Proc. HotNets, New York, NY, USA, 2009. [Online]. Available:
http://conferences.sigcomm.org/hotnets/2009/papers/ hotnets2009-final143.pdf
[75] J. Pettit, J. Gross, B. Pfaff, M. Casado, and S. Crosby, “Virtual switching
in an era of advanced edges,” in Proc. 2nd Workshop DC-CAVES, 2010, pp. 1–7. [76] J.
Lockwood et al., “NetFPGA-an open platform for gigabit-rate
network switching and routing,” in Proc. IEEE Int. Conf. MSE, 2007, pp. 160–161.
[77] M. Anwer, M. Motiwala, M. Tariq, and N. Feamster, “SwitchBlade: A
platform for rapid deployment of network protocols on programmable hardware,” ACM
SIGCOMM Comput. Commun. Rev., vol. 40, no. 4, pp. 183–194, Oct. 2010. [78] G. Lu et al., “Serverswitch:
A programmable and high performance
platform for data center networks,” in Proc. NSDI, 2011, p. 2.
[79] A. Rostami, T. Jungel, A. Koepsel, H. Woesner, and A. Wolisz, “ORAN:
OpenFlow routers for academic networks,” in Proc. IEEE 13th Int. Conf. HPSR, 2012, pp.
216–222.
[80] J. Naous, D. Erickson, G. A. Covington, G. Appenzeller, and
N. McKeown, “Implementing an OpenFlow switch on the NetFPGA platform,” in Proc. 4th
ACM/IEEE Symp. ANCS, 2008, pp. 1–9.
[81] J. Kempf et al., “OpenFlow MPLS and the open source label switched
router,” in Proc. 23rd ITC, 2011, pp. 8–14.
[82] Indigo—Open Source OpenFlow Switches. [Online]. Available: http://
www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/
ns827/white_paper_c11-481360.pdf
[83] A. Bianco, R. Birke, L. Giraudo, and M. Palacin, “Openflow switching:
Data plane performance,” in Proc. IEEE ICC, 2010, pp. 1–5.
[84] C. Rotsos, N. Sarrar, S. Uhlig, R. Sherwood, and A. W. Moore,
“OFLOPS: An open framework for OpenFlow switch evaluation,” in
Proc. 13th Int. Conf. PAM, 2012, pp. 85–95.
[85] T. Ulversoy, “Software defined radio: Challenges and opportunities,”
IEEE Commun. Surveys Tuts., vol. 12, no. 4, pp. 531–550, May 2010. [86] E. Mannie,
Generalized Multi-Protocol Label Switching (GMPLS) Ar-
chitecture, Oct. 2004, RFC 3945. [Online]. Available: http://tools.ietf. org/rfc/rfc6325.txt
[87] M. Bansal, J. Mehlman, S. Katti, and P. Levis, “OpenRadio: A pro-
grammable wireless dataplane,” in Proc. 1st Workshop HotSDN, 2012, pp. 109–114.
[88] R. Murty, J. Padhye, A. Wolman, andM. Welsh, “Dyson: An architecture
for extensible wireless LANs,” in Proc. USENIXATC, 2010, p. 15.
[89] Joint Program Executive Office (JPEO) for the Joint Tactical Radio
System (JTRS), Software Communications Architecture Specification, San Diego, CA, USA
2012. [Online]. Available: http://jpeojtrs.mil/sca/
Documents/SCAv4_0/SCA_4.0_20120228_ScaSpecification.pdf [90] G. Jianxin, Y. Xiaohui, G.
Jun, and L. Quan, “The software communica-
tion architecture specification: Evolution and trends,” in Proc. PACIIA,
2009, vol. 2, pp. 341–344.
[91] Wireless Innovation Forum (Previously the SDRForum). [Online]. Avail-
able: http://www.wirelessinnovation.org/ [92] J. Elbers and A. Autenrieth, “From static to
software-defined optical
networks,” in Proc. 16th Int. Conf. ONDM, 2012, pp. 1–4.
[93] A. Giorgetti, F. Cugini, F. Paolucci, and P. Castoldi, “OpenFlow and PCE
Architectures in Wavelength Switched Optical Networks,” in Proc. 16th Int. Conf. ONDM, 2012,
pp. 1–6.
[94] S. Das, G. Parulkar, and N. McKeown, “Simple unified control for packet
and circuit networks,” in Proc. IEEE/LEOSST Meet., 2009, pp. 147–148.
[95] S. Das, G. Parulkar, and N. McKeown, “Unifying packet and circuit
switched networks,” in Proc. IEEE GLOBECOM Workshops, 2009, pp. 1–6. [96] S. Das et al., “Packet
and circuit network convergence with OpenFlow,”
in Pro. OFC/NFOEC, 2010, pp. 1–3.
[97] S. Das et al., “Application-aware aggregation and traffic engineering
in a converged packet-circuit network,” in Proc. OFC/NFOEC, 2011, pp. 1–3.
[98] L. Liu, T. Tsuritani, I. Morita, H. Guo, and J. Wu, “OpenFlow-based
wavelength path control in transparent optical networks: A proof-ofconcept demonstration,” in
Proc. 37th ECOC, 2011, pp. 1–3.
48 IEEE COMMUNICATION SURVEYS & TUTORIALS, VOL. 17, NO. 1, FIRST QUARTER 2015
[99] L. Liu, T. Tsuritani, I. Morita, H. Guo, and J. Wu, “Experimental valida-
tion and performance evaluation of OpenFlow-based wavelength path control in transparent
optical networks,” Opt. Exp., vol. 19, no. 27, pp. 26 578–26 593, Dec. 2011. [100] L. Liu et al., “First
field trial of an OpenFlow-based unified control
plane for multi-layer multi-granularity optical networks,” presented at the Optical Fiber
Communication Conference, Los Angeles, CA, USA,
2012, Paper PDP5D.2.
[101] L. Liu et al., “First field trial of an OpenFlow-based unified con-
trol plane for multi-layer multi-granularity optical networks,” in Proc. OFC/NFOEC, 2012, pp.
1–3.
[102] L. Liu, T. Tsuritani, and I. Morita, “Experimental demonstration of
OpenFlow/GMPLS interworking control plane for IP/DWDM multilayer optical networks,” in Proc. [129] R. Raghavendra, J. Lobo, and K.-W. Lee, “Dynamic graph query primi-
14th ICTON, 2012, pp. 1–4.
[103] L. Liu, T. Tsuritani, and I. Morita, “From GMPLS to PCE/GMPLS
to OpenFlow: How much benefit can we get from the technical evolution of control plane in
optical networks?” in Proc. 14th ICTON, 2012, pp. 1–4.
[104] F. Farias, J. Salvatti, E. Cerqueira, and A. Abelem, “A proposal manage-
ment of the legacy network environment using OpenFlow control plane,” in Proc. IEEE
NOMS, 2012, pp. 1143–1150.
[105] M. Casado, T. Koponen, S. Shenker, and A. Tootoonchian, “Fabric: A
retrospective on evolving SDN,” in Proc. 1st Workshop HotSDN, 2012, pp. 85–90. [106] B.
Raghavan et al., “Software-defined internet architecture: Decoupling
architecture from infrastructure,” in Proc. 11th ACM Workshop Hot Topics Netw., 2012, pp.
43–48.
[107] V. Gudla et al., “Experimental demonstration of OpenFlow control of
packet and circuit switches,” presented at the Optical Fiber Communication Conference, San
Diego, CA, USA, 2010, Paper OTuG2. [108] D. Simeonidou, R. Nejabati, and S. Azodolmolky,
“Enabling the future
optical Internet with OpenFlow: A paradigm shift in providing intelligent optical network
services,” in Proc. 13th ICTON, 2011, pp. 1–4.
[109] S. Azodolmolky et al., “Integrated OpenFlow-GMPLS control plane: An
overlay model for software defined packet over optical networks,” Opt. Exp., vol. 19, no. 26,
pp. B421–B428, Dec. 2011.
[110] Cisco’s One Platform Kit (onePK). [Online]. Available: http://www.
cisco.com/en/US/prod/iosswrel/onepk.html
[111] T. L. Hinrichs, N. S. Gude, M. Casado, J. C. Mitchell, and S. Shenker,
“Practical declarative network management,” in Proc. 1st ACM WREN,
2009, pp. 1–10.
[112] N. Foster et al., “Frenetic: A high-level language for OpenFlow net-
works,” in Proc. Workshop PRESTO, 2010, pp. 6:1–6:6.
[113] N. Foster et al., “Frenetic: A network programming language,”
SIGPLAN Notices, vol. 46, no. 9, pp. 279–291, Sep. 2011. [114] A. Voellmy and P. Hudak,
“Nettle: A language for configuring routing
networks,” in Proc. IFIP TC 2 Working Conf. DSL, 2009, pp. 211–235.
[115] A. Voellmy et al., “Don’t configure the network, program it!
Domain-specific programming languages for network systems,” Defense Tech. Inf. Center,
Fort Belvoir, VA, USA, DTIC Doc. Tech. Rep.,
2010.
[116] A. Voellmy and P. Hudak, “Nettle: Taking the sting out of programming
network routers,” in Proc. 13th Int. Conf. PADL, 2011, pp. 235–249.
[117] A. Voellmy, H. Kim, and N. Feamster, “Procera: A language for high-
level reactive network control,” in Proc. 1st Workshop HotSDN, 2012, pp. 43–48.
[118] T. Hinrichs, N. Gude, M. Casado, J. Mitchell, and S. Shenker, “Express-
ing and enforcing flow-based network security policies,” Univ. Chicago, Chicago, IL, USA,
Tech. Rep, 2008.
[119] A. D. Ferguson, A. Guha, C. Liang, R. Fonseca, and S. Krishnamurthi,
“Hierarchical policies for software defined networks,” in Proc. 1st Workshop HotSDN, 2012,
pp. 37–42.
[120] C. Monsanto, N. Foster, R. Harrison, and D. Walker, “A compiler and
run-time system for network programming languages,” in Proc. 39th Annu. ACM
SIGPLAN-SIGACT Symp. POPL, 2012, pp. 217–230.
[121] S. Gutz, A. Story, C. Schlesinger, and N. Foster, “Splendid isolation: A
slice abstraction for software-defined networks,” in Proc. 1st Workshop HotSDN, 2012, pp.
79–84.
[122] C. Monsanto, J. Reich, N. Foster, J. Rexford, and D. Walker, “Composing
software-defined networks,” in Proc. 10th USENIX Conf. NSDI, 2013, pp. 1–14.
[123] A. Voellmy, J. Wang, Y. R. Yang, B. Ford, and P. Hudak, “Maple: Sim-
plifying SDN programming using algorithmic policies,” in Proc. ACM SIGCOMM Conf., 2013,
pp. 87–98.
[124] R. Wang, D. Butnariu, and J. Rexford, “OpenFlow-based server load
balancing gone wild,” in Proc. 11th USENIX Conf. Hot-ICE Netw. Serv.,
2011, p. 12.
[125] S. Ghorbani and M. Caesar, “Walk the line: Consistent network updates
with bandwidth guarantees,” in Proc. 1st Workshop HotSDN, 2012, pp. 67–72.
[126] M. Reitblatt, N. Foster, J. Rexford, C. Schlesinger, and D. Walker,
“Abstractions for network update,” in Proc. ACM SIGCOMM Conf. Appl., Technol., Archit.,
Protocols Comput. Commun., 2012, pp. 323–334.
[127] M. Reitblatt, N. Foster, J. Rexford, and D. Walker, “Consistent updates
for software-defined networks: Change you can believe in!” in Proc. 10th ACM Workshop
HotNets-X, 2011, pp. 7:1–7:6.
[128] R. McGeer, “A safe, efficient update protocol for OpenFlow networks,”
in Proc. 1st Workshop HotSDN, 2012, pp. 61–66.
tives for SDN-based cloudnetwork management,” in Proc. 1st Workshop HotSDN, 2012, pp.
97–102.
[130] A. Medina, N. Taft, K. Salamatian, S. Bhattacharyya, and C. Diot,
“Traffic matrix estimation: Existing techniques and new directions,”
ACM SIGCOMM Comput. Commun. Rev., vol. 32, no. 4, pp. 161–174, Oct. 2002.
[131] A. Tootoonchian, M. Ghobadi, and Y. Ganjali, “OpenTM: Traffic matrix
estimator for OpenFlow networks,” in Passive and Active Measurement.
Berlin, Germany: Springer-Verlag, 2010, pp. 201–210. [132] A. Curtis, W. Kim, and P.
Yalagandula, “Mahout: Low-overhead data-
center traffic management using end-host-based elephant detection,” in
Proc. IEEE INFOCOM, 2011, pp. 1629–1637.
[133] L. Jose, M. Yu, and J. Rexford, “Online measurement of large traffic
aggregates on commodity switches,” in Proc. 11th USENIX Conf. HotICE Netw. Serv., 2011,
p. 13.
[134] N. Alon, Y. Matias, and M. Szegedy, “The space complexity of approxi-
mating the frequency moments,” in Proc. 28th Annu. ACM STOC, 1996, pp. 20–29.
[135] G. Cormode and M. Hadjieleftheriou, “Finding frequent items in data
streams,” Proc. VLDB Endow., vol. 1, no. 2, pp. 1530–1541, Aug. 2008. [136] A. Kumar, M.
Sung, J. J. Xu, and J. Wang, “Data streaming algo-
rithms for efficient and accurate estimation of flow size distribution,”
SIGMETRICS Perform. Eval. Rev., vol. 32, no. 1, pp. 177–188, Jun. 2004.
[137] A. Kumar, M. Sung, J. J. Xu, and J. Wang, “Data streaming algo-
rithms for efficient and accurate estimation of flow size distribution,” in
Proc. Joint SIGMETRICS Int. Conf. Meas. Model. Comput. Syst., 2004, pp. 177–188.
[138] C. Estan, G. Varghese, and M. Fisk, “Bitmap algorithms for counting
active flows on high-speed links,” IEEE/ACM Trans. Netw., vol. 14, no. 5, pp. 925–937, Oct.
2006.
[139] M. Yu, L. Jose, and R. Miao, “Software defined traffic measurement with
OpenSketch,” in Proc. 10th USENIX Conf. NSDI, 2013, pp. 29–42.
[140] P. Fonseca, R. Bennesby, E. Mota, and A. Passito, “A replication compo-
nent for resilient OpenFlow-based networking,” in Proc. IEEE NOMS,
2012, pp. 933–939.
[141] D. Levin, A. Wundsam, B. Heller, N. Handigol, and A. Feldmann,
“Logically centralized?: State distribution trade-offs in software defined networks,” in Proc. 1st
Workshop HotSDN, 2012, pp. 1–6.
[142] A. Tootoonchian and Y. Ganjali, “HyperFlow: A distributed control
plane for OpenFlow,” in Proc. INM/WREN, 2010, p. 3.
[143] T. Koponen et al., “Onix: A distributed control platform for large-scale
production networks,” in Proc. 9th USENIX Conf. OSDI, 2010, pp. 1–6.
[144] P. Porras et al., “A security enforcement kernel for OpenFlow networks,”
in Proc. 1st Workshop HotSDN, 2012, pp. 121–126.
[145] E. Al-Shaer and S. Al-Haj, “FlowChecker: Configuration analysis and
verification of federated OpenFlow infrastructures,” in Proc. 3rd ACM Workshop Assurable
Usable Security SafeConfig, 2010, pp. 37–44.
[146] E. Al-Shaer, W. Marrero, A. El-Atawy, and K. ElBadawi, “Network con-
figuration in a box: Towards end-to-end verification of network reachability and security,” in Proc.
17th IEEE ICNP, 2009, pp. 123–132.
[147] P. Perešíni and M. Canini, “Is your OpenFlow application correct?” in
Proc. ACM CoNEXT Student Workshop, 2011, pp. 18:1–18:2.
[148] M. Canini, D. Kostic, J. Rexford, and D. Venzano, “Automating the
testing of OpenFlow applications,” presented at the 1st International Workshop Rigorous
Protocol Engineering, Portland, OR, USA, 2011. [149] M. Canini, D. Venzano, P. Perešíni, D.
Kosti´ c, and J. Rexford, “A nice
way to test OpenFlow applications,” in Proc. 9th USENIX Conf. NSDI,
2012, p. 10.
[150] M. Ku´ zniar, M. Canini, and D. Kosti´ c, “OFTEN testing OpenFlow net-
works,” in Proc. 1st EWSDN, Oct. 2012, pp. 54–60. [151] H. Mai et al., “Debugging the data
plane with anteater,” ACM
SIGCOMM Comput. Commun. Rev., vol. 41, no. 4, pp. 290–301, Aug. 2011.
XIA et al.: A SURVEY ON SOFTWARE-DEFINED NETWORKING
[152] A. Khurshid, W. Zhou, M. Caesar, and P. B. Godfrey, “VeriFlow: Ver-
ifying network-wide invariants in real time,” in Proc. 1st Workshops HotSDN, 2012, pp. 49–54,
New York, NY, USA.
[153] A. Khurshid, W. Zhou, M. Caesar, and P. B. Godfrey, “Veriflow:
Verifying network-wide invariants in real time,” SIGCOMM Comput. Commun. Rev., vol. 42,
no. 4, pp. 467–472, Sep. 2012. [154] A. Khurshid, X. Zou, W. Zhou, M. Caesar, and P. B.
Godfrey, “VeriFlow:
Verifying network-wide invariants in real time,” in Proc. 10th USENIX Conf. NSDI, 2013, pp.
15–28.
[155] B. Heller, R. Sherwood, and N. McKeown, “The controller placement
problem,” in Proc. 1st Workshop HotSDN, 2012, pp. 7–12.
[156] Z. Cai, “Maestro: Achieving scalability and coordination in centralized
network control plane,” Ph.D. dissertation, Rice Univ., Houston, TX, USA, 2011.
[157] Z. Cai, A. L. Cox, and T. E. Ng, “Maestro: A system for scalable
OpenFlow control,” Rice Univ., Houston, TX, USA, Tech. Rep. TR 10-08, Dec. 2010.
[158] A. Tootoonchian, S. Gorbunov, Y. Ganjali, M. Casado, and R. Sherwood,
“On controller performance in software-defined networks,” in Proc. 2nd USENIX Conf.
Hot-ICE Netw. Serv., 2012, p. 10.
[159] A. Voellmy and J. Wang, “Scalable software defined network con-
trollers,” in Proc. ACM SIGCOMM Conf. Appl., Technol., Archit., Protocols Comput.
Commun., 2012, pp. 289–290.
[160] A. Voellmy, B. Ford, P. Hudak, and Y. R. Yang, “Scaling software-
defined network controllers on multicore servers,” Comput. Sci., Yale Univ., New Haven, CT,
USA, Yale CS TR 1468, 2012. [161] Beacon.
[Online]. Available: https://openflow.stanford.edu/display/ Beacon/Home [162]
M. Jarschel et al., “Modeling and performance evaluation of an
OpenFlow architecture,” in Proc. 23rd ITCP, 2011, pp. 1–7.
[163] M. Yu, J. Rexford, M. J. Freedman, and J. Wang, “Scalable flow-
based networking with DIFANE,” in Proc. ACM SIGCOMM, 2010, pp. 351–362. [164] A. R.
Curtis et al., “DevoFlow: Scaling flow management for high-
performance networks,” SIGCOMM Comput. Commun. Rev., vol. 41, no. 4, pp. 254–265,
Aug. 2011.
[165] S. H. Yeganeh and Y. Ganjali, “Kandoo: A framework for efficient
and scalable offloading of control applications,” in Proc. 1st Workshop HotSDN, 2012, pp.
19–24.
[166] Cbench (Controller Benchmarker). [Online]. Available: http://www.
openflow.org/wk/index.php/Oflops
[167] M. Jarschel, F. Lehrieder, Z. Magyari, and R. Pries, “A flexible
OpenFlow-controller benchmark,” in Proc. EWSDN, 2012, pp. 48–53.
[168] R. Alimi, R. Penno, and Y. Yang, ALTO Protocol, Feb. 2013,
Internet Draft. [Online]. Available: http://tools.ietf.org/id/
draft-ietf-alto-protocol-14.txt
[169] V. Gurbani, M. Scharf, T. Lakshman, V. Hilt, and E. Marocco, “Abstract-
ing network state in Software Defined Networks (SDN) for rendezvous services,” in Proc.
IEEE ICC, 2012, pp. 6627–6632.
[170] E. Kissel, G. Fernandes, M. Jaffee, M. Swany, and M. Zhang, “Driving
software defined networks with XSP,” in Proc. Workshop SDN/IEEE Int. Conf. Commun., 2012,
pp. 6616–6621.
[171] E. Keller and J. Rexford, “The “Platform as a service” model for net-
working,” in Proc. INM/WREN, 2010, p. 4.
[172] N. Handigol et al., “Plug-n-Serve: Load-balancing web traffic us-
ing OpenFlow,” in Proc. ACM SIGCOMM Demo, Barcelona, Spain,
2009. [Online]. Available: http://conferences.sigcomm.org/sigcomm/
2009/demos/sigcomm-pd-2009-final26.pdf [173] K.-K. Yap et al., “Blueprint for introducing
innovation into wireless
mobile networks,” in Proc. 2nd ACM SIGCOMMWorkshop VISA, 2010, pp. 25–32. [174] K.-K.
Yap et al., “OpenRoads: Empowering research in mobile net-
works,” SIGCOMMComput. Commun. Rev., vol. 40, no. 1, pp. 125–126, Jan. 2010.
[175] K. Yap, S. Katti, G. Parulkar, and N. McKeown, “Delivering capacity
for the mobile internet by stitching together networks,” in Proc. ACM Workshop Wireless
Students, 2010, pp. 41–44.
[176] L. Suresh, J. Schulz-Zander, R. Merz, A. Feldmann, and T. Vazao,
“Towards programmable enterprise WLANS with Odin,” in Proc. 1st Workshop HotSDN, 2012,
pp. 115–120.
[177] A. Wundsam, D. Levin, S. Seetharaman, and A. Feldmann, “OFRewind:
Enabling record and replay troubleshooting for networks,” in Proc. USENIX Annu. Tech.
Conf., 2011, p. 29.
[178] J. H. Jafarian, E. Al-Shaer, and Q. Duan, “OpenFlow random
host mutation: Transparent moving target defense using software defined networking,” in Proc.
1st Workshop HotSDN, 2012, pp. 127–132.
49
[179] M. Mendonca, S. Seetharaman, and K. Obraczka, “A flexible
in-network IP anonymization service,” in Proc. IEEE ICC, 2012, pp. 6651–6656.
[180] J. Fu, P. Sjödin, and G. Karlsson, “Intra-domain routing convergence
with centralized control,” Comput. Netw., vol. 53, no. 18, pp. 2985–2996, Dec. 2009.
[181] K. K. Lakshminarayanan, I. Stoica, S. Shenker, and J. Rexford, “Routing
as a service,” EECS Dept., Univ. California, Berkeley, CA, USA, Tech. Rep.
UCB/EECS-2006-19, Feb. 2006. [182] P. Pisa et al., “OpenFlow and Xen-based virtual network
migration,” in
Communications: Wireless in Developing Countries and Networks of the Future. Berlin,
Germany: Springer-Verlag, 2010, pp. 170–181. [183] M. Koerner and O. Kao, “Multiple service
load-balancing with Open-
Flow,” in Proc. 13th IEEE Int. Conf. HPSR, 2012, pp. 210–214.
[184] G. Wang, T. E. Ng, and A. Shaikh, “Programming your network at run-
time for big data applications,” in Proc. 1st Workshop HotSDN, 2012, pp. 103–108.
[185] Z. Kerravala, “As the value of enterprise networks escalates, so
does the need for configuration management,” Enterprise Computing & Networking, The
Yankee Group Report, Boston, MA, USA,
2004.
[186] N. Handigol, B. Heller, V. Jeyakumar, D. Maziéres, and N. McKeown,
“Where is the debugger for my software-defined network?” in Proc. 1st Workshop HotSDN, 2012,
pp. 55–60.
[187] S. Sharma, D. Staessens, D. Colle, M. Pickavet, and P. Demeester, “En-
abling fast failure recovery in OpenFlow networks,” in Proc. 8th Int. Workshop DRCN, 2011,
pp. 164–171.
[188] R. Braga, E. Mota, and A. Passito, “Lightweight DDoS flooding attack
detection using NOX/OpenFlow,” in Proc. 35th IEEE Conf. LCN, 2010, pp. 408–415.
[189] G. Gibb, H. Zeng, and N. McKeown, “Outsourcing network functional-
ity,” in Proc. 1st Workshop HotSDN, 2012, pp. 73–78.
[190] G. Huang, C. Chuah, S. Raza, and S. Seetharaman, “Dynamic
measurement-aware routing in practice,” IEEE Netw., vol. 25, no. 3, pp. 29–34, May/Jun.
2011.
[191] J. Naous, R. Stutsman, D. Mazieres, N. McKeown, and N. Zeldovich,
“Delegating network security with more information,” in Proc. 1st ACM WREN, 2009, pp.
19–26.
[192] C. Rigney, A. Rubens, W. Simpson, and S. Willens, Remote Authenti-
cation Dial in User Service (RADIUS), Jun. 2000. [Online]. Available:
http://tools.ietf.org/rfc/rfc2865.txt
[193] Y. Yamasaki, Y. Miyamoto, J. Yamato, H. Goto, and H. Sone, “Flexible
access management system for campus VLAN based on OpenFlow,” in
Proc. IEEE/IPSJ 11th Int. SAINT, 2011, pp. 347–351.
[194] S. Kinoshita, T. Watanabe, J. Yamato, H. Goto, and H. Sone, “Imple-
mentation and evaluation of an OpenFlow-based access control system for wireless LAN
roaming,” in Proc. 36th Annu. COMPSACW, 2012, pp. 82–87.
[195] A. Ramachandran, Y. Mundada, M. Tariq, and N. Feamster, “Secur-
ing enterprise networks using traffic tainting,” Georgia Inst. Technol., Atlanta, GA, USA, Tech.
Rep. GTCS-09-15, 2009. [196] N. Feamster et al., “Decoupling policy from configuration in
campus
and enterprise networks,” in Proc. 17th IEEEWorkshop LANMAN, 2010, pp. 1–6.
[197] A. Nayak, A. Reimers, N. Feamster, and R. Clark, “Resonance: Dynamic
access control for enterprise networks,” in Proc. 1st ACMWorkshop Res. Enterprise Netw., 2009,
pp. 11–18.
[198] N. Chowdhury and R. Boutaba, “Network virtualization: State of
the art and research challenges,” IEEE Commun. Mag., vol. 47, no. 7, pp. 20–26, Jul. 2009.
[199] D. Turull, M. Hidell, and P. Sjodin, “Using libNetVirt to control
the virtual network,” in Proc. IEEE Int. Conf. CLOUDNET, 2012, pp. 148–152.
[200] D. Turull, M. Hidell, and P. Sjodin, “libNetVirt: The network virtualiza-
tion library,” in Proc. IEEE ICC, 2012, pp. 5543–5547.
[201] R. Sherwood et al., “Flowvisor: A network virtualization layer,”
OpenFlow Switch Consortium, OPENFLOW-TR-2009-1, 2009. [Online]. Available:
http://archive.openflow.org/downloads/technicalreports/ openflow-tr-2009-1-flowvisor.pdf [202]
R. Sherwood et al., “Can the production network be the testbed?” in
Proc. 9th USENIX Conf. OSDI, 2010, pp. 1–6.
[203] R. Sherwood et al., “Carving research slices out of your production
networks with OpenFlow,” ACM SIGCOMM Comput. Commun. Rev.,
vol. 40, no. 1, pp. 129–130, Jan. 2010. [204] Y. Yiakoumis, K.-K. Yap, S. Katti, G. Parulkar,
and N. McKeown, “Slic-
ing home networks,” in Proc. 2nd ACM SIGCOMM Workshop HomeNets, 2011, pp. 1–6.
50 IEEE COMMUNICATION SURVEYS & TUTORIALS, VOL. 17, NO. 1, FIRST QUARTER 2015
[205] A. Bianzino, C. Chaudet, D. Rossi, and J. Rougier, “A survey of green
networking research,” IEEE Commun. Surveys Tuts., vol. 14, no. 1, pp. 3–20, Dec. 2012.
[206] D. Staessens, S. Sharma, D. Colle, M. Pickavet, and P. Demeester, “Soft-
ware defined networking: Meeting carrier grade requirements,” in Proc. 18th IEEE Workshop
LANMAN, 2011, pp. 1–6.
[207] T. Benson, A. Akella, A. Shaikh, and S. Sahu, “CloudNaaS: A cloud
networking platform for enterprise applications,” in Proc. 2nd ACM SOCC, 2011, pp. 8:1–8:13.
[208] A. Tavakoli, M. Casado, T. Koponen, and S. Shenker, “Applying
NOX to the datacenter,” in Proc. HotNets, New York, NY, USA,
2009. [Online]. Available: http://conferences.sigcomm.org/hotnets/
2009/papers/hotnets2009-final103.pdf
[209] M. Moshref, M. Yu, A. Sharma, and R. Govindan, “Scalable rule man-
agement for data centers,” in Proc. 10th USENIX Conf. NSDI, 2013, pp. 157–170.
[210] Q. Zhang, L. Cheng, and R. Boutaba, “Cloud computing: State-of-the-art
and research challenges,” J. Internet Serv. Appl., vol. 1, no. 1, pp. 7–18, May 2010.
[211] Q. Li, J. Huai, J. Li, T. Wo, and M. Wen, “HyperMIP: Hypervisor
controlled mobile IP for virtual machine live migration across networks,” in Proc. 11th IEEE
HASE Symp., 2008, pp. 80–88.
[212] P. Raad et al., “Achieving sub-second downtimes in internet-wide virtual
machine live migrations in LISP networks,” in Proc. IFIP/IEEE Int. Symp. IM, 2013, pp.
286–293.
[213] M. Coudron, S. Secci, G. Maier, G. Pujolle, and A. Pattavina, “Boosting
cloud communications through a crosslayer multipath protocol architecture,” in Proc. IEEE
SDN4FNS, Nov. 2013, pp. 1–8. [214] OpenDaylight. [Online]. Available:
http://www.opendaylight.org/ [215] F. Hao, T. Lakshman, S. Mukherjee, and H. Song, “Enhancing
dynamic
cloud-based services using network virtualization,” in Proc. 1st ACM Workshop Virtualized
Infrastruct. Syst. Archit., 2009, pp. 37–44.
[216] B. Boughzala, R. Ben Ali, M. Lemay, Y. Lemieux, and O. Cherkaoui,
“OpenFlow supporting inter-domain virtual machine migration,” in
Proc. 8th Int. Conf. WOCN, 2011, pp. 1–7.
[217] J. Matias, E. Jacob, D. Sanchez, and Y. Demchenko, “An OpenFlow
based network virtualization framework for the cloud,” in Proc. 3rd Int. Conf. CloudComp
Technol. Sci., 2011, pp. 672–678.
[218] V. Mann, A. Vishnoi, K. Kannan, and S. Kalyanaraman, “CrossRoads:
Seamless VM mobility across data centers through software defined networking,” in Proc.
IEEE NOMS, 2012, pp. 88–96.
[219] Y. Pu, Y. Deng, and A. Nakao, “Cloud rack: Enhanced virtual topo-
logy migration approach with open vswitch,” in Proc. ICOIN, 2011, pp. 160–164.
[220] E. Keller, S. Ghorbani, M. Caesar, and J. Rexford, “Live migration of an
entire network (and its hosts),” in Proc. 11th ACM Workshop HotNets-
XI, 2012, pp. 109–114.
[221] H. Qian, X. Huang, and C. Chen, “Swan: End-to-end orchestration for
cloud network and wan,” in Proc. IEEE 2nd Int. Conf. CloudNet, Nov.
2013, pp. 236–242.
[222] N. McKeown et al., “OpenFlow: Enabling innovation in campus net-
works,” SIGCOMM Comput. Commun. Rev., vol. 38, no. 2, pp. 69–74, Mar. 2008.
[223] OpenFlow Switch Consortium. [Online]. Available: http://www.
openflow.org/ [224] D. Mattos et al., “OMNI: OpenFlow management infrastructure,” in
Proc. Int. Conf. NOF, 2011, pp. 52–56.
[225] Trema. [Online]. Available: http://trema.github.com/trema/ [226] Ryu. [Online]. Available:
http://osrg.github.com/ryu/ [227] Floodlight. [Online]. Available: http://www.projectfloodlight.org/ [228]
N. Gude et al., “NOX: Towards an operating system for networks,”
SIGCOMMComput.Commun. Rev., vol. 38, no. 3, pp. 105–110, Jul. 2008. [229] NOX.
[Online]. Available: http://www.noxrepo.org/ [230] K.-K. Yap et al., “The Stanford OpenRoads
deployment,” in Proc. 4th
ACM Int. WINTECH, 2009, pp. 59–66.
[231] S. Jain et al., “4: Experience with a globally-deployed software defined
WAN,” in Proc. ACM SIGCOMM Conf., 2013, pp. 3–14.
[232] N. Feamster and J. Rexford, “Getting students’ hands dirty with clean-
slate networking,” in Proc. SIGCOMM Educ. Workshop, Toronto, ON, Canada, 2011. [Online].
Available: http://edusigcomm.info.ucl.ac.be/
pmwiki/uploads/Workshop2011/20110430002/clean-slate.pdf [233] L. Peterson, T. Anderson, D.
Culler, and T. Roscoe, “A blueprint for
introducing disruptive technology into the Internet,” ACM SIGCOMM Comput. Commun.
Rev., vol. 33, no. 1, pp. 59–64, Jan. 2003. [234] Federated E-Infrastructure Dedicated to
European Researchers
Innovating in Computing Network Architectures (FEDERICA). [Online]. Available:
http://www.fp7-federica.eu/
[235] JGN-X (JGN-eXtreme). [Online]. Available: http://www.jgn.nict.go.jp/
english/index.html
[236] Future Internet Testbeds Experimentation Between Brazil and Europe
(FIBRE). [Online]. Available: http://www.fibre-ict.eu/ [237] R. Riggio, T. Rasheed, and F.
Granelli, “Empower: A testbed for network
function virtualization research and experimentation,” in Proc. IEEE SDN4FNS, Nov. 2013,
pp. 1–5.
[238] U. Holzle, OpenFlow @ Google, Apr. 2012. [Online]. Available: http://
www.opennetsummit.org/archives/apr12/hoelzle-tue-openflow.pdf [239] B. Lantz, B. Heller,
and N. McKeown, “A network in a laptop: Rapid pro-
totyping for software-defined networks,” in Proc. 9th ACM SIGCOMM Workshop HotNets-IX, 2010,
pp. 19:1–19:6.
[240] L. Dong, F. Jia, and W. Wang, “Definition and implementation of logical
function blocks compliant to ForCES specification,” in Proc. 15th ICON,
2007, pp. 531–536.
[241] Z. Wang, T. Tsou, J. Huang, X. Shi, and X. Yin, Analysis of
Comparisons Between OpenFlow and ForCES, Mar. 2012, Internet Draft. [Online]. Available:
http://tools.ietf.org/id/draft-wang-forcescompare-openflow-forces-01.txt
[242] E. Haleplidis, S. Denazis, O. Koufopavlou, J. Salim, and J. Halpern,
“Software-defined networking: Experimenting with the control to forwarding plane interface,”
in Proc. EWSDN, 2012, pp. 91–96.
[243] P. Lin, J. Bi, and H. Hu, “ASIC: An architecture for scalable intra-domain
control in OpenFlow,” in Proc. 7th Int. Conf. Future Internet Technol.,
2012, pp. 21–26.
[244] M. R. Nascimento, C. E. Rothenberg, M. R. Salvador, and
M. F. Magalhães, “QuagFlow: Partnering Quagga with OpenFlow,”
SIGCOMM Comput. Commun. Rev., vol. 40, no. 4, pp. 441–442, Aug. 2010. [245] M. R.
Nascimento et al., “Virtual routers as a service: The RouteFlow
approach leveraging software-defined networks,” in Proc. 6th Int. CFI Technol., 2011, pp.
34–37.
[246] Y. Nakagawa, K. Hyoudou, and T. Shimizu, “A management method of
IP multicast in overlay networks using openflow,” in Proc. 1st Workshop HotSDN, 2012, pp.
91–96.
[247] K.-K. Yap, T.-Y. Huang, B. Dodson, M. S. Lam, and N. McKeown, “To-
wards software-friendly networks,” in Proc. 1st ACM APSys Workshop,
2010, pp. 49–54.
[248] T.-Y. Huang et al., “PhoneNet: A phone-to-phone network for
group communication within an administrative domain,” in Proc. 2nd ACM SIGCOMM
Workshop Netw., Syst., Appl. MobiHeld, 2010, pp. 27–32.
[249] B. Koldehofe, F. Dürr, M. A. Tariq, and K. Rothermel, “The power
of software-defined networking: Line-rate content-based routing using OpenFlow,” in Proc.
7th Workshop MW4NG Internet Comput., 2012, pp. 3:1–3:6.
[250] D. Kotani, K. Suzuki, and H. Shimonishi, “A design and implementation
of OpenFlow controller handling IP multicast with fast tree switching,” in Proc. IEE/IPSJ Int.
SAINT, 2012, pp. 60–67.
[251] R. Ravindran, X. Liu, A. Chakraborti, X. Zhang, and G. Wang, “Towards
software defined icn based edge-cloud services,” in Proc. IEEE 2nd Int. Conf. CloudNet, Nov.
2013, pp. 227–235. [252] T. Li, N. Van Vorst, R. Rong, and J. Liu, “Simulation studies of
OpenFlow-based in-network caching strategies,” in Proc. 15th CNS Symp., 2012, pp.
12:1–12:7.
[253] G. Stabler, A. Rosen, S. Goasguen, and K.-C. Wang, “Elastic IP and
security groups implementation using OpenFlow,” in Proc. 6th Int. Workshop VTDC, 2012, pp.
53–60.
[254] J. Rubio-Loyola et al., “Scalable service deployment on software-
defined networks,” IEEE Commun. Mag., vol. 49, no. 12, pp. 84–93, Dec. 2011.
[255] T. Nadeau and P. Pan, Framework for Software Defined Networks,
Oct. 2011, Internet Draft. [Online]. Available: http://tools.ietf.org/id/
draft-nadeau-sdn-framework-01.txt
[256] ETSI Industry Specification Group for Network Functions Virtualization
(ISG NFV), Network Functions Virtualisation, An Introduction, Benefits, Enablers, Challenges
& Call for Action, Oct. 2012, White Paper. [Online]. Available:
http://www.cisco.com/en/US/solutions/collateral/
ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360.pdf [257] M. Kuzniar, P. Peresini,
M. Canini, D. Venzano, and D. Kostic, “A SOFT
way for openflow switch interoperability testing,” in Proc. 8th Int. Conf. Emerging Netw. Exp.
Technol., 2012, pp. 265–276.
[258] M. Kind, F. Westphal, A. Gladisch, and S. Topp, “SplitArchitecture:
Applying the software defined networking concept to carrier networks,” in Proc. WTC, 2012,
pp. 1–6.
[259] P. Dely, A. Kassler, and N. Bayer, “Openflow for wireless mesh net-
works,” in Proc. 20th ICCCN, 2011, pp. 1–6.
XIA et al.: A SURVEY ON SOFTWARE-DEFINED NETWORKING 51

[260] A. Mahmud and R. Rahmani, “Exploitation of OpenFlow in wireless
sensor networks,” in Proc. ICCSNT, 2011, vol. 1, pp. 594–600.
[261] A. Mahmud, R. Rahmani, and T. Kanter, “Deployment of flow-sensors
in internet of things’ virtualization via OpenFlow,” in Proc. 3rd FTRA Int. Conf. MUSIC, 2012,
pp. 195–200.
Wenfeng Xia received the B.S. degree in computer science from
the University of Science and Technology of China, Hefei, China, in
2011. He is currently working toward the M.S. degree at the School
of Computer Science and Technology, USTC. He is currently
working as a Project Officer with the School of Computer
Engineering, Nanyang Technological University, Singapore. His
research interests include computer networks and software
engineering.
Dusit Niyato received the B.Eng. degree in computer engineering
from King Mongkut’s Institute of Technology Ladkrabang, Bangkok,
Thailand, in 1999 and the Ph.D. degree in electrical and computer
engineering from the University of Manitoba, Winnipeg, MB,
Canada, in 2008. He is currently an Associate Professor with the
School of Computer Engineering, Nanyang Technological
University, Singapore. His research interests include radio resource
management in cognitive radio networks and broadband wireless
access networks.

Haiyong Xie received the B.S. degree from the University of

Science and Technology of China, Hefei, China, in 1997 and the
Yonggang Wen ( S’99–M’08–SM’14) received the Ph.D. degree in
M.S. and Ph.D. degrees in computer science from Yale University,
electrical engineering and computer science (minor in western
New Haven, CT, USA in 2005 and 2008, respectively. He is
literature) from Massachusetts Institute of Technology (MIT),
currently the Executive Director of the Cyberspace and Data
Cambridge, MA, USA. He has worked in Cisco to lead product
Science Laboratory, Chinese Academy of Electronics and
development in content delivery networks, which had a revenue
Information Technology, Beijing, China, and a Professor with the
impact of $3 billion globally. He has published over 100 papers in
School of Computer Science and Technology, University of Science
top journals and prestigious conferences. He is currently an
and Technology of China, Hefei, China. He was the Prin-
Assistant Professor with the School Of Computer Engineering,
Nanyang Technological University,

cipal Researcher for Huawei U.S. Research Labs and the P4P Working Group (P4PWG) and
Distributed Computing Industry Association. He proposed P4P (proactive provider participation in
Singapore. His research interests include cloud computing, green data centers, big data analytics,
P2P) to coordinate network providers and peer-to-peer applications in a seminal paper published in
multimedia networks, and mobile computing. His latest work in multiscreen cloud social televisions
ACM SIGCOMM
has been featured by global media (more than 1600 news articles from over 29 countries) and
2008, and led and conducted original research and large-scale tests on P4P. Encouraged by and
recognized with ASEAN ICT Award 2013 (Gold Medal) and IEEE Globecom 2013 Best Paper Award.
based upon his research and results on P4P, the P4PWG was formed to promote academic studies
He serves on the editorial boards of IEEE T RANSACTIONS ON M ULTIMEDIA, IEEE A CCESS J
and industrial adoptions of P4P, which was later adopted by IETF to form a new Application Layer
OURNAL, and Elsevier Ad Hoc Networks.
Traffic Optimization (ALTO) Working Group. His research interest includes contentcentric networking,
software-defined networking, future Internet architecture, and network traffic engineering.

Chuan Heng Foh ( S’00–M’03–SM’09) received the M.Sc. degree

from Monash University, Clayton, Vic., Australia, in 1999 and the
Ph.D. degree from the University of Melbourne, Parkville, Vic., in
2002. After his Ph.D. studies, he spent six months as a Lecturer
with Monash University. From 2002 to

2012, he was an Assistant Professor with Nanyang Technological

University, Singapore. He is currently a Senior Lecturer with the
University of Surrey, Surrey, U.K. He is the author or coauthor of
over 100 refereed papers in international journals and

conferences. His research interests include protocol design and performance analysis of various
computer networks such as wireless local area and mesh networks, and mobile ad hoc and sensor
networks, fifth-generation networks, and data center networks. He actively participates in IEEE
conference and workshop organization, including the International Workshop on Cloud Computing
Systems, Networks, and Applications (CCSNA), where he is a steering member. He is currently an
Associate Editor for IEEE A CCESS, IEEE W IRELESS C OMMUNICATIONS, and International
Journal of Communications Systems. He is also the Chair of the Special Interest Group on Green Data
Center and Cloud Computing under the IEEE Technical Committee on Green Communications and
Computing.