Documente Academic
Documente Profesional
Documente Cultură
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 grandes datos de un conjunto diverso de fuentes de datos, están exigiendo una
está en condiciones de proporcionar más e fi ciente con fi guración, un mejor rendimiento y una mayor mayor velocidad de conexión de red que nunca. Por ejemplo, la televisión social
flexibilidad para adaptarse a los diseños de red innovadoras. Este trabajo se analizan últimos avances en esta [5] - [7] y ultra alta de fi nición (UHD) de televisión traer “norte-sur” tráfico
área de investigación activa de SDN. Primero se presenta una aceptación general de fi nición de SDN con los
cliente-servidor fi co tsunami a los centros de datos, y grande de análisis de
dos rasgos característicos antes mencionadas y los posibles beneficios de la SDN. a continuación, nos
datos de aplicaciones, como MapReduce [8], provocan grandes “ este-oeste”de
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 servidor a servidor de trá fi co en los centros de datos para dividir los datos de
investigación relacionadas. Seguimos de que con una visión general de la aplicación de facto SDN (es decir, entrada y combinar los resultados de salida. En segundo lugar, una gran
OpenFlow). Por último, concluimos este trabajo encuesta con algunos retos de investigación abiertas penetración de los dispositivos móviles y las redes sociales es exigente
sugeridas. a continuación, nos detenemos en su arquitectura de tres capas, incluyendo una capa de
comunicaciones ubicuas a fi ll cumplir las necesidades sociales de la población
infraestructura, una capa de control, y una capa de aplicación, y justificar cada capa con los esfuerzos de
en general.
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 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).
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 que analiza los enfoques para construir dispositivos y los retos de la utilización de
al 80 por ciento de las interrupciones de dispositivos de red [13]. Esta creciente complejidad diferentes medios de transmisión de conmutación con capacidad de SDN. La
exige además nuevos enfoques para las futuras redes de ordenadores, en los que la sección IV trata la capa de control, que introduce las operaciones de un controlador
complejidad puede ser controlada. 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
Debido a su tamaño, la heterogeneidad y complejidad de la actual y, posiblemente, las futuras redes en plataformas SDN, incluyendo encaminamiento adaptativo, la movilidad sin
de ordenadores, los enfoques tradicionales para la con fi guración, optimización y resolución de límites, gestión de red, seguridad de red, virtualización de redes, redes verde, y un
problemas se convertirían en ine fi ciente, y en algunos casos, insu fi ciente. Por ejemplo, del sistema caso especial el uso SDN con el cloud computing. Sección VI cubre OpenFlow, que
autónomo (AS) basados enfoques a menudo se centran en la gestión de un subconjunto de las redes y se considera como la aplicación de facto de la SDN. Una breve conclusión con un
optimizar el rendimiento o la calidad de la experiencia del usuario para algunos servicios de red, como en poco de discusión sobre las implementaciones actuales y desarrollos adicionales de
el caso de aplicaciones en la red ajena P2P [14] y la tasa de transmisión de vídeo recogiendo [ 15]. SDN se presenta en la Sección VII.
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
II. SDN: D DEFINICIÓN, segundo ENEFICIOS, Y do ESAFÍOS
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, Últimamente SDN se ha convertido en uno de los temas más populares en el ámbito de
optimización, o métodos de recuperación, implementación y pruebas pueden tardar años, desde el las TIC. Sin embargo, al ser un nuevo concepto, un consenso todavía no se ha alcanzado en
diseño a la normalización ante un posible despliegue. Un protocolo puede tardar años en ser su exacta definición. De hecho, una gran cantidad de diferentes fi niciones [23] - [28] han
estandarizado como un RFC [17], [18]. Estas observaciones han exigido un enfoque novedoso para las surgido en el último par de años, cada uno de los cuales tiene sus propios méritos. En esta
futuras redes para apoyar la implementación, prueba y despliegue de ideas innovadoras. implementación sección, presentamos una primera generalmente aceptada definición de SDN, y luego
y las pruebas pueden tardar años, desde el diseño a la normalización ante un posible despliegue. Un delinear un conjunto de ts y desafíos de la SDN bene fi clave, y finalmente introducimos un
protocolo puede tardar años en ser estandarizado como un RFC [17], [18]. Estas observaciones han modelo de referencia SDN como el ancla de este documento encuesta.
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 A. Definición de SDN
apoyar la implementación, prueba y despliegue de ideas innovadoras.
La Fundación Redes abierto (ONF) [29] es un consorcio sin ánimo de lucro fi
De hecho, la creación de redes comunidad de investigación y la industria hace
cio dedica al desarrollo, la estandarización y comercialización de SDN. ONF ha
mucho han notado los problemas antes mencionados. Anteriormente algunas ideas
proporcionado la definición más explícita y bien recibido del SDN de la siguiente
nuevas se han introducido para un mejor diseño de las futuras redes [19], incluyendo
manera:
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 Software-De definido Networking (SDN) es una arquitectura de red emergente
se promociona como una solución más prometedora. La idea clave de la SDN es donde el control de la red se desacopla de reenvío y es directamente programable
disociar el plano de control desde el plano de datos y permitir la gestión fl exible fi [23]. Por esta definición, SDN se define por dos características, a saber, el
ciente y e y operación de la red a través de programas de software. Específicamente, desacoplamiento de planos de control y de datos, y capacidad de programación en
los dispositivos (por ejemplo, conmutadores y routers) en el plano de datos realizan el el plano de control. Sin embargo, ninguna de estas dos firmas de SDN es
reenvío de paquetes, basado en reglas instaladas por los controladores. Controladores totalmente nueva en la arquitectura de la red, como se detalla a continuación.
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 En primer lugar, se han hecho varios esfuerzos anteriores para promover la capacidad
ejemplo, seguridad de red, virtualización de red y redes verde) pueden implementarse de programación de la red. Un ejemplo es el concepto de red activa que intenta controlar
rápidamente en forma de software y desplegados en redes con tráfico real, c. Por otra una red en un tiempo real de manera usando el software. SwitchWare [30], [31] es una
parte, SDN permite la centralización lógica de control de realimentación con mejores solución de red activo, permitiendo que los paquetes fl debido a través de una red para
decisiones basadas en una vista de la red global y la información de capa cruzada. 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
En este artículo, analizamos la literatura SDN y tienen por objeto presentar la encaminamiento existente.
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 En segundo lugar, el espíritu de desacoplamiento entre los planos de control y de
organiza como sigue. Primero se presenta la definición de SDN y sus principales datos se ha proliferado en la última década. César et al.
beneficios y desafíos en la Sección II. Las tres secciones siguientes describen la primera presenta una plataforma de control de enrutamiento (RCP) en 2004 [36], en el que
arquitectura SDN con tres capas en detalle. Específicamente, la Sección III se Border Gateway Protocol (BGP) de enrutamiento entre dominios se sustituye por control de
centra en la capa de infraestructura, 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 29
años, IETF liberado marco de Separación Forwarding y Control Element (fuerzas), 1) Mejora de Con fi guración: En la gestión de la red, con fi guración es una de las
que separa los elementos de control y reenvío de paquetes en una red de fuerzas funciones más importantes. Específicamente, cuando se añade un nuevo equipo en una
[37] - [40]. En 2005, Greenberg et al. propuesto un enfoque 4D [41] - [43], la red existente, se requiere con fi guraciones adecuadas para lograr un funcionamiento
introducción de un diseño pizarra limpia de toda la arquitectura de red con cuatro coherente de la red en su conjunto. Sin embargo, debido a la heterogeneidad entre los
planos. Estos planos son “decisión”, “difusión”, “descubrimiento”, y “datos”, fabricantes de dispositivos de red y las interfaces con fi guración, red actual con fi
respectivamente, que se organiza de arriba a abajo. En 2006, el Elemento de guración típicamente implica un cierto nivel de procesamiento manual. Este
Cálculo (PCE), la arquitectura Path se presentó para calcular etiqueta Switched procedimiento con fi guración manual es tedioso y propenso a errores. Al mismo
Paths por separado de inMPLS reenvío de paquetes reales y las redes GMPLS tiempo, también se requiere signi fi esfuerzo no puede solucionar una red con errores
[44]. En 2007, Casado et al. presentó etano, donde conmutadores Ethernet con fi guración. En general se acepta que, con el diseño actual de la red, automática y
basado-ow sencilla fl se complementan con un controlador centralizado para dinámica reconfiguración de una red inalámbrica sigue siendo un gran desafío. SDN le
gestionar la admisión y el encaminamiento de los flujos [45] - [48]. En este último ayudará a remediar una situación tal en la gestión de redes. En SDN, unificación del
desarrollo, el principio de la separación de control de datos avión ha sido declarado plano de control sobre todos los tipos de dispositivos de red [50], incluyendo
explícitamente. dispositivos de redes comerciales también han adoptado la idea de conmutadores, enrutadores, traductores de direcciones de red (NAT), rewalls fi, y los
la separación de planos datacontrol. Por ejemplo, en los routers de la serie Cisco equilibradores de carga, hace que sea posible para con los dispositivos de red fi gura
ASR 1000 y conmutadores de la serie Nexus 7000, el plano de control se desde un único punto, de forma automática a través de control de software. Como tal,
desacopla del plano de datos y modular, lo que permite la coexistencia de una una red completa puede ser mediante programación con fi gurado y dinámicamente
instancia de plano de control activo y un uno espera para alta tolerancia a fallos y optimizado basado en estado de la red.
actualización de software transparente.
TABLA I
C OMPARISONS E ntre SDN Y C ONVENTIONAL N ETWORKING
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 La capa de control cierra la capa de aplicación y la capa de infraestructura,
los consumidores de dispositivos de red, aún no ha aparecido. 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
SDN ofrece una plataforma para las técnicas innovadoras de red, sin embargo, el cambio dispositivos de conmutación. Las funciones pueden incluir la presentación de
de las redes tradicionales a SDN puede ser perjudicial como dolorosa. Las preocupaciones informes de estado de red y la importación de reglas de reenvío de paquetes.
comunes incluyen la interoperabilidad SDN con los dispositivos de red antiguas, el Para interactuar hacia arriba con la capa de aplicación (es decir, la interfaz
rendimiento y las preocupaciones de privacidad de control centralizado, y la falta de expertos norte-unido), que proporciona puntos de acceso de servicio en diversas
para el apoyo técnico. implementaciones existentes de SDN a menudo se limitan a pequeñas formas, por ejemplo, una interfaz de programación de aplicaciones (API). SDN
banco de pruebas de prototipos de investigación. Prototipos para fines de investigación siguen aplicaciones pueden acceder a información sobre el estado de la red
siendo prematuro ofrecer con fi anza para el despliegue en el mundo real. 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.
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
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.
Este nuevo principio arquitectónico presta ventajas competitivas SDN. A diferencia de los
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
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
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
ef fi ciente memoria. Específicamente, para hacer frente a registros de encaminamiento masivas, “Ratones” flujos contribuir primaria a los eventos frecuentes que ser manejados por los
routers convencionales utilizan técnicas tales como la ruta de agregación o resumen y política de dispositivos de conmutación, pero tienen poca influencia en el rendimiento global de la
reemplazo de caché apropiadas [65], [66]. la ruta de agregación o la sumarización pueden red. Tomando esta observación, Lu et al. sugerir de fl oading “elefante” fluye a un ASIC,
reducir el uso de la memoria mediante la agregación de varios registros de encaminamiento con dejando “ratones” fluye a ser manipulados por una CPU con relativamente más lenta la
un común de enrutamiento pre fi x a un único registro de encaminamiento nueva con el fi pre velocidad de procesamiento [71].
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 3) clasi fi y evaluación de dispositivos de conmutación de: Actualmente, los dispositivos
fi ciente. Estas técnicas se pueden adoptar para mejorar la SDN diseño del dispositivo de de conmutación SDN pueden clasificarse a tres categorías principales, según sus hardware
conmutación. especí fi caciones, como se muestra en la Tabla II, incluyendo:
Otro principio importante en la mejora de conmutación SDN diseño del dispositivo es • Implementación en hardware de PC en general: SDN interruptores pueden ser
juiciosa combinación de diferentes tecnologías de almacenamiento para lograr la deseada implementados como software que se ejecuta en un sistema operativo anfitrión (OS),
tamaño de memoria, velocidad de procesamiento, y la flexibilidad con el precio y la por lo general Linux. El sistema operativo anfitrión puede ejecutarse en hardware x86 /
complejidad razonable. hardware de almacenamiento diferente exhibe características x64 PC estándar u otro hardware compatible. Ejemplos de conmutadores de software
diferentes [67], [68]. Por ejemplo, la memoria estática de acceso aleatorio (SRAM) se puede incluyen Pantou [72] y OpenFlowClick [73]. Pantou se basa en OpenWRT, que es una
escalar fácilmente y es más flexible; Contenido ternaria de memoria direccionable (TCAM) distribución de Linux para dispositivos empotrados, especialmente los routers.
ofrece una velocidad más rápida para buscar paquetes clasi fi cación. SRAM y TCAM se OpenFlowClick se basa en Haga clic en [32], que se implementa en hardware de PC
pueden utilizar conjuntamente para equilibrar el compromiso entre el rendimiento de de uso general como una extensión del núcleo de Linux. interruptores de software
cationes de paquetes clasi fi y flexibilidad. 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
2) plano de datos: La función principal del plano de datos de un dispositivo de interruptores SDN es que pueden proporcionar conmutación virtual para máquinas
conmutación de SDN es el reenvío de paquetes. Específicamente, después de recibir de un virtuales en el paradigma popular de la virtualización de servidores y cloud computing.
paquete, fi el dispositivo de conmutación primera identifica la regla de reenvío que coincide Software implementado interruptores SDN como Open vSwitch [74], [75] pueden
con el paquete y a continuación, reenvía el paquete al siguiente salto en consecuencia. En proporcionar visibilidad y control de la red de una manera directa. Traf fi c entre las
comparación con el reenvío de paquetes en redes tradicionales basados en direcciones IP o máquinas virtuales alojados por el mismo servidor físico se mantiene en el servidor,
MAC, SDN reenvío de paquetes también se puede basar en otros parámetros, por ejemplo, mientras que en la conmutación de horquilla, todo tráfico c se redirige al conmutador
puerto TCP o UDP, la etiqueta de red de área local virtual (VLAN), y puertos de conmutación físico conectado con el servidor, entonces salta.
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. • 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
En primer lugar, en dispositivos de conmutación basados en PC, utilizando el software también está prestando más atención a abrir plataformas de hardware de red.
para el procesamiento de paquetes puede resultar en un rendimiento ineficientes. Como Ejemplos de conmutación SDN basado plataforma de hardware de red abierta
mejora, Tanyingyong et al. sugerir el uso de hardware clasi fi cación para aumentar el implementaciones de dispositivo incluye NetFPGA [76] implementaciones
procesamiento de rendimiento [69], [70]. En este diseño, los paquetes entrantes se dirigen a basadas tales como SwitchBlade [77] y ServerSwitch [78], y Advanced
un controlador a bordo de interfaz de red (NIC) para clasi fi cación de hardware basado en Telecommunications Computing Architecture (ATCA) implementaciones basadas
firmas de fluencia. Como resultado, una CPU está exento del proceso de búsqueda. 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
En segundo lugar, la distinta naturaleza para el “elefante” y “ratones” flujos puede ser proveedores y proporcionan un mayor rendimiento que el de los software
explotado. Al contrario de “elefante” flujos “ratones” flujos son numerosos, pero cada uno de implementado.
ellos tiene unos paquetes. página web de la recuperación de los flujos son ejemplos de
“ratones” flujos. De hecho,
XIA et al .: Una encuesta sobre Software-Defined Networking 33
• Implementación de encendido del proveedor: Hoy en día, más y más fabricantes de (FFT) con probablemente diferentes FFT-longitudes. Esta observación motiva a
hardware de redes están liberando sus estrategias y soluciones SDN, junto con proponer OpenRadio para desacoplar inalámbrica protocolo de definición del hardware
una amplia variedad de conmutadores habilitados para SDN, incluyendo NEC y utilizar una interfaz declarativa para programar protocolos inalámbricos. En otro
PF5240, IBM G8264, y Pica8 3920. También hay proyectos, por ejemplo, Indigo estudio, Murty et al. presente Dyson donde un controlador NIC inalámbrica es modi fi
[82] , para permitir SDN Las funciones que utilizan actualizaciones de fi rmware en para apoyar la recolección estadística y Dyson comando API [88]. Los clientes y los
los interruptores de proveedores que no admiten SDN cuenta originalmente. 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
referencia de rendimiento juega un papel importante en la innovación en los enlace, selección de canal, velocidad de transmisión y tráfico c conformación para los
dispositivos de conmutación. Por ejemplo, la prueba y la evaluación de los dispositivos clientes y los puntos de acceso a través de la API se basa en información de medición
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 Esencialmente, tanto OpenRadio y Dyson permiten funciones de la capa física para
enrutamiento de capa 3 IP [83]. Este resultado da confianza en el rendimiento de SDN ser controlados por software. En este sentido, son los sistemas de DEG. Por otra parte, la
conmutación de conmutación no SDN convencional. Para facilitar la referencia de arquitectura de software de comunicaciones (SCA) [89], [90] ha sido diseñado por el
rendimiento, Rotsos et al. 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
presentar el marco de operaciones OpenFlow por segundo (OFLOPS) que soporta la Software fi gurability de un sistema de SDR como SCA da controladores SDN una interfaz
generación de paquetes múltiples, la captura, y los mecanismos de sellado de tiempo con para controlar el sistema de SDR. De hecho, SDR puede beneficiarse de la central de
diferentes precisiones e impactos [84]. OFLOPS mide los parámetros de rendimiento de control y visión global de SDN, como se usa en Dyson [88]. A cambio, los controladores
las operaciones de plano de control como el retraso de inserción regla y tráfico de retardo SDN pueden controlar sistemas de DEG y tener un control generalizado y precisa de
consulta c estadística. OFLOPS permite operaciones detalladas de medición del todos los dispositivos de red.
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. 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
B. La transmisión de medios
de control SDN ayuda a lograr el control fi ciente más precisa y ef del plano de datos [93].
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 Uni fi ed acerca con un solo plano de control SDN tanto sobre la conmutación de
sus características únicas, que a su vez dan lugar a menudo tecnologías fi co con fi dominios y dominios de conmutación de circuitos de paquetes se consideran fi rstly, como
guración y de gestión específicos. Como tal, SDN debería integrarse con estas se muestra en la Fig. 2 donde “Controller B” gestiona un circuito óptico de dominio y la
tecnologías en las redes inalámbricas y ópticas. Por ejemplo, Software-De fi ne Radio “conmutación de paquetes de dominio A” de conmutación. Das et al. sugerir que se extiende
(SDR) [85] apoya la evolución rentable de dispositivos de radio y Generalizado parámetros utilizados en coincidencia de regla de reenvío de la capa 2, 3, y 4 cabeceras de
conmutación de etiquetas multiprotocolo (GMPLS) [86] es el plano de control de facto un paquete para incluir la capa 1 tecnologías de conmutación, tales como intervalo de
para la longitud de onda de conmutación de redes ópticas. La integración de estas tiempo, longitud de onda, y la conmutación de fibra. Por lo tanto, proporciona un único plano
tecnologías da a los controladores SDN una gran oportunidad de tener un amplio de control unificado sobre paquetes y redes ópticas [94] - [97]. El esquema propuesto
control sobre todos los comportamientos de la red, incluyendo el envío de paquetes, el proporciona un modelo de control simplificada, pero necesita para actualizar dispositivos de
modo inalámbrico o canal, y longitud de onda óptica. De ello se desprende que la SDN conmutación de circuitos ópticos para apoyar esta extensión. Liu et al. proponer utilizar un
puede obtener un control más adecuado de la infraestructura de red y lograr la conmutador virtual en cada nodo de conmutación óptica para obtener uni fi de control ed
utilización de recursos de infraestructura más e fi ciente. 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
1) de radio inalámbrica: Muchas tecnologías de transmisión inalámbricas avanzadas SDN. Durante el despliegue, habrá una capa adicional a los controladores de puentes e
se han desarrollado para maximizar la utilización del espectro en las redes inalámbricas. interruptores de legado [104]. Aunque estos enfoques pueden volver a utilizar los equipos
Entre ellos, Software-de fi nido Radio (SDR) permite el control de la estrategia de de red legado, que provocan la latencia de comunicación adicional mediante el uso de
transmisión inalámbrica a través de software [85]. Dada su naturaleza similar, la mensajes proxy.
tecnología SDR se puede integrar fácilmente con la SDN. Por ejemplo, Bansal et al.
Transformada Rápida de Fourier 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
• Interfaces: el controlador SDN tiene dos interfaces. La interfaz sur de ruedas, que
operación de la red; un proceso de actualización regla para instalar reglas generadas a partir de dichas políticas; un está marcado como la interfaz controllerinfrastructure en la Fig. 1, se ocupa de las
proceso de recolección de estado de la red para recopilar información de infraestructura de la red; un proceso de
operaciones con la capa de infraestructura, es decir, la recogida de estado de la
sincronización de estado de red para construir una vista de red global utilizando estado de la red recogida por cada
controlador individual.
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,
múltiples grupos de interés, cada uno de los cuales los controles de elementos de la ruta de
se ocupa de las transacciones con la capa de aplicación, es decir, la recepción de
datos. En este caso, puede que no sea práctico tener un único plano de control a lo largo de la
políticas descritas en lenguajes de alto nivel de las aplicaciones SDN y
ruta de datos. enfoques de control de Split, como se muestra en la Fig. 2 donde “Controller B”
proporcionando una visión global sincronizada.
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.
Estrategias para el diseño de lenguajes de alto nivel cuali fi cados para los controladores
Diseño del controlador A.
SDN toman por lo menos dos formatos. Una estrategia es utilizar lenguajes de alto nivel
El controlador es el componente más importante en la arquitectura SDN, donde maduros existentes, como por ejemplo, C ++, Java y Python, para desarrollo de
reside la complejidad. En esta subsección, se adopta una estrategia de “divide y aplicaciones. Este enfoque normalmente proporciona un kit de desarrollo de software (SDK)
vencerás” para presentar una arquitectura de controlador lógico. . Nuestra arquitectura con las bibliotecas de características deseables, tales como la seguridad, ancho de banda
propuesta, como se representa en la figura 4, se basa en dos principios, incluyendo: 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
• Objetos: las ofertas controlador SDN con dos tipos de objetos. Uno se nuevos lenguajes de alto nivel con características especiales para lograr e fi ciente
utiliza para la red de control, incluyendo las políticas impuestas por la capa comportamiento de la red
de aplicación y de paquetes for-
XIA et al .: Una encuesta sobre Software-Defined Networking 35
control para SDN. En comparación con el enfoque de primera, pocos trabajos gineering. Ortiga utiliza Haskell como la lengua de acogida debido a su notable
publicados o liberados implementos de SDK se pueden encontrar en la actualidad, ni flexibilidad en el apoyo a los DSL embebidos. Más tarde, Voellmy et al. presente
tampoco un nuevo lenguaje de alto nivel dominante existe. En los siguientes párrafos, “Maple” para simplificar la programación SDN al permitir a un programador
se revisan varios lenguajes de alto nivel para la SDN, incluyendo el trabajo anterior en para usar un lenguaje de programación estándar para diseñar un algoritmo
este dominio llamado Flowbased lenguaje para la gestión (FML) [111], un lenguaje de centralizado arbitraria para cada paquete entra en la red, eliminando por lo
programación bien desarrollado para SDN llamado frenético [112], [113] , y otro tanto, detalles de bajo nivel [123]. Arce consta de dos componentes
lenguaje de alto nivel llamado ortiga [114] - [117]. principales, a saber, un “optimizador” y un “programador”. El optimizador utiliza
una estructura de datos “árbol traza” para grabar la invocación del algoritmo
Lenguaje basado en el flujo de Gestión (FML) [111], anteriormente conocido como programmersupplied en un paquete específico, entonces se generaliza reglas
lenguaje basado en el flujo de Seguridad (FSL) [118], es un lenguaje para la descripción en la tabla de flujo de interruptores individuales. Un árbol traza captura la
conveniente y expresiva de las políticas de conectividad de red en SDN. FML ofrece reutilización de los cálculos anteriores y, por tanto, reduce sustancialmente el
operaciones de fi ne granulares en red flujos unidireccionales y es compatible con las número de invocaciones del mismo algoritmo. El optimizador utiliza varias
limitaciones expresivas en permitir / denegar trá fi co y la limitación de ancho de banda, técnicas para mejorar la e fi ciencia, incluyendo el aumento del rastro árbol,
latencia y jitter. irrelevancia orden de FML hace que sea fácil de combinar un conjunto de árbol de la compresión de seguimiento, y la minimización prioridad de la regla.
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 2) reglas de actualización: Un controlador SDN también es responsable de generar las
[119]. 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
Frenetic [112], [113] que se propone para eliminar complicado asíncrono y las con fi guración y control dinámico, tales como dirigir tráfico c de una réplica a otro para la
interacciones basadas en eventos entre aplicaciones SDN y dispositivos de conmutación. carga dinámica de equilibrio [124], la máquina virtual (VM) la migración [125], y recuperación
En particular, frenético introduce un lenguaje de consulta de red declarativa similar a SQL de la red después de un fallo inesperado. En presencia de la dinámica de la red, la
para la clasificación y agregación de las estadísticas de trá fi co de red. Por otra parte, se consistencia es una característica básica que regla de actualización debe preservar para
introduce una biblioteca de gestión de políticas de red reactiva funcional para manejar los garantizar las operaciones de red adecuadas y propiedades de red preferidas, tales como,
detalles de la instalación y desinstalación reglas de nivel interruptor. El lenguaje de bucle libre, ningún agujero negro, y la seguridad.
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. consistencia regla puede establecerse en diferentes sabores. En la literatura, se
Monsanto et al. introducir el uso de reglas comodín y la generación proactiva. Como discuten dos de fi niciones de consistencia alternativa, incluyendo:
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
• La consistencia estricta: asegura que se utiliza ya sea el conjunto de reglas original o el
conmutación sin peticiones a los controladores [120]. gutz et al. añadir sintaxis para
conjunto de reglas actualizado. consistencia estricta podría ser ejecutada en un nivel
describir aislados rebanadas de red y permitir la virtualización de red utilizando Frenetic
por paquete, donde se procesa cada paquete, o en un per- flujo nivel, donde todos los
[121]. Pyretic [122] introduce composición secuencial que permite que una regla para
paquetes de un de flujo se procesan ya sea por la regla original establecer o el conjunto
actuar sobre los paquetes ya procesados por otra regla, y la abstracción de topología que
de reglas actualizado.
mapea entre los conmutadores físicos y conmutadores virtuales.
• La consistencia eventual: asegura que los paquetes posteriores utilizan la regla actualizada
anteriores paquetes de la misma de flujo para utilizar la regla original establecido antes o durante
Entonces, el programa emite actualizaciones de reglas para el uso especí fi co, por establecido después de un tiempo lo suficientemente largo. A continuación, el conjunto de reglas
ejemplo, la autenticación de usuarios. Uno solo de tamaño ts-fi todo lenguaje puede no ser original será eliminado. Sin embargo, tanto los conjuntos de reglas originales y actualizadas se
posible, dada la diversidad de problemas de gestión de red. DSL permiten ortiga para mantienen en los dispositivos de conmutación antes de que el conjunto de reglas originales
proporcionar una familia extensible de DSL, cada uno de los cuales está diseñado para expira y se retira.
En esta última categoría, McGeer et al. aplicar consistencia eventual para conservar actualizar los contadores de trá fi co para el partido de más alta prioridad. Por lo tanto sólo las
espacio de memoria del conmutador asegurando que sólo un único conjunto de reglas se estadísticas de trá fi co del “elefante” flujos se actualizarán y se recogen.
base de datos de respaldo de una máquina de estado replicado que asegura la durabilidad y VeriFlow para mostrar que el objetivo de latencia extremadamente baja durante los controles en
consistencia. Como resultado, esta aplicación puede ser simple sin tener en cuenta la tiempo real se puede lograr [152] - [154]. En su diseño, se introduce un proxy entre un
consistencia. Las aplicaciones SDN también pueden optar por una de un salto, con el tiempo, controlador y los dispositivos de conmutación para comprobar violaciónes invariantes en toda la
consistente, memoria de sólo Distribuir tabla hash (DHT) que tiene capacidad de alta velocidad red de forma dinámica a medida que cada regla de reenvío se actualiza. Se primer divide reglas
de actualización; sin embargo, estas aplicaciones necesitan para manejar las inconsistencias sí en clases de equivalencia en base a pre fi x superposición y utiliza pre estructura de datos de
mismos. á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.
B. Políticas y Regla de validación
La verificación de modelos, que es ampliamente utilizado para verificar automáticamente la Para abordar el problema de escalabilidad con un controlador SDN, los investigadores
corrección de un sistema de estado finito, se puede adoptar fácilmente para la política y la han propuesto anteriormente varios controladores con la colocación geográfica adecuada
validación regla. A lo largo de esta línea de investigación, se propone FlowChecker para identificar [155], que sería necesario sincronización estado de la red. los esfuerzos de investigación
intra-interruptor configuraciones Miscon fi e inconsistencias entre conmutadores aprovechando alternativos también son buscados desde un aspecto de diseño para aumentar la capacidad
modelo comprobación [145], [146]. Específicamente, FlowChecker utiliza diagrama de decisión de procesamiento de un único controlador o disminuir la frecuencia de las solicitudes de ser
binario (BBDs) para codificar configuraciones y modelos de comportamiento global de una red en procesada. Describimos estos esfuerzos de investigación en este apartado, y técnicas de
una sola máquina de estados fi estafadores red de “qué pasaría si” análisis. FlowChecker referencia actual de rendimiento para los controladores de SDN.
proporciona, además, una interfaz basada en propiedad genérica para verificar las propiedades de
modelo simbólico basado en BDD y la lógica temporal. El uso del lenguaje CTL hace que sea más 1) El aumento de la capacidad de procesamiento: Un controlador es esencialmente una pieza de
fácil de escribir consultas para validar ciertas propiedades o extraer estadísticas que se han software. Como tales técnicas de optimización de software, convencionales como paralelismo y de
utilizado para su posterior análisis. En otro ejemplo, Canini et al. presente NICE (No hay errores en dosificación se pueden utilizar para mejorar el rendimiento del controlador en el procesamiento de
el controlador de ejecución), que también adopta modelo de comprobación para comprobar las solicitudes, que se utiliza en Maestro [156], [157], NOX-MT [158], y McNettle [159], [160 ].
propiedades de corrección en SDN [147] - [149]. AGRADABLE toma una aplicación SDN, topología Específicamente, Maestro [156], [157] es una implementación controlador basado en Java. Se explota de
de la red y la corrección propiedades, por ejemplo, entradas libres de bucles, como, a continuación, paralelismo junto con técnicas de optimización de rendimiento adicionales, tales como, entrada y salida
realiza una búsqueda de espacio de estado y produce trazas de violaciónes de propiedad. Utiliza la de dosificación, el núcleo y la rosca de unión. Está demostrado que este diseño conduce a un mejor
verificación de modelos para explorar las rutas de ejecución del sistema, la ejecución simbólica rendimiento y escalabilidad casi lineal desempeño en procesadores multi-núcleo. En otro caso, NOX-MT
para reducir el espacio de las entradas y las estrategias de búsqueda para reducir el espacio de es un controlador multi-hilo basado en el único hilo C aplicación ++ de sistema operativo de red (NOX)
estados. En la práctica, a menudo (OpenFlow entorno de pruebas) construido en base a [158]. Benchmarking sobre diferentes controladores, incluyendo NOX, NOX-MT, Maestro, y Beacon
AGRADABLE utilizando dispositivos de conmutación físicas cuyos estados están sincronizados con [161], muestra ventajas de rendimiento de NOX-MT sobre los otros en términos de tiempo mínimo y
los modelos de conmutación utilizados en AGRADABLE [150]. A menudo puede ser utilizado para máximo de respuesta, así como el máximo rendimiento. McNettle es un controlador SDN escrito en
el dispositivo de conmutación física pruebas de recuadro negro. 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,
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
Desde otra perspectiva, las reglas pueden ser validados de forma estática o dinámica. Por múltiples núcleos de la Haskell Compiler Glasgow (GHC) y el sistema de tiempo de ejecución [159],
un lado, las reglas se pueden comprobar de forma estática para ciertos invariantes red, tales [160]. McNettle controladores de eventos horarios, asigna memoria, optimiza el análisis de mensajes y la
como la accesibilidad, libre de bucles, y la consistencia, basado en Topología de red [151]. Por serialización, y reduce el número de llamadas al sistema con el fin de optimizar el uso de la caché, el
otro lado, también es útil para verificar las reglas en tiempo real, como evoluciona el estado de procesamiento del sistema operativo, y la sobrecarga del sistema en tiempo de ejecución. Los
la red. Sin embargo, el logro de una latencia extremadamente baja durante estos controles es experimentos muestran que McNettle puede servir hasta 5000 interruptores usando un único controlador
en última instancia importante. Khurshid et al. presente 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. V. Un OLICITUD L AYER
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.
Enrutamiento adaptativo A.
presente DevoFlow para manejar la mayoría “ratones” flujos en los dispositivos de conmutación La conmutación de paquetes y el enrutamiento son las principales funciones de una
[164]. DevoFlow proactivamente instala un pequeño conjunto de posibles reglas de reenvío de red. Tradicionalmente, los diseños de conmutación y enrutamiento se basan en enfoques
paquetes en los dispositivos de conmutación. Como resultado de ello, de igual costo Multi-Path distribuidas para robustez. Sin embargo, tales diseños distribuidos tienen muchas
(ECMP) de enrutamiento y cambio de ruta rápida después del puerto de salida designado baja se deficiencias, incluyendo la implementación compleja, lenta convergencia [180], y la
puede apoyar sin solicitar controladores. DevoFlow también utiliza el muestreo, lo que provocó capacidad limitada para lograr el control adaptativo [181]. Como solución alternativa, SDN
informe después de una condición de umbral se ha cumplido, y se aproxima a los contadores que ofrece un control de bucle cerrado, la alimentación de las aplicaciones con información de
sólo un seguimiento de las estadísticas de las láminas superior k 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
mayores “ratones” flujos. Como resultado, se reduce la cantidad de datos en la comunicación la plataforma SDN por mejores diseños de enrutamiento. En los siguientes párrafos, se
con los controladores durante la recolección estadística. describen dos aplicaciones SDN populares en este dominio, es decir, el equilibrio de
organización adecuada y la división del trabajo de los dispositivos de carga y diseño cross-layer.
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, 1) de equilibrio de carga: El balanceo de carga es una técnica ampliamente utilizada para
Kandoo tiene una arquitectura de dos capas para manejar la mayoría de los lograr un mejor uso de los recursos. Una práctica común de equilibrio de carga en los centros
eventos frecuentes a nivel local. La capa inferior es un grupo de controladores sin de datos está desplegando equilibradores de carga front-end para dirigir la petición de cada
una vista de toda la red que manejar la mayoría de los eventos frecuentes. cliente para una réplica servidor en particular para aumentar el rendimiento, reducir el tiempo
“Elefante” detección de flujo, que necesita consultar constantemente cada de respuesta, y evitar la sobrecarga de la red. equilibradores de carga dedicados, sin
dispositivo de conmutación para ver si una de flujo tiene datos suficientes para ser embargo, suelen ser muy caros. SDN permite un enfoque alternativo. En los párrafos
un “elefante” flujo, se puede hacer a la capa inferior. Al mismo tiempo, la capa siguientes, que primero discutimos algoritmos para equilibrar la carga usando reglas de
superior es un controlador de lógica centralizada que mantiene una visión de toda reenvío de paquetes y, a continuación presente usos casos en varios escenarios.
la red y gestiona los eventos raros, por ejemplo, solicitando para decisiones de
enrutamiento. Como resultado de la arquitectura de dos capas,
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
3) Estudio comparativo del rendimiento: Controlador de pruebas de rendimiento se puede árbol binario para organizar IP pre fi jos. El tráfico c se divide entonces usando reglas de tarjeta
utilizar para identificar los cuellos de botella y es esencial para aumentar la capacidad de salvaje, de modo que una réplica del servidor manejará un tráfico c cuyo volumen es
procesamiento de un controlador. Cbench (benchmarker controlador) [166] y OFCBenchmark proporcional a la capacidad de procesamiento de la réplica del servidor. Aunque la suposición
[167] son dos herramientas diseñadas para la evaluación comparativa controlador. Cbench puede no ser cierto en la mayoría de los casos, este trabajo establece una base para futuras
[166] prueba el rendimiento del controlador mediante la generación de solicitudes de reglas investigaciones sobre las reglas de reenvío de paquetes apalancamiento de balanceo de carga
de reenvío de paquetes y viendo para las respuestas desde el controlador. Cbench ofrece de SDN. Además de calcular una ruta para cada tráfico c flujo de forma proactiva para lograr
estadísticas agregadas de rendimiento del controlador y el tiempo de respuesta para todos los carga equilibrada, otra metodología es migrar tráfico c de dispositivos de conmutación cargadas
dispositivos de conmutación. estadísticas agregadas pueden no ser suficiente suficiente para pesadas a ligeramente cargado los reactivamente [182].
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 Si bien el desarrollo de algoritmos es esencial, otros hacen esfuerzos para
respuesta y el número de paquetes sin respuesta para cada dispositivo de conmutación. 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 39
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, desde una estación base a otra, o incluso de una red inalámbrica a otra.
el tráfico web fi co y el tráfico de correo electrónico fi co, para lograr implementaciones del Uniformidad de traspaso es crítico para aplicaciones para proporcionar un servicio
algoritmo de equilibrado dedicados y especializados en función de los requisitos de los ininterrumpido. Handover en la literatura actual es a menudo limitada a las redes
servicios y cargas de trabajo [183]. En otra situación, un equilibrador de carga frontal tiene de una sola portadora con la misma tecnología. En SDN, redes de diferentes
que dirigir todas las solicitudes y puede llegar a ser el cuello de botella de un centro de datos. portadoras con diferentes tecnologías podrían tener un plano de control ed fi uni
Para resolver este problema, Handigol et al. 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.
presente Plug-n-Serve (ahora llamado Aster * x [53]), que equilibra la carga sobre una red 2.
no estructurada arbitraria usando una implementación de SDN [172]. Controla
directamente caminos tomados por nuevas peticiones HTTP para minimizar el tiempo de Varios esquemas de transferencia se han desarrollado sobre la base de SDN.
respuesta promedio de los servicios web. 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-
2) Diseño Cruz-capa: Un enfoque cross-layer es una técnica muy promocionado para casting, que duplica tráfico c a través norte caminos distintos [173] - [175]. Estos
mejorar la integración de las entidades en diferentes capas en una arquitectura de capas, esquemas de transferencia se pueden implementar fácilmente con NEE para
por ejemplo, el modelo de referencia OSI, permitiendo a las entidades en diferentes capas reducir la pérdida de paquetes y mejorar el rendimiento TCP durante el traspaso.
para intercambiar información entre sí. Como SDN ofrece una plataforma de aplicaciones Otro caso de uso es Odin, que es un marco SDN prototipo para redes WLAN
para acceder fácilmente a la información de estado de red, los enfoques crosslayer se empresariales [176]. Odin asigna una única fi cación identi conjunto de servicios
pueden desarrollar fácilmente en esta plataforma. En los párrafos siguientes, se presentan básicos (BSSID) para cada cliente conectado. Traspaso se realiza retirando el
casos de uso para proporcionar QoS garantizados y la mejora de rendimiento de las BSSID de un punto de acceso inalámbrico física (AP) y el desove a otro. Odin
aplicaciones que aprovechan la técnica de diseño de capa cruzada. 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.
programación de ancho de banda disponible de un controlador SDN. A continuación, la hora más errores guración fi estafadores son causas comunes de fallas en la red. Se ha
temprana a la que una llamada de vídeo o, alternativamente, una llamada de audio se pueden informado de que más del 60% de inactividad de la red se debe a errores con fi
hacer con la garantía de calidad se calcula [55]. Como otro ejemplo, Jeong et al. presentes guración humanos [185]. Lo peor es que las herramientas de red existentes que tienen
compatibles con QoS de red del sistema operativo (QNOX) para ofrecer servicios de calidad de que ver con el diagnóstico individual como ping, traceroute, tcpdump, y NetFlow, no
servicio garantizados, como la evaluación de calidad de servicio QoS cuenta virtual de la pueden proporcionar una solución de mantenimiento de la red automatizado e integral.
incrustación de la red y de extremo a extremo de la red [56]. Para una solicitud exigentes una red A modo de comparación, la gestión centralizada y automatizada y aplicación de
virtual con requisitos de QoS en el ancho de banda de enlace virtual y el retardo entre los nodos políticas coherentes, inherente a las redes SDN, ayudar a reducir los errores con fi
virtuales, QNOX hará QoSaware asignación para la red virtual en la red de sustrato. QNOX guración. Por otra parte, con una visión global y el control central de la con fi guración,
también supervisa la QoS de extremo a extremo que ofrecen resultados medidos para ayudar a SDN ofrece oportunidades para diseñar mecanismos integrales de diagnóstico y
hacer cambios operacionales. pronóstico de la red para el mantenimiento de la red automatizado, como se describe
en los siguientes párrafos.
ópticos. Utilizan Hadoop como un ejemplo y el diseño de estrategias de planificación de controlador. El controlador entonces construir una traza inversa para la depuración de la red.
tareas de Hadoop para acomodar red dinámica con fi guración de una red híbrida con Tomando una estrategia similar, OFRewind registra constantemente eventos de red que
Ethernet y conmutadores ópticos. Sus informes de análisis preliminares mejoraron aparecen en una red. Una característica novedosa de OFRewind es que repeticiones eventos
rendimiento de la aplicación y utilización de la red con relativamente baja sobrecarga con registrados más adelante para solucionar problemas de la red.
fi guración.
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
B. Roaming sin límites
controlador calcula nuevos caminos de reenvío para las rutas afectadas y reglas de reenvío
Los teléfonos inteligentes y las tabletas se están convirtiendo en dispositivos que dominan en el actualizaciones paquete inmediatamente sin esperar a que las reglas de reenvío viejos de
acceso a Internet. Estos dispositivos móviles acceder a Internet de forma inalámbrica. Para garantizar expirar.
la conectividad continua, mientras que éstos
40 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 1, PRIMER TRIMESTRE 2015
D. Seguridad de Red
para lograr una red verde, incluyendo, pero no limitado a, la adaptación de enlace de datos bajo
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
TABLA III
E Xperiment S ETUP DE SDN A plicaciones
G. SDN para Cloud Computing 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
La computación en nube está cambiando la forma de hacer la computación y de negocios.
de datos VM migración [182], [215] - [221] mediante la inserción de reglas adecuadas
disposiciones, los recursos de computación y almacenamiento en la demanda y cargas sobre
reenvío de paquetes en los dispositivos de conmutación para dirigir tráfico c a la nueva
el uso con servidores y virtualización de la red. SDN proporciona oportunidades para extender
ubicación VM. Como ejemplo de los centros de datos inter VMmigration, Mann et al.
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
presentes CrossRoads migren VM a través de los centros de datos sin problemas usando una
obtener más flexible y e fi ciente cloud computing [207].
implementación de SDN [218]. CrossRoads se extiende la idea de la independencia de la
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
Fig. 6. Interruptor OpenFlow. La tabla de flujo es controlado por un controlador remoto a través del canal escala fi se despliega por el proyecto OpenRoads Stanford [230]. El despliegue de Stanford OpenRoads
seguro [222].
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
la creación de una red separada exclusivamente para el control de la red se de la red. Un servidor DHCP se utiliza para asignar direcciones IP a los clientes móviles. OpenRoads
manifiesta el concepto clave de SDN y sienta las bases para la programación también tiene un sistema de registro, herramientas de gráficos y visualización de datos en tiempo real
de la red y el control centralizado lógicamente. En el desarrollo de la SDN y para controlar el sistema. Estas herramientas han sido cuidadosamente diseñados para ser
OpenFlow, sus conceptos y enfoques de diseño van de la mano con la otra. complementarios pero independientes, y que son reutilizables para otras implementaciones. El
Por un lado, muchos conceptos en SDN se basan en el diseño de OpenFlow. despliegue OpenRoads abre el camino para desplegar OpenFlow en redes de campus con ambas
Por otra parte, como el concepto de NEE se vuelve más clara y más maduro, conexiones cableadas e inalámbricas. Aparte de las implementaciones de propósito de investigación en
entonces influye en el desarrollo futuro de OpenFlow. En otras palabras, redes de campus, OpenFlow también se ha desplegado en las redes de producción. Google ha
OpenFlow de fi ne el concepto inicial de la SDN y SDN rige el desarrollo futuro implementado un software definida WAN llamado “B4” que conecta los centros de datos de Google en
de OpenFlow. En las siguientes subsecciones, que primero presente proceso todo el planeta durante tres años [231]. B4 es un enfoque híbrido con el apoyo simultáneo de los
de normalización y casos de implementación de OpenFlow. A continuación, protocolos de enrutamiento existentes y enfoque novedoso OpenFlow SDN. Para el plano de datos,
presentamos algunos proyectos de software ampliamente utilizado OpenFlow, Google construye sus propios conmutadores de OpenFlow habilitado de múltiples chips de silicio
y por último comparamos con las fuerzas OpenFlow, 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
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
A. Normalización y despliegue
enlace 100%. B4 soportes existentes protocolos de enrutamiento y OpenFlow, por lo tanto ofrece una
El OpenFlow especí fi cación está evolucionando continuamente con nuevas solución menos perjudicial y más económico para el despliegue OpenFlow en las redes de producción
características en cada nueva versión. Con más y más vendedores de la liberación de sus para las empresas. OpenFlow redes se han expandido rápidamente, desde su primera implementación.
productos y soluciones OpenFlow habilitado, más proyectos de software están Ahora, los productos de OpenFlow están permeando en laboratorios, aulas [232], las redes de bancos de
desarrollando en OpenFlow y más organizaciones desplegar redes OpenFlow habilitado, pruebas [58], [59], [233] - [237], centros de datos y redes de proveedores de servicios [238]. OpenFlow
un ecosistema completo y bien funcionado-está siendo construido alrededor de redes se han expandido rápidamente, desde su primera implementación. Ahora, los productos de
OpenFlow. OpenFlow están permeando en laboratorios, aulas [232], las redes de bancos de pruebas [58], [59], [233]
El OpenFlow Interruptor Consortium [223] libera la aplicación primer OpenFlow - [237], centros de datos y redes de proveedores de servicios [238]. OpenFlow redes se han expandido
referencia, versión 0.1.0, con el código fuente, el 30 de noviembre de 2007. A rápidamente, desde su primera implementación. Ahora, los productos de OpenFlow están permeando en
continuación, publicó la versión OpenFlow 1.0 el 31 de diciembre de 2009, que laboratorios, aulas [232], las redes de bancos de pruebas [58], [59], [233] - [237], centros de datos y
añade múltiples colas por puerto de salida para mínimo garantías de ancho de redes de proveedores de servicios [238].
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
B. OpenFlow Proyectos de Software
lanzado con DE-Con fi g 1.1, que es un protocolo para con fi gura y gestionar
interruptores OpenFlow y controladores. 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.
Junto con el proceso de OpenFlow normalización, muchos interruptores NOX es el controlador de primer OpenFlow. Permite que las aplicaciones que se ejecutarán
OpenFlow y controladores de superficie. El primer OpenFlow sobre la base de una visión centralizada de la red utilizando
XIA et al .: Una encuesta sobre Software-Defined Networking 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
Fig. 7. IETF fuerzas Arquitectura. Un elemento de red fuerzas consiste de dos tipos de
y CEs, y la Capa fuerzas protocolo de asignación de Transporte (fuerzas TML) para
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 transportar los mensajes de PL. Por lo tanto, las fuerzas permite la coexistencia de
correspondiente o Fe en la fase de pre-asociación. 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
nombres de niveles altos en comparación con los algoritmos distribuidos en las direcciones
los cuales tiene una única función específico de paquetes de procesamiento. En los
de bajo nivel. Las aplicaciones se escriben ya sea Python o C ++ y se cargan de forma
párrafos siguientes, se presenta una comparación completa entre OpenFlow y
dinámica. funciones de infraestructura y speedcritical centrales de NOX se implementan en
fuerzas en términos de sus objetivos, la arquitectura, el modelo de reenvío y el
C ++.
protocolo de la interfaz, tal como se resume en la Tabla V [241], [242]:
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 • Gol: Fuerzas no está diseñado con una visión a largo plazo para implementar
entre dos hosts usando ping. Desde MiniNet proporciona un entorno simulado para la SDN. El objetivo de las fuerzas es separar el plano de datos del plano de
experimentación, las nuevas ideas pueden ser desarrolladas y probadas en MiniNet control, mientras que OpenFlow está diseñado para SDN;
espacios de nombres de red, para crear redes virtuales permite MiniNet para escalar a todavía se ejecutan los protocolos de enrutamiento al igual que los routers convencionales. A
cientos de nodos en un solo equipo. diferencia de fuerzas, interruptores OpenFlow serán controlados por un controlador y pueden
TABLA VI SDN R
ELACIONADAS R ESEARCHES
En resumen, las fuerzas proporciona más fl exible modelo de reenvío y funciones de mejorar el rendimiento, la innovación y alentado. Por otra parte, hemos proporcionado
los protocolos más ricos. Sin embargo, debido al modelo de negocio disruptivo un estudio de la literatura de investigaciones recientes SDN en la capa de
interpuesto por el modelo de reenvío LFB y falta de apoyo de código abierto, las fuerzas infraestructura, la capa de control, y la capa de aplicación, tal como se resume en la
no es tan ampliamente adoptados como OpenFlow. OpenFlow todavía puede aprender Tabla VI. Por último, hemos introducido OpenFlow, la aplicación de facto SDN.
mucho de ambas ventajas y deficiencias de fuerzas para un mayor éxito.
B. Pautas de diseño
VII. do CONCLUSIÓN, re DISEÑO GRAMO IRECTRICES
El éxito de SDN requiere mejoras y desarrollos en todas las tres capas,
Y F UTURO R NVESTIGACIONES
incluyendo la capa de infraestructura, la capa de control, y la capa de aplicación. Se
Para concluir, primero presentamos un breve resumen de todo el artículo. A continuación necesita la colaboración de diferentes organizaciones, incluyendo proveedores,
enumeramos los principios de diseño que se han adoptado en las investigaciones relacionadas SDN. instituciones académicas y las comunidades, y el conocimiento interdisciplinario que
Por último, señalamos unos SDN algunos aspectos relacionados que necesitan los futuros esfuerzos cubren tanto de hardware como de software. En los párrafos siguientes,
de investigación. 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 45
• SDN se desarrolló originalmente para las redes basadas en IP en los cisiones se llevan a cabo adecuadamente en la capa de infraestructura. Sin embargo, se
campus. Por lo tanto, la ampliación de cobertura ubicua de SDN requiere uni requiere la participación de los desarrolladores de software para convertir las ideas
fi cación y la integración con tecnologías avanzadas en la transmisión innovadoras de soluciones que pueden traer beneficios económicos, sociales y
• Para mejorar ventajas de desacoplar el plano de control desde el plano de datos, abiertas que cubren todo el ciclo de vida de SDN de la normalización, implementación,
un expresivo y completa interfaz de alto nivel para el acceso y los dispositivos de despliegue:
conmutación de control debe ser proporcionado para facilitar aún más con la red • La estandarización de SDN: Siendo la aplicación de facto del concepto
fi configuración y gestión. Habilidades de diversas áreas de la informática, como SDN, OpenFlow es de ninguna manera la única aplicación SDN. IETF
la teoría del lenguaje de programación, métodos formales y sistemas distribuidos, también ha lanzado un marco SDN [255]. El ETSI Industria Speci fi
se deben aplicar para permitir la generación automática de lenguaje de alto nivel cación Group (ISG) para las funciones de red de virtualización (NFV) se
de las políticas descritas en las normas de bajo nivel y sin conflictos y garantizar ha formado recientemente para promover NFV, que es altamente
la consistencia durante el procedimiento de actualización de reglas. 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
• técnicas de medición de la red también son útiles para la recolección de estado de testigos de muchos proyectos dirigidos a problemas similares que
la red. Para las redes a gran escala, varios controladores son necesarios. utilizan enfoques similares. Sin embargo, una solución hablaba aún no
algoritmos de sincronización estudiados en sistemas distribuidos y sistemas de ha surgido. La fragmentación en funciones del controlador y API
bases de datos pueden ser adoptados para sincronizar el estado de la red proporcionadas por los controladores puede ser una barrera de potencial
percibidas entre múltiples controladores. para el desarrollo comercial de SDN. Además, OpenFlow especí fi
cación evoluciona rápidamente y permite diferentes interpretaciones. Por
• Un controlador SDN tiene que manejar una enorme cantidad de eventos de lo tanto,
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 • Implementación de SDN: El enfoque actual SDN de desacoplamiento de plano de
solicitud. control completamente de plano de datos sugiere una eliminación total de cualquier
• SDN proporciona una plataforma para implementar diversas aplicaciones SDN. SDN protocolos de enrutamiento a bordo de los dispositivos de conmutación. Este
aplicaciones pueden acceder a una vista de red y la capa cruzada mundial de enfoque puede ser demasiado idealista, lo que puede impedir SDN de la
información para tomar mejores decisiones de operación de la red. SDN adaptación generalizada. Una inmediata y directa a transformar idealista SDN se
controladores aseguran que éstos de-
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 [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.
convencionales. En la fase de transición de los dispositivos de conmutación
regla y más tiempo en las operaciones de búsqueda. Además, el diseño de proxy 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
ampliamente utilizado entre los dispositivos de conmutación y el controlador ya ha
[5] P. y D. Cesar Geerts, “Pasado, presente y futuro de la televisión social: una cate- [33] M. Handley, O. Hodson, and E. Kohler, “XORP: An open platform for
gorization,”en Proc. IEEE CCNC, 2011, pp. 347-351. network research,” ACM SIGCOMM Comput. Commun. Rev., vol. 33, no. 1, pp. 53–57, Jan.
[6] Y. Jin, X. Liu, Y. Wen, y J. Cai, “interacción de pantalla Inter para la sesión 2003.
reconocimiento y transferencia basada en la red multimedia nube centrada”en Proc. IEEE ISCAS, 2013, [34] Quagga Routing Software Suite. [Online]. Available: http://www.
pp. 877-880. nongnu.org/quagga/
[7] Y. Jin, Y. Wen, G. Shi, G. Wang, y A. Vasilakos “, CoDaaS: [35] The BIRD Internet Routing Daemon. [Online]. Available: http://bird.
Una plataforma experimental nube centrada de entrega de contenido para el contenido generado por el network.cz/
usuario,”en Proc. En t. Conf. Comput. Netw. Commun., 2012, pp. 934-938. [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
[8] J. Dean y S. Ghemawat, “MapReduce: Simpli fi procesamiento de datos ed en FDNA, 2004, pp. 5–12.
racimos grandes,” Commun. ACM, vol. 51, no. 1, pp 107-113, enero de 2008. [9] “Cisco Visual [37] L. Yang, R. Dantu, T. Anderson, and R. Gopal, Forwarding and Con-
Networking Index:. Global móvil tráfico de datos fi c pronóstico UP- trol Element Separation (ForCES) Framework, Apr. 2004, RFC 3746. [Online]. Available:
fecha, 2013-2018 “, San José, CA, EE.UU., Libro Blanco, febrero de 2014. [10] Facebook http://www.cisco.com/en/US/solutions/collateral/
línea de tiempo. [En línea]. Disponible: http://newsroom.fb.com/ ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360.pdf [38] T. Lakshman, T.
Cronología Nandagopal, R. Ramjee, K. Sabnani, and T. Woo, “The
[11] “Cisco Visual Networking Index: El Tiempo y la metodología, softrouter architecture,” in Proc. ACM SIGCOMMWorkshop Hot Topics Netw., 2004, pp. 1–6.
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/ [39] W. Wang et al., “Design and implementation of an open programmable
ns525 / ns537 / ns705 / ns827 / white_paper_c11-481360.pdf [12] H. Kim, T. Benson, A. router compliant to IETF ForCES specifications,” in Proc. 6th ICN,
Akella, y N. Feamster, “La evolución de NET 2007, pp. 1–6.
con fi guración de trabajo: La historia de dos campus,”en Proc. ACM SIGCOMM Conf. Meas de [40] A. Doria et al., Forwarding and Control Element Separation (ForCES)
Internet. Conf., 2011, pp. 499-514. Protocol Specification, Mar. 2010, RFC 5810. [Online]. Available:
[13] “¿Qué hay detrás de la red de inactividad?” Sunnyvale, CA, EE.UU., mayo de 2008, http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/
Papel blanco. [En línea]. Disponible: https://www-935.ibm.com/services/ sg / GTS / pdf / ns705/ns827/white_paper_c11-481360.pdf [41] J. Rexford et al., “Network-wide decision
200249.pdf making: Toward a wafer-thin
[14] H. Xie, Y. Yang, A. Krishnamurthy, Y. Liu, y A. Silberschatz, “P4P: control plane,” in Proc. HotNets, 2004, pp. 59–64.
portal de proveedores de aplicaciones” ACM SIGCOMM Comput. Commun. Rdo., vol. 38, no. 4, pp. [42] A. Greenberg et al., “A clean slate 4D approach to network control
351-362, agosto de de 2008. and management,” SIGCOMM Comput. Commun. Rev., vol. 35, no. 5, pp. 41–54, Oct. 2005.
[15] T.-Y. Huang, N. Handigol, B. Heller, N. McKeown, y R. Johari, “Con- [43] H. Yan et al., “Tesseract: A 4D network control plane,” in Proc. 4th
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. USENIX Conf. NSDI, 2007, p. 27.
XIA et al.: A SURVEY ON SOFTWARE-DEFINED NETWORKING 47
[44] A. Farrel, J.-P. Vasseur, and J. Ash, A Path Computation Element [71] G. Lu, R. Miao, Y. Xiong, and C. Guo, “Using CPU as a traffic co-
(PCE)-Based Architecture, Aug. 2006, RFC 4655. [Online]. Available: processing unit in commodity switches,” in Proc. 1st Workshop HotSDN,
http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ 2012, pp. 31–36.
ns705/ns827/white_paper_c11-481360.pdf [45] M. Casado et al., “SANE: A protection [72] Pantou: OpenFlow 1.0 for OpenWRT. [Online]. Available: http://www.
architecture for enterprise net- openflow.org/wk/index.php/Pantou_:_OpenFlow_1.0_for_OpenWRT [73] Y. Mundada, R.
works,” in Proc. 15th Conf. USENIX-SS, Berkeley, CA, USA, 2006, vol. 15, p. 10. Sherwood, and N. Feamster, “An OpenFlow switch
element for click,” presented at the Symposium Click Modular Router, Ghent, Belgium, 2009.
[46] J. Luo, J. Pettit, M. Casado, J. Lockwood, and N. McKeown, “Prototyp- [74] B. Pfaff et al., “Extending networking into the virtualization
ing Fast, Simple, Secure Switches for Etha,” in Proc. 15th Annu. IEEE Symp. HOTI, 2007, pp.
73–82. layer,” in Proc. HotNets, New York, NY, USA, 2009. [Online]. Available:
[47] M. Casado et al., “Ethane: Taking control of the enterprise,” in Proc. http://conferences.sigcomm.org/hotnets/2009/papers/ hotnets2009-final143.pdf
Conf. SIGCOMM Appl., Technol., Archit., Protocols Comput. Commun.,
2007, pp. 1–12. [75] J. Pettit, J. Gross, B. Pfaff, M. Casado, and S. Crosby, “Virtual switching
[48] M. Casado et al., “Rethinking enterprise network control,” IEEE/ACM in an era of advanced edges,” in Proc. 2nd Workshop DC-CAVES, 2010, pp. 1–7. [76] J.
Trans. Netw., vol. 17, no. 4, pp. 1270–1283, Aug. 2009. [49] S. Shenker, M. Casado, T. Lockwood et al., “NetFPGA-an open platform for gigabit-rate
Koponen, and N. McKeown, “The future of
networking, and the past of protocols,” presented at the Open Networking Summit, Stanford, network switching and routing,” in Proc. IEEE Int. Conf. MSE, 2007, pp. 160–161.
CA, USA, 2011. [Online]. Available: http://www.
opennetsummit.org/archives/apr12/site/talks/shenker-tue.pdf [50] A. Gember, P. Prabhu, Z. [77] M. Anwer, M. Motiwala, M. Tariq, and N. Feamster, “SwitchBlade: A
Ghadiyali, and A. Akella, “Toward software- platform for rapid deployment of network protocols on programmable hardware,” ACM
defined middlebox networking,” in Proc. 11th ACM Workshop Hot Topics Netw., 2012, pp. SIGCOMM Comput. Commun. Rev., vol. 40, no. 4, pp. 183–194, Oct. 2010. [78] G. Lu et al., “Serverswitch:
7–12. A programmable and high performance
[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. platform for data center networks,” in Proc. NSDI, 2011, p. 2.
NSDI, 2010, p. 19. [79] A. Rostami, T. Jungel, A. Koepsel, H. Woesner, and A. Wolisz, “ORAN:
[52] M. Ghobadi, S. Yeganeh, and Y. Ganjali, “Rethinking end-to-end con- OpenFlow routers for academic networks,” in Proc. IEEE 13th Int. Conf. HPSR, 2012, pp.
gestion control in software-defined networks,” in Proc. 11th ACMWorkshop Hot Topics Netw., 2012, 216–222.
pp. 61–66. [80] J. Naous, D. Erickson, G. A. Covington, G. Appenzeller, and
[53] N. Handigol, S. Seetharaman, M. Flajslik, R. Johari, and N. McKeown, N. McKeown, “Implementing an OpenFlow switch on the NetFPGA platform,” in Proc. 4th
“Aster ∗ x: Load-balancing as a network primitive,” in Proc. 9th GENI Eng. Conf. (Plenary), 2010, ACM/IEEE Symp. ANCS, 2008, pp. 1–9.
pp. 1–2. [81] J. Kempf et al., “OpenFlow MPLS and the open source label switched
[54] B. Heller et al., “ElasticTree: Saving energy in data center networks,” in router,” in Proc. 23rd ITC, 2011, pp. 8–14.
Proc. 7th USENIX Conf. NSDI, 2010, p. 17. [82] Indigo—Open Source OpenFlow Switches. [Online]. Available: http://
[55] A. Ferguson, A. Guha, J. Place, R. Fonseca, and S. Krishnamurthi, www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/
“Participatory networking,” in Proc. Hot-ICE, San Jose, CA, USA, ns827/white_paper_c11-481360.pdf
2012, p. 2. [83] A. Bianco, R. Birke, L. Giraudo, and M. Palacin, “Openflow switching:
[56] K. Jeong, J. Kim, and Y. Kim, “QoS-aware network operating system Data plane performance,” in Proc. IEEE ICC, 2010, pp. 1–5.
for software defined networking with generalized OpenFlows,” in Proc. IEEE NOMS, 2012, pp. [84] C. Rotsos, N. Sarrar, S. Uhlig, R. Sherwood, and A. W. Moore,
1167–1174. “OFLOPS: An open framework for OpenFlow switch evaluation,” in
[57] T. Koponen et al., “Architecting for innovation,” ACM SIGCOMM Proc. 13th Int. Conf. PAM, 2012, pp. 85–95.
Comput. Commun. Rev., vol. 41, no. 3, pp. 24–36, Jul. 2011. [58] PlanetLab. [Online]. [85] T. Ulversoy, “Software defined radio: Challenges and opportunities,”
Available: http://www.planet-lab.org/ [59] Global Environment for Network Innovations (GENI). IEEE Commun. Surveys Tuts., vol. 12, no. 4, pp. 531–550, May 2010. [86] E. Mannie,
[Online]. Avail- Generalized Multi-Protocol Label Switching (GMPLS) Ar-
able: http://www.geni.net/ chitecture, Oct. 2004, RFC 3945. [Online]. Available: http://tools.ietf. org/rfc/rfc6325.txt
[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. [87] M. Bansal, J. Mehlman, S. Katti, and P. Levis, “OpenRadio: A pro-
452–453, Aug. 2011. [61] N. Blefari-Melazzi, A. Detti et al., “An OpenFlow-based testbed for grammable wireless dataplane,” in Proc. 1st Workshop HotSDN, 2012, pp. 109–114.
information centric networking,” in Proc. Future Netw. Mobile Summit, [88] R. Murty, J. Padhye, A. Wolman, andM. Welsh, “Dyson: An architecture
2012, pp. 4–6. for extensible wireless LANs,” in Proc. USENIXATC, 2010, p. 15.
[62] H. Yin et al., SDNi: AMessage Exchange Protocol for Software Defined [89] Joint Program Executive Office (JPEO) for the Joint Tactical Radio
Networks (SDNS) across Multiple Domains, Jun. 2012, Internet draft. [Online]. Available: System (JTRS), Software Communications Architecture Specification, San Diego, CA, USA
http://www.cisco.com/en/US/solutions/collateral/ 2012. [Online]. Available: http://jpeojtrs.mil/sca/
ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360.pdf [63] H. Xie et al., “Software-defined Documents/SCAv4_0/SCA_4.0_20120228_ScaSpecification.pdf [90] G. Jianxin, Y. Xiaohui, G.
networking efforts debuted at IETF 84,” Jun, and L. Quan, “The software communica-
IETF J., Oct. 2012. [Online]. Available: http://www.internetsociety.org/ fr/node/45708 [64] R. tion architecture specification: Evolution and trends,” in Proc. PACIIA,
Birke et al., “Partition/aggregate in commodity 10G ethernet 2009, vol. 2, pp. 341–344.
[91] Wireless Innovation Forum (Previously the SDRForum). [Online]. Avail-
software-defined networking,” in Proc. IEEE 13th Int. Conf. HPSR, able: http://www.wirelessinnovation.org/ [92] J. Elbers and A. Autenrieth, “From static to
2012, pp. 7–14. software-defined optical
[65] E. Karpilovsky, M. Caesar, J. Rexford, A. Shaikh, and J. van der networks,” in Proc. 16th Int. Conf. ONDM, 2012, pp. 1–4.
Merwe, “Practical network-wide compression of IP routing tables,” [93] A. Giorgetti, F. Cugini, F. Paolucci, and P. Castoldi, “OpenFlow and PCE
IEEE Trans. Netw. Serv. Manage., vol. 9, no. 4, pp. 446–458, Dec. 2012. Architectures in Wavelength Switched Optical Networks,” in Proc. 16th Int. Conf. ONDM, 2012,
pp. 1–6.
[66] T. Pan, X. Guo, C. Zhang, W. Meng, and B. Liu, “ALFE: A replacement [94] S. Das, G. Parulkar, and N. McKeown, “Simple unified control for packet
policy to cache elephant flows in the presence of mice flooding,” in Proc. IEEE ICC, Jun. and circuit networks,” in Proc. IEEE/LEOSST Meet., 2009, pp. 147–148.
2012, pp. 2961–2965. [67] O. Ferkouss et al., “A 100 Gig network processor platform for [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
OpenFlow,” in Proc. 7th Int. CNSM, 2011, pp. 1–4. and circuit network convergence with OpenFlow,”
[68] J. C. Mogul and P. Congdon, “Hey, you darned counters!: Get off my
ASIC!” in Proc. 1st Workshop HotSDN, 2012, pp. 25–30. in Pro. OFC/NFOEC, 2010, pp. 1–3.
[69] V. Tanyingyong, M. Hidell, and P. Sjodin, “Improving PC-based [97] S. Das et al., “Application-aware aggregation and traffic engineering
OpenFlow switching performance,” in Proc. ACM/IEEE Symp. ANCS, in a converged packet-circuit network,” in Proc. OFC/NFOEC, 2011, pp. 1–3.
2010, pp. 1–2.
[70] V. Tanyingyong, M. Hidell, and P. Sjodin, “Using hardware classification [98] L. Liu, T. Tsuritani, I. Morita, H. Guo, and J. Wu, “OpenFlow-based
to improve pc-based OpenFlow switching,” in Proc. IEEE 12th Int. Conf. HPSR, 2011, pp. wavelength path control in transparent optical networks: A proof-ofconcept demonstration,” in
215–221. 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- [125] S. Ghorbani and M. Caesar, “Walk the line: Consistent network updates
tion and performance evaluation of OpenFlow-based wavelength path control in transparent with bandwidth guarantees,” in Proc. 1st Workshop HotSDN, 2012, pp. 67–72.
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 [126] M. Reitblatt, N. Foster, J. Rexford, C. Schlesinger, and D. Walker,
“Abstractions for network update,” in Proc. ACM SIGCOMM Conf. Appl., Technol., Archit.,
plane for multi-layer multi-granularity optical networks,” presented at the Optical Fiber Protocols Comput. Commun., 2012, pp. 323–334.
Communication Conference, Los Angeles, CA, USA,
2012, Paper PDP5D.2. [127] M. Reitblatt, N. Foster, J. Rexford, and D. Walker, “Consistent updates
[101] L. Liu et al., “First field trial of an OpenFlow-based unified con- for software-defined networks: Change you can believe in!” in Proc. 10th ACM Workshop
trol plane for multi-layer multi-granularity optical networks,” in Proc. OFC/NFOEC, 2012, pp. HotNets-X, 2011, pp. 7:1–7:6.
1–3. [128] R. McGeer, “A safe, efficient update protocol for OpenFlow networks,”
[102] L. Liu, T. Tsuritani, and I. Morita, “Experimental demonstration of in Proc. 1st Workshop HotSDN, 2012, pp. 61–66.
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. tives for SDN-based cloudnetwork management,” in Proc. 1st Workshop HotSDN, 2012, pp.
[103] L. Liu, T. Tsuritani, and I. Morita, “From GMPLS to PCE/GMPLS 97–102.
to OpenFlow: How much benefit can we get from the technical evolution of control plane in [130] A. Medina, N. Taft, K. Salamatian, S. Bhattacharyya, and C. Diot,
optical networks?” in Proc. 14th ICTON, 2012, pp. 1–4. “Traffic matrix estimation: Existing techniques and new directions,”
ACM SIGCOMM Comput. Commun. Rev., vol. 32, no. 4, pp. 161–174, Oct. 2002.
[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 [131] A. Tootoonchian, M. Ghobadi, and Y. Ganjali, “OpenTM: Traffic matrix
NOMS, 2012, pp. 1143–1150. estimator for OpenFlow networks,” in Passive and Active Measurement.
[105] M. Casado, T. Koponen, S. Shenker, and A. Tootoonchian, “Fabric: A Berlin, Germany: Springer-Verlag, 2010, pp. 201–210. [132] A. Curtis, W. Kim, and P.
retrospective on evolving SDN,” in Proc. 1st Workshop HotSDN, 2012, pp. 85–90. [106] B. Yalagandula, “Mahout: Low-overhead data-
Raghavan et al., “Software-defined internet architecture: Decoupling center traffic management using end-host-based elephant detection,” in
Proc. IEEE INFOCOM, 2011, pp. 1629–1637.
architecture from infrastructure,” in Proc. 11th ACM Workshop Hot Topics Netw., 2012, pp. [133] L. Jose, M. Yu, and J. Rexford, “Online measurement of large traffic
43–48. aggregates on commodity switches,” in Proc. 11th USENIX Conf. HotICE Netw. Serv., 2011,
[107] V. Gudla et al., “Experimental demonstration of OpenFlow control of p. 13.
packet and circuit switches,” presented at the Optical Fiber Communication Conference, San [134] N. Alon, Y. Matias, and M. Szegedy, “The space complexity of approxi-
Diego, CA, USA, 2010, Paper OTuG2. [108] D. Simeonidou, R. Nejabati, and S. Azodolmolky, mating the frequency moments,” in Proc. 28th Annu. ACM STOC, 1996, pp. 20–29.
“Enabling the future
optical Internet with OpenFlow: A paradigm shift in providing intelligent optical network [135] G. Cormode and M. Hadjieleftheriou, “Finding frequent items in data
services,” in Proc. 13th ICTON, 2011, pp. 1–4. streams,” Proc. VLDB Endow., vol. 1, no. 2, pp. 1530–1541, Aug. 2008. [136] A. Kumar, M.
[109] S. Azodolmolky et al., “Integrated OpenFlow-GMPLS control plane: An Sung, J. J. Xu, and J. Wang, “Data streaming algo-
overlay model for software defined packet over optical networks,” Opt. Exp., vol. 19, no. 26, rithms for efficient and accurate estimation of flow size distribution,”
pp. B421–B428, Dec. 2011. SIGMETRICS Perform. Eval. Rev., vol. 32, no. 1, pp. 177–188, Jun. 2004.
[110] Cisco’s One Platform Kit (onePK). [Online]. Available: http://www.
cisco.com/en/US/prod/iosswrel/onepk.html [137] A. Kumar, M. Sung, J. J. Xu, and J. Wang, “Data streaming algo-
[111] T. L. Hinrichs, N. S. Gude, M. Casado, J. C. Mitchell, and S. Shenker, rithms for efficient and accurate estimation of flow size distribution,” in
“Practical declarative network management,” in Proc. 1st ACM WREN, Proc. Joint SIGMETRICS Int. Conf. Meas. Model. Comput. Syst., 2004, pp. 177–188.
2009, pp. 1–10.
[112] N. Foster et al., “Frenetic: A high-level language for OpenFlow net- [138] C. Estan, G. Varghese, and M. Fisk, “Bitmap algorithms for counting
works,” in Proc. Workshop PRESTO, 2010, pp. 6:1–6:6. active flows on high-speed links,” IEEE/ACM Trans. Netw., vol. 14, no. 5, pp. 925–937, Oct.
[113] N. Foster et al., “Frenetic: A network programming language,” 2006.
SIGPLAN Notices, vol. 46, no. 9, pp. 279–291, Sep. 2011. [114] A. Voellmy and P. Hudak, [139] M. Yu, L. Jose, and R. Miao, “Software defined traffic measurement with
“Nettle: A language for configuring routing OpenSketch,” in Proc. 10th USENIX Conf. NSDI, 2013, pp. 29–42.
networks,” in Proc. IFIP TC 2 Working Conf. DSL, 2009, pp. 211–235. [140] P. Fonseca, R. Bennesby, E. Mota, and A. Passito, “A replication compo-
[115] A. Voellmy et al., “Don’t configure the network, program it! nent for resilient OpenFlow-based networking,” in Proc. IEEE NOMS,
Domain-specific programming languages for network systems,” Defense Tech. Inf. Center, 2012, pp. 933–939.
Fort Belvoir, VA, USA, DTIC Doc. Tech. Rep., [141] D. Levin, A. Wundsam, B. Heller, N. Handigol, and A. Feldmann,
2010. “Logically centralized?: State distribution trade-offs in software defined networks,” in Proc. 1st
[116] A. Voellmy and P. Hudak, “Nettle: Taking the sting out of programming Workshop HotSDN, 2012, pp. 1–6.
network routers,” in Proc. 13th Int. Conf. PADL, 2011, pp. 235–249. [142] A. Tootoonchian and Y. Ganjali, “HyperFlow: A distributed control
[117] A. Voellmy, H. Kim, and N. Feamster, “Procera: A language for high- plane for OpenFlow,” in Proc. INM/WREN, 2010, p. 3.
level reactive network control,” in Proc. 1st Workshop HotSDN, 2012, pp. 43–48. [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.
[118] T. Hinrichs, N. Gude, M. Casado, J. Mitchell, and S. Shenker, “Express- [144] P. Porras et al., “A security enforcement kernel for OpenFlow networks,”
ing and enforcing flow-based network security policies,” Univ. Chicago, Chicago, IL, USA, in Proc. 1st Workshop HotSDN, 2012, pp. 121–126.
Tech. Rep, 2008. [145] E. Al-Shaer and S. Al-Haj, “FlowChecker: Configuration analysis and
[119] A. D. Ferguson, A. Guha, C. Liang, R. Fonseca, and S. Krishnamurthi, verification of federated OpenFlow infrastructures,” in Proc. 3rd ACM Workshop Assurable
“Hierarchical policies for software defined networks,” in Proc. 1st Workshop HotSDN, 2012, Usable Security SafeConfig, 2010, pp. 37–44.
pp. 37–42. [146] E. Al-Shaer, W. Marrero, A. El-Atawy, and K. ElBadawi, “Network con-
[120] C. Monsanto, N. Foster, R. Harrison, and D. Walker, “A compiler and figuration in a box: Towards end-to-end verification of network reachability and security,” in Proc.
run-time system for network programming languages,” in Proc. 39th Annu. ACM 17th IEEE ICNP, 2009, pp. 123–132.
SIGPLAN-SIGACT Symp. POPL, 2012, pp. 217–230. [147] P. Perešíni and M. Canini, “Is your OpenFlow application correct?” in
[121] S. Gutz, A. Story, C. Schlesinger, and N. Foster, “Splendid isolation: A Proc. ACM CoNEXT Student Workshop, 2011, pp. 18:1–18:2.
slice abstraction for software-defined networks,” in Proc. 1st Workshop HotSDN, 2012, pp. [148] M. Canini, D. Kostic, J. Rexford, and D. Venzano, “Automating the
79–84. testing of OpenFlow applications,” presented at the 1st International Workshop Rigorous
[122] C. Monsanto, J. Reich, N. Foster, J. Rexford, and D. Walker, “Composing Protocol Engineering, Portland, OR, USA, 2011. [149] M. Canini, D. Venzano, P. Perešíni, D.
software-defined networks,” in Proc. 10th USENIX Conf. NSDI, 2013, pp. 1–14. Kosti´ c, and J. Rexford, “A nice
way to test OpenFlow applications,” in Proc. 9th USENIX Conf. NSDI,
[123] A. Voellmy, J. Wang, Y. R. Yang, B. Ford, and P. Hudak, “Maple: Sim- 2012, p. 10.
plifying SDN programming using algorithmic policies,” in Proc. ACM SIGCOMM Conf., 2013, [150] M. Ku´ zniar, M. Canini, and D. Kosti´ c, “OFTEN testing OpenFlow net-
pp. 87–98. works,” in Proc. 1st EWSDN, Oct. 2012, pp. 54–60. [151] H. Mai et al., “Debugging the data
[124] R. Wang, D. Butnariu, and J. Rexford, “OpenFlow-based server load plane with anteater,” ACM
balancing gone wild,” in Proc. 11th USENIX Conf. Hot-ICE Netw. Serv., SIGCOMM Comput. Commun. Rev., vol. 41, no. 4, pp. 290–301, Aug. 2011.
2011, p. 12.
XIA et al.: A SURVEY ON SOFTWARE-DEFINED NETWORKING 49
[152] A. Khurshid, W. Zhou, M. Caesar, and P. B. Godfrey, “VeriFlow: Ver- [179] M. Mendonca, S. Seetharaman, and K. Obraczka, “A flexible
ifying network-wide invariants in real time,” in Proc. 1st Workshops HotSDN, 2012, pp. 49–54, in-network IP anonymization service,” in Proc. IEEE ICC, 2012, pp. 6651–6656.
New York, NY, USA.
[153] A. Khurshid, W. Zhou, M. Caesar, and P. B. Godfrey, “Veriflow: [180] J. Fu, P. Sjödin, and G. Karlsson, “Intra-domain routing convergence
Verifying network-wide invariants in real time,” SIGCOMM Comput. Commun. Rev., vol. 42, with centralized control,” Comput. Netw., vol. 53, no. 18, pp. 2985–2996, Dec. 2009.
no. 4, pp. 467–472, Sep. 2012. [154] A. Khurshid, X. Zou, W. Zhou, M. Caesar, and P. B.
Godfrey, “VeriFlow: [181] K. K. Lakshminarayanan, I. Stoica, S. Shenker, and J. Rexford, “Routing
Verifying network-wide invariants in real time,” in Proc. 10th USENIX Conf. NSDI, 2013, pp. as a service,” EECS Dept., Univ. California, Berkeley, CA, USA, Tech. Rep.
15–28. UCB/EECS-2006-19, Feb. 2006. [182] P. Pisa et al., “OpenFlow and Xen-based virtual network
[155] B. Heller, R. Sherwood, and N. McKeown, “The controller placement migration,” in
problem,” in Proc. 1st Workshop HotSDN, 2012, pp. 7–12. Communications: Wireless in Developing Countries and Networks of the Future. Berlin,
[156] Z. Cai, “Maestro: Achieving scalability and coordination in centralized Germany: Springer-Verlag, 2010, pp. 170–181. [183] M. Koerner and O. Kao, “Multiple service
network control plane,” Ph.D. dissertation, Rice Univ., Houston, TX, USA, 2011. load-balancing with Open-
Flow,” in Proc. 13th IEEE Int. Conf. HPSR, 2012, pp. 210–214.
[157] Z. Cai, A. L. Cox, and T. E. Ng, “Maestro: A system for scalable [184] G. Wang, T. E. Ng, and A. Shaikh, “Programming your network at run-
OpenFlow control,” Rice Univ., Houston, TX, USA, Tech. Rep. TR 10-08, Dec. 2010. time for big data applications,” in Proc. 1st Workshop HotSDN, 2012, pp. 103–108.
[158] A. Tootoonchian, S. Gorbunov, Y. Ganjali, M. Casado, and R. Sherwood, [185] Z. Kerravala, “As the value of enterprise networks escalates, so
“On controller performance in software-defined networks,” in Proc. 2nd USENIX Conf. does the need for configuration management,” Enterprise Computing & Networking, The
Hot-ICE Netw. Serv., 2012, p. 10. Yankee Group Report, Boston, MA, USA,
[159] A. Voellmy and J. Wang, “Scalable software defined network con- 2004.
trollers,” in Proc. ACM SIGCOMM Conf. Appl., Technol., Archit., Protocols Comput. [186] N. Handigol, B. Heller, V. Jeyakumar, D. Maziéres, and N. McKeown,
Commun., 2012, pp. 289–290. “Where is the debugger for my software-defined network?” in Proc. 1st Workshop HotSDN, 2012,
[160] A. Voellmy, B. Ford, P. Hudak, and Y. R. Yang, “Scaling software- pp. 55–60.
defined network controllers on multicore servers,” Comput. Sci., Yale Univ., New Haven, CT, [187] S. Sharma, D. Staessens, D. Colle, M. Pickavet, and P. Demeester, “En-
USA, Yale CS TR 1468, 2012. [161] Beacon. abling fast failure recovery in OpenFlow networks,” in Proc. 8th Int. Workshop DRCN, 2011,
[Online]. Available: https://openflow.stanford.edu/display/ Beacon/Home [162] pp. 164–171.
M. Jarschel et al., “Modeling and performance evaluation of an [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.
OpenFlow architecture,” in Proc. 23rd ITCP, 2011, pp. 1–7.
[163] M. Yu, J. Rexford, M. J. Freedman, and J. Wang, “Scalable flow- [189] G. Gibb, H. Zeng, and N. McKeown, “Outsourcing network functional-
based networking with DIFANE,” in Proc. ACM SIGCOMM, 2010, pp. 351–362. [164] A. R. ity,” in Proc. 1st Workshop HotSDN, 2012, pp. 73–78.
Curtis et al., “DevoFlow: Scaling flow management for high- [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.
performance networks,” SIGCOMM Comput. Commun. Rev., vol. 41, no. 4, pp. 254–265, 2011.
Aug. 2011. [191] J. Naous, R. Stutsman, D. Mazieres, N. McKeown, and N. Zeldovich,
[165] S. H. Yeganeh and Y. Ganjali, “Kandoo: A framework for efficient “Delegating network security with more information,” in Proc. 1st ACM WREN, 2009, pp.
and scalable offloading of control applications,” in Proc. 1st Workshop HotSDN, 2012, pp. 19–26.
19–24. [192] C. Rigney, A. Rubens, W. Simpson, and S. Willens, Remote Authenti-
[166] Cbench (Controller Benchmarker). [Online]. Available: http://www. cation Dial in User Service (RADIUS), Jun. 2000. [Online]. Available:
openflow.org/wk/index.php/Oflops http://tools.ietf.org/rfc/rfc2865.txt
[167] M. Jarschel, F. Lehrieder, Z. Magyari, and R. Pries, “A flexible [193] Y. Yamasaki, Y. Miyamoto, J. Yamato, H. Goto, and H. Sone, “Flexible
OpenFlow-controller benchmark,” in Proc. EWSDN, 2012, pp. 48–53. access management system for campus VLAN based on OpenFlow,” in
[168] R. Alimi, R. Penno, and Y. Yang, ALTO Protocol, Feb. 2013, Proc. IEEE/IPSJ 11th Int. SAINT, 2011, pp. 347–351.
Internet Draft. [Online]. Available: http://tools.ietf.org/id/ [194] S. Kinoshita, T. Watanabe, J. Yamato, H. Goto, and H. Sone, “Imple-
draft-ietf-alto-protocol-14.txt mentation and evaluation of an OpenFlow-based access control system for wireless LAN
[169] V. Gurbani, M. Scharf, T. Lakshman, V. Hilt, and E. Marocco, “Abstract- roaming,” in Proc. 36th Annu. COMPSACW, 2012, pp. 82–87.
ing network state in Software Defined Networks (SDN) for rendezvous services,” in Proc.
IEEE ICC, 2012, pp. 6627–6632. [195] A. Ramachandran, Y. Mundada, M. Tariq, and N. Feamster, “Secur-
[170] E. Kissel, G. Fernandes, M. Jaffee, M. Swany, and M. Zhang, “Driving ing enterprise networks using traffic tainting,” Georgia Inst. Technol., Atlanta, GA, USA, Tech.
software defined networks with XSP,” in Proc. Workshop SDN/IEEE Int. Conf. Commun., 2012, Rep. GTCS-09-15, 2009. [196] N. Feamster et al., “Decoupling policy from configuration in
pp. 6616–6621. campus
[171] E. Keller and J. Rexford, “The “Platform as a service” model for net- and enterprise networks,” in Proc. 17th IEEEWorkshop LANMAN, 2010, pp. 1–6.
working,” in Proc. INM/WREN, 2010, p. 4.
[172] N. Handigol et al., “Plug-n-Serve: Load-balancing web traffic us- [197] A. Nayak, A. Reimers, N. Feamster, and R. Clark, “Resonance: Dynamic
ing OpenFlow,” in Proc. ACM SIGCOMM Demo, Barcelona, Spain, access control for enterprise networks,” in Proc. 1st ACMWorkshop Res. Enterprise Netw., 2009,
2009. [Online]. Available: http://conferences.sigcomm.org/sigcomm/ pp. 11–18.
2009/demos/sigcomm-pd-2009-final26.pdf [173] K.-K. Yap et al., “Blueprint for introducing [198] N. Chowdhury and R. Boutaba, “Network virtualization: State of
innovation into wireless the art and research challenges,” IEEE Commun. Mag., vol. 47, no. 7, pp. 20–26, Jul. 2009.
mobile networks,” in Proc. 2nd ACM SIGCOMMWorkshop VISA, 2010, pp. 25–32. [174] K.-K.
Yap et al., “OpenRoads: Empowering research in mobile net- [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.
works,” SIGCOMMComput. Commun. Rev., vol. 40, no. 1, pp. 125–126, Jan. 2010.
[200] D. Turull, M. Hidell, and P. Sjodin, “libNetVirt: The network virtualiza-
[175] K. Yap, S. Katti, G. Parulkar, and N. McKeown, “Delivering capacity tion library,” in Proc. IEEE ICC, 2012, pp. 5543–5547.
for the mobile internet by stitching together networks,” in Proc. ACM Workshop Wireless [201] R. Sherwood et al., “Flowvisor: A network virtualization layer,”
Students, 2010, pp. 41–44. OpenFlow Switch Consortium, OPENFLOW-TR-2009-1, 2009. [Online]. Available:
[176] L. Suresh, J. Schulz-Zander, R. Merz, A. Feldmann, and T. Vazao, http://archive.openflow.org/downloads/technicalreports/ openflow-tr-2009-1-flowvisor.pdf [202]
“Towards programmable enterprise WLANS with Odin,” in Proc. 1st Workshop HotSDN, 2012, R. Sherwood et al., “Can the production network be the testbed?” in
pp. 115–120.
[177] A. Wundsam, D. Levin, S. Seetharaman, and A. Feldmann, “OFRewind: Proc. 9th USENIX Conf. OSDI, 2010, pp. 1–6.
Enabling record and replay troubleshooting for networks,” in Proc. USENIX Annu. Tech. [203] R. Sherwood et al., “Carving research slices out of your production
Conf., 2011, p. 29. networks with OpenFlow,” ACM SIGCOMM Comput. Commun. Rev.,
[178] J. H. Jafarian, E. Al-Shaer, and Q. Duan, “OpenFlow random vol. 40, no. 1, pp. 129–130, Jan. 2010. [204] Y. Yiakoumis, K.-K. Yap, S. Katti, G. Parulkar,
host mutation: Transparent moving target defense using software defined networking,” in Proc. and N. McKeown, “Slic-
1st Workshop HotSDN, 2012, pp. 127–132. 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 [235] JGN-X (JGN-eXtreme). [Online]. Available: http://www.jgn.nict.go.jp/
networking research,” IEEE Commun. Surveys Tuts., vol. 14, no. 1, pp. 3–20, Dec. 2012. english/index.html
[236] Future Internet Testbeds Experimentation Between Brazil and Europe
[206] D. Staessens, S. Sharma, D. Colle, M. Pickavet, and P. Demeester, “Soft- (FIBRE). [Online]. Available: http://www.fibre-ict.eu/ [237] R. Riggio, T. Rasheed, and F.
ware defined networking: Meeting carrier grade requirements,” in Proc. 18th IEEE Workshop Granelli, “Empower: A testbed for network
LANMAN, 2011, pp. 1–6. function virtualization research and experimentation,” in Proc. IEEE SDN4FNS, Nov. 2013,
[207] T. Benson, A. Akella, A. Shaikh, and S. Sahu, “CloudNaaS: A cloud pp. 1–5.
networking platform for enterprise applications,” in Proc. 2nd ACM SOCC, 2011, pp. 8:1–8:13. [238] U. Holzle, OpenFlow @ Google, Apr. 2012. [Online]. Available: http://
www.opennetsummit.org/archives/apr12/hoelzle-tue-openflow.pdf [239] B. Lantz, B. Heller,
[208] A. Tavakoli, M. Casado, T. Koponen, and S. Shenker, “Applying and N. McKeown, “A network in a laptop: Rapid pro-
NOX to the datacenter,” in Proc. HotNets, New York, NY, USA, totyping for software-defined networks,” in Proc. 9th ACM SIGCOMM Workshop HotNets-IX, 2010,
2009. [Online]. Available: http://conferences.sigcomm.org/hotnets/ pp. 19:1–19:6.
2009/papers/hotnets2009-final103.pdf [240] L. Dong, F. Jia, and W. Wang, “Definition and implementation of logical
[209] M. Moshref, M. Yu, A. Sharma, and R. Govindan, “Scalable rule man- function blocks compliant to ForCES specification,” in Proc. 15th ICON,
agement for data centers,” in Proc. 10th USENIX Conf. NSDI, 2013, pp. 157–170. 2007, pp. 531–536.
[241] Z. Wang, T. Tsou, J. Huang, X. Shi, and X. Yin, Analysis of
[210] Q. Zhang, L. Cheng, and R. Boutaba, “Cloud computing: State-of-the-art Comparisons Between OpenFlow and ForCES, Mar. 2012, Internet Draft. [Online]. Available:
and research challenges,” J. Internet Serv. Appl., vol. 1, no. 1, pp. 7–18, May 2010. http://tools.ietf.org/id/draft-wang-forcescompare-openflow-forces-01.txt
[211] Q. Li, J. Huai, J. Li, T. Wo, and M. Wen, “HyperMIP: Hypervisor [242] E. Haleplidis, S. Denazis, O. Koufopavlou, J. Salim, and J. Halpern,
controlled mobile IP for virtual machine live migration across networks,” in Proc. 11th IEEE “Software-defined networking: Experimenting with the control to forwarding plane interface,”
HASE Symp., 2008, pp. 80–88. in Proc. EWSDN, 2012, pp. 91–96.
[212] P. Raad et al., “Achieving sub-second downtimes in internet-wide virtual [243] P. Lin, J. Bi, and H. Hu, “ASIC: An architecture for scalable intra-domain
machine live migrations in LISP networks,” in Proc. IFIP/IEEE Int. Symp. IM, 2013, pp. control in OpenFlow,” in Proc. 7th Int. Conf. Future Internet Technol.,
286–293. 2012, pp. 21–26.
[213] M. Coudron, S. Secci, G. Maier, G. Pujolle, and A. Pattavina, “Boosting [244] M. R. Nascimento, C. E. Rothenberg, M. R. Salvador, and
cloud communications through a crosslayer multipath protocol architecture,” in Proc. IEEE M. F. Magalhães, “QuagFlow: Partnering Quagga with OpenFlow,”
SDN4FNS, Nov. 2013, pp. 1–8. [214] OpenDaylight. [Online]. Available: SIGCOMM Comput. Commun. Rev., vol. 40, no. 4, pp. 441–442, Aug. 2010. [245] M. R.
http://www.opendaylight.org/ [215] F. Hao, T. Lakshman, S. Mukherjee, and H. Song, “Enhancing Nascimento et al., “Virtual routers as a service: The RouteFlow
dynamic
cloud-based services using network virtualization,” in Proc. 1st ACM Workshop Virtualized approach leveraging software-defined networks,” in Proc. 6th Int. CFI Technol., 2011, pp.
Infrastruct. Syst. Archit., 2009, pp. 37–44. 34–37.
[216] B. Boughzala, R. Ben Ali, M. Lemay, Y. Lemieux, and O. Cherkaoui, [246] Y. Nakagawa, K. Hyoudou, and T. Shimizu, “A management method of
“OpenFlow supporting inter-domain virtual machine migration,” in IP multicast in overlay networks using openflow,” in Proc. 1st Workshop HotSDN, 2012, pp.
Proc. 8th Int. Conf. WOCN, 2011, pp. 1–7. 91–96.
[217] J. Matias, E. Jacob, D. Sanchez, and Y. Demchenko, “An OpenFlow [247] K.-K. Yap, T.-Y. Huang, B. Dodson, M. S. Lam, and N. McKeown, “To-
based network virtualization framework for the cloud,” in Proc. 3rd Int. Conf. CloudComp wards software-friendly networks,” in Proc. 1st ACM APSys Workshop,
Technol. Sci., 2011, pp. 672–678. 2010, pp. 49–54.
[218] V. Mann, A. Vishnoi, K. Kannan, and S. Kalyanaraman, “CrossRoads: [248] T.-Y. Huang et al., “PhoneNet: A phone-to-phone network for
Seamless VM mobility across data centers through software defined networking,” in Proc. group communication within an administrative domain,” in Proc. 2nd ACM SIGCOMM
IEEE NOMS, 2012, pp. 88–96. Workshop Netw., Syst., Appl. MobiHeld, 2010, pp. 27–32.
[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. [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.
[220] E. Keller, S. Ghorbani, M. Caesar, and J. Rexford, “Live migration of an 7th Workshop MW4NG Internet Comput., 2012, pp. 3:1–3:6.
entire network (and its hosts),” in Proc. 11th ACM Workshop HotNets-
XI, 2012, pp. 109–114. [250] D. Kotani, K. Suzuki, and H. Shimonishi, “A design and implementation
[221] H. Qian, X. Huang, and C. Chen, “Swan: End-to-end orchestration for of OpenFlow controller handling IP multicast with fast tree switching,” in Proc. IEE/IPSJ Int.
cloud network and wan,” in Proc. IEEE 2nd Int. Conf. CloudNet, Nov. SAINT, 2012, pp. 60–67.
2013, pp. 236–242. [251] R. Ravindran, X. Liu, A. Chakraborti, X. Zhang, and G. Wang, “Towards
[222] N. McKeown et al., “OpenFlow: Enabling innovation in campus net- software defined icn based edge-cloud services,” in Proc. IEEE 2nd Int. Conf. CloudNet, Nov.
works,” SIGCOMM Comput. Commun. Rev., vol. 38, no. 2, pp. 69–74, Mar. 2008. 2013, pp. 227–235. [252] T. Li, N. Van Vorst, R. Rong, and J. Liu, “Simulation studies of
[223] OpenFlow Switch Consortium. [Online]. Available: http://www. OpenFlow-based in-network caching strategies,” in Proc. 15th CNS Symp., 2012, pp.
openflow.org/ [224] D. Mattos et al., “OMNI: OpenFlow management infrastructure,” in 12:1–12:7.
[253] G. Stabler, A. Rosen, S. Goasguen, and K.-C. Wang, “Elastic IP and
Proc. Int. Conf. NOF, 2011, pp. 52–56. security groups implementation using OpenFlow,” in Proc. 6th Int. Workshop VTDC, 2012, pp.
[225] Trema. [Online]. Available: http://trema.github.com/trema/ [226] Ryu. [Online]. Available: 53–60.
http://osrg.github.com/ryu/ [227] Floodlight. [Online]. Available: http://www.projectfloodlight.org/ [228] [254] J. Rubio-Loyola et al., “Scalable service deployment on software-
N. Gude et al., “NOX: Towards an operating system for networks,” defined networks,” IEEE Commun. Mag., vol. 49, no. 12, pp. 84–93, Dec. 2011.
SIGCOMMComput.Commun. Rev., vol. 38, no. 3, pp. 105–110, Jul. 2008. [229] NOX. [255] T. Nadeau and P. Pan, Framework for Software Defined Networks,
[Online]. Available: http://www.noxrepo.org/ [230] K.-K. Yap et al., “The Stanford OpenRoads Oct. 2011, Internet Draft. [Online]. Available: http://tools.ietf.org/id/
deployment,” in Proc. 4th draft-nadeau-sdn-framework-01.txt
ACM Int. WINTECH, 2009, pp. 59–66. [256] ETSI Industry Specification Group for Network Functions Virtualization
[231] S. Jain et al., “4: Experience with a globally-deployed software defined (ISG NFV), Network Functions Virtualisation, An Introduction, Benefits, Enablers, Challenges
WAN,” in Proc. ACM SIGCOMM Conf., 2013, pp. 3–14. & Call for Action, Oct. 2012, White Paper. [Online]. Available:
[232] N. Feamster and J. Rexford, “Getting students’ hands dirty with clean- http://www.cisco.com/en/US/solutions/collateral/
slate networking,” in Proc. SIGCOMM Educ. Workshop, Toronto, ON, Canada, 2011. [Online]. ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360.pdf [257] M. Kuzniar, P. Peresini,
Available: http://edusigcomm.info.ucl.ac.be/ M. Canini, D. Venzano, and D. Kostic, “A SOFT
pmwiki/uploads/Workshop2011/20110430002/clean-slate.pdf [233] L. Peterson, T. Anderson, D. way for openflow switch interoperability testing,” in Proc. 8th Int. Conf. Emerging Netw. Exp.
Culler, and T. Roscoe, “A blueprint for Technol., 2012, pp. 265–276.
introducing disruptive technology into the Internet,” ACM SIGCOMM Comput. Commun. [258] M. Kind, F. Westphal, A. Gladisch, and S. Topp, “SplitArchitecture:
Rev., vol. 33, no. 1, pp. 59–64, Jan. 2003. [234] Federated E-Infrastructure Dedicated to Applying the software defined networking concept to carrier networks,” in Proc. WTC, 2012,
European Researchers pp. 1–6.
Innovating in Computing Network Architectures (FEDERICA). [Online]. Available: [259] P. Dely, A. Kassler, and N. Bayer, “Openflow for wireless mesh net-
http://www.fp7-federica.eu/ 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 Dusit Niyato received the B.Eng. degree in computer engineering
sensor networks,” in Proc. ICCSNT, 2011, vol. 1, pp. 594–600. from King Mongkut’s Institute of Technology Ladkrabang, Bangkok,
[261] A. Mahmud, R. Rahmani, and T. Kanter, “Deployment of flow-sensors Thailand, in 1999 and the Ph.D. degree in electrical and computer
in internet of things’ virtualization via OpenFlow,” in Proc. 3rd FTRA Int. Conf. MUSIC, 2012, engineering from the University of Manitoba, Winnipeg, MB,
pp. 195–200. 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
Wenfeng Xia received the B.S. degree in computer science from management in cognitive radio networks and broadband wireless
the University of Science and Technology of China, Hefei, China, in access networks.
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.
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.
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.