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

1, PRIMER TRIMESTRE 2015 27

Una Encuesta sobre el Software de fi nida Redes

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

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

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

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

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

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

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

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

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

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

Objetos Digitales identi fi cador 10.1109 / COMST.2014.2330903

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

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

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

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

C. Desafíos SDN

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

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

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

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

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

D. Modelo de Referencia SDN

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

dos subsecciones. dispositivos de conmutación.

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

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

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

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

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

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

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

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

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

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

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

D. Seguridad de Red

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TABLA VI SDN R
ELACIONADAS R ESEARCHES

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

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

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

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

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

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

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

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

NEE y destacó bene fi cios de SDN en ofrecer una mayor con fi guración, de hardware nuevos es necesario.
XIA et al .: Una encuesta sobre Software-Defined Networking
TABLA VII C ACTUAL I
NVESTIGACIÓN P ROYECTOS
• SDN se desarrolló originalmente para las redes basadas en IP en los
campus. Por lo tanto, la ampliación de cobertura ubicua de SDN requiere uni
fi cación y la integración con tecnologías avanzadas en la transmisión
inalámbrica y óptica (es decir, SDR y GMPLS, respectivamente). Estas
tecnologías dan oportunidades para un controlador SDN para tener un control
generalizado de todos los parámetros y el comportamiento de la red.
Integrado con estas tecnologías, SDN obtendrá un control más adecuado de
la infraestructura para lograr la utilización de recursos de infraestructura más
e fi ciente.
• Para mejorar ventajas de desacoplar el plano de control desde el plano de datos,
un expresivo y completa interfaz de alto nivel para el acceso y los dispositivos de
conmutación de control debe ser proporcionado para facilitar aún más con la red
fi configuración y gestión. Habilidades de diversas áreas de la informática, como
la teoría del lenguaje de programación, métodos formales y sistemas distribuidos,
se deben aplicar para permitir la generación automática de lenguaje de alto nivel
de las políticas descritas en las normas de bajo nivel y sin conflictos y garantizar
la consistencia durante el procedimiento de actualización de reglas.
• técnicas de medición de la red también son útiles para la recolección de estado de
la red. Para las redes a gran escala, varios controladores son necesarios.
algoritmos de sincronización estudiados en sistemas distribuidos y sistemas de
bases de datos pueden ser adoptados para sincronizar el estado de la red
percibidas entre múltiples controladores.
• Un controlador SDN tiene que manejar una enorme cantidad de eventos de
interacción con sus dispositivos de conmutación asociados. Para garantizar la e fi
ciencia de las operaciones de la red, los métodos de optimización de software y
análisis algoritmo se pueden utilizar para mejorar el rendimiento del controlador, y
debidamente arquitectura diseñada puede ayudar a disminuir la frecuencia de
solicitud.
• SDN proporciona una plataforma para implementar diversas aplicaciones SDN. SDN
aplicaciones pueden acceder a una vista de red y la capa cruzada mundial de
información para tomar mejores decisiones de operación de la red. SDN
controladores aseguran que éstos de-
45
cisiones se llevan a cabo adecuadamente en la capa de infraestructura. Sin embargo, se
requiere la participación de los desarrolladores de software para convertir las ideas
innovadoras de soluciones que pueden traer beneficios económicos, sociales y
medioambientales.
C. Investigación Future
Muchos de los retos SDN todavía necesitan más atención de la investigación y muchas
organizaciones han iniciado proyectos de investigación en varios aspectos de la SDN
como se muestra en la Tabla VII. En los párrafos siguientes se indican las cuestiones
abiertas que cubren todo el ciclo de vida de SDN de la normalización, implementación,
despliegue:
• La estandarización de SDN: Siendo la aplicación de facto del concepto
SDN, OpenFlow es de ninguna manera la única aplicación SDN. IETF
también ha lanzado un marco SDN [255]. El ETSI Industria Speci fi
cación Group (ISG) para las funciones de red de virtualización (NFV) se
ha formado recientemente para promover NFV, que es altamente
complementaria a SDN [256]. Al vencimiento de las implementaciones
SDN, una comparación exhaustiva entre todas las aplicaciones posibles
del SDN debe llevarse a cabo. En la capa de control, hemos sido
testigos de muchos proyectos dirigidos a problemas similares que
utilizan enfoques similares. Sin embargo, una solución hablaba aún no
ha surgido. La fragmentación en funciones del controlador y API
proporcionadas por los controladores puede ser una barrera de potencial
para el desarrollo comercial de SDN. Además, OpenFlow especí fi
cación evoluciona rápidamente y permite diferentes interpretaciones. Por
lo tanto,
• Implementación de SDN: El enfoque actual SDN de desacoplamiento de plano de
control completamente de plano de datos sugiere una eliminación total de cualquier
protocolos de enrutamiento a bordo de los dispositivos de conmutación. Este
enfoque puede ser demasiado idealista, lo que puede impedir SDN de la
adaptación generalizada. Una inmediata y directa a transformar idealista SDN se
46 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 1, PRIMER TRIMESTRE 2015
necesitará una inversión de riesgo mucho para reemplazar todos los dispositivos de red
convencionales. En la fase de transición de los dispositivos de conmutación
convencionales para desacoplado totalmente dispositivos de conmutación SDN,
dispositivos de conmutación semi-desacoplado, que se ejecutan los protocolos de
enrutamiento y también se puede controlar de forma remota son útiles para suavizar la
evolución a SDN idealista. Existen algunos otros inconvenientes de diseño en la
aplicación SDN actual. Por ejemplo, en OpenFlow, un largo de cabecera se utiliza para
hacer coincidir para permitir un control más granular, es decir, doce tuplas en OpenFlow
1,0 y más en OpenFlow 1.1. Esto puede requerir más espacio de almacenamiento en
regla y más tiempo en las operaciones de búsqueda. Además, el diseño de proxy
ampliamente utilizado entre los dispositivos de conmutación y el controlador ya ha
demostrado un efecto negativo en el rendimiento [152], [204].
• El despliegue de SDN: El estudio adicional de SDN en redes de operadores con
los requisitos de grado carrier [258], redes de malla inalámbrica con movilidad
rápida cliente [259], y las redes de sensores inalámbricos que requieren alta
fiabilidad y asequibilidad [260], [261] es también necesario para el despliegue
de ancho de SDN.
Por último, cabe destacar que estas cuestiones señaladas aquí no pretenden ser
exhaustivas. Sin embargo, muchos más problemas aún no se han atendido en esta zona
activa y prometedora de la SDN.
R EFERENCIAS
[1] Las predicciones de IDC 2013: competir en la plataforma tercero, IDC,
Framingham, MA, EE.UU., noviembre de 2012, Libro Blanco. [En línea]. Disponible:
http://www.idc.com/research/Predictions13/downloadable/238044.pdf [2] P. Mell y T. Grance, “El
NIST definición de computación en la nube (borrador),”
NIST Special Publication, vol. 800-145, p. 7, 2011.
[3] J. Gantz y D. Reinsel, “extraer valor de caos,” IDC,
Framingham, MA, EE.UU., Libro Blanco, Jun. 2011. [En línea]. Disponible:
http://www.emc.com/collateral/analyst-reports/idc-extracting-valuefrom-chaos-ar.pdf [4] J.
Manyika et al., “Big data: La próxima frontera de la innovación,
la competencia y la productividad “, McKinsey Global Inst., Mumbai, India, pp. 1-137, 2011.
[5] P. y D. Cesar Geerts, “Pasado, presente y futuro de la televisión social: una cate-
gorization,”en Proc. IEEE CCNC, 2011, pp. 347-351.
[6] Y. Jin, X. Liu, Y. Wen, y J. Cai, “interacción de pantalla Inter para la sesión
reconocimiento y transferencia basada en la red multimedia nube centrada”en Proc. IEEE ISCAS, 2013,
pp. 877-880.
[7] Y. Jin, Y. Wen, G. Shi, G. Wang, y A. Vasilakos “, CoDaaS:
Una plataforma experimental nube centrada de entrega de contenido para el contenido generado por el
usuario,”en Proc. En t. Conf. Comput. Netw. Commun., 2012, pp. 934-938.
[8] J. Dean y S. Ghemawat, “MapReduce: Simpli fi procesamiento de datos ed en
racimos grandes,” Commun. ACM, vol. 51, no. 1, pp 107-113, enero de 2008. [9] “Cisco Visual
Networking Index:. Global móvil tráfico de datos fi c pronóstico UP-
fecha, 2013-2018 “, San José, CA, EE.UU., Libro Blanco, febrero de 2014. [10] Facebook
línea de tiempo. [En línea]. Disponible: http://newsroom.fb.com/
Cronología
[11] “Cisco Visual Networking Index: El Tiempo y la metodología,
2011-2016 “, San José, CA, EE.UU., Libro Blanco, mayo de 2012. [En línea]. Disponible:
http://www.cisco.com/en/US/solutions/collateral/ns341/
ns525 / ns537 / ns705 / ns827 / white_paper_c11-481360.pdf [12] H. Kim, T. Benson, A.
Akella, y N. Feamster, “La evolución de NET
con fi guración de trabajo: La historia de dos campus,”en Proc. ACM SIGCOMM Conf. Meas de
Internet. Conf., 2011, pp. 499-514.
[13] “¿Qué hay detrás de la red de inactividad?” Sunnyvale, CA, EE.UU., mayo de 2008,
Papel blanco. [En línea]. Disponible: https://www-935.ibm.com/services/ sg / GTS / pdf /
200249.pdf
[14] H. Xie, Y. Yang, A. Krishnamurthy, Y. Liu, y A. Silberschatz, “P4P:
portal de proveedores de aplicaciones” ACM SIGCOMM Comput. Commun. Rdo., vol. 38, no. 4, pp.
351-362, agosto de de 2008.
[15] T.-Y. Huang, N. Handigol, B. Heller, N. McKeown, y R. Johari, “Con-
fusionada, tímida, e inestable: Escoger un vídeo de velocidad de transmisión es duro “, en
Proc. ACM Conf. Meas de Internet. Conf., 2012, pp. 225-238.
[16] X. Chen, ZM Mao, y J. Van Der Merwe, “ShadowNet: Una plataforma para
evolución de la red rápida y segura “, en Proc. Conf. USENIX Annu. Tech. Conf., 2009, p. 3.
[17] R. Perlman, “RBridges: enrutamiento transparente”, en Proc. 23 Annu. Articulación
Conf. IEEE INFOCOM, 2004, vol. 2, pp. 1211-1218.
[18] R. Perlman, D. Eastlake, III, S. Gai, D. Dutt, y A. Ghanwani, Routing
(puentes): RBridges. Protocolo Base especí fi cación, jul 2011, RFC 6325. [En línea].
Disponible: http://tools.ietf.org/rfc/rfc6325.txt [19] J. Pan, S. Pablo, y R. Jain, “Un estudio de la
investigación sobre el futuro In-
arquitecturas Ternet” IEEE Commun. Revista., vol. 49, no. 7, pp. 26-36, Jul. 2011. [20] L.
Zhang et al., “Proyecto denominado Redes de Datos (NDN),” Relatório
Técnico NDN-0001, Xerox Palo Alto Research Center-PARC, Palo Alto, CA, EE.UU., 2010.
[21] A Campbell et al., “Un estudio de las redes programables,” ACM
SIGCOMM Comput. Commun. Rdo., vol. 29, no. 2, pp. 7-23, abril de 1999. [22] L. Popa, A.
Ghodsi, y I. Stoica, “HTTP como el estrecho de la cintura de la
Internet del futuro “, en Proc. Noveno ACM SIGCOMM Workshop Hotnets-IX,
2010, pp. 6: 1-6: 6.
[23] “fi nida en red Software-de: La nueva norma para redes”, Palo Alto,
CA, EE.UU., Libro Blanco, abril de 2012. [En línea]. Disponible: https: // www.
opennetworking.org/images/stories/downloads/white-papers/wp-sdnnewnorm.pdf
[24] T. Nadeau y P. Pan, Software Dirigido Redes planteamiento del problema,
De octubre de 2011, Proyecto de Internet. [En línea]. Disponible: http://www.cisco. com / es / es /
soluciones / garantía / ns341 / ns525 / ns537 / ns705 / ns827 / white_paper_c11-481360.pdf [25]
Open Networking Summit.
[En línea]. Disponible: http: // www.
opennetsummit.org/archives/oct11/site/tutorials.html [26] Temas de actualidad en Software de fi
nido en red (HotSDN). [En línea]. Aprovechar-
poder: http://conferences.sigcomm.org/sigcomm/2012/hotsdn.php [27] Taller Europeo de
Software de fi ne Redes. [En línea]. Aprovechar-
poder: http://www.ewsdn.eu/previous/ewsdn12.html [28] “El software de fi nida de redes: Un
nuevo paradigma para el virtual, dinámico,
fl exible de redes “, Hopewell Junction, Nueva York, EE.UU., Libro Blanco, 2012. octubre [En
línea]. Disponible: http://ict.unimap.edu.my/images/doc/ SDN% 20IBM% 20WhitePaper.pdf
[29] Fundación Redes abierto (ONF). [En línea]. Disponible: https: // www.
opennetworking.org/ [30] J. Smith et al., “Switchware: Aceleración de evolución de la red,”
CIS
Dept., Univ. Pennsylvania, Filadelfia, PA, EE.UU., Libro Blanco, 1996. [31] D. Alexander et
al., “La arquitectura de red activa SwitchWare,”
IEEE Serv., vol. 12, no. 3, pp. 29-36, May / Jun. 1998. [32] E. Kohler, R. Morris, B. Chen, J.
Jannotti, y M. Kaashoek, “El clic
enrutador modular” ACM Trans. Comput. Syst., vol. 18, no. 3, pp. 263-297, agosto de de 2000.
[33] M. Handley, O. Hodson, y E. Kohler, “XORP: una plataforma abierta para
investigación de la red” ACM SIGCOMM Comput. Commun. Rdo., vol. 33, no. 1, pp. 53-57, enero
de 2003.
[34] Quagga enrutamiento Software Suite. [En línea]. Disponible: http: // www.
nongnu.org/quagga/
[35] El AVE enrutamiento de Internet Daemon. [En línea]. Disponible: http: // aves.
network.cz/
[36] N. Feamster, H. Balakrishnan, J. Rexford, A. Shaikh, y J. van der
Merwe, “El caso para la separación de enrutamiento de routers,” en Proc. ACM SIGCOMM
Taller FDNA, 2004, pp. 5-12.
[37] L. Yang, R. Dantu, T. Anderson, y R. Gopal, Reenvío y Con-
Separación (fuerzas) Marco trol Elemento, abril de 2004, RFC 3746. [En línea]. Disponible:
http://www.cisco.com/en/US/solutions/collateral/ ns341 / ns525 / ns537 / ns705 / ns827 /
white_paper_c11-481360.pdf [38] T. Lakshman, T. Nandagopal, R. Ramjee, K. Sabnani, y T.
Woo, “The
arquitectura softrouter,”en Proc. ACM SIGCOMMWorkshop Hot Topics, Serv. 2004, pp. 1-6.
[39] W. Wang et al., “Diseño e implementación de un abierto programable
enrutador conforme a las fuerzas IETF especificaciones,”en Proc. 6 de CIE,
2007, pp. 1-6.
[40] A. Doria et al., Reenvío y Elemento de Control de Separación (fuerzas)
Protocolo especi fi cación, marzo de 2010, RFC 5810. [En línea]. Disponible:
http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ ns705 / ns827 /
white_paper_c11-481360.pdf [41] J. Rexford et al., “La toma de decisiones de toda la red: hacia
una finísima
controlar avión “, en Proc. HotNets, 2004, pp. 59-64.
[42] A. Greenberg et al., “Un enfoque 4D pizarra limpia para el manejo de red
y la gestión” SIGCOMM Comput. Commun. Rdo., vol. 35, no. 5, pp. 41-54, octubre de 2005.
[43] H. Yan et al., “Tesseract: un plano de control de red 4D,” en Proc. cuarto
USENIX Conf. INDE, 2007, p. 27.
XIA et al .: Una encuesta sobre Software-Defined Networking
[44] A. Farrel, J.-P. Vasseur, y J. Ash, A Path Computation Element
(PCE) Arquitectura -Based, agosto de 2006, el RFC 4655. [En línea]. Disponible:
http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ ns705 / ns827 /
white_paper_c11-481360.pdf [45] M. Casado et al., “SANE: Una arquitectura de protección de la
empresa NET
trabaja en Proc. 15a Conf. USENIX-SS, Berkeley, CA, EE.UU., 2006, vol. 15, p. 10.
[46] J. Luo, J. Pettit, M. Casado, J. Lockwood, y N. McKeown, “Prototyp-
ING, seguros, interruptores simples rápidos para Etha,”en Proc. 15a Annu. IEEE Symp. HOTI, 2007,
pp. 73-82.
[47] M. Casado et al., “Etano: Tomar el control de la empresa”, en Proc.
Conf. SIGCOMM Appl., Technol., Archit., Protocolos Comput. Commun.,
2007, pp. 1-12.
[48] ​M. Casado et al., “Repensando control de la red de la empresa,” IEEE / ACM
Trans. Netw., vol. 17, no. 4, pp. 1270-1283, agosto de 2009. [49] S. Shenker, M. Casado, T.
Koponen, y N. McKeown, “El futuro de
la creación de redes, y el pasado de los protocolos “, presentado en la Cumbre abierto
Networking, Stanford, CA, EE.UU., 2011. [En línea]. Disponible: http: // www.
opennetsummit.org/archives/apr12/site/talks/shenker-tue.pdf [50] A. gember, P. Prabhu, Z.
Ghadiyali, y A. Akella, “Hacia software-
de fi nida redes middlebox,”en Proc. 11 de ACM Taller Temas calientes, Serv. 2012, pp. 7-12.
[51] M. Al-tarifas, S. Radhakrishnan, B. Raghavan, N. Huang, y A. Vahdat,
“Hedera: dinámico flujo de la programación de redes de centros de datos”, en Proc. 7ª Conf
USENIX. INDE, 2010, p. 19.
[52] M. Ghobadi, S. Yeganeh, y Y. Ganjali, “Rethinking de extremo a extremo con-
control de gestion de redes definida por software de,”en Proc. 11 ACMWorkshop Hot Topics,
Serv. 2012, pp. 61-66.
[53] N. Handigol, S. Seetharaman, M. Flajslik, R. Johari, y N. McKeown,
"Aster * x: equilibrio de carga como una red primitiva “, en Proc. 9 de GENI Ing. Conf.
(Plenario), 2010, pp. 1-2.
[54] B. Heller et al., “ElasticTree: El ahorro de energía en las redes de centros de datos”, en
Proc. 7ª Conf USENIX. INDE, 2010, p. 17.
[55] A. Ferguson, A. Guha, J. Place, R. Fonseca, y S. Krishnamurthi,
“Las redes participativa”, en Proc. Hielo caliente, San Jose, CA, EE.UU.,
2012, p. 2.
[56] K. Jeong, J. Kim, y Y. Kim, “sistema operativo de red compatibles con QoS
para el software definida en red con Openflows generalizadas,”en Proc. IEEE NOMS, 2012,
pp. 1167-1174.
[57] T. Koponen et al., “Arquitectura de la innovación” ACM SIGCOMM
Comput. Commun. Rdo., vol. 41, no. 3, pp. 24-36, Jul. 2011. [58] PlanetLab. [En línea].
Disponible: http://www.planet-lab.org/ [59] Medio Ambiente Mundial para la Innovación de la Red
(GENI). [En línea]. Aprovechar-
poder: http://www.geni.net/
[60] A. Sharafat, S. Das, G. Parulkar, y N. McKeown, “MPLS-TE y
MPLS VPN con OpenFlow” ACM SIGCOMM Comput. Commun. Rdo., vol. 41, no. 4, pp.
452-453, agosto de 2011. [61] N. Blefari-Melazzi, A. Detti et al., “Un banco de pruebas basados ​en
OpenFlow para
la información centrada en la creación de redes,”en Proc. S Dentro futuro. Cumbre móvil,
2012, pp. 4-6.
[62] H. Yin et al., SDNi: unMensaje protocolo de Exchange para el software de fi nido
Redes (SDN) a través de varios dominios, hijo. 2012, borrador de Internet. [En línea]. Disponible:
http://www.cisco.com/en/US/solutions/collateral/ ns341 / ns525 / ns537 / ns705 / ns827 /
white_paper_c11-481360.pdf [63] H. Xie et al., “Los esfuerzos de redes definida por software de
debutó en el IETF, 84”
IETF J., Octubre de 2012. [En línea]. Disponible: http://www.internetsociety.org/ fr / nodo / 45708 [64]
R. Birke et al., “Partición / agregado en los productos básicos de Ethernet 10G
software de fi nido en red,”en Proc. IEEE 13 Int. Conf. IPSS,
2012, pp. 7-14.
[65] E. Karpilovsky, M. Caesar, J. Rexford, A. Shaikh, y J. van der
Merwe, “Práctica de compresión de toda la red de tablas de enrutamiento IP”
IEEE Trans. Netw. Serv. Gestionar., vol. 9, no. 4, pp. 446-458, diciembre de de 2012.
[66] T. Pan, X. Guo, C. Zhang, W. Meng, y B. Liu, “ALFE: Un reemplazo
la política de caché de elefante fluye en presencia de los ratones inundando “, en Proc. IEEE ICC, Jun.
2012, pp. 2961-2965. [67] O. Ferkouss et al., “Una plataforma de procesador de red 100 Funda para
OpenFlow “, en Proc. 7º Int. CNSM, 2011, pp. 1-4.
[68] JC Mogul y P. Congdon, “Hey, zurcidos contadores !: ¡Fuera de mi
ASIC!”En Proc. 1er Taller HotSDN, 2012, pp. 25-30.
basado en PC [69] V. Tanyingyong, M. Hidell, y P. Sjodin, “Mejora
OpenFlow rendimiento de conmutación,”en Proc. ACM / IEEE Symp. ANCS,
2010, pp. 1-2.
[70] V. Tanyingyong, M. Hidell, y P. Sjodin, “Uso de hardware clasi fi cación
OpenFlow para mejorar la conmutación basada en PC “, en Proc. IEEE 12 Int. Conf. IPSS, 2011, pp.
215-221.
47
[71] G. Lu, R. Miao, Y. Xiong, y C. Guo, “Uso de CPU como un tráfico c co-
unidad de procesamiento en los conmutadores de las materias primas,”en Proc. 1er Taller HotSDN,
2012, pp. 31-36.
[72] Pantou: OpenFlow 1.0 para OpenWRT. [En línea]. Disponible: http: // www.
ow.org/wk/index.php/Pantou_:_OpenFlow_1.0_for_OpenWRT [73] Y. Mundada, R.
Sherwood, y N. Feamster, “Un interruptor OpenFlow fl abierto
elemento de clic “, presentado en el Simposio click Router modular, Gante, Bélgica, 2009.
[74] B. Pfaff et al., “La ampliación de redes en la virtualización
capa “, en Proc. HotNets, Nueva York, Nueva York, EE.UU., 2009. [En línea]. Disponible:
http://conferences.sigcomm.org/hotnets/2009/papers/ hotnets2009- fi nal143.pdf
[75] J. Pettit, J. Gross, B. Pfaff, M. Casado, y S. Crosby, “conmutación virtual
en una era de bordes avanzados “, en Proc. 2º Taller DC-CUEVAS, 2010, pp. 1-7. [76] J.
Lockwood et al., “-NetFPGA una plataforma abierta para gigabit de velocidad
conmutación de red y enrutamiento,”en Proc. IEEE Int. Conf. MSE, 2007, pp. 160-161.
[77] M. Anwer, M. Motiwala, M. Tariq, y N. Feamster, “SwitchBlade: A
plataforma para el rápido despliegue de protocolos de red de hardware programable,” ACM
SIGCOMM Comput. Commun. Rdo., vol. 40, no. 4, pp. 183-194, octubre de 2010. [78] G. Lu et
al., “ServerSwitch: Un rendimiento programable y alto
plataforma para redes de centros de datos “, en Proc. INDE, 2011, p. 2.
[79] A. Rostami, T. Jungel, A. Koepsel, H. Woesner, y A. wolisz, “Oran:
OpenFlow routers para redes académicas “, en Proc. IEEE 13 Int. Conf. IPSS, 2012, pp.
216-222.
[80] J. Naous, D. Erickson, GA Covington, G. Appenzeller, y
N. McKeown, “Implementación de un interruptor de OpenFlow en la plataforma NetFPGA,” en Proc.
Cuarto ACM / IEEE Symp. ANCS, 2008, pp. 1-9.
[81] J. Kempf et al., “OpenFlow MPLS y la etiqueta de código abierto conmutan
enrutador,”en Proc. 23 ITC, 2011, pp. 8-14.
[82] Indigo-Open Source OpenFlow interruptores. [En línea]. Disponible: http: //
www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ ns827 /
white_paper_c11-481360.pdf
[83] A. Bianco, R. Birke, L. Giraudo, y M. Palacín, “conmutación abierto flujo:
el rendimiento del plano de datos “, en Proc. IEEE ICC, 2010, pp. 1-5.
[84] C. Rotsos, N. Sarrar, S. Uhlig, R. Sherwood, y AW Moore,
“OFLOPS: Un marco abierto para la evaluación interruptor de OpenFlow,” en
Proc. 13 Int. Conf. PAM, 2012, pp. 85-95.
[85] T. Ulversoy, “Software de fi nido de radio: desafíos y oportunidades”
IEEE Commun. Encuestas, Tuts. vol. 12, no. 4, pp. 531-550, mayo de 2010. [86] E. Mannie,
Generalizado Multi-Protocolo Label Switching (GMPLS) Ar-
quitectura, octubre de 2004, RFC 3945. [En línea]. Disponible: http: //tools.ietf. org / rfc / rfc6325.txt
[87] M. Bansal, J. Mehlman, S. Katti, y P. Levis, “OpenRadio: A pro-
dataplane inalámbrica gramable,”en Proc. 1er Taller HotSDN, 2012, pp. 109-114.
[88] R. Murty, J. Padhye, A. Wolman, y M.. Welsh, “Dyson: Una arquitectura
extensibles para redes LAN inalámbricas “, en Proc. USENIXATC, 2010, p. 15.
[89] Ejecutivo del Programa Conjunto fi cina (JPEO) para la radio táctica conjunta
Sistema (JTRS), software de comunicaciones Arquitectura especí fi cación, San Diego, CA,
EE.UU. 2012. [En línea]. Disponible: http://jpeojtrs.mil/sca/ Documentos / SCAv4_0 /
SCA_4.0_20120228_ScaSpeci fi cation.pdf [90] G. Jianxin, Y. Xiaohui, G. Jun, y L. Quan, “El
software de comunica-
arquitectura ción especí fi cación: Evolución y tendencias “, en Proc. PACIIA,
2009, vol. 2, pp. 341-344.
[91] Forum Wireless Innovation (Anteriormente la SDRForum). [En línea]. Aprovechar-
capaz: http://www.wirelessinnovation.org/ [92] J. Elbers y A. Autenrieth, “de estática a
software-de fi Ned óptico
redes “, en Proc. 16a Int. Conf. ONDM, 2012, pp. 1-4.
[93] A. Giorgetti, F. Cugini, F. Paolucci, y P. Castoldi, “OpenFlow y PCE
Arquitecturas en Longitud de Onda Switched Optical Networks,”en Proc. 16a Int. Conf.
ONDM, 2012, pp. 1-6.
[94] S. Das, G. Parulkar, y N. McKeown, “uni de control fi ed simple para paquetes
y redes de circuitos,”en Proc. IEEE / LEOSST Meet., 2009, pp. 147-148.
[95] S. Das, G. Parulkar, y N. McKeown, “paquete unificación y el circuito de
las redes de conmutación “, en Proc. Talleres GlobeCom IEEE, 2009, pp. 1-6. [96] S. Das et
al., “Paquete y la convergencia de redes de circuitos con OpenFlow”
en Pro. OFC / NFOEC, 2010, pp. 1-3.
[97] S. Das et al., “Ingeniería de aplicación consciente de agregación y tráfico c
en una red de paquetes de circuito convergente”en Proc. OFC / NFOEC, 2011, pp. 1-3.
[98] L. Liu, T. Tsuritani, I. Morita, H. Guo, y J. Wu, “OpenFlow basa-
control de la trayectoria de longitud de onda en las redes ópticas transparentes: Una demostración de
prueba ofconcept,”en Proc. 37a CEC, 2011, pp. 1-3.
48 ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 1, PRIMER TRIMESTRE 2015
[99] L. Liu, T. Tsuritani, I. Morita, H. Guo, y J. Wu, “validación Experimental
ción y evaluación del rendimiento de control de la trayectoria de longitud de onda basado en OpenFlow en
redes ópticas transparentes” Optar. Exp., vol. 19, no. 27, pp. 26 578 a 26 593, diciembre de 2011. [100] L. Liu et
al., “En primer ensayo de campo de un control unificado fi basados ​en OpenFlow
avión por múltiples capas de redes ópticas múltiples granularidad “, presentado en la Conferencia de
fibra óptica para comunicaciones, Los Ángeles, CA, EE.UU.,
2012, Papel PDP5D.2.
[101] L. Liu et al., “En primer ensayo de campo de una uni fi basados ​en OpenFlow ed con-
avión trol para redes ópticas de múltiples capas multi-granularidad,”en Proc. OFC / NFOEC, 2012,
pp. 1-3.
[102] L. Liu, T. Tsuritani, y I. Morita, “Demostración experimental de
OpenFlow / GMPLS interfuncionamiento plano de control para IP / DWDM redes ópticas de
múltiples capas,”en Proc. 14a ICTON, 2012, pp. 1-4.
[103] L. Liu, T. Tsuritani, y I. Morita, “Desde GMPLS a PCE / GMPLS
a OpenFlow: ¿Cuánto beneficio podemos obtener de la evolución técnica del plano de
control en redes ópticas “en? Proc. 14a ICTON, 2012, pp. 1-4.
[104] F. Farías, J. Salvatti, E. Cerqueira, y A. Abelem, “A manage- propuesta
ción del entorno de red usando legado plano de control OpenFlow “, en Proc. IEEE NOMS, 2012, [131] A. Tootoonchian, M. Ghobadi, y Y. Ganjali, “OpenTM: matriz Traf fi c
pp. 1143-1150.
[105] M. Casado, T. Koponen, S. Shenker, y A. Tootoonchian, “Tejido: A
retrospectiva sobre la evolución de SDN,”en Proc. 1er Taller HotSDN, 2012, pp. 85-90. [106] B.
Raghavan et al., “Fi nida la arquitectura de Internet Software-de: Desacoplamiento
la arquitectura de infraestructura “, en Proc. 11 de ACM Taller Temas calientes, Serv. 2012,
pp. 43-48.
[107] V. Gudla et al., “Demostración experimental de control de OpenFlow de
conmutadores de paquetes y de circuitos “, presentado en la Conferencia de fibra óptica
Comunicación, San Diego, CA, EE.UU., 2010, Documento de OTuG2. [108] D. Simeonidou, R. Nejabati,
y S. Azodolmolky, “Habilitación el futuro
Internet óptico con OpenFlow: Un cambio de paradigma en la prestación de servicios de redes
ópticas inteligentes “, en Proc. 13 ICTON, 2011, pp. 1-4.
[109] S. Azodolmolky et al., “Integrado de plano de control GMPLS-OpenFlow: Un
modelo de superposición para el software de fi nida de paquetes a través de redes ópticas,” Optar. Exp., vol. 19,
no. 26, pp. B421-B428, Dic de 2011.
[110] Kit Una plataforma de Cisco (onePK). [En línea]. Disponible: http: // www.
cisco.com/en/US/prod/iosswrel/onepk.html
[111] TL Hinrichs, NS Gude, M. Casado, JC Mitchell, y S. Shenker,
“Gestión de la red declarativa Práctica,” en Proc. ACM primera Wren,
2009, pp. 1-10.
[112] N. Foster, et al., “Frenético: Un lenguaje de alto nivel para OpenFlow NET
trabaja en Proc. Taller PRESTO, 2010, pp. 6: 1-6: 6.
[113] N. Foster, et al., “Frenético: Un lenguaje de programación de la red,”
Avisos SIGPLAN, vol. 46, no. 9, pp 279-291, Sep. 2011. [114] A. Voellmy y P. Hudak,
“Nettle:. Un lenguaje para con fi gurar enrutamiento
redes “, en Proc. IFIP TC 2 Conf Trabajo. DSL, 2009, pp. 211-235.
[115] A. Voellmy et al., “No con fi gurar la red, el programa de él!
fi lenguajes de programación C-dominio específico para sistemas de red,”Tech Defensa. Inf.
Center, Fort Belvoir, VA, EE.UU., DTIC Doc. Tech. Reps.,
2010.
[116] A. Voellmy y P. Hudak, “Ortiga: Tomando la picadura de la programación
enrutadores de red “, en Proc. 13 Int. Conf. PADL, 2011, pp. 235-249.
[117] A. Voellmy, H. Kim, y N. Feamster, “Procera: Un lenguaje de alto
nivel de control de la red reactiva,”en Proc. 1er Taller HotSDN, 2012, pp. 43-48.
[118] T. Hinrichs, N. Gude, M. Casado, J. Mitchell, y S. Shenker, “Express-
y valorar la capacidad políticas de seguridad de red basados ​en de flujo “, Univ. Chicago, Chicago, IL,
EE.UU., Tech. Rep, 2008.
[119] AD Ferguson, A. Guha, C. Liang, R. Fonseca, y S. Krishnamurthi,
“Las políticas jerárquicas para las redes de software de fi nidas,” en Proc. 1er Taller HotSDN, 2012,
pp. 37-42.
[120] C. Monsanto, N. Foster, R. Harrison, y D. Walker, “Un compilador y
tiempo de ejecución del sistema para lenguajes de programación de la red,”en Proc. 39ª Annu.
ACM-SIGPLAN SIGACT Symp. POPL, 2012, pp. 217-230.
[121] S. Gutz, A. Story, C. Schlesinger, y N. Foster, “Splendid aislamiento: A
abstracción rebanada de redes software de fi nida,”en Proc. 1er Taller HotSDN, 2012, pp.
79-84.
[122] C. Monsanto, J. Reich, N. Foster, J. Rexford, y D. Walker, “Composición de
software de fi nido redes “, en Proc. 10 de USENIX Conf. INDE, 2013, pp. 1-14.
[123] A. Voellmy, J. Wang, YR Yang, B. Ford, y P. Hudak, “Maple: Sim-
plifying SDN programación utilizando políticas algorítmicos,”en Proc. ACM SIGCOMM Conf., 2013,
[150] M. Ku'
pp. 87-98.
[124] R. Wang, D. Butnariu, y J. Rexford, “carga del servidor basada en OpenFlow
equilibrar Gone Wild “, en Proc. 11 USENIX Conf. S Dentro hot-ICE. Serv.,
2011, p. 12.
[125] S. Ghorbani y M. César, “Walk la línea: actualizaciones de red coherente
con garantías de ancho de banda “, en Proc. 1er Taller HotSDN, 2012, pp. 67-72.
[126] M. Reitblatt, N. Foster, J. Rexford, C. Schlesinger, y D. Walker,
“Las abstracciones de actualización de la red”, en Proc. ACM SIGCOMM Conf. Appl.,
Technol., Archit., Protocolos Comput. Commun., 2012, pp. 323-334.
[127] M. Reitblatt, N. Foster, J. Rexford, y D. Walker, “actualizaciones consistentes
para las redes de software de fi nida: Cambio que usted puede creer en “en! Proc. HotNets-X 10a
ACM Taller, 2011, pp. 7: 1-7: 6.
[128] R. McGeer, “A, e fi protocolo de actualización ciente seguro para redes OpenFlow,”
en Proc. 1er Taller HotSDN, 2012, pp. 61-66.
[129] R. Raghavendra, J. Lobo, y K.-W. Lee, “primi- consulta Gráfico dinámico
tivos para la gestión basada en cloudnetwork SDN,”en Proc. 1er Taller HotSDN, 2012, pp.
97-102.
[130] A. Medina, N. Taft, K. Salamatian, S. Bhattacharyya, y C. Diot,
“Traf fi c matriz de estimación: Las técnicas existentes y nuevas direcciones,”
ACM SIGCOMM Comput. Commun. Rdo., vol. 32, no. 4, pp. 161-174, octubre de 2002.
estimador de redes OpenFlow “, en Medición pasiva y activa.
Berlín, Alemania: Springer-Verlag, 2010, pp 201-210.. [132] A. Curtis, Kim W., y P.
Yalagandula, “mahout Data- baja sobrecarga
centro de gestión de c fi tráfico usando la detección elefante base de extremo anfitrión”en
Proc. IEEE INFOCOM, 2011, pp. 1629-1637.
[133] L. Jose, M. Yu, y J. Rexford, “Medición en línea de gran tráfico c
agregados en los interruptores de las materias primas “, en Proc. 11 USENIX Conf. HotICE Serv. Serv., 2011,
p. 13.
[134] N. Alon, Y. Matias, y M. Szegedy, “La complejidad espacio de aproximación
apareamiento los momentos de frecuencia “, en Proc. 28 Annu. ACM COTS, 1996, pp. 20-29.
[135] G. y M. Cormode Hadjieleftheriou, “Localización de elementos frecuentes en los datos
corrientes” Proc. Haga ganar a VLDB., vol. 1, no. 2, pp. 1530-1541, agosto de 2008. [136] A.
Kumar, M. Sung, JJ Xu, y J. Wang, “Secuencia de datos en algo-
ritmos de e fi ciente y la estimación precisa de la distribución del tamaño de flujo”
Realizar Sigmetrics. Eval. Rdo., vol. 32, no. 1, pp. 177-188, Jun. De 2004.
[137] A. Kumar, M. Sung, JJ Xu, y J. Wang, “Secuencia de datos en algo-
ritmos de e fi ciente y la estimación precisa de la distribución del tamaño de flujo “, en
Proc. Conjunto Sigmetrics Int. Conf. Meas. Modelo. Comput. Syst., 2004, pp. 177-188.
[138] C. Estan, G. Varghese, y M. Fisk, “algoritmos de mapa de bits para el recuento
flujos activos en enlaces de alta velocidad,” IEEE / ACM Trans. Netw., vol. 14, no. 5, pp. 925-937,
octubre de 2006.
[139] M. Yu, L. Jose, y R. Miao, “Software se ha definido medición tráfico c con
OpenSketch,”en Proc. 10 de USENIX Conf. INDE, 2013, pp. 29-42.
[140] P. Fonseca, R. Bennesby, E. Mota, y A. Passito, “A compo- replicación
nente para las redes basadas en OpenFlow resistente “, en Proc. IEEE NOMS,
2012, pp. 933-939.
[141] D. Levin, A. Wundsam, B. Heller, N. Handigol, y A. Feldmann,
“Lógicamente centralizados ?: distribución de las compensaciones del Estado en las redes de nidos de software
de fi”, en Proc. 1er Taller HotSDN, 2012, pp. 1-6.
[142] A. Tootoonchian y Y. Ganjali, “HyperFlow: Un control distribuido
avión para OpenFlow “, en Proc. INM / Wren, 2010, p. 3.
[143] T. Koponen et al., “Onix: una plataforma de control distribuido para a gran escala
redes de producción “, en Proc. Conf USENIX noveno. IESO, 2010, pp. 1-6.
[144] P. Porras et al., “Un núcleo de refuerzo de la seguridad de las redes OpenFlow”
en Proc. 1er Taller HotSDN, 2012, pp. 121-126.
[145] E. Al-Shaer y S. Al-Haj “, FlowChecker: análisis Con fi guración y
la verificación de las infraestructuras de OpenFlow federados “, en Proc. 3er Taller ACM assurable
utilizable Seguridad SAFEcon fi g, 2010, pp. 37-44.
[146] E. Al-Shaer, W. Marrero, A. El-Atawy, y K. Elbadawi, “Red de con-
guración fi en una caja: Hacia de extremo a extremo de fiscalización de alcanzabilidad y seguridad
de la red,”en Proc. 17a IEEE CIPE, 2009, pp. 123-132.
[147] P. Peresini y M. Canini, “es su aplicación correcta OpenFlow?” En
Proc. ACM conexto Student Workshop, 2011, pp. 18: 1-18: 2.
[148] M. Canini, D. Kostic, J. Rexford, y D. Venzano, “Automatización de la
prueba de aplicaciones OpenFlow “, presentado en la primera Protocolo Internacional de
Ingeniería Taller riguroso, Portland, Oregón, EE.UU., 2011. [149] M. Canini, D. Venzano, P.
Peresini, D. Kosti' c, y J. Rexford, “A nice
manera de probar aplicaciones OpenFlow “, en Proc. Conf USENIX noveno. INDE,
2012, p. 10.
zniar, M. Canini, y D. Kosti' c “, a menudo pruebas OpenFlow NET
trabaja en Proc. Primero EWSDN, Oct. 2012, pp. 54-60. [151] H. Mai et al., “Depuración del
plano de datos con anteater,” ACM
SIGCOMM Comput. Commun. Rdo., vol. 41, no. 4, pp. 290-301, agosto de de 2011.
XIA et al .: Una encuesta sobre Software-Defined Networking
[152] A. Khurshid, W. Zhou, M. Caesar, y PB Godfrey, “VeriFlow: Ver-
ifying invariantes de toda la red en tiempo real “, en Proc. Talleres primera HotSDN, 2012, pp.
49-54, Nueva York, NY, EE.UU..
[153] A. Khurshid, W. Zhou, M. César, y PB Godfrey, “Veri flujo:
Verificación de invariantes de toda la red en tiempo real” SIGCOMM Comput. Commun.
Rdo., vol. 42, no. 4, pp 467-472, Sep. 2012. [154] A. Khurshid, X. Zou, W. Zhou, M. Caesar, y PB
Godfrey, “VeriFlow.:
Verificación de invariantes de toda la red en tiempo real “, en Proc. 10 de USENIX Conf. INDE, 2013,
pp. 15-28.
[155] B. Heller, R. Sherwood, y N. McKeown, “La colocación controlador
problema “, en Proc. 1er Taller HotSDN, 2012, pp. 7-12.
[156] Z. Cai, “Maestro: El logro de la escalabilidad y la coordinación en centralizado
plano de control de red “, Ph.D. disertación, Rice Univ., Houston, TX, EE.UU., 2011.
[157] Z. Cai, AL Cox, y TE Ng, “Maestro: Un sistema para escalable
control de OpenFlow,”Rice Univ., Houston, TX, EE.UU., Tech. Rep. TR 10-08, Dic de 2010.
[158] A. Tootoonchian, S. Gorbunov, Y. Ganjali, M. Casado, y R. Sherwood,
“El rendimiento del controlador de redes definida por software de,” en Proc. Segundo USENIX Conf. S
Dentro hot-ICE. Serv., 2012, p. 10.
[159] A. Voellmy y J. Wang, “escalable software de red con fi nida
ladores,”en Proc. ACM SIGCOMM Conf. Appl., Technol., Archit., Protocolos Comput.
Commun., 2012, pp. 289-290.
[160] A. Voellmy, B. Ford, P. Hudak, y YR Yang, “Scaling software-
controladores de red definida de en los servidores multinúcleo,”Comput. Sci., Yale University., New
Haven, CT, EE.UU., Yale CS TR 1468, 2012. [161] Beacon.
[En línea]. Disponible: https: // fl abierta ow.stanford.edu/display/ Beacon / Inicio
[162] M. Jarschel et al., “Modelado y evaluación de rendimiento de una
arquitectura OpenFlow “, en Proc. 23 PICT, 2011, pp. 1-7.
[163] M. Yu, J. Rexford, MJ Freedman, y J. Wang, “Scalable fl OW
basada en red con DIFANE,”en Proc. ACM SIGCOMM, 2010, pp. 351-362. [164] AR Curtis et
al., “DevoFlow: Escala de flujo para la gestión de alto
redes de desempeño” SIGCOMM Comput. Commun. Rdo., vol. 41, no. 4, pp. 254-265, agosto
de de 2011.
[165] SH Yeganeh y Y. Ganjali, “Kandoo: Un marco para ef ciente fi
y escalable de oading fl de aplicaciones de control “, en Proc. 1er Taller HotSDN, 2012, pp.
19-24.
[166] Cbench (Controller Benchmarker). [En línea]. Disponible: http: // www.
abrir fl ow.org/wk/index.php/O fl ops
[167] M. Jarschel, F. Lehrieder, Z. Magyari, y R. Pries, “A flexible
punto de referencia OpenFlow-controlador,”en Proc. EWSDN, 2012, pp. 48-53.
[168] R. Alimi, R. Penno, e Y. Yang, Protocolo ALTO, febrero de 2013,
Internet Borrador. [En línea]. Disponible: http://tools.ietf.org/id/
proyecto-IETF-alto-protocol-14.txt
[169] V. Gurbani, M. Scharf, T. Lakshman, V. Hilt, y E. Marruecos, “Resumen-
ing estado de la red en el software de fi ne Redes (SDN) para los servicios de encuentro “, en Proc.
IEEE ICC, 2012, pp. 6627 hasta 6632.
[170] E. Kissel, G. Fernandes, M. Jaffee, M. Swany, y M. Zhang, “Conducir
software de fi nido redes con XSP,”en Proc. Taller SDN / IEEE Int. Conf. Commun., 2012, pp.
6616 a 6.621.
[171] E. Keller y J. Rexford, “La‘Plataforma como un modelo de servicio’para NET
trabajando en Proc. INM / Wren, 2010, p. 4.
[172] N. Handigol et al., “Plug-n-Serve: equilibrio de carga web trá fi co US-
ing OpenFlow “, en Proc. ACM SIGCOMM Demo, Barcelona, ​España,
2009. [En línea]. Disponible: http://conferences.sigcomm.org/sigcomm/ 2009 / demos /
SIGCOMM-PD-2009- fi nal26.pdf [173] K.-K. Ladrar et al., “Proyecto para la introducción de la
innovación en la radio
las redes móviles “, en Proc. Segundo ACM SIGCOMMWorkshop VISA, 2010, pp. 25-32. [174]
K.-K. Ladrar et al., “OpenRoads: Capacitar a la investigación en NET móvil
trabajos," SIGCOMMComput. Commun. Rdo., vol. 40, no. 1, pp. 125-126, enero de 2010.
[175] K. Yap, S. Katti, G. Parulkar, y N. McKeown, “capacidad de entrega
para el Internet móvil uniendo redes “, en Proc. ACM Taller estudiantes inalámbrica, 2010,
pp. 41-44.
[176] L. Suresh, J. Schulz-Zander, R. Merz, A. Feldmann, y T. Vazao,
“Hacia las WLAN empresariales programables con Odin,” en Proc. 1er Taller HotSDN, 2012,
pp. 115-120.
[177] A. Wundsam, D. Levin, S. Seetharaman, y A. Feldmann, “OFRewind:
Activación de grabación y reproducción de solución de problemas de redes “, en Proc. USENIX Annu.
Tech. Conf., 2011, p. 29.
[178] JH Jafarian, E. Al-Shaer, y Q. Duan, “OpenFlow azar
sede de la mutación: Transparente defensa objetivo en movimiento usando el software de fi
nida en red “, en Proc. 1er Taller HotSDN, 2012, pp. 127-132.
49
[179] M. Mendonca, S. Seetharaman, y K. Obraczka, “A flexible
Dentro de la red IP servicio de forma anónima,”en Proc. IEEE ICC, 2012, pp. 6651 a 6656.
[180] J. Fu, P. Sjödin, y G. Karlsson, “convergencia de enrutamiento intra-dominio
con control centralizado,” Comput. Netw., vol. 53, no. 18, pp. 2985-2996, Dic de 2009.
[181] KK Lakshminarayanan, I. Stoica, S. Shenker y J. Rexford, “Routing
como un servicio,”Ingeniería Eléctrica e Informática Departamento, Univ. California, Berkeley, CA, EE.UU., Tech. Rep. UCB
/ Ingeniería Eléctrica e Informática-2006-19, febrero de 2006. [182] P. Pisa et al., “OpenFlow y la migración de la red virtual basado
en Xen,” en
Comunicaciones: Wireless en los países y redes del futuro desarrollo. Berlín, Alemania:
Springer-Verlag, 2010, pp 170-181.. [183] ​M. Koerner y O. Kao, “servicio múltiple de equilibrio de
carga con Abierta
Fluir en Proc. 13 IEEE Int. Conf. IPSS, 2012, pp. 210-214.
[184] G. Wang, TE Ng, y A. Shaikh, “Programación de su red en Run-
tiempo para las aplicaciones de datos grandes,”en Proc. 1er Taller HotSDN, 2012, pp. 103-108.
[185] Z. Kerravala, “A medida que el valor de las redes empresariales se intensifica, por lo
lo hace la necesidad de una gestión con fi guración,”Empresa Informática y Redes, El
informe de Yankee Group, Boston, MA, EE.UU.,
2004.
[186] N. Handigol, B. Heller, V. Jeyakumar, D. Mazieres, y N. McKeown,
“¿Dónde está el depurador para mi red fi nido de software-de?” En Proc. 1er Taller HotSDN, 2012,
pp. 55-60.
[187] S. Sharma, D. Staessens, D. Colle, M. Pickavet, y P. Demeester, “En-
abling rápida recuperación de fallos en las redes OpenFlow “, en Proc. Octavo Int. Taller DRCN, 2011,
pp. 164-171.
[188] R. Braga, E. Mota, y A. Passito “DDoS ligeros fl ataque inundando
detección usando NOX / OpenFlow “, en Proc. 35th IEEE Conf. LCN, 2010, pp. 408-415.
[189] G. Gibb, H. Zeng, y N. McKeown “, funcional- red de subcontratación
dad “, en Proc. 1er Taller HotSDN, 2012, pp. 73-78.
[190] G. Huang, C. Chuah, S. Raza, y S. Seetharaman, “Dynamic
medición consciente de enrutamiento en la práctica,” IEEE Serv., vol. 25, no. 3, pp. 29-34, May /
Jun. 2011.
[191] J. Naous, R. Stutsman, D. Mazieres, N. McKeown, y N. Zeldovich,
“La delegación de seguridad de la red con más información”, en Proc. ACM primera Wren, 2009, pp.
19-26.
[192] C. Rigney, A. Rubens, W. Simpson, y S. Willens, autenti- remoto
Marcación de cationes en servicio de usuario (RADIUS), Jun. 2000. [En línea]. Disponible:
http://tools.ietf.org/rfc/rfc2865.txt
[193] Y. Yamasaki, Y. Miyamoto, J. Yamato, H. Goto, y H. Sone, “Flexible
sistema de acceso a la administración de VLAN basado en el campus de OpenFlow,”en
Proc. IEEE / IPSJ 11 Int. SMO, 2011, pp. 347-351.
[194] S. Kinoshita, T. Watanabe, J. Yamato, H. Goto, y H. Sone, “Imple-
mentación y evaluación de un sistema de control de acceso basado en OpenFlow para la itinerancia
de LAN inalámbrica “, en Proc. 36ª Annu. COMPSACW, 2012, pp. 82-87.
[195] A. Ramachandran, Y. Mundada, M. Tariq, y N. Feamster, “Secur-
ing redes empresariales que utilizan trá fi co adulteración,”Georgia Inst. Technol., Atlanta, GA,
EE.UU., Tech. Rep. GTCS-09-15, 2009. [196] N. Feamster et al., “Política de disociación de con fi
guración en el campus
y redes empresariales “, en Proc. 17a IEEEWorkshop LANMAN, 2010, pp. 1-6.
[197] A. Nayak, A. Reimers, N. Feamster, y R. Clark, “Resonancia: Dinámico
control de acceso para redes empresariales,”en Proc. Primero ACMWorkshop Res. Empresa
Serv., 2009, pp. 11-18.
[198] N. y R. Chowdhury Boutaba, “la virtualización de red: Estado de
los retos del arte y de investigación,” IEEE Commun. Revista., vol. 47, no. 7, pp. 20-26, Jul. De
2009.
[199] D. Turull, M. Hidell, y P. Sjodin, “Uso de libNetVirt para controlar
la red virtual “, en Proc. IEEE Int. Conf. CLOUDNET, 2012, pp. 148-152.
[200] D. Turull, M. Hidell, y P. Sjodin, “libNetVirt: La red de virtualiza-
biblioteca ción “, en Proc. IEEE ICC, 2012, pp. 5.543-5.547.
[201] R. Sherwood et al., “Flowvisor: Una capa de virtualización de la red,”
Consorcio OpenFlow Switch, OpenFlow-TR-2009-1, 2009. [En línea]. Disponible:
http://archive.open fl ow.org/downloads/technicalreports/ abrir flujo-TR-2009-1- fl owvisor.pdf
[202] R. Sherwood et al., “¿Puede la red de producción será el banco de pruebas?” En
Proc. Conf USENIX noveno. IESO, 2010, pp. 1-6.
[203] R. Sherwood et al., “Talla rebanadas de investigación fuera de su producción
redes con OpenFlow” ACM SIGCOMM Comput. Commun. Rdo.,
vol. 40, no. 1, pp. 129-130, enero de 2010. [204] Y. Yiakoumis, K.-K. Yap, Katti S., G.
Parulkar, y N. McKeown, “Slic-
ing redes domésticas “, en Proc. 2º ACM SIGCOMM HomeNets Taller, 2011, pp. 1-6.
50
[205] A. Bianzino, C. Chaudet, D. Rossi, y J. Rougier, “Un estudio de verde
la creación de redes de investigación” IEEE Commun. Encuestas, Tuts. vol. 14, no. 1, pp. 3-20, Dic de
2012.
[206] D. Staessens, S. Sharma, D. Colle, M. Pickavet, y P. Demeester, “Soft-
utensilios de fi nida en red: requisitos de reuniones con calidad de operador,”en Proc. 18a IEEE
LANMAN taller, 2011, pp. 1-6.
[207] T. Benson, A. Akella, A. Shaikh, y S. Sahu, “CloudNaaS: Una nube
plataforma de red para aplicaciones empresariales,”en Proc. Segundo ACM SOCC, . 2011, pp 8:
1-8: 13.
[208] A. Tavakoli, M. Casado, T. Koponen, y S. Shenker, “Aplicación
NOX al centro de datos “, en Proc. HotNets, Nueva York, NY, EE.UU.,
2009. [En línea]. Disponible: http://conferences.sigcomm.org/hotnets/ 2009 / documentos /
nal103.pdf fi hotnets2009-
[209] M. Moshref, M. Yu, A. Sharma, y ​R. Govindan, “hombre-regla Scalable
agement para centros de datos “, en Proc. 10 de USENIX Conf. INDE, 2013, pp. 157-170.
[210] Q. Zhang, L. Cheng, y R. Boutaba, “Cloud computing: State-of-the-art
y desafíos de la investigación,” J. internet Serv. Appl., vol. 1, no. 1, pp. 7-18, mayo de 2010.
[211] P: Li, J. Huai, J. Li, T. Wo, y M. Wen, “HyperMIP: Hypervisor
controlado IP móvil para la migración en la máquina virtual a través de redes “, en Proc. 11
IEEE Symp ASE., 2008, pp. 80-88.
[212] P. Raad et al., “El logro de los tiempos de parada de fracciones de segundos en virtuales en todo el internet
migraciones en vivo de máquinas en redes LISP,”en Proc. IFIP / IEEE Int. Symp. ESTOY, 2013,
pp. 286-293.
[213] M. Coudron, S. Secci, G. Maier, G. Pujolle, y A. Pattavina, “Impulsar
comunicaciones nube a través de una arquitectura de protocolo crosslayer multipath “, en Proc.
IEEE SDN4FNS, Nov. 2013, pp. 1-8. [214] OpenDaylight. [En línea]. Disponible:
http://www.opendaylight.org/ [215] F. Hao, T. Lakshman, S. Mukherjee, y H. Song, “Mejora de la
dinámica
utilizando los servicios de virtualización de red basado en la nube “, en Proc. 1er Taller ACM
virtualizado Infrastruct. Syst. Archit., 2009, pp. 37-44.
[216] B. Boughzala, R. Ben Ali, M. Lemay, Y. Lemieux, y O. Cherkaoui,
“OpenFlow apoyar la migración de la máquina virtual inter-dominio,” en
Proc. Octavo Int. Conf. WOCN, 2011, pp. 1-7.
[217] J. Matias, E. Jacob, D. Sánchez, y Y. Demchenko, “An OpenFlow
marco virtualización de la red basado en la nube “, en Proc. Int tercero. Conf. CloudComp
Technol. Sci., 2011, pp. 672-678.
[218] V. Mann, A. Vishnoi, K. Kannan, y S. Kalyanaraman, “cruce de caminos:
La movilidad sin VM a través de los centros de datos a través del software de fi nida en red “, en
Proc. IEEE NOMS, 2012, pp. 88-96.
[219] Y. Pu, Y. Deng, y A. Nakao, “Nube de bastidor: Enhanced topográfica virtuales
enfoque de migración logía con el conmutador virtual abierta “, en Proc. ICOIN, 2011, pp. 160-164.
[220] E. Keller, S. Ghorbani, M. Caesar, y J. Rexford, “migración en vivo de una
Toda la red (y sus hosts),”en Proc. 11 de ACM Taller HotNets-
XI, 2012, pp. 109-114.
[221] H. Qian, X. Huang y C. Chen, “Swan: orquestación de extremo a extremo para
la red y de la nube Wan,”en Proc. IEEE Int segundo. Conf. CloudNet, Nov.
2013, pp. 236-242.
[222] N. McKeown et al., “OpenFlow: Habilitación de la innovación en el campus NET
trabajos," SIGCOMM Comput. Commun. Rdo., vol. 38, no. 2, pp. 69-74, marzo de 2008.
[223] OpenFlow Interruptor Consortium. [En línea]. Disponible: http: // www.
abierto ow.org/ fl [224] D. Mattos et al., “OMNI: infraestructura de gestión de OpenFlow,” en
Proc. En t. Conf. NOF, 2011, pp. 52-56.
[225] Trema. [En línea]. Disponible: http://trema.github.com/trema/ [226] Ryu. [En línea]. Disponible:
http://osrg.github.com/ryu/ [227] reflector. [En línea]. Disponible: http: //www.project fl oodlight.org/
[228] N. Gude et al., “NOX: Hacia un sistema operativo para redes”
SIGCOMMComput.Commun. Rdo., vol. 38, no. 3, pp. 105-110, Jul. 2008. [229] NOX. [En
línea]. Disponible: http://www.noxrepo.org/ [230] K.-K. Ladrar et al., “El despliegue OpenRoads de
Stanford,” en Proc. cuarto
ACM Int. WINTECH, 2009, pp. 59-66.
[231] S. Jain et al., “4: Experiencia con un desplegado a nivel mundial en software de fi nido
WAN,”en Proc. ACM SIGCOMM Conf., 2013, pp. 3-14.
[232] N. y J. Feamster Rexford, “Obtención de manos de los estudiantes sucia con limpio-
redes de pizarra,”en Proc. SIGCOMM Educ. Taller, Toronto, ON, Canadá, 2011. [En línea].
Disponible: http://edusigcomm.info.ucl.ac.be/ pmwiki / uploads / Workshop2011 / 20110430002 /
limpieza slate.pdf [233] L. Peterson, T. Anderson, D. Culler, y T. Roscoe, “ Un modelo para
la introducción de tecnología de punta en Internet” ACM SIGCOMM Comput. Commun. Rdo., vol. [258] M. Kind, F. Westphal, A. Gladisch, y S. Topp, “SplitArchitecture:
33, no. 1, pp. 59-64, enero de 2003. [234] Federados E-infraestructura dedicada a los
investigadores europeos
Innovar en Network Computing (Arquitecturas FEDERICA). [En línea]. Disponible:
http://www.fp7-federica.eu/
ENCUESTAS DE COMUNICACIÓN IEEE y tutoriales, vol. 17, NO. 1, PRIMER TRIMESTRE 2015
[235] JGN-X (JGN-extremo). [En línea]. Disponible: http://www.jgn.nict.go.jp/
Inglés / index.html
[236] Internet del Futuro bancos de pruebas Experimentación entre Brasil y Europa
(FIBRA). [En línea]. Disponible: http: // www. Fi bre-ict.eu/ [237] R. Riggio, T. Rasheed, y F. Granelli,
“Empower: un banco de pruebas para la red de
virtualización función de investigación y experimentación,”en Proc. IEEE SDN4FNS, Nov.
2013, pp. 1-5.
[238] U. Holzle, OpenFlow @ Google, abril de 2012. [En línea]. Disponible: http: //
www.opennetsummit.org/archives/apr12/hoelzle-tue-open fl ow.pdf [239] B. Lantz, B. Heller, y
N. McKeown, “Una red en un ordenador portátil: pro rápido
totyping para redes definida por software de,”en Proc. 9th ACM SIGCOMM taller HotNets-IX, 2010,
pp. 19: 1-19: 6.
[240] L. Dong, F. Jia, y W. Wang, “De fi nición e implementación de lógica
bloques de función compatible con las fuerzas especi fi cación,”en Proc. ICONO 15a,
2007, pp. 531-536.
[241] Z. Wang, T. Tsou, J. Huang, X. Shi, y X. Yin, Análisis de
Las comparaciones entre OpenFlow y fuerzas, marzo de 2012, Proyecto de Internet. [En
línea]. Disponible: http://tools.ietf.org/id/draft-wang-forcescompare-open flujo de fuerzas-01.txt
[242] E. Haleplidis, S. Denazis, O. Koufopavlou, J. Salim, y J. Halpern,
“El software de fi nida en red: La experimentación con el control de la interfaz de reenvío
avión”, en Proc. EWSDN, 2012, pp. 91-96.
[243] P. Lin, J. Bi, y H. Hu, “ASIC: Una arquitectura para escalable intra-dominio
de control en OpenFlow “, en Proc. 7º Int. Conf. Internet del Futuro Technol.,
2012, pp. 21-26.
[244] MR Nascimento, CE Rothenberg, D. Salvador, y
MF Magalhães, “QuagFlow: Asociarse con OpenFlow Quagga”
SIGCOMM Comput. Commun. Rdo., vol. 40, no. 4, pp. 441-442, agosto de 2010. [245] MR
Nascimento et al., “routers virtuales como un servicio: El RouteFlow
enfoque de aprovechar las redes software de fi nida,”en Proc. 6º Int. TPI Technol., 2011, pp.
34-37.
[246] Y. Nakagawa, K. Hyoudou, y T. Shimizu, “Un método de gestión de
multidifusión IP en redes superpuestas utilizando de flujo abierto “, en Proc. 1er Taller HotSDN, 2012,
pp. 91-96.
[247] K.-K. Yap, T.-Y. Huang, B. Dodson, MS Lam, y N. McKeown, “To-
redes de salas software amigable “, en Proc. ACM primera Apsys taller,
2010, pp. 49-54.
[248] T.-Y. Huang et al., “PhoneNet: Una red de teléfono a teléfono
la comunicación de grupo dentro de un dominio administrativo,”en Proc. 2do Taller ACM
SIGCOMM Serv., Syst., Appl. MobiHeld, 2010, pp. 27-32.
[249] B. Koldehofe, F. Dürr, MA Tariq, y K. Rothermel, “El poder
de software de redes de fi nida: a velocidad de línea de enrutamiento basado en el contenido con
OpenFlow “, en Proc. 7º Taller MW4NG Internet Comput., 2012, pp. 3: 1-3: 6.
[250] D. Kotani, K. Suzuki, y H. Shimonishi, “Un diseño e implementación
del controlador de OpenFlow manejo de multidifusión IP con conmutación árbol de rápido “, en Proc. IEE
/ IPSJ Int. SMO, 2012, pp. 60-67.
[251] R. Ravindran, X. Liu, A. Chakraborti, X. Zhang, y G. Wang, “Hacia
software de fi ne los servicios en la nube basada borde del CIE,”en Proc. IEEE Int segundo.
Conf. CloudNet, Nov. 2013, pp. 227-235. [252] T. Li, N. Van Vorst, R. Rong, y J. Liu, “Estudios de
simulación de
OpenFlow basados ​estrategias de caché dentro de la red,”en Proc. 15a SNC Symp., 2012, pp.
12: 1-12: 7.
[253] G. Stabler, A. Rosen, S. Goasguen, y K.-C. Wang, “elástico IP y
Los grupos de seguridad de aplicación usando OpenFlow “, en Proc. 6º Int. Taller VTDC, 2012,
pp. 53-60.
[254] J. Rubio-Loyola et al., despliegue “servicio escalable de software-
de fi ne redes” IEEE Commun. Revista., vol. 49, no. 12, pp. 84-93, Dic de 2011.
[255] T. Nadeau y P. Pan, Marco para el software de fi ne Redes,
De octubre de 2011, Proyecto de Internet. [En línea]. Disponible: http://tools.ietf.org/id/
proyecto-Nadeau-SDN-marco-01.txt
[256] ETSI Industria Speci fi cación de grupo para las funciones de red de virtualización
(ISG NFV), las funciones de red de virtualización, una introducción, Bene fi cios, habilitadores,
Desafíos y llamado a la acción, octubre de 2012, Libro Blanco. [En línea]. Disponible:
http://www.cisco.com/en/US/solutions/collateral/ ns341 / ns525 / ns537 / ns705 / ns827 /
white_paper_c11-481360.pdf [257] M. Kuzniar, P. Peresini, M. Canini, D. Venzano, y D. Kostic,
“A SUAVE
camino para las pruebas de interoperabilidad interruptor de fl ujo abierta “, en Proc. Octavo Int. Conf. Emerging
Serv. Exp. Technol., 2012, pp. 265-276.
Aplicando el software de fi ne la creación de redes concepto a las redes de transporte,”en Proc. WTC, 2012,
pp. 1-6.
[259] P. Dely, A. Kassler, y N. Bayer, “fl abierto ow para NET de malla inalámbrica
trabaja en Proc. 20 ICCCN, 2011, pp. 1-6.
XIA et al .: Una encuesta sobre Software-Defined Networking 51

[260] A. Mahmud y R. Rahmani, “Explotación de OpenFlow en inalámbrica
redes de sensores, en” Proc. ICCSNT, 2011, vol. 1, pp. 594-600.
[261] A. Mahmud, R. Rahmani, y T. Kanter, “Despliegue de flujo-sensores
en Internet de la virtualización de las cosas a través de OpenFlow,”en Proc. Tercero FTRA Int. Conf.
MÚSICA, 2012, pp. 195-200.
Wen Feng Xia recibió la licenciatura en ciencias de la computación
de la Universidad de Ciencia y Tecnología de China, Hefei, China,
en 2011. En la actualidad trabaja hacia la maestría de la Facultad
de Ciencias de la Computación y Tecnología, USTC. En la
actualidad trabaja como un proyecto fi cial con la Escuela de
Ingeniería Informática, Universidad Tecnológica de Nanyang,
Singapur. Sus intereses de investigación incluyen las redes
informáticas y la ingeniería de software.
Dusit Niyato recibido el B.Eng. Grado en Ingeniería Informática del
Instituto de Tecnología de Ladkrabang, Bangkok, Tailandia, del rey
Mongkut en 1999 y el doctorado título en ingeniería eléctrica e
informática de la Universidad de Manitoba, Winnipeg, MB, Canadá,
en 2008. En la actualidad es Profesor Asociado de la Facultad de
Ingeniería Informática, Universidad Tecnológica de Nanyang,
Singapur. Sus intereses de investigación incluyen la gestión de
recursos de radio en las redes de radio cognitiva y redes de acceso
inalámbrico de banda ancha.

Haiyong Xie recibió la licenciatura de la Universidad de Ciencia y

Tecnología de China, Hefei, China, en 1997, y la MS y Ph.D.
Yonggang Wen ( S'99-M'08-SM'14) recibió el Ph.D. título en
grados en ciencias de la computación de la Universidad de Yale,
ingeniería eléctrica e informática (de menor importancia en la
New Haven, CT, EE.UU. en 2005 y 2008, respectivamente. En la
literatura occidental) del Massachusetts Institute of Technology
actualidad es el Director Ejecutivo del ciberespacio y el Laboratorio
(MIT), Cambridge, MA, EE.UU.. Ha trabajado en Cisco para liderar
de Ciencias de datos de la Academia China de Electrónica y
el desarrollo de productos en las redes de distribución de
Tecnología de la Información, Beijing, China, y el profesor de la
contenidos, que tuvieron un impacto en los ingresos de 3 $ billón en
Facultad de Ciencias de la Computación y Tecnología de la
todo el mundo. Ha publicado más de 100 artículos en revistas y
Universidad de Ciencia y Tecnología de China, Hefei, China. Fue el
conferencias de prestigio. En la actualidad es profesor adjunto de la
Principia
Escuela de Ingeniería Informática, Universidad Tecnológica de
Nanyang,
Investigador cipal para Huawei laboratorios de investigación de Estados Unidos y el Grupo de Trabajo P4P
(P4PWG) y Distributed Computing Industry Association. Propuso P4P (participación de los proveedores
Singapur. Sus intereses de investigación incluyen la computación en nube, los centros de datos verdes,
proactivos en P2P) para coordinar los proveedores de redes y aplicaciones peer-to-peer en un artículo seminal
análisis de grandes volúmenes de datos, redes multimedia, y la informática móvil. Su último trabajo en
publicado en SIGCOMM ACM
televisores sociales multipantalla nube ha sido presentado por la prensa mundial (más de 1600 artículos de
2008, y conducido y llevado a cabo pruebas de investigación originales y de gran escala en el P4P. Alentado
noticias procedentes de más de 29 países) y reconocido con la ASEAN Premio TIC 2013 (medalla de oro) e
por y basado en sus investigaciones y resultados en el P4P, se formó la P4PWG promover estudios
IEEE Globecom 2013 Best Paper Award. Es miembro de los consejos editoriales de IEEE T PERACIONES
académicos y adopciones industriales de P4P, que posteriormente fue adoptado por el IETF para formar una
EN M ULTIMEDIA, IEEE ACCESO J OURNAL, y Elsevier redes ad hoc.
nueva capa de aplicación Traf fi c optimización del Grupo de Trabajo (ALTO). Su interés de investigación
incluye la creación de redes contentcentric, fi nida de redes de software-de, futura arquitectura de Internet, y la
ingeniería de tráfico de red fi co.

Chuan Heng Foh ( S'00-M'03-SM'09) recibió el M.Sc. título de la

Universidad de Monash, Clayton, Vic., Australia, en 1999 y el
doctorado grado de la Universidad de Melbourne, Parkville, Vic., en
2002. Después de su Ph.D. los estudios, pasó seis meses como
profesor de la Universidad de Monash. De 2002 a

2012, fue Profesor Adjunto de la Universidad Tecnológica de

Nanyang, Singapur. En la actualidad es profesor titular de la
Universidad de Surrey, Surrey, Reino Unido Es autor o coautor de
más de 100 artículos en revistas arbitradas internacionales y

conferencias. Sus áreas de investigación incluyen el diseño de protocolo y análisis de rendimiento de

varias redes de ordenadores tales como las redes de área local inalámbricas y de malla, y redes
móviles ad hoc y de sensores, redes de quinta generación, y redes de centros de datos. Participa
activamente en la conferencia IEEE y la organización del taller, incluyendo el Taller Internacional
sobre Cloud Computing Sistemas, Redes y Aplicaciones (CCSNA), donde es un miembro de la
dirección. En la actualidad es editor asociado de IEEE ACCESO, IEEE W Inalámbricos C OMUNICACIONES,
y Revista Internacional de sistemas de comunicaciones. Él es también el Presidente del Grupo de
Interés Especial sobre Green Data Center y Cloud Computing en el marco del Comité Técnico IEEE
sobre Comunicaciones verdes y Computación.