Articulo de referencia

Redes definidas por software

Las redes definidas por software ( SDN ) son un enfoque para crear redes y gestionarlas mediante software y tecnologías de redes virtualizadas, en lugar de físicas, como enrutad...

Las redes definidas por software ( SDN ) son un enfoque para crear redes y gestionarlas mediante software y tecnologías de redes virtualizadas, en lugar de físicas, como enrutadores, cortafuegos y conmutadores. Esto permite la abstracción por software de la red, lo que posibilita una configuración de red dinámica y programáticamente eficiente para crear agrupaciones y segmentaciones, al tiempo que mejora el rendimiento y la monitorización de la red de una manera más similar a la computación en la nube que a la gestión de redes tradicional. [ 1 ] Las SDN están diseñadas para mejorar la arquitectura estática de las redes tradicionales y pueden emplearse para centralizar la inteligencia de la red en un componente de red, disociando el proceso de reenvío de paquetes de red ( plano de datos ) del proceso de enrutamiento ( plano de control ). [ 2 ] El plano de control consta de uno o más controladores, que se consideran el cerebro de la red SDN, donde se incorpora toda la inteligencia. Sin embargo, la centralización tiene ciertas desventajas relacionadas con la seguridad, [ 1 ] la escalabilidad y la elasticidad. [ 1 ] [ 3 ]

SDN se asoció comúnmente con el protocolo OpenFlow para la comunicación remota con elementos del plano de red para determinar la ruta de los paquetes de red a través de conmutadores de red desde la aparición de OpenFlow en 2011. Sin embargo, desde 2012, los sistemas propietarios también han utilizado el término. [ 4 ] [ 5 ] Estos incluyen Open Network Environment de Cisco Systems y la plataforma de virtualización de red de Nicira .

SD-WAN aplica una tecnología similar a una red de área amplia (WAN). [ 6 ]

Además de los casos de uso de WAN, SDN también se aplica cada vez más en las redes troncales de telecomunicaciones, donde se combina con plataformas de automatización e inventario operativo para proporcionar visibilidad en tiempo real, garantía de servicio y aprovisionamiento simplificado en redes de múltiples proveedores. [ 7 ] [ 8 ] [ 9 ]

Historia

Los orígenes de los principios de SDN se remontan a la separación de los planos de control y de datos, utilizada inicialmente en las redes telefónicas públicas conmutadas. Esto simplificó el aprovisionamiento y la gestión años antes de que esta arquitectura se empleara en redes de datos.

El Grupo de Trabajo de Ingeniería de Internet (IETF) comenzó a considerar varias formas de desacoplar las funciones de control y reenvío de datos en un estándar de interfaz propuesto publicado en 2004 llamado Separación de Elementos de Reenvío y Control (ForCES). [ 10 ] El Grupo de Trabajo de ForCES también propuso una arquitectura SoftRouter complementaria. [ 11 ] Otros estándares iniciales del IETF que buscaban separar los planos de control y de datos incluyen el protocolo Linux Netlink como protocolo de servicios IP, [ 12 ] y una arquitectura basada en elementos de cálculo de ruta (PCE). [ 13 ]

Estos primeros intentos no tuvieron éxito. Una de las razones es que muchos en la comunidad de Internet consideraban arriesgado separar el control de los datos, especialmente por el potencial de fallos en el plano de control. Otra razón es que a los proveedores les preocupaba que la creación de interfaces de programación de aplicaciones (API) estándar entre los planos de control y de datos aumentara la competencia.

En 2006 se fundó una joven empresa emergente en torno a una topología de red de estilo SDN y presentó una colección de patentes SDN en 2007 [ 14 ] .

El uso de software de código abierto en estas arquitecturas separadas tiene sus raíces en el proyecto Ethane del departamento de informática de Stanford . El sencillo diseño de conmutador de Ethane dio lugar a la creación de OpenFlow , [ 15 ] y la primera API para OpenFlow se creó en 2008. [ 16 ] Ese mismo año, se creó NOX, un sistema operativo para redes. [ 17 ]

La investigación sobre SDN incluyó emuladores como vSDNEmul, [ 18 ] EstiNet, [ 19 ] y Mininet. [ 20 ]

El trabajo en OpenFlow continuó en Stanford, incluyendo la creación de bancos de pruebas para evaluar el uso del protocolo en una red de un solo campus , así como a través de la WAN como columna vertebral para conectar múltiples campus. [ 21 ] En entornos académicos, existían varias redes de investigación y producción basadas en conmutadores OpenFlow de NEC y Hewlett-Packard , así como aquellas basadas en cajas blancas de Quanta Computer a partir de aproximadamente 2009. [ 22 ]

Fuera del ámbito académico, los primeros despliegues fueron realizados por Nicira en 2010 para controlar OVS desde Onix, desarrollado conjuntamente con NTT y Google. Un despliegue notable fue el de Google en B4 en 2012. [ 23 ] [ 24 ] Posteriormente, Google anunció los primeros despliegues de OpenFlow/Onix en sus centros de datos. [ 25 ] Otro gran despliegue se encuentra en China Mobile . [ 26 ]

La Open Networking Foundation se fundó en 2011 para promover SDN y OpenFlow.

En el Interop and Tech Field Day de 2014, Avaya demostró la red definida por software utilizando el puenteo de ruta más corta ( IEEE 802.1aq ) y OpenStack como un campus automatizado, extendiendo la automatización desde el centro de datos hasta el dispositivo final y eliminando el aprovisionamiento manual de la prestación de servicios. [ 27 ] [ 28 ]

Concepto

Las arquitecturas SDN desacoplan las funciones de control de red ( plano de control ) y reenvío ( plano de datos ), lo que permite que el control de red sea directamente programable y que la infraestructura subyacente se abstraiga de las aplicaciones y los servicios de red. [ 29 ] El protocolo OpenFlow es uno de los protocolos utilizados en las tecnologías SDN.

La arquitectura SDN es:

  • Programable directamente: El control de red es programable directamente porque está desacoplado de las funciones de reenvío.
  • Metodología ágil: Al abstraer el control del reenvío, los administradores pueden ajustar dinámicamente el flujo de tráfico en toda la red para satisfacer las necesidades cambiantes.
  • Gestión centralizada: La inteligencia de la red está centralizada (lógicamente) en controladores SDN basados ​​en software que mantienen una visión global de la red, la cual aparece para las aplicaciones y los motores de políticas como un único conmutador lógico.
  • Configuración programática: SDN permite a los administradores de red configurar, gestionar, proteger y optimizar los recursos de red muy rápidamente a través de programas SDN dinámicos y automatizados, que pueden escribir ellos mismos porque los programas no dependen de software propietario . [ 30 ]
  • Basada en estándares abiertos e independiente del proveedor: Cuando se implementa mediante estándares abiertos, la SDN simplifica el diseño y el funcionamiento de la red porque las instrucciones las proporcionan los controladores SDN en lugar de múltiples dispositivos y protocolos específicos de cada proveedor.

Nueva arquitectura de red

La explosión de dispositivos y contenido móviles, la virtualización de servidores y la llegada de los servicios en la nube se encuentran entre las tendencias que impulsan a la industria de redes a reexaminar las arquitecturas de red tradicionales. [ 31 ] Muchas redes convencionales son jerárquicas, construidas con niveles de conmutadores Ethernet dispuestos en una estructura de árbol. Este diseño tenía sentido cuando la computación cliente-servidor era dominante, pero una arquitectura estática como esta puede no ser adecuada para las necesidades dinámicas de computación y almacenamiento de los centros de datos empresariales, campus y entornos de operadores actuales. [ 32 ] Algunas de las tendencias informáticas clave que impulsan la necesidad de un nuevo paradigma de red incluyen:

Cambios en los patrones de tráfico
Dentro del centro de datos empresarial, los patrones de tráfico han cambiado significativamente. A diferencia de las aplicaciones cliente-servidor, donde la mayor parte de la comunicación se produce entre un cliente y un servidor, las aplicaciones actuales acceden a diferentes bases de datos y servidores, generando un intenso tráfico de máquina a máquina en dirección este-oeste antes de devolver los datos al dispositivo del usuario final, siguiendo el patrón de tráfico clásico norte-sur . Al mismo tiempo, los usuarios están modificando los patrones de tráfico de red al exigir acceso a contenido y aplicaciones corporativas desde cualquier tipo de dispositivo, conectándose desde cualquier lugar y en cualquier momento. Finalmente, muchos administradores de centros de datos empresariales están implementando un modelo de computación de utilidad , que puede incluir una nube privada, una nube pública o una combinación de ambas, lo que genera tráfico adicional en la red de área amplia.
La consumerización de las TI
Los usuarios utilizan cada vez más dispositivos personales móviles, como teléfonos inteligentes, tabletas y ordenadores portátiles, para acceder a la red corporativa. El departamento de TI se enfrenta a la presión de gestionar estos dispositivos personales de forma precisa, protegiendo al mismo tiempo los datos corporativos y la propiedad intelectual, y cumpliendo con las normativas vigentes.
El auge de los servicios en la nube
Las empresas han adoptado con entusiasmo los servicios de nube pública y privada, lo que ha dado lugar a un crecimiento sin precedentes de estos servicios. Muchas empresas buscan la agilidad necesaria para acceder a aplicaciones, infraestructura y otros recursos de TI bajo demanda y de forma discreta. La planificación de TI para servicios en la nube debe realizarse en un entorno con mayores requisitos de seguridad, cumplimiento y auditoría, además de reorganizaciones, consolidaciones y fusiones empresariales que pueden modificar rápidamente las premisas. Proporcionar aprovisionamiento de autoservicio, ya sea en una nube privada o pública, requiere una escalabilidad elástica de los recursos de computación, almacenamiento y red, idealmente desde una perspectiva común y con un conjunto común de herramientas.
Los macrodatos implican más ancho de banda.
El manejo de los macrodatos actuales requiere un procesamiento paralelo masivo en miles de servidores, todos los cuales necesitan conexiones directas entre sí. El aumento de estos grandes conjuntos de datos está impulsando una demanda constante de capacidad de red adicional en el centro de datos. Los operadores de redes de centros de datos hiperescalables se enfrentan a la ardua tarea de escalar la red a un tamaño antes inimaginable, manteniendo la conectividad entre todos los nodos dentro de un presupuesto limitado. [ 33 ]
Consumo de energía en grandes centros de datos
Con la aparición del Internet de las cosas , la computación en la nube y el SaaS , la necesidad de centros de datos más grandes ha incrementado el consumo energético de dichas instalaciones. Muchos investigadores han mejorado la eficiencia energética de las redes definidas por software (SDN) aplicando técnicas de enrutamiento existentes para ajustar dinámicamente el plano de datos de la red y así ahorrar energía. [ 34 ] También se están investigando técnicas para mejorar la eficiencia energética del plano de control. [ 35 ]

Componentes arquitectónicos

Descripción general de alto nivel de la arquitectura de redes definidas por software.

La siguiente lista define y explica los componentes arquitectónicos de SDN: [ 36 ]

Aplicación SDN
Las aplicaciones SDN son programas que comunican sus requisitos de red y el comportamiento deseado de la red al controlador SDN mediante una interfaz de nivel superior (NBI). Además, pueden utilizar una vista abstracta de la red para la toma de decisiones internas. Una aplicación SDN consta de la lógica de la aplicación SDN y uno o más controladores NBI. Las propias aplicaciones SDN pueden exponer otra capa de control de red abstracto, ofreciendo así una o más NBI de nivel superior a través de los agentes NBI correspondientes.
controlador SDN
El controlador SDN es una entidad lógicamente centralizada encargada de (i) traducir los requisitos de la capa de aplicación SDN a las rutas de datos SDN y (ii) proporcionar a las aplicaciones SDN una vista abstracta de la red (que puede incluir estadísticas y eventos). Un controlador SDN consta de uno o más agentes NBI, la lógica de control SDN y el controlador de la interfaz de control al plano de datos (CDPI). La definición del controlador como entidad lógicamente centralizada no prescribe ni excluye arquitecturas de implementación tales como la federación de múltiples controladores, la conexión jerárquica de controladores, las interfaces de comunicación entre controladores, ni la virtualización o segmentación de recursos de red.
Ruta de datos SDN
La ruta de datos SDN es un dispositivo de red lógico que ofrece visibilidad y control absoluto sobre sus capacidades de reenvío y procesamiento de datos. La representación lógica puede abarcar todas o solo una parte de dichas capacidades. Una ruta de datos SDN consta de un agente CDPI y un conjunto de uno o más motores de reenvío de tráfico, así como cero o más funciones de procesamiento de tráfico. Estos motores y funciones pueden incluir el reenvío simple entre las interfaces externas de la ruta de datos o funciones internas de procesamiento o terminación de tráfico. Una o más rutas de datos SDN pueden estar contenidas en un único elemento de red (físico): una combinación física integrada de recursos de comunicación, gestionados como una unidad. Una ruta de datos SDN también puede definirse en varios elementos de red físicos. Esta definición lógica no prescribe ni excluye detalles de implementación como la asignación de lógica a física, la gestión de recursos físicos compartidos, la virtualización o segmentación de la ruta de datos SDN, la interoperabilidad con redes que no son SDN, ni la funcionalidad de procesamiento de datos, que puede incluir funciones de las capas 4 a 7 del modelo OSI .
Interfaz de control SDN a plano de datos (CDPI)
La interfaz SDN CDPI se define entre un controlador SDN y una ruta de datos SDN, y proporciona, como mínimo, control programático de todas las operaciones de reenvío, la publicación de capacidades, la generación de informes estadísticos y la notificación de eventos. Una de las ventajas de SDN reside en la expectativa de que la interfaz CDPI se implemente de forma abierta, independiente del proveedor e interoperable.
Interfaces de dirección norte de SDN (NBI)
Las interfaces de red definidas por software (SDN NBI) son interfaces entre las aplicaciones SDN y los controladores SDN. Normalmente, proporcionan vistas abstractas de la red y permiten expresar directamente el comportamiento y los requisitos de la misma. Esto puede ocurrir en cualquier nivel de abstracción y en diferentes conjuntos de funcionalidades.

plano de control SDN

La implementación del plano de control SDN puede seguir un diseño centralizado, jerárquico o descentralizado. Las propuestas iniciales del plano de control SDN se centraron en una solución centralizada, donde una única entidad de control tenía una visión global de la red. Si bien esto simplifica la implementación de la lógica de control, presenta limitaciones de escalabilidad a medida que aumenta el tamaño y la dinámica de la red. Para superar estas limitaciones, se han propuesto enfoques jerárquicos y distribuidos. En las soluciones jerárquicas, [ 37 ] [ 38 ] los controladores operan sobre una vista de red particionada, mientras que las decisiones que requieren conocimiento de toda la red son tomadas por un controlador raíz lógicamente centralizado. En los enfoques distribuidos, [ 39 ] [ 40 ] los controladores operan sobre su vista local o pueden intercambiar mensajes de sincronización para mejorar su conocimiento. Las soluciones distribuidas son más adecuadas para soportar aplicaciones SDN adaptativas.

Un aspecto clave al diseñar un plano de control SDN distribuido es decidir el número y la ubicación de las entidades de control. Un parámetro importante a considerar es el retardo de propagación entre los controladores y los dispositivos de red, [ 41 ] especialmente en el contexto de redes grandes. Otros objetivos considerados incluyen la fiabilidad de la ruta de control , [ 42 ] la tolerancia a fallos [ 43 ] y los requisitos de la aplicación. [ 44 ]

plano de datos SDN

En SDN, el plano de datos se encarga de procesar los paquetes que contienen datos utilizando un conjunto de reglas especificadas por el plano de control. El plano de datos puede implementarse en conmutadores de hardware físicos o en software, como Open vSwitch . La capacidad de memoria de los conmutadores de hardware puede limitar el número de reglas que se pueden almacenar, mientras que las implementaciones de software pueden tener mayor capacidad. [ 45 ]

La ubicación del plano de datos y del agente de SDN se puede utilizar para clasificar las implementaciones de SDN:

  • Conmutación por hardware: Este enfoque implementa el procesamiento del plano de datos dentro de un dispositivo físico. Los conmutadores OpenFlow pueden usar tablas TCAM para enrutar secuencias de paquetes (flujos) . Estos conmutadores pueden usar un ASIC para su implementación.
  • Conmutación por software: Algunos conmutadores físicos pueden implementar la compatibilidad con SDN mediante software en el dispositivo para rellenar tablas de flujo y actuar como agente SDN al comunicarse con el controlador. Los hipervisores también pueden utilizar implementaciones de software para admitir protocolos SDN en los conmutadores virtuales que dan soporte a sus máquinas virtuales .

Las entradas de la tabla de flujo pueden completarse de forma proactiva, reactiva o híbrida. [ 49 ] [ 50 ] En el modo proactivo, el controlador completa las entradas de la tabla de flujo para todas las coincidencias de tráfico posibles para este conmutador con antelación. Este modo se puede comparar con las entradas típicas de la tabla de enrutamiento actuales, donde todas las entradas estáticas se instalan con antelación. Posteriormente, no se envía ninguna solicitud al controlador, ya que todos los flujos entrantes encontrarán una entrada coincidente. Una ventaja importante del modo proactivo es que todos los paquetes se reenvían a la velocidad de línea (considerando todas las entradas de la tabla de flujo en la TCAM) y no se añade ningún retardo. En el modo reactivo, las entradas se completan bajo demanda. Si llega un paquete sin una regla de coincidencia correspondiente en la tabla de flujo, el agente SDN envía una solicitud al controlador para obtener más instrucciones. El controlador examina las solicitudes del agente SDN y proporciona instrucciones, instalando una regla en la tabla de flujo para el paquete correspondiente si es necesario. El modo híbrido utiliza el modo de reenvío proactivo de baja latencia para una parte del tráfico, mientras que se basa en la flexibilidad del procesamiento del modo reactivo para el tráfico restante.

Aplicaciones

SDMN

Las redes móviles definidas por software (SDMN) [ 51 ] [ 52 ] son ​​un enfoque para el diseño de redes móviles donde todas las características específicas del protocolo se implementan en software, maximizando el uso de hardware y software genéricos y comerciales tanto en la red central como en la red de acceso de radio . [ 53 ] Se propone como una extensión del paradigma SDN para incorporar funcionalidades específicas de la red móvil. [ 54 ] Desde 3GPP Rel.14, se introdujo una separación del plano de usuario de control en las arquitecturas de la red central móvil con el protocolo PFCP .

SD-WAN

Una SD-WAN es una WAN gestionada mediante los principios de las redes definidas por software. [ 55 ] El principal objetivo de la SD-WAN es reducir los costes de la WAN mediante el uso de líneas arrendadas más asequibles y disponibles comercialmente, como alternativa o sustitución parcial de las líneas MPLS más caras . El control y la gestión se administran de forma independiente del hardware, y los controladores centrales facilitan la configuración y la administración. [ 56 ]

SD-LAN

Una SD-LAN es una red de área local (LAN) construida sobre los principios de las redes definidas por software, aunque existen diferencias clave en la topología, la seguridad de la red, la visibilidad y el control de las aplicaciones, la gestión y la calidad del servicio. [ 57 ] La SD-LAN desacopla los planos de control, gestión y datos para permitir una arquitectura basada en políticas para LAN cableadas e inalámbricas. Las SD-LAN se caracterizan por el uso de un sistema de gestión en la nube y conectividad inalámbrica sin la presencia de un controlador físico. [ 58 ]

Seguridad mediante el paradigma SDN

La arquitectura SDN puede habilitar, facilitar o mejorar las aplicaciones de seguridad relacionadas con la red debido a la visión centralizada de la red que ofrece el controlador y su capacidad para modificar el comportamiento o el plano de datos en cualquier momento. Las implicaciones de seguridad de la arquitectura SDN siguen en estudio. [ 59 ] [ 60 ] [ 61 ] [ 62 ]

Diversos trabajos de investigación sobre SDN ya han analizado aplicaciones de seguridad basadas en el controlador SDN, con distintos objetivos. La detección y mitigación de ataques de denegación de servicio distribuido (DDoS) [ 63 ] [ 64 ] , así como la propagación de botnets [ 65 ] y gusanos [ 66 ] , son algunos casos de uso concretos de dichas aplicaciones. Las aplicaciones propuestas recopilan periódicamente estadísticas de red del plano de reenvío de la red de forma estandarizada (por ejemplo, mediante OpenFlow) y, a continuación, aplican algoritmos de clasificación a dichas estadísticas para detectar anomalías en la red. Si se detecta una anomalía, la aplicación indica al controlador cómo reprogramar el plano de datos para mitigarla.

Otro tipo de aplicación de seguridad aprovecha el controlador SDN mediante la implementación de algoritmos de defensa de objetivo móvil (MTD). Los algoritmos MTD se utilizan normalmente para dificultar cualquier ataque a un sistema o red determinado, ocultando o modificando periódicamente propiedades clave de dicho sistema o red. En las redes tradicionales, implementar algoritmos MTD no es una tarea sencilla, ya que resulta difícil establecer una autoridad central capaz de determinar, para cada parte del sistema que se va a proteger, qué propiedades clave se ocultan o modifican. En una red SDN, estas tareas se simplifican gracias a la centralidad del controlador. Una aplicación puede, por ejemplo, asignar periódicamente direcciones IP virtuales a los hosts de la red, y el controlador se encarga de la asignación de la IP virtual a la IP real. [ 67 ] Otra aplicación puede simular puertos falsos abiertos/cerrados/filtrados en hosts aleatorios de la red para generar un ruido significativo durante el escaneo realizado por un atacante. [ 68 ]

También se puede obtener valor adicional en cuanto a seguridad en redes habilitadas para SDN utilizando FlowVisor [ 69 ] y FlowChecker [ 70 ] . El primero intenta utilizar un único plano de reenvío de hardware que comparte múltiples redes lógicas separadas. Siguiendo este enfoque, los mismos recursos de hardware pueden utilizarse para fines de producción y desarrollo, así como para separar el tráfico de monitorización, configuración e Internet, donde cada escenario puede tener su propia topología lógica, que se denomina segmento. En conjunto con este enfoque, FlowChecker [ 69 ] realiza la validación de nuevas reglas OpenFlow implementadas por los usuarios utilizando su propio segmento.

Las aplicaciones de controlador SDN se implementan principalmente en escenarios a gran escala, lo que requiere comprobaciones exhaustivas de posibles errores de programación. En 2012 se describió un sistema para ello llamado NICE. [ 71 ] La introducción de una arquitectura de seguridad integral requiere un enfoque exhaustivo y prolongado para SDN. Desde su introducción, los diseñadores han estado buscando posibles maneras de proteger SDN sin comprometer la escalabilidad. Una de estas arquitecturas es la Arquitectura de Seguridad SN-SECA (SDN+NFV). [ 72 ]

Entrega de datos grupales mediante SDN

Las aplicaciones distribuidas que se ejecutan en varios centros de datos suelen replicar datos para la sincronización, la tolerancia a fallos, el equilibrio de carga y para acercar los datos a los usuarios (lo que reduce la latencia y aumenta el rendimiento percibido). Además, muchas aplicaciones, como Hadoop, replican datos dentro de un centro de datos en varios racks para aumentar la tolerancia a fallos y facilitar la recuperación de datos. Todas estas operaciones requieren la entrega de datos desde una máquina o centro de datos a varias máquinas o centros de datos. El proceso de entrega fiable de datos de una máquina a varias máquinas se denomina Entrega Confiable de Datos en Grupo (RGDD).

Los conmutadores SDN se pueden usar para RGDD mediante la instalación de reglas que permiten el reenvío a múltiples puertos de salida. Por ejemplo, OpenFlow proporciona soporte para tablas de grupo desde la versión 1.1 [ 73 ], lo que lo hace posible. Usando SDN, un controlador central puede configurar cuidadosamente e inteligentemente árboles de reenvío para RGDD. Dichos árboles se pueden construir prestando atención al estado de congestión/carga de la red para mejorar el rendimiento. Por ejemplo, MCTCP [ 74 ] es un esquema para la entrega a muchos nodos dentro de centros de datos que se basa en topologías regulares y estructuradas de redes de centros de datos, mientras que DCCast [ 75 ] y QuickCast [ 76 ] son ​​enfoques para la replicación rápida y eficiente de datos y contenido a través de centros de datos a través de WAN privadas.

Relación con NFV

La virtualización de funciones de red , o NFV por sus siglas en inglés, es un concepto que complementa a SDN. Por lo tanto, NFV no depende de SDN ni de sus conceptos. NFV separa el software del hardware para permitir una implementación de red flexible y una operación dinámica. Las implementaciones de NFV suelen utilizar servidores estándar para ejecutar versiones de software de servicios de red que anteriormente se basaban en hardware. Estos servicios basados ​​en software que se ejecutan en un entorno NFV se denominan funciones de red virtualizadas (VNF). [ 77 ] El programa híbrido SDN-NFV se proporcionó para capacidades de alta eficiencia, elasticidad y escalabilidad. NFV se diseñó para acelerar la innovación y el aprovisionamiento de servicios utilizando tecnologías de virtualización de TI estándar. [ 77 ] [ 78 ] SDN proporciona la agilidad de controlar los dispositivos de reenvío genéricos, como los enrutadores y conmutadores, mediante el uso de controladores SDN. Por otro lado, la agilidad de NFV se proporciona para las aplicaciones de red mediante el uso de servidores virtualizados. Es totalmente posible implementar una función de red virtualizada (VNF) como una entidad independiente utilizando paradigmas de orquestación y redes existentes. Sin embargo, existen beneficios inherentes al aprovechar los conceptos de SDN para implementar y administrar una infraestructura NFV, particularmente al considerar la administración y orquestación de VNF, y es por eso que se están definiendo plataformas de múltiples proveedores que incorporan SDN y NFV en ecosistemas concertados. [ 79 ]

Relación con DPI

La inspección profunda de paquetes (DPI) proporciona a la red conocimiento de las aplicaciones, mientras que SDN proporciona a las aplicaciones conocimiento de la red. [ 80 ] Aunque SDN cambiará radicalmente las arquitecturas de red genéricas, debe ser capaz de trabajar con arquitecturas de red tradicionales para ofrecer una alta interoperabilidad. La nueva arquitectura de red basada en SDN debe considerar todas las capacidades que actualmente se proporcionan en dispositivos o software separados, distintos de los dispositivos de reenvío principales (enrutadores y conmutadores), como DPI y dispositivos de seguridad. [ 81 ]

Estimación de la calidad de la experiencia (QoE) mediante SDN

Al utilizar un modelo basado en SDN para la transmisión de tráfico multimedia, un aspecto importante a tener en cuenta es la estimación de la QoE. Para estimar la QoE, primero debemos poder clasificar el tráfico y, posteriormente, se recomienda que el sistema pueda resolver problemas críticos por sí mismo analizando dicho tráfico. [ 82 ] [ 83 ]

Véase también

Referencias

  1. 1 2 3 Benzekki, Kamal; El Fergougui, Abdeslam; Elbelrhiti Elalaoui, Abdelbaki (2016). "Redes definidas por software (SDN): una revisión". Security and Communication Networks . 9 (18): 5803– 5833. doi : 10.1002/sec.1737 .
  2. Montazerolghaem, Ahmadreza (2020-07-13). "Centro de datos con balanceo de carga definido por software: diseño, implementación y análisis de rendimiento" . Cluster Computing . 24 (2): 591– 610. doi : 10.1007/s10586-020-03134-x . ISSN 1386-7857 . S2CID 220490312 .  
  3. Montazerolghaem, Ahmadreza (2021). "Internet de las cosas multimedia definidas por software: gestión de recursos energéticamente eficiente y con equilibrio de carga" . IEEE Internet of Things Journal . 9 (3): 2432– 2442. doi : 10.1109/JIOT.2021.3095237 . ISSN 2327-4662 . S2CID 237801052 .  
  4. " Las empresas afirman que las redes definidas por software no son OpenFlow" . searchsdn.techtarget.com
  5. "El laboratorio de pruebas OpenFlow SDN de InCNTRE trabaja para obtener un producto SDN certificado" . 10 de febrero de 2016.
  6. "Predicción de la adopción de SD-WAN" . gartner.com. 15 de diciembre de 2015. Consultado el 27 de junio de 2016 .
  7. Mijumbi, R.; Serrat, J.; Gorricho, JL; Bouten, N.; De Turck, F.; Boutaba, R. (2016). "Virtualización de funciones de red: estado del arte y desafíos de investigación". IEEE Communications Surveys & Tutorials . 18 (1): 236– 262. arXiv : 1509.07675 . doi : 10.1109/COMST.2015.2477041 .
  8. Li, Y.; Chen, M. (2015). "Virtualización de funciones de red definidas por software: una revisión" . IEEE Access . 3 : 2542–2553 . doi : 10.1109/ACCESS.2015.2499271 .
  9. Scott-Hayward, S.; Natarajan, S.; Sezer, S. (2016). "Un estudio sobre la seguridad en redes definidas por software". IEEE Communications Surveys & Tutorials . 18 (1): 623– 654. doi : 10.1109/COMST.2015.2453114 .
  10. L. Yang (Intel Corp.), R. Dantu (Univ. del Norte de Texas), T. Anderson (Intel Corp.) y R. Gopal (Nokia.) (abril de 2004). Marco de separación de elementos de reenvío y control (ForCES) . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC3746 . RFC 3746 .{{citation}}: CS1 maint: varios nombres: lista de autores ( enlace )
  11. ^ TV Lakshman, T. Nandagopal, R. Ramjee, K. Sabnani y T. Woo (noviembre de 2004). "La arquitectura de SoftRouter" (PDF) .{{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace )
  12. J. Salim (Znyx Networks), H. Khosravi (Intel), A. Kleen (Suse) y A. Kuznetsov (INR/Swsoft) (julio de 2003). "Linux Netlink como protocolo de servicios IP" . doi : 10.17487/RFC3549 .{{cite journal}}: La cita de la revista requiere |journal=( ayuda ) CS1 maint: nombres múltiples: lista de autores ( enlace )
  13. A. Farrel (Old Dog Consulting), J. Vasseur (Cisco Systems, Inc.) y J. Ash (AT&T) (agosto de 2006). "Una arquitectura basada en elementos de cálculo de ruta (PCE)" . doi : 10.17487/RFC4655 .{{cite journal}}: La cita de la revista requiere |journal=( ayuda ) CS1 maint: nombres múltiples: lista de autores ( enlace )
  14. US20090044270A1 , Shelly, Asaf y Feldman, Moshe, "Elemento de red e infraestructura para un sistema de gestión de riesgos de red", publicado el 12 de febrero de 2009 
  15. Martín Casado, Michael J. Freedman, Justin Pettit, Jianying Luo y Nick McKeown (Universidad de Stanford) (agosto de 2007). "Etano: Tomando el control de la empresa" (PDF) .{{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace )
  16. N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker y J. Turner. (Abril de 2008). "OpenFlow: Facilitando la innovación en redes de campus" (PDF) .{{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace )
  17. N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown y S. Shenker. (julio de 2008). "NOX: Hacia un sistema operativo para redes" (PDF) .{{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace )
  18. Farías, Fernando NN; Junior, Antonio de O.; da Costa, Leonardo B.; Pinheiro, Billy A.; Abelém, Antônio JG (28/08/2019). "vSDNEmul: un emulador de red definido por software basado en virtualización de contenedores". arXiv : 1908.10980 [ cs.NI ].
  19. Wang, S.; Chou, C.; Yang, C. (septiembre de 2013). "Simulador y emulador de red OpenFlow EstiNet". IEEE Communications Magazine . 51 (9): 110– 117. Bibcode : 2013IComM..51i.110W . doi : 10.1109/MCOM.2013.6588659 . ISSN 1558-1896 . S2CID 14375937 .  
  20. Oliveira, RLS de; Schweitzer, CM; Shinoda, AA; Ligia Rodrigues Prete (junio de 2014). "Uso de Mininet para la emulación y prototipado de redes definidas por software". Conferencia Colombiana de Comunicaciones y Computación IEEE 2014 (COLCOM) . pp. 1–6 . doi : 10.1109/ColComCon.2014.6860404 . ISBN  978-1-4799-4340-1. S2CID 17915639 . 
  21. "GENI. Topología OpenFlow del Campus" . 2011.
  22. Kuang-Ching "KC" Wang (3 de octubre de 2011). "Redes definidas por software y OpenFlow para universidades: motivación, estrategia y usos" (PDF) . Archivado del original (PDF) el 3 de enero de 2018.
  23. Sushant Jain, Alok Kumar, Subhasree Mandal, Joon Ong, Leon Poutievski, Arjun Singh, Subbaiah Venkata, Jim Wanderer, Junlan Zhou, Min Zhu, Jonathan Zolla, Urs Hölzle, Stephen Stuart y Amin Vahdat (Google) (12-16 de agosto de 2013). "B4: Experiencia con una WAN definida por software implementada globalmente" (PDF) .{{cite web}}: |author=tiene nombre genérico ( ayuda ) CS1 maint: nombres múltiples: lista de autores ( enlace )
  24. Brent Salisbury (14 de mayo de 2013). "Dentro de la red definida por software de Google" . Network Computing .
  25. Arjun Singh, Joon Ong, Amit Agarwal, Glen Anderson, Ashby Armistead, Roy Bannon, Seb Boving, Gaurav Desai, Bob Felderman, Paulie Germano, Anand Kanagala, Jeff Provost, Jason Simmons, Eiichi Tanda, Jim Wanderer, Urs Hölzle, Stephen Stuart, Amin Vahdat (2015). "Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google's Datacenter Network" .{{cite web}}: CS1 maint: varios nombres: lista de autores ( enlace )
  26. ""Extensiones del protocolo OpenFlow MPLS-TP para SPTN" se convierte en un estándar ONF formal por aprobación unánime . 27 de junio de 2017.
  27. Camille Campbell (6 de febrero de 2014). "Avaya presenta innovaciones en redes en el 'Tech Field Day'"" .
  28. Elizabeth Miller Coyne (23 de septiembre de 2016). "Ejecutivo de Huawei: Las SDN se han convertido en un 'término completamente sin sentido'"." Lectura ligera . "
  29. "Definición de redes definidas por software (SDN)" . Opennetworking.org . Consultado el 26 de octubre de 2014 .
  30. Montazerolghaem, Ahmadreza; Yaghmaee, Mohammad Hossein; Leon-Garcia, Alberto (septiembre de 2020). "Redes multimedia en la nube verde: asignación de recursos energéticamente eficientes basada en NFV/SDN" . IEEE Transactions on Green Communications and Networking . 4 (3): 873– 889. Bibcode : 2020ITGCN...4..873M . doi : 10.1109/TGCN.2020.2982821 . ISSN 2473-2400 . S2CID 216188024 .  
  31. "Documentos técnicos" . Opennetworking.org . Consultado el 26 de octubre de 2014 .
  32. Montazerolghaem, Ahmadreza.; Yaghmaee, MH; Leon-Garcia, A. (2017). "OpenSIP: Hacia redes SIP definidas por software". IEEE Transactions on Network and Service Management . PP (99): 184– 199. arXiv : 1709.01320 . Bibcode : 2017arXiv170901320M . doi : 10.1109/tnsm.2017.2741258 . ISSN 1932-4537 . S2CID 3873601 .  
  33. Vicentini, Cleverton; Santin, Altair; Viegas, Eduardo; Abreu, Vilmar (enero de 2019). "Mecanismo de aprovisionamiento de recursos basado en SDN y con reconocimiento de multitenencia para la transmisión de big data en la nube". Journal of Network and Computer Applications . 126 : 133–149 . doi : 10.1016/j.jnca.2018.11.005 . S2CID 57941895 . 
  34. Assefa, Beakal Gizachew; Özkasap, Öznur (junio de 2020). "RESDN: una nueva métrica y método para el enrutamiento energéticamente eficiente en redes definidas por software" . IEEE Transactions on Network and Service Management . 17 (2): 736–749 . arXiv : 1905.12219 . Bibcode : 2020ITNSM..17..736A . doi : 10.1109/TNSM.2020.2973621 . S2CID 199442001 . 
  35. Oliveira, Tadeu F.; Xavier-de-Souza, Samuel; Silveira, Luiz F. (mayo de 2021). "Mejora de la eficiencia energética en el plano de control SDN mediante controladores multinúcleo" . Energies . 14 (11): 3161. doi : 10.3390/en14113161 .
  36. "Descripción general de la arquitectura SDN" (PDF) . Opennetworking.org . Consultado el 22 de noviembre de 2014 .
  37. Yeganeh, SH; Ganjali, Y. "Kandoo: Un marco para la descarga eficiente y escalable de aplicaciones de control" . doi : 10.1145/2342441.2342446 . S2CID 193153 . {{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
  38. Ahmed, R.; Boutaba, R. (2014). "Consideraciones de diseño para la gestión de redes definidas por software de área amplia". IEEE Communications Magazine . 52 (7): 116– 123. Bibcode : 2014IComM..52g.116A . doi : 10.1109/MCOM.2014.6852092 . S2CID 7912785 . 
  39. Koponen, T. (2010). "Onix: Una plataforma de control distribuido para redes de producción a gran escala" (PDF) . Actas de USENIX, Ser. OSDI'10 . Vancouver, Canadá.
  40. Tuncer, Daphne; Charalambides, Marinos; Clayman, Stuart; Pavlou, George (marzo de 2015). "Gestión y control adaptativos de recursos en redes definidas por software" . IEEE Transactions on Network and Service Management . 12 (1): 18– 33. Bibcode : 2015ITNSM..12...18T . doi : 10.1109/TNSM.2015.2402752 . hdl : 10044/1/63600 . S2CID 9215618 . 
  41. Heller, B.; Sherwood, R.; McKeown, N. (2012). "El problema de la ubicación del controlador". Actas del primer taller sobre temas candentes en redes definidas por software - HotSDN '12 . pág. 7. doi : 10.1145/2342441.2342444 . ISBN  9781450314770. S2CID 1770114 . 
  42. Hu, Yan-nan; Wang, Wen-Dong; Gong, Xiang-Yang; Que, Xi-Rong; Cheng, Shi-Duan (2012). "Sobre la ubicación de controladores en redes definidas por software". The Journal of China Universities of Posts and Telecommunications . 19 : 92– 171. doi : 10.1016/S1005-8885(11)60438-X .
  43. Ros, Francisco Javier; Ruiz, Pedro Miguel (2014). "Cinco nueves de fiabilidad en la red sur en redes definidas por software". Actas del tercer taller sobre temas candentes en redes definidas por software . pp. 31–36 . doi : 10.1145/2620728.2620752 . ISBN  9781450329897. S2CID 17088018 . 
  44. Tuncer, Daphne; Charalambides, Marinos; Clayman, Stuart; Pavlou, George (2015). «Sobre la ubicación de la funcionalidad de gestión y control en redes definidas por software». 11.ª Conferencia Internacional sobre Gestión de Redes y Servicios (CNSM) de 2015. pp. 360–365 . doi : 10.1109/CNSM.2015.7367383 . ISBN  978-3-9018-8277-7. S2CID 6977724 . 
  45. Wang, An; Guo, Yang; Hao, Fang; Lakshman, T.; Chen, Songqing (2 de diciembre de 2014). "Scotch: Escalado elástico del plano de control SDN mediante superposición basada en vSwitch" (PDF) . ACM CoNEXT .
  46. Taylor, Curtis; MacFarland, Douglas; Smestad, Doran; Shue, Craig (10 de abril de 2014). "Control de acceso contextual basado en flujo con técnicas SDN escalables basadas en host" . IEEE INFOCOM 2016 - 35.ª Conferencia Internacional Anual IEEE sobre Comunicaciones Informáticas . págs. 1-9 . doi : 10.1109/INFOCOM.2016.7524498 . ISBN  978-1-4673-9953-1. S2CID 17491115 . 
  47. Chuluundorj, Zorigtbaatar; Taylor, Curtis; Walls, Robert; Shue, Craig (6 de diciembre de 2021). "¿Puede el usuario ayudar? Aprovechamiento de las acciones del usuario para la elaboración de perfiles de red". Octava Conferencia Internacional sobre Sistemas Definidos por Software (SDS) de 2021. págs. 1-8 . doi : 10.1109/SDS54264.2021.9732164 . ISBN  978-1-6654-5820-7. S2CID 244036711 . 
  48. Lei, Yunsen; Lanson, Julian; Kaldawy, Remy; Estrada, Jeffrey; Shue, Craig (11 de noviembre de 2020). "¿Puede SDNS basado en host rivalizar con las capacidades de ingeniería de tráfico de SDNS basado en conmutador?". 11.ª Conferencia Internacional sobre Redes del Futuro (NoF) de 2020. págs. 91-99 . doi : 10.1109/NoF50125.2020.9249110 . ISBN  978-1-7281-8055-7. S2CID 221505891 . 
  49. "OpenFlow: Proactivo vs Reactivo" . NetworkStatic.net . 15 de enero de 2013. Consultado el 1 de julio de 2014 .
  50. "Reactivo, proactivo, predictivo: modelos SDN | F5 DevCentral" . Devcentral.f5.com . 11 de octubre de 2012. Consultado el 30 de junio de 2016 .
  51. Pentikousis, Kostas; Wang, Yan; Hu, Weihua (2013). "Mobileflow: Hacia redes móviles definidas por software". IEEE Communications Magazine . 51 (7): 44– 53. Bibcode : 2013IComM..51g..44P . doi : 10.1109/MCOM.2013.6553677 . S2CID 10655582 . 
  52. Liyanage, Madhusanka (2015). Redes móviles definidas por software (SDMN): Más allá de la arquitectura de red LTE . Reino Unido: John Wiley. págs. 1–438 . ISBN  978-1-118-90028-4.
  53. Costa-Requena, José; Liyanage, Madhusanka; Ylianttila, Mika; De Oca, Edgardo Montes; Santos, Jesús Llorente; Guasch, Vicent Ferrer; Ahokas, Kimmo; Premsankar, Gopika; Luukkainen, Sakari; Pérez, Óscar López; Itzazelaia, Mikel Uriarte; Ahmad, Ijaz (2015). "Integración SDN y NFV en arquitectura de red móvil generalizada". 2015 Conferencia Europea sobre Redes y Comunicaciones (EuCNC) . págs. 154-158 . doi : 10.1109/EuCNC.2015.7194059 . ISBN  978-1-4673-7359-3. S2CID 2453962 . 
  54. Liyanage, Madhusanka; Ylianttila, Mika; Gurtov, Andrei (2014). «Asegurando el canal de control de redes móviles definidas por software». Actas del Simposio Internacional IEEE sobre un Mundo de Redes Inalámbricas, Móviles y Multimedia 2014. págs. 1–6 . doi : 10.1109/WoWMoM.2014.6918981 . ISBN  978-1-4799-4786-7. S2CID 1378181 . 
  55. Haranas, Mark (8 de octubre de 2016). "16 productos de redes populares que le dan un toque especial a SD-WAN" . CRN . Consultado el 1 de noviembre de 2016 .
  56. "SD-WAN: Qué es y por qué la usarás algún día" . Network World . 10 de febrero de 2016. Consultado el 27 de junio de 2016 .
  57. ^ Serries, William (12 de septiembre de 2016). "SD-LAN y SD-WAN: dos enfoques diferentes para las redes definidas por software" . ZDNet . Consultado el 1 de noviembre de 2016 .
  58. Kerravala, Zeus (13 de septiembre de 2016). "Aerohive presenta la LAN definida por software" . Network World . Consultado el 1 de noviembre de 2016 .
  59. Kreutz, Diego; Ramos, Fernando; Verissimo, Paulo (2013). "Hacia redes definidas por software seguras y confiables". Actas del segundo taller ACM SIGCOMM sobre temas candentes en redes definidas por software . págs. 50–60 . 
  60. Scott-Hayward, Sandra; O'Callaghan, Gemma; Sezer, Sakir (2013). "Seguridad SDN: una revisión". Future Networks and Services (SDN4FNS), 2013 IEEE SDN for . pp. 1– 7. 
  61. Benton, Kevin; Camp, L Jean; Small, Chris (2013). "Evaluación de vulnerabilidades de Openflow". Actas del segundo taller ACM SIGCOMM sobre temas candentes en redes definidas por software . págs. 151–152 . 
  62. Abdou, AbdelRahman; van Oorschot, Paul; Wan, Tao (mayo de 2018). "Un marco y análisis comparativo de la seguridad del plano de control de redes SDN y convencionales". IEEE Communications Surveys and Tutorials . Próxima publicación. arXiv : 1703.06992 . Bibcode : 2017arXiv170306992A .
  63. Giotis, K; Argyropoulos, Christos; Androulidakis, Georgios; Kalogeras, Dimitrios; Maglaris, Vasilis (2014). "Combinación de OpenFlow y sFlow para un mecanismo eficaz y escalable de detección y mitigación de anomalías en entornos SDN" . Computer Networks . 62 : 122–136 . doi : 10.1016/j.bjp.2013.10.014 .
  64. Braga, Rodrigo; Mota, Edjard; Passito, Alexandre (2010). "Detección ligera de ataques de inundación DDoS mediante NOX/OpenFlow". Redes de computadoras locales (LCN), 35.ª Conferencia IEEE de 2010. pp. 408–415 . 
  65. Feamster, Nick (2010). "Subcontratación de la seguridad de redes domésticas". Actas del taller ACM SIGCOMM 2010 sobre redes domésticas . págs. 37–42 . 
  66. Jin, Ruofan y Wang, Bing (2013). "Detección de malware para dispositivos móviles mediante redes definidas por software". Taller de Investigación y Experimentación Educativa (GREE), 2013 Segundo GENI . 81-88.{{cite conference}}: CS1 mantenimiento: ubicación ( enlace )
  67. Jafarian, Jafar Haadi; Al-Shaer, Ehab; Duan, Qi (2012). "Mutación aleatoria de host de Openflow: defensa transparente de objetivo móvil mediante redes definidas por software". Actas del primer taller sobre temas candentes en redes definidas por software . págs. 127–132 . 
  68. Kampanakis, Panos; Perros, Harry; Beyene, Tsegereda. Soluciones basadas en SDN para la protección de redes Moving Target Defense (PDF) . Consultado el 16 de febrero de 2022 .
  69. 1 2 Sherwood, Rob; Gibb, Glen; Yap, Kok-Kiong; Appenzeller, Guido; Casado, Martin; McKeown, Nick; Parulkar, Guru (2009). "Flowvisor: Una capa de virtualización de red". OpenFlow Switch Consortium, Informe técnico .
  70. Al-Shaer, Ehab y Al-Haj, Saeed (2010). "FlowChecker: Análisis y verificación de la configuración de infraestructuras OpenFlow federadas". Actas del 3er taller de ACM sobre configuración de seguridad fiable y utilizable . págs. 37–44 . 
  71. Canini, Marco; Venzano, Daniele; Peresini, Pedro; Kostic, Dejan; Rexford, Jennifer; et al. (2012). Una forma AGRADABLE de probar aplicaciones OpenFlow . INDE. págs. 127-140 .  
  72. Bernardo y Chua (2015). Introducción y análisis de la arquitectura de seguridad SDN y NFV (SA-SECA) . 29.º IEEE AINA 2015. págs. 796–801 . 
  73. B. Pfaf; et al. (28 de febrero de 2011). "Especificación del conmutador OpenFlow" (PDF) . Consultado el 8 de julio de 2017 . 
  74. T. Zhu; et al. (18 de octubre de 2016). "MCTCP: TCP multicast robusto y con conciencia de la congestión en redes definidas por software". 2016 IEEE/ACM 24th International Symposium on Quality of Service (IWQoS) . IEEE. págs. 1–10 . doi : 10.1109/IWQoS.2016.7590433 . ISBN   978-1-5090-2634-0. S2CID 28159768 . 
  75. M. Noormohammadpour; et al. (10 de julio de 2017). "DCCast: Transferencias eficientes de punto a multipunto a través de centros de datos" . USENIX . Consultado el 3 de julio de 2017 . 
  76. M. Noormohammadpour; et al. (2018). QuickCast: Transferencias rápidas y eficientes entre centros de datos mediante cohortes de árboles de reenvío . arXiv : 1801.00837 . Bibcode : 2018arXiv180100837N . doi : 10.31219/osf.io/uzr24 . Consultado el 23 de enero de 2018 . 
  77. 1 2 William, Stalling (2016). "Fundamentos de las redes modernas: SDN, NFV, QoE, IoT y nube". Pearson Education .
  78. Rowayda, A. Sadek (mayo de 2018). "Una arquitectura de red definida por software (SDN) ágil basada en Internet de las cosas (IoT)". Revista Egipcia de Ciencias de la Computación . 42 (2): 13– 29.
  79. "Plataforma para infraestructura virtual y física de múltiples proveedores" .
  80. ^ Graham, Finnie (diciembre de 2012). "El papel del DPI en un mundo SDN". Libro Blanco .
  81. Serie, Y. (mayo de 2015). "Infraestructura global de información, aspectos del protocolo de Internet y redes de próxima generación". Serie ITU-T Y.2770, Suplemento sobre casos de uso y escenarios de aplicación de DPI .
  82. Canovas, Alejandro (2020). "Un sistema de gestión robusto de tráfico multimedia basado en SDN que utiliza patrones y modelos de estimación de QoE con BRNN" . Journal of Network and Computer Applications . 150 102498. doi : 10.1016/j.jnca.2019.102498 . hdl : 10251/163292 . S2CID 210925444 . 
  83. Rego, Albert (2019). "Adaptación del aprendizaje por refuerzo para la transmisión multimedia en SDN" . Transactions on Emerging Telecommunications Technologies . 30 (9) e3643. doi : 10.1002/ett.3643 . hdl : 10251/186852 . S2CID 182028234 .