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

El contenido puede cambiar antes de la publicación final. información de referencia: DOI

10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales

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, 1.4 dispositivos móviles per cápita [9]. Las redes sociales también han
y datos grandes) en Tecnologías de la Información (TIC) y están ordenando nuevos retos para el futuro de Internet, experimentado un crecimiento espectacular en los últimos años. Por ejemplo,
para los que la accesibilidad ubicua, gran ancho de banda, y la gestión dinámica son cruciales. Sin embargo, los
Facebook amplió de 1 millón de usuarios en diciembre de 2004 a más de 1 mil
enfoques tradicionales basados ​en el manual con fi guración de los dispositivos patentados son engorrosos y
millones de usuarios activos en octubre de 2012 [10]. Por último, el cloud
propenso a errores, y no pueden utilizar plenamente la capacidad de la infraestructura de red física. Recientemente,

software-de fi nido Networking (SDN) ha sido considerada como una de las soluciones más prometedoras para el
futuro de Internet. SDN se 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 artículo examina últimos avances en esta área de
investigación activa de SDN. Primero se presenta una aceptación general de fi nición de SDN de los citados dos
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 autogestionado [2], dictando un
alto nivel de automática con fi guración de el sistema. Al mismo tiempo, con

rasgos característicos 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 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. que incluye una capa de infraestructura, una capa de control, y una
más recursos de cálculo y almacenamiento colocados de forma remota en la
nube, ef acceso deficiente a estos recursos a través de una red se está
convirtiendo en fundamental para las necesidades informáticas de hoy ful fi ll.
Como tal,

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. que incluye 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 de la
aplicación de facto SDN (es decir, OpenFlow). Por último, concluimos este trabajo encuesta con algunos retos de
investigación abiertas sugeridas.
Términos del Índice -software de fi nida en red, SDN, la red vir-
tualization, OpenFlow
I. INTRODUCCIÓN
En respuesta a los requisitos antes mencionados para las redes de ordenadores, una
solución inmediata sería hacer una inversión adicional en la infraestructura de red para
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
en 2016, por encima de más de un dispositivo conectado en red y 4 gigabytes de datos
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
tamaño enorme. Incluso la red de una organización de tamaño medio, por ejemplo, una
red de campus, podría estar compuesto por cientos o incluso miles de dispositivos [12].
En segundo lugar, las redes son muy heterogéneas, especialmente cuando los equipos,

mi
aplicaciones, y los servicios son proporcionados por diferentes fabricantes, vendedores y
en particular,
FUSIÓN los grandes
grandes datos
tendencias móvil,
en el social,
ámbito de lasnube [2] yen[3], [4], están
TIC [1], proveedores. En tercer lugar, las redes son muy difíciles de gestionar. Los factores
instando a las redes informáticas de gran ancho de banda, la accesibilidad en humanos son reportados a ser el mayor contribuyente a la red el tiempo de inactividad,
todas partes, y la gestión dinámica. En primer lugar, la creciente popularidad de responsable del 50 al 80 por ciento de las interrupciones de dispositivos de red [13].
los contenidos multimedia ricos y el aumento de la demanda de analítica de Esta creciente complejidad exige además nuevos enfoques para las futuras redes de
grandes datos de un conjunto diverso de fuentes de datos, están exigiendo una ordenadores, en los que la complejidad puede ser controlada.
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
servidor a servidor de trá fi co en los centros de datos para dividir los datos de Debido a su tamaño, la heterogeneidad y complejidad de la actual y, posiblemente,
entrada y combinar los resultados de salida. En segundo lugar, una gran las futuras redes de ordenadores, los enfoques tradicionales para la con fi guración,
penetración de los dispositivos móviles y las redes sociales es exigente optimización y resolución de problemas se convertirían en ine fi ciente, y en algunos
comunicaciones ubicuas a fi ll cumplir las necesidades sociales de la población casos, insu fi ciente. Por ejemplo, del sistema autónomo (AS) basados ​enfoques a
en general. 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
Wen Feng Xia, Yonggang Wen y Dusit Niyato son con la Escuela de Ingeniería Informática de la
subóptimo con una ganancia de rendimiento mundial marginal. Por otra parte, la
Universidad Tecnológica de Nanyang (NTU), Singapur. E-mail: {Wenfeng Xia, ygwen,
dniyato}@ntu.edu.sg.
aplicación de optimizaciones locales en un único dominio, sin coordinación entre
Chuan Heng Foh es con el Centro para la Investigación de Sistemas de Comunicación en la Universidad de dominios, puede causar operaciones innecesarias conflictivas con resultados
Surrey, Reino Unido. E-mail: c.foh@surrey.ac.uk.
indeseables. La situación podría empeorar como la red de legado plata-
Haiyong Xie es con el Laboratorio para el ciberespacio y Ciencia de Datos de la Universidad de
Tsinghua y la Academia China de Electrónica y Tecnología de la Información. E-mail:
haiyong.xie@acm.org.

1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales
formas 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.
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 retroalimentación con mejores decisiones
basadas en una visión global de la red y la información crosslayer.
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 discute enfoques para
construir dispositivos y desafíos de la utilización de diferentes medios de
transmisión de conmutación SDN-capaz. 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 Y ENEFICIOS 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
1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
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 interdominio se sustituye por control
de encaminamiento centralizado para reducir la complejidad de cálculo de ruta
totalmente distribuida. En el mismo año, 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 reenvío de paquetes real en
redes GMPLS [44] MPLS y. 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 datos de control de avión. por
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales
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 beneficios potenciales de una mayor con fi guración, mejorar el
rendimiento, y alentó a la innovación en la arquitectura y las operaciones de la red.
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 de sintonización a un
nivel de enlace de datos, rompiendo la barrera de 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.
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 red
1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
dispositivos de [50], incluyendo conmutadores, routers, 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, no puede resolver el problema por completo. 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. 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. 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
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales
TABLA I
do OMPARISONS ENTRE SDN Y C ONVENTIONAL N ETWORKING
SDN
datos desconectados y plano de control, y programabilidad
Caracteristicas
Con fi guración automatizado con fi guración con la validación centralizado
Actuación control global dinámico con información de la capa transversal
una fácil implementación de software para nuevas ideas, entorno de prueba suf fi ciente con
Innovación el aislamiento, y el despliegue rápido usando la actualización del software
Figura 1. SDN Modelo de referencia: un modelo de tres capas, que van desde una capa de la
infraestructura a una capa de control a una capa de aplicación, de una manera bottomup.
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
ONF es de ninguna manera el único estándar SDN y de ninguna manera una solución
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
alto nivel que aún falta para el desarrollo de aplicaciones SDN. Un ecosistema saludable
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.
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
1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
Redes convencionales
un nuevo protocolo por problema, control de red complejo [49]
propenso a errores con manual de fi guración
información limitada, y con fi guración relativamente estático
implementación de hardware dif fi cil para las nuevas ideas, entorno de prueba
limitada, proceso de normalización de largo
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 los controladores. El estado de la red puede incluir información tal como
la topología de red, estadísticas de tráfico c, y usos de la red. En segundo lugar, que son
responsables de procesar paquetes basados ​en reglas proporcionadas por un controlador.
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.
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.
En esta encuesta, se adopta este modelo de referencia como un hilo para organizar los
esfuerzos de investigación existentes en SDN en tres secciones.
III. yo NFRAESTRUCTURA L AYER
En la capa más baja en el modelo de referencia SDN, la capa de infraestructura consiste
en dispositivos de conmutación (por ejemplo, conmutadores, enrutadores, etc.), que están
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,
la radio inalámbrica, y también fibras ópticas. En la Fig. 2, se ilustra una red de referencia
permitido-SDN. En particular, las principales preocupaciones de investigación asociados con
la capa de infraestructura incluyen tanto las operaciones de fi cientes de dispositivos y la
utilización de los medios de transmisión de conmutación, como se detalla en los siguientes
dos subsecciones.
A. dispositivos de conmutación
En la Fig. 3, se ilustra el diseño arquitectónico de un SDN dispositivo de
conmutación, que consta de dos componentes lógicos para
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales

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.

solución costo.
Esta nueva arquitectura, sin embargo, requiere nuevo diseño de hardware para dispositivos

de conmutación compatibles con SDN. En este apartado, se describen las investigaciones

recientes que avanza en el cambio de diseño de hardware del dispositivo, centrándose tanto en

el plano de control y el plano de datos. También vamos a clasificar las plataformas de

dispositivos de conmutación más populares, y discutir la prueba y evaluación de estos

dispositivos de conmutación.

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

Fig. 3. Conmutación modelo necesario en SDN: un modelo lógico de dos capas
que consta de un procesador para el reenvío de datos y la memoria de información de control de a bordo.
el plano de datos y el plano de control. En el plano de datos, el dispositivo de
conmutación, en particular, a través de su procesador, realiza el reenvío de
paquetes, basándose en las reglas de reenvío impuestas por la capa de control. Los
ejemplos de procesadores de red incluyen la familia de procesadores XLP
(arquitectura MIPS64) de Broadcom, el procesador XScale (arquitectura ARM) de
Intel, NPX NPU de EZCHIP, PowerQUICC procesadores de comunicaciones
(arquitectura de alimentación) de Freescale, procesadores de la serie PFN
(arquitectura ARM) de Netronome, Xelerated HX familia de Marvell, procesadores de
la serie OCTEON (arquitectura MIPS64) forma 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.
de los principales retos de diseño reside en el uso e fi ciente de memoria interna.
Fundamentalmente, el uso de memoria en un dispositivo de conmutación depende de la
escala de la red. Específicamente, los dispositivos de conmutación en una red de escala más
grande necesitaría un espacio de memoria más grande; de lo contrario, pueden necesitar
actualizaciones de hardware constantes para evitar el agotamiento de memoria. En caso de
insu fi espacio de memoria ciente, los paquetes se caen o se dirigen a los controladores para
nuevas decisiones sobre cómo procesar ellos, dando como resultado un rendimiento de la red
degradada [64].
técnicas de gestión de memoria en el diseño del interruptor tradicional se pueden ampliar
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 memoria e fi cientemente. 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.

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

enrutamiento que decidir cómo reenviar paquetes, tomas de decisiones de enrutamiento se
eliminan 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 paquetes en base a las reglas de reenvío impuestas. De ello se
desprende que la SDN dispositivos de conmutación son más simples y será más fácil de fabricar.
La complejidad reducida a su vez conduce a una baja
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

1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales
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.
Segundo, la distinta naturaleza para el “elefante” y
“Ratones” flujos pueden ser explotadas. 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:
• Aplicación en el PC en general Hardware: 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 generalpurpose 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
1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
vSwitch abierto [74], [75] puede 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.
• 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 OFLOPS (Operaciones OpenFlow por
segundo) 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, debe integrar SDN
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales
Aplicación en el PC General de Hardware
Categoría
Plataforma o
Representante
Procesamiento de velocidad baja
densidad de puertos Bajas, limitado a la cantidad de tarjetas de red Oriente, 4 puertos para NetFPGA
Alta, todas las funciones están el software de fi nido
Flexibilidad
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 controladores SDN una gran oportunidad para
tener un control generalizado sobre todos los comportamientos de la red, incluyendo el
reenví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 (FFT) probablemente con diferentes longitudes
FFT. 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.
1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
TABLA II quipos SDN S
WITCHING D
Implementación en hardware de red abierta Aplicación en el interruptor del vendedor
Medio, de 1 Gbps o 10 Gbps para NetFPGA Alta, por lo general de 1 Gbps y por encima
De altura, por lo general los puertos 48 y más
Medio Bajo
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 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 control GMPLS que gestiona la
red óptica. A lo largo de esta línea de la lógica, Casado et al. sugerir borde de
desacoplamiento de transporte y el núcleo [105], [106]. Presentan “tejido” donde regulación
de bordes de manejar los requisitos del operador; de borde de entrada conmuta junto con
sus requisitos de host mango controladores; interruptores en los paquetes hacia adelante
simplemente “tejido”.
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales
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.
Del mismo modo, Azodolmolky et al. 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 controlar la red, incluidas las políticas impuestas por las reglas de
reenvío de la capa de aplicación y de paquetes 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 refiere a las transacciones
1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
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.
Aprovechando estos principios de la arquitectura, el diseño lógico para los controladores
SDN se puede desacoplar en cuatro componentes del edificio, es decir, un lenguaje de alto
nivel, un proceso de actualización regla general, un proceso de recolección de estado de la
red, y un proceso de sincronización de estado de la red. En este apartado, se adopta esta
estructura para explicar los esfuerzos de investigación existentes en el diseño del controlador
en los grupos antes mencionados.
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
Kit Una plataforma (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 el control de comportamiento de la red e
fi ciente para la 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 párrafos siguientes,
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 granulares finas de OWS y soportes fl red
unidireccionales
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales
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
gestión de la política [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. Una sola onesize- 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, la autenticación de usuario y la ingeniería
tráfico c. 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 programador suministrado 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
1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
y reduce por lo tanto 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.
tabla de flujo perdido los paquetes tienen que ser procesados ​en el controlador, y el
planificador se aplica “paralelismo a nivel de interruptor” en los servidores de núcleos
múltiples, la unión de rosca, la memoria, y el bucle de procesamiento de eventos del
controlador a un interruptor de “cliente” particular.
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.
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 puesto delante de la de flujo se dirige al controlador y el estado actualizado establecido
después de que el fl ujo se libera de nuevo a cambiar
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales
dispositivos. Esta es una condición no deseada que puede ocurrir en consistencia
eventual. No obstante, la coherencia de eventos podría ser una opción cuando el espacio
de memoria es escasa.
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,
“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 se ajustan a los paquetes con 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 hash
1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
10
código 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. Su implementación
prototipo de OpenSketch en NetFPGA no muestra ningún efecto en el rendimiento del
plano de datos y alrededor de 200 nanosegundos proceso de retardo para 5 cambios de
contador por paquete.
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 una visión
global de la red sincronizada. 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 doble función. Se puede utilizar para
compartir y sincronizar la información de estado de la red, y coordinar los
procesos de toma de decisiones controladores.
postergación 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 una base de datos transaccional persistente
respaldado por una máquina de estados 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 SDN
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales
redes. 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 de dominio entre 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. presentar 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.
1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
11
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 rendimiento en procesadores multinú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 NOXMT más de 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 46 núcleos, el logro de rendimiento de más de
14 millones de flujos por segundo. 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 46 núcleos, el logro de rendimiento de más de 14 millones
de flujos por segundo. 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]. Mc
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 por “autoridad
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales
interruptores”según sea necesario para acceder a las reglas apropiadas, por lo tanto todos los
paquetes pueden ser manipulados 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 el rápido cambio de ruta
después de 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 networkwide y se ocupa de 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
1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
12
las redes físicas subyacentes utilizando un lenguaje de alto nivel proporcionado 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 implementaciones del algoritmo de balanceo de carga dedicada y
especializada y no quieren afectan entre sí, aunque algunas implementaciones de
balanceo de carga se descomponen. En esta consideración, Koerner et al. introducir
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
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales

13

TABLA III
E Xperiment S ETUP DE SDN A plicaciones

Nombre Estándar Método Escala Controlador Cambiar

Plug-n-Serve [53], banco de pruebas reales [172] OpenFlow sobre 10 conmutadores a base de NOX interruptores comerciales de Cisco, HP y NEC, y
NetFPGA basan-
Panel [55] OpenFlow MiniNet vSwitch abierto basado en la ortiga
simulación
QNOX [56] Efectivo banco de 6 servidores de PC de alojamiento 114 FE construir sobre conmutadores basados ​CE Linux en máquinas virtuales

pruebas virtuales

OpenRoads [173] - [175] OpenFlow banco de pruebas reales 5 conmutadores de Ethernet, 30 puntos de NOX interruptores de NEC y HP, WiMAX estación base construida por
acceso WiFi, y 1 WiMAX estación base NEC, y los puntos de acceso WiFi a base de cajas de ALIX
PCEngine
Odin [176] OpenFlow banco de pruebas reales un cliente, un servidor, y 2 puntos de acceso NOX vSwitch abierta en la tarjeta inalámbrica Atheros AR9280

OFRewind [177] OpenFlow banco de pruebas reales 10 PCs, 5 interruptores NOX interruptores de 3 proveedores
DE-RHM [178] OpenFlow MiniNet 2 conmutadores virtuales NOX vSwitch abierto basado
simulación
AnonyFlow [179] OpenFlow banco de pruebas reales 4 interruptores a base de NOX 2 interruptores comerciales y 2 conmutadores basados
​NetFPGA
ElasticTree [54] OpenFlow banco de pruebas reales 3 conmutadores físicos NOX interruptores de NEC y HP

Alabama. presente Plug-n-Serve (ahora llamada Aster * x [53]), que equilibra la carga sobre una red híbrida con Ethernet y conmutadores ópticos. Sus informes de análisis
una red no estructurada arbitraria usando una implementación de SDN [172]. Controla preliminares mejoraron rendimiento de la aplicación y utilización de la red con
directamente caminos tomados por nuevas peticiones HTTP para minimizar el tiempo de relativamente baja sobrecarga con fi guración.
respuesta promedio de los servicios web.

2) Diseño Cruz-capa: Un enfoque cross-layer es una técnica muy promocionado para B. Roaming sin límites
mejorar la integración de las entidades en diferentes capas en una arquitectura de capas,
Los teléfonos inteligentes y las tabletas se están convirtiendo en dispositivos que
por ejemplo, el modelo de referencia OSI, permitiendo a las entidades en diferentes capas
dominan en el acceso a Internet. Estos dispositivos móviles acceder a Internet de
para intercambiar información entre sí. Como SDN ofrece una plataforma de aplicaciones
forma inalámbrica. Para garantizar la conectividad continua, mientras que estos
para acceder fácilmente a la información de estado de red, los enfoques crosslayer se
dispositivos se mueven de un lugar a otro, las conexiones pueden ser entregados
pueden desarrollar fácilmente en esta plataforma. En los párrafos siguientes, se presentan
desde una estación base a otra, o incluso de una red inalámbrica a otra. Uniformidad
casos de uso para proporcionar QoS garantizados y la mejora de rendimiento de las
de traspaso es crítico para aplicaciones para proporcionar un servicio ininterrumpido.
aplicaciones que aprovechan la técnica de diseño de capa cruzada.
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
Muchas aplicaciones de red requieren un cierto nivel de soporte de QoS. Utilizando
la movilidad ilimitada con seamless handover conexión inalámbrica entre diferentes
información de QoS para una reserva adecuada de recursos de red representa un enfoque
tecnologías y portadores, como se muestra en la Fig. 2.
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
Varios esquemas de transferencia se han desarrollado sobre la base de SDN.
hora más temprana a la que una llamada de vídeo o, alternativamente, una llamada de
Por ejemplo, Yap et al. proponer algoritmos de traspaso entre redes Wi-Fi y
audio se pueden hacer con la garantía de calidad se calcula [55]. Como otro ejemplo, Jeong et
WiMAX, incluyendo Hoolock, que explota varias interfaces en un dispositivo, y norte-
al. presentes compatibles con QoS de red del sistema operativo (QNOX) para ofrecer
casting, que duplica tráfico c a través norte caminos distintos [173] - [175]. Estos
servicios de calidad de servicio garantizados, tales como QoS-aware incrustación de red
esquemas de transferencia se pueden implementar fácilmente con NEE para
virtual y la evaluación de calidad de servicio de red de extremo a extremo [56]. Para una
reducir la pérdida de paquetes y mejorar el rendimiento TCP durante el traspaso.
solicitud exigentes una red virtual con requisitos de QoS en el ancho de banda de enlace
Otro caso de uso es Odin, que es un marco SDN prototipo para redes WLAN
virtual y el retardo entre los nodos virtuales, QNOX hará mapeo compatibles con QoS para
empresariales [176]. Odin asigna una única fi cación identi conjunto de servicios
la red virtual en la red de sustrato. QNOX también supervisa la QoS de extremo a extremo
básicos (BSSID) para cada cliente conectado. Traspaso se realiza retirando el
que ofrecen resultados medidos para ayudar a hacer cambios operacionales.
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.

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
Mantenimiento C. Red

Hadoop como un ejemplo y diseño de estrategias de planificación de tareas de Hadoop errores guración fi estafadores son causas comunes de fallas en la red. Se ha
para acomodar red dinámica con fi guración de informado de que más del 60% de inactividad de la red se debe a errores con fi
guración humanos [185]. Lo que lo hace peor es

1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales

14

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
automatizada e integral mantenimiento de la red. 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 La figura 5. La virtualización de red:. Múltiples redes virtuales se pueden crear en la misma red física,
compartiendo los recursos de infraestructura. Una aplicación SDN sólo puede supervisar y recursos
similar, OFRewind registra constantemente eventos de red que aparecen en una red. Una
de los usuarios de su propia red virtual.
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.
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 punto final en forma
anónima dentro de la red 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].
E. virtualización de redes
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 papel significativo en el modelo IaaS. Una práctica común de virtualización de la red
es para cortar una red físico en múltiples instancias virtuales y asignarlos a los
diferentes usuarios, controladores o aplicaciones SDN, como se ilustra en la Fig. 5.
Métodos de virtualización convencional usando túneles y etiquetas VLAN o MPLS
requieren configuraciones fi tediosas en todos los dispositivos de red implicados. Como
comparación, SDN ofrece una plataforma que permite con fi guración de todos los
dispositivos de conmutación 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 la investigación experimental

1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales

15

mentaciones [203] y para compartir una red física con varios usuarios con aislamiento
claro [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
Fig. 6. Interruptor OpenFlow. La tabla de flujo es controlado por un controlador remoto a través del canal
consumo energético, consciente de la energía de trá fi co proxy, infraestructura de energía y
seguro [222].
cuenta con reconocimiento de aplicaciones de energía, como se sugiere en [205].

Resulta que los dispositivos de conmutación SDN no pueden ofrecer directamente bene
fi cios en la reducción de energía en el funcionamiento de la red [206]. Sin embargo, SDN
podría ofrecer promesas significativas en el apoyo a la minimización del consumo de
energía de toda la red. Como prueba, Heller et al. demostrar la adaptación de enlace de
datos-consciente de energía con SDN [54]. Proponen un mecanismo para determinar
enlaces de datos mínimos y dispositivos de conmutación para una red de centro de datos
basado en las cargas tráfico c y dinámicamente apagar enlaces redundantes y dispositivos
de conmutación para las operaciones de fi cientes energía.
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.
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. IP móvil y /
Identi fi cador de Protocolo Separación Locator (LISP) soluciones basadas [211] - [213]
pueden fi jar este tema y han inspirado soluciones SDN. 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. 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.

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 una nube virtual de la regla de base de información
(vCRIB) para superar estas limitaciones de recursos [209]. vCRIB Fi automáticamente la
colocación NDS regla óptima entre los conmutadores físicos y virtuales
VI. do ASE EN PAG OINT: O BOLÍGRAFO F BAJO
OpenFlow es primera propuesto por McKeown et al. con el objetivo de permitir a la
red experimentos sencillos 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, los investigadores descubrieron que la implementación de una red controlable
software por separado usando OpenFlow es en realidad un habilitador práctica del
llamado “software-de fi nido en red”.

1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales
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 crear
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. 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,
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
2012, lo que añade 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. Los interruptores primera OpenFlow se
construyen utilizando hardware de red abierta, por ejemplo, NetFPGA [80], [81].
Después de la aparición primera,
1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
dieciséis
proveedores, incluyendo NEC, IBM, Juniper, HP, Cisco, Huawei, Pica8 / Pronto,
Centec, Dell / Force10, Detalle, Mellanox, NoviFlow, Arista, Brocade, NetGear y
muchos más, empezar a liberar sus conmutadores de OpenFlow. 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 vista de red centralizada utilizando nombres de alto nivel en
comparación con algoritmos distribuidos más de
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales

17

(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;

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.
• 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;

TABLA V
do OMPARISONS ENTRE O PEN F LOW Y F O CES
• Reenvío de modelo: OpenFlow modelo reenvío proporciona programabilidad que
está restringida a prede fi capacidades definidas de interruptores OpenFlow. Por
OpenFlow Efectivo
Gol implementación de SDN separación de reenvío ejemplo, acciones sólo prede fi nida pueden ser elegidos para procesar un
y planos de control paquete con OpenFlow. Fuerzas lógica de envío es más flexible, ya que la
Arquitectura ambos dispositivos de red y red de arquitectura
función de cada LFB y la topología LFB puede ser dinámicamente especi fi. Por
la arquitectura se cambian permanece sin cambios
reenvío tabla de flujo Bloque funcional lógica lo tanto, las nuevas acciones de procesamiento de paquetes pueden ser
Protocolo creados;
modelo Protocolo OpenFlow Fuerzas PL y TML
Interfaz y DE-Con fi g
• 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

direcciones de bajo nivel. Las aplicaciones se escriben ya sea Python o C ++ y se modo de ejecución, y la canalización de comandos.

cargan de forma dinámica. infraestructura básica y las funciones de velocidad crítica

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 CLI (Command-Line Interface)
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.
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.
VII. do CONCLUSIÓN, re DISEÑO GRAMO Y IRECTRICES 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

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. 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.
de investigación.
A. Resumen y conclusión
Los recientes desarrollos en ámbito de las TIC, por ejemplo, móvil, multimedia,
nube, y los datos grandes, están exigiendo para un acceso más cómodo a Internet,
más ancho de banda de los usuarios, así como una gestión más dinámica de los
proveedores de servicios. SDN se considera como una solución prometedora para
satisfacer estas demandas. En el presente trabajo, hemos presentado el concepto
de NEE y destacó bene fi cios de SDN en ofrecer una mayor con fi guración,
mejorar el rendimiento, y alentó la innovación. Por otra parte, hemos proporcionado
una encuesta reciente de la literatura SDN investiga 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.

1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales

18

TABLA IV O PEN F LOW C

ONTROLLERS

Nombre Plataforma Organización Caracteristicas Sitio

NOX / POX C ++ / Python Stanford el controlador de OpenFlow primera http://www.noxrepo.org/
Faro Java Stanford apoyar tanto la operación basada en eventos y roscado, https: // fl abierta ow.stanford.edu/display/Beacon/Home
proporcionar la interfaz de usuario Web

Luz de inundación Java big Switch desarrollador de usar con un montón de documentos http: // fl fl oodlight.open owhub.org/

Ryu Pitón laboratorios NTT con el apoyo de OpenStack http://osrg.github.io/ryu/

grupo OSRG
Maestro Java Rice University El soporte multi-hilo http://code.google.com/p/maestro-platform/
OMNI Pyhton / Java Universidade Federal interfaz web de NOX http://www.gta.ufrj.br/omni/
do Rio de Janeiro
McNettle Haskell Universidad de Yale de alto nivel de lenguaje expresivo declarativa, la http://haskell.cs.yale.edu/nettle/mcnettle/
optimización multi-core
Trema Rubí / C DSL red virtual http://trema.github.io/trema/
OpenDaylight Java Fundación Linux proporcionar API REST y la GUI Web http://www.opendaylight.org/
Controlador

TABLA VI SDN R
ELACIONADAS R ESEARCHES

Capa Problema Enfoque y Referencia Área relacionada

reducir el uso de la memoria [65], Circuitos integrados,
Almacenamiento uso e fi ciente de la memoria [66], Sistemas embebidos,
combinar diferentes hardwares de almacenamiento [67], [68] Las pruebas de hardware

dispositivo de conmutación de Tratamiento combinar diferentes hardwares de procesamiento [69] - [71]

Implementación de software,
Plataforma de hardware aplicación fi rmware,
Infraestructura implementación en hardware abierto
plataforma de [32], [76] - [78]
Evaluación del desempeño [83], [84]
Radio inalámbrico OpenRadio [87] SDR [85],
Transmisión Mobile Ad Hoc
Medios de comunicación Fibras ópticas uni plano de control fi ed [94] - [103], [107], avión división
de control [105], [106], [108], [109] GMPLS, ROADMs [92]

FML [55], [111], [118], [119], Lenguaje de programación,

Lenguaje de alto nivel Frenetic [112], [113], [120] - [122], Métodos formales,
hacia el sur Ortiga [114] - [117] Los compiladores

Flujo de datos regla de actualización [126] - [128] Sistema distribuido

Política y Estado FlowChecker [145], NICE [147] - [150], Los métodos formales

Validación VeriFlow [152] - [154]

Controlar Estado de la red OpenTM [131] red de Medida
Dirección norte Colección
Flujo de datos Estado de la red HyperFlow [142], Onix [143] Sistema distribuido,
Sincronización Base de datos [243]

Incrementar paralelismo [156] - [158] Análisis de algoritmos,

Actuación Capacidad de procesamiento Ingeniería de software
Disminución “autoridad interruptores” [163], DevoFlow [164],
solicitud de frecuencia Kandoo [165]

equilibrio de carga [53], [124], [172], [183], Routing [244], [245],

enrutamiento adaptativo diseño cross-layer [55], [56], [184], Tra fi co Ingeniería,
multicast [246], [246] - [250] NDN [61], [251]
Movilidad sin límites OpenRoads [173] - [175], Odin [176] Red inalámbrica,
consolidar la seguridad detección de ataques [71], [188], de anonimización [179], La seguridad informática,

Solicitud MTD [178], el control de acceso [195] - [197] La externalización de funciones [189],

Red FlowVisor [201], [202], La virtualización de red,

virtualización virtualización de nivel de idioma [121] Caché web [252],
La facilidad de mantenimiento depurador [177], [186], la restauración [187]
Redes verde ElasticTree [54] Redes verde,
Computación en la nube vSwitch abierto [74], [75], VM
migración [182], [215] - [220] Nube [207], [253], [254]

B. Pautas de diseño esbozar algunas pautas de diseño para el desarrollo y la investigación futura
en SDN:
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. • Un dispositivo de conmutación de SDN es relativamente simple, con un plano de control

Se necesita la colaboración de diferentes organizaciones, incluyendo proveedores, separado. El dispositivo de conmutación de SDN puede ser más fácil de fabricar y su costo

instituciones académicas y las comunidades, y el conocimiento interdisciplinario será más barato utilizar el silicio comercial. Sin embargo, las cuestiones sobre el cambio de

que cubren tanto de hardware como de software. En los párrafos siguientes, se diseño de hardware del dispositivo están todavía abiertas. Específicamente, SWITCH- SDN

1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales

19

TABLA VII C ACTUAL I

NVESTIGACIÓN P ROYECTOS

Nombre Área de investigación Organización Dirección del sitio

ONRC moderna SDN Pila, OpenRadio y software de fi nido celular, de alambre Stanford, Berkerly http://onrc.net/
menos conmutador de red, el rediseño de la pila de red para dispositivos móviles,
OpenFlow optimizado ASIC de diseño, SDN para el hogar Redes, Análisis Espacial
Cabecera, equilibrio de carga como una primitiva red, unificada arquitectura de control de
paquetes y de circuitos Networks, SDN Aproximación al fi co Ingeniería MPLS Traf y redes
privadas virtuales.

CRISTAL Participativa redes (PANE) es un controlador de OpenFlow prototipo de integración de los usuarios Universidad de Brown http://pane.cs.brown.edu/
finales, los anfitriones y aplicaciones de gestión de la red por las solicitudes de apoyo de recursos, trá
fi co consejos y consultas de estado.
Frenético Un lenguaje de programación para redes OpenFlow. Cornell, Princeton http://www.frenetic-lang.org/
Bismark plataforma OpenWRT-base para realizar mediciones de per- ISP Georgia Tech, http://projectbismark.net/
Formance, así como trá fi co dentro de la casa. Universidad de
Nápoles Federico II
servicios de enrutamiento IP RouteFlow virtualizado más de hardware habilitado OpenFlow. CPqD https://sites.google.com/site/route flujo /
herramientas InCNTRE SDN pruebas, metodologías y procedimientos. Universidad de Indiana http://incntre.iu.edu/SDNlab
Programas

relacionados Federated E-infraestructura dedicada a los investigadores europeos innovando en principalmente http://ec.europa.eu/research/fp7/
SDNLab 7PM arquitecturas de red informática (FEDERICA), Split Arquitectura Carrier Grade Redes organizaciones en
SDN (SPARC), OpenFlow en Europa Vinculación de Infraestructura y Aplicaciones (OFELIA), la Europa

Internet del Futuro bancos de pruebas de experimentación entre Brasil y Europa (FIBRA),
OpenFlow experimento en tiempo real de Internet Edutainment (OFERTIE)

ing dispositivos necesitan más espacio de memoria y mayor velocidad de • SDN proporciona una plataforma para implementar diversas aplicaciones SDN. SDN

procesamiento con un coste económicamente viable. La integración de diversas aplicaciones pueden acceder a una vista de red y la capa cruzada mundial de información

tecnologías de hardware nuevos es necesario. para tomar mejores decisiones de operación de la red. SDN controladores aseguran que

• SDN se desarrolló originalmente para las redes basadas en IP en los estas decisiones se llevan a cabo adecuadamente en la capa de infraestructura. Sin

campus. Por lo tanto, la ampliación de cobertura ubicua de SDN requiere uni embargo, se requiere la participación de los desarrolladores de software para convertir las

fi cación y la integración con tecnologías avanzadas en la transmisión ideas innovadoras de soluciones que pueden traer beneficios económicos, sociales y

inalámbrica y óptica (es decir, SDR y GMPLS, respectivamente). Estas medioambientales.

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.
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,

1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales
• 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
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.
UN CKNOWLEDGMENT
Haiyong Xie es apoyado en parte por la Fundación Nacional de Ciencias
Naturales de China (SNCF) con la subvención No.
61073192, por el Programa de Investigación Fundamental Gran China (973
programas) con la subvención No. 2011CB302905, por el Programa de talentos
excelentes nuevo siglo, y por los Fondos de Investigación Fundamental para las
universidades centrales bajo la subvención No. WK0110000014. Yonggang Wen
fue apoyada por de inicio Beca de NTU, MOE Tier-1 Grant (RG 31/11) de
Singapur MOE y EIRP02 Beca de Singapur EMA. Yonggang Wen también
reconoce el apoyo de la Fundación Nacional de Investigación de Singapur en
virtud de sus futuros IDM iniciativa de financiación y administrados por el
Programa de Medios de Comunicación Interactiva y Digital O fi cina, Autoridad de
Desarrollo de Medios. Wen Feng Xia es apoyado por SNCF subvención No.
61073192, Grant 973 Programa Nº 2011CB302905 y EIRP02 subvención de
Singapur EMA.
R EFERENCIAS
[1] “Las predicciones de IDC 2013: competir en la tercera plataforma,” Libro Blanco,
IDC, noviembre de 2012. [En línea]. Disponible: http://www.idc.com/research/ Predictions13 /
descargables / 238044.pdf
[2] P. Mell y T. Grance, “La definición NIST de fi de computación en la nube
(borrador)," NIST publicación especial, vol. 800-145, p. 7, 2011. [3] J. Gantz y D. Reinsel,
“extraer valor de caos,” Libro Blanco,
IDC, Jun. 2011. [En línea]. Disponible: http://www.emc.com/collateral/ analista-informes /
IDC-extracción-valor-de-caos-ar.pdf
1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
20
[4] J. Manyika, M. Chui, B. Brown, J. Bughin, R. Dobbs, C. Roxburgh, y
AH Byers, “Big data: La próxima frontera para la innovación, la competencia y la productividad”
McKinsey Global Institute, Pp. 1-137, 2011. [5] P. Cesar y D. Geerts, “Pasado, presente y futuro de
la televisión social: una cate-
gorization,”en Consumidores de Comunicaciones y Networking Conference (CCNC), IEEE
2011. IEEE, 2011, pp. 347-351.
[6] Y. Jin, X. Liu, Y. Wen, y J. Cai, “Interacción Inter-Screen para la Sesión
Reconocimiento y Transferencia Sobre la base de la nube centrada Media Network,”Circuitos
y Sistemas (ISCAS), 2013 Simposio Internacional sobre, IEEE 2013, que se publicarán.
[7] Y. Jin, Y. Wen, G. Shi, G. Wang, y A. Vasilakos “, CoDaaS: Un
experimental nube centrada plataforma de entrega de contenido para los contenidos generados por los
usuarios”, pp 934-938, 2012. [8] J. Dean y S. Ghemawat, IEEE.“MapReduce: procesamiento de datos
simplificada fi
en grandes grupos,” Communications of the ACM, vol. 51, no. 1, pp. 107-113, 2008.
[9] “Global Mobile Data Traf fi c Pronóstico actualización, 2013-2018”
Cisco Visual Networking Index, Libro Blanco, Cisco, Feb.
2014. [En línea]. Disponible: http://www.cisco.com/c/en/us/solutions/ garantía / prestador
de servicios / visual-redes-index-VNI / c11-520862.pdf papel blanco
[10] Facebook línea de tiempo. [En línea]. Disponible: http://newsroom.fb.com/
Cronología
[11] “Pronóstico y metodología, 2011-2016,” Cisco Visual Net-
trabajando Índice, Libro Blanco, Cisco, mayo de 2012. [En-
línea]. Disponible: http://www.cisco.com/en/US/solutions/collateral/
ns341 / ns525 / ns537 / ns705 / ns827 / c11-481360.pdf papel blanco [12] H. Kim, T.
Benson, A. Akella, y N. Feamster, “La evolución
de la red con fi guración: una historia de dos campus,”en Actas de la conferencia ACM
SIGCOMM en conferencia de medición de Internet 2011. ACM, 2011, pp. 499-514. [13] “¿Cuál
es el tiempo de inactividad de la red detrás?” Libro Blanco, Juniper Networks,
Mayo de 2008. [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”, en ACM SIGCOMM ordenador examen de la
comunicación, vol. 38, no. 4. ACM, 2008, pp. 351-362. [15] T.-Y. Huang, N. Handigol, B. Heller,
N. McKeown, y R. Johari,
“Confundido, tímida, e inestable: Selección de una tasa de transmisión de video es duro”, en Actas
de la conferencia de 2012 en la conferencia ACM medición de Internet. ACM, 2012, pp. 225-238.
[16] X. Chen, ZM Mao, y J. Van Der Merwe, “ShadowNet: una plataforma
para la evolución de la red rápida y segura “, en Actas de la conferencia de 2009 en la
conferencia técnica anual de USENIX, Ser. USENIX'09. Berkeley, CA, EE.UU.: Asociación
USENIX, 2009. [17] R. Perlman, “RBridges: encaminamiento transparente,” en INFOCOM
2004.
XXIII Conferencia AnnualJoint de las Sociedades de Comunicaciones IEEE Computer y, vol.
2. IEEE, 2004, pp. 1211-1218.
[18] R. Perlman, D. Eastlake tercero, S. Gai, D. Dutt, y A. Ghanwani,
“Puentes de enrutamiento (RBridges): protocolo Base específico de cationes,”. RFC 6325, Julio 2011.
[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 la Internet del futuro
arquitecturas” Communications Magazine, IEEE, vol. 49, no. 7, pp. 26-36, 2011.
[20] L. Zhang, D. Estrin, J. Burke, V. Jacobson, JD Thornton, DK
Smetters, B. Zhang, G. Tsudik, D. Massey, C. Papadopoulos et al.,
“Proyecto de red de datos con nombre (NDN),” Relat' orio T ' ecnico NDN-0001,
Xerox Palo Alto Research Center-PARC, 2010.
[21] AT Campbell, HG De Meer, ME Kounavis, K. Miki, JB
Vicente, y D. Villela, “Un estudio de las redes programables,” ACM SIGCOMM ordenador
examen de la comunicación, vol. 29, no. 2, pp. 7-23,
1999.
[22] L. Popa, A. Ghodsi, y I. Stoica, “HTTP como el estrecho de la cintura de la
Internet del futuro “, en Actas de la novena ACM SIGCOMM Taller sobre Temas de actualidad
en las redes, Ser. Hotnets-IX. Nueva York, NY, EE.UU.: ACM, 2010, pp. 6: 1-6: 6.
[23] “El software de fi nida de redes: la nueva norma para las redes,” White
Papel, Fundación Redes abierto (ONF), abril de 2012. [En línea]. Disponible:
https://www.opennetworking.org/images/stories/downloads/ papeles blancos /
wp-SDN-newnorm.pdf
[24] T. Nadeau y P. Pan, “Declaración de Software Redes Driven problema”
borrador de Internet, octubre de 2011. [En línea]. Disponible: http://tools.ietf.org/html/
proyecto-Nadeau-SDN-problema-comunicado-01 [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].
Disponible: http://conferences.sigcomm.org/sigcomm/2012/hotsdn.php
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales
[27] Taller Europeo de Software de fi ne Redes. [En línea].
Disponible: http://ewsdn.eu/ewsdn12.html
[28] “Software De fi nida Networking: Un nuevo paradigma para el virtual, dinámico,
establecimiento de una red flexible,”Libro Blanco, tecnología y sistemas IBM, octubre de 2012.
[En línea]. Disponible: http://public.dhe.ibm.com/common/ssi/ ecm / es / qcw03016usen /
QCW03016USEN.PDF
[29] Fundación Redes abierto. [En línea]. Disponible: https: // www.
opennetworking.org/
[30] J. Smith, D. Farber, C. Gunter, S. ortigas, D. Feldmeier, y W. Sin-
coskie, “Switchware: Aceleración de evolución de la red,” Libro Blanco del Departamento de la CEI de
la Universidad de Pennsylvania, 1996.
[31] D. Alexander, W. Arbaugh, M. Hicks, P. Kakkar, A. Keromytis,
J. Moore, C. Gunter, S. ortigas, y J. Smith, “La arquitectura de red activa SwitchWare,” Red,
IEEE, vol. 12, no. 3, pp. 29-36, 1998. [32] E. Kohler, R. Morris, B. Chen, J. Jannotti, y M.
Kaashoek, “The
Haga clic en el router modular” ACM Transactions on Computer Systems (COT), vol. 18, no.
3, pp. 263-297, 2000.
[33] M. Handley, O. Hodson, y E. Kohler, “XORP: Una plataforma abierta
para la investigación de la red” ACM SIGCOMM ordenador examen de la comunicación, vol. 33,
no. 1, pp. 53-57, 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 Actas del taller ACM
SIGCOMM sobre las orientaciones futuras en la arquitectura de red, Ser. FDNA'04. Nueva
York, NY, EE.UU.: ACM, 2004, pp 5-12..
[37] L. Yang, R. Dantu, T. Anderson, y R. Gopal, “Reenvío y
control de la separación elemento (fuerzas) marco “, RFC 3746, abril de
2004. [En línea]. Disponible: http://tools.ietf.org/rfc/rfc3746.txt
[38] T. Lakshman, T. Nandagopal, R. Ramjee, K. Sabnani, y T. Woo,
“La arquitectura softrouter,” en Proc. ACM SIGCOMM Taller sobre Temas de actualidad en
redes, 2004.
[39] W. Wang, L. Dong, B. Zhuge, M. Gao, F. Jia, R. Jin, J. Yu, y X. Wu,
“Diseño e implementación de un enrutador abierto programable especi fi caciones compatible
con fuerzas IETF,” en Redes de 2007. ICN'07. Sexta Conferencia Internacional sobre.
IEEE 2007.
[40] A. Doria, R. Haas, J. Salim, R. Gopal, H. Khosravi, L. Dong,
y W. Wang, “Reenvío y elemento de control de separación (fuerzas) de protocolo específico de
cationes,” RFC 5810, marzo de 2010. [En línea]. Disponible: http://tools.ietf.org/rfc/rfc5810.txt
[41] J. Rexford, A. Greenberg, G. Hjalmtysson, D. Maltz, A. Myers, G. Xie,
J. Zhan, y H. Zhang, “de toda la red toma de decisiones: hacia un plano de control de oblea
delgada,” en Proc. HotNets, 2004, pp. 59-64.
[42] A. Greenberg, G. Hjalmtysson, DA Maltz, A. Myers, J. Rexford,
G. Xie, H. Yan, J. Zhan, y H. Zhang, “Un enfoque pizarra 4D limpia para la red de control y
gestión,” SIGCOMM Comput. Commun. Rdo., vol. 35, no. 5, pp. 41-54, octubre de 2005.
[43] H. Yan, DA Maltz, TSE Ng, H. Gogineni, H. Zhang, y Z. Cai,
“Tesseract: un plano de control de red 4D,” en Actas de la cuarta conferencia USENIX en el
diseño de sistemas en red y la aplicación,
Ser. NSDI'07. Berkeley, CA, EE.UU.: Asociación USENIX, 2007. [44] A. Farrel, J.-P.
Vasseur, y J. Ash, “A Path Computation
Elemento (PCE) basado en la arquitectura “, RFC 4655, agosto de 2006. [En línea]. Disponible:
http://www.ietf.org/rfc/rfc4655.txt
[45] M. Casado, T. Garfinkel, A. Akella, MJ Freedman, D. Boneh,
N. McKeown, y S. Shenker, “sano: una arquitectura de protección para redes
empresariales,” en Actas de la 15ª Conferencia de USENIX Simposio de Seguridad -
Volumen 15, Ser. USENIX-SS'06. Berkeley, CA, EE.UU.: Asociación USENIX 2006.
[46] J. Luo, J. Pettit, M. Casado, J. Lockwood, y N. McKeown, “Proto-
escribir, seguros, interruptores simples rápidos para Etha,”en Actas de la 15ª Simposio
Anual IEEE sobre interconexiones de alto rendimiento, Ser. HOTI'07. Washington, DC,
EE.UU.: IEEE Computer Society, 2007, pp 73-82..
[47] M. Casado, MJ Freedman, J. Pettit, J. Luo, N. McKeown, y
S. Shenker, “Etano: tomar el control de la empresa”, en Actas de la conferencia de 2007 en
las aplicaciones, tecnologías, arquitecturas y protocolos para comunicaciones informáticas, Ser.
SIGCOMM'07. Nueva York, NY, EE.UU.: ACM, 2007, pp 1-12..
[48] ​M. Casado, MJ Freedman, J. Pettit, J. Luo, N. Gude, N. McKeown,
y S. Shenker, “Rethinking 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,
“The
futuro de las redes, y el pasado de protocolos,” Open Networking
1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
21
Cumbre, 2011. [En línea]. Disponible: http://www.opennetsummit.org/ archivos / apr12 / site /
charlas / Shenker-tue.pdf [50] A. gember, P. Prabhu, Z. Ghadiyali, y A. Akella, “Hacia software-
de fi nida redes middlebox,”en Actas del 11º Taller ACM sobre Temas de actualidad en
redes. ACM, 2012, pp. 7-12. [51] M. Al-tarifas, S. Radhakrishnan, B. Raghavan, N. Huang, y A.
Vahdat,
“Hedera: dinámica de flujo de programación de redes de centros de datos”, en Actas de la 7ª
Conferencia de USENIX en el diseño de sistemas en red y la aplicación, Ser. NSDI'10.
Berkeley, CA, EE.UU.: Asociación USENIX 2010.
[52] M. Ghobadi, S. Yeganeh, y Y. Ganjali, “Rethinking de extremo a extremo
control de la congestión en las redes definida por software de,”en Actas del 11º Taller ACM
sobre Temas de actualidad en redes. ACM, 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 9ª Conferencia de Ingeniería GENI
(Pleno), 2010.
[54] B. Heller, S. Seetharaman, P. Mahadevan, Y. Yiakoumis, P. Sharma,
S. Banerjee, y N. McKeown, “ElasticTree: ahorro de energía en redes de centros de datos”,
en Actas de la 7ª Conferencia de USENIX en el diseño de sistemas en red y la aplicación, Ser.
NSDI'10. Berkeley, CA, EE.UU.: Asociación USENIX, 2010. [55] A. Ferguson, A. Guha, J.
Place, R. Fonseca, y S. Krishnamurthi,
“Redes participativa”, en Proc. Hot-ICE'12, San Jose, CA, 2012. [56] K. Jeong, J. Kim, e Y.
Kim, “compatibles con QoS Sistema Operativo de Red
para el software definida en red con Openflows generalizadas,”en Operaciones de Red y el
Simposio de Gestión (NOM), IEEE 2012.
IEEE, 2012, pp. 1167-1174.
[57] T. Koponen, S. Shenker, H. Balakrishnan, N. Feamster, I. Ganichev,
A. Ghodsi, P. Godfrey, N. McKeown, G. Parulkar, B. Raghavan et al.,
“Arquitectura de la innovación” ACM SIGCOMM ordenador examen de la comunicación, vol.
41, no. 3, pp. 24-36, 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].
Disponible: http://www.geni.net/
[60] A. Sharafat, S. Das, G. Parulkar, y N. McKeown, “Mpls-te y mpls
VPNs con de flujo abierto,”en ACM SIGCOMM ordenador examen de la comunicación, vol.
41, no. 4. ACM, 2011, pp. 452-453. [61] N. Blefari-Melazzi, A. Detti, G. Mazza, G. Morabito, S.
Salsano,
y L. Veltri, “Un banco de pruebas basados ​en OpenFlow para la Información centrada en
redes,” Futura Red & Summit móvil, pp. 4-6, 2012. [62] H. Yin, H. Xie, H. Tsou, D. López, P.
Aranda, y R. Sidi, “
SDNi:. Un Protocolo de mensajes de cambio de software de fi ne Redes (SDNS) a través de
varios dominios,”borrador de Internet, Jun 2012. [En línea]. Disponible:
http://tools.ietf.org/id/draft-yin-sdn-sdni-00.txt [63] H. Xie, T. Tsou, D. López, R. Sidi, H. Yin, y
PA Aranda,
“definida esfuerzos software de red-de debutó en el IETF, 84” IETF Journal, Octubre de 2012.
[En línea]. Disponible: http: //www.internetsociety. org / fr / nodo / 45708
[64] R. Birke, D. Crisan, K. Barabash, A. Levin, C. DeCusatis, C. Minken-
berg, y M. Gusat, “Partición / agregado en los productos básicos 10G Ethernet software de fi
nida en red”, en La conmutación y enrutamiento de alto rendimiento (IPSS), 2012 Conferencia
Internacional IEEE sobre 13. IEEE,
2012, pp. 7-14.
[65] E. Karpilovsky, M. Caesar, J. Rexford, A. Shaikh, y J. van der
Merwe, “Práctica de compresión de la red amplia de tablas de enrutamiento IP”
Red y Gestión de Servicios, IEEE Transactions on, vol. 9, no. 4, pp. 446-458, 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
Comunicaciones (CPI), 2012 Conferencia Internacional IEEE sobre, junio
2012, pp. 2961 -2965.
[67] O. Ferkouss, I. Snaiki, O. Mounaouar, H. Dahmouni, R. Ben Ali,
Y. Lemieux, y C. Omar, “plataforma de procesador de red A 100Gig para de flujo abierto”, en La
red y administración de servicios (CNSM), 2011 7ª Conferencia Internacional sobre.
IEEE, 2011, pp. 1-4.
[68] JC Mogul y P. Congdon, “Hey, zurcidos contadores !: ¡Fuera de mi
ASIC!”En Actas del taller primero en Temas de actualidad en las redes de software definida
de, Ser. HotSDN'12. Nueva York, NY, EE.UU.: ACM, 2012, pp 25-30..
basado en PC [69] V. Tanyingyong, M. Hidell, y P. Sjodin, “Mejora
OpenFlow rendimiento de conmutación,”en Arquitecturas para Redes y Sistemas de
Comunicaciones (ANCS), 2010 ACM / IEEE Simposio sobre, 2010, pp. 1-2.
[70] -, “Uso de clasi fi cación de hardware para mejorar basados ​en PC abierta flujo
conmutación,”en La conmutación y enrutamiento de alto rendimiento (IPSS), IEEE 2011 12ª
Conferencia Internacional sobre. IEEE, 2011, pp. 215-221.
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales
[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 Actas del taller primero en
Temas de actualidad en las redes de software definida de, Ser. HotSDN'12. Nueva York, NY, EE.UU.: ACM,
2012, pp 31-36..
[72] Pantou: OpenFlow 1.0 para OpenWRT. [En línea]. Disponible: http: // www.
fl abierto ow.org/wk/index.php/Pantou: OpenFlow 1.0 para OpenWRT [73] Y. Mundada, R.
Sherwood, y N. Feamster, “An abierta flujo interruptor ele-
ment por clic,”en en el Simposio sobre Haga clic en Router modular. Citeseer,
2009.
[74] B. Pfaff, J. Pettit, T. Koponen, K. Amidon, M. Casado, y S. Shenker,
“Extensión de red en la capa de virtualización,” Proc. HotNets (octubre de 2009), 2009.
[75] J. Pettit, J. Gross, B. Pfaff, M. Casado, y S. Crosby, “Virtual
conmutación en una era de bordes avanzados “, en 2do Taller de centro de datos
convergente y conmutación Ethernet virtual (DC-CUEVAS), 2010.
[76] J. Lockwood, N. McKeown, G. Watson, G. Gibb, P. Hartke, J. Naous,
R. Raghuraman, y J. Luo, “NetFPGA-una plataforma abierta para la conmutación de red
gigabitrate y enrutamiento,” en Sistemas microelectrónicos Educación, 2007. MSE'07.
Conferencia Internacional IEEE sobre. IEEE,
2007, pp. 160-161.
[77] M. Anwer, M. Motiwala, M. Tariq, y N. Feamster, “Switchblade:
Una plataforma para el rápido despliegue de protocolos de red de hardware programable,” ACM
SIGCOMM ordenador examen de la comunicación, vol. 40, no. 4, pp. 183-194, 2010.
[78] G. Lu, C. Guo, Y. Li, Z. Zhou, T. Yuan, H. Wu, Y. Xiong, R. Gao,
y Y. Zhang, “ServerSwitch: Una plataforma de rendimiento programable y alta para redes de
centros de datos”, en Proc. INDE, 2011.
[79] A. Rostami, T. Jungel, A. Koepsel, H. Woesner, y A. wolisz,
“ORAN: OpenFlow routers para redes académicas,” en La conmutación y enrutamiento de
alto rendimiento (IPSS), 2012 Conferencia Internacional IEEE sobre 13.
IEEE, 2012, pp. 216-222.
[80] J. Naous, D. Erickson, GA Covington, G. Appenzeller, y N. McK-
Eactividad propia, “Implementación de un interruptor de OpenFlow en la plataforma NetFPGA,”
en Actas de la cuarta ACM / IEEE Simposio sobre arquitecturas de redes y sistemas de
comunicaciones, Ser. ANCS'08. Nueva York, NY, EE.UU.: ACM, 2008, pp 1-9..
[81] J. Kempf, S. Whyte, J. Ellithorpe, P. Kazemian, M. Haitjema, N. Be-
heshti, S. Stuart, y H. Green, “OpenFlow MPLS y la fuente abierta de etiquetas conmutadas
router,” en Actas de la 23ª fi Internacional Teletraf c Congreso, Ser. ITC'11.
PICT, 2011, pp. 8-14.
[82] Indigo - Abierto Fuente Interruptores OpenFlow. [En-
línea]. Disponible: http: //indigo1.project fl oodlight.org/display/Indigo/ Indigo + - + + Fuente
Abierta + OpenFlow + Interruptores + - + + Primera Generación [83] A. Bianco, R. Birke, L.
Giraudo, y M. Palacín “Abre flujo SWITCH-
ción: el rendimiento del plano de datos “, en Comunicaciones (CPI) de 2010 Conferencia Internacional
IEEE sobre. IEEE, 2010, pp. 1-5.
[84] C. Rotsos, N. Sarrar, S. Uhlig, R. Sherwood, y AW Moore,
“OFLOPS: un marco abierto para cambiar abierta fl ujo de evaluación”, en
Actas de la 13ª Conferencia Internacional sobre Medición Activa y Pasiva, Ser. PAM'12.
Berlín, Heidelberg: Springer-Verlag,
2012, pp. 85-95.
[85] T. Ulversoy, “Software de fi nido de radio: desafíos y oportunidades”
Las encuestas de comunicación y tutoriales, IEEE, vol. 12, no. 4, pp. 531-
550, 2010.
[86] E. Mannie, “Generalizado Multi-Protocolo Label Switching (GMPLS)
Arquitectura “, RFC 3945, octubre de 2004. [En línea]. Disponible: http: // herramientas.
ietf.org/rfc/rfc6325.txt
[87] M. Bansal, J. Mehlman, S. Katti, y P. Levis, “OpenRadio: a pro-
dataplane inalámbrica gramable,”en Actas del taller primero en Temas de actualidad en las
redes de software definida de, Ser. HotSDN'12. Nueva York, NY, EE.UU.: ACM, 2012, pp
109-114..
[88] R. Murty, J. Padhye, A. Wolman, y M. Welsh “, Dyson: un archi-
tecture para LANs inalámbricas extensibles,”en Actas de la conferencia USENIX 2010 en la
conferencia técnica anual de USENIX, Ser. USENIXATC'10. Berkeley, CA, EE.UU.: Asociación
USENIX, 2010. [89] Software de comunicaciones Arquitectura especí fi cación, Programa
Conjunto de las
Ejecutivo O fi cina (JPEO) para el estándar Conjunto de sistema de radio táctico (JTRS).,
Rev. 4.0, 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
Comu-
nicación Arquitectura especí fi cación: Evolución y tendencias “, en Inteligencia Computacional y
Aplicaciones Industriales, 2009. PACIIA 2009. Conferencia fi co de Asia y el Pacífico sobre, vol. 2.
IEEE, 2009, pp. 341-344.
[91] Forum Wireless Innovation (anteriormente la SDRForum). [En línea].
Disponible: http://www.wirelessinnovation.org/
1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
22
[92] J. Elbers y A. Autenrieth, “de estática a software-de fi Ned óptico
redes “, en Diseño de red óptica y Modelado (ONDM), 2012 16a Conferencia Internacional
sobre. IEEE, 2012, pp. 1-4.
[93] A. Giorgetti, F. Cugini, F. Paolucci, y P. Castoldi, “OpenFlow y
Arquitecturas PCE en la longitud de onda Switched Optical Networks,”en Diseño de red
óptica y Modelado (ONDM), 2012 16a Conferencia Internacional sobre.
IEEE, 2012, pp. 1-6.
[94] S. Das, G. Parulkar, y N. McKeown, “control uni fi ed simple para
redes de paquetes y de circuitos,”en Reunión tópica verano de 2009. LEOSST'09. IEEE /
LEOS. IEEE, 2009, pp. 147-148.
[95] -, “paquete unificar y conmutación de circuitos redes”, en GLOBO-
Talleres COM, 2009 IEEE. IEEE, 2009, pp. 1-6.
[96] S. Das, G. Parulkar, N. McKeown, P. Singh, D. Getachew, y
L. Ong, “la convergencia de paquetes y la red de circuitos con de flujo abierto”, en
La fibra óptica Comunicación (OFC), un emplazamiento común Conferencia Nacional de Ingenieros de
fibra óptica de 2010 Conferencia sobre (OFC / NFOEC). IEEE,
2010, pp. 1-3.
[97] S. Das, Y. Yiakoumis, G. Parulkar, N. McKeown, P. Singh,
D. Getachew, y P. Desai, “ingeniería agregación y tráfico c consciente de las aplicaciones en
una red de paquetes de circuito convergente” en Conferencia de fibra óptica Comunicación y
Exposición (OFC / NFOEC) de 2011 y la Conferencia Nacional de Fibra Óptica Ingenieros. IEEE,
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 La comunicación óptica (CEC) de 2011 37ª Conferencia
y Feria Europea. IEEE, 2011, pp. 1-3.
[99] -, “Validación experimental y el rendimiento evaluación de
control de la trayectoria de longitud de onda basado en OpenFlow en redes ópticas
transparentes” Optics Express, vol. 19, no. 27, pp. 26 578 a 26 593, 2011. [100] L. Liu, D. Zhang,
T. Tsuritani, R. Vilalta, R. Casellas, L. Hong,
I. Morita, H. Guo, J. Wu, R. Mart'ınez et al., “Prueba de campo En primer lugar de una uni fi plano de
control ed basados ​en OpenFlow para redes ópticas de múltiples capas multi-granularidad,” en Conferencia
de fibra óptica Comunicación. Optical Society of America, 2012.
[101] L. Liu, D. Zhang, T. Tsuritani, R. Vilalta, R. Casellas, L. Hong,
I. Morita, H. Guo, J. Wu, R. Martínez, y R. Muñoz, “Primera prueba de campo de una uni fi
plano de control ed basados ​en OpenFlow para redes ópticas de múltiples capas
multigranularity,” en Conferencia de fibra óptica Comunicación y Exposición (OFC / NFOEC)
de 2012 y la Conferencia Nacional de Fibra Óptica Ingenieros, 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 Redes ópticas transparentes (ICTON), 2012 14ª Conferencia Internacional
sobre. IEEE, 2012, pp. 1-4.
[103] - “De GMPLS al PCE / GMPLS a OpenFlow: ¿Cuánto beneficio
podemos obtener de la evolución técnica del plano de control en redes ópticas?”en Redes
ópticas transparentes (ICTON), 2012 14ª Conferencia Internacional sobre.
IEEE, 2012, pp. 1-4.
[104] F. Farías, J. Salvatti, E. Cerqueira, y A. Abelem, “Una propuesta
la gestión del entorno de red usando legado plano de control OpenFlow “, en Operaciones
de Red y el Simposio de Gestión (NOM), IEEE 2012.
IEEE, 2012, pp. 1143-1150.
[105] M. Casado, T. Koponen, S. Shenker, y A. Tootoonchian, “tela: una
retrospectiva sobre la evolución de SDN,”en Actas del taller primero en Temas de actualidad
en las redes de software definida de, Ser. HotSDN'12. Nueva York, NY, EE.UU.: ACM, 2012, pp
85-90.. [106] B. Raghavan, M. Casado, T. Koponen, S. Ratnasamy, A. Ghodsi,
y S. Shenker, “Software-de fi nido arquitectura de Internet: desacoplar la arquitectura de
infraestructura”, en Actas del 11º Taller ACM sobre Temas de actualidad en redes. ACM, 2012,
pp. 43-48. [107] V. Gudla, S. Das, A. Shastri, G. Parulkar, N. McKeown, L. Kazovsky,
y S. Yamashita, “Demostración experimental de control de OpenFlow de conmutadores de
paquetes y de circuitos,” en Conferencia de fibra óptica Comunicación. Optical Society of
America, 2010. [108] D. Simeonidou, R. Nejabati, y S. Azodolmolky, “Habilitación de la
Internet del futuro óptico con OpenFlow: Un cambio de paradigma en la prestación de servicios
de redes ópticas inteligentes “, en Redes ópticas transparentes (ICTON), 2011 13ª Conferencia
Internacional sobre. IEEE, 2011, pp.
1-4.
[109] S. Azodolmolky, R. Nejabati, E. Escalona, ​R. Jayakumar, N. Efstathiou,
y D. Simeonidou, “plano de control OpenFlow-GMPLS integrado: un modelo de superposición
para el software de fi paquete Ned sobre redes ópticas,” Optar. Exprimir, vol. 19, no. 26, pp.
B421-B428, 2011 Dic [110] Kit Plataforma Uno 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 Actas de la primera
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales
taller de ACM para la Investigación en redes empresariales, Ser. WREN'09. Nueva York, NY,
EE.UU.: ACM, 2009, pp 1-10..
[112] N. Foster, MJ Freedman, R. Harrison, J. Rexford, ML Meola, y
D. Walker, “Frenético: un lenguaje de alto nivel para redes OpenFlow”, en
Actas del Taller sobre routers programables para extensibles Los servicios de Mañana, Ser.
PRESTO'10. Nueva York, NY, EE.UU.: ACM,
2010, pp. 6: 1-6: 6.
[113] N. Foster, R. Harrison, MJ Freedman, C. Monsanto, J. Rexford,
A. Historia y D. Walker, “Frenético: un lenguaje de programación de la red”
No SIGPLAN., vol. 46, no. 9, pp 279-291, Sep. 2011. [114] A. Voellmy y P. Hudak, “Nettle:.
Un idioma para fi Con gurar Rout-
ING Redes “, en Actas de la Conferencia de Trabajo IFIP TC 2 de dominio especí fi cos
Idiomas, Ser. DSL'09. Berlín, Heidelberg:
Springer-Verlag, 2009, pp. 211-235.
[115] A. Voellmy, A. Agarwal, P. Hudak, N. Feamster, S. Burnett, y
J. Launchbury, “No con fi gurar la red, el programa de él! fi lenguajes de programación C
domainspeci para sistemas de red,”Documento DTIC, Tech. Rep., 2010.
[116] A. Voellmy y P. Hudak, “Ortiga: tomar la picadura de la programación
enrutadores de red “, en Actas de la 13ª conferencia internacional sobre los aspectos
prácticos de los lenguajes declarativos, Ser. PADL'11. Berlín, Heidelberg: Springer-Verlag,
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 Actas del taller primero en Temas de actualidad en las
redes de software definida de, Ser. HotSDN'12. Nueva York, NY, EE.UU.: ACM, 2012, pp
43-48..
[118] T. Hinrichs, N. Gude, M. Casado, J. Mitchell, y S. Shenker, “Express-
ING y aplica políticas de seguridad de red basado en de fluencia” Universidad de Chicago, Tech.
Reps, 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 Actas del taller primero
en Temas de actualidad en las redes de software definida de, Ser. HotSDN'12. Nueva York, NY,
EE.UU.: ACM, 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 Actas del 39º
Simposio Anual ACM SIGPLAN-SIGACT sobre los principios de lenguajes de programación, Ser.
POPL'12. Nueva York, NY, EE.UU.: ACM,
2012, pp. 217-230.
[121] S. Gutz, A. Story, C. Schlesinger, y N. Foster, “aislamiento Splendid:
una abstracción rebanada de redes software de fi nida,”en Actas del taller primero en Temas de
actualidad en las redes de software definida de, Ser. HotSDN'12. Nueva York, NY, EE.UU.: ACM,
2012, pp 79-84.. [122] C. Monsanto, J. Reich, N. Foster, J. Rexford, y D. Walker, “un proceso de
compostaje
ing-Software de fi ne Redes “, en Actas de la conferencia USENIX 10a Sistemas en Red se
diseño e implementación, Ser. nsdi'13. Berkeley, CA, EE.UU.: Asociación USENIX, 2013, pp
1-14.. [123] A. Voellmy, J. Wang, YR Yang, B. Ford, y P. Hudak, “Maple:
La simplificación de SDN Programación Uso de directivas algorítmicos,”en Actas de la ACM
SIGCOMM 2013 Conferencia sobre SIGCOMM, Ser. SIGCOMM '13. Nueva York, NY, EE.UU.:
ACM, 2013, pp 87-98.. [124] R. Wang, D. Butnariu, y J. Rexford, “carga del servidor basada en
OpenFlow
equilibrar Gone Wild “, en Actas de la conferencia USENIX 11 en Temas de actualidad en la
gestión de Internet, la nube y las redes y servicios de la empresa, Ser. Hot-ICE'11. Berkeley,
CA, EE.UU.: Asociación USENIX 2011.
[125] S. Ghorbani y M. César, “Walk la línea: actualizaciones de la red consistentes
con garantías de ancho de banda “, en Actas del taller primero en Temas de actualidad en las
redes de software definida de, Ser. HotSDN'12. Nueva York, NY, EE.UU.: ACM, 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 Actas de la Conferencia ACM SIGCOMM
2012 sobre las aplicaciones, tecnologías, arquitecturas y protocolos de comunicación
informática. ACM, 2012, pp. 323-334. [127] M. Reitblatt, N. Foster, J. Rexford, y D. Walker, “UP-
Consistente
fechas para las redes de software de fi nida: Cambio que usted puede creer en “en!
Actas de la 10ª Taller ACM sobre Temas de actualidad en las redes,
Ser. HotNets-X. Nueva York, NY, EE.UU.: ACM, 2011, págs. 7: 1-7: 6. [128] R. McGeer, “A, e fi ciente
protocolo de actualización de seguridad para las redes de fl ujo abierta”
en Actas del taller primero en Temas de actualidad en las redes de software definida de, Ser.
HotSDN'12. Nueva York, NY, EE.UU.: ACM, 2012, pp 61-66..
[129] R. Raghavendra, J. Lobo, y K.-W. Lee, “consulta Gráfico dinámico
primitivas para la gestión basada en cloudnetwork SDN,”en Actas del taller primero en
Temas de actualidad en las redes de software definida de, Ser. HotSDN'12. Nueva York, NY,
EE.UU.: ACM, 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,”
1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
23
en ACM SIGCOMM ordenador examen de la comunicación, vol. 32, no. 4. ACM, 2002, pp.
161-174.
[131] A. Tootoonchian, M. Ghobadi, y Y. Ganjali, “OpenTM: tráfico c matriz
estimador de redes OpenFlow “, en Medición pasiva y activa.
Springer, 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
INFOCOM, 2011 Actas del IEEE, 2011, pp. 1629-1637.
[133] L. Jose, M. Yu, y J. Rexford, “Medición en línea de gran traf-
fi c agregados en los interruptores de las materias primas,”en Actas de la conferencia
USENIX 11 en Temas de actualidad en la gestión de Internet, la nube y las redes y servicios
de la empresa, Ser. Hot-ICE'11. Berkeley, CA, EE.UU.: Asociación USENIX 2011.
[134] N. Alon, Y. Matias, y M. Szegedy, “La complejidad espacio de
la aproximación de los momentos de frecuencia “, en Actas del simposio anual de ACM
twentyeighth en la Teoría de la computación, Ser. '96 COTS. Nueva York, NY, EE.UU.: ACM,
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.
2004.
[137] -, “algoritmos de transmisión de datos para e fi ciente y la estimación precisa
de la distribución del tamaño de flujo “, en Actas de la conferencia internacional conjunta
sobre la medición y modelización de sistemas informáticos, Ser. Sigmetrics '04 '04 /
rendimiento. Nueva York, NY, EE.UU.: ACM,
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, “tráfico definido medición Software de fi fi c
con OpenSketch,”en Actas de la conferencia USENIX 10a Sistemas en Red se diseño e
implementación, Ser. nsdi'13. Berkeley, CA, EE.UU.: Asociación USENIX, 2013, pp 29-42.. [En
línea]. Disponible: http://dl.acm.org/citation.cfm?id=2482626.2482631 [140] P. Fonseca, R.
Bennesby, E. Mota, y A. Passito, “A replicación
componente para redes basadas en OpenFlow resistente “, en Operaciones de Red y el
Simposio de Gestión (NOM), IEEE 2012. IEEE,
2012, pp. 933-939.
[141] D. Levin, A. Wundsam, B. Heller, N. Handigol, y A. Feldmann,
“Lógicamente centralizados ?: distribución de compensaciones estatales en las redes de nidos de
software de fi”, en Actas del taller primero en Temas de actualidad en las redes de software definida
de, Ser. HotSDN'12. Nueva York, NY, EE.UU.: ACM, 2012, pp 1-6..
[142] A. Tootoonchian y Y. Ganjali, “HyperFlow: un control distribuido
avión para OpenFlow “, en Actas de la conferencia de 2010 de Internet de gestión de red
para la Investigación en redes empresariales, Ser. INM / WREN'10. Berkeley, CA, EE.UU.:
Asociación USENIX, 2010. [143] T. Koponen, M. Casado, N. Gude, J. Stribling, L. Poutievski,
M. Zhu,
R. Ramanathan, Y. Iwata, H. Inoue, T. Hama, y ​S. Shenker, “Onix: una plataforma de control
distribuido para redes de producción a gran escala,” en Actas de la conferencia USENIX
novena de diseño del sistema operativo y la aplicación, Ser. OSDI'10.
Berkeley, CA, EE.UU.:
Asociación USENIX, 2010, pp. 1-6. [144] P. Porras, S. Shin, V. Yegneswaran, M. Fong, M.
Tyson, y G. Gu, “A
kernel de la aplicación de seguridad para redes OpenFlow “, en Actas del taller primero en
Temas de actualidad en las redes de software definida de, Ser. HotSDN'12. Nueva York, NY,
EE.UU.: ACM, 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 federada abierta flujo “, en Actas de la tercera taller de ACM
sobre assurable y utilizable con fi guración de seguridad,
Ser. SAFEcon fi g'10. Nueva York, NY, EE.UU.: ACM, 2010, pp 37-44.. [146] E. Al-Shaer,
W. Marrero, A. El-Atawy, y K. Elbadawi, “Red
con fi guración en una caja: Hacia de extremo a extremo de fiscalización de alcanzabilidad y
seguridad de la red,”en Protocolos de red, 2009. CIPE 2009. 17a Conferencia Internacional
IEEE sobre. IEEE, 2009, pp. 123-132.
[147] P. Pere s'ıni y M. Canini, “es su aplicación correcta OpenFlow?” en
Actas del taller ACM conexto Estudiante, Ser. Estudiante CoNEXT'11. Nueva York, NY,
EE.UU.: ACM, 2011, pp. 18: 1-18: 2. [En línea]. Disponible:
http://doi.acm.org/10.1145/2079327.2079345 [148] M. Canini, D. Kostic, J. Rexford, y D.
Venzano, “Automatización
la comprobación de las aplicaciones de OpenFlow,”en Presentado en: El 1er Taller
Internacional sobre Ingeniería riguroso protocolo (WRiPE),
2011.
[149] M. Canini, D. Venzano, P. Pere s'ıni, D. Kosti' c, y J. Rexford, “A nice
manera de probar las aplicaciones abiertas de fluencia,”en Actas de la novena USENIX
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales
conferencia sobre la Red de Sistemas Diseño e implementación, Ser. NSDI'12. Berkeley,
CA, EE.UU.: Asociación USENIX, 2012. [150] M. Ku'
zniar, M. Canini, y D. Kosti' c “, a menudo Prueba OpenFlow
Redes “, en Actas del 1er Taller Europeo de Software de fi nido (Redes), EWSDN'12 Oct de
2012.
[151] H. Mai, A. Khurshid, R. Agarwal, M. César, P. Godfrey, y S. King,
“Depuración del plano de datos con anteater,” ACM SIGCOMM ordenador examen de la
comunicación, vol. 41, no. 4, pp 290-301, 2011. [152] A. Khurshid, W. Zhou, M. Caesar, y PB
Godfrey, “VeriFlow.:
la verificación de los invariantes de toda la red en tiempo real “, en Actas del taller primero en
Temas de actualidad en las redes de software definida de, Ser. HotSDN'12. Nueva York, NY,
EE.UU.: ACM, 2012, pp 49-54.. [153] -, “Veri flujo: la verificación de los invariantes de toda la red en
tiempo real” SIG-
COMM 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: la verificación de los invariantes de toda la red en tiempo real”, en Actas de la
conferencia USENIX 10a Sistemas en Red se diseño e implementación, Ser. nsdi'13.
Berkeley, CA, EE.UU.: USENIX
Asociación, 2013, pp. 15-28.
[155] B. Heller, R. Sherwood, y N. McKeown, “La colocación controlador
problema “, en Actas del taller primero en Temas de actualidad en las redes de software
definida de, Ser. HotSDN'12. Nueva York, NY, EE.UU.: ACM, 2012, pp 7-12..
[156] Z. Cai, “Maestro: El logro de escalabilidad y la coordinación en Central-
izada de red del plano de control “, Ph.D. tesis doctoral, Universidad Rice, 2011. [157] Z.
Cai, AL Cox, y TE Ng, “Maestro: Un sistema para escalable
Control de OpenFlow “, Universidad Rice, Informe Técnico TR10-08, Dic
2010.
[158] A. Tootoonchian, S. Gorbunov, Y. Ganjali, M. Casado, y R. Sher
madera, “El rendimiento del controlador de software en redes de fi nida,” en
Actas de la segunda conferencia USENIX sobre Temas de actualidad en la gestión de
Internet, la nube y las redes empresariales y servicios, Ser. Hot-ICE'12 2012.
[159] A. Voellmy y J. Wang, “Scalable Software de fi ne Con- Red
ladores,”en Actas de la ACM SIGCOMM 2012 Conferencia sobre aplicaciones, tecnologías,
arquitecturas y protocolos para la Comunicación, Ser. SIGCOMM '12. Nueva York, NY,
EE.UU.: ACM,
2012, pp. 289-290.
[160] A. Voellmy, B. Ford, P. Hudak, y YR Yang, “Scaling Software-
de fi nida controladores de red en servidores multinúcleo,” YaleCS TR1468,
2012.
[161] Beacon. [En línea]. Disponible: https: // fl abierta ow.stanford.edu/display/ Beacon / Inicio
[162] M. Jarschel, S. Oechsner, D. Schlosser, R. Pries, S. Goll, y P. tran-
Gia, “Modelado y evaluación del desempeño de una arquitectura OpenFlow”, en Actas de la
23ª fi Internacional Teletraf c Congreso.
PICT, 2011, pp. 1-7.
[163] M. Yu, J. Rexford, MJ Freedman, y J. Wang, “fl Scalable ow basa-
creación de redes con DIFANE,”en Actas de la conferencia ACM SIGCOMM 2010, Ser.
SIGCOMM'10. Nueva York, NY, EE.UU.: ACM,
2010, pp. 351-362.
[164] AR Curtis, JC Mogul, J. Tourrilhes, P. Yalagandula, P. Sharma,
y S. Banerjee, “DevoFlow: escalado de flujo de gestión para redes de alto rendimiento” SIGCOMM
Comput. Commun. Rdo., vol. 41, no. 4, pp. 254-265, agosto de de 2011.
[165] S. Hassas Yeganeh y Y. Ganjali, “Kandoo: un marco para ef ciente fi
y escalable de oading fl de aplicaciones de control “, en Actas del taller primero en Temas
de actualidad en las redes de software definida de, Ser. HotSDN'12. Nueva York, NY, EE.UU.:
ACM, 2012, pp 19-24.. [166] Cbench (benchmarker controlador). [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
Benchmark OpenFlow-Controller “, en Software de fi nido en red (EWSDN), 2012 Taller
Europeo sobre. IEEE, 2012, pp. 48-53.
[168] R. Alimi, R. Penno, y Y. Yang, “protocolo ALTO,” Internet
borrador, Feb. 2013. [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,
“Haciendo abstracción estado de la red en el software de fi ne Networks (SDN) para los servicios de
encuentro”, en Comunicaciones (CPI), 2012 Conferencia Internacional IEEE sobre.
IEEE, 2012, pp. 6627-6632.
[170] E. Kissel, G. Fernandes, M. Jaffee, M. Swany, y M. Zhang, “Conducir
Software de fi ne Redes con XSP,”en SDN12: Taller sobre Software de fi ne Redes, 2012.
[171] E. Keller y J. Rexford, “El” modelo de plataforma como servicio”para
redes “, en Actas de la gestión de la red de Internet 2010
1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
24
Jornadas de Investigación en redes empresariales, Ser. INM / WREN'10. Berkeley, CA,
EE.UU.: Asociación USENIX, 2010. [172] N. Handigol, S. Seetharaman, M. Flajslik, N. McKeown,
y R. Johari,
“Plug-n-Serve: equilibrio de carga web trá fi co usando OpenFlow” ACM SIGCOMM Demo, 2009.
[173] K.-K. Yap, R. Sherwood, M. Kobayashi, T.-Y. Huang, M. Chan,
N. Handigol, N. McKeown, y G. Parulkar, “Proyecto para la introducción de la innovación en
las redes móviles inalámbricas,” en Actas del segundo taller ACM SIGCOMM en los
sistemas virtualizados de infraestructura y arquitecturas, Ser. VISA'10. Nueva York, NY,
EE.UU.: ACM, 2010, pp 25-32..
[174] K.-K. Yap, M. Kobayashi, R. Sherwood, T.-Y. Huang, M. Chan,
N. Handigol, y N. McKeown, “OpenRoads: potenciar la investigación en redes móviles” SIGCOMM
Comput. 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 Actas del taller ACM 2010 en Wireless de los
estudiantes, por parte de los estudiantes, para los estudiantes. ACM, 2010, pp. 41-44. [176] L.
Suresh, J. Schulz-Zander, R. Merz, A. Feldmann, y T. Vazao, “To-
salas redes WLAN empresariales programables con Odin,”en Actas del taller primero en
Temas de actualidad en las redes de software definida de, Ser. HotSDN'12. Nueva York, NY,
EE.UU.: ACM, 2012, pp 115-120.. [177] A. Wundsam, D. Levin, S. Seetharaman, y A.
Feldmann,
“OFRewind: permite grabar y solución de problemas de reproducción de las redes”, en Conferencia
Técnica Anual USENIX, 2011.
[178] JH Jafarian, E. Al-Shaer, y Q. Duan, “host abierto al azar flujo
mutación: transparente defensa objetivo en movimiento usando el software de fi nida en red “,
en Actas del taller primero en Temas de actualidad en las redes de software definida de, Ser.
HotSDN'12. Nueva York, NY, EE.UU.: ACM, 2012, pp 127-132..
[179] M. Mendonca, S. Seetharaman, y K. Obraczka, “A In- Flexible
Red IP servicio de forma anónima,”en Taller sobre la CPI IEEE Software de fi ne Redes, 2012.
[180] J. Fu, P. SJ Odin, y G. Karlsson “, la convergencia de enrutamiento intra-dominio
con control centralizado,” Red de computadoras, vol. 53, no. 18, pp. 2985-2996, 2009.
[181] KK Lakshminarayanan, I. Stoica, S. Shenker y J. Rexford,
“Enrutamiento como un servicio”, Departamento de Ingeniería Eléctrica e Informática, Universidad de
California, Berkeley, Tech. Rep. UCB / EECS-2006-19, febrero de 2006. [182] P. Pisa, N. Fernandes, H. Carvalho,
M. Moreira, M. Campista, L. Costa,
y O. Duarte, “abierto de flujo y la migración de la red virtual basado en Xen,”
Comunicaciones: Wireless en los países y redes del futuro desarrollo, Pp. 170-181, 2010.
[183] ​M. Koerner y O. Kao, “servicio múltiple de equilibrio de carga con Abierta
Fluir en La conmutación y enrutamiento de alto rendimiento (IPSS), 2012 Conferencia
Internacional IEEE sobre 13. IEEE, 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 Actas del taller primero en Temas de actualidad en
las redes de software definida de, Ser. HotSDN'12. Nueva York, NY, EE.UU.: ACM, 2012, pp 103-108.. [185]
Z. Kerravala, “A medida que el valor de las redes empresariales aumenta, también lo hace
la necesidad de una gestión con fi guración” Informática empresarial y Redes, El informe de
Yankee Group, 2004.
[186] N. Handigol, B. Heller, V. Jeyakumar, D. Mazi' Eres, y N. McKeown,
“¿Dónde está el depurador para mi red fi nido de software-de?” En Actas del taller primero en
Temas de actualidad en las redes de software definida de,
Ser. HotSDN'12. Nueva York, NY, EE.UU.: ACM, 2012, pp 55-60.. [187] S. Sharma, D.
Staessens, D. Colle, M. Pickavet, y P. Demeester,
“Activación rápida recuperación de fallos en las redes OpenFlow”, en Diseño de Redes de
Comunicación Fiable (DRCN), 2011 8º Seminario Internacional sobre la.
IEEE, 2011, pp. 164-171.
[188] R. Braga, E. Mota, y A. Passito “DDoS ligeros fl ataque inundando
detección usando NOX / OpenFlow “, en Redes locales de ordenadores (LCN), 2010 35ª
Conferencia IEEE sobre. IEEE, 2010, pp. 408-415.
[189] G. Gibb, H. Zeng, y N. McKeown “, Función- red de subcontratación
lidad,”en Actas del taller primero en Temas de actualidad en las redes de software definida de, Ser.
HotSDN'12. Nueva York, NY, EE.UU.: ACM, 2012, pp 73-78..
[190] G. Huang, C. Chuah, S. Raza, y S. Seetharaman, “Dynamic
medición consciente de enrutamiento en la práctica,” Red, IEEE, vol. 25, no. 3, pp. 29-34, 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 Actas del 1er Taller ACM
sobre Investigación en redes empresariales, Ser. WREN'09. Nueva York, NY, EE.UU.: ACM,
2009, pp 19-26..
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales
[192] C. Rigney, A. Rubens, W. Simpson, y S. Willens, “Remote
Dial de autenticación de usuario de servicios (RADIUS) “, RFC 2865, 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 gestión de acceso de VLAN Campus Sobre la base de OpenFlow,”en Aplicaciones
e Internet (SAN), 2011 IEEE / IPSJ 11º Simposio Internacional sobre.
IEEE, 2011, pp. 347-351.
[194] S. Kinoshita, T. Watanabe, J. Yamato, H. Goto, y H. Sone, “Im-
plementation y evaluación de un sistema de control de acceso basado en OpenFlow para
LAN inalámbrica de roaming “, en Software y Aplicaciones Conferencia Talleres
(COMPSACW), 2012 IEEE 36a anual.
IEEE, 2012, pp. 82-87.
[195] A. Ramachandran, Y. Mundada, M. Tariq, y N. Feamster, “Asegurando
redes empresariales que utilizan trá fi co adulteración,”Informe Técnico GTCS-09-
15, (Instituto de Tecnología de Georgia, Atlanta, GA), Tech. Rep., 2009.
[196] N. Feamster, A. Nayak, H. Kim, R. Clark, Y. Mundada, A. Ramachan-
Dran, y M. bin Tariq, “política de disociación de con fi guración de las redes de campus y de
la empresa,” en Local y redes de área metropolitana (LANMAN), 2010 17a IEEE Taller
sobre. IEEE 2010,
pp. 1-6.
[197] A. Nayak, A. Reimers, N. Feamster, y R. Clark, “Resonancia:
control de acceso dinámico para las redes empresariales “, en Actas del 1er Taller ACM
sobre Investigación en redes empresariales. ACM,
2009, pp. 11-18.
[198] N. Chowdhury y R. Boutaba, “virtualización de red: estado de la técnica
y desafíos de la investigación,” Communications Magazine, IEEE, vol. 47, no. 7, pp. 20-26,
2009.
[199] D. Turull, M. Hidell, y P. Sjodin, “Uso de libNetVirt para controlar el
red virtual “, en Nube de red (CLOUDNET), 2012 Conferencia Internacional IEEE sobre el
primero, 2012, pp. 148-152.
[200] -, “libNetVirt: La biblioteca de virtualización de red”, en nicación
ciones (CPI), 2012 Conferencia Internacional IEEE sobre, 2012, pp. 5543-
5547.
[201] R. Sherwood, G. Gibb, K. Yap, G. Appenzeller, M. Casado, N. McK-
Eactividad propia, y G. Parulkar, “Flowvisor: Una capa de virtualización de la red,”
OpenFlow Interruptor Consorcio, Tech. Reps, 2009.
[202] R. Sherwood, G. Gibb, K.-K. Yap, G. Appenzeller, M. Casado,
N. McKeown, y G. Parulkar, “¿Puede la red de producción será el banco de pruebas?” En Actas
de la conferencia USENIX novena de diseño del sistema operativo y la aplicación, Ser.
OSDI'10. Berkeley, CA,
EE.UU.: Asociación USENIX, 2010, pp 1-6..
[203] R. Sherwood, M. Chan, A. Covington, G. Gibb, M. Flajslik, N. Hand-
IGOL, T. Huang, P. Kazemian, M. Kobayashi, J. Naous et al., “Talla rebanadas de investigación
fuera de sus redes de producción con OpenFlow” ACM SIGCOMM ordenador examen de la
comunicación, vol. 40, no. 1, pp. 129-
130, 2010.
[204] Y. Yiakoumis, K.-K. Yap, Katti S., G. Parulkar, y N. McKeown,
“Cortando las redes domésticas,” en Actas del segundo taller de ACM SIGCOMM en redes
domésticas, Ser. HomeNets'11. Nueva York, NY, EE.UU.: ACM, 2011, pp 1-6..
[205] A. Bianzino, C. Chaudet, D. Rossi, y J. Rougier, “Un estudio de verde
la creación de redes de investigación” Las encuestas de comunicación y tutoriales, IEEE,
vol. 14, no. 1, pp. 3-20, 2012.
[206] D. Staessens, S. Sharma, D. Colle, M. Pickavet, y P. Demeester,
“El software de fi nida en red: requisitos de reuniones con calidad de operador,” en Local y
redes de área metropolitana (LANMAN), 2011 18a IEEE Taller sobre.
IEEE, 2011, pp. 1-6.
[207] T. Benson, A. Akella, A. Shaikh, y S. Sahu, “CloudNaaS: una nube
plataforma de red para aplicaciones empresariales,”en Actas del 2º Simposio ACM sobre
Cloud Computing, Ser. SOCC'11. Nueva York, NY, EE.UU.:. ACM, 2011, pp 8: 1-8: 13.
[208] A. Tavakoli, M. Casado, T. Koponen, y S. Shenker, “Aplicación de NOX
para el centro de datos” Proc. HotNets (octubre de 2009), 2009.
[209] M. Moshref, M. Yu, A. Sharma, y ​R. Govindan, “regla Scalable
la gestión de los centros de datos “, en Actas de la conferencia USENIX 10a Sistemas en
Red se diseño e implementación, Ser. nsdi'13. Berkeley, CA, EE.UU.: Asociación USENIX,
2013, pp 157-.
170.
[210] P. Zhang, L. Cheng, y R. Boutaba, “La computación en nube: Estado-de-
la técnica y desafíos de la investigación,” Diario de Servicios de Internet y aplicaciones, vol.
1, no. 1, pp. 7-18, 2010.
[211] Qin Li y Jinpeng Huai y Jianxin Li y Tianyu Wo y Minx-
iong Wen, “HyperMIP: hipervisor Controlled Mobile IP para Virtual Machine migración en
vivo a través de redes”, en Sistemas de Garantía de alta Simposio de Ingeniería de 2008.
ASE 2008. 11 de IEEE, 2008, pp. 80-
88.
1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
25
[212] P. Raad, G. Colombo, Chi DP, S. Secci, A. Cianfrani, P. Gallard, y
G. Pujolle, “El logro de los tiempos de parada de fracciones de segundos en las migraciones en vivo de
máquinas virtuales en toda la Internet en redes LISP,” en Gestión Integrada de red (IM 2013), 2013
IFIP / IEEE Simposio Internacional sobre,
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 Las
redes futuras y Servicios (SDN4FNS), IEEE 2013, para SDN 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 Actas del 1er Taller
ACM en sistemas virtualizados de infraestructura y arquitecturas. ACM, 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
Inalámbrica y redes de comunicaciones ópticas (WOCN), 2011 Octava Conferencia
Internacional sobre. IEEE, 2011, pp. 1-7.
[217] J. Matias, E. Jacob, D. Sánchez, y Y. Demchenko, “An OpenFlow
Marco de virtualización de red basada en la nube “, en Cloud Computing Tecnología y
Ciencia (CloudCom), IEEE 2011 Tercera Conferencia Internacional sobre.
IEEE, 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 Operaciones de Red y el Simposio de Gestión (NOM), IEEE 2012.
IEEE, 2012, pp. 88-96.
[219] Y. Pu, Y. Deng, y A. Nakao, “Nube de bastidor: Enhanced topología virtual
enfoque de migración con el conmutador virtual abierta “, en Redes de Información (ICOIN), 2011
Conferencia Internacional sobre. IEEE, 2011, pp. 160-
164.
[220] E. Keller, S. Ghorbani, M. Caesar, y J. Rexford, “migración en vivo de
una red completa (y sus hosts),”en Actas del 11º Taller ACM sobre Temas de actualidad en
las redes, Ser. HotNets-XI. Nueva York, NY, EE.UU.: ACM, 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 Nube de red (CloudNet), 2013 2ª Conferencia Internacional
IEEE sobre, Nov 2013, pp. 236-242. [222] N. McKeown, T. Anderson, H. Balakrishnan, G.
Parulkar, L. Peterson,
J. Rexford, S. Shenker, y J. Turner, “OpenFlow: facilitar la innovación en las redes de
campus,” SIGCOMM Comput. Commun. Rdo., vol. 38, no. 2, pp. 69-74, marzo de 2008.
[223] OpenFlow Interruptor Consortium. [En línea]. Disponible: http: // www.
abrir fl ow.org/
[224] D. Mattos, N. Fernandes, V. da Costa, L. Cardoso, M. Campista,
L. Costa, y O. Duarte, “OMNI: OpenFlow gestión de la infraestructura,” en Red del Futuro
(NOF), 2011 Conferencia Internacional sobre la.
IEEE, 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, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown,
y S. Shenker, “NOX: hacia un sistema operativo para redes”
SIGCOMM Comput. Commun. Rdo., vol. 38, no. 3, pp. 105-110, Jul.
2008.
[229] NOX. [En línea]. Disponible: http://www.noxrepo.org/ [230] K.-K. Yap, M. Kobayashi, D.
Underhill, S. Seetharaman, P. Kazemian,
y N. McKeown, “El OpenRoads despliegue de Stanford,” en Actas del 4º Taller Internacional
ACM sobre la evaluación y caracterización experimental, Ser. WINTECH'09. Nueva York,
NY, EE.UU.: ACM, 2009, pp 59-66..
[231] S. Jain, A. Kumar, S. Mandal, J. Ong, L. Poutievski, A. Singh,
S. Venkata, J. Wanderer, J. Zhou, M. Zhu, J. Zolla, U. H olzle,
S. Stuart, y A. Vahdat, “4: Experiencia con un Software De fi Desplegado-Globalmente
definido WAN,” en Actas de la conferencia ACM SIGCOMM 2013 en SIGCOMM, Ser.
SIGCOMM '13. Nueva York, NY, EE.UU.: ACM, 2013, pp 3-14..
[232] N. y J. Feamster Rexford, “Obtención de manos de los estudiantes sucio con
Borrón y cuenta nueva de red “, en SIGCOMM 2011 taller de Educación,
2011.
[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 ordenador examen de la
comunicación, vol. 33, no. 1, pp. 59-64, 2003. [234] Federados E-infraestructura dedicada a los
investigadores europeos
Innovar en arquitecturas de red informática (FEDERICA). [En línea]. Disponible:
http://www.fp7-federica.eu/ [235] JGN-X (JGN-extremo). [En línea]. Disponible:
http://www.jgn.nict.go.jp/
Inglés / index.html
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales

26

[236] Internet del Futuro bancos de pruebas de 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 NET
función de los trabajos de investigación y experimentación de virtualización “, en Las redes
futuras y Servicios (SDN4FNS), IEEE 2013, para SDN Nov 2013, pp. 1-5. [238] U. Holzle,
“OpenFlow @ Google,” abril 2012. [On-
línea]. Disponible: http://www.opennetsummit.org/archives/apr12/
Hoelzle-mar-abierta ow.pdf fl
[239] B. Lantz, B. Heller, y N. McKeown, “Una red en un ordenador portátil: rápido
creación de prototipos para las redes definida por software de,”en Actas de la novena ACM SIGCOMM
Taller sobre Temas de actualidad en las redes, Ser. Hotnets-
IX. Nueva York, NY, EE.UU.: ACM, 2010, pp. 19: 1-19: 6.
[240] L. Dong, F. Jia, y W. Wang, “De definición y aplicación de Logi-
Cal bloques de función que cumplen con las fuerzas especi fi cación “, en redes,
2007. ICONO 2007. 15a Conferencia Internacional IEEE sobre.
2007, pp. 531-536.
de fi ne redes” Communications Magazine, IEEE, vol. 49, no. 12, pp. 84-93, 2011.
[255] T. Nadeau y P. Pan, “Marco para el software de fi ne Redes”
borrador de Internet, octubre de 2011. [En línea]. Disponible: http://tools.ietf.org/id/
proyecto-Nadeau-SDN-marco-01.txt
[256] “Funciones de red de virtualización, una introducción, Bene fi cios, Enablers,
Desafíos y llamado a la acción,”Libro Blanco, ETSI Industria especí fi cación de grupo para
las funciones de red de virtualización (ISG NFV), 2012. octubre [En línea]. Disponible:
http://portal.etsi.org/NFV/NFV blanca Paper.pdf
[257] M. Kuzniar, P. Peresini, M. Canini, D. Venzano, y D. Kostic, “A
SUAVE forma para las pruebas de interoperabilidad interruptor de fl ujo abierta “, en Actas
de la conferencia internacional sobre el octavo emergentes experimentos y tecnologías de red. ACM,
2012, pp. 265-276. [258] M. Kind, F. Westphal, A. Gladisch, y S. Topp, “SplitArchitecture:
IEEE, Aplicando el software de fi ne redes Concepto de Carrier Networks,”en Congreso Mundial de
Telecomunicaciones (WTC), 2012. IEEE,

[241] Z. Wang, T. Tsou, J. Huang, X. Shi, y X. Yin, 2012, pp. 1-6.

“El análisis de comparaciones entre OpenFlow y fuerzas,” borrador de Internet, marzo de [259] P. Dely, A. Kassler, y N. Bayer, “fl abierto ow para malla inalámbrica

2012. [En línea]. Disponible: http: //tools.ietf. redes “, en Comunicaciones y Redes de ordenadores (ICCCN), 2011 Actas de la 20ª

org / id / Draft-Wang-fuerzas-compare-abierta flujo-fuerzas-01.txt [242] E. Haleplidis, S. Conferencia Internacional sobre. IEEE, 2011, pp.
1-6.
Denazis, O. Koufopavlou, J. Salim, y J. Halpern,
[260] A. Mahmud y R. Rahmani, “Explotación de OpenFlow en inalámbrica
“El software de fi nida en red: La experimentación con el control de reenvío plano de
redes de sensores, en” Ciencias de la Computación y Tecnología de red (ICCSNT), 2011
interfaz,” en Software de fi nido en red (EWSDN), 2012 Taller Europeo sobre.
Conferencia Internacional sobre, vol. 1. IEEE, 2011, pp.
IEEE, 2012, pp. 91-96.
594-600.
[243] P. Lin, J. Bi, y H. Hu, “ASIC: una arquitectura para intra escalable
[261] A. Mahmud, R. Rahmani, y T. Kanter, “Despliegue de Flow
control de dominio en OpenFlow “, en Actas de la 7ª Conferencia Internacional sobre
Los sensores en Internet de las Cosas a través de la virtualización “, en OpenFlow Móvil, ubicua
Tecnologías de la Internet del futuro. ACM, 2012, pp. 21-26. [244] MR Nascimento, CE
y Computación Inteligente (MUSIC), 2012 Tercera Conferencia Internacional sobre FTRA.
Rothenberg, D. Salvador, y MF Ma-
IEEE, 2012, pp. 195-200.
galh~ aes, “QuagFlow: Quagga asociarse con OpenFlow” SIGCOMM Comput. Commun.
Rdo., vol. 40, no. 4, pp. 441-442, agosto de 2010. [245] MR Nascimento, CE Rothenberg, MR
Salvador, CNA Corr ea,
SC de Lucena, y MF Magalh~ aes, “Enrutadores virtuales como un servicio:

el enfoque RouteFlow aprovechar las redes definida por software de,”en

Actas de la 6ª Conferencia Internacional sobre Tecnologías de la Internet del futuro, Ser.
CFI'11. Nueva York, NY, EE.UU.: ACM, 2011, pp 34-37.. Wen Feng Xia recibió su licenciatura en Ciencias de la Computación
de la Universidad de Ciencia y Tecnología de China (USTC), Hefei,
[246] Y. Nakagawa, K. Hyoudou, y T. Shimizu, “Un método de gestión Anhui, China, en 2011. En la actualidad es un candidato MS en la
de multidifusión IP en redes superpuestas utilizando de flujo abierto “, en Actas del taller Escuela de Informática de la USTC y trabajando como un proyecto
primero en Temas de actualidad en las redes de software definida de, Ser. HotSDN'12. Nueva o fi cial en el escuela de Ingeniería Informática de la Universidad
York, NY, EE.UU.: ACM, 2012, pp 91-96.. [247] K.-K. Yap, T.-Y. Huang, B. Dodson, MS Lam, y Tecnológica de Nanyang (NTU) en Singapur. Sus intereses de
N. McKeown, investigación incluyen las redes informáticas y la ingeniería de
“Hacia las redes de software amigable,” en Actas del taller ACM de Asia y el Pacífico software.
primera en Taller sobre sistemas, Ser. APSys'10. Nueva York, NY, EE.UU.: ACM, 2010, pp
49-54..
[248] T.-Y. Huang, K.-K. Yap, B. Dodson, MS Lam, y N. McKeown,
“PhoneNet: una red de teléfono a teléfono para la comunicación de grupo dentro de un
dominio administrativo”, en Actas del segundo taller ACM SIGCOMM en redes, sistemas y
aplicaciones en dispositivos de mano móviles, Ser. MobiHeld'10. Nueva York, NY, EE.UU.:
ACM, 2010, pp 27-32..

[249] B. Koldehofe, F. D URR, 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 Actas de la séptima Taller sobre Middleware para la próxima generación de Internet
Yonggang Wen ( S'99-M'08-SM'14) es un profesor asistente en la
Computing, Ser. MW4NG'12. Nueva York, NY, EE.UU.: ACM, 2012, pp. 3: 1-3: 6.
escuela de ingeniería informática en la Universidad Tecnológica de
Nanyang, Singapur. Recibió su doctorado en Ingeniería Eléctrica e
[250] D. Kotani, K. Suzuki, y H. Shimonishi, “Un diseño y aplica-
Informática (de menor importancia en la literatura occidental) del
tación de OpenFlow controlador de manejo de multidifusión IP con conmutación de árboles de
Massachusetts Institute of Technology (MIT), Cambridge, EE.UU..
rápido “, en Aplicaciones e Internet (SAN), 2012 IEEE / IPSJ 12º Simposio Internacional sobre.
Anteriormente ha trabajado en Cisco para liderar el desarrollo de
IEEE, 2012, pp. 60-67.
productos en la red de distribución de contenidos, el cual tuvo un
[251] R. Ravindran, X. Liu, A. Chakraborti, X. Zhang, y G. Wang,
impacto en los ingresos de 3 mil millones de dólares a nivel mundial.
“Hacia fi nida servicios de borde en la nube basado en el CIE de software”, en Nube de red
El Dr. Wen ha publicado más de 100 artículos en revistas y
(CloudNet), 2013 2ª Conferencia Internacional IEEE sobre,
conferencias de prestigio.
Nov 2013, pp. 227-235.
[252] T. Li, N. Van Vorst, R. Rong, y J. Liu, “Estudios de simulación de
Su último trabajo en la nube multi-pantalla de televisión social ha sido presentado por la prensa mundial
OpenFlow basados ​estrategias de caché dentro de la red,”en Actas de la 15ª
(más de 1600 artículos de noticias procedentes de más de 29 países) y reconocido con la ASEAN Premio
Comunicaciones y Redes Simposio de simulación, Ser. CNS'12.
TIC 2013 (medalla de oro) e IEEE Globecom 2013 Best Paper Award. Es miembro de los consejos
San Diego, CA, EE.UU.: Society for Computer Simulation
editoriales de IEEE Transactions on Multimedia, IEEE Journal y Acceso Ad Hoc Redes Elsevier. Sus
Internacional, 2012, pp. 12: 1-12: 7.
intereses de investigación incluyen la computación en nube, centro de datos verde, análisis de grandes
[253] G. Stabler, A. Rosen, S. Goasguen, y K.-C. Wang, “Elastic IP
volúmenes de datos, red multimedia y la informática móvil.
y grupos de seguridad de la aplicación usando OpenFlow “, en Actas de la sexta taller
internacional sobre tecnologías de virtualización en Distributed Computing Fecha, Ser.
VTDC'12. Nueva York, NY, EE.UU.: ACM, 2012, pp 53-60..

[254] J. Rubio-Loyola, A. Galis, A. Astorga, J. Serrat, L. Lefevre, A. Fischer,

A. Más pálido, y H. Meer, “el despliegue de servicios escalables en software-

1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.
Este artículo ha sido aceptado para su publicación en un próximo número de esta revista, pero no ha sido totalmente editado. El contenido puede cambiar antes de la publicación final. información de referencia: DOI
10.1109 / Encuestas COMST.2014.2330903, IEEE Communications & Tutoriales

27

Chuan Heng Foh ( S'00-M'03-SM'09) recibió su
M.Sc. grado de la Universidad de Monash, Australia en 1999 y Ph.D.
grado de la Universidad de Melbourne, Australia, en 2002. Después
de su doctorado, pasó 6 meses como profesor de la Universidad de
Monash en Australia. En diciembre de 2002, se incorporó a la
Universidad Tecnológica de Nanyang, Singapur como profesor
adjunto hasta 2012. En la actualidad es profesor titular de la
Universidad de Surrey. Sus intereses de investigación incluyen el
diseño del protocolo y el análisis de rendimiento de varias redes de
ordenadores y local inalámbrica
Haiyong Xie Actualmente es el director ejecutivo para el
ciberespacio y el Laboratorio de Ciencias de datos, la Academia
China de Electrónica y Tecnología de la Información y profesor en la
Facultad de Ciencias y Tecnología de Computadores de la
Universidad de Ciencia y Tecnología de China (USTC) en Hefei,
China. Recibió su Ph.D. licenciatura y máster en Informática en
2008 y 2005, respectivamente, ambos de la Universidad de Yale, y
su título de licenciatura de la USTC en 1997. Antes de su posición
actual, fue el Investigador Principal para Huawei Investigación de
EE.UU.

redes de área y de malla, redes móviles ad hoc y de sensores, redes 5G, y redes de centros de
datos. Ha sido autor y coautor de más de 100 artículos arbitrados en revistas y congresos
internacionales. 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, IEEEWireless
Comunicaciones, y la Revista Internacional de Sistemas de Comunicaciones. Él es también el
presidente del Grupo de Interés Especial en el centro verde de Datos y Cloud Computing bajo Comité
Técnico IEEE sobre Comunicaciones e Informática Verde (TCGCC). Él es un miembro de alto rango
de la IEEE.
Laboratorios y el Grupo de Trabajo P4P (P4PWG) y Distributed Computing Industry Association. Propuso
P4P (participación de los proveedores proactivos en P2P) para coordinar los proveedores de redes y
aplicaciones peer-to-peer en un artículo seminal publicado en ACM SIGCOMM 2008, llevado a cabo pruebas
y de investigación originales y de gran escala en el P4P. Alentado por y basado en sus investigaciones y
resultados en el P4P, se formó la P4PWG promover estudios académicos y adopciones industriales de P4P,
que posteriormente fue adoptado por el IETF para formar una 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 centrado en el
contenido, la creación de redes fi nida de software-de, futura arquitectura de Internet, y la ingeniería de
tráfico de red fi co.

Dusit Niyato Actualmente es profesor asociado en la Escuela de

Ingeniería Informática, en la Universidad Tecnológica de Nanyang,
Singapur. Obtuvo su Licenciatura de Ingeniería en Ingeniería
Informática por el rey Instituto de Tecnología de Mongkuts
Ladkrabang (KMITL), Bangkok, Tailandia, en 1999. Recibió Ph.D.
en Ingeniería Eléctrica y Computación de la Universidad de
Manitoba, Canadá en

2008. Sus líneas de investigación están en el área de gestión de

recursos de radio en las redes de radio cognitiva y redes de acceso
inalámbrico de banda ancha.

1553-877X (c) 2013 IEEE. El uso personal está permitida, 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.