I.

INTRODUCCION
Los protocolos de red de transporte y control distribuidos que se ejecutan
dentro de los enrutadores y conmutadores son las tecnologas clave que
permiten que la informacin, en forma de paquetes digitales, viaje alrededor
del mundo. A pesar de su adopcin generalizada, las redes IP tradicionales
son complejas y difciles de gestionar [1]. Para expresar las polticas de red
de alto nivel deseadas, los operadores de red deben configurar cada
dispositivo de red individualmente utilizando comandos de bajo nivel y, a
menudo, especficos del proveedor. Adems de la complejidad de la
configuracin, los entornos de red tienen que soportar la dinmica de las
fallas y adaptarse a los cambios de carga. Los mecanismos de
reconfiguracin y respuesta automtica son prcticamente inexistentes en
las redes IP actuales. Por lo tanto, hacer cumplir las polticas requeridas en
un entorno tan dinmico es muy difcil. Para hacerlo an ms complicado,
las redes actuales tambin estn integradas verticalmente. El plano de
control (que decide cmo manejar el trfico de red) y el plano de datos (que
reenva el trfico de acuerdo con las decisiones tomadas por el plano de
control) se agrupan dentro de los dispositivos de red, reduciendo la
flexibilidad y obstaculizando la innovacin y la evolucin de la
infraestructura de red. La transicin de IPv4 a IPv6, iniciada hace ms de
una dcada y an en gran parte incompleta, da testimonio de este desafo,
mientras que de hecho IPv6 representaba simplemente una actualizacin de
protocolo. Debido a la inercia de las redes IP actuales, un nuevo protocolo
de enrutamiento puede tardar entre cinco y diez aos en ser totalmente
diseado, evaluado y desplegado. Del mismo modo, un planteamiento de
pizarra limpia para cambiar la arquitectura de Internet (por ejemplo, la
sustitucin de IP) se considera como una tarea desalentadoraVsimply no
factible en la prctica [2], [3]. En ltima instancia, esta situacin ha inflado
los gastos de capital y operativos de funcionamiento de una red IP. Software
de redes definidas (SDN) [4], [5] es un paradigma de redes emergentes que
da la esperanza de cambiar las limitaciones de las actuales infraestructuras
de red. En primer lugar, rompe la integracin vertical separando la lgica de
control de la red (el plano de control) de los enrutadores y conmutadores
subyacentes que reenvan el trfico (el plano de datos). En segundo lugar,
con la separacin de los planos de control y de datos, los conmutadores de
red se convierten en simples dispositivos de reenvo y la lgica de control se
implementa en un controlador lgicamente centralizado (o sistema
operativo de red1) . Una vista simplificada de esta arquitectura se muestra
en la Fig. 1. Es importante enfatizar que un modelo programtico
lgicamente centralizado no postula un sistema fsicamente centralizado
[7]. De hecho, la necesidad de garantizar niveles adecuados de rendimiento,
escalabilidad y fiabilidad impedira tal solucin. En cambio, los diseos de
redes SDN a nivel de produccin recurren a planos de control fsicamente
distribuidos [7], [8].
La separacin del plano de control y del plano de datos puede realizarse por
medio de una interfaz de programacin bien definida entre los
conmutadores y el controlador SDN. El controlador ejerce control directo
sobre el estado en los elementos del plano de datos a travs de esta
interfaz de programacin de aplicaciones bien definida (API), como se
representa en la Fig. 1. El ejemplo ms notable de tal API es OpenFlow [9],
[10].
Un conmutador OpenFlow tiene una o ms tablas de reglas de manejo de
paquetes (tabla de flujo). Cada regla se corresponde con un subconjunto del
trfico y realiza ciertas acciones (descartar, reenviar, modificar, etc.) en el
trfico. Dependiendo de las reglas instaladas por una aplicacin de
controlador, un conmutador OpenFlow puede ser supervisado por el
controlador. Se comportan como un enrutador, conmutador, cortafuegos o
desempean otras funciones (por ejemplo, equilibrador de carga,
formateador de trfico y, en general, de una caja intermedia). Una
consecuencia importante de los principios de SDN es la separacin de las
preocupaciones introducidas entre la definicin de las polticas de red, su
implementacin en el hardware de conmutacin y la transmisin del trfico.
Esta separacin es clave para la flexibilidad deseada, rompiendo el
problema de control de red en piezas manejables y facilitando la creacin e
introduccin de nuevas abstracciones en redes, simplificando la gestin de
la red y facilitando la evolucin e innovacin de la red. Aunque SDN y
OpenFlow comenzaron como experimentos acadmicos [9], ganaron la
traccin significativa en la industria en los ltimos aos. La mayora de los
vendedores de conmutadores comerciales ahora incluyen el soporte de la
API OpenFlow en su equipo. El impulso de SDN fue lo suficientemente fuerte
como para hacer que Google, Facebook, Yahoo, Microsoft, Verizon y
Deutsche Telekom financiaran Open Networking Foundation (ONF) [10] con
el objetivo principal de promocin y adopcin de SDN a travs del desarrollo
de estndares abiertos. Como las preocupaciones iniciales con la
escalabilidad SDN se abordaron [11] Vin particular el mito de que la
centralizacin lgica implicaba un controlador fsicamente centralizado, un
tema que volveremos a ms adelante las ideas VSDN han madurado y
evolucionado de un ejercicio acadmico a un xito comercial. Google, por
ejemplo, ha desplegado un SDN para interconectar sus centros de datos en
todo el mundo. Esta red de produccin ha estado en despliegue durante tres
aos, ayudando a la compaa a mejorar la eficiencia operativa y reducir
significativamente los costos [8]. La plataforma de virtualizacin de red1 de
VMware, NSX [12], es otro ejemplo. NSX es una solucin comercial que
ofrece una red totalmente funcional en software, provisto
independientemente de los dispositivos de red subyacentes, basado
totalmente en los principios de SDN. Como ltimo ejemplo, las empresas de
TI ms grandes del mundo (desde compaas areas y fabricantes de
equipos hasta proveedores de servicios cloud y compaas de servicios
financieros) se han unido recientemente a consorcios SDN como la ONF y la
iniciativa OpenDaylight [13], otra indicacin de la importancia de SDN
Industrial. Algunos artculos recientes han estudiado aspectos
arquitectnicos especficos de SDN [14] - [16]. En [14] y [15] se puede
encontrar una visin general de OpenFlow y una revisin breve de la
literatura.
Estas encuestas orientadas a OpenFlow presentan una pila de tres capas
relativamente simplificada compuesta de servicios de red de alto nivel,
controladores y la interfaz controlador / conmutador. En [16], Jarraya et al.
Dar un paso ms all proponiendo una taxonoma para SDN. Sin embargo, al
igual que los trabajos anteriores, la encuesta es limitada en trminos de
alcance, y no proporciona un tratamiento en profundidad de los aspectos
fundamentales de SDN. En esencia, las encuestas existentes carecen de una
discusin exhaustiva de los componentes esenciales de un SDN, como los
sistemas operativos de red (NOS), la programacin
Guages, e interfaces. Tambin se quedan cortos en el anlisis de las
cuestiones de capa cruzada, tales como escalabilidad, seguridad y
confiabilidad. Tambin falta una visin ms completa de los esfuerzos de
investigacin en curso, los desafos y las actividades de normalizacin
conexas. En este artculo, presentamos, segn nuestro mejor conocimiento,
la encuesta bibliogrfica ms completa sobre SDN hasta la fecha.
Organizamos esta encuesta como se muestra en la Fig. 2. Empezamos, en
las dos secciones siguientes, explicando el contexto, introduciendo la
motivacin para SDN y explicando los conceptos principales de este nuevo
paradigma y cmo ste difiere de las redes tradicionales. Nuestro objetivo
en la primera parte de la encuesta es tambin para explicar que SDN no es
tan nuevo como un avance tecnolgico. De hecho, su existencia est
arraigada en la interseccin de una serie de "viejas" ideas, impulsores de la
tecnologa y necesidades actuales y futuras. Los conceptos subyacentes a la
separacin de los planos de control y de datos, la abstraccin de flujo sobre
la cual se toman las decisiones de reenvo, la centralizacin (lgica) del
control de la red y la capacidad de programar la red no son novedosas por s
mismas. Sin embargo, la integracin de los conceptos ya probados con las
tendencias recientes en la creacin de redes, como la disponibilidad de
silicio de conmutacin comercial y el enorme inters en formas factibles de
virtualizacin de red, conducen a este cambio de paradigma en la creacin
de redes. Como resultado del alto inters de la industria y el potencial para
cambiar el statu quo de la creacin de redes desde mltiples perspectivas,
se estn llevando a cabo una serie de esfuerzos de estandarizacin
alrededor de SDN, como tambin discutimos en la Seccin III. La seccin IV
es el ncleo de esta encuesta, presentando un anlisis extenso y completo
de los componentes bsicos de una infraestructura SDN usando un enfoque
de abajo hacia arriba, en capas. La opcin para un enfoque en capas se
basa en el hecho de que SDN permite pensar en la creacin de redes a lo
largo de dos conceptos fundamentales, comunes en otras disciplinas de la
informtica: la separacin de las preocupaciones (aprovechando el concepto
de abstraccin) y la recursin. Nuestro enfoque en capas y de abajo hacia
arriba divide el problema de red en ocho partes: 1) infraestructura de
hardware; 2) interfaces hacia el sur; 3) virtualizacin de red (capa de
hipervisor entre los dispositivos de reenvo y los NOS); 4) NOS
(controladores SDN y plataformas de control); 5) interfaces norte (para
ofrecer una abstraccin de programacin comn a las capas superiores,
principalmente las aplicaciones de red); 6) virtualizacin utilizando tcnicas
de corte proporcionadas por bibliotecas de propsito especial o lenguajes de
programacin y compiladores; 7) lenguajes de programacin en red; Y
finalmente 8) aplicaciones de red. Adems, tambin examinamos los
problemas de capa cruzada, como los mecanismos de depuracin y solucin
de problemas. La discusin en la Seccin V sobre los esfuerzos de
investigacin en curso, los retos, el futuro y las oportunidades concluye este
documento.
 II. STATUS QUO EN REDES

Las redes de ordenadores se pueden dividir en tres planos de funcionalidad:

los datos, el control y los planos de gestin (vase la figura 3). El plano de
datos corresponde a los dispositivos de red, que son responsables de
(eficientemente) reenvo de datos. El plano de control representa los
protocolos utilizados para rellenar las tablas de reenvo de los elementos del
plano de datos.
El plano de gestin incluye los servicios de software, tales como el simple
protocolo de gestin de red (SNMP) Basadas en herramientas [18], usadas
para supervisar y configurar remotamente la funcionalidad de control. La
poltica de red se define en el plano de gestin, el plano de control hace
cumplir la poltica y el plano de datos la ejecuta transmitiendo los datos de
forma correspondiente. En las redes IP tradicionales, los planos de control y
datos estn estrechamente acoplados, incrustados en los mismos
dispositivos de red y toda la estructura est altamente descentralizada. Esto
se consider importante para el diseo de Internet en los primeros das:
pareca la mejor manera de garantizar la resiliencia de la red, que era un
objetivo de diseo crucial. De hecho, este enfoque ha sido muy eficaz en
trminos de rendimiento de la red, con un rpido aumento de la tasa de
lnea y las densidades de puertos. Sin embargo, el resultado es una
arquitectura muy compleja y relativamente esttica, como se ha informado
a menudo en la literatura de redes (por ejemplo, [1] - [3], [6] and [19]).
Tambin es la razn fundamental por la cual las redes tradicionales son
rgidas y complejas de manejar y controlar. Estas dos caractersticas son en
gran parte responsables de una industria integrada verticalmente donde la
innovacin es difcil. Las configuraciones errneas de la red y los errores
relacionados son extremadamente comunes en las redes actuales. Por
ejemplo, ms de 1000 errores de configuracin se han observado en el
protocolo de puerta de enlace frontera (BGP) routers [20]. Desde un solo
dispositivo mal configurado, puede resultar un comportamiento de red muy
no deseado (incluyendo, entre otros, prdidas de paquetes, bucles de
reenvo, establecimiento de rutas no deseadas o infracciones del contrato
de servicio). De hecho, aunque raro, un nico router mal configurado es
capaz de comprometer el correcto funcionamiento de toda Internet durante
horas [21], [22]. Para apoyar la gestin de red, un pequeo nmero de
proveedores ofrecen soluciones propietarias de hardware especializado,
sistemas operativos y programas de control (aplicaciones de red). Los
operadores de red tienen que adquirir y mantener diferentes soluciones de
gestin y los correspondientes equipos especializados. El costo de capital y
de operacin de la construccin y mantenimiento de una infraestructura de
redes es significativo, con ciclos de retorno de la inversin largos, que
obstaculizan la innovacin y la adicin de nuevas caractersticas y servicios
(por ejemplo, control de acceso, equilibrio de carga, eficiencia energtica,
ingeniera de trfico). Para aliviar la falta de funcionalidades dentro de la
ruta dentro de la red, una multitud de componentes especializados y
middleboxes, tales como firewalls, sistemas de deteccin de intrusiones y
motores de inspeccin profunda de paquetes, proliferan en las redes
actuales. Una encuesta reciente de 57 redes empresariales muestra que el
nmero de middleboxes ya est a la par con el nmero de routers en las
redes actuales [23]. A pesar de ayudar en las funcionalidades en el camino,
el efecto neto de middleboxes ha aumentado la complejidad del diseo de la
red y su funcionamiento.

III. QU ES EL NETWORKING DEFINIDO POR SOFTWARE?

El trmino SDN fue acuado originalmente para representar las ideas y
trabajar alrededor de OpenFlow en la Universidad de Stanford, Stanford, CA,
los EEUU [24]. Tal como se defini originalmente, SDN se refiere a una
arquitectura de red en la que el estado de reenvo en el plano de datos es
gestionado por un plano controlado remotamente desacoplado del primero.
La industria de redes ha cambiado en muchas ocasiones de esta visin
original de SDN al referirse a cualquier cosa que involucre al software como
SDN. Por lo tanto, intentamos, en esta seccin, proporcionar una definicin
mucho menos ambigua de SDN. Definimos un SDN como una arquitectura
de red con cuatro pilares. 1) Los planos de control y datos estn
desacoplados. La funcionalidad de control se elimina de los dispositivos de
red que se convertirn en simples elementos de reenvo (paquetes). 2) Las
decisiones de reenvo se basan en el flujo, en lugar de basado en el destino.
Un flujo se define ampliamente mediante un conjunto de valores de campo
de paquete que actan como un criterio de coincidencia (filtro) y un
conjunto de acciones (instrucciones). En el contexto SDN / OpenFlow, un
flujo es una secuencia de paquetes entre una fuente y un destino. Todos los
paquetes de un flujo reciben polticas de servicio idnticas en los
dispositivos de reenvo [25], [26]. La abstraccin de flujo permite unificar el
comportamiento de diferentes tipos de dispositivos de red, incluyendo
enrutadores, switches, firewalls y middleboxes [27]. La programacin de
flujo permite una flexibilidad sin precedentes, limitada slo a las
capacidades de las tablas de flujo implementadas [9]. 3) La lgica de control
se mueve a una entidad externa, el denominado controlador SDN o NOS. El
NOS es una plataforma de software que se ejecuta en la tecnologa de
servidor de productos bsicos y proporciona los recursos esenciales y las
abstracciones para facilitar la programacin de los dispositivos de reenvo
basados en una visin de red lgicamente centralizada y abstracta. Su
propsito es, por lo tanto, similar al de un sistema operativo tradicional.
4) La red es programable a travs de aplicaciones de software que se
ejecutan en la parte superior de la NOS que interacta con los dispositivos
de plano de datos subyacentes. Esta es una caracterstica fundamental de
SDN, considerada como su principal proposicin de valor. Obsrvese que la
centralizacin lgica de la lgica de control, en particular, ofrece varios
beneficios adicionales. En primer lugar, es ms sencillo y menos propenso a
modificar las polticas de red a travs de lenguajes de alto nivel y
componentes de software, en comparacin con las configuraciones
especficas de dispositivos de bajo nivel. En segundo lugar, un programa de
control puede reaccionar automticamente a los cambios espurios del
estado de la red y mantener as las polticas de alto nivel intactas. En tercer
lugar, la centralizacin de la lgica de control en un controlador con
conocimiento global del estado de la red simplifica el desarrollo de
funciones, servicios y aplicaciones de redes ms sofisticadas. Siguiendo el
concepto de SDN introducido en [5], un SDN puede ser definido por tres
abstracciones fundamentales: reenvo, distribucin y especificacin. De
hecho, las abstracciones son herramientas esenciales de investigacin en
informtica y tecnologa de la informacin, siendo ya una caracterstica
omnipresente de muchas arquitecturas y sistemas informticos [28].
Idealmente, la abstraccin de reenvo debera permitir cualquier
comportamiento de reenvo deseado por la aplicacin de red (el programa
de control) mientras ocultas detalles del hardware subyacente. OpenFlow es
una realizacin de tal abstraccin, que puede ser vista como el equivalente
a un '' controlador de dispositivo '' en un sistema operativo. La abstraccin
de distribucin debe proteger las aplicaciones SDN de los caprichos del
estado distribuido, haciendo que el problema de control distribuido sea
lgicamente centralizado. Su realizacin requiere una capa de distribucin
comn, que en SDN reside en la NOS. Esta capa tiene dos funciones
esenciales. En primer lugar, es responsable de instalar los comandos de
control en los dispositivos de reenvo. En segundo lugar, recopila
informacin de estado sobre la capa de reenvo (dispositivos de red y
enlaces), para ofrecer una vista de red global a las aplicaciones de red. La
ltima abstraccin es la especificacin, que debera permitir que una
aplicacin de red exprese el comportamiento de red deseado sin ser
responsable de implementar ese comportamiento en s. Esto se puede
lograr a travs de soluciones de virtualizacin, as como lenguajes de
programacin de red. Estos enfoques mapean las configuraciones
abstractas que las aplicaciones expresan basadas en un modelo simplificado
y abstracto de la red, en una configuracin fsica para la vista de red global
expuesta por el controlador SDN. Higo. 4 representa la arquitectura SDN,
conceptos y bloques de construccin.
Como se mencion anteriormente, el fuerte acoplamiento entre los planos
de control y de datos ha dificultado la adicin de nueva funcionalidad a las
redes tradicionales, hecho ilustrado en la Fig. 5. El acoplamiento de los
planos de control y de datos (y su incorporacin fsica en los elementos de
red) hace muy difcil el desarrollo y despliegue de nuevas funciones de red
(por ejemplo, algoritmos de enrutamiento), ya que implicara una
modificacin del plano de control de todos Dispositivos de red mediante la
instalacin de nuevos firmware y, en algunos casos, actualizaciones de
hardware. Por lo tanto, las nuevas caractersticas de la red se introducen
comnmente a travs de equipos caros, especializados y difciles de
configurar (tambin conocidos como middleboxes) como equilibradores de
carga, sistemas de deteccin de intrusiones (IDS) y firewalls, entre otros.
Estas cajas de medio tienen que colocarse estratgicamente en la red, lo
que hace an ms difcil cambiar la topologa de la red, configuracin y
funcionalidad. Por el contrario, SDN desacopla el plano de control de los
dispositivos de red y se convierte en una entidad externa: el controlador
NOS o SDN. Este enfoque tiene varias ventajas. Es ms fcil programar
estas aplicaciones, ya que las abstracciones proporcionadas por la
plataforma de control y / o los lenguajes de programacin de red pueden ser
compartidos. Todas las aplicaciones pueden aprovechar la misma
informacin de red (la visin de red global), lo que conduce (posiblemente)
a decisiones de poltica ms consistentes y eficaces, al tiempo que reutiliza
mdulos de software de plano de control. Estas aplicaciones pueden tomar
acciones (es decir, reconfigurar dispositivos de reenvo) desde cualquier
parte de la red. Por lo tanto, no es necesario disear una estrategia precisa
sobre la ubicacin de la nueva funcionalidad. La integracin de diferentes
aplicaciones se hace ms directa [29]. Por ejemplo, load ba
Lancing y las aplicaciones de enrutamiento se pueden combinar
secuencialmente, con las decisiones de equilibrio de carga que tienen
precedencia sobre las polticas de enrutamiento.
A. Terminologa Para identificar los diferentes elementos de un SDN tan
inequvocamente como sea posible, presentamos ahora la terminologa
esencial utilizada a lo largo de este trabajo.
1) Dispositivos de reenvo (FD): Son dispositivos de plano de datos basados
en hardware o software que realizan un conjunto de operaciones
elementales. Los dispositivos de reenvo tienen conjuntos de instrucciones
bien definidos (por ejemplo, reglas de flujo) usados para tomar acciones en
los paquetes entrantes (por ejemplo, dirigir a puertos especficos, soltar,
enviar al controlador, reescribir algn encabezado). Estas instrucciones
estn definidas por interfaces hacia el sur (por ejemplo, OpenFlow [9],
ForCES [30], protocoloblivious reenvo (POF) [31]) y se instalan en los
dispositivos de reenvo por los controladores SDN implementar los
protocolos southbound.
2) Plano de datos (DP): Los dispositivos de reenvo estn interconectados a
travs de canales de radio inalmbricos o cables cableados. La
infraestructura de red comprende los dispositivos de reenvo
interconectados, que representan el plano de datos.
3) Interfaz de direccin sur (SI): El conjunto de instrucciones de los
dispositivos de reenvo est definido por la API hacia el sur, que forma parte
de la interfaz hacia el sur. Adems, el SI tambin define el protocolo de
comunicacin entre dispositivos de reenvo y elementos de plano de control.
Este protocolo formaliza la forma en que interactan los elementos del
plano de control y de datos.
4) Plano de control (CP): Los dispositivos de reenvo se programan mediante
elementos de plano de control a travs de realizaciones de SI bien definidas.
El plano de control puede ser visto como el "cerebro de red". Todas las
lgicas de control descansan en las aplicaciones y controladores, que
forman el plano de control.
5) Northbound Interface (NI): La NOS puede ofrecer una API a los
desarrolladores de aplicaciones. Esta API representa una interfaz hacia el
norte, es decir, una interfaz comn para desarrollar aplicaciones.
Normalmente, una interfaz en direccin norte abstrae los conjuntos de
instrucciones de bajo nivel utilizados por las interfaces en direccin sur para
los dispositivos de reenvo de programas.
6) Plano de Gestin (MP): El plano de gestin es el conjunto de aplicaciones
que aprovechan las funciones ofrecidas por el NI para implementar el
control de red y la lgica de operacin. Esto incluye aplicaciones como
enrutamiento, cortafuegos, equilibradores de carga, supervisin, etc.
Esencialmente, una aplicacin de gestin define las directivas, que en
ltima instancia se traducen a instrucciones especficas hacia el sur que
programan el comportamiento de los dispositivos de reenvo.
B. Definiciones alternativas y ampliantes Desde su creacin en 2010 [24], el
trmino original SDN centrado en OpenFlow ha visto ampliado su alcance
ms all de las arquitecturas con una interfaz de plano de control
claramente disociada. Es probable que la definicin de SDN contine
amplindose, impulsada por los puntos de vista de la industria orientados a
los negocios sobre SDN, independientemente del desacoplamiento del plano
de control. En esta encuesta, nos enfocamos en la definicin original, ''
cannica '' de la SDN basada en los pilares claves antes mencionados y en
el concepto de abstracciones en capas. Sin embargo, en aras de la
integridad y la claridad, reconocemos las definiciones alternativas SDN [32],
como sigue.
1) Plano de control / Broker SDN: Un enfoque de red que retiene los planos
de control distribuidos existentes pero ofrece nuevas API que permiten a las
aplicaciones interactuar (bidireccionalmente) con la red. Un controlador de
SDN, llamado a menudo plataforma de orquestacin, acta como
intermediario entre las aplicaciones y los elementos de red. Este enfoque
presenta efectivamente datos de plano de control a la aplicacin y permite
un cierto grado de programacin de red mediante "plug-ins" entre la funcin
del orquestador y los protocolos de red. Esta aproximacin impulsada por
API corresponde a un modelo hbrido de SDN, ya que permite al
intermediario manipular e interactuar directamente con los planos de
control de dispositivos tales como enrutadores y conmutadores. Ejemplos de
este punto de vista sobre SDN incluyen esfuerzos de normalizacin
recientes en el Grupo de Trabajo de Ingeniera de Internet (IETF) (vase
Seccin III-C) y la filosofa de diseo detrs del proyecto OpenDaylight [13]
que va ms all del modo de control de divisin de OpenFlow.
2) Overlay SDN: Es un enfoque de red en el que el borde de la red (software
o hardware) est dinmicamente programado para gestionar tneles entre
hipervisores y / o conmutadores de red, introduciendo una red de
superposicin. En este enfoque de redes hbridas, el plano de control
distribuido que proporciona la base permanece intacto. El plano de control
centralizado proporciona una superposicin lgica que utiliza la base como
una red de transporte. Este sabor de SDN sigue un modelo proactivo para
instalar los tneles de superposicin. Los tneles de superposicin
generalmente terminan dentro de conmutadores virtuales dentro de
hipervisores o en dispositivos fsicos que actan como puertas de enlace a
la red existente. Este enfoque es muy popular en la reciente virtualizacin
de redes de centros de datos [33], y se basan en una variedad de
tecnologas de tunelizacin (por ejemplo, aptridas de transporte de tneles
[34], virtualizado de capa 2 redes (VXLAN) [35] Encapsulacin (NVGRE) [36],
localizador / ID de separacin de protocolo (LISP) [37], [38], y la red
genrica de virtualizacin encapsulacin (GENEVE) [39]] [40].
Recientemente, otros intentos de definir SDN en una aproximacin en capas
han aparecido [16], [41] .Fromapracticalperspective y tratando de mantener
la compatibilidad con los enfoques existentes de gestin de red, una
iniciativa en el IRTF Software Defined Networking Research Group (SDNRG)
[41] propone un plano de gestin al mismo nivel del plano de control, es
decir, clasifica las soluciones en dos categoras: lgica de control (con
interfaces de control en direccin sur) y lgica de gestin (con interfaces de
direccin en direccin sur). En otras palabras, el plano de gestin puede ser
visto como una plataforma de control que acomoda servicios y protocolos
tradicionales de gestin de red, tales como SNMP [18], BGP [42], protocolo
de comunicacin de elementos de clculo de trayectoria (PCEP) [43] y
configuracin de red Protocolo (NETCONF) [44]. Adems de las definiciones
de ampliacin anteriores, el trmino SDN se utiliza a menudo para definir
planos de gestin de red extensibles (por ejemplo, OpenStack [45]),
switches whitebox / baremetal con sistemas operativos abiertos (por
ejemplo, Cumulus Linux) Por ejemplo, Pica8 Xorplus [46], Quagga [47]),
dispositivos de hardware programables especializados (por ejemplo,
NetFPGA [48]), dispositivos virtualizados basados en software (por ejemplo,
plataforma abierta para virtualizacin de funciones de red A pesar de
carecer de un control desacoplado y un plano de datos o una interfaz comn
a lo largo de su API. Los modelos hbridos SDN se discuten ms
detalladamente en la Seccin V-G.
C. Actividades de normalizacin El panorama de la normalizacin en SDN (y
cuestiones relacionadas con SDN) ya es amplio y se espera que siga
evolucionando con el tiempo. Mientras que algunas de las actividades se
llevan a cabo en organizaciones de desarrollo estndar (SDOs), otros
esfuerzos relacionados estn en curso en consorcios industriales o
comunitarios (por ejemplo, OpenDaylight, OpenStack, OPNFV), entregando
resultados a menudo considerados candidatos para los estndares de facto.
Estos resultados a menudo vienen en la forma de implementaciones de
cdigo abierto que se han convertido en la estrategia comn hacia la
aceleracin de SDN y relacionados con la nube y las tecnologas de red [50].
La razn de esta fragmentacin se debe a los conceptos de SDN que
abarcan diferentes reas de TI y redes, tanto desde un punto de vista de
segmentacin de red (desde el acceso al ncleo) como desde una
perspectiva tecnolgica (desde ptica a inalmbrica). La Tabla 1 presenta un
resumen de las principales ODS y organizaciones que contribuyen a la
estandarizacin de las NDS, as como los principales resultados obtenidos
hasta la fecha. La ONF fue concebida como una organizacin dirigida por
miembros para promover la adopcin de SDN a travs del desarrollo del
protocolo OpenFlow como un estndar abierto para comunicar decisiones de
control a dispositivos de plano de datos. La ONF est estructurada en varios
grupos de trabajo (GT). Algunos GT se centran en la definicin de
extensiones del protocolo OpenFlow en general, como el GT de
extensibilidad, o adaptadas a reas tecnolgicas especficas. Ejemplos de
este ltimo incluyen el GT de transporte ptico (OT), el WG inalmbrico y
mvil (W & M) y el GT de interfaces norte (NBI). Otros grupos de trabajo
centran su actividad en proporcionar nuevas capacidades de protocolo para
mejorar el propio protocolo, como el GT de arquitectura o el GT de
abstracciones de retransmisin (FA).

Similar a cmo las ideas de programacin de red han sido consideradas por
varios grupos de trabajo de IETF (GTs) en el pasado, la actual tendencia SDN
tambin est influyendo en una
Nmero de actividades. Un organismo relacionado que se centra en
aspectos de investigacin para la evolucin de Internet, IRTF, ha creado el
SDNRG. Este grupo investiga SDN desde varias perspectivas con el objetivo
de identificar los enfoques que se pueden definir, desplegar y utilizar en el
corto plazo, as como identificar los desafos de bsqueda futuros. En el
Sector de Telecomunicaciones de la Unin Internacional de
Telecomunicaciones (UIT-T), algunas Comisiones de Estudio ya han
comenzado a elaborar recomendaciones para SDN y se ha establecido una
Actividad de Coordinacin Conjunta sobre SDN (JCASDN) para coordinar la
labor de normalizacin del SDN. El Foro de Banda Ancha (BBF) est
trabajando en temas de SDN a travs del WG del Servicio de Innovacin y
Requisitos de Mercado (SIMR). El objetivo del BBF es publicar
recomendaciones para apoyar SDN en redes multiservicio de banda ancha,
incluyendo entornos hbridos en los que solo parte del equipo de red est
habilitada para SDN. El Metro Ethernet Forum (MEF) se est acercando a
SDN con el objetivo de definir la orquestacin de servicios con APIs para las
redes existentes. En el IEEE, el 802 LAN / MAN Standards Committee ha
iniciado recientemente algunas actividades para estandarizar las
capacidades de SDN en redes de acceso basadas en la infraestructura IEEE
802 a travs del proyecto P802.1CF, tanto para tecnologas cableadas como
inalmbricas para adoptar nuevas interfaces de control. El Foro de
Operadores de Redes pticas (OIF) Carrier WG public un conjunto de
requisitos para el transporte SDN. Las actividades iniciales tienen como
objetivo principal describir las caractersticas y funcionalidades necesarias
para soportar el despliegue de capacidades SDN en redes de transporte
portador. Open Data Center Alliance (ODCA) es una organizacin que trabaja
en la unificacin de centros de datos en la migracin a entornos de cloud
computing a travs de soluciones interoperables. A travs de la
documentacin de modelos de uso, especficamente uno para SDN, ODCA
est definiendo nuevos requisitos para el despliegue de la nube. La Alianza
para las Soluciones de la Industria de las Telecomunicaciones (ATIS) cre un
grupo focal para analizar las cuestiones operacionales y las oportunidades
asociadas con las capacidades programables de la infraestructura de red. En
el Instituto Europeo de Normas de Telecomunicaciones (ETSI), se estn
dedicando esfuerzos a la virtualizacin de funciones de red (NFV) a travs
de un Grupo de Especificacin de la Industria (ISG) recientemente definido.
Los conceptos de NFV y SDN se consideran complementarios, compartiendo
el objetivo de acelerar la Innovacin dentro de la red permitiendo la
programacin y cambiando completamente el modelo operativo de la red a
travs de la automatizacin y un cambio real a las plataformas basadas en
software. Por ltimo, el consorcio del proyecto de asociacin de tercera
generacin de la industria de redes mviles est estudiando la gestin de
redes virtualizadas, un esfuerzo alineado con la arquitectura ETSI NFV y,
como tal, susceptible de apalancarse de SDN.
D. Historia de SDN Aunque un concepto bastante reciente, SDN aprovecha
ideas de redes con una historia ms larga [17]. En particular, se basa en
trabajos realizados en redes programables, como redes activas [81], redes
ATM programables [82], [83] y en propuestas de control y separacin de
planos de datos, como el punto de control de red (PCN) [84] y la plataforma
de control de enrutamiento (BCP) [85]. Con el fin de presentar una
perspectiva histrica, resumimos en la Tabla 2 diferentes instancias de
trabajo relacionado con SDN antes de SDN, dividindolo en cinco categoras.
Junto con las categoras que definimos, la segunda y tercera columnas de la
tabla mencionan iniciativas pasadas (pre-SDN, es decir, antes de las
iniciativas basadas en OpenFlow que surgieron en el concepto de SDN) y
desarrollos recientes que condujeron a la definicin de SDN. La
programacin del plano de datos tiene una larga historia. Las redes activas
[81] representan uno de los primeros intentos de construir nuevas
arquitecturas de red basadas en este concepto. La idea principal detrs de
las redes activas es que cada nodo tenga la capacidad de realizar clculos o
modificar el contenido de los paquetes. Con este fin, las redes activas
proponen dos enfoques distintos: interruptores programables y cpsulas. El
formador no cambia automticamente en el formato de paquete o celda
existente. Asume que los dispositivos de conmutacin soportan la descarga
de programas con instrucciones especficas sobre cmo procesar paquetes.
Por otra parte, la segunda aproximacin sugiere que los paquetes deben ser
reemplazados por pequeos programas, que se encapsulan en tramas de
transmisin y se ejecutan en cada nodo a lo largo de su trayectoria. ForCES
[30], OpenFlow [9] y POF [31] representan enfoques recientes para el diseo
y despliegue de dispositivos de plano de datos programables. De una
manera diferente a las redes activas, estas nuevas propuestas se basan
esencialmente en la modificacin de dispositivos de reenvo para soportar
tablas de flujo, que pueden ser configuradas dinmicamente por entidades
remotas a travs de operaciones simples tales como aadir, eliminar o
actualizar reglas de flujo, es decir, mesas. Las primeras iniciativas de
separacin de datos y sealizacin de control datan de los aos ochenta y
noventa. El NCP [84] es probablemente el primer intento de separar el
control y la sealizacin del plano de datos. AT & T introdujo PCN para
mejorar la gestin y el control de su red telefnica. Este cambio promovi
un ritmo ms rpido de innovacin de la red y proporcion nuevos medios
para mejorar su eficiencia, aprovechando la visin global de la red
proporcionada por NCP. De manera similar, otras iniciativas como Tempest
[96], ForCES [30], RCP [85] Y PCE [43] propuso la separacin de los planos
de control y datos para la gestin mejorada en ATM, Ethernet, BGP, y las
redes de conmutacin de etiquetas multiprotocolo (MPLS), respectivamente.
Ms recientemente, iniciativas como SANE [100], Ethane [101], OpenFlow
[9], NOX [26] y POF [31] propusieron el desacoplamiento de los planos de
control y datos para las redes Ethernet. Curiosamente, estas soluciones
recientes no requieren modificaciones significativas en los dispositivos de
reenvo, hacindolos atractivos no slo para la comunidad de investigacin
en red, sino an ms para la industria de redes. Por ejemplo, los dispositivos
basados en OpenFlow [9] pueden coexistir fcilmente con los dispositivos
Ethernet tradicionales, lo que permite una adopcin progresiva (es decir,
que no requiere un cambio perturbador en las redes existentes). La
virtualizacin de la red ha ganado una nueva traccin con la llegada de
SDN. Sin embargo, la virtualizacin de la red tambin tiene sus races en la
dcada de 1990. El proyecto Tempest [96] es una de las primeras iniciativas
para introducir la virtualizacin de redes, introduciendo el concepto de
switchlets en redes ATM. La idea central era permitir mltiples switchlets
encima de un nico conmutador ATM, permitiendo que mltiples redes ATM
independientes compartan los mismos recursos fsicos. Del mismo modo,
MBone [102] fue una de las primeras iniciativas que apunt a la creacin de
topologas de redes virtuales en la parte superior de las redes de legado, o
superposicin de redes. A este trabajo le siguieron otros proyectos como
Planet Lab [105], GENI [107] y VINI [108]. FlowVisor [119] tambin es digno
de mencin como una de las primeras iniciativas recientes para promover
una arquitectura de virtualizacin de tipo hipervisor para infraestructuras de
red, parecida al modelo de hipervisor comn para el clculo y el
almacenamiento. Ms recientemente, Koponen et al. Propuso una
plataforma de virtualizacin de red (NVP) [112] para centros de datos
multitenant utilizando SDN como una tecnologa de base. El concepto de
NOS renaci con la introduccin de NOSs basados en OpenFlow, como NOX
[26], Onix [7] y ONOS [117]. De hecho, NOSs han estado en existencia
durante dcadas. Uno de los ms conocidos y desplegados es el Cisco IOS
[113], que fue originalmente concebido a principios de 1990. Otras NOS que
vale la pena mencionar son JUNOS [114], ExtremeXOS [115], y SR OS [116].
A pesar de ser NOSs ms especializados, dirigidos a dispositivos de red
como enrutadores principales de alto rendimiento, estos NOS resumen el
hardware subyacente al operador de red, facilitando el control de la
infraestructura de red y simplificando el desarrollo y la implementacin de
nuevos protocolos y aplicaciones de gestin . Por ltimo, tambin vale la
pena recordar las iniciativas que pueden considerarse impulsores de la
tecnologa. En la dcada de 1990, comenz a ocurrir un movimiento hacia la
sealizacin abierta [118]. La motivacin principal fue promover la adopcin
ms amplia de las ideas propuestas por proyectos como el NCP [84] y
Tempest [96]. El movimiento de sealizacin abierto trabaj para separar el
control y la sealizacin de datos al proponer interfaces abiertas y
programables. Curiosamente, un movimiento bastante similar se puede
observar con el reciente advenimiento de OpenFlow y SDN, con el liderazgo
de la ONF [10]. Este tipo de movimiento es crucial para promover las
tecnologas abiertas en el mercado, con la esperanza de liderar a los
fabricantes de equipos para apoyar estndares abiertos y as fomentar la
interoperabilidad, la competencia y la innovacin. Para una historia
intelectual ms extensa de redes programables y SDN, dirigimos al lector al
reciente artculo de Feamster et al. [17].
IV. REDES DEFINIDAS POR SOFTWARE: BOTTOM-UP
Una arquitectura SDN puede ser representada como una composicin de
capas diferentes, como se muestra en la Fig. 6 (b). Cada capa tiene sus
propias funciones especficas. Mientras que algunos de ellos estn siempre
presentes en una implementacin SDN, como la API hacia el sur, las NOS, la
API hacia el norte y las aplicaciones de red, otras pueden estar presentes
slo en implementaciones particulares, como la virtualizacin basada en
hipervisor o en lenguaje. La fig. 6 presenta una perspectiva triple de las
NSS. Las capas SDN se representan en la Fig. 6 (b), como se explic
anteriormente. La fig. 6 (a) y (c) representa una vista orientada en plano y
una perspectiva de diseo de sistema, respectivamente. Las siguientes
secciones introducen cada capa, siguiendo un enfoque ascendente. Para
cada capa, las propiedades y conceptos del ncleo se explican en base a las
diferentes tecnologas y soluciones. Adems, se discuten las tcnicas y
herramientas de depuracin y solucin de problemas.
A. Capa I: Infraestructura
Una infraestructura SDN, similar a una red tradicional, est compuesta por
un conjunto de equipos de red (switches, routers y dispositivos de
middlebox). La principal diferencia reside en el hecho de que esos
dispositivos fsicos tradicionales son ahora simples elementos de reenvo sin
control incorporado o software para tomar decisiones autnomas. La
inteligencia de red se elimina de los dispositivos de plano de datos a un
sistema de control lgicamente centralizado, es decir, las NOS y
aplicaciones, como se muestra en la Fig. 6 (c). Ms importante an, estas
nuevas redes se construyen (conceptualmente) sobre interfaces abiertas y
estndar (por ejemplo, OpenFlow), un enfoque crucial para asegurar la
compatibilidad de la configuracin y la comunicacin y la interoperabilidad
entre diferentes dispositivos de datos y planos de control. En otras palabras,
estas interfaces abiertas permiten a las entidades controladoras programar
dinmicamente dispositivos de reenvo heterogneos, algo difcil en las
redes tradicionales, debido a la gran variedad de interfaces propietarias y
cerradas ya la naturaleza distribuida del plano de control. En una
arquitectura SDN / OpenFlow, hay dos elementos principales, los
controladores y los dispositivos de reenvo, como se muestra en la Fig. 7. Un
dispositivo de plano de datos es un elemento de hardware o software
especializado en el reenvo de paquetes, mientras que un controlador es
una pila de software (el "cerebro de red") que se ejecuta en una plataforma
de hardware de productos bsicos. Un dispositivo de reenvo
OpenFlowenabled se basa en una tubera de tablas de flujo donde cada
entrada de una tabla de flujo tiene tres partes: 1) una regla de coincidencia;
2) acciones a ejecutar en paquetes coincidentes; Y 3) contadores que
mantienen las estadsticas de paquetes coincidentes. Este modelo de alto
nivel y simplificado derivado de
OpenFlow es actualmente el diseo ms extendido de los dispositivos de
plano de datos SDN. Sin embargo, se estn llevando a cabo otras
especificaciones de los dispositivos de reenvo habilitados para SDN,
incluidos POF [31], [120] y los modelos negociables de datapath (NDMs) del
Grupo de Trabajo de Abstracciones de Transmisin de la ONF (FAWG). Dentro
de un dispositivo OpenFlow, una ruta a travs de una secuencia de tablas
de flujo define cmo se deben manejar los paquetes. Cuando un nuevo
paquete llega, el proceso de bsqueda comienza en la primera tabla y
termina con una coincidencia en una de las tablas de la tubera o con una
falta (cuando no se encuentra ninguna regla para ese paquete). Una regla
de flujo se puede definir combinando diferentes campos de coincidencia,
como se ilustra en la Fig. 7. Si no hay una regla por defecto, el paquete ser
descartado. Sin embargo, el caso comn es instalar una regla
predeterminada que indica al conmutador que enve el paquete al
controlador (oa la tubera normal no OpenFlow del conmutador). La
prioridad de las reglas sigue el nmero de secuencia natural de las tablas y
el orden de filas en una tabla de flujo. Las acciones posibles incluyen: 1)
enviar el paquete a los puertos salientes; 2) encapsularlo y enviarlo al
controlador; 3) dejarlo caer; 4) enviarlo a la tubera de procesamiento
normal y 5) enviarlo a la siguiente tabla de flujo oa tablas especiales, tales
como las tablas de grupo o de medicin presentadas en el ltimo protocolo
de OpenFlow. Como se detalla en la Tabla 3, cada versin de la
especificacin OpenFlow introdujo nuevos campos de coincidencia
incluyendo Ethernet, IPv4 / v6, MPLS, TCP / UDP, etc. Sin embargo, slo un
subconjunto de los campos coincidentes son obligatorios para ser
compatibles con una versin de protocolo dada . Del mismo modo, muchas
acciones y tipos de puertos son caractersticas opcionales. Las reglas de
coincidencia de flujo pueden basarse en combinaciones casi arbitrarias de
bits de los diferentes encabezados de paquetes utilizando mscaras de bits
para cada campo. La adicin de nuevos campos coincidentes se ha
facilitado con las capacidades de extensibilidad introducidas en OpenFlow
versin 1.2 a travs de un OpenFlow Extensible Match (OXM) basado en
estructuras de longitud de tipo (TLV). Para mejorar la extensibilidad general
del protocolo, con la versin 1.4 de OpenFlow, tambin se han agregado
estructuras TLV a puertos, tablas y colas en sustitucin de las contrapartidas
codificadas de versiones anteriores de protocolos.
1) Visin general de los dispositivos OpenFlow disponibles: Existen varios
dispositivos de reenvo habilitados para OpenFlow disponibles en el
mercado, tanto como productos comerciales como de cdigo abierto (ver
Tabla 4).
Hay muchos disponibles en el mercado, listos para implementar,
conmutadores y enrutadores OpenFlow, entre otros dispositivos. La mayora
de los conmutadores disponibles en el mercado tienen memoria ternaria
relativamente accesible (TCAMs), con hasta 8000 entradas. Sin embargo,
esto est cambiando a un ritmo acelerado. Algunos de los ltimos
dispositivos lanzados en el mercado van mucho ms all de esa cifra. Los
conmutadores Gigabit Ethernet (GbE) para propsitos comerciales comunes
ya soportan hasta 32 000 flujos de coincidencia exacta de Capa 2 (L2) +
Capa 3 (L3) o 64 000 L2 / L3 [122]. Los switches de clase empresarial 10GbE
se entregan con ms de 80 000 entradas de flujo de capa 2 [123]. Otros
dispositivos de conmutacin que utilizan chips de alto rendimiento (por
ejemplo, EZchip NP-4) proporcionan
Memoria TCAM optimizada que admite desde 125 000 hasta 1 000 000
entradas de la tabla de flujo [124]. Esto es una clara seal de que el tamao
de las tablas de flujo est creciendo a un ritmo que apunta a satisfacer las
necesidades de futuras implementaciones SDN. Los fabricantes de equipos
de red han producido varios tipos de dispositivos habilitados para OpenFlow,
como se muestra en la Tabla 4. Estos dispositivos van desde equipos para
pequeas empresas (por ejemplo, conmutadores GbE) hasta equipos de alta
clase (por ejemplo, chasis de alta densidad con chasis Conectividad de
hasta 100GbE para aplicaciones de borde a ncleo, con decenas de terabits
por segundo de capacidad de conmutacin). Los conmutadores de software
estn surgiendo como una de las soluciones ms prometedoras para los
centros de datos y las infraestructuras de redes virtualizadas [147] - [149].
Ejemplos de implementaciones de switch OpenFlow basadas en software
incluyen Switch Light [145], ofsoftswitch13 [141], Open vSwitch [142],
OpenFlow Reference [143], Pica8 [150], Pantou [146] y XorPlus [46].
Informes recientes muestran que el nmero de puertos de acceso virtual es
ya mayor que los puertos de acceso fsico en los centros de datos [149]. La
virtualizacin de la red ha sido uno de los motores detrs de esta tendencia.
Interruptores de software como Open vSwitch se han utilizado para mover
las funciones de red al borde (con el ncleo realizando el reenvo IP
tradicional), permitiendo as la virtualizacin de la red [112]. Una
observacin interesante es el nmero de pequeas empresas de
lanzamiento dedicadas a SDN, como Big Switch, Pica8, Cyan, Plexxi y
NoviFlow. Esto parece implicar que SDN est creando un mercado de redes
ms competitivo y abierto, uno de sus objetivos originales. Otros efectos de
esta apertura desencadenada por SDN incluyen la aparicin de los llamados
"conmutadores de metal desnudo" o "conmutadores de cuadro blanco",
donde el software y la seguridad se guardan separadamente y el usuario
final es libre de cargar un sistema operativo de su eleccin [151].
B. Layer II: Southbound Interfaces Las interfaces Southbound (o southbound
APIs) son los puentes de conexin entre elementos de control y de reenvo,
siendo as el instrumento crucial para separar claramente el control y la
funcionalidad del plano de datos. Sin embargo, estas API todava estn
estrechamente vinculadas a los elementos de reenvo de la infraestructura
fsica o virtual subyacente. Normalmente, un nuevo conmutador puede
tardar dos aos en estar listo para la comercializacin si se construye desde
cero, con ciclos de actualizacin que pueden tardar hasta nueve meses. El
desarrollo de software para un nuevo producto puede tomar desde seis
meses hasta un ao [152]. El principal componente de su diseo, Las API
hacia el sur representan una serie de barreras para la introduccin y la
aceptacin de cualquier otra tecnologa de red. En la actualidad, la aparicin
de propuestas de API de SDN hacia el sur como OpenFlow [9] es vista como
bienvenida por muchos en la industria. Estas normas promueven la
interoperabilidad, permitiendo el despliegue de dispositivos de red
agnsticos de proveedores. Esto ya ha sido demostrado por la
interoperabilidad entre equipos habilitados para OpenFlow de diferentes
proveedores. A partir de esta escritura, OpenFlow es el ms aceptado y
desplegado abierto southbound estndar para SDN. Proporciona una
especificacin comn para implementar dispositivos de reenvo habilitados
para OpenFlow, y para el canal de comunicacin entre datos y dispositivos
de plano de control (por ejemplo, conmutadores y controladores). El
protocolo OpenFlow proporciona tres fuentes de informacin para NOS. En
primer lugar, los mensajes basados en eventos se envan mediante reenvo
de dispositivos al controlador cuando se activa un enlace o cambio de
puerto. En segundo lugar, las estadsticas de flujo son generadas por los
dispositivos de reenvo y
Recogida por el controlador. En tercer lugar, los mensajes de paquete son
enviados por los dispositivos de reenvo al controlador cuando no saben qu
hacer con un nuevo flujo entrante o porque hay una accin explcita "enviar
al controlador" en la entrada coincidente de la tabla de flujo. Estos canales
de informacin son los medios esenciales para proporcionar informacin a
nivel de flujo a la NOS. Aunque sea el ms visible, OpenFlow no es la nica
interfaz southbound disponible para SDN. Existen otras propuestas API tales
como ForCES [30], Open vSwitch Database (OVSDB) [153], POF [31], [120],
OpFlex [154], OpenState [155], revisin de la librera de flujo abierto (ROFL)
156], la capa de abstraccin de hardware (HAL) [157], [158], y la
abstraccin programable de la ruta de datos (PAD) [159]. ForCES propone un
enfoque ms flexible de la gestin de red tradicional sin cambiar la
arquitectura actual de la red, es decir, sin necesidad de un controlador
externo lgicamente centralizado. Los planos de control y de datos estn
separados, pero pueden mantenerse potencialmente en el mismo elemento
de red. Sin embargo, la parte de control del elemento de red se puede
actualizar sobre la marcha con el firmware de terceros. OVSDB [153] es otro
tipo de API orientada hacia el sur, diseada para proporcionar capacidades
avanzadas de administracin para Open vSwitches. Ms all de las
capacidades de OpenFlow para configurar el comportamiento de los flujos
en un dispositivo de reenvo, Open vSwitch ofrece otras funciones de red.
Por ejemplo, permite a los elementos de control crear varias instancias de
conmutacin virtual, establecer polticas de calidad de servicio (QoS) en
interfaces, adjuntar interfaces a los conmutadores, configurar interfaces de
tnel en rutas de datos de OpenFlow, gestionar colas y recopilar
estadsticas. Por lo tanto, el OVSDB es un protocolo complementario a
OpenFlow para Open vSwitch. Uno de los primeros competidores directos de
OpenFlow es POF [31], [120]. Uno de los objetivos principales de POF es
mejorar el actual plano de reenvo SDN. Con OpenFlow, los conmutadores
tienen que entender los encabezados de los protocolos para extraer los bits
necesarios para que coincidan con las entradas de las tablas de flujo. Este
anlisis representa una carga significativa para los dispositivos de plano de
datos, en particular si consideramos que OpenFlow versin 1.3 ya contiene
ms de 40 campos de encabezado. Adems de esta complejidad inherente,
problemas de compatibilidad con versiones anteriores pueden surgir cada
vez que nuevos campos de encabezado se incluyen o se quitan del
protocolo. Para lograr su objetivo, POF propone un conjunto de instrucciones
de flujo genrico (FIS) que hace que el protocolo del plano de reenvo no
tenga en cuenta.
Un elemento de reenvo no necesita saber, por s mismo, nada sobre el
formato de paquete por adelantado. Los dispositivos de reenvo son vistos
como cajas blancas con slo capacidades de procesamiento y reenvo. En
POF, el anlisis de paquetes es una tarea de controlador que da como
resultado una secuencia de claves genricas y instrucciones de bsqueda
de tabla que se instalan en los elementos de reenvo. El comportamiento de
los dispositivos de plano de datos est, por lo tanto, completamente bajo el
control del controlador SDN. Similar a una unidad de procesamiento central
(CPU) en un sistema informtico, un conmutador POF es agnstico de
aplicacin y protocolo. Una propuesta de interfaz southbound reciente es
OpFlex [154]. Contrariamente a OpenFlow (y similar a ForCES), una de las
ideas detrs de OpFlex es distribuir parte de la complejidad de la gestin de
la red a los dispositivos de reenvo, con el objetivo de mejorar la
escalabilidad. De forma similar a OpenFlow, las directivas son lgicamente
centralizadas y abstradas de la implementacin subyacente. Las diferencias
entre OpenFlow y OpFlex son una clara ilustracin de una de las preguntas
importantes que se deben responder al disear una interfaz hacia el sur:
dnde colocar cada pieza de la funcionalidad general. A diferencia de
OpFlex y POF, OpenState [155] y ROFL [156] no proponen un nuevo
conjunto de instrucciones para programar dispositivos planos de datos.
OpenState propone mquinas finitas extendidas (abstracciones de
programacin con estado) como una extensin (superconjunto) de la
abstraccin de coincidencia / accin de OpenFlow. Las mquinas de estado
finito permiten la implementacin de varias tareas con estado dentro de los
dispositivos de reenvo, es decir, sin aumentar la complejidad o la
sobrecarga del plano de control. Por ejemplo, todas las tareas que implican
slo el estado local, como las operaciones de aprendizaje de control de
acceso a medios (MAC), el acceso de puerta o los cortafuegos de borde con
estado, se pueden realizar directamente en los dispositivos de reenvo sin
ninguna comunicacin de control y retardo de procesamiento adicionales.
ROFL, por otra parte, propone una capa de abstraccin que oculta los
detalles de las diferentes versiones de OpenFlow, proporcionando as una
API limpia para desarrolladores de software, simplificando el desarrollo de
aplicaciones.
HAL [157], [158] no es exactamente una API hacia el sur, pero est
estrechamente relacionada. Diferentemente de los enfoques mencionados
anteriormente, HAL es ms bien un traductor que permite una API hacia el
sur como OpenFlow para controlar dispositivos de hardware heterogneos.
Por lo tanto, se encuentra entre la API hacia el sur y el dispositivo de
hardware. Recientes experimentos de investigacin con HAL han
demostrado la viabilidad de SDN control en redes de acceso como Gigabit
Ethernet pasiva ptica redes (GEPON) [160] y redes de cable (DOCSIS)
[161]. Un esfuerzo similar a HAL es PAD [159], una propuesta que va un
poco ms all al trabajar tambin como un API hacia el sur por s mismo.
Ms importante an, PAD permite una programacin ms genrica de los
dispositivos de reenvo permitiendo el control del comportamiento de la ruta
de datos utilizando operaciones de byte genricas, definiendo encabezados
de protocolo y proporcionando definiciones de funciones.
C. Capa III: Hipervisores de red La virtualizacin ya es una tecnologa
consolidada en las computadoras modernas. Los rpidos avances de la
ltima dcada han hecho que la virtualizacin de las plataformas de
computacin sea corriente. Basndose en informes recientes, el nmero de
servidores virtuales ya ha superado el nmero de servidores fsicos [162],
[112]. Los hipervisores permiten a las distintas mquinas virtuales compartir
los mismos recursos de hardware. En una infraestructura de nube-asa-
service (IaaS), cada usuario puede tener sus propios recursos virtuales,
desde la computacin hasta el almacenamiento. Esto permiti nuevos
ingresos y modelos de negocio donde los usuarios asignan recursos a
demanda, a partir de una infraestructura fsica compartida, a un costo
relativamente bajo. Al mismo tiempo, los proveedores hacen un mejor uso
de la capacidad de sus infraestructuras fsicas instaladas, creando nuevas
fuentes de ingresos sin aumentar significativamente sus gastos de capital y
gastos operativos (OPEX). Una de las caractersticas interesantes de las
tecnologas de virtualizacin en la actualidad es el hecho de que las
mquinas virtuales pueden migrarse fcilmente de un servidor fsico a otro
y pueden crearse y / o destruirse a peticin, permitiendo el suministro de
servicios elsticos con una gestin flexible y fcil. Desafortunadamente, la
virtualizacin slo se ha realizado parcialmente en la prctica. A pesar de
los grandes avances en la virtualizacin de los elementos de computacin y
almacenamiento, la red todava est configurada principalmente
estticamente en una caja por caja [33]. Los principales requisitos de red
pueden capturarse a lo largo de dos dimensiones: topologa de red y
espacio de direcciones. Las diferentes cargas de trabajo requieren
diferentes topologas y servicios de red, como servicios planos L2 o L3 o
incluso servicios L4-L7 ms complejos para funciones avanzadas.
Actualmente, es muy difcil para una sola topologa fsica soportar las
diversas demandas de aplicaciones y servicios. Del mismo modo, el espacio
de direcciones es difcil de cambiar en las redes actuales. Hoy en da, las
cargas de trabajo virtualizadas tienen que operar en la misma direccin de
la infraestructura fsica. Por lo tanto, es difcil mantener la configuracin de
red original para un inquilino, las mquinas virtuales no pueden migrar a
ubicaciones arbitrarias y el esquema de direccionamiento es fijo y difcil de
cambiar. Por ejemplo, IPv6 no puede ser utilizado por las mquinas virtuales
(VM) de un inquilino si los dispositivos de reenvo fsicos subyacentes
admiten slo IPv4. Para proporcionar una virtualizacin completa, la red
debe proporcionar propiedades similares a la capa de clculo [33]. La
infraestructura de red debe ser capaz de soportar topologas de redes
arbitrarias y esquemas de direccionamiento. Cada inquilino debe tener la
capacidad de configurar los nodos informticos y la red simultneamente.
La migracin de host debe activar automticamente la migracin de los
puertos de red virtuales correspondientes. Uno podra pensar que las
primitivas de virtualizacin de larga data como VLAN (dominio L2
virtualizado), NAT (espacio de direcciones IP virtualizado) y MPLS (ruta
virtualizada) son suficientes para proporcionar una virtualizacin completa y
automatizada de la red. Sin embargo, estas tecnologas se anclan en una
configuracin de base caja por caja, es decir, no hay una nica abstraccin
unificadora que puede ser apalancada para configurar (o reconfigurar) la red
de una manera global. Como consecuencia, el aprovisionamiento de la red
actual puede tomar meses, mientras que la provisin de computacin tarda
slo unos minutos [112], [163] - [165]. Hay esperanza de que esta situacin
cambie con SDN y la disponibilidad de nuevas tcnicas de tunelizacin (por
ejemplo, VXLAN [35] y NVGRE [36]). Por ejemplo, soluciones tales como
FlowVisor [111], [166], [167], FlowN [168], NVP [112], OpenVirteX [169],
[170], IBM SDN VE [171], [172], RadioVisor [173], AutoVFlow [174],
eXtensible Datapath Daemon (xDPd) [175], [176], ptica de transporte de
red de virtualizacin [177], y la versin agnstico OpenFlow slicing
mecanismos [178], han sido recientemente propuesto, evaluado y
Desplegado en escenarios reales para el aprovisionamiento bajo demanda
de redes virtuales.
1) Cortar la red: FlowVisor es una de las primeras tecnologas para
virtualizar un SDN. Su idea bsica es permitir que mltiples redes lgicas
compartan la misma infraestructura de red OpenFlow. Para ello, proporciona
una capa de abstraccin que facilita la divisin de un plano de datos basado
en conmutadores habilitados OpenFlow, permitiendo la coexistencia de
redes mltiples y diversas. Se consideran cinco dimensiones de corte en
FlowVisor: ancho de banda, topologa, trfico, CPU del dispositivo y tablas de
reenvo. Adems, cada rebanada de red soporta un controlador, es decir,
mltiples controladores pueden coexistir en la parte superior de la misma
infraestructura de red fsica. A cada controlador se le permite actuar slo en
su propia rebanada de red. En trminos generales, una rebanada se define
como un conjunto particular de flujos en el plano de datos. Desde una
perspectiva de diseo de sistemas, FlowVisor es un proxy transparente que
intercepta mensajes OpenFlow entre switches y controladores. Particiona las
tablas de ancho de banda y flujo de enlace de cada switch. Cada segmento
recibe una velocidad de datos mnima y cada controlador invitado obtiene
su propia tabla de flujo virtual en los conmutadores. De forma similar a
FlowVisor, OpenVirteX [169], [170] acta como un proxy entre el NOS y los
dispositivos de reenvo. Sin embargo, su principal objetivo es proporcionar
SDN virtuales a travs de
Topologa, direccin y virtualizacin de funciones de control. Todas estas
propiedades son necesarias en entornos multitenant donde las redes
virtuales necesitan ser gestionadas y migradas de acuerdo con los recursos
virtuales de computacin y almacenamiento. Las topologas de redes
virtuales tienen que ser asignadas a los dispositivos de reenvo
subyacentes, con direcciones virtuales que permiten a los inquilinos
administrar completamente su espacio de direcciones sin depender de los
elementos de red subyacentes que abordan los esquemas. AutoSlice [179]
es otra propuesta de virtualizacin basada en SDN. Diferentemente de
FlowVisor, se centra en la automatizacin de la implementacin y operacin
de topologas virtuales SDN (vSDN) con mediacin mnima o arbitraje por
parte del operador de la red de sustratos. Adems, AutoSlice se dirige
tambin a los aspectos de escalabilidad de los hipervisores de red al
optimizar la utilizacin de los recursos y al mitigar las limitaciones de la
tabla de flujo mediante un control preciso de las estadsticas de trfico de
flujo. Al igual que AutoSlice, AutoVFlow [174] tambin habilita la
virtualizacin de red multidomain. Sin embargo, en lugar de tener un solo
tercero para controlar la asignacin de topologas vSDN, como es el caso de
AutoSlice, AutoVFlow utiliza una arquitectura multiproxy que permite a los
propietarios de redes implementar la virtualizacin de espacio de flujo de
manera autnoma intercambiando informacin entre los diferentes
dominios. FlowN [168], [180] se basa en un concepto ligeramente diferente.
Mientras que FlowVisor puede compararse con una tecnologa de
virtualizacin completa, FlowN es anlogo a una virtualizacin basada en
contenedores, es decir, un enfoque de virtualizacin ligero. FlowN tambin
fue concebido principalmente para abordar multitenancy en el contexto de
las plataformas de nube. Est diseado para ser escalable y permite utilizar
una plataforma de controlador compartido nica para administrar varios
dominios en un entorno de nube. Cada inquilino tiene un control total sobre
sus redes virtuales y es libre de implementar cualquier abstraccin de red y
la aplicacin en la parte superior de la plataforma del controlador. El
hipervisor composicin SDN [181] fue diseado con un conjunto diferente de
objetivos. Su principal objetivo es permitir la ejecucin cooperativa
(secuencial o paralela) de aplicaciones desarrolladas con diferentes
lenguajes de programacin o concebidas para diversas plataformas de
control. Por lo tanto, ofrece interoperabilidad y portabilidad, adems de las
funciones tpicas de hipervisores de red.
2) Hipervisores comerciales de la Red Multitenant: Ninguno de los enfoques
antes mencionados est diseado para abordar todos los desafos de los
centros de datos de mltiples agentes. Por ejemplo, los inquilinos quieren
ser capaces de migrar sus soluciones empresariales a los proveedores de la
nube sin la necesidad de modificar la configuracin de red de su red
domstica. Las tecnologas de redes existentes y las estrategias de
migracin han fracasado en su mayora en satisfacer tanto los requisitos de
los inquilinos como de los proveedores de servicios.
Un entorno multitenant debe ser anclado en un hipervisor de red capaz de
abstraer los dispositivos de reenvo de subyacentes y la topologa de red
fsica de los inquilinos. Adems, cada inquilino debe tener acceso a
abstracciones de control y administrar sus propias redes virtuales de forma
independiente y aislada de otros inquilinos. Con la demanda del mercado
para la virtualizacin de la red y la reciente investigacin sobre SDN
mostrando promesa como una tecnologa habilitadora, diferentes
plataformas de virtualizacin comercial basadas en los conceptos de SDN
han comenzado a aparecer. VMWare ha propuesto una plataforma de
virtualizacin de red (NVP) [112] que proporciona las abstracciones
necesarias para permitir la creacin de redes virtuales independientes para
entornos multitenant de gran escala. NVP es una solucin completa de
virtualizacin de red que permite la creacin de redes virtuales, cada una
con un modelo de servicio independiente, topologas y arquitecturas de
direccionamiento en la misma red fsica. Con NVP, los inquilinos no
necesitan saber nada acerca de la topologa de red subyacente, la
configuracin u otros aspectos especficos de los dispositivos de reenvo. El
hipervisor de red de NVP traduce las configuraciones y requerimientos de
los inquilinos en conjuntos de instrucciones de bajo nivel para ser instalados
en los dispositivos de reenvo. Para ello, la plataforma utiliza un grupo de
controladores SDN para manipular las tablas de reenvo de los vSwitches
Open en el hipervisor del host. Por lo tanto, las decisiones de reenvo se
hacen exclusivamente en el borde de la red. Despus de que se toma la
decisin, el paquete es tunneled sobre la red fsica al hypervisor del
anfitrin receptor (la red fsica ve nada sino paquetes IP ordinarios). IBM
tambin ha propuesto recientemente SDN VE [171], [172], otra plataforma
comercial y de clase empresarial de virtualizacin de la red. SDN VE utiliza
OpenDaylight como uno de los bloques de construccin de los llamados
entornos definidos por software (SDE), una tendencia que se discute ms
detalladamente en la Seccin V. Esta solucin tambin ofrece un marco
completo de implementacin para la virtualizacin de redes. Al igual que
NVP, utiliza un enfoque de superposicin basado en host, logrando una
abstraccin de red avanzada que permite servicios de red a nivel de
aplicacin en entornos multitenant de gran escala. Curiosamente, SDN VE
1.0 es capaz de apoyar en una sola consolidacin hasta 16.000 redes
virtuales y 128.000 mquinas virtuales [171], [172]. Para resumir,
actualmente ya hay algunas propuestas de hipervisor de red aprovechando
los avances de SDN. Hay, sin embargo, todava varias cuestiones a tratar.
Estos incluyen, entre otros, la mejora de las tcnicas de cartografa virtual-
fsica [182], la definicin del nivel de detalle que debe exponerse en el nivel
lgico, y el apoyo a la virtualizacin anidadas [29]. Sin embargo,
anticipamos que este ecosistema se expandir en un futuro prximo, ya que
la virtualizacin de la red probablemente desempear un papel clave en
futuros entornos virtualizados, al igual que la expansin que hemos estado
presenciando en la computacin virtualizada.
D. Capa IV: Sistemas operativos de red / controladores Los sistemas
operativos tradicionales proporcionan abstracciones (por ejemplo, API de
programacin de alto nivel) para acceder a dispositivos de nivel inferior,
gestionar el acceso concurrente a los recursos subyacentes (por ejemplo,
unidad de disco duro, adaptador de red,
Memoria), y proporcionar mecanismos de proteccin de seguridad. Estas
funcionalidades y recursos son factores clave para aumentar la
productividad, facilitando la vida de los desarrolladores de sistemas y
aplicaciones. Su uso generalizado ha contribuido significativamente a la
evolucin de varios ecosistemas (por ejemplo, lenguajes de programacin) y
el desarrollo de una mirada de aplicaciones. Por el contrario, hasta el
momento las redes se han gestionado y configurado utilizando conjuntos de
instrucciones de nivel inferior, especficos del dispositivo y principalmente
NOS propietarios cerrados (por ejemplo, Cisco IOS y Juniper JunOS). Por otra
parte, la idea de que los sistemas operativos abstraen las caractersticas
especficas de los dispositivos y proporcionen, de manera transparente, las
funcionalidades comunes, est an mayormente ausente en las redes. Por
ejemplo, hoy los diseadores de protocolos de enrutamiento necesitan lidiar
con complicados algoritmos distribuidos al resolver problemas de red. Los
profesionales de la red han resuelto los mismos problemas una y otra vez.
SDN se compromete a facilitar la gestin de la red y aliviar la carga de
resolver problemas de redes mediante el control lgicamente centralizado
que ofrece una NOS [26].
Al igual que con los sistemas operativos tradicionales, el valor crucial de una
NOS es proporcionar abstracciones, servicios esenciales y API comunes a los
desarrolladores. La funcionalidad genrica como el estado de red y la
informacin de topologa de red, el descubrimiento de dispositivos y la
distribucin de configuracin de red se pueden proporcionar como servicios
del NOS. Con NOS, para definir polticas de red, un desarrollador ya no
necesita preocuparse por los detalles de bajo nivel de la distribucin de
datos entre los elementos de enrutamiento, por ejemplo. Estos sistemas
pueden crear un nuevo entorno capaz de fomentar la innovacin a un ritmo
ms rpido al reducir la complejidad inherente a la creacin de nuevos
protocolos de red y aplicaciones de red. Una NOS (o un controlador) es un
elemento crtico en una arquitectura SDN, ya que es la pieza clave de
soporte para la lgica de control (aplicaciones) para generar la
configuracin de red basada en las polticas definidas por el operador de
red. Similar a un sistema operativo tradicional, la plataforma de control
abstrae los detalles de nivel inferior de conexin e interaccin con los
dispositivos de reenvo (es decir, materializar las directivas de red).
1) Ejes de Arquitectura y Diseo: Existe un conjunto muy diverso de
controladores y plataformas de control con diferentes opciones de diseo y
arquitectura [7], [13], [183] - [186]. Los controladores existentes pueden
categorizarse basndose en muchos aspectos. Desde el punto de vista
arquitectnico, uno de los ms relevantes es si estn centralizados o
distribuidos. Este es uno de los principales ejes de diseo de las plataformas
de control de SDN, por lo que comenzamos por discutir este aspecto a
continuacin.
2) Centralizado Versus Distribuido: Un controlador centralizado es una
entidad nica que gestiona todos los dispositivos de reenvo de la red.
Naturalmente, representa un nico punto de fallo y puede tener limitaciones
de escala. Un solo controlador puede no ser suficiente para administrar una
red con un gran nmero de elementos de plano de datos. Los controladores
centralizados como NOX-MT [187], Maestro [188], Beacon [186] y Floodlight
[189] han sido diseados como sistemas altamente concurrentes, para
lograr el rendimiento requerido por las redes de clase empresarial y los
centros de datos. Estos controladores se basan en diseos multiproceso
para explorar el paralelismo de las arquitecturas multicore. Como ejemplo,
Beacon puede manejar ms de 12 millones de flujos por segundo usando
nodos de computacin de gran tamao de proveedores de nube como
Amazon [186]. Otros controladores centralizados como Trema [190], Ryu
NOS [191], Meridian [192] y ProgrammableFlow [133], [193] apuntan a
entornos especficos tales como centros de datos, infraestructuras en nube
y redes de grado portador. Adems, controladores como Rosemary [194]
ofrecen funcionalidad y garantas especficas, a saber seguridad y
aislamiento de aplicaciones. Mediante el uso de una arquitectura basada en
contenedores llamada micro-NOS, logra su objetivo principal de aislar las
aplicaciones e impedir la propagacin de fallas a lo largo de la pila SDN.
Contrariamente a un diseo centralizado, una NOS distribuida puede
ampliarse para satisfacer los requisitos potencialmente de cualquier
entorno, desde redes de pequea a gran escala. Un controlador distribuido
puede ser un clster centralizado de nodos o un conjunto fsicamente
distribuido de elementos. Mientras que la primera alternativa puede ofrecer
un alto rendimiento para centros de datos muy densos, estos ltimos
pueden ser ms resistentes a diferentes tipos de fallas lgicas y fsicas. Un
proveedor de nube que abarca mltiples centros de datos interconectados
por una red de rea extensa puede requerir un enfoque hbrido, con
clsteres de controladores dentro de cada centro de datos y nodos de
control distribuidos en los diferentes sitios [8]. Onix [7], HyperFlow [195], HP
VAN SDN [184], ONOS [117], DISCO [185], yanc [196], PANE [197], SMaRt-
Light [198] y Fleet [199] Ejemplos de controladores distribuidos. La mayora
de los controladores distribuidos ofrecen
Consistency semantics, lo que significa que las actualizaciones de datos en
distintos nodos eventualmente se actualizarn en todos los nodos del
controlador. Esto implica que hay un perodo de tiempo en el cual nodos
distintos pueden leer valores diferentes (valor antiguo o nuevo) para la
misma propiedad. Por otro lado, la consistencia fuerte garantiza que todos
los nodos del controlador leern el valor de la propiedad ms actualizada
despus de una operacin de escritura. A pesar de su impacto en el
rendimiento del sistema, la consistencia fuerte ofrece una interfaz ms
sencilla para los desarrolladores de aplicaciones. Hasta la fecha, slo Onix,
ONOS y SMaRtLight proporcionan este modelo de coherencia de datos. Otra
propiedad comn de los controladores distribuidos es la tolerancia a fallos.
Cuando un nodo falla, otro nodo vecino debe asumir las funciones y
dispositivos del nodo fallido.
Hasta el momento, a pesar de que algunos controladores toleran fallos de
bloqueo, no toleran fallos arbitrarios, lo que significa que cualquier nodo con
un comportamiento anormal no ser reemplazado por uno potencialmente
bien comportado. Un nico controlador puede ser suficiente para
administrar una red pequea, sin embargo, representa un nico punto de
fallo. Del mismo modo, los controladores independientes se pueden
distribuir a travs de la red, cada uno de ellos la gestin de un segmento de
red, reduciendo el impacto de un fallo nico controlador. Sin embargo, si la
disponibilidad de control es importante, se pueden usar controladores de
control para obtener un mayor grado de disponibilidad y / o para soportar
ms dispositivos. En ltima instancia, un controlador distribuido puede
mejorar la resiliencia del plano de control y la escalabilidad y reducir el
impacto de los problemas causados por la particin de red, por ejemplo. La
resiliencia de SDN como un todo es un desafo abierto que ser discutido
ms a fondo en la Seccin V-C.
3) Diseccin de las plataformas de controlador SDN: Para proporcionar una
mejor descripcin arquitectnica y comprender el diseo de una NOS, la
Tabla 5 resume algunas de las propiedades arquitectnicas y de diseo ms
relevantes de los controladores SDN y las plataformas de control. Nos
hemos centrado en los elementos, servicios e interfaces de una seleccin de
controladores y plataformas de control a nivel de produccin y bien
documentados. Cada lnea de la tabla representa un componente que
consideramos importante en una plataforma de control modular y escalable.
Se observa un entorno muy diversificado, con diferentes propiedades y
componentes que son utilizados por distintas plataformas de control. Esto
no es sorprendente, dado un entorno con muchos competidores dispuestos
a estar a la vanguardia del desarrollo SDN. Tenga en cuenta tambin que no
todos los componentes estn disponibles en todas las plataformas. Por
ejemplo, las API de este / oeste no son necesarias en controladores
centralizados como Beacon. De hecho, algunas plataformas tienen nichos de
mercado muy especficos, tales como compaas de telecomunicaciones y
proveedores de nube, por lo que los requisitos sern diferentes. Basado en
el anlisis de los diferentes controladores SDN propuestos hasta la fecha
(tanto los presentados en la Tabla 5 como otros, como NOX [26], Meridian
[192], ForCES [30] y FortNOX [201]), Y proporcionar un primer intento de
disecar de forma clara y sistemtica una plataforma de control SDN en la
Fig. 8. Existen al menos tres capas relativamente bien definidas en la
mayora de las plataformas de control existentes: 1) la aplicacin, la
orquestacin y los servicios; 2) las funciones del controlador del ncleo; Y 3)
los elementos para las comunicaciones en direccin sur. La conexin en las
capas de nivel superior se basa en las interfaces hacia el norte como las API
REST [202] y los lenguajes de programacin como FML [203], Frenetic [204]
y NetCore [205]. En la parte de nivel inferior de una plataforma de control,
las API y los complementos de protocolo orientados hacia el sur interactan
con los elementos de reenvo. El ncleo de una plataforma de controlador
puede caracterizarse como una combinacin de sus funciones de servicio de
red de base y las diversas interfaces.
4) Funciones bsicas del controlador: Las funciones bsicas del servicio de
red son lo que consideramos la funcionalidad esencial que todos los
controladores deben proporcionar. Como una analoga, estas funciones son
como servicios bsicos de sistemas operativos, tales como ejecucin de
programas, control de operaciones de entrada / salida (E / S),
comunicaciones, proteccin, etc. Estos servicios son utilizados por otros
servicios de nivel del sistema operativo y aplicaciones de usuario. De forma
similar, funciones como la topologa, las estadsticas, las notificaciones y la
gestin de dispositivos, junto con el encaminamiento de ruta ms corto y los
mecanismos de seguridad, son funciones de control de red esenciales que
las aplicaciones de red pueden utilizar para construir su lgica. Por ejemplo,
el administrador de notificaciones debe ser capaz de recibir, procesar y
reenviar eventos (por ejemplo, notificaciones de alarma, alarmas de
seguridad, cambios de estado) [55]. Los mecanismos de seguridad son otro
ejemplo, ya que son componentes crticos para proporcionar aislamiento
bsico y aplicacin de seguridad entre servicios y aplicaciones. Por ejemplo,
las reglas generadas por servicios de alta prioridad no deben sobrescribirse
con las reglas creadas por las aplicaciones con una prioridad inferior.
5) Sur: En el nivel inferior de las plataformas de control, las API orientadas
hacia el sur pueden verse como una capa de controladores de dispositivos.
Proporcionan una interfaz comn para las capas superiores, mientras que
permiten a una plataforma de control utilizar diferentes APIs en el sur (por
ejemplo, OpenFlow, OVSDB y ForCES) y plug-ins de protocolo para
administrar dispositivos fsicos o virtuales existentes o nuevos (por ejemplo,
SNMP, BGP , Y NetConf). Esto es esencial tanto para la compatibilidad hacia
atrs como para la heterogeneidad, es decir, para permitir mltiples
protocolos y conectores de administracin de dispositivos. Por lo tanto, en el
plano de datos, una mezcla de dispositivos fsicos, dispositivos virtuales (por
ejemplo, Open vSwitch [109], [142], vRouter [206]) y una variedad de
dispositivos
Interfaces (por ejemplo, OpenFlow, OVSDB, de-config [207], NetConf y
SNMP) pueden coexistir. La mayora de los controladores admiten slo
OpenFlow como una API hacia el sur.
Sin embargo, algunos de ellos, como OpenDaylight, Onix y HP VAN SDN
Controller, ofrecen una gama ms amplia de APIs y / o protocolos en el sur.
Onix admite los protocolos OpenFlow y OVSDB. El controlador HP VAN SDN
tiene otros conectores en el sur, como los agentes L2 y L3. OpenDaylight va
un paso ms all al proporcionar una abstraccin de capa de servicio (SLA)
que permite que varias API y protocolos en direccin sur coexistan en la
plataforma de control. Por ejemplo, su arquitectura original fue diseada
para soportar al menos siete protocolos y plug-ins diferentes: OpenFlow,
OVSDB [153], NETCONF [44], PCEP [43], SNMP [208], BGP [42] y LISP Flow
Mapeo [13]. Por lo tanto, OpenDaylight es una de las pocas plataformas de
control concebidas para soportar una integracin ms amplia de tecnologas
en una sola plataforma de control.
6) hacia el este y hacia el oeste: API hacia el este / oeste, como se ilustra en
la Fig. 9, son un caso especial de interfaces requeridas por los controladores
distribuidos. Actualmente, cada controlador implementa su propia API de
este / oeste. Las funciones de estas interfaces incluyen datos de
importacin / exportacin entre controladores, algoritmos para modelos de
consistencia de datos y capacidades de supervisin / notificacin (por
ejemplo, compruebe si un controlador est activo o notifica una toma de
control en un conjunto de dispositivos de reenvo). De manera similar a las
interfaces hacia el sur y hacia el norte, las APIs de este / oeste son
componentes esenciales de los controladores distribuidos. Para identificar y
proporcionar la compatibilidad comn y la interoperabilidad entre los
diferentes controladores, es necesario contar con interfaces estndar este-
oeste. Por ejemplo, SDNi [209] define requisitos comunes para coordinar el
flujo de configuracin e intercambiar informacin sobre la accesibilidad a
travs de mltiples dominios.
En esencia, tales protocolos se pueden utilizar de una manera orquestada e
interoperable para crear plataformas de control distribuidas escalables y
confiables. La interoperabilidad puede ser aprovechada para aumentar la
diversidad del elemento de la plataforma de control. De hecho, la diversidad
Aumenta la robustez del sistema reduciendo la probabilidad de fallos
comunes, tales como fallos de software [210]. Otras propuestas que tratan
de definir interfaces entre controladores incluyen funciones de importacin /
exportacin de datos Onix [7], interfaz ForCES CE-CE [30], [211], ForCES
Intra-NE coldstandby mecanismos de alta disponibilidad [212] y almacenes
de datos distribuidos [213]. Una API de este / oeste requiere mecanismos
avanzados de distribucin de datos, tales como el protocolo de cola de
mensajes avanzado (AMQP) utilizado por DISCO [185], tcnicas para la
composicin de polticas concurrentes y consistentes distribuidas [215],
bases de datos transaccionales y DHTs [216] (asusedinOnix [7]).
Consistencia y tolerancia a fallos [198], [213]. En una configuracin
multidominio, east / westbound APIs pueden requerir tambin protocolos de
comunicacin ms especficos entre SDN controladores de dominio [217].
Algunas de las funciones esenciales de tales protocolos son coordinar la
configuracin de flujo originada por aplicaciones, intercambiar informacin
de accesibilidad para facilitar el enrutamiento inter-SDN, actualizar la
accesibilidad para mantener el estado de la red consistente, entre otros.
Otra cuestin importante con respecto a las interfaces este / oeste es la
heterogeneidad. Por ejemplo, adems de comunicarse con controladores
SDN iguales, los controladores tambin pueden necesitar comunicarse con
controladores subordinados (en una jerarqua de controladores) y
controladores no SDN [218], como es el caso del flujo cerrado [219]. Para
ser interoperables, las interfaces de este / oeste deben adaptarse a
diferentes interfaces de controladores, con su conjunto especfico de
servicios y las diversas caractersticas de la infraestructura subyacente,
incluida la diversidad de tecnologa, el alcance geogrfico y la escala de la
red y la distincin Entre WAN y LANVpotencialmente a travs de los lmites
administrativos. En esos casos, debe intercambiarse informacin diferente
entre los controladores, incluida la adyacencia y el descubrimiento de
capacidad, la informacin de topologa (en la medida de los contratos
acordados entre los dominios administrativos), la informacin de
facturacin, entre muchos otros [218]. Por ltimo, una "metodologa de la
brjula SDN" [220] sugiere una distincin ms fina entre las interfaces
horizontales en direccin este y oeste, haciendo referencia a las interfaces
hacia el oeste como protocolos SDN a SDN y API controladoras, mientras
que las interfaces eastbound se utilizaran para referirse a protocolos
estndar utilizados Para comunicarse con los planos de control de red
heredados (por ejemplo, PCEP [43] y GMPLS [221]).
7) hacia el norte: Los controladores actuales ofrecen una variedad bastante
amplia de APIs en direccin norte, como APIs ad hoc, APIs RESTful [202],
interfaces de programacin multinivel, sistemas de archivos, entre otras
APIs ms especializadas como NVP NBAPI [7] Y SDMN API [222]. La Seccin
IV-E est dedicada a una discusin ms detallada sobre la capa en evolucin
de las API en direccin norte. Un segundo tipo de interfaces hacia el norte
son los que se derivan de lenguajes de programacin de SDN como Frenetic
[204], Nettle [223], NetCore [205], Procera [224], Pyretic [225], NetKAT
[226] Basado en idiomas [227]. La Seccin IV-G ofrece una visin ms
detallada de los varios lenguajes de programacin existentes para SDN.
8) Comparacin de comentarios y plataformas: La Tabla 6 muestra un
resumen de algunos de los controladores existentes con sus respectivas
arquitecturas y caracteres
Ticas. Como puede observarse, la mayora de los controladores estn
centralizados y multiproceso. Curiosamente, la API hacia el norte es muy
diversa. En particular, cinco controladores (Onix, Floodlight, MuL, Meridian y
SDN Unified Controller) prestan un poco ms de atencin a esta interfaz,
como una declaracin de su importancia. Los modelos de consistencia y
tolerancia a fallos slo estn presentes en Onix, HyperFlow, HP VAN SDN,
ONOS y SMaRtLight. Por ltimo, cuando se trata del estndar OpenFlow
como API hacia el sur, slo Ryu admite sus tres versiones principales (v1.0,
v1.2 y v1.3). Para concluir, es importante destacar que la plataforma de
control es uno de los puntos crticos para el xito de SDN [234]. Uno de los
principales problemas que debe abordarse a este respecto es la
interoperabilidad. Esto es bastante interesante, ya que fue el primer
problema que las API en direccin sur (como OpenFlow) intentaron resolver.
Por ejemplo, mientras que las redes WiFi y de larga evolucin (LTE) [235]
necesitan plataformas de control especializadas como MobileFlow [222] o
SoftRAN [236], las redes de centros de datos tienen diferentes requisitos
que se pueden cumplir con plataformas como Onix [7]. ] O OpenDaylight
[13]. Por esta razn, en ambientes donde la diversidad de redes
Infraestructuras es una realidad, la coordinacin y cooperacin entre los
diferentes controladores es crucial. Por lo tanto, las API estandarizadas para
despliegues multicontroller y multidominio se consideran un paso
importante para lograr este objetivo.
E. Layer V: Northbound Interfaces Las interfaces northbound y southbound
son dos abstracciones clave del ecosistema SDN. La interfaz southbound ya
tiene una propuesta ampliamente aceptada (OpenFlow), pero una interfaz
comn hacia el norte sigue siendo un problema abierto. En este momento
todava puede ser un poco demasiado pronto para definir una interfaz
estndar hacia el norte, ya que los casos de uso todava estn siendo
elaborados [237]. De todos modos, es de esperar un comn (oradefacto)
northboundinterfacetoariseasSDNevolves. Una abstraccin que permita que
las aplicaciones de red no dependan de implementaciones especficas es
importante para explorar todo el potencial de SDN. La interfaz hacia el norte
es principalmente un ecosistema de software, no un hardware, como es el
caso de las APIs hacia el sur. En estos ecosistemas, la implementacin es
comnmente el motor de vanguardia, mientras que los estndares emergen
ms tarde y son esencialmente impulsados por una amplia adopcin [238].
Sin embargo, un estndar inicial y mnimo para las interfaces hacia el norte
puede todava desempear un papel importante para el futuro de la DSN.
Las discusiones sobre esta cuestin ya han comenzado [237] - [244], y un
consenso comn es que las API en direccin norte son realmente
importantes pero que es demasiado pronto para definir una nica Estndar
ahora mismo. La experiencia del desarrollo de diferentes controladores ser
sin duda la base para llegar a una interfaz de nivel de aplicacin comn. Las
interfaces abiertas y estndar hacia el norte son cruciales para promover la
portabilidad de las aplicaciones y la interoperabilidad entre las diferentes
plataformas de control. Una API en direccin norte se puede comparar con el
estndar POSIX [245] en sistemas operativos, representando una
abstraccin que garantiza el lenguaje de programacin y la independencia
del controlador. NOSIX [246] es uno de los primeros ejemplos de un esfuerzo
en esta direccin. Intenta definir interfaces de aplicaciones porttiles de
bajo nivel (por ejemplo, modelo de flujo), haciendo que APIs orientadas
hacia el sur como OpenFlow parezcan '' controladores de dispositivos ''. Sin
embargo, NOSIX no es exactamente una interfaz de propsito general hacia
el norte sino una abstraccin de nivel superior Para interfaces hacia el sur.
De hecho, podra ser parte de la capa de abstraccin comn en una
plataforma de control como la descrita en la Seccin IV-D. Los controladores
existentes, como Floodlight, Trema, NOX, Onix y OpenDaylight, proponen y
definen sus propias API en direccin norte [239], [247]. Sin embargo, cada
uno de ellos tiene sus propias definiciones especficas. Los lenguajes de
programacin como Frenetic [204], Nettle [223], NetCore [205], Procera
[224], Pyretic [248] y NetKAT [226] tambin resumen los detalles internos
de las funciones del controlador y el comportamiento del plano de datos de
la aplicacin Desarrolladores.
Adems, como explicamos en la Seccin IV-G, los lenguajes de
programacin pueden proporcionar una amplia gama de poderosas
abstracciones y mecanismos tales como composicin de aplicaciones, datos
transparentes
La tolerancia a fallos en el plano y una variedad de bloques de construccin
bsicos para facilitar el desarrollo de mdulos y aplicaciones de software.
SFNet [249] es otro ejemplo de una interfaz hacia el norte. Se trata de una
API de alto nivel que convierte los requisitos de las aplicaciones en
solicitudes de servicio de nivel inferior. Sin embargo, SFNet tiene un alcance
limitado, dirigindose a consultas para solicitar el estado de congestin de
la red y servicios como la reserva de ancho de banda y la multidifusin.
Otras propuestas utilizan diferentes enfoques para permitir que las
aplicaciones interacten con los controladores. La plataforma de control
yanc [196] explora esta idea proponiendo una plataforma de control general
basada en Linux y abstracciones como el sistema de archivos virtual (VFS).
Este enfoque simplifica el desarrollo de aplicaciones SDN, ya que los
programadores pueden utilizar un concepto tradicional (archivos) para
comunicarse con dispositivos y subsistemas de nivel inferior.
Eventualmente, es poco probable que una nica interfaz en direccin norte
resulte como la ganadora, ya que los requisitos para las diferentes
aplicaciones de red son muy diferentes. Es probable que las API de las
aplicaciones de seguridad sean diferentes de las de las aplicaciones de
enrutamiento o financieras. Un posible camino de evolucin para las API
hacia el norte son propuestas orientadas verticalmente, antes de que ocurra
cualquier tipo de estandarizacin, un reto que la ONF ha comenzado a
emprender en el GT NBI en paralelo con los desarrollos SDN de fuente
abierta. El trabajo de arquitectura de la ONF [218] incluye la posibilidad de
que las API del norte proporcionen recursos para permitir el control dinmico
y granular de los recursos de la red de las aplicaciones de los clientes,
eventualmente a travs de diferentes fronteras empresariales y
organizacionales. Tambin hay otros tipos de API, como los proporcionados
por el controlador PANE [197]. Diseado para ser adecuado para el concepto
de redes participativas, PANE permite a los administradores de red definir
cuotas especficas de mdulos y polticas de control de acceso en recursos
de red. El controlador proporciona una API que permite que las aplicaciones
de host final soliciten de forma dinmica y autnoma recursos de red. Por
ejemplo, las aplicaciones de audio (por ejemplo, VoIP) y vdeo se pueden
modificar fcilmente para utilizar la API PANE para reservar el ancho de
banda para ciertas garantas de calidad durante la sesin de comunicacin.
PANE incluye un compilador y un motor de verificacin para asegurar que
las solicitudes de ancho de banda no excedan los lmites establecidos por el
administrador y evitar la inanicin, es decir, otras aplicaciones no se vern
afectadas por nuevas solicitudes de recursos.
F. Capa VI: Virtualizacin Basada en Lenguaje Dos caractersticas esenciales
de las soluciones de virtualizacin son la capacidad de expresar la
modularidad y de permitir diferentes niveles de abstraccin, al tiempo que
garantiza las propiedades deseadas como la proteccin. Por ejemplo, las
tcnicas de virtualizacin pueden permitir diferentes vistas de una nica
infraestructura fsica. Por ejemplo, un "switch grande" virtual podra
representar una combinacin de varios dispositivos de reenvo subyacentes.
Esto simplifica intrnsecamente la tarea de los desarrolladores de
aplicaciones, ya que no necesitan pensar en la secuencia de los
conmutadores en los que deben instalarse las reglas de reenvo, sino ms
bien ver la red como un simple "gran conmutador". Desarrollo y despliegue
de aplicaciones de red complejas, como servicios avanzados relacionados
con la seguridad.
Pyretic [248] es un ejemplo interesante de un lenguaje de programacin que
ofrece este tipo de abstraccin de alto nivel de la topologa de red.
Incorpora este concepto de abstraccin introduciendo objetos de red. Estos
objetos consisten en una topologa de red abstracta y los conjuntos de
polticas que se le aplican. Los objetos de red simultneamente ocultan
informacin y ofrecen los servicios necesarios. Otra forma de virtualizacin
basada en lenguaje es el corte esttico. Este es un esquema en el que la red
es cortada por un compilador, basado en las definiciones de la capa de
aplicacin. La salida del compilador es un programa de control monoltico
que ya tiene definiciones de corte y comandos de configuracin para la red.
En tal caso, no es necesario que un hipervisor administre dinmicamente las
rebanadas de la red. El rebanado esttico puede ser valioso para
despliegues con requisitos especficos, en particular aquellos en los que es
preferible un mayor rendimiento y unas sencillas garantas de aislamiento
frente al corte dinmico. Un ejemplo de enfoque de corte esttico es el
aislamiento Esplndido [250]. En esta solucin, las rebanadas de red estn
formadas por tres componentes: 1) topologa, que consiste en
conmutadores, puertos y enlaces; 2) asignacin de conmutadores, puertos y
enlaces de nivel de segmento en la infraestructura de red; Y 3) predicados
en paquetes, donde cada puerto de los interruptores de borde de la
rebanada tiene un predicado asociado. La topologa es un grfico simple de
los nodos, puertos y enlaces cortados. La asignacin traducir los elementos
abstractos de la topologa en los correspondientes fsicos. Los predicados se
utilizan para indicar si se permite a un paquete introducir un segmento
especfico. Se pueden asociar diferentes aplicaciones a cada segmento. El
compilador toma la combinacin de sectores (topologa, asignacin y
predicados) y los programas respectivos para generar una configuracin
global para toda la red. Tambin
Asegura que las propiedades tales como el aislamiento se impongan entre
las rebanadas, es decir, ningn paquete de rebanada A puede atravesar a la
rebanada B a menos que se permita explcitamente. Otras soluciones, como
libNetVirt [251], intentan integrar tecnologas heterogneas para crear
rebanadas de red esttica. LibNetVirt es una biblioteca diseada para
proporcionar una forma flexible de crear y administrar redes virtuales en
diferentes entornos informticos. Su idea principal es similar al proyecto
OpenStack Quantum [252]. Mientras que Quantum est diseado para
OpenStack (ambientes de nube), libNetVirt es una biblioteca de propsito
ms general que se puede utilizar en diferentes entornos. Adems, va un
paso ms all de OpenStack Quantum al habilitar capacidades QoS en redes
virtuales [251]. La biblioteca libNetVirt tiene dos capas: una interfaz de red
genrica y controladores de dispositivo especficos de tecnologa (por
ejemplo, VPN, MPLS, OpenFlow). En la parte superior de las capas estn las
aplicaciones de red y las descripciones de redes virtuales. El controlador
OpenFlow utiliza un controlador NOX para administrar la infraestructura
subyacente, utilizando tablas de flujo basadas en reglas OpenFlow para
crear redes virtuales aisladas. Al soportar diferentes tecnologas, puede
utilizarse como un componente de puente en redes heterogneas. La Tabla
7 resume las tecnologas de virtualizacin hipervisora y no hipervisorbida.
Como se puede observar, slo libNetVirt soporta tecnologas heterogneas,
no restringiendo su aplicacin a redes habilitadas para OpenFlow. FlowVisor,
AutoSlice y OpenVirteX permiten mltiples controladores,
onepernetworkslice.FlowNprovidesacontainerbased enfoque donde mltiples
aplicaciones de diferentes usuarios pueden coexistir en un solo controlador.
FlowVisor permite garantas de aprovisionamiento de QoS utilizando bits
PCP de VLAN para colas de prioridad. SDN VE y NVP tambin proporcionan
sus propios mtodos de aprovisionamiento para garantizar la QoS.
G. Capa VII: Lenguajes de programacin Los lenguajes de programacin
proliferan desde hace dcadas.
Tanto la academia como la industria han evolucionado desde lenguajes de
mquina especficos de hardware de bajo nivel, como ensamblaje para
arquitecturas x86, hasta lenguajes de programacin de alto nivel y
poderosos como Java y Python. Los avances hacia un cdigo ms porttil y
reutilizable han impulsado un cambio significativo en la industria informtica
[254], [255]. Del mismo modo, la programacin en las redes est
comenzando a moverse de lenguajes de mquina de bajo nivel como
OpenFlow ('' montaje '') a lenguajes de programacin de alto nivel [112],
[203] - [205], [223] - [225] . Los lenguajes de mquina de ensamblaje, como
OpenFlow [9] y POF [31], [120], esencialmente imitan el comportamiento de
los dispositivos de reenvo, forzando a los desarrolladores a pasar
demasiado tiempo en detalles de bajo nivel en lugar de resolver el
problema. Los programas Raw OpenFlow tienen que ocuparse de los detalles
del comportamiento del hardware, tales como las reglas que se superponen,
el orden de prioridad de las reglas y las inconsistencias en los planos de
datos que surgen de los paquetes en vuelo cuyas reglas de flujo estn bajo
la instalacin [204, 205, 256]. El uso de estos lenguajes de bajo nivel
dificulta la reutilizacin del software, la creacin de cdigo modular y
extenso y conduce a un proceso de desarrollo ms propenso a errores [225],
[257], [258]. Las abstracciones proporcionadas por los lenguajes de
programacin de alto nivel pueden ayudar significativamente a resolver
muchos de los desafos de estos conjuntos de instruccin de nivel inferior
[203] - [205], [223] - [225]. En SDN, los lenguajes de programacin de alto
nivel pueden ser diseados y utilizados para: 1) crear abstracciones de nivel
superior para simplificar la tarea de programar dispositivos de reenvo; 2)
posibilitar entornos ms productivos y centrados en problemas para los
programadores de software de red, acelerando el desarrollo y la innovacin;
3) promover la modularizacin del software y la reutilizacin del cdigo en el
plano de control de la red; 4) fomentar el desarrollo de la virtualizacin de
red. Varios desafos pueden ser mejor abordados por lenguajes de
programacin en SDNs. Por ejemplo, en SDN puros basados en OpenFlow, es
difcil asegurar que mltiples tareas de una sola aplicacin (por ejemplo,
enrutamiento, supervisin, control de acceso) no interfieran entre s. Por
ejemplo, las reglas generadas para una tarea no deben anular la
funcionalidad de otra tarea [204], [256]. Otro ejemplo es cuando mltiples
aplicaciones se ejecutan en un nico controlador [201], [225], [256], [259],
[260]. Normalmente, cada aplicacin genera reglas basadas en sus propias
necesidades y polticas sin ms conocimientos sobre las reglas generadas
por otras aplicaciones. Como consecuencia, se pueden generar e instalar
reglas conflictivas en los dispositivos de reenvo, lo que puede crear
problemas para el funcionamiento de la red. Los lenguajes de programacin
y los sistemas de tiempo de ejecucin pueden ayudar a resolver estos
problemas que de otro modo seran difciles de prevenir. Importantes
tcnicas de diseo de software como la modularidad de cdigo y la
reutilizacin son muy difciles de lograr usando modelos de programacin de
bajo nivel [225]. Las aplicaciones as construidas son monolticas y
consisten en bloques de construccin que no pueden ser reutilizados en
otras aplicaciones. El resultado final es un proceso de desarrollo muy lento y
propenso a errores.
Otra caracterstica interesante que proporcionan las abstracciones de
lenguaje de programacin es la capacidad de crear y escribir programas
para topologas de redes virtuales [248], [250]. Este concepto es similar a la
programacin orientada a objetos, donde los objetos resumen datos y
funciones especficas para los desarrolladores de aplicaciones, facilitando el
enfoque en resolver un problema en particular sin preocuparse por las
estructuras de datos y su gestin. Por ejemplo, en un contexto SDN, en
lugar de generar e instalar reglas en cada dispositivo de reenvo, se puede
pensar en crear topologas de redes virtuales simplificadas que representen
toda la red o un subconjunto de ella. Por ejemplo, el desarrollador de
aplicaciones debera ser capaz de abstraer la red como un gran cambio
atmico, en lugar de una combinacin de varios dispositivos fsicos
subyacentes.
Los lenguajes de programacin o los sistemas de tiempo de ejecucin deben
ser responsables de generar e instalar las instrucciones de nivel inferior
requeridas en cada dispositivo de reenvo para aplicar la poltica de usuario
a travs de la red. Con este tipo de abstracciones, el desarrollo de una
aplicacin de enrutamiento se convierte en un proceso sencillo. Del mismo
modo, un solo interruptor fsico podra ser representado como un conjunto
de conmutadores virtuales, cada uno de ellos pertenecientes a una red
virtual diferente. Estos dos ejemplos de topologas de red abstractas seran
mucho ms difciles de implementar con conjuntos de instrucciones de bajo
nivel. En contraste, un lenguaje de programacin o sistema de ejecucin
puede proporcionar ms fcilmente abstracciones para topologas de redes
virtuales, como ya lo han demostrado lenguajes como Pyretic [248].
1) Lenguajes de programacin SDN de alto nivel: Los lenguajes de
programacin de alto nivel pueden ser herramientas poderosas como medio
para implementar y proporcionar abstracciones para diferentes propiedades
y funciones importantes de SDN tales como estructuras de red,
actualizaciones distribuidas, composicin modular, virtualizacin y
Verificacin formal [29]. Los conjuntos de instrucciones de bajo nivel sufren
varios problemas. Para abordar algunos de estos desafos, se han propuesto
lenguajes de programacin de nivel superior, con diversas metas, tales
como: Evitar configuraciones y dependencias de bajo nivel y especficas
de dispositivos distribuidas por la red, como sucede en los enfoques
tradicionales de configuracin de redes; Proporcionar abstracciones que
permitan realizar diferentes tareas de gestin a travs de una fcil
comprensin y mantenimiento de las polticas de red; desacoplamiento de
mltiples tareas (por ejemplo, enrutamiento, control de acceso, ingeniera
de trfico); la implementacin de interfaces de programacin de nivel
superior para evitar conjuntos de instrucciones de bajo nivel; resolver
problemas de reglas de reenvo, por ejemplo, reglas conflictivas o
incompletas que pueden impedir que un evento de conmutacin se active,
de una manera automatizada; abordar diferentes problemas de condicin
racial que son inherentes a los sistemas distribuidos; Mejorar las tcnicas de
resolucin de conflictos en entornos con tomadores de decisiones
distribuidos; Proporcionar capacidades nativas de tolerancia a fallos en la
configuracin de ruta de plano de datos; reducir la latencia en el
procesamiento de nuevos flujos; facilitar la creacin de aplicaciones con
estado (por ejemplo, firewall con estado). Los lenguajes de programacin
tambin pueden proporcionar abstracciones especializadas para hacer
frente a otros requisitos de gestin, tales como el monitoreo [204], [224],
[227], [261]. Por ejemplo, el sistema de tiempo de ejecucin de un lenguaje
de programacin puede hacer todo el trabajo de lavandera de instalar
reglas, de sondear los contadores, de recibir las respuestas, de combinar los
resultados segn sea necesario y de componer consultas de monitoreo junto
con otras polticas. En consecuencia, los desarrolladores de aplicaciones
pueden aprovechar la simplicidad y la potencia de las instrucciones de
consulta de nivel superior para implementar fcilmente mdulos o
aplicaciones de supervisin. Otro aspecto de suma importancia es la
portabilidad del lenguaje de programacin, necesaria para que los
desarrolladores no tengan que volver a implementar aplicaciones para
diferentes plataformas de control. La portabilidad de un lenguaje de
programacin puede considerarse como un valor aadido significativo para
el ecosistema del plano de control. Mecanismos como los back-ends
desacoplados podran ser ingredientes arquitectnicos clave para permitir la
portabilidad de la plataforma. De forma similar a la mquina virtual Java,
una interfaz port-
Permiten fcilmente que las aplicaciones se ejecuten en diferentes
controladores sin requerir ninguna modificacin.
Como ejemplo, el lenguaje de Pyretic requiere solamente una interfaz de
socket estndar y un cliente OpenFlow simple en la plataforma de
controlador de destino [225]. Varios lenguajes de programacin han sido
propuestos para SDNs, como se resume en la Tabla 8. La gran mayora
proponen abstracciones para redes habilitadas para OpenFlow. El paradigma
de programacin predominante es el declarativo, con una sola excepcin, el
piretico, que es un lenguaje imperativo. La mayora de los lenguajes
declarativos son funcionales, pero hay casos de los tipos lgicos y reactivos.
El propsito, los problemas especficos que pretenden resolver y el poder de
expresividad varan de un lenguaje a otro, mientras que el objetivo final es
casi siempre el mismo: proporcionar abstracciones de nivel superior para
facilitar el desarrollo de la lgica de control de red. Los lenguajes de
programacin como FML [203], Nettle [223] y Procera [224] son funcionales
y reactivos. Las polticas y aplicaciones escritas en estos idiomas se basan
en acciones reactivas activadas por eventos (por ejemplo, un nuevo host
conectado a la red o la carga de red actual). Dichos lenguajes permiten a los
usuarios expresar declarativamente diferentes reglas de configuracin de
red como listas de control de acceso (ACL), LANs virtuales (VLANs) y muchas
otras. Las reglas se expresan esencialmente como polticas de permitir o
negar, que se aplican a los elementos de reenvo para asegurar el
comportamiento deseado de la red.
Otros lenguajes de programacin SDN, como Frenetic [204], tablas de flujo
jerrquico (HFT) [256], NetCore [205], y Pyretic [225], fueron diseados con
el objetivo simultneo de expresar eficientemente las polticas de envo de
paquetes y tratar la superposicin Reglas de diferentes aplicaciones,
ofreciendo operadores avanzados para la composicin paralela y secuencial
de mdulos de software. Para evitar conflictos que se superponen, Frenetic
desambigua reglas con patrones superpuestos asignando diferentes
prioridades enteras, mientras que HFT utiliza polticas jerrquicas con
operadores mejorados de resolucin de conflictos. Las abstracciones de See-
every-pack y la semntica libre de raza tambin representan caractersticas
interesantes proporcionadas por lenguajes de programacin (como Frenetic
[204]). El primero asegura que todos los paquetes de control estarn
disponibles para anlisis, tarde o temprano, mientras que el ltimo
proporciona los mecanismos para suprimir paquetes sin importancia. Como
ejemplo, los paquetes que surgen de una condicin de carrera de red, tal
como debido a una instalacin de regla de flujo concurrente en
conmutadores, pueden ser descartados simplemente por el sistema de
ejecucin. Los operadores avanzados para la composicin en paralelo y
secuencial ayudan a enlazar (a travs de operadores de flujo de trabajo
internos) las caractersticas clave de lenguajes de programacin como
Pyretic [225]. La composicin en paralelo hace posible operar mltiples
polticas en el mismo conjunto de paquetes, mientras que la composicin
secuencial facilita la definicin de un flujo de trabajo secuencial de polticas
a procesar en un conjunto de paquetes. El procesamiento secuencial de
polticas permite que mltiples mdulos (por ejemplo, control de acceso y
encaminamiento) operen de una manera cooperativa. Mediante el uso de
composiciones secuenciales, las aplicaciones complejas pueden construirse
a partir de una combinacin de diferentes mdulos (de manera similar a
como las tuberas pueden usarse para crear sofisticadas aplicaciones Unix).
Otras caractersticas avanzadas son proporcionadas por otros lenguajes de
programacin SDN. FatTire [262] es un ejemplo de un lenguaje declarativo
que depende en gran medida de las expresiones regulares para permitir a
los programadores describir las rutas de red con requisitos de tolerancia a
fallos. Por ejemplo, cada flujo puede tener sus propios caminos alternativos
para tratar el fallo de las rutas primarias. Curiosamente, esta caracterstica
se proporciona de una manera muy programador-amigable, con el
programador de la aplicacin que slo tiene que utilizar expresiones
regulares con caracteres especiales, como un asterisco. En el caso particular
de FatTire, un asterisco producir el mismo comportamiento que una
expresin regular tradicional, pero se traducir en rutas de desplazamiento
alternativas. Los lenguajes de programacin, como FlowLog [257] y Flog
[258], traen diferentes caractersticas, como la comprobacin de modelos, la
verificacin dinmica y las middleboxes con estado.
Por ejemplo, utilizando un lenguaje de programacin como Flog, es posible
construir una aplicacin de firewall con estado con slo cinco lneas de
cdigo [258]. Merlin [264] es uno de los primeros ejemplos de marco
unificado para controlar diferentes componentes de red, tales como
dispositivos de reenvo, middleboxes y hosts finales. Una ventaja importante
es la compatibilidad
Sistemas existentes. Para lograr este objetivo, Merlin genera cdigo
especfico para cada tipo de componente. Tomando una definicin de
poltica como entrada, el compilador de Merlin determina rutas de reenvo,
colocacin de transformacin y asignacin de ancho de banda. Las salidas
compiladas son conjuntos de instrucciones especficas de bajo nivel de
componentes que se instalarn en los dispositivos. El lenguaje de polticas
de Merlin tambin permite a los operadores delegar el control de una subred
a los inquilinos, asegurando al mismo tiempo el aislamiento. Este control
delegado se expresa mediante polticas que pueden ser perfeccionadas por
cada propietario del inquilino, lo que les permite personalizar las polticas
para sus necesidades particulares. Otras iniciativas recientes (por ejemplo,
los lenguajes de programacin de sistemas [265]) apuntan a problemas
como la deteccin de anomalas para mejorar la seguridad de los protocolos
de red (por ejemplo, Open-Flow) y la optimizacin de la escalabilidad
horizontal para lograr un alto rendimiento en aplicaciones que funcionan
con arquitecturas multincleo. ]. Sin embargo, todava hay margen para
ms investigacin y desarrollo en lenguajes de programacin. Por ejemplo,
una investigacin reciente ha revelado que los compiladores de polticas
actuales generan actualizaciones de reglas innecesarias (redundantes), la
mayora de las cuales slo modifican el campo de prioridad [266]. La mayor
parte del valor de SDN provendr de las aplicaciones de gestin de redes
construidas sobre la infraestructura. Los avances en los lenguajes de
programacin de alto nivel son un componente fundamental para el xito de
un prolfico ecosistema de desarrollo de aplicaciones SDN. Con este fin, se
estn realizando esfuerzos para conformar prximas interfaces estndar
(vase [267]) y hacia la realizacin de entornos de desarrollo integrados
(por ejemplo, NetIDE [268]) con el objetivo de fomentar el desarrollo de una
gran variedad de aplicaciones SDN. Discutimos estos prximos.
H. Capa VIII: Aplicaciones de red Las aplicaciones de red pueden ser vistas
como los "cerebros de red". Implementan la lgica de control que se
traducir en comandos a instalar en el plano de datos, dictando el
comportamiento de los dispositivos de reenvo. Tome una aplicacin simple
como enrutamiento como un ejemplo. La lgica de esta aplicacin es definir
la ruta a travs de la cual los paquetes fluirn desde el punto A al punto B.
Para lograr este objetivo, una aplicacin de enrutamiento tiene que, sobre la
base de la entrada de topologa, decidir el camino a utilizar e instruir al
controlador a Instale las reglas de reenvo respectivas en todos los
dispositivos de reenvo en la ruta elegida, de A a B. Los SDN se pueden
implementar en cualquier entorno de red tradicional, desde redes
domsticas y empresariales hasta centros de datos y puntos de intercambio
de Internet. Esta variedad de entornos ha llevado a una amplia gama de
aplicaciones de red. Las aplicaciones de red existentes realizan
funcionalidades tradicionales como enrutamiento, equilibrio de carga y
aplicacin de polticas de seguridad, pero tambin exploran enfoques
novedosos, como reducir el consumo de energa. Otros ejemplos incluyen
fail-over y funcionalidades de confiabilidad para el plano de datos,
cumplimiento de QoS de extremo a extremo, virtualizacin de red,
administracin de movilidad en redes inalmbricas, entre muchos otros. Se
espera que la variedad de aplicaciones de red, combinada con despliegues
reales de casos de uso, sea una de las fuerzas principales para fomentar
una amplia adopcin de SDN [269]. A pesar de la gran variedad de casos de
uso, la mayora de las aplicaciones de SDN pueden agruparse en una de
cinco categoras: ingeniera de trfico, movilidad e inalmbrica, medicin y
monitoreo, seguridad y confiabilidad y redes de centros de datos. Las Tablas
9 y 10 resumen varias aplicaciones clasificadas como tales, indicando su
propsito principal, el controlador donde se implement / evalu y se us la
API hacia el sur.
1) Ingeniera de trfico: Se han propuesto varias aplicaciones de ingeniera
de trfico, incluyendo ElasticTree [274], Hedera [276], balanceo de carga
basado en OpenFlow [338], Plug-n-Serve [285] y Aster * x [273] QoS [289],
QoS para SDN [288], ALTO [270], ViAgregre SDN [293], ProCel [282], el filtro
de Bloom en paquete [277], SIM-PLE [292], QNOX [287] FlowQoS [275], y
Middlepipes [27].
Adems de stas, las propuestas recientes incluyen la optimizacin de la
colocacin de reglas [339], el uso de MAC como rtulo universal para el
enrutamiento eficiente en centros de datos [340], entre otras tcnicas de
gestin de flujo, tolerancia a fallos, actualizacin de topologa y
caracterizacin de trfico [341] .La mayora de las aplicaciones son el trfico
de ingenieros con el objetivo de minimizar el consumo de energa,
maximizar la utilizacin de la red agregada, proporcionar un equilibrio de
carga optimizado y otras tcnicas genricas de optimizacin del trfico. El
balanceo de carga fue una de las primeras aplicaciones previstas para SDN /
OpenFlow. Diferentes algoritmos y tcnicas se han propuesto para este fin
[338], [273], [285]. Una preocupacin particular es la escalabilidad de estas
soluciones. Una tcnica para permitir que este tipo de aplicaciones a escala
es el uso de reglas basadas en comodn para realizar balanceo de carga
proactivo [338]. Los comodines se pueden utilizar para agregar solicitudes
de cliente basadas en los rangos de prefijos IP, por ejemplo, permitiendo la
distribucin y direccin de grandes grupos de solicitudes de clientes sin
necesidad de intervencin del controlador para cada nuevo flujo. En
tndem, la operacin en modo reactivo todava se puede utilizar cuando se
detectan rfagas de trfico. La aplicacin de controlador necesita supervisar
el trfico de red y utilizar algn tipo de umbral en los contadores de flujo
para redistribuir clientes entre los servidores cuando es probable que se
produzcan cuellos de botella. SDN balanceo de carga tambin simplifica la
colocacin de los servicios de red en la red [285]. Cada vez que se instala
un nuevo servidor, el servicio de equilibrio de carga puede tomar las
acciones adecuadas para distribuir el trfico entre los servidores
disponibles, teniendo en cuenta tanto la carga de red como la capacidad de
computacin disponible de los respectivos servidores. Esto simplifica la
gestin de red y proporciona ms flexibilidad a los operadores de red. Las
interfaces existentes hacia el sur pueden utilizarse para supervisar
activamente la carga del plano de datos. Esta informacin puede ser
Apalancada para optimizar el consumo energtico de la red [274]. Mediante
el uso de algoritmos de optimizacin especializados y opciones de
configuracin diversificada, es posible cumplir con los objetivos de
infraestructura de latencia, rendimiento y tolerancia a fallos, por ejemplo,
mientras se reduce el consumo de energa. Con el uso de tcnicas simples,
como el cierre de enlaces y dispositivos inteligentemente en respuesta a la
dinmica de carga de trfico, los operadores de centros de datos pueden
ahorrar hasta un 50% de la energa de la red en condiciones normales de
trfico [274]. Uno de los objetivos importantes de las redes de centros de
datos es evitar o mitigar el efecto de los cuellos de botella en la red sobre el
funcionamiento de los servicios informticos ofrecidos. El ancho de banda
de biseccin lineal es una tcnica que puede adoptarse para los patrones de
trfico que hacen hincapi en la red explorando la diversidad de rutas en
una topologa de centros de datos. Tal tcnica se ha propuesto en un ajuste
SDN, lo que permite la maximizacin de la utilizacin de la red agregada con
una mnima sobrecarga de programacin [276]. SDN tambin se puede
utilizar para proporcionar un sistema totalmente automatizado para
controlar la configuracin de routers. Esto puede ser particularmente til en
los escenarios que aplican la agregacin virtual [342]. Esta tcnica permite
a los operadores de red reducir los datos replicados en las tablas de
enrutamiento, que es una de las causas del crecimiento de las tablas de
enrutamiento [343]. Una aplicacin de enrutamiento especializada [293]
puede calcular, dividir y configurar las tablas de enrutamiento de los
diferentes dispositivos de enrutamiento a travs de una API hacia el sur
como OpenFlow. La optimizacin del trfico es otra aplicacin interesante
para los proveedores de servicios a gran escala, donde se requiere una
escala dinmica. Por ejemplo, el aprovisionamiento dinmico y escalable de
VPNs en infraestructuras de nube, utilizando protocololos como ALTO [272],
puede simplificarse a travs de un enfoque basado en SDN [270]. Trabajos
recientes tambin han demostrado que la optimizacin de la colocacin de
reglas puede aumentar la eficiencia de la red [339]. Soluciones como ProCel
[282], diseadas para redes de ncleo celular, son capaces de reducir el
trfico de sealizacin hasta un 70%, lo que representa un logro
significativo. Otras aplicaciones que realizan el enrutamiento y la ingeniera
de trfico incluyen la creacin de redes de aplicacin para el streaming de
video y datos [344], [345] y QoS mejorada mediante el uso de mltiples
planificadores de paquetes [290] y otras tcnicas [279], [287], [289] , [346].
Como la ingeniera de trfico es una cuestin crucial en todo tipo de redes,
se pueden esperar mtodos, tcnicas e innovaciones en el contexto de las
SDNs.
2) Movilidad e Inalmbrico: El actual plano de control distribuido de las
redes inalmbricas es subptimo para gestionar el espectro limitado,
asignar recursos de radio, implementar mecanismos de transferencia,
gestionar interferencias y realizar un balanceo de carga eficiente entre
celdas. Los enfoques basados en SDN representan una oportunidad para
facilitar el despliegue y la gestin de diferentes tipos de redes inalmbricas,
como las WLAN y las redes celulares [236], [296], [300], [302], [347], [348].
Tradicionalmente duro-toimplement pero las caractersticas deseadas estn
sin duda convirtindose en una realidad con las redes inalmbricas basadas
en SDN. [347], [349], balanceo de carga [236], [300], creacin de puntos de
acceso virtuales (VAP) [297], [300] de ondemand, programacin de enlace
descendente (por ejemplo, , Un conmutador OpenFlow puede hacer una
conformacin de velocidad o divisin de tiempo [297], uso del espectro
dinmico [297], coordinacin de interferencia entre clulas mejorada [297],
[347], descarga de dispositivo a dispositivo (es decir, decidir cundo y cmo
LTE [350], por asignacin de bloques de recursos de cliente y / o estacin
base (es decir, ranuras de tiempo y frecuencia en redes LTE / ortogonal de
acceso mltiple por divisin de frecuencia (OFDMA) [296] , Que son
conocidos como bloques de recursos) [236], [296], [348], controlan y
asignan parmetros de transmisin y potencia en dispositivos o en grupos
(por ejemplo, algoritmos para optimizar los parmetros de transmisin y
potencia de dispositivos WLAN, Asignar valores de potencia de transmisin
a cada bloque de recursos, en cada estacin base, en redes LTE / OFDMA)
[236], [296], administracin simplificada [236], [300], [302], fcil manejo de
tecnologas de red heterogneas [236]. , [302], [351], la interoperabilidad
entre diferentes redes [348], [351], las infraestructuras inalmbricas
compartidas [351], la movilidad continua de los abonados y las redes
celulares [347], la QoS y las polticas de control de acceso factibles y fciles
[347]. ], [348], y el empleo de nuevas aplicaciones [236], [300], [351]. Uno
de los primeros pasos hacia la realizacin de estas caractersticas en las
redes inalmbricas es proporcionar capas de pilas programables y flexibles
para redes inalmbricas [236], [352]. Uno de los primeros ejemplos es
OpenRadio [352], que propone un soft
Ware capa de abstraccin para desacoplar la definicin del protocolo
inalmbrico del hardware, lo que permite compartir las capas MAC a travs
de diferentes protocolos utilizando las plataformas multicore commodity.
OpenRadio puede ser visto como el "OpenFlow para redes inalmbricas".
Similarmente, SoftRAN [236] propone repensar la capa de acceso de radio
de las actuales infraestructuras LTE. Su principal objetivo es permitir a los
operadores mejorar y optimizar algoritmos para mejores traspasos, control
de granos finos de poderes de transmisin, asignacin de bloques de
recursos, entre otras tareas de gestin. Los puntos de acceso virtuales
ligeros (LVAPs) son otra forma interesante de mejorar las capacidades de
gestin de las redes inalmbricas, tal como lo propone el marco Odin [300].
Diferentemente de OpenRadio, funciona con el hardware inalmbrico
existente y no impone ningn cambio en los estndares IEEE 802.11. Un
LVAP se implementa como una identificacin de conjunto de servicios
bsicos nica asociada con un cliente especfico, lo que significa que hay un
mapeo uno a uno entre LVAP y clientes. Esta abstraccin de punto de acceso
(AP) por cliente simplifica el manejo de las asociaciones de clientes, la
autenticacin, las transferencias y el corte unificado de partes tanto
cableadas como inalmbricas de la red. Odin logra la separacin del control
entre los distintos segmentos, ya que los PVAs son el tipo primitivo sobre el
cual las aplicaciones toman decisiones de control, y las aplicaciones no
tienen visibilidad de los LVAP desde fuera de su segmento. Esto permite que
los operadores de infraestructura proporcionen servicios a travs de las
aplicaciones de Odin, como un administrador de movilidad, un equilibrador
de carga basado en cliente, un algoritmo de seleccin de canal y una
aplicacin de solucin de problemas inalmbrica con diferentes segmentos
de red. Por ejemplo, cuando un usuario se desplaza de un AP a otro, Actuar
de manera automtica y proactiva y trasladar al cliente LVAP de un AP a
otro. De esta manera, un cliente inalmbrico ni siquiera se dar cuenta de
que empez a usar un AP diferente porque no hay un retraso perceptible en
el traspaso, como sera el caso en las redes inalmbricas tradicionales. Las
redes inalmbricas heterogneas muy densas tambin han sido un objetivo
para SDN. Estos DenseNets tienen limitaciones debido a restricciones tales
como cuellos de botella de acceso de radio, control de gastos generales y
altos costos de operacin [296]. Una jerarqua dinmica de controlador de
dos niveles SDN se puede adaptar para abordar algunas de estas
restricciones [296]. Los controladores locales pueden utilizarse para tomar
decisiones rpidas y finas, mientras que los controladores regionales (o
'globales') pueden tener un alcance ms amplio y ms grueso, es decir,
tomar decisiones ms lentas pero globales. De esta manera, el diseo de
una nica arquitectura integrada que abarque las clulas LTE (macro / pico /
femto) y WiFi, aunque desafiante, parece factible.
3) Medicin y monitoreo: Las soluciones de medicin y monitoreo se pueden
dividir en dos clases: primero, aplicaciones que proporcionan nueva
funcionalidad para otros servicios de redes; Y en segundo lugar, las
propuestas que apuntan a mejorar las caractersticas de los SDN basados en
OpenFlow, tales como reducir la sobrecarga del plano de control debido a la
recopilacin de estadsticas. Un ejemplo de la primera clase de solicitudes
es mejorar la visibilidad del rendimiento de la banda ancha [6], [353]. Una
conexin domiciliaria de banda ancha basada en SDN puede simplificar la
adicin de nuevas funciones en sistemas de medicin como BISmark [353],
lo que permite al sistema reaccionar a las condiciones cambiantes en la red
[6]. Por ejemplo, una pasarela puede realizar una configuracin reactiva del
trfico considerando los resultados de medicin actuales De la red
domstica. La segunda clase de soluciones normalmente implica diferentes
tipos de tcnicas de muestreo y estimacin que se aplicarn, con el fin de
reducir la carga del plano de control con respecto a la recopilacin de
estadsticas de planos de datos. Diferentes tcnicas han sido aplicadas para
lograr este objetivo, tales como las tcnicas de muestreo de paquetes
estocstico y determinista [354], estimacin de la matriz de trfico [261],
monitoreo de grano fino de las cadenas de wildcard [355], dos
etapasBloomfilters [356] La precisin de la medicin sin incurrir en una
sobrecarga de trfico de la memoria adicional o del plano de control [304], y
funciones de monitorizacin especiales (extensiones a OpenFlow) en los
dispositivos de reenvo para reducir el trfico y procesar la carga en el plano
de control. La estimacin de la matriz de trfico punto a punto, en
particular, puede ayudar en el diseo de la red y en tareas operativas tales
como equilibrio de carga, deteccin de anomalas, planificacin de
capacidad y aprovisionamiento de red. Con informacin sobre el conjunto de
flujos activos en la red, informacin de enrutamiento (por ejemplo, desde la
aplicacin de enrutamiento), rutas de flujo y contadores de flujo en los
conmutadores, es posible construir una matriz de trfico utilizando diversos
niveles de agregacin para fuentes y destinos [ 261].
Otras iniciativas de esta segunda clase proponen un mayor
desacoplamiento entre primitivas bsicas (por ejemplo, coincidencia y
conteo) y funciones de anlisis de trfico ms pesadas, como la deteccin
de ataques de condiciones de anomala [358]. Una separacin ms fuerte
favorece la portabilidad y la flexibilidad. Por ejemplo, una funcionalidad para
detectar flujos anormales no debe ser restringida por las primitivas bsicas
o la implementacin especfica de hardware. Dicho de otro modo, los
desarrolladores deben estar capacitados con abstracciones de flujo continuo
y capacidades de programacin de nivel superior. En ese sentido, algunas
abstracciones de planos de datos y de control se han diseado
especficamente para fines de medicin. OpenSketch [311] es una API
orientada al sur de propsito especial diseada para proporcionar
flexibilidad para mediciones de red. Por ejemplo, al permitir que mltiples
tareas de medicin se ejecuten simultneamente sin perjudicar la precisin.
El diseo interno de un switch OpenSketch se puede considerar como una
tubera con tres etapas (hashing, clasificacin y conteo). Los paquetes de
entrada pasan primero por una funcin de hashing. Luego, se clasifican de
acuerdo con una regla de coincidencia. Finalmente, la regla de coincidencia
identifica un ndice de conteo, que se utiliza para calcular la posicin del
contador en la etapa de recuento. Mientras que un TCAM con pocas
entradas es suficiente para la etapa de clasificacin, los contadores flexibles
se almacenan en SRAM. Esto hace que la operacin de OpenSketch sea
eficiente (rpida coincidencia) y rentable (SRAM ms barato para almacenar
contadores). Otros marcos de monitoreo, tales como OpenSample [309] y
PayLess [313], proponen diferentes mecanismos para entregar en tiempo
real, baja latencia y capacidades de monitoreo flexible a SDN sin perjudicar
la carga y el rendimiento del plano de control. Las soluciones propuestas se
aprovechan de tecnologas de muestreo como sFlow [310] para monitorear
redes de alta velocidad y colecciones flexibles de componentes acoplados
de forma holgada (plug-and-play) para proporcionar vistas abstractas de la
red que proporcionan enfoques de monitoreo de red eficientes y
eficientes. ], [313], [355].
4) Seguridad y Confiabilidad: Un conjunto de propuestas de seguridad y
confiabilidad ya est emergiendo en el contexto de las NDS. La mayora
aprovecha el SDN para mejorar los servicios requeridos para asegurar
sistemas y redes, como la aplicacin de polticas (por ejemplo, control de
acceso, firewalling, middleboxes como middlepipes [27], [100], [326], [328],
[337], deteccin y mitigacin de ataques DoS [325], [336], mutacin
aleatoria del anfitrin [326] (es decir, manda aleatoriamente y
frecuentemente las direcciones IP de los hosts finales para romper la
suposicin de los atacantes sobre IPs estticos, que es la [331], el monitoreo
de las infraestructuras de nube para las inspecciones de seguridad de grano
fino (es decir, analizar automticamente y desviar el trfico sospechado
para ser inspeccionado por dispositivos especializados de seguridad de la
red, como los sistemas de inspeccin profunda de paquetes) [323] [325],
[336], [354], el control de acceso a redes de grano fino basado en flujo
[327], la aplicacin de polticas de grano fino para aplicaciones mviles
personales [329], etc. [100], [323], [ 325], [326], [328], [331], [337], [354].
Otros abordan problemas de redes basadas en OpenFlow, tales como
priorizacin de reglas de flujo, composicin de servicios de seguridad,
proteccin contra la sobrecarga de trfico y proteccin contra
administradores malintencionados [199], [201], [259], [322], [330]. Hay
esencialmente dos enfoques, uno implica el uso de SDN para mejorar la
seguridad de la red, y otro para mejorar la seguridad de la propia SDN. El
enfoque ha sido, hasta ahora, en el segundo.
5) Uso de SDN para mejorar la seguridad de las redes actuales:
Probablemente la primera instancia de SDN fue una aplicacin para la
aplicacin de polticas de seguridad [100]. Un SDN permite que se haga la
imposicin en el primer punto de entrada a la red (por ejemplo, el
conmutador Ethernet al que el usuario est conectado). Alternativamente,
en un entorno hbrido, la aplicacin de la poltica de seguridad puede
hacerse en un permetro de red ms amplio a travs de dispositivos
programables (sin necesidad de migrar toda la infraestructura a OpenFlow)
[328]. Con cualquiera de las aplicaciones, las acciones malintencionadas se
bloquean antes de entrar en las regiones crticas de la red. SDN se ha
aplicado con xito para otros fines, a saber, para la deteccin (y la reaccin)
contra los ataques distribuidos de denegacin de servicio (DDoS) [325], y la
seguridad activa [321]. Los dispositivos de reenvo de OpenFlow facilitan la
recopilacin de una variedad de informacin de la red, de manera oportuna,
lo cual es muy til para algoritmos especializados en la deteccin de
ataques DDoS. Las capacidades ofrecidas por los SDN para aumentar la
capacidad de recopilar datos estadsticos de la red y permitir que las
aplicaciones programen activamente los dispositivos de reenvo, son
poderosas para las tcnicas de proteccin y de seguridad policial, como
Seguridad activa [321]. Esta nueva metodologa de seguridad propone un
nuevo circuito de retroalimentacin para mejorar el control de los
mecanismos de defensa de una infraestructura en red y se centra alrededor
de cinco capacidades principales: proteger, detectar, ajustar, recoger y
contrarrestar. En esta perspectiva, la seguridad activa proporciona una
interfaz de programacin centralizada que simplifica la integracin de
mecanismos para detectar ataques mediante: 1) recoleccin de datos de
diferentes fuentes (para identificar ataques); 2) convergir a una
configuracin consistente para los dispositivos de seguridad; Y 3) reforzar
las contramedidas para bloquear o minimizar el efecto de los ataques.
6) Mejorar la seguridad de SDN: Ya existen algunos esfuerzos de
investigacin para identificar las amenazas crticas a la seguridad de los
SDN y aumentar su seguridad y fiabilidad [201], [259], [359]. Los primeros
enfoques tratan de aplicar tcnicas simples, como clasificar las aplicaciones
y utilizar la priorizacin de reglas, para asegurar que las reglas generadas
por las aplicaciones de seguridad no sern sobrescritas por las aplicaciones
de menor prioridad [201]. Otras propuestas tratan de ir un paso ms all al
proporcionar un marco para el desarrollo de aplicaciones relacionadas con la
seguridad en las NDS [259]. Sin embargo, todava hay un largo camino por
recorrer en el desarrollo de infraestructuras SDN seguras y fiables [359]. Un
profundo sobre en la seccin V-F.
7) Redes de centros de datos: Desde las pequeas empresas hasta los
proveedores de cloud computing a gran escala, la mayora de los sistemas y
servicios de TI existentes dependen en gran medida de centros de datos
altamente escalables y eficientes. Sin embargo, estas infraestructuras
siguen planteando desafos significativos en cuanto a computacin,
almacenamiento y redes. En lo que respecta a este ltimo, los centros de
datos deben disearse y desplegarse de tal manera que ofrezcan ancho de
banda de alta y flexible seccin y baja latencia, QoS basado en los requisitos
de la aplicacin, altos niveles de resiliencia, utilizacin inteligente de
recursos para reducir el consumo de energa y mejorar La agilidad en el
aprovisionamiento de los recursos de la red, por ejemplo, mediante la
virtualizacin de la red y la orquestacin con la computacin y el
almacenamiento, y as sucesivamente [360] - [362]. No es sorprendente que
muchas de estas cuestiones permanezcan abiertas debido a la complejidad
e inflexibilidad de las arquitecturas de red tradicionales. Se espera que el
surgimiento de SDN cambie la situacin actual. Los primeros esfuerzos de
investigacin han demostrado que la creacin de redes de centros de datos
puede beneficiarse significativamente de SDN en la solucin de diferentes
problemas, como la migracin en red viva [318], la mejora de la gestin de
red [317], [318], eminente fracaso [317] [318], la solucin de problemas
[318], [319], la optimizacin de la utilizacin de la red [314], [316], [317],
[319], el suministro dinmico y elstico de middleboxes-as-a -servicio [27], y
la minimizacin de la latencia de configuracin de flujo y la reduccin de los
costos de operacin del controlador [363]. SDN tambin puede ofrecer
primitivas de red para aplicaciones en nube, soluciones para predecir
transferencias de aplicaciones de red [314], [316], mecanismos para la
reaccin rpida a problemas de operacin, colocacin de VM en red [315],
[319] 316], [319], servicios y mecanismos de aplicacin de la poltica de
seguridad [315], [319], y permitir la adaptacin programtica de los
protocolos de transporte [314] , [320]. SDN puede ayudar a los proveedores
de infraestructura a exponer ms primitivas de red a sus clientes,
permitiendo el aislamiento virtual de la red, el direccionamiento
personalizado y la colocacin de las cajas de acceso mltiples y las
aplicaciones virtuales del escritorio [315], [364]. Para explorar
completamente el potencial de las redes virtuales en las nubes, una
caracterstica esencial es la migracin de la red virtual. De manera similar a
la migracin de mquinas virtuales tradicionales, es posible que sea
necesario migrar una red virtual cuando sus mquinas virtuales se mueven
de un lugar a otro. Integrar la migracin en vivo de mquinas virtuales y
redes virtuales es uno de los retos ms importantes [318]. Para lograr este
objetivo, es necesario reconfigurar dinmicamente todos los dispositivos de
red afectados (fsicos o virtuales). Esto se ha demostrado que es posible con
las plataformas SdN, tales como NVP [112]. Otra aplicacin potencial de
SDN en centros de datos es la deteccin de comportamientos anormales en
la operacin de la red [317]. Mediante la utilizacin de diferentes modelos
de comportamiento y la recopilacin de la informacin necesaria de los
elementos involucrados en el funcionamiento de un centro de datos
(infraestructura, operadores, aplicaciones), es posible crear continuamente
firmas para aplicaciones capturando pasivamente el trfico de control.
Entonces, la historia de la firma se puede utilizar para identificar diferencias
en comportamiento. Cada vez que se detecta una diferencia, los operadores
pueden tomar medidas correctivas de forma reactiva o proactiva. Esto
puede ayudar a aislar componentes anormales y evitar mayores daos a la
infraestructura.
8) hacia almacenes de la aplicacin de SDN: Como se puede observar en las
tablas 9 y 10, la mayora de las aplicaciones de SDN confan en NOX y
OpenFlow. NOX fue el primer controlador disponible para uso general, por lo
que es una eleccin natural para la mayora de los casos de uso hasta el
momento. Como se indica por el gran nmero de aplicaciones relacionadas
con la seguridad, la seguridad es probablemente una de las aplicaciones
asesinas para SDNs. Curiosamente, mientras que la mayora de los casos de
uso se basan en OpenFlow, nuevas soluciones como SoftRAN estn
considerando diferentes APIs, como es el caso del Femto API [253], [303].
Esta diversidad de aplicaciones y APIs probablemente seguir creciendo en
SDN. Hay otros tipos de aplicaciones de red que no encajan fcilmente en
nuestra taxonoma, como Avior [365], OESS [366] y SDN App Store [367],
[368]. Avior y OESS son interfaces grficas y conjuntos de herramientas de
software que facilitan la configuracin y administracin de controladores
(por ejemplo, Floodlight) y conmutadores habilitados para OpenFlow,
respectivamente. Al aprovechar sus funciones grficas es posible programar
dispositivos habilitados para OpenFlow sin codificar en un lenguaje de
programacin particular. La tienda de aplicaciones SDN [367], [368],
propiedad de HP, es probablemente la primera tienda del mercado de
aplicaciones SDN. Los clientes que usan el controlador OpenFlow de HP
tienen acceso a la Tienda de aplicaciones SDN en lnea y pueden seleccionar
aplicaciones que se descargarn e instalarn dinmicamente en el
controlador. La idea es similar al Android Market o Apple Store, lo que facilita
a los desarrolladores proporcionar nuevas aplicaciones y que los clientes las
obtengan.
I. Problemas de capa cruzada En esta seccin, examinamos problemas de
capa cruzada como depuracin y solucin de problemas, pruebas,
verificacin, simulacin y emulacin. Un resumen de las herramientas
existentes para hacer frente a los problemas de la capa transversal se
puede encontrar en la Tabla11.
1) Depuracin y solucin de problemas: La depuracin y la solucin de
problemas han sido temas importantes en las infraestructuras informticas,
sistemas paralelos y distribuidos, sistemas embebidos y aplicaciones de
escritorio [369] - [375]. Las dos estrategias predominantes aplicadas a la
depuracin y solucin de problemas son la depuracin en tiempo de
ejecucin (por ejemplo, las herramientas tipo gdb) y el anlisis post-mortem
(por ejemplo, rastreo, reproduccin y visualizacin). A pesar de la constante
evolucin y la aparicin de nuevas tcnicas para mejorar la depuracin y
solucin de problemas, todava hay varias vas abiertas y preguntas de
investigacin [370].
La depuracin y la solucin de problemas en las redes est en una etapa
muy primitiva. En las redes tradicionales, los ingenieros y desarrolladores
tienen que usar herramientas como ping, traceroute, tcpdump, nmap,
netflow y estadsticas SNMP para depurar y solucionar problemas. Depurar
una red compleja con estas herramientas primitivas es muy difcil. Incluso
cuando se consideran marcos tales como XTrace [374], Netreplay [376] y
NetCheck [377], que mejoran las capacidades de depuracin en las redes,
sigue siendo difcil solucionar las infraestructuras de red. Por ejemplo, estos
marcos requieren un esfuerzo enorme en trminos de instrumentacin de
red. La complejidad adicional introducida por diferentes tipos de
dispositivos, tecnologas y componentes y caractersticas especficos del
proveedor empeora las cosas. Como consecuencia, estas soluciones pueden
resultar difciles de implementar y desplegar ampliamente en las redes
actuales.
SDN ofrece algunas esperanzas en este sentido. Las capacidades de control
basadas en software hardwareagnostic y el uso de estndares abiertos para
la comunicacin de control pueden potencialmente facilitar la depuracin y
la resolucin de problemas. La flexibilidad y la programabilidad introducida
por SDN est de hecho abriendo nuevas vas para desarrollar mejores
herramientas para depurar, solucionar problemas, verificar y probar redes
[378] - [385]. Las primeras herramientas de depuracin para redes
habilitadas para OpenFlow, como ndb [378], OFRewind [379] y NetSight
[386], facilitan descubrir la fuente de problemas de red como el firmware del
dispositivo defectuoso [378], flujo inconsistente o inexistente Reglas [378],
[379], falta de accesibilidad [378], [379] y enrutamiento defectuoso [378],
[379]. De forma similar al conocido depurador de software gdb, ndb
proporciona acciones bsicas de depuracin tales como punto de
interrupcin, watch, backtrace, single step y continuar. Estos primitivos
ayudan a los desarrolladores de aplicaciones a depurar redes de una
manera similar al software tradicional. Mediante el uso de las tarjetas
postales de ndb (es decir, un identificador de paquete nico compuesto por
una copia truncada del encabezado del paquete, la entrada de flujo
coincidente, el conmutador y el puerto de salida), por ejemplo, un
programador puede identificar y aislar rpidamente un OpenFlow Con
problemas de hardware o software. Si el conmutador est presentando un
comportamiento anormal como la corrupcin de partes del encabezado del
paquete, analizando las secuencias de flujo problemticas con una
herramienta de depuracin, se puede encontrar (en cuestin de segundos)
donde los paquetes de un flujo estn siendo daados, y tomar Las acciones
necesarias para resolver el problema. La herramienta OFRewind [379]
funciona de manera diferente. La idea es registrar y reproducir eventos de
red, en particular mensajes de control. Estos suelen representar menos del
1% del trfico de datos y son responsables del 95% -99% de los errores
[385]. Esta herramienta permite a los operadores realizar un rastreo de
grano fino del comportamiento de la red, pudiendo decidir qu subconjuntos
de la red sern grabados y, a continuacin, seleccionar partes especficas
de las trazas a reproducir. Estas repeticiones proporcionan informacin
valiosa para encontrar la causa raz de la mala conducta de la red.
Asimismo, NetRevert [387] tambin registra el estado de las redes
OpenFlow. Sin embargo, el objetivo principal no es reproducir el
comportamiento de la red, sino ms bien proporcionar recuperacin de
reversin en caso de fallos, que es un enfoque comn utilizado en sistemas
distribuidos para eliminar errores transitorios en los nodos [388], [389]. A
pesar de la disponibilidad de estas herramientas de depuracin y
verificacin, todava es difcil responder preguntas como: Qu est
sucediendo a mis paquetes que fluyen desde el punto A al punto B? Qu
camino siguen? Qu modificaciones de cabecera sufren en el camino? Para
responder a algunas de estas preguntas uno podra volver a la historia de
los paquetes. El historial de un paquete corresponde a las rutas que utiliza
para recorrer la red ya las modificaciones de encabezado en cada salto de la
ruta. NetSight [386] es una plataforma cuyo objetivo principal es permitir
que las aplicaciones que utilizan el historial de los paquetes para ser
construido, con el fin de averiguar los problemas en una red. Esta
plataforma se compone de tres elementos esenciales: 1) NetSight, con sus
servidores dedicados que reciben y procesan las tarjetas postales para
construir el historial de paquetes; 2) el NetSigh-SwitchAssist, que se puede
utilizar en conmutadores para reducir la carga de procesamiento en los
servidores dedicados; Y 3) el NetSight-HostAssist para generar y procesar
tarjetas postales en los hosts finales (por ejemplo, en el hipervisor en una
infraestructura virtualizada). Netwatch [386], netshark [386], y nprof [386]
son tres ejemplos de herramientas construidas sobre NetSight. El primero es
un monitor invariante de red en vivo. Por ejemplo, se puede activar una
alarma cada vez que un paquete viola cualquier invariante (por ejemplo, sin
bucles). El segundo, netshark, permite a los usuarios definir y ejecutar filtros
en todo el historial de paquetes. Con esta herramienta, un operador de red
puede ver una lista completa de propiedades de paquetes en cada salto,
como puerto de entrada, puerto de salida y valores de encabezado de
paquete. Finalmente, nprof puede usarse para perfilar conjuntos de enlaces
de red para proporcionar datos para analizar patrones de trfico y
decisiones de enrutamiento que podran estar contribuyendo a la carga de
enlaces.
2) Pruebas y Verificacin: Las herramientas de verificacin y prueba pueden
complementar la depuracin y la solucin de problemas. Investigaciones
recientes [380], [382] - [385], [390], [391] ha demostrado que las tcnicas
de verificacin se pueden aplicar para detectar y evitar problemas en SDN,
tales como bucles de reenvo y agujeros negros. La verificacin se puede
hacer en diferentes capas (en los controladores, aplicaciones de red o
dispositivos de red). Adems, hay diferentes propiedades de redV
principalmente topolgicas especficasV que se pueden verificar
formalmente, siempre que haya un modelo de red disponible. Ejemplos de
tales propiedades son la conectividad, la libertad de lazo, y el control de
acceso [29]. Tambin se han propuesto varias herramientas para evaluar el
rendimiento de los controladores OpenFlow emulando la carga de las redes
a gran escala (por ejemplo, Cbench [392], OFCBenchmark [393], PktBlaster
[394]). Del mismo modo, las herramientas de evaluacin comparativa para
los conmutadores OpenFlow estn tambin disponibles (por ejemplo,
OFLOPS [381] y FLOPS-Turbo [395]). Herramientas como NICE [380] generan
conjuntos de diversas corrientes de paquetes para probar tantos eventos
como sea posible, exponiendo casos de esquina tales como condiciones de
carrera. Del mismo modo, OFLOPS [381] proporciona un conjunto de
caractersticas y funciones que
Permiten el desarrollo y la ejecucin de un rico conjunto de pruebas en
dispositivos habilitados para OpenFlow. Su objetivo final es medir la
capacidad de procesamiento y los cuellos de botella de las aplicaciones de
control y los dispositivos de reenvo. Con esta herramienta, los usuarios
pueden observar y evaluar la consistencia de la tabla de reenvo, la latencia
de la configuracin de flujo, la granularidad del espacio de flujo, los tipos de
modificacin de paquetes y las capacidades de supervisin de trfico (por
ejemplo, contadores). FlowChecker [382], OFTEN [384] y VeriFlow [383] son
tres ejemplos de herramientas para verificar las infracciones de propiedades
de correccin en el sistema. Mientras que los dos anteriores se basan en
anlisis offline, este ltimo es capaz de comprobar en lnea de invariants de
red. Las restricciones de verificacin incluyen problemas de seguridad y
accesibilidad, actualizaciones de configuracin en la red, bucles, agujeros
negros, etc. Otras tcnicas formales de modelado, como Alloy, pueden
aplicarse a los SDN para identificar un comportamiento inesperado [390].
Por ejemplo, una especificacin de protocolo puede ser dbil cuando
subestima algunos aspectos del protocolo o debido a una secuencia muy
especfica de eventos. En tales situaciones, las tcnicas de comprobacin de
modelos como Alloy pueden ayudar a encontrar y corregir comportamientos
inesperados. Herramientas como FLOWGUARD [396] estn diseadas
especficamente para detectar y resolver infracciones de polticas de
seguridad en redes habilitadas para OpenFlow. FLOWGUARD es capaz de
examinar las actualizaciones de la poltica de red al instante, comprobar
infracciones de seguridad indirectas (por ejemplo, la modificacin de las
acciones de Set-Field de OpenFlow) y realizar un monitoreo con estado. El
marco utiliza cinco estrategias de resolucin para la resolucin de
violaciones de polticas de seguridad en tiempo real, rechazo de flujo,
ruptura de dependencia, rechazo de actualizacin, eliminacin de flujo y
bloqueo de paquetes [396]. Estas resoluciones se aplican a diversas
situaciones de actualizacin en redes habilitadas para OpenFlow. Ms
recientemente, se han diseado herramientas como VeriCon [397] para
verificar la correccin de las aplicaciones SDN en una amplia gama de
topologas de red y analizar una amplia gama de secuencias de eventos de
red. En concreto, VeriCon confirma o no la correcta ejecucin del programa
SDN. Uno de los desafos en la prueba y verificacin es verificar las tablas
de reenvo en redes muy grandes para encontrar errores de enrutamiento,
lo que puede causar prdidas de trfico y violaciones de seguridad, tan
pronto como sea posible. En las redes a gran escala, no es posible suponer
que la instantnea de la red, en ningn momento, es consistente, debido a
los frecuentes cambios en el estado de enrutamiento. Por lo tanto, las
soluciones tales como HSA [398], Anteater [399], NetPlumber [400], Veri-
Flow [383] y lenguajes de asercin [401] no son adecuados para este tipo
de entorno. Otra cuestin importante est relacionada con la rapidez con
que se realiza el proceso de verificacin, especialmente en los centros de
datos modernos que tienen requisitos de sincronizacin muy ajustados.
Libra [391] representa uno de los primeros intentos de abordar estos
desafos particulares de las redes a gran escala. Esta herramienta
proporciona los medios para capturar instantneas estables y consistentes
de despliegues de red a gran escala, al tiempo que aplica tcnicas de
coincidencia de prefijos largos para aumentar la escalabilidad del sistema.
Mediante el uso de clculos MapReduce, Libra es capaz de verificar la
correccin de una red con un mximo de 10 000 nodos dentro de un minuto.
Anteater [399] es una herramienta que analiza el estado del plano de datos
de los dispositivos de red mediante la codificacin de configuraciones de
conmutador como instancias de problema de satisfaccin booleana (SAT),
permitiendo utilizar un solver SAT para analizar el estado de la red. La
herramienta es capaz de verificar violaciones de invariantes tales como
reenvo sin bucle, conectividad y consistencia. Estos invariantes indican
generalmente un error en la red, es decir, su deteccin ayuda a aumentar la
fiabilidad del plano de datos de red.
3) Simulacin y emulacin: El software de simulacin y emulacin es de
importancia particular para el diseo y la prueba de prototipos sin necesidad
de dispositivos fsicos costosos. Mininet [110] es el primer sistema que
proporciona una manera rpida y fcil de prototipos y evaluar protocolos y
aplicaciones SDN. Una de las principales propiedades de Mininet es su uso
de conmutadores OpenFlow basados en software en contenedores
virtualizados, proporcionando la semntica exacta de los conmutadores
OpenFlow basados en hardware. Esto significa que los controladores o
aplicaciones desarrolladas y probadas en el entorno emulado pueden (en
teora) desplegarse en una red OpenFlowenabled sin la modificacin. Los
usuarios emulan fcilmente una red OpenFlow con cientos de nodos y
docenas de conmutadores usando un solo ordenador personal. Mininet-HiFi
[402] es una evolucin de Mininet que mejora la virtualizacin basada en
contenedores (ligera) con mecanismos para reforzar el aislamiento del
rendimiento, el aprovisionamiento de recursos y el monitoreo preciso de la
fidelidad al rendimiento. Uno de los principales objetivos de Mininet-HiFi es
mejorar la reproducibilidad de la investigacin en red. Mininet CE [403] y
SDN Cloud DC [404] son extensiones de Mininet para permitir simulaciones
a gran escala. Mininet CE combina grupos de instancias de Mininet en un
cluster de instancias de simulador para modelar redes de escala global. SDN
Cloud DC mejora Mininet y POX para emular una red intra-DC basada en
SDN mediante la implementacin de nuevas capacidades de anlisis de
redes y generacin de trfico de red. Las propuestas recientes de la
plataforma de emulacin que permiten realizar experimentos a gran escala
siguiendo un enfoque distribuido incluyen Max-iNet [405], DOT [406]
yCityFlow [407]. El proyecto es un proyecto con el objetivo de construir una
capacidad de control controlada de millones de habitantes. Tales iniciativas
son un punto de partida para proporcionar conocimientos experimentales
para despliegues SDN a gran escala. La capacidad de simular dispositivos
OpenFlow tambin se ha aadido al popular simulador ns-3 [408]. Otro
simulador es fs-sdn, el cual extiende el motor de simulacin de ffs [409]
incorporando un controlador y conmutando componentes con soporte de
OpenFlow. Su principal objetivo es proporcionar una plataforma de
simulacin ms realista y escalable en comparacin con Mininet. Por ltimo,
STS [410] es un simulador diseado para permitir a los desarrolladores
especificar y aplicar una variedad de casos de prueba, mientras que les
permite examinar de forma interactiva el estado de la red.

V. ESFUERZOS Y DESAFOS DE LA INVESTIGACIN CONTINUA

Los desarrollos de investigacin que hemos estudiado hasta ahora tratan de
superar los desafos de realizar la visin y cumplir las promesas de SDN. Si
bien la Seccin IV proporciona una perspectiva estructurada a travs de las
capas de la "pila SDN", esta seccin destaca los esfuerzos de investigacin
que consideramos de particular importancia para liberar el potencial de
DSN, y por lo tanto merece una cobertura especfica en esta encuesta.
A. Diseos de conmutadores Los interruptores OpenFlow actualmente
disponibles son muy diversos y presentan notables diferencias en trminos
de conjunto de caractersticas (por ejemplo, tamao de la tabla de flujo,
acciones opcionales), rendimiento (por ejemplo, velocidad frente a
trayectoria lenta, latencia / rendimiento del canal de control), interpretacin
y adherencia A la especificacin del protocolo (p. Ej., Comando BARRIER) ya
la arquitectura (por ejemplo, hardware versus diseos de software).
1) Implementaciones heterogneas: Las opciones de implementacin tienen
un impacto fundamental en el comportamiento, la precisin y el rendimiento
de los conmutadores, que van desde las diferencias en el comportamiento
del contador de flujo [418] hasta una serie de otras mtricas de rendimiento
[381]. Un enfoque para dar cabida a dicha heterogeneidad es a travs de
NOSIX, una API porttil que separa las expectativas de la aplicacin de la
heterogeneidad de conmutacin [246]. Para ello, NOSIX proporciona una
tubera de mltiples tablas de flujo virtual y controladores de conmutador.
Las tablas de flujo virtuales estn diseadas para satisfacer las expectativas
de las aplicaciones y, en ltima instancia, son traducidas por los
controladores en tablas de flujo de conmutacin reales. Hacia la
domesticacin de la complejidad de mltiples versiones de protocolo
OpenFlow con diferentes conjuntos de capacidades requeridas y opcionales,
se ha propuesto un bloqueo para practicantes de SDN, tinyNBI [419] como
una API simple que proporciona un conjunto unificador de abstracciones de
ncleo de cinco versiones de protocolo OpenFlow 1,0 a 1,4). Los esfuerzos
en curso para introducir un nuevo HAL para dispositivos no compatibles con
OpenFlow incluyen el desarrollo de artefactos de cdigo abierto como la
Biblioteca OpenFlow Revisada (ROFL) y el demonio eXtensible DataPath
(xDPd), un marco para crear nuevas implementaciones de rutas de datos
OpenFlow basadas en Un conjunto diverso de plataformas de hardware y
software. Un esfuerzo relacionado de cdigo abierto para desarrollar una
biblioteca comn para implementar los terminales de protocolo OpenFlow
1.0 y 1.3 (agentes de conmutacin y controladores) es libfluid [421],
ganador del concurso de OpenFlow organizado por la ONF. Dentro de la ONF,
el Grupo de Trabajo de Abstraccin de Transmisin (FAWG) est buscando
otra solucin al problema de heterogeneidad, a travs de patrones de tipo
de tabla (TTPs) [121]. Un TTP es una abstraccin conductual basada en
estndares y negociada. Consiste en las relaciones entre las tablas que
forman una estructura de grfico, los tipos de tablas en el grfico, un
conjunto de las propiedades de tablas parametrizadas para cada tabla en el
grfico, los comandos de flujo-mod legal y mod de tabla para cada tabla de
flujo y La mscara de metadatos que se puede pasar entre cada par de
tablas en el grfico.
2) Capacidad de la tabla de flujo: Las reglas de coincidencia de flujo se
almacenan en tablas de flujo dentro de los dispositivos de red. Un desafo
prctico consiste en proporcionar conmutadores con tablestostorterulas de
flujo grandes y eficientes [422]. Los TCAMs son una opcin comn para
mantener tablas de flujo. Aunque son flexibles y eficientes en trminos de
capacidad de comparacin, los TCAM son costosos y usualmente pequeos
(de 4000 a 32 000 entradas). Algunos chips TCAM integran actualmente 18
millones de bits (configurados como 500 000 entradas, 36 bits por entrada)
en un solo chip que funciona a 133 MHz [423], es decir, capaz de 133
millones de bsquedas por segundo. Sin embargo, estos chips son costosos
y tienen un consumo de alta potencia [424], que representa un mayor
drenaje de potencia en un dispositivo de conmutacin [425]. Estas son
algunas de las razones por las que los dispositivos OpenFlow actualmente
disponibles tienen TCAMs con aproximadamente 8000 entradas, donde la
capacidad real en trminos de tamao de tabla OpenFlow tiene una relacin
no trivial con el tipo de entradas de flujo que se estn utilizando [426],
[427]. OpenFlow versin 1.1 introdujo varias tablas, lo que agrega
flexibilidad y escalabilidad adicionales. De hecho, OpenFlow 1.0 implic la
explosin del estado debido a su modelo plano de la tabla [121]. Sin
embargo, el apoyo a mltiples tablas en el hardware es un desafo y
limitados. Sin embargo, otra motivacin para el trabajo en curso de la FAFN
sobre TTP [121]. Algunos esfuerzos se centran en las tcnicas de
compresin para reducir el nmero de entradas de flujo en TCAM [428] -
[430]. La heurstica de Espresso [430] se puede utilizar para comprimir
tarjetas comodn de tablas de encaminamiento de interdomains basadas en
OpenFlow, reduciendo en un 17% la base de informacin de reenvo (FIB) y,
por consiguiente, ahorrando hasta 40 000 entradas de tabla de flujo [428].
Los MAC de sombra [429] proponen la conmutacin de etiquetas para
resolver dos problemas, actualizaciones consistentes y agotamiento del
espacio de reglas, utilizando valores opacos (similares a las etiquetas MPLS)
para codificar rutas de grano fino como etiquetas. Una ventaja importante
de las etiquetas de tamao fijo se basa en las bsquedas de matemticas
exactas que pueden implementarse de manera sencilla y rentable mediante
tablas de hardware simples en lugar de requerir que las reglas se codifiquen
en tablas TCAM caras.
3) Rendimiento: Hoy en da, el rendimiento de los conmutadores OpenFlow
comerciales vara de 38 a 1000 flujo-mod por segundo, con la mayora de
los dispositivos de lograr un rendimiento inferior a 500 flujo-mod por
segundo [431], [432]. Este es claramente un factor limitante que se
abordar en el proceso de diseo de conmutadores. El soporte de OpenFlow
en lneas de productos existentes ha sido ms una actividad de
reacondicionamiento que una actividad de planificacin e implementacin
de caractersticas limpias. Las experiencias de despliegue [433] han
sealado una serie de desafos derivados de la limitada potencia de CPU
integrada de los interruptores comerciales OpenFlow actuales. Un enfoque
para manejar el problema consiste en la adicin de CPUs ms potentes en
los conmutadores, como se propone en [434]. Otros han propuesto repensar
la distribucin de acciones de control entre los controladores externos y el
OpenFlow
Agente dentro del conmutador [418]. Nuestra comprensin actual indica
que una manera eficaz de avanzar es un diseo nativo de SDN
conmutadores consistentes con la evolucin de la API hacia el sur
actividades de normalizacin [121], [435].
4) Evolucin de diseos de conmutadores y mejoras de hardware: Como en
cualquier ciclo de innovacin de software / hardware, se espera una serie de
avances desde la perspectiva del hardware para mejorar las capacidades y
el rendimiento de SDN. Los nuevos diseos de conmutadores SDN aparecen
en una mirada de combinaciones de hardware para trabajar eficientemente
con TCAMs, tales como memoria esttica de acceso aleatorio (SRAM),
memoria dinmica de acceso aleatorio (DRAM), DRAM de baja frecuencia,
unidad de procesamiento grfico (GPU), campo programable Gate array
(FPGA), procesadores de red, CPUs, entre otros procesadores de red
especializados [436] - [441].
Estas primeras obras sugieren la necesidad de esfuerzos adicionales en
nuevas arquitecturas de hardware para futuros dispositivos de conmutacin
SDN. Por ejemplo, algunas propuestas apuntan a tecnologas como las GPUs
que han demostrado 20 gigabits por segundo (Gb / s) con tablas de flujo de
hasta 1 milln de entradas de coincidencia exacta y hasta 1000 entradas
comodn [438]. Las alternativas a los diseos basados en TCAM incluyen
nuevas arquitecturas de hardware y componentes, as como aviones de
reenvo nuevos y escalables, como el propuesto por el firmware Rain Man
[442]. Otras soluciones de diseo, como los modelos de bsqueda en
paralelo [443], tambin se pueden aplicar a SDN para reducir los costos en
dispositivos de conmutacin y enrutamiento. Las propuestas recientes sobre
arreglos de conmutadores OpenFlow cachelike [444] arrojan luz sobre cmo
superar las limitaciones prcticas de los tamaos de tablas de flujo con
diseos de conmutacin inteligentes. Adems, los contadores representan
otro desafo prctico en implementaciones de hardware SDN. Muchos
contadores ya existen, y podran conducir a una supervisin significativa del
control del plano de control [418]. Se han propuesto contadores definidos
por software (SDC) [434] para proporcionar tanto escalabilidad como
flexibilidad. Se proponen arquitecturas SDN con aplicacin para generalizar
las abstracciones estndar de envo de OpenFlow mediante la inclusin de
acciones con estado para permitir el procesamiento de informacin desde
las capas 4 a 7 [445]. Para ello, se proponen tablas de flujo de aplicaciones
como mdulos de aplicacin de plano de datos que requieren slo un estado
local, es decir, no dependen de una vista global de la red. Esos minsculos
mdulos de aplicacin se ejecutan dentro de los dispositivos de reenvo (y
se pueden instalar bajo demanda), aliviando la sobrecarga en el plano de
control y aumentando la eficiencia de ciertas tareas, que pueden
mantenerse en el plano de datos. Del mismo modo, otras iniciativas
proponen soluciones basadas en mquinas de estado preinstaladas. La
transicin de estado a nivel de flujo (FAST) [446] permite a los controladores
programar proactivamente las transiciones de estado en los dispositivos de
reenvo, permitiendo a los conmutadores ejecutar acciones dinmicas que
requieren slo informacin local. Otros enfoques para la evolucin de los
diseos de conmutadores incluyen CAching in Buckets (CAB), una propuesta
de almacenamiento en cach reactiva que utiliza una representacin
geomtrica del conjunto de reglas, que se divide en pequeas estructuras
lgicas [447]. A travs de esta tcnica, CAB es capaz de resolver el
problema de dependencia de reglas y lograr un uso eficiente de los recursos
del plano de control, es decir, el ancho de banda, la carga de procesamiento
del controlador y la latencia de la configuracin del flujo. Nuevos chips de
conmutacin Ethernet programables, como XPliant Ethernet [448], estn
surgiendo en este nuevo mercado de redes programables. Su objetivo
principal es permitir el nuevo soporte de protocolo y la adicin de nuevas
caractersticas a travs de actualizaciones de software, aumentando la
flexibilidad. Un ejemplo de esta flexibilidad es el apoyo de GENEVE [39], un
esfuerzo reciente hacia protocolos genricos de encapsulacin de
virtualizacin de red, y OpenFlow. El rendimiento de la primera familia de
chips XPliant Ethernet vara de 880 Gb / s a 3,2 Terabits por segundo (Tb /
s), soportando hasta 64 puertos de 40 GbE o 50 GbE, por ejemplo. Las
empresas de microchip como Intel ya estn enviando procesadores con
capacidades SDN flexibles al mercado [449]. Los recientes avances en la
tecnologa de CPU de propsito general incluyen un kit de desarrollo de
plano de datos (DPDK) [450] que permite la programacin de alto nivel de
cmo los paquetes de datos sern procesados directamente dentro de las
tarjetas de interfaz de red. Las implementaciones de prototipos del
conmutador Intel DPDK acelerado muestran el potencial para entregar
switches de software SDN de alto rendimiento [441]. Es probable que esta
tendencia contine, ya que se necesita hardware de alta velocidad y
especializado para aumentar el rendimiento y escalabilidad de SDN para
grandes redes del mundo real. Las tecnologas programables por hardware
como FPGA se utilizan ampliamente para reducir el tiempo y los costos de
las implementaciones de caractersticas basadas en hardware. NetFPGA, por
ejemplo, ha sido una tecnologa pionera utilizada para implementar
conmutadores OpenFlow 1.0 [437], proporcionando una solucin de
prototipado rentable de productos bsicos. Otra lnea de trabajo en los
planos de datos SDN propone aumentar los conmutadores con FPGA para
(remotamente) definir la gestin de la cola y el comportamiento de
programacin de los conmutadores de paquetes [451].
Por ltimo, los ltimos desarrollos han demostrado que las plataformas de
sistema en chip (SoC) de ltima generacin, como la placa Xilinx Zynq
ZC706, pueden utilizarse para implementar dispositivos OpenFlow con un
rendimiento de 88 Gb / s para 1000 flujos dinmicos de soporte
Actualizaciones [452].
5) Diseos de conmutadores SDN nativos: La mayora de los esfuerzos de
diseo (re) de conmutacin de SDN hasta ahora siguen un enfoque
evolutivo para adaptar las caractersticas programables especficas de
OpenFlow a los diseos de hardware existentes, siguiendo la sabidura
comn sobre diseos de conmutador / enrutador y tecnologas
consolidadas , TCAM, FPGA). Una desviacin de este enfoque es el trabajo
en curso sobre el envo de meta-morfosis [435], un modelo de tabla de
coincidencias reconfigurable inspirado en la arquitectura de pipeline
RISClike aplicada a los chips de conmutacin. Este trabajo ilustra la
factibilidad de realizar un conjunto mnimo de primitivas de accin para el
procesamiento de cabecera flexible en hardware, casi sin coste adicional o
potencia. Tambin en lnea con los objetivos centrales de SDN de planos de
datos altamente flexibles y programables (basados en hardware), POF [120]
tiene como objetivo
Superando algunas de las limitaciones de OpenFlow (por ejemplo,
expresividad, soporte de protocolos definidos por el usuario, eficiencia de
memoria), a travs de conjuntos de instrucciones de flujo genrico. Los
prototipos de cdigo abierto estn disponibles [31] as como los resultados
de las evaluaciones que muestran las capacidades de velocidad de lnea
utilizando una implementacin de prueba de concepto de la unidad de
procesamiento de red (NPU) [453]. En esta lnea, ya mencionamos
OpenState [155], otra iniciativa que apunta a aumentar la capacidad y
flexibilidad de los dispositivos de reenvo. Tomando ventaja de eXtended
Finite State Machines (XFSMs) [454], [455], OpenState propone una
abstraccin como un super conjunto de primitivas OpenFlow para permitir el
manejo con estado de las reglas de OpenFlow dentro de los dispositivos de
reenvo. De la misma manera que los TTP permiten a los controladores
compilar el conjunto correcto de instrucciones de baja palanca conocidas
como soportadas por los conmutadores, una nueva generacin de
conmutadores denominada procesador de paquetes programable
independiente del protocolo (P4) [456] sugiere una evolucin Para
OpenFlow, basado en un compilador de alto nivel. Esta propuesta permitira
que la funcionalidad de los conmutadores programables (es decir, la
canalizacin, el anlisis del encabezado, la coincidencia de campos) no slo
fuera especificada por el controlador sino tambin cambiada en el campo.
En este modelo, los programadores son capaces de decidir cmo el plano de
reenvo procesa los paquetes sin preocuparse por detalles de
implementacin. Es entonces el compilador que transforma el programa
imperativo en un grfico de flujo de control que se puede asignar a
diferentes conmutadores de destino.
B. Plataformas del controlador En el modelo SDN, la plataforma del
controlador es un pilar crtico de la arquitectura y, como tal, se estn
dedicando esfuerzos para convertir los controladores SDN en dispositivos de
alto rendimiento, escalables, distribuidos, modulares y altamente
disponibles para programadores software. Las plataformas de controladores
distribuidos, en particular, tienen que abordar una variedad de desafos.
Merece especial consideracin la latencia entre los dispositivos de reenvo y
las instancias del controlador, la tolerancia a fallos, el equilibrio de carga, la
coherencia y la sincronizacin, entre otras cuestiones [7], [457], [458]. Los
operadores tambin deben ser capaces de observar y comprender cmo la
combinacin de diferentes funciones y mdulos pueden afectar su red
[459]. A medida que la comunidad SDN aprende de las experiencias de
desarrollo y operativas con los controladores OpenFlow (por ejemplo,
Beacon [186]), se esperan otros avances en trminos de rendimiento bruto
de las implementaciones del controlador, incluyendo la explotacin de
diseos jerrquicos y el tamao optimizado del buffer. Un enfoque para
aumentar el rendimiento de los controladores es el motor IRIS IO [461], lo
que permite aumentos significativos en la tasa de ajuste de flujo de los
controladores SDN. Otra forma de reducir la sobrecarga del plano de control
es mantener una copia comprimida de las tablas de flujo en la memoria del
controlador [462].
1) Modularidad y Flexibilidad: Una serie de esfuerzos de investigacin en
curso apuntan a la composicin modular y flexible de los controladores.
RAON [463] propone una abstraccin recursiva de los controladores
OpenFlow donde cada controlador ve a los controladores de abajo como
interruptores OpenFlow. Los temas de investigacin abiertos incluyen la
definicin de interfaces adecuadas entre las diferentes capas en tal
jerarqua de controladores. Otras cuestiones abiertas a investigar ms a
fondo en este contexto son las API orientadas hacia el este / oeste, y su uso
para permitir que los diseos jerrquicos adecuados alcancen la
escalabilidad, la modularidad y la seguridad [218]. Por ejemplo, cada nivel
de una jerarqua de controladores puede ofrecer diferentes abstracciones y
alcances para el enrutamiento de centro intradata e interdata, aumentando
as la escalabilidad y la modularidad. Del mismo modo, desde una
perspectiva de seguridad, cada nivel jerrquico puede ser una parte de un
dominio de confianza diferente. Por lo tanto, las interfaces este / oeste entre
las diferentes capas de controladores deben ser capaces de hacer cumplir
tanto las polticas de seguridad intradomain como interdomain. Otra
observacin importante es que, actualmente, la falta de modularidad en la
mayora de los controladores SDN obliga a los desarrolladores a
implementar de nuevo los servicios bsicos de red desde cero en cada
nueva aplicacin [29]. Al igual que en la ingeniera de software en general,
la falta de resultados de modularidad en las implementaciones de
controlador que son difciles de construir, mantener y extenderVent en
ltima instancia, se convierten en resistentes a nuevas innovaciones,
parecido a las redes tradicionales '' hardware definido. Tal como se ha
examinado en la Seccin IV-G, las abstracciones de programacin de SDN
(por ejemplo, Pyretic [225]) introducen modularidad en aplicaciones SDN y
simplifican su desarrollo en conjunto. Otros esfuerzos de investigacin (por
ejemplo, Corybantic [464]) tratan de lograr modularidad en los programas
de control SDN. Se pueden esperar otras contribuciones para lograr
controladores modulares de otras reas de la informtica (por ejemplo, los
principios del Sistema Operativo [196]) y las mejores prcticas de las
modernas aplicaciones de software a escala de nube.
2) Interoperabilidad y portabilidad de aplicaciones: Al igual que el
agnosticismo del proveedor de dispositivos de transporte que proviene de
interfaces estndar hacia el sur, es importante fomentar la interoperabilidad
entre controladores. Las primeras iniciativas hacia plataformas de control
ms interoperables incluyen lenguajes de programacin porttiles como
Pyretic [225] y las interfaces este / oeste entre controladores, como SDNi
[209], ForCES CE-CE interface [30], [211], y ForCES Intra-NE Mecanismos
[212]. Sin embargo, estos esfuerzos estn an lejos de realizar plenamente
la interoperabilidad del controlador y la portabilidad de las aplicaciones. En
contraste con Pyretic [248], PANE [197], Maple [263], y Corybantic [464],
que se restringen a las aplicaciones de ingeniera de trfico y / o imponer la
resolucin de conflictos de estado de red en el nivel de aplicacin , El
estadista [465] propone un marco para permitir que una variedad de
aplicaciones de red de acoplamiento suelto coexista en el mismo plano de
control sin comprometer la seguridad y el rendimiento de la red. Este marco
facilita el desarrollo de aplicaciones
Mediante la resolucin automtica y transparente de conflictos. En otras
palabras, el estadista permite una composicin segura de las acciones de
una aplicacin no coordinada o conflictiva. Otro enfoque reciente para
simplificar la gestin de la red es la idea de composicin SDN hypervisors
[181]. Su caracterstica principal es permitir que las aplicaciones escritas en
diferentes idiomas, o en diferentes plataformas, trabajen juntas en el
procesamiento del mismo trfico. El componente clave de integracin es un
conjunto de listas simples y priorizadas de reglas OpenFlow, que pueden ser
generadas por diferentes lenguajes de programacin o aplicaciones.
3) Alta disponibilidad: En la produccin, los controladores de SDN necesitan
sostener la operacin sana bajo presin de diversos objetivos de las
aplicaciones que reciben. Se requieren muchos avances para tratar con los
posibles vectores de riesgo de las soluciones basadas en el controlador
[359]. Ciertamente, muchas soluciones se aprovecharn de los resultados
de los sistemas distribuidos y las comunidades de seguridad realizadas
durante la ltima dcada. Por ejemplo, los esfuerzos recientes proponen
almacenes de datos tolerantes a fallos consistentes para construir
controladores distribuidos confiables [198], [213], [458]. Otro posible
enfoque hacia la construccin de baja latencia, alta disponibilidad SDN
controladores es explotar controlador localidad [457], [466]. Modelos
clsicos de sistemas distribuidos, como LOCAL y CONGEST [467], pueden
ser explorados para resolver este problema. Estos modelos pueden
utilizarse para desarrollar protocolos de coordinacin que permitan a cada
controlador tomar acciones independientes sobre eventos que tienen lugar
en su vecindario local [457]. Otro desafo fundamental se relaciona con los
equilibrios fundamentales entre el modelo de consistencia de la distribucin
estatal en los controladores SDN distribuidos, los requisitos de consistencia
de las aplicaciones de control y el rendimiento [466]. Para facilitar el
desarrollo, la aplicacin idealmente no debe ser consciente de los caprichos
del estado distribuido. Esto implica un fuerte modelo de consistencia, que se
puede lograr con los almacenes de datos distribuidos tal como se propuso
recientemente [213]. Sin embargo, mantener todos los datos de control en
un almacn de datos distribuido coherente es inviable debido a las
penalidades inherentes de rendimiento. Por lo tanto, es probable que las
soluciones hbridas coexistan requiriendo que los desarrolladores de
aplicaciones sean conscientes de las compensaciones y penalidades del uso,
o no, de un modelo de consistencia fuerte, un principio del controlador Onix
distribuido [7]. La alta disponibilidad tambin puede lograrse a travs de
mejoras API hacia el sur y heursticas de colocacin de controladores y
modelos formales [468] - [470]. Estos tienen como objetivo maximizar la
resiliencia y la escalabilidad permitiendo que los dispositivos de reenvo se
conecten a mltiples controladores de una manera rentable y eficiente
[469]. Los esfuerzos iniciales en esta direccin ya han demostrado que los
dispositivos de reenvo conectados a dos o tres controladores pueden
alcanzar tpicamente alta disponibilidad (hasta cinco nueves) y robustez en
trminos de conectividad de plano de control [468], [470]. Tambin se ha
demostrado que el nmero de controladores requeridos depende ms de la
topologa que del tamao de la red [468]. Otro hallazgo que vale la pena
mencionar es el hecho de que para la mayora de las topologas comunes y
tamaos de red menos de diez controladores parecen ser suficientes [468].
4) Delegacin de control: Para aumentar la eficiencia operativa, los
controladores SDN pueden delegar funciones de control a cambios de
estado de estado y de atributo de valor, alertas de cruce de umbral, fallas
de hardware, etc. Estas notificaciones normalmente siguen un modelo de
publicacin / suscripcin, es decir, los controladores y las aplicaciones se
suscriben (bajo demanda) a la clase particular de notificaciones que les
interesa. Adems, estos subsistemas pueden proporcionar propiedades de
resistencia y confiabilidad [471]. Algunas razones para delegar el control al
plano de datos incluyen [218]: respuesta de baja latencia a una variedad
de eventos de red; la cantidad de trfico que debe procesarse en el plano
de datos, en particular en redes de gran escala, tales como centros de
datos; Funciones de bajo nivel, tales como las (byte o bit orientado)
requeridas por la jerarqua digital sncrona repetitiva (SDH) [472] sobrecarga
de seccin mltiplex; Funciones bien comprendidas y estandarizadas,
como encriptacin, intercambio BIP [473], insercin AIS [474], aprendizaje
MAC y intercambio de mensajes de control de codec (CCM) [475]; la
tolerancia de fallo del controlador, es decir, las funciones de red esenciales
deben ser capaces de mantener una operacin de red bsica incluso cuando
los controladores estn inactivos; funciones bsicas de bajo nivel
normalmente disponibles en el plano de datos de silicio, como proteccin de
conmutacin de estado de mquinas, contadores CCM y temporizadores;
todas aquellas funciones que no agregan ningn valor cuando se mueven de
los datos al plano de control. Los candidatos fuertes para la ejecucin en los
dispositivos de reenvo en lugar de ser implementados en las plataformas
de control, incluyen OAM, procesamiento ICMP, aprendizaje MAC,
descubrimiento de vecinos, reconocimiento de defectos e integracin [218].
Esto no slo reducira la sobrecarga (trfico y clculo) del plano de control,
sino que tambin mejorara la eficiencia de la red al mantener funciones
bsicas de red en el plano de datos.
C. Resiliencia Lograr una comunicacin resiliente es un objetivo principal de
la creacin de redes. Como tal, se espera que los SDN produzcan los mismos
niveles de disponibilidad que el legado y cualquier nueva tecnologa
alternativa. Las arquitecturas de control dividido como SDN son
comnmente cuestionadas [476] acerca de su capacidad real de ser
resilientes a fallas que pueden comprometer las comunicaciones del plano
controlto-data y por lo tanto resultar en redes "sin cerebro". De hecho, el
mal funcionamiento de determinados elementos del SDN no debe resultar
en la prdida de disponibilidad. La reubicacin de la funcionalidad del plano
de control de SDN, desde el interior de las cajas a loci remoto, lgicamente
centralizado,
Es un desafo cuando se consideran las funciones crticas del plano de
control tales como las relacionadas con la deteccin de fallos de enlace o las
decisiones de reaccin rpida. La resistencia de una red OpenFlow depende
de la tolerancia a fallos en el plano de datos (como en las redes
tradicionales), pero tambin de la alta disponibilidad de las funciones de
plano de control (lgicamente) centralizadas. Por lo tanto, la resistencia de
SDN es un desafo debido a los mltiples fallos posibles de las diferentes
piezas de la arquitectura. Como se seala en [477], hay una falta de
suficiente investigacin y experiencia en la construccin y operacin
tolerante a fallos SDNs. Google B4 [8] puede ser uno de los pocos ejemplos
que han demostrado que SDN puede ser resistente a escala. Varios
esfuerzos relacionados [357], [262], [363], [478] - [483] han comenzado a
abordar las preocupaciones sobre las arquitecturas de plano de control de
divisin. Las arquitecturas de control distribuidas examinadas en la Seccin
IV-D son ejemplos de enfoques hacia plataformas de controlador SDN
resistentes con diferentes compensaciones en trminos de consistencia,
durabilidad y escalabilidad. En una discusin detallada sobre si el teorema
CAP [484] se aplica a las redes, Panda et al. [479] argumentan que los
tradeoffs en la construccin de bases de datos distribuidas consistentes,
disponibles y particionadas de particin (es decir, el teorema CAP) son
aplicables a SDN. El teorema CAP demuestra que es imposible que los
sistemas de almacenamiento de datos alcancen simultneamente una
consistencia fuerte, disponibilidad y tolerancia de particin. Si bien la
disponibilidad y los problemas de tolerancia de particin son similares tanto
en las bases de datos distribuidas como en las redes, el problema de la
coherencia en el SDN se relaciona con la aplicacin coherente de las
polticas. Teniendo en cuenta una red OpenFlow, cuando un switch detecta
un fallo de enlace (evento de puerto descendente), se enva una notificacin
al controlador, que toma las acciones requeridas (reroute computation,
bsqueda de ruta de copia de seguridad precargada) e instala entradas de
flujo actualizadas en el requisito Cambia para redirigir el trfico afectado.
Tales estrategias reactivas implican un tiempo de restauracin elevado
debido a la necesaria interaccin con el controlador y carga adicional en el
canal de control. Un trabajo experimental sobre OpenFlow para las redes de
grado portador investig el proceso de restauracin y midi una
restauracin veces en el orden de 100 ms [478]. El retraso introducido por el
controlador puede, en algunos casos, ser prohibitivo. Con el fin de satisfacer
los requisitos de grado de portador (por ejemplo, 50 ms de tiempo de
recuperacin), se requieren esquemas de proteccin para mitigar los efectos
de un plano de control separado. Los mecanismos de proteccin adecuados
(por ejemplo, la instalacin de trayectos de reserva preestablecidos en los
dispositivos de reenvo) se pueden implementar mediante entradas de tabla
de grupo de OpenFlow que utilizan acciones de 'fast-fail-over'. Un enfoque
de gestin de fallos de OpenFlow [357] similar a la proteccin de ruta global
MPLS tambin podra ser una solucin viable, siempre y cuando los
conmutadores OpenFlow se amplen con capacidades de supervisin de ruta
de extremo a extremo similares a las especificadas por la deteccin
bidireccional de reenvo [485] . Tales esquemas de proteccin son una
opcin de diseo crtico para redes de mayor escala y tambin pueden
requerir un espacio de flujo adicional considerable. Mediante el uso de pares
de rutas primarias y secundarias programadas como entradas de tabla de
grupo de conmutacin rpida OpenFlow, se ha informado un tiempo de
restauracin de ruta de 3,3 ms [486] utilizando sesiones BFD para detectar
rpidamente fallos de enlace. En una lnea relacionada de resiliencia de
plano de datos, SlickFlow [482] aprovecha la idea de usar el espacio de
encabezado de paquetes para transportar informacin de trayecto
alternativo para implementar enrutamiento de origen resiliente en redes
OpenFlow. Bajo la presencia de fallos a lo largo de una ruta primaria, los
paquetes pueden ser reencaminados a rutas alternativas por los propios
conmutadores sin implicar al controlador. Otra propuesta reciente que utiliza
informacin en paquetes es INFLEX [483], una arquitectura basada en SDN
para resiliencia de red de capas cruzadas que proporciona un fail-over de
ruta a peticin al tener puntos finales etiquetan paquetes con informacin
de plano de enrutamiento virtual que pueden ser utilizados por Salida para
redirigir cambiando las etiquetas sobre la deteccin del fallo. Similarmente a
SlickFlow, OSP [280] propone un enfoque de proteccin para la resiliencia
del plano de datos. Se basa en la proteccin de segmentos individuales de
un camino evitando la intervencin del controlador al fallar.
El tiempo de recuperacin depende del tiempo de deteccin del fallo, es
decir, unas pocas decenas de milisegundos en los escenarios propuestos. En
la misma direccin, estn empezando a aparecer otras propuestas para
habilitar mecanismos rpidos de fail-over para la proteccin y restauracin
de enlaces en redes basadas en OpenFlow [487]. Tambin se han propuesto
soluciones basadas en el lenguaje para el problema de tolerancia a errores
de plano de datos [262]. En este trabajo, los autores proponen un lenguaje
que compila expresiones regulares en las reglas de OpenFlow para expresar
lo que los paquetes de rutas de red pueden tomar y qu grado de tolerancia
a fallos (nivel de enlace) se requiere. Tales abstracciones alrededor de la
tolerancia a fallos permiten a los desarrolladores crear capacidades de
recuperacin de fallas en aplicaciones sin grandes esfuerzos de codificacin.
D. Escalabilidad La escalabilidad ha sido una de las principales
preocupaciones de los SDN desde el principio. Este es un problema que
debe ser abordado en cualquier sistema Vg., En las redes tradicionalesV y
es obviamente tambin una cuestin de mucha discusin en el contexto de
SDN [11]. La mayora de las preocupaciones de escalabilidad en SDNs estn
relacionadas con el desacoplamiento de los planos de control y datos. Son
de particular relevancia las configuraciones de red reactiva en las que el
primer paquete de un nuevo flujo es enviado por el primer elemento de
reenvo al controlador. El trfico adicional del plano de control aumenta la
carga de la red y hace que el plano de control sea un posible cuello de
botella. Adems, como las tablas de flujo de los conmutadores estn
configuradas en tiempo real por una entidad externa, tambin hay la
latencia adicional introducida por el proceso de configuracin de flujo. En las
redes a gran escala, los controladores debern ser capaces de procesar
millones de flujos por segundo [488] sin comprometer la calidad de su
servicio. Por lo tanto, estas sobrecargas en el plano de control y en la
latencia de la configuracin del flujo son (posiblemente) dos de las mayores
preocupaciones de escala en SDN.
Como resultado, se han dedicado varios esfuerzos a abordar las
preocupaciones de escala de SDN, incluyendo DevoFlow [418], SDCs [434],
DIFANE [489], Onix [7], HyperFlow [195], Kandoo [229], Maestro [188 ],
NOX-MT [187] y Maple [263]. An relacionado con la escalabilidad, la nocin
de elasticidad en los controladores SDN tambin se est persiguiendo [228],
[363], [481]. Los enfoques elsticos incluyen cambiar dinmicamente el
nmero de controladores y sus ubicaciones bajo diferentes condiciones
[490]. La mayora de los esfuerzos de investigacin que abordan las
limitaciones de escala de SDN pueden clasificarse en tres categoras: plano
de datos, plano de control e hbrido. Mientras que la orientacin del plano de
datos, propuestas tales como DevoFlow [418] y SDC [434] en realidad
reducir la sobrecarga del plano de control mediante la delegacin de
algunos trabajos a los dispositivos de reenvo. Por ejemplo, en lugar de
solicitar una decisin del controlador para cada flujo, los conmutadores
pueden identificar selectivamente los flujos (por ejemplo, flujos de
elefantes) que pueden necesitar decisiones de nivel superior desde las
aplicaciones de plano de control. Otro ejemplo es introducir CPUs de
propsito general ms potentes en los dispositivos de reenvo para habilitar
SDC. Una CPU de uso general y SDC ofrecen nuevas posibilidades para
reducir la sobrecarga del plano de control al permitir implementaciones
basadas en software de funciones para la agregacin y compresin de
datos, por ejemplo. Maestro [188], NOX-MT [187], Kandoo [229], Beacon
[186] y Maple [263] son ejemplos del esfuerzo en disear y desplegar
controladores de alto rendimiento, es decir, tratar de aumentar el
rendimiento del plano de control. Estos controladores exploran
principalmente tcnicas bien conocidas de redes, arquitecturas de
computadoras y computacin de alto rendimiento, tales como buffering,
pipeline y paralelismo, para aumentar el rendimiento de la plataforma de
control. La categora hbrida est compuesta de soluciones que tratan de
dividir las funciones de lgica de control entre dispositivos de plano de
datos especializados y controladores. En esta categora, DIFANE [489]
propone interruptores autoritativos (intermedios) para mantener todo el
trfico en el plano de datos, dirigido a un plano de control ms escalable y
eficiente.
Los conmutadores autoritativos son responsables de instalar reglas en los
conmutadores restantes, mientras que el controlador sigue siendo
responsable de generar todas las reglas requeridas por la lgica de las
aplicaciones. Al dividir el trabajo del controlador con estos interruptores
especiales, el sistema general se escala mejor. El Cuadro 12 proporciona
una lista no exhaustiva de propuestas que abordan las cuestiones de
escalabilidad de SDN. Caracterizamos estas cuestiones por el dominio de la
aplicacin (control o plano de datos), su propsito, el rendimiento en
trminos de nmero de flujos por segundo (cuando se informan los
resultados de los experimentos) y las estrategias utilizadas. Como se puede
observar, la gran mayora son soluciones de plano de control que tratan de
incrementar la escalabilidad usando arquitecturas distribuidas y multicore.
Algunas cifras son relativamente impresionantes, con algunas soluciones
alcanzando hasta 20 millones de flujos / s. Sin embargo, debemos advertir al
lector que las evaluaciones actuales consideran slo aplicaciones simples y
cuentan bsicamente el nmero de paquetes y paquetes de mensajes para
medir el rendimiento. El rendimiento real de los controladores se ver
afectado por otros factores, como el nmero y la complejidad de las
aplicaciones que se ejecutan en el controlador y los mecanismos de
seguridad implementados. Por ejemplo, un algoritmo de enrutamiento
consume ms recursos de computacin y necesita ms tiempo para
ejecutarse que una simple aplicacin de conmutador de aprendizaje.
Adems, las evaluaciones actuales se realizan utilizando conexiones TCP
simples. Es muy probable que el rendimiento cambie cuando se establezcan
mecanismos bsicos de seguridad, como TLS, o mecanismos ms
avanzados para evitar espionaje, interceptacin y ataques DoS en el plano
de control. Otra cuestin importante acerca de la escalabilidad es la
distribucin de datos entre las rplicas de controlador en arquitecturas
distribuidas. Las plataformas de control distribuidas se basan en
mecanismos de distribucin de datos para alcanzar sus objetivos. Por
ejemplo, controladores como Onix, HyperFlow y ONOS necesitan
mecanismos para mantener un estado consistente en la plataforma de
control distribuido. Recientemente, las evaluaciones experimentales han
demostrado que los almacenes de datos distribuidos y tolerantes a fallos de
alto rendimiento pueden utilizarse para abordar tales desafos [213]. No
obstante, es necesario seguir trabajando para comprender adecuadamente
las compensaciones de distribucin del Estado [466].
E. Evaluacin del Desempeo Como se presenta en la Seccin IV-A, ya hay
varias implementaciones OpenFlow de proveedores de hardware y software
que se estn desplegando en diferentes tipos de redes, desde pequeas
empresas hasta centros de datos a gran escala. Por lo tanto, se espera un
nmero creciente de experimentos sobre las redes habilitadas para SDN en
un futuro prximo. Esto naturalmente crear nuevos retos, ya que las
preguntas con respecto al desempeo y la escalabilidad del SDN an no han
sido debidamente investigadas. Comprender el rendimiento y la limitacin
del concepto de SDN es un requisito para su implementacin en las redes de
produccin. Hay muy pocos estudios de evaluacin de rendimiento de la
arquitectura OpenFlow y SDN. Aunque los estudios de simulacin y la
experimentacin estn entre las tcnicas de evaluacin de desempeo ms
utilizadas, el modelado analtico tambin tiene sus propios beneficios. Una
descripcin en forma cerrada de una arquitectura de red abre el camino
para que los diseadores de redes tengan una estimacin rpida (y
aproximada) del desempeo de su diseo, sin la necesidad de dedicar un
tiempo considerable a los estudios de simulacin oa una instalacin
experimental costosa [433]. Algunos trabajos han investigado formas de
mejorar el rendimiento de las capacidades de conmutacin en SDN. [492], la
aceleracin del hardware [439], la influencia de los tipos de reglas y
tamaos de paquetes [493], los cuellos de botella de rendimiento de las
implementaciones actuales de OpenFlow [418] , Cmo los ajustes reactivos
afectan el rendimiento en las redes de centros de datos [494], y el impacto
de la configuracin en los conmutadores OpenFlow [392].
Las opciones de diseo pueden tener un impacto significativo en el
rendimiento de bsqueda de la conmutacin de OpenFlow en el sistema
operativo Linux usando tarjetas de interfaz de red de productos estndar
[492]. Slo con el uso de hardware de red de productos bsicos, el
throughput de conmutacin de paquetes se puede mejorar hasta en un 25%
en comparacin con uno basado en la conmutacin suave de OpenFlow
[492]. Del mismo modo, la aceleracin de hardware basada en procesadores
de red tambin se puede aplicar para realizar conmutacin OpenFlow. En
tales casos, los primeros informes indican que el rendimiento, en trminos
de retardo de paquetes, se puede mejorar en un 20% en comparacin con
los diseos convencionales [439]. Utilizando la biblioteca DPDK de Intel
[450], se ha demostrado que es posible proporcionar una capacidad flexible
de direccin del trfico a nivel del hipervisor (por ejemplo, KVM) sin las
limitaciones de rendimiento impuestas por las tcnicas tradicionales de
conmutacin de hardware [495], como SR- IOV [496]. Esto es
particularmente relevante ya que la mayora de las implementaciones
empresariales actuales de SDN se encuentran en infraestructuras de centro
de datos virtualizadas, como en la solucin NVP de VMware [112]. Las
implementaciones de conmutadores OpenFlow actuales pueden conducir a
cuellos de botella de rendimiento con respecto a la carga de la CPU [418].
Sin embargo, las modificaciones en la especificacin del protocolo pueden
ayudar a reducir la ocurrencia de estos cuellos de botella. Otras
investigaciones proporcionan mediciones sobre el rendimiento del
conmutador OpenFlow para diferentes tipos de reglas y tamaos de
paquetes [493]. En los centros de datos, un ajuste reactivo de las reglas de
flujo puede conducir a un rendimiento inaceptable cuando slo un switch
OpenFlow maneja slo ocho conmutadores [494]. Esto significa que los
despliegues de SDN a gran escala probablemente no dependeran de un
"modus operandi" puramente reactivo, sino ms bien de una combinacin
de configuracin de flujo reactivo y proactivo. Para fomentar la evaluacin
de diferentes aspectos de rendimiento de los dispositivos OpenFlow, se han
propuesto marcos como OFLOPS [381], OFLOPS-Turbo [395], Cbench [187] y
OFCBenchmark [393]. Proporcionan un conjunto de herramientas para
analizar el rendimiento de los conmutadores y controladores OpenFlow.
Cbench [187], [392] es una herramienta de referencia desarrollada para
evaluar el rendimiento de los controladores OpenFlow. Aprovechando el
Cbench, es posible identificar mejoras de rendimiento para los controladores
OpenFlow basados en diferentes configuraciones de entorno y sistema, tales
como el nmero de dispositivos de reenvo, la topologa de red, la carga de
trabajo global de la red, el tipo de equipos, la complejidad de reenvo y la
sobrecarga de Ejecutndose las aplicaciones sobre los controladores [187].
Por lo tanto, estas herramientas pueden ayudar a los diseadores de
sistemas a tomar mejores decisiones con respecto al rendimiento de los
dispositivos y la red, al mismo tiempo que permite a los usuarios finales
medir el
El rendimiento del dispositivo y decidir mejor cul es el ms adecuado para
la infraestructura de red de destino. Sorprendentemente, a pesar de estar
diseado para evaluar el rendimiento de los controladores, Cbench es
actualmente una herramienta de un solo tema. Por lo tanto, se deben iniciar
varias instancias para utilizar varias CPU. Tambin establece una sola
conexin de controlador para todos los conmutadores emulados. Por
desgracia, esto significa que poco se puede derivar de los resultados en
trminos de rendimiento del controlador y el comportamiento o estimacin
de diferentes lmites en el momento. Por ejemplo, las estadsticas agregadas
se recopilan para todos los conmutadores, pero no para cada conmutador
individual. Como resultado, no es posible identificar si todas las respuestas
del controlador son para un nico conmutador, o si la capacidad del
controlador se comparte realmente entre los conmutadores. Sin embargo,
los benchmarks flexibles del controlador OpenFlow estn disponibles.
OFCBenchmark [393] es uno de los acontecimientos recientes. Crea un
conjunto de conmutadores virtuales que generan mensajes, que pueden
configurarse independientemente unos de otros para emular un escenario
especfico y mantener sus propias estadsticas. Otra cuestin interesante
que se plantea al evaluar el rendimiento de las arquitecturas SDN es cul es
el nmero necesario de controladores para una determinada topologa de
red y dnde colocar los controladores [469], [497]. Al analizar el rendimiento
de los controladores en diferentes topologas de red, es posible concluir que
un controlador es a menudo suficiente para mantener la latencia a un ritmo
razonable [497]. Adems, como se observa en los mismos experimentos, en
el caso general la adicin de k controladores a la red puede reducir la
latencia por un factor de k. Sin embargo, hay casos, tales como redes de
gran escala y WANs, donde se deben desplegar ms controladores para
lograr una alta confiabilidad y una baja latencia del plano de control.
Estudios recientes tambin muestran que el plano de control SDN no puede
ser totalmente fsicamente centralizado debido a la capacidad de respuesta,
fiabilidad y escalabilidad mtricas [466], [469]. Por lo tanto, los
controladores distribuidos son la eleccin natural para crear un plano de
control lgicamente centralizado, al tiempo que son capaces de hacer frente
a las demandas de las redes a gran escala. Sin embargo, los controladores
distribuidos plantean desafos adicionales, como la consistencia de la vista
de red global, que puede afectar significativamente el rendimiento de la red
si no se ha diseado cuidadosamente. Tomando dos aplicaciones como
ejemplos, una que ignora las inconsistencias y otra que toma inconsistencia
en la consideracin, es posible observar que la optimalidad es afectada
perceptiblemente cuando las inconsistencias no se consideran y que la
robustez de una aplicacin se aumenta cuando el regulador est enterado
de la red Distribucin estatal [466]. La mayora de estas iniciativas para
identificar las limitaciones y los cuellos de botella de las arquitecturas SDN
pueden tomar mucho tiempo y esfuerzo para producir resultados
consistentes debido a los requisitos prcticos de desarrollo y
experimentacin. Como se mencion anteriormente, los modelos analticos
pueden proporcionar rpidamente indicadores de rendimiento y
escalabilidad potencial
Cuellos de botella para un sistema de controlador de conmutacin OpenFlow
antes de disponer de datos detallados. Si bien la simulacin puede
proporcionar una visin detallada de una determinada configuracin, el
modelo analtico simplifica en gran medida una decisin de implementacin
conceptual. Por ejemplo, se puede utilizar un modelo basado en clculo de
red para evaluar el rendimiento de un conmutador SDN y la interaccin de
los conmutadores y controladores SDN [498]. El modelo de conmutador SDN
propuesto captur la forma cerrada del retardo de paquete y la longitud del
buffer dentro del conmutador SDN de acuerdo con los parmetros de un
proceso de llegada acumulativo. Mediante las mediciones recientes, los
autores han reproducido el retardo de procesamiento de paquetes de dos
variantes de conmutadores OpenFlow y han calculado los requisitos de
memoria intermedia de un controlador OpenFlow. Los modelos analticos
basados en la teora de colas para la velocidad de reenvo y la probabilidad
de bloqueo de interruptores OpenFlow actuales tambin se pueden usar
para estimar el rendimiento de la red [492].
F. Seguridad y fiabilidad Los ataques cibernticos contra instituciones
financieras, instalaciones energticas, dependencias gubernamentales e
instituciones de investigacin se estn convirtiendo en una de las
principales preocupaciones de los gobiernos y organismos de todo el mundo
[499] - [504]. Diferentes incidentes, como Stuxnet [503], ya han demostrado
la persistencia de los vectores de amenaza [505]. Dicho de otra manera,
estos ataques son capaces de daar la amplia infraestructura de una
nacin, lo que representa un problema significativo y preocupante. Como
era de esperar, uno de los medios ms comunes de ejecutar esos ataques
es a travs de la red, ya sea Internet o la red de rea local.
Se puede utilizar como una simple infraestructura de transporte para el
ataque o como un arma potencializada para amplificar el impacto del
ataque. Por ejemplo, las redes de alta capacidad pueden utilizarse para
lanzar ataques a gran escala, aunque el atacante slo tiene una conexin de
red de baja capacidad en sus instalaciones. Debido al peligro de los ataques
cibernticos y al actual panorama de las amenazas digitales, la seguridad y
la fiabilidad son las principales prioridades de SDN. Mientras que la
investigacin y la experimentacin en SDNs est siendo conducida por
algunos jugadores comerciales (por ejemplo, Google, Yahoo !, Rackspace,
Microsoft), la adopcin comercial todava est en su etapa temprana. Los
expertos de la industria creen que la seguridad y la fiabilidad son cuestiones
que necesitan ser abordadas y investigadas en SDN [359], [506], [507].
Adems, desde la perspectiva de la fiabilidad, la disponibilidad de
enrutadores de Internet es hoy una preocupacin importante con la
generalizacin de las nubes y sus fuertes expectativas sobre la red [508].
Por lo tanto, es crucial para alcanzar altos niveles de disponibilidad en las
plataformas de control SDN si se van a convertir en los pilares principales de
las aplicaciones en red [468]. Varios vectores de amenaza ya han sido
identificados en SDN arquitecturas [359], as como varias cuestiones de
seguridad y debilidades en OpenFlow basado en redes [194], [201], [509] -
[514]. Aunque algunos vectores de amenaza son comunes a las redes
existentes, otros son ms especficos de SDN, como ataques a la
comunicacin de plano de control y controladores lgicamente
centralizados. Vale la pena mencionar que la mayora de los vectores de
amenazas son independientes de la tecnologa o el protocolo (por ejemplo,
OpenFlow, POF y ForCES), porque representan amenazas en capas
conceptuales y arquitectnicas de SDN. Como se muestra en la Fig. 10 y la
Tabla 13, hay al menos siete identificados vector amenazas en SDN
arquitecturas. El primer vector de amenaza consiste en flujos de trfico
forjados o falsificados en el plano de datos, que pueden usarse para atacar
dispositivos de reenvo y controladores. El segundo permite a un atacante
explotar las vulnerabilidades de los dispositivos de reenvo y
consecuentemente causar estragos en la red. Los vectores de amenaza tres,
cuatro y cinco son los ms peligrosos, ya que pueden comprometer la
operacin de la red. Los ataques en el plano de control, controladores y
aplicaciones pueden conceder fcilmente a un atacante el control de la red.
Por ejemplo, un controlador o aplicacin defectuosa o maliciosa podra
utilizarse para reprogramar toda la red con fines de robo de datos, por
ejemplo, en un centro de datos. El sexto vector de amenaza est vinculado
a ataques y vulnerabilidades en las estaciones administrativas. Un
ordenador crtico comprometido, conectado directamente a la red de
control, habilitar al atacante Con recursos para lanzar ms fcilmente un
ataque al controlador, por ejemplo. Por ltimo, el vector de amenaza
nmero siete representa la falta de recursos confiables para forenses y
remediacin, lo que puede comprometer las investigaciones (por ejemplo, el
anlisis forense) y evitar modos de recuperacin rpidos y seguros para
llevar la red de vuelta a una condicin de operacin segura. Como se puede
observar en la Tabla 13, los vectores de amenaza 3 a 5 son especficos de
SDN, ya que provienen de la separacin de los planos de control y de datos
y de la consiguiente introduccin de una nueva entidad en estas redes de
control lgicamente centralizado. Los otros vectores ya estaban presentes
en las redes tradicionales. Sin embargo, el impacto de estas amenazas
podra ser mayor que el de hoy, o por lo menos puede expresarse de
manera diferente. Por consiguiente, puede que tenga que tratarse de
manera diferente. Las redes OpenFlow estn sujetas a una variedad de
problemas de seguridad y confiabilidad, tales como spoofing [509],
alteracin [509], repudiacin [509], divulgacin de informacin [509],
denegacin de servicio [509], [511], [512] Elevacin de privilegios [509], y
la suposicin de que todas las solicitudes son benignas y no afectar a la
operacin SDN [194]. La falta de aislamiento, proteccin, control de acceso
y recomendaciones de seguridad ms fuertes [194], [201], [510] - [512] son
algunas de las razones de estas vulnerabilidades. Exploraremos estos
prximos.
1) Evaluacin de seguridad de OpenFlow: Ya hay una serie de problemas de
seguridad identificados en las redes habilitadas para OpenFlow. Partiendo de
una metodologa STRIDE [515], es posible identificar diferentes ataques a
redes habilitadas para OpenFlow. La Tabla 14 resume estos ataques (basado
en [509]). Por ejemplo, la divulgacin de informacin puede lograrse
mediante ataques de canal lateral dirigidos al proceso de configuracin de
la regla de flujo. Cuando la configuracin del flujo reactivo est en su lugar,
la obtencin de informacin sobre el funcionamiento de la red es
relativamente fcil. Un atacante que mide el retardo experimentado por el
primer paquete de un flujo y el siguiente puede deducir fcilmente que la
red de destino es un SDN reactivo y proceder con un ataque especializado.
Este ataque puede ser el primer paso para lanzar un ataque de DoS
destinado a agotar los recursos de la red, por ejemplo. Si el SDN es
proactivo, adivinar sus polticas de reglas de reenvo es ms difcil, pero an
factible [509]. Enterrar
Todas las amenazas y ataques reportados afectan a todas las versiones (1.0
a 1.3.1) de la especificacin de OpenFlow. Tambin vale la pena enfatizar
que algunos ataques, como el spoofing, no son especficos de SDN. Sin
embargo, estos ataques pueden tener un mayor impacto en SDNs. Por
ejemplo, al falsificar la direccin del controlador de red, el atacante (usando
un controlador falso) podra asumir el control de toda la red. Un ataque
inteligente podra persistir durante slo unos segundos, es decir, slo el
tiempo necesario para instalar reglas especiales en todos los dispositivos de
reenvo con fines maliciosos (por ejemplo, clonacin de trfico). Tal ataque
podra ser muy difcil de detectar. Tomando contra falsificacin como otro
ejemplo, un atacante puede tratar de adivinar las reglas de flujo instaladas
y, posteriormente, forjar paquetes para aumentar artificialmente el
contador. Este ataque sera especialmente crtico para sistemas de
facturacin y balanceo de carga, por ejemplo. Un cliente podra ser cobrado
por ms trfico que ella, de hecho utilizado, mientras que un algoritmo de
equilibrio de carga puede tomar decisiones no ptimas debido a contadores
forjados.
Las redes de flujo incluyen la falta de fuertes recomendaciones de seguridad
para los desarrolladores, la falta de TLS y el soporte de control de acceso en
la mayora de las implementaciones de switches y controladores [510], la
creencia de que TCP es suficiente porque los enlaces son fsicamente
seguros [510] 512], el hecho de que muchos conmutadores tienen el modo
de escucha activado de forma predeterminada (lo que permite establecer
conexiones TCP malintencionadas, por ejemplo) [512] o que las capacidades
de verificacin de la tabla de flujo son ms difciles de implementar cuando
TLS no est en uso [260] 510]. Vale la pena mencionar tambin el alto
riesgo de denegacin de servicio que plantea a los controladores
centralizados [260], [511], as como las vulnerabilidades de los propios
controladores [260], [359], bugs y vulnerabilidades en las aplicaciones [516]
Ataques de inundacin dirigidos [16], interfaces inseguras hacia el norte que
pueden conducir a brechas de seguridad [16], y el riesgo de ataques de
agotamiento de recursos [511], [512]. Por ejemplo, se ha demostrado que
un atacante puede fcilmente comprometer las comunicaciones del plano
de control a travs de ataques DoS y lanzar un ataque de agotamiento de
recursos en las plataformas de control explotando una sola aplicacin, como
un conmutador de aprendizaje [511], [512]. Otro punto de preocupacin es
el hecho de que los controladores actuales, como Floodlight, OpenDaylight,
POX y Beacon, tienen varios problemas de seguridad y resiliencia [194].
Problemas comunes de desarrollo de aplicaciones (errores), como la salida
repentina de una aplicacin o la asignacin continua de espacio de
memoria, son suficientes para bloquear los controladores existentes. Desde
el punto de vista de la seguridad, una simple accin maliciosa, como
cambiar el valor de una estructura de datos en la memoria, tambin puede
afectar directamente el funcionamiento y la fiabilidad de los controladores
actuales. Estos ejemplos son ilustrativos de que, desde una perspectiva de
seguridad y confiabilidad, todava hay un largo camino por recorrer.
2) Contramedidas para SDN basadas en OpenFlow: Pueden implementarse
varias contramedidas para mitigar las amenazas de seguridad en SDNs. La
Tabla 15 resume una serie de contramedidas que se pueden aplicar a
diferentes elementos de una red habilitada para SDN / OpenFlow. Algunas
de estas medidas, a saber, la limitacin de velocidad, el filtrado de eventos,
la reduccin de paquetes, los tiempos de espera ms cortos y la agregacin
de flujo, ya se recomiendan en las versiones ms recientes de la
especificacin OpenFlow (versin 1.3.1 y posteriores). Sin embargo, la
mayora de ellos an no estn soportados o implementados en
implementaciones SDN. Las tcnicas tradicionales como el control de
acceso, los mecanismos de deteccin de ataques, el filtrado de eventos (por
ejemplo, el controlador decide qu mensajes asncronos no va a aceptar),
los cortafuegos y los sistemas de deteccin de intrusos pueden utilizarse
para mitigar el impacto o evitar ataques. Pueden implementarse en
diferentes dispositivos, como controladores, dispositivos de reenvo, cajas
de medio, etc. Las cajas de medio pueden ser una buena opcin para hacer
cumplir las polticas de seguridad en una empresa porque son (en general)
dispositivos ms robustos y de propsito especial (alto rendimiento). Dicha
estrategia tambin reduce el potencial de gastos indirectos al implementar
estas contramedidas directamente en los controladores o dispositivos de
reenvo. Sin embargo, las middleboxes pueden aadir complejidad adicional
a la gestin de red, es decir, aumentar el OPEX a costa de un mejor
rendimiento.
Limitacin de velocidad, cada de paquetes, tiempos de espera ms cortos y
agregaciones de flujo son tcnicas que se pueden aplicar a controladores y
dispositivos de reenvo para mitigar diferentes tipos de ataques, como la
denegacin de servicio y la divulgacin de informacin. Por ejemplo, se
pueden utilizar tiempos de espera reducidos para mitigar el efecto de un
ataque explorando el modo de funcionamiento reactivo de la red para hacer
que el controlador instale reglas que desvan el trfico a una mquina
malintencionada. Con tiempos de espera reducidos, el atacante se vera
obligado a generar constantemente una serie de paquetes forjados para
evitar la caducidad, lo que hace que el ataque sea ms probable que se
detecte.
La limitacin de velocidad y la reduccin de paquetes pueden aplicarse para
evitar ataques de DoS en el plano de control o detener ataques en curso
directamente en el plano de datos instalando reglas especficas en los
dispositivos donde se originan los ataques. Los forenses y la remediacin
abarcan mecanismos tales como registro seguro, correlacin de eventos y
reportes consistentes. Si sucede algo malo con la red, los operadores deben
ser capaces de averiguar con seguridad la causa raz del problema y poner
la red a trabajar en un modo de operacin seguro lo ms rpido posible.
Adems, las tcnicas para tolerar fallas e intrusiones, como la replicacin de
mquinas de estado [517], recuperacin reactiva proactiva [518] y
diversidad [210], pueden agregarse a plataformas de control para aumentar
las propiedades de robustez y seguridad al enmascarar y eliminar
automticamente Fallas En otras palabras, los controladores SDN deben ser
capaces de resistir contra diferentes tipos de eventos (por ejemplo, cortes
de energa, interrupciones de la red, fallos de comunicacin, particiones de
red) y ataques (por ejemplo, DDoS, agotamiento de recursos) [213], [359].
Una de las maneras ms tradicionales de lograr alta disponibilidad es a
travs de la replicacin. Sin embargo, la recuperacin reactiva-reactiva y la
diversidad son dos ejemplos de tcnicas cruciales que agregan valor al
sistema para resistir contra diferentes tipos de ataques y fracasos (por
ejemplo, aquellos que exploran vulnerabilidades comunes o causados por
problemas de envejecimiento del software). Otras medidas para abordar
diferentes amenazas y problemas de SDN incluyen mejorar la seguridad y
fiabilidad de los controladores, la proteccin y el aislamiento de las
aplicaciones [359], [201], [359], [506], la gestin de confianza entre
controladores y dispositivos de reenvo [359 ], Controles de integridad de
controladores y aplicaciones [359], forenses y remediacin [359], [506],
marcos de verificacin [201], [519], [520] y planos de control resilientes
[359], [506], [ 521], [520]. Los mecanismos de proteccin y aislamiento
deben ser parte de cualquier controlador. Las aplicaciones deben aislarse
entre s y desde el controlador. Se deben implementar diferentes tcnicas
como dominios de seguridad (por ejemplo, kernel, seguridad y nivel de
usuario) y mecanismos de proteccin de acceso a datos para evitar
amenazas a la seguridad de las aplicaciones de red. La implementacin de
confianza entre controladores y reenvo es otro requisito para asegurar que
los elementos maliciosos no pueden daar la red sin ser detectados. Un
atacante puede intentar falsificar la direccin IP del controlador y hacer que
los switches se conecten a su propio
controlador. Esto es actualmente el caso ya que la mayora de los
controladores y switches slo establecen conexiones TCP inseguras. Las
comprobaciones de integridad complementarias en el controlador y el
software de aplicacin pueden ayudar a asegurar que se est arrancando
cdigo seguro, lo que elimina el software daino que se inicia una vez que el
sistema se reinicia. Adems de los controles de integridad, se deben
desarrollar otras cosas tales como sistemas altamente especializados de
deteccin de malware para SDN. Las aplicaciones de red de terceros
siempre deben ser escaneadas por cdigo malo y vulnerabilidades debido a
que una aplicacin malintencionada representa una amenaza de seguridad
significativa para la red. Cabe mencionar que tambin existen otros
enfoques para mitigar las amenazas de seguridad en SDN, como los
lenguajes declarativos para eliminar las vulnerabilidades del protocolo de
red [265]. Este tipo de lenguajes descriptivos pueden especificar
restricciones semnticas, restricciones estructurales y propiedades de
acceso seguro de los mensajes de OpenFlow.
Entonces, un compilador puede usar estas entradas para encontrar errores
de implementacin de los programadores en las operaciones de los
mensajes. En otras palabras, tales lenguajes pueden ayudar a eliminar las
vulnerabilidades de implementacin de las especificaciones hacia el sur.
Comienzan a aparecer propuestas que proporcionan propiedades bsicas de
seguridad, como la autenticacin [522] y el control de acceso [523]. C-BAS
[522] es una arquitectura de autenticacin, autorizacin y contabilidad
basada en certificados (AAA) para mejorar el control de seguridad en las
instalaciones experimentales de SDN. Las soluciones en el espritu de C-BAS
se pueden hacer altamente seguras y confiables a travs de arquitecturas
de sistemas hbridos, que combinan diferentes tecnologas y tcnicas de
sistemas distribuidos, seguridad, tolerancia a fallos e intrusos [524] - [526].
G. Migracin e implementaciones hbridas Las promesas de SDN de ofrecer
un diseo, operacin y administracin ms fcil de las redes de
computadoras estn en peligro debido a desafos relacionados con la
despliegue incremental, robustez y escalabilidad. Un reto primordial de
adopcin del SDN se relaciona con las barreras organizacionales que pueden
surgir debido a los efectos del primer (y el segundo) orden de las
capacidades de automatizacin del SDN y el "desdibujamiento de capa /
dominio". Se puede esperar cierto nivel de resistencia humana y puede
afectar la decisin Y los procesos de despliegue de SDN, especialmente por
aquellos que pueden considerar la refactorizacin de control de SDN como
un riesgo para la actual cadena de control y mando, o incluso para su
seguridad laboral. Este desafo social complejo es similar (y potencialmente
ms grande) a problemas conocidos entre las divisiones de transporte y red
IP de los proveedores de servicios, o el administrador del sistema,
almacenamiento, redes y equipos de seguridad de las organizaciones
empresariales. Este desafo es observable en los centros de datos
virtualizados de hoy en da, a travs del cambio en el papel y el poder de
decisin entre las personas de redes y servidores. Del mismo modo, el
movimiento de desarrollo y operaciones (DevOps) ha causado un cambio en
el lugar de influencia, no slo en la arquitectura de la red sino tambin en la
compra, y este es un efecto que SDN puede exacerbar. Estos cambios en el
rol y el poder causan un
En la divisin de ventas de los vendedores que estn obligados a adaptarse
en consecuencia. Pioneros despliegues operacionales de SDN han sido
principalmente escenarios de greenfield y / o dominios administrativos
nicos estrechamente controlados. Las estrategias de despliegue inicial se
basan principalmente en modelos de superposicin de conmutadores
virtuales o controles de toda la red de OpenFlow. Sin embargo, una adopcin
ms amplia de SDN ms all de los silos de centro de datos y entre ellos
mismos requiere considerar la interaccin e integracin con los planos de
control heredados que proporcionan conmutacin tradicional; enrutamiento;
Y funciones de operacin, administracin y administracin (OAM).
Ciertamente, rip-and-replace no es una estrategia viable para la amplia
adopcin de nuevas tecnologas de redes. La creacin de redes hbridas en
SDN debe permitir el despliegue de OpenFlow para un subconjunto de todos
los flujos, habilitar OpenFlow en un subconjunto de dispositivos y / o puertos
nicamente y proporcionar opciones para interactuar con protocolos OAM
existentes, dispositivos heredados y dominios vecinos. Como en cualquier
perodo de transicin tecnolgica en el que las actualizaciones de
montacargas pueden no ser una opcin para muchos, los caminos de
migracin son crticos para la adopcin. La red hbrida en SDN abarca varios
niveles. El Grupo de Trabajo de Migracin de la ONF est abordando el
escenario donde coexisten arquitecturas de conmutadores hbridos y
dispositivos hbridos (OpenFlow y no OpenFlow). Los conmutadores hbridos
pueden configurarse para comportarse como un conmutador heredado o
como un conmutador OpenFlow y, en algunos casos, como ambos
simultneamente.
Esto puede lograrse, por ejemplo, particionando el conjunto de puertos de
un conmutador, donde un subconjunto est dedicado a redes controladas
por OpenFlow y el otro subconjunto a redes heredadas. Para que estos
subconjuntos estn activos al mismo tiempo, cada uno que tiene su propio
plano de datos, soporte multitable en el motor de reenvo (por ejemplo, a
travs de particin TCAM) es requerido. Adems del particionamiento
basado en puertos, tambin es posible confiar en VLAN (antes de entrar en
la tubera de OpenFlow) o particin basada en flujo usando coincidencias de
OpenFlow y las acciones LOCALES y / o NORMALES para redirigir paquetes a
la tubera heredada o al switch Pila de red local y su pila de gestin. La
particin basada en flujo es la opcin ms flexible, ya que permite que cada
paquete que ingresa un switch sea clasificado por una descripcin de flujo
de OpenFlow y tratado por el plano de datos apropiado (OpenFlow o
heredado). Existen diversos controladores, como OpenDaylight [13], HP VAN
SDN [184] y OpenContrail [183], que han sido diseados para integrar
tecnologas actuales no SDN (por ejemplo, SNMP, PCEP, BGP y NETCONF)
con SDN Interfaces como OpenFlow y OVSDB. Sin embargo, se han
propuesto recientemente controladores como ClosedFlow [219] con el
objetivo de introducir capacidades de programacin similares a las SDN en
las infraestructuras de red tradicionales, haciendo realidad la integracin de
las redes heredadas y SDN sin efectos secundarios en trminos de
programacin y red global controlar. ClosedFlow est diseado para
controlar dispositivos heredados de Ethernet (por ejemplo, conmutadores
Cisco 3550 con un IOS mnimo de 12,2 SE) de manera similar al controlador
OpenFlow que permite a los administradores controlar los dispositivos
habilitados para OpenFlow. Ms importante an, ClosedFlow no impone
ningn cambio en los dispositivos de reenvo. Slo aprovecha las
capacidades existentes de hardware y firmware para imitar un control SDN
sobre la red, es decir, permite una programacin dinmica y flexible en el
plano de datos. El siguiente paso podra ser la integracin de controladores
como los controladores basados en ClosedFlow y OpenFlow, promoviendo la
interoperabilidad entre los controladores y una transicin suave de las
infraestructuras heredadas a la infraestructura SDN habilitada con casi
todas las capacidades de una infraestructura habilitada SDN. Adems, los
controladores pueden tener que ser separados en distintos dominios pares
por diferentes razones, tales como escalabilidad, tecnologa, controladores
de diferentes proveedores, controladores con diferentes funcionalidades de
servicio y diversidad de dominios administrativos [218]. Tambin se requiere
que los controladores de diferentes dominios o con propsitos distintos sean
compatibles con versiones anteriores, ya sea mediante la adaptacin o
ampliacin de protocolos de multidominio existentes (por ejemplo, BGP) o
proponiendo nuevos protocolos SDN a SDN (tambin conocidos como APIs
de este / oeste). Algunos esfuerzos ya se han dedicado a los retos de la
migracin y los SDN hbridos. RouteFlow [527] implementa un plano de
control de nivel IP encima de una red OpenFlow, permitiendo que los
dispositivos subyacentes acten como routers IP bajo diferentes arreglos
posibles.
El proyecto Cardigan [50], [528] ha desplegado RouteFlow en un
intercambio de Internet en vivo ahora por ms de un ao. LegacyFlow [529]
extiende la red controlada basada en OpenFlow para abarcar los nodos que
no son OpenFlow. Tambin hay algunos otros casos de uso temprano en la
integracin de complejos sistema heredado, como DOCSIS [161], Gigabit
Ethernet de red ptica pasiva, y DWDM reconfigurable optical add / drop
multiplexor (ROADM) [157], [158]. Las bases comunes de estos trabajos son:
1) considerar hbrido como la coexistencia de entornos tradicionales de
enrutadores y conmutadores de proveedores cerrados con nuevos
dispositivos habilitados para OpenFlow; 2) dirigirse a la interconexin tanto
de los planos de control como de los datos de los elementos heredados y
nuevos de la red; Y 3) tomar un enfoque control-centrgrico, dibujando la
lnea hbrida fuera de cualquier dispositivo en s, pero en el espacio de
aplicacin del controlador. Panopticon [530] define una arquitectura y una
metodologa para implementar consistentemente SDN dentro de las redes
heredadas de la empresa a travs de la orquestacin de la red bajo estrictas
restricciones presupuestarias. La arquitectura propuesta incluye
configuraciones de polticas, solucin de problemas y tareas de
mantenimiento que establecen redes de transicin (SDN y legacy) en
estructuras denominadas rboles de confinamiento solitario (SCT), donde
los ID de VLAN son utilizados eficientemente por algoritmos de orquestacin
para construir caminos para dirigir el trfico a travs de conmutadores
SDN . Desafiando el concepto de implementacin parcial de SDN, confirman
que sta podra ser una solucin de estrategia operacional a largo plazo
para redes empresariales. HybNET [531] presenta un marco de gestin de
red para las redes hbridas OpenFlow-legacy. Proporciona un
Interfaz de configuracin centralizada comn para construir redes virtuales
que utilizan VLAN. Una abstraccin de la topologa de red fsica se tiene en
cuenta por un controlador centralizado que aplica un mecanismo de
bsqueda de trayecto, para calcular rutas de red y programar los
conmutadores OpenFlow a travs de interfaces REST y dispositivos
heredados utilizando NETCONF [44]. Ms recientemente, marcos tales como
ESCAPE [532] y sus extensiones se han propuesto para proporcionar la
orquestacin de servicios multicapa en multidominios. Tales marcos
combinan diferentes herramientas y tecnologas como Click [533], POX
[231], OpenDaylight [13] y NETCONF [44]. En otras palabras, estos marcos
integran diferentes soluciones SDN con las tradicionales. Por lo tanto,
pueden ser herramientas tiles en el proceso de integracin o migracin de
la infraestructura de red heredada a SDN. Otras soluciones hbridas que
comienzan a emerger incluyen hbrido de cdigo abierto IP / SDN (OSHI)
[534]. OSHI combina Quagga para el enrutamiento de ruta ms corta
abierta y dispositivos de conmutacin con capacidades SDN (por ejemplo,
Open vSwitch) en Linux para proporcionar compatibilidad hacia atrs para
soportar despliegues incrementales de SDN, es decir, permitir la
interoperabilidad con dispositivos de reenvo no OF en redes de grado
portador. Mientras que los despliegues de SDN completos son sencillos slo
en algunos despliegues de campo verde como redes de centros de datos o
mediante un enfoque de modelo de superposicin, los enfoques de SDN
hbridos representan un modelo de despliegue muy probable que puede
perseguirse por diferentes medios, incluyendo los siguientes [535].
HybridSDN basado en topologa: Basado en la separacin noatopolgica de
los nodos controlados por paradigmas tradicionales y de SDN.
La red est dividida en diferentes zonas y cada nodo pertenece a una sola
zona. SDN hbrido basado en servicios: Las redes convencionales y SDN
proporcionan diferentes servicios, donde superponen nodos, controlando
una parte diferente de la FIB (o tabla de flujo generalizada) de cada nodo.
Algunos ejemplos son los servicios de toda la red, como el reenvo que
puede basarse en el control distribuido heredado, mientras que SDN
proporciona servicios de punta a punta, como la aplicacin de polticas de
ingeniera de trfico y acceso, o servicios que requieren visibilidad total del
trfico. SDN hbrido basado en clases: basado en la particin del trfico en
las clases, algunas controladas por SDN y el resto por protocolos heredados.
Mientras que cada paradigma controla un conjunto disjunto de entradas de
reenvo de nodos, cada paradigma es responsable de todos los servicios de
red para las clases de trfico asignadas. SDN hbrido integrado: un modelo
en el que SDN es responsable de todos los servicios de red y utiliza
protocolos tradicionales (por ejemplo, BGP) como interfaz para FIB de nodo.
Por ejemplo, puede controlar rutas de reenvo inyectando rutas
cuidadosamente seleccionadas en un sistema de enrutamiento o ajustando
configuraciones de protocolo (por ejemplo, pesos de IGP). Los esfuerzos
pasados en RCP [85] y los esfuerzos en curso dentro de ODL [13] pueden ser
considerados ejemplos de este modelo hbrido. En general, los beneficios de
los enfoques hbridos incluyen flexibilidad de habilitacin (por ejemplo,
combinacin fcil en los campos de paquetes para la caja intermedia) y
caractersticas especficas de SDN (por ejemplo, interfaz de administracin
declarativa), manteniendo parcialmente las caractersticas heredadas de
redes convencionales tales como robustez, escalabilidad, madurez
tecnolgica , Y bajos costos de implementacin. En el lado negativo, los
inconvenientes de la hibridacin incluyen la necesidad de asegurar
interacciones provechosas entre los paradigmas de redes (SDN y
tradicionales) al tratar con la heterogeneidad que depende en gran medida
del modelo. Los anlisis de tradeoff iniciales [535] sugieren que la
combinacin de paradigmas centralizados y distribuidos puede proporcionar
beneficios mutuos. Sin embargo, se requiere trabajo futuro para idear
tcnicas y mecanismos de interaccin que maximicen tales beneficios,
limitando al mismo tiempo la complejidad aadida de la coexistencia
paradigmtica.
H. Cumplimiento de los requisitos de la categora de portador y de la nube
Una serie de proveedores de infraestructuras de grado de transportista (por
ejemplo, NTT, AT & T, Verizon y Deutsche Telekom) estn en el centro de la
comunidad de SDN con el objetivo final de resolver sus problemas de redes
de larga data. En el mundo de las telecomunicaciones, NTT puede
considerarse uno de los primeros en invertir en la adopcin y despliegue de
SDN en todo tipo de infraestructuras de red, desde backbone, centro de
datos hasta clientes marginales [269]. En 2013, NTT lanz una plataforma
de provisin elstica basada en SDN de recursos de red (por ejemplo, ancho
de banda) para emisoras de video HD [536]. Asimismo, como proveedor
global de cloud computing con centros de datos distribuidos por todo el
mundo [537], la misma compaa lanz un servicio similar para sus clientes
en la nube, que ahora son capaces de aprovechar la red dinmica de
aprovisionamiento de intradata e interdata. AT & T es otra compaa de
telecomunicaciones que est invirtiendo fuertemente en nuevos servicios,
como las nubes de red definidas por el usuario, que aprovechan los
recientes desarrollos en NFV y SDN [539]. Como se mencion
anteriormente, SDN y NFV son tecnologas complementarias que pueden
aplicarse a diferentes tipos de redes, desde redes locales y centros de datos
hasta redes de transporte [540] - [545]. Recientemente, varias iniciativas de
investigacin han trabajado para combinar SDN y NFV a travs de DPDK de
Intel, un conjunto de bibliotecas y controladores que facilita el desarrollo de
aplicaciones intensivas en red y permite la implementacin de funciones de
red de grano fino [546].
Los trabajos iniciales hacia el encadenamiento de servicios se han
propuesto combinando las tecnologas SDN y NFV [27], [547] - [550], y
tambin han aparecido estudios en torno a la aplicabilidad del ForCES [30]
al NFV mejorado por SDN [540]. Estos son algunos de los primeros ejemplos
de las oportunidades SDNs parecen traer a los proveedores de
telecomunicaciones y la nube.
Las redes portadoras estn utilizando el paradigma SDN como el medio
tecnolgico para resolver una serie de problemas de larga data. Algunos de
estos esfuerzos incluyen nuevas arquitecturas para una migracin fluida de
la actual infraestructura de ncleo mvil a SDN [222], y modelos
tecnoeconmicos para la virtualizacin de estas redes [551], [552]; Los
sistemas de virtualizacin OpenFlow carriergrade [112], [553], incluidas las
infraestructuras virtualizadas de acceso de banda ancha [554], las tcnicas
que permiten la oferta de redes como servicio [555]; Programable GEPON y
DWDM ROADM [157] - [160]; Despliegues habilitados con SDN de sistemas
interautonomos (ASs) a gran escala [556]; Control flexible de los recursos de
la red [557], incluida la oferta de servicios MPLS utilizando un enfoque SDN
[558]; Y la investigacin de nuevas arquitecturas de red, a partir de
propuestas para separar el borde de red del ncleo [559], [560], formando
este ltimo el tejido que transporta paquetes definidos por un borde
inteligente a puntos de intercambio de Internet definidos por software
[ 528], [561]. El anlisis de casos de uso [562] de las funciones de gestin
requeridas por las redes portadoras ha identificado un conjunto de
requisitos en las limitaciones existentes en el cuadro de protocolo de
ProtocoloSDN. Por ejemplo, se ha determinado que OF-Config [54] necesita
unas cuantas extensiones para satisfacer los requisitos de los transportistas,
tales como el descubrimiento de recursos fsicos, la configuracin del enlace
lgico, la instanciacin de los conmutadores lgicos y la configuracin OAM
del dispositivo y enlace [562]. Del mismo modo, las extensiones de
OpenFlow tambin se han propuesto para realizar la integracin de
paquetes pticos con SDN [563]. Para apoyar los conceptos de SDN en
redes de rea extensa a gran escala, se requieren diferentes extensiones y
mecanismos, tanto especficos de tecnologa (por ejemplo, MPLS BFD) como
agnsticos de tecnologa, tales como: mecanismos de resiliencia para fallas
de enlaces sobrevivientes [486] O elementos de reenvo; Soluciones para
integrar los servicios al cliente residencial en diferentes formas (es decir,
apoyar tambin las tecnologas actuales); Nuevos enfoques de redes
energticamente eficientes; Propiedades de QoS para la clasificacin de
paquetes, medicin, coloracin, vigilancia, configuracin y programacin; Y
los aspectos multicapa que describen las diferentes etapas de la integracin
de paquetes pticos [563] - [565]. La tecnologa SDN tambin aporta nuevas
posibilidades a los proveedores de la nube. Aprovechando el control
lgicamente centralizado de los recursos de red [8], [566], es posible
simplificar y optimizar la gestin de la red de centros de datos y lograr: 1) la
creacin de redes eficaces de intradacin, incluyendo mecanismos de
recuperacin rpida de los datos y [568], ingeniera de trfico adaptable con
mnimas modificaciones a las redes de CC [278], enrutamiento tolerante a
fallos simplificado [569], aislamiento de rendimiento [570] y migracin de
recursos fcil y eficiente , De VMs y redes virtuales) [478]; 2) mejora de la
comunicacin interdatacentro, incluida la capacidad de utilizar plenamente
los costosos enlaces de alto ancho de banda sin menoscabar la calidad del
servicio [8], [571]; 3) mayores niveles de fiabilidad (con nuevos mecanismos
de gestin de fallas, etc.) [478], [486], [567], [569]; Y 4) reduccin de costos
reemplazando
Hardware complejo y costoso por dispositivos de reenvo simples y ms
baratos [8], [572]. La Tabla 16 resume algunos de los requerimientos de los
proveedores de infraestructuras de red y de nube de carrier-grade. En esta
tabla, mostramos los desafos actuales y lo que se espera con SDN. Como
vimos antes, algunas de las expectativas ya se estn convirtiendo en una
realidad, pero muchas son todava cuestiones abiertas.
Lo que parece estar claro es que SDN representa una oportunidad para los
proveedores de telecomunicaciones y cloud, al proporcionar flexibilidad,
rentabilidad y una gestin ms fcil de sus redes.
I. SDN: la pieza perdida en relacin con los entornos definidos por software
La convergencia de diferentes tecnologas permite la aparicin de
infraestructuras de TI completamente programables. Ya es posible
configurar y reconfigurar de forma dinmica y automtica toda la pila de TI,
desde la infraestructura de red hasta las aplicaciones, para responder mejor
a
Cambios en la carga de trabajo. Los avances recientes hacen posible el
aprovisionamiento de recursos a demanda, en casi todas las capas
infraestructurales. El aprovisionamiento y la orquestacin totalmente
automatizados de las infraestructuras de TI han sido recientemente
denominados entornos definidos por software (SDE) [171], [172], por IBM.
Este es un nuevo enfoque que se espera tenga un potencial significativo en
la simplificacin de la gestin de TI, la optimizacin del uso de la
infraestructura, reducir los costos y reducir el tiempo de comercializacin de
nuevas ideas y productos. En una SDE, las cargas de trabajo pueden
asignarse de forma fcil y automtica a los recursos de TI adecuados
basados en las caractersticas de la aplicacin, las polticas de seguridad y
de nivel de servicio y los recursos mejor disponibles para ofrecer
optimizacin y reconfiguracin continua y dinmica para abordar los
problemas de infraestructura de forma rpida y sensible. manera. Cuadro 17
resume los enfoques tradicionales y algunas de las caractersticas clave que
estn habilitados por SDE [577], [578]. En una SDE, las cargas de trabajo se
gestionan independientemente de los sistemas y la infraestructura
subyacente, es decir, no son
Vinculados a una tecnologa o proveedor especficos [171], [172]. Otra
caracterstica de este nuevo enfoque es ofrecer un acceso programtico al
medio ambiente en su conjunto, seleccionar los mejores recursos
disponibles en funcin del estado actual de la infraestructura y hacer
cumplir las polticas definidas. En este sentido, comparte gran parte de la
filosofa de SDN. Curiosamente, una de las piezas clave faltantes de un SDE
fue, hasta ahora, SDN. Los cuatro bloques esenciales de una SDE [171],
[172], [578] son: SDNs [579], [580]; almacenamiento definido por
software (SDS) [577]; computacin definida por software (SDC) [171];
gestin definida por software (SDM) [581]. En la ltima dcada, los avances
en virtualizacin de computacin y almacenamiento, junto con la
disponibilidad de sofisticadas herramientas de orquestacin en nube, han
permitido SDS, SDC y SDM. Estos componentes arquitectnicos han sido
ampliamente utilizados por los proveedores de la nube y para la
construccin de infraestructuras de TI en diferentes entornos empresariales.
Sin embargo, la falta de control programable de la red ha obstaculizado
hasta ahora la realizacin de un SDE completo. SDN es visto como la
tecnologa que puede llenar este vaco, como atestiguan la aparicin de las
plataformas de virtualizacin de la red a escala de nube basadas en este
nuevo paradigma [112]. El IBM SmartCloud Orchestrator es uno de los
primeros ejemplos de un SDE [171], [172]. Integra la computacin, el
almacenamiento, la gestin y la creacin de redes de forma estructurada.
La fig. 11 da una visin simplificada de un SDE, tomando como base el
enfoque desarrollado por IBM. La idea principal de una infraestructura
basada en SDE es que las necesidades de negocio que definen las cargas de
trabajo desencadenan la reconfiguracin de la infraestructura global de TI
(clculo, almacenamiento, red). Este es un paso importante hacia una
infraestructura de TI ms personalizable que se enfoca en los requisitos del
negocio en lugar de en las limitaciones de la propia infraestructura.

VI. CONCLUSIN
Las redes tradicionales son complejas y difciles de manejar. Una de las
razones es que los planos de control y de datos estn integrados
verticalmente y especficos del proveedor. Otra razn concurrente es que los
dispositivos de red tpicos tambin estn estrechamente vinculados a
productos de lnea y versiones. En otras palabras, cada lnea de producto
puede tener sus propias interfaces particulares de configuracin y gestin,
lo que implica ciclos largos para producir actualizaciones de productos (por
ejemplo, nuevos firmware) o actualizaciones (por ejemplo, nuevas versiones
de los dispositivos). Todo esto ha dado lugar a problemas de bloqueo de
proveedores para propietarios de infraestructuras de red, adems de
plantear severas restricciones al cambio ya la innovacin. SDN cre una
oportunidad para resolver estos problemas de larga data. Algunas de las
ideas clave de SDN son la introduccin de la programacin dinmica en los
dispositivos de reenvo a travs de interfaces abiertas en direccin sur, la
disociacin del plano de control y datos y la visin global de la red mediante
la centralizacin lgica del cerebro de red. Los elementos del plano de datos
se convirtieron en dispositivos de reenvo de paquetes, pero altamente
eficientes y programables, los elementos de plano de control ahora estn
representados por una nica entidad, el controlador o NOS. Las aplicaciones
que implementan la lgica de red se ejecutan en la parte superior del
controlador y son mucho ms fciles de desarrollar y desplegar en
comparacin con las redes tradicionales. Dada la visin global, la coherencia
de las polticas es sencilla de hacer cumplir. SDN representa un importante
cambio de paradigma en el desarrollo y la evolucin de las redes,
introduciendo un nuevo ritmo de innovacin en la infraestructura de redes.
A pesar de los recientes e interesantes intentos de investigar este nuevo
captulo en la historia de las redes [14] - [16], la literatura todava careca, a
nuestro entender, de una sola visin amplia y completa de los bloques de
construccin, los conceptos , Y los desafos de los SDN. Tratando de abordar
esta laguna, este documento utiliz un enfoque en capas para diseccionar
metdicamente el estado de la tcnica en trminos de conceptos, ideas y
componentes de SDN, que abarca una amplia gama de soluciones
existentes, as como las direcciones futuras. Comenzamos comparando este
nuevo paradigma con redes tradicionales y discutiendo cmo la academia y
la industria ayudaron a formar SDN. Siguiendo un enfoque de abajo hacia
arriba, ofrecimos una visin en profundidad de lo que consideramos las ocho
facetas fundamentales del problema SDN: 1) infraestructura de hardware; 2)
interfaces hacia el sur; 3) virtualizacin de red (capa de hipervisor entre los
dispositivos de reenvo y los NOS), 4) NOS (SDNcontrollersandcontrol
platforms); 5) interfaces en direccin norte (abstracciones comunes de
programacin ofrecidas a aplicaciones de red); 6) virtualizacin utilizando
tcnicas de corte proporcionadas por bibliotecas de propsito especial y / o
lenguajes de programacin y compiladores, 7) lenguajes de programacin
de red; Y finalmente, 8) aplicaciones de red.
SDN ha conseguido abrir el camino hacia una red de prxima generacin,
generando un innovador ambiente de investigacin y desarrollo,
promoviendo avances en varias reas: diseo de plataforma de
conmutadores y controladores, evolucin de escalabilidad y rendimiento de
dispositivos y arquitecturas, promocin de seguridad y fiabilidad.
Seguiremos siendo testigos de una amplia actividad en torno a SDN en un
futuro prximo. Temas emergentes que requieren ms investigacin son, por
ejemplo: la ruta de migracin a SDN, extendiendo SDN hacia redes de
transporte de portadores, la realizacin del paradigma de cloud computing
de red como servicio o SDE. Como tal, nos gustara recibir retroalimentacin
de la comunidad de redes / SDN a medida que evoluciona este nuevo
paradigma, para convertirlo en un '' documento vivo '' que se actualiza y
mejora basado en la retroalimentacin de la comunidad. Hemos creado un
repositorio github (https://github.com/SDN-Survey/latex/ wiki) para este
propsito, e invitamos a nuestros lectores a unirse a nosotros en este
esfuerzo comunal. Adems, los nuevos lanzamientos de la encuesta estarn
disponibles en http://arxiv.org/abs/1406.0440.