stringtranslate.com

Redes definidas por software

La red definida por software ( SDN ) es un enfoque de gestión de red que utiliza la abstracción para permitir una configuración de red dinámica y programáticamente eficiente para crear agrupaciones y segmentaciones al tiempo que mejora el rendimiento y la supervisión de la red de una manera más parecida a la computación en la nube que a la gestión de red tradicional. [1] La SDN está destinada a mejorar la arquitectura estática de las redes tradicionales y puede 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 los cerebros de la red SDN, donde se incorpora toda la inteligencia. Sin embargo, la centralización tiene ciertos inconvenientes relacionados 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]

Historia

La historia de los principios de SDN se remonta a la separación del plano de control y de datos utilizada por primera vez en las redes telefónicas públicas conmutadas. [ cita requerida ] Esto proporcionó una manera de simplificar el aprovisionamiento y la gestión años antes de que la arquitectura se utilizara en redes de datos.

El Grupo de Trabajo de Ingeniería de Internet (IETF) comenzó a considerar varias formas de disociar 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 Control y Reenvío (Forces). [7] El Grupo de Trabajo ForCES también propuso una arquitectura complementaria SoftRouter. [8] Otros estándares tempranos del IETF que buscaban separar el control de los datos incluyen Linux Netlink como un protocolo de servicios IP [9] y una arquitectura basada en elementos de cálculo de ruta (PCE). [10]

Estos primeros intentos no tuvieron éxito. Una de las razones es que muchos en la comunidad de Internet consideraban que separar el control de los datos era riesgoso, especialmente dada la posibilidad de que fallara 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 generara una mayor competencia.

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 diseño simple de los conmutadores de Ethane condujo a la creación de OpenFlow, [11] y una API para OpenFlow se creó por primera vez en 2008. [12] Ese mismo año, se creó NOX, un sistema operativo para redes. [13]

En 2007, investigadores independientes presentaron varias solicitudes de patente que describían aplicaciones prácticas para SDN, [14] sistemas operativos para redes, [15] unidades de cómputo de infraestructura de red como una CPU multinúcleo [16] y un método para la segmentación de redes virtuales basado en la funcionalidad. [17] Estas solicitudes se hicieron públicas en 2009 y desde entonces han sido abandonadas.

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

El trabajo sobre OpenFlow continuó en Stanford, incluida la creación de bancos de pruebas para evaluar el uso del protocolo en una única red de campus, así como en toda la WAN como columna vertebral para conectar varios campus. [21] En entornos académicos, hubo 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] [ verificación fallida ]

Más allá del ámbito académico, las primeras implementaciones fueron las de Nicira en 2010 para controlar OVS desde Onix, codesarrollado con NTT y Google. Una implementación notable fue la de B4 de Google en 2012. [23] [24] Más tarde, Google anunció las primeras implementaciones de OpenFlow/Onix en sus centros de datos. [25] Otra gran implementación existe 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 puente 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 entrega de servicios. [27] [28]

Concepto

Las arquitecturas SDN desacoplan las funciones de control de red ( plano de control ) y de reenvío ( plano de datos ), lo que permite que el control de red se vuelva directamente programable y que la infraestructura subyacente se abstraiga de las aplicaciones y los servicios de red. [29]

El protocolo OpenFlow se puede utilizar en tecnologías SDN. La arquitectura SDN es:

Nueva arquitectura de red

La explosión de dispositivos y contenidos móviles, la virtualización de servidores y la llegada de los servicios en la nube son algunas de las tendencias que están impulsando a la industria de las 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 informática cliente-servidor era dominante, pero una arquitectura tan estática puede resultar inadecuada 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
En el 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, lo que crea una oleada de tráfico de máquina a máquina de este a oeste antes de devolver los datos al dispositivo del usuario final en el patrón de tráfico norte-sur clásico . Al mismo tiempo, los usuarios están cambiando los patrones de tráfico de red a medida que presionan para acceder a contenido y aplicaciones corporativas desde cualquier tipo de dispositivo, conectándose desde cualquier lugar y en cualquier momento. Por último, muchos administradores de centros de datos empresariales están implementando un modelo de computación de servicios públicos, 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 computadoras portátiles, para acceder a la red corporativa. El departamento de TI se encuentra bajo presión para adaptarse a estos dispositivos personales de manera detallada, al tiempo que protege los datos corporativos y la propiedad intelectual y cumple con los mandatos de cumplimiento normativo.
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 quieren la agilidad necesaria para acceder a aplicaciones, infraestructura y otros recursos de TI a pedido y de forma discreta. La planificación de TI para los servicios de nube debe realizarse en un entorno de mayores requisitos de seguridad, cumplimiento y auditoría, junto con reorganizaciones, consolidaciones y fusiones empresariales que pueden cambiar rápidamente las suposiciones. Ofrecer un aprovisionamiento de autoservicio, ya sea en una nube privada o pública, requiere un escalamiento elástico de los recursos informáticos, de almacenamiento y de red, idealmente desde un punto de vista común y con un conjunto común de herramientas.
Big data significa más ancho de banda
El manejo de los grandes datos 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 a gran escala se enfrentan a la abrumadora tarea de escalar la red a un tamaño antes inimaginable, manteniendo la conectividad de cualquier dispositivo con un presupuesto limitado. [33]
Consumo de energía en grandes centros de datos
A medida que surgieron la Internet de las cosas , la computación en la nube y el SaaS , la necesidad de centros de datos más grandes aumentó el consumo de energía de esas instalaciones. Muchos investigadores han mejorado la eficiencia energética de SDN aplicando técnicas de enrutamiento existentes para ajustar dinámicamente el plano de datos de la red para 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

Una descripción general de alto nivel de la arquitectura de red definida por software

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

Aplicación SDN
Las aplicaciones SDN son programas que comunican de forma explícita, directa y programática sus requisitos de red y el comportamiento de red deseado al controlador SDN a través de una interfaz en dirección norte (NBI). Además, pueden consumir una vista abstracta de la red para sus propósitos de toma de decisiones internas. Una aplicación SDN consta de una lógica de aplicación SDN y uno o más controladores NBI. Las aplicaciones SDN pueden exponer por sí mismas otra capa de control de red abstracto, ofreciendo así una o más NBI de nivel superior a través de los respectivos agentes NBI.
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 interfaz de plano de datos (CDPI). La definición como entidad lógicamente centralizada no prescribe ni excluye detalles de implementación 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 los recursos de red.
Ruta de datos de SDN
El SDN Datapath es un dispositivo de red lógico que expone la visibilidad y el control indiscutible sobre sus capacidades anunciadas de reenvío y procesamiento de datos. La representación lógica puede abarcar todos o un subconjunto de los recursos físicos del sustrato. Un SDN Datapath comprende un agente CDPI y un conjunto de uno o más motores de reenvío de tráfico y cero o más funciones de procesamiento de tráfico. Estos motores y funciones pueden incluir un reenvío simple entre las interfaces externas del datapath o funciones internas de procesamiento o terminación de tráfico. Uno o más SDN Datapath pueden estar contenidos en un único elemento de red (físico), una combinación física integrada de recursos de comunicaciones, gestionados como una unidad. Un SDN Datapath también puede definirse en varios elementos físicos de red. Esta definición lógica no prescribe ni excluye detalles de implementación como el mapeo lógico a físico, la gestión de recursos físicos compartidos, la virtualización o segmentación del SDN Datapath, la interoperabilidad con redes que no sean SDN ni la funcionalidad de procesamiento de datos, que puede incluir funciones de capa 4 a 7 de OSI .
Interfaz de control de SDN a plano de datos (CDPI)
La CDPI de SDN es la interfaz definida entre un controlador de SDN y una ruta de datos de SDN, que proporciona al menos (i) control programático de todas las operaciones de reenvío, (ii) publicidad de capacidades, (iii) generación de informes estadísticos y (iv) notificación de eventos. Un valor de SDN reside en la expectativa de que la CDPI se implemente de una manera abierta, independiente del proveedor e interoperable.
Interfaces de dirección norte de SDN (NBI)
Las interfaces NBI de SDN son interfaces entre las aplicaciones SDN y los controladores SDN y, por lo general, proporcionan vistas abstractas de la red y permiten la expresión directa del comportamiento y los requisitos de la red. Esto puede ocurrir en cualquier nivel de abstracción (latitud) y en diferentes conjuntos de funcionalidades (longitud). Un valor de SDN radica en la expectativa de que estas interfaces se implementen de una manera abierta, independiente del proveedor e interoperable.

Plano de control SDN

Centralizado - Jerárquico - Distribuido

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 tiene una vista global de la red. Si bien esto simplifica la implementación de la lógica de control, tiene limitaciones de escalabilidad a medida que aumenta el tamaño y la dinámica de la red. Para superar estas limitaciones, se han propuesto varios enfoques en la literatura que se dividen en dos categorías: enfoques jerárquicos y completamente distribuidos. En las soluciones jerárquicas, [37] [38] los controladores distribuidos operan en una vista de red particionada, mientras que las decisiones que requieren conocimiento de toda la red las toma un controlador raíz lógicamente centralizado. En los enfoques distribuidos, [39] [40] los controladores operan en su vista local o pueden intercambiar mensajes de sincronización para mejorar su conocimiento. Las soluciones distribuidas son más adecuadas para admitir aplicaciones SDN adaptativas.

Colocación del controlador

Una cuestión clave al diseñar un plano de control SDN distribuido es decidir la cantidad y la ubicación de las entidades de control. Un parámetro importante a tener en cuenta al hacerlo es el retardo de propagación entre los controladores y los dispositivos de red, [41] especialmente en el contexto de redes grandes. Otros objetivos que se han considerado incluyen la confiabilidad de la ruta de control, [42] la tolerancia a fallas, [43] y los requisitos de la aplicación. [44]

Plano de datos SDN

En SDN, el plano de datos es responsable 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 implementaciones de software, como Open vSwitch . La capacidad de memoria de los conmutadores de hardware puede limitar la cantidad de reglas que se pueden almacenar, mientras que las implementaciones de software pueden tener una mayor capacidad. [45]

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

Las entradas de la tabla de flujo se pueden completar de manera proactiva, reactiva o híbrida. [49] [50] En el modo proactivo, el controlador completa las entradas de la tabla de flujo para todas las posibles coincidencias de tráfico posibles para este conmutador con anticipación. Este modo se puede comparar con las entradas de la tabla de enrutamiento típicas actuales, donde todas las entradas estáticas se instalan con anticipación. Después de esto, 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 velocidad de línea (considerando todas las entradas de la tabla de flujo en TCAM) y no se agrega demora. En el modo reactivo, las entradas se completan a pedido. 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 en el modo reactivo. 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 confía en la flexibilidad del procesamiento del modo reactivo para el tráfico restante.

Aplicaciones

SDMN

La red móvil definida por software (SDMN) [51] [52] es 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 básicos tanto en la red central como en la red de acceso por 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 red central móvil con el protocolo PFCP .

Red de área amplia definida por software (SD-WAN)

Una SD-WAN es una WAN administrada mediante los principios de redes definidas por software. [55] El principal impulsor de la SD-WAN es reducir los costos de la WAN mediante líneas arrendadas más asequibles y disponibles comercialmente, como una alternativa o reemplazo parcial de las líneas MPLS más costosas . El control y la gestión se administran por separado del hardware con controladores centrales que permiten una configuración y administración más sencillas. [56]

Red de área local definida por software

Una SD-LAN es una red de área local (LAN) construida en torno a 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 la gestión del control y los planos de datos para permitir una arquitectura basada en políticas para redes LAN cableadas e inalámbricas. Las SD-LAN se caracterizan por el uso de un sistema de gestión en la nube y la 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 vista central de la red que tiene el controlador y a su capacidad de reprogramar el plano de datos en cualquier momento. Si bien la seguridad de la arquitectura SDN en sí misma sigue siendo una cuestión abierta que ya se ha estudiado un par de veces en la comunidad de investigación, [59] [60] [61] [62] los párrafos siguientes solo se centran en las aplicaciones de seguridad que se hicieron posibles o se revisaron utilizando SDN.

Varios trabajos de investigación sobre SDN ya han investigado aplicaciones de seguridad construidas sobre el controlador SDN, con diferentes objetivos en mente. La detección y mitigación de ataques distribuidos de denegación de servicio (DDoS), [63] [64] así como la propagación de botnets [65] y gusanos, [66] son ​​algunos casos de uso concretos de tales aplicaciones: básicamente, la idea consiste en recopilar periódicamente estadísticas de red desde el plano de reenvío de la red de una manera estandarizada (por ejemplo, utilizando Openflow), y luego aplicar algoritmos de clasificación sobre esas estadísticas para detectar cualquier anomalía en la red. Si se detecta una anomalía, la aplicación le indica al controlador cómo reprogramar el plano de datos para mitigarla.

Otro tipo de aplicación de seguridad aprovecha el controlador SDN implementando algunos algoritmos de defensa de objetivo móvil (MTD). Los algoritmos MTD se utilizan normalmente para dificultar de lo habitual cualquier ataque a un sistema o red determinados ocultando o modificando periódicamente las propiedades clave de ese sistema o red. En las redes tradicionales, la implementación de algoritmos MTD no es una tarea trivial, ya que es difícil construir 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 vuelven más sencillas gracias a la centralidad del controlador. Por ejemplo, una aplicación puede asignar periódicamente direcciones IP virtuales a los hosts dentro de la red, y el controlador realiza entonces la asignación de direcciones IP virtuales/reales. [67] Otra aplicación puede simular algunos puertos falsos abiertos/cerrados/filtrados en hosts aleatorios de la red para añadir ruido significativo durante la fase de reconocimiento (por ejemplo, escaneo) realizada por un atacante. [68]

También se puede obtener un valor adicional en cuanto a seguridad en redes habilitadas para SDN utilizando FlowVisor [69] y FlowChecker [70] respectivamente. 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 se pueden utilizar para fines de producción y desarrollo, así como para separar la supervisión, la configuración y el tráfico de Internet, donde cada escenario puede tener su propia topología lógica que se denomina slice. Junto con este enfoque, FlowChecker [69] realiza la validación de nuevas reglas OpenFlow que son implementadas por los usuarios utilizando su propio slice.

Las aplicaciones de controlador SDN se implementan principalmente en escenarios de gran escala, lo que requiere verificaciones exhaustivas de posibles errores de programación. En 2012 se describió un sistema para hacer esto llamado NICE . [71] La introducción de una arquitectura de seguridad general requiere un enfoque integral y prolongado para SDN. Desde su introducción, los diseñadores están buscando posibles formas de proteger SDN que no comprometan la escalabilidad. Una arquitectura llamada Arquitectura de seguridad SN-SECA (SDN + NFV). [72]

Entrega de datos grupales mediante SDN

Las aplicaciones distribuidas que se ejecutan en centros de datos suelen replicar datos con el fin de sincronizar, resistir fallos, equilibrar la carga y acercar los datos a los usuarios (lo que reduce la latencia para los usuarios y aumenta su 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 confiable de datos desde una máquina a varias máquinas se conoce como Entrega de datos grupales confiables (RGDD).

Los conmutadores SDN se pueden utilizar 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 grupos desde la versión 1.1 [73], lo que hace que esto sea posible. Mediante SDN, un controlador central puede configurar de forma cuidadosa e inteligente á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 en centros de datos sobre WAN privadas.

Relación con NFV

La virtualización de funciones de red , o NFV para abreviar, es un concepto que complementa a SDN. Por lo tanto, NFV no depende de SDN o conceptos de SDN. NFV separa el software del hardware para permitir una implementación de red flexible y una operación dinámica. Las implementaciones de NFV generalmente utilizan servidores básicos para ejecutar versiones de software de servicios de red que anteriormente estaban basadas en hardware. Estos servicios basados ​​en software que se ejecutan en un entorno NFV se denominan funciones de red virtual (VNF). [77] El programa híbrido SDN-NFV se proporcionó para capacidades de alta eficiencia, elásticas y escalables. NFV tenía como objetivo 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 NFV se proporciona para las aplicaciones de red mediante el uso de servidores virtualizados. Es completamente posible implementar una función de red virtualizada (VNF) como una entidad independiente utilizando paradigmas de red y orquestación existentes. Sin embargo, existen beneficios inherentes en aprovechar los conceptos de SDN para implementar y gestionar una infraestructura NFV, particularmente cuando se analiza la gestió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 el DPI

La inspección profunda de paquetes DPI proporciona a la red un reconocimiento de aplicaciones, mientras que la SDN proporciona a las aplicaciones un reconocimiento de redes. [80] Aunque la SDN cambiará radicalmente las arquitecturas de red genéricas, debería poder trabajar con arquitecturas de red tradicionales para ofrecer una alta interoperabilidad. La nueva arquitectura de red basada en SDN debería considerar todas las capacidades que actualmente se proporcionan en dispositivos o software separados además de los dispositivos de reenvío principales (routers y switches) como la DPI y los dispositivos de seguridad [81].

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

Al utilizar un modelo basado en SDN para transmitir 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 luego, se recomienda que el sistema pueda resolver problemas críticos por sí solo analizando el tráfico. [82] [83]

Véase también

Referencias

  1. ^ abc Benzekki, Kamal; El Fergougui, Abdeslam; Elbelrhiti Elalaoui, Abdelbaki (2016). "Redes definidas por software (SDN): una encuesta". Seguridad y redes de comunicación . 9 (18): 5803–5833. doi :10.1002/sec.1737.
  2. ^ Montazerolghaem, Ahmadreza (13 de julio de 2020). "Centro de datos con equilibrio de carga definido por software: diseño, implementación y análisis de rendimiento". Computación en clúster . 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 definida por software: gestión de recursos con equilibrio de carga y eficiencia energética". Revista IEEE Internet of Things . 9 (3): 2432–2442. doi :10.1109/JIOT.2021.3095237. ISSN  2327-4662. S2CID  237801052.
  4. ^ "Las redes definidas por software no son OpenFlow, proclaman las empresas". searchsdn.techtarget.com .
  5. ^ "El laboratorio de pruebas SDN OpenFlow 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. ^ L. Yang (Intel Corp.), R. Dantu (Universidad del Norte de Texas), T. Anderson (Intel Corp.) y R. Gopal (Nokia) (abril de 2004). Marco de trabajo ForCES (Forwarding and Control Element Separation). Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC3746 . RFC 3746.{{citation}}: CS1 maint: multiple names: authors list (link)
  8. ^ TV Lakshman, T. Nandagopal, R. Ramjee, K. Sabnani y T. Woo (noviembre de 2004). "La arquitectura de SoftRouter" (PDF) .{{cite web}}: CS1 maint: multiple names: authors list (link)
  9. ^ 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}}: Requiere citar revista |journal=( ayuda )CS1 maint: multiple names: authors list (link)
  10. ^ 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}}: Requiere citar revista |journal=( ayuda )CS1 maint: multiple names: authors list (link)
  11. ^ 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: multiple names: authors list (link)
  12. ^ N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker y J. Turner. (Abril de 2008). "OpenFlow: Habilitación de la innovación en redes de campus" (PDF) .{{cite web}}: CS1 maint: multiple names: authors list (link)
  13. ^ 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: multiple names: authors list (link)
  14. ^ Solicitud estadounidense 2009044270, Shelly, Asaf y Feldman, Moshe, "Elemento de red y una infraestructura para un sistema de gestión de riesgos de red", publicada el 12 de febrero de 2009  , abandonada en 2011.
  15. ^ Solicitud WO 2009010982, Shelly, Asaf, "Software para una infraestructura en tiempo real", publicada el 22 de enero de 2009 
  16. ^ Solicitud WO 2009004628, Shelly, Asaf, "CPU multinúcleo", publicada el 8 de enero de 2009 
  17. ^ Solicitud WO 2009093237, Shelly, Asaf, "Gestión de interacciones de red utilizando marcos de interés y anillos de despeje", publicada el 30 de julio de 2009 
  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 de flujo abierto EstiNet". Revista de comunicaciones IEEE . 51 (9): 110–117. 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 emulación y prototipado de redes definidas por software". 2014 IEEE Colombian Conference on Communications and Computing (COLCOM) . pp. 1–6. doi :10.1109/ColComCon.2014.6860404. ISBN 978-1-4799-4340-1. Número de identificación del sujeto  17915639.
  21. ^ "GENI. Topología Campus OpenFlow". 2011.
  22. ^ Kuang-Ching "KC" Wang (3 de octubre de 2011). "Software Defined Networking y OpenFlow para universidades: motivación, estrategia y usos" (PDF) . Archivado desde el 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 al 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: multiple names: authors list (link)
  24. ^ Brent Salisbury (14 de mayo de 2013). "Dentro de la red definida por software de Google".
  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: Una década de topologías cerradas y control centralizado en la red de centros de datos de Google".{{cite web}}: CS1 maint: multiple names: authors list (link)
  26. ^ ""MPLS-TP OpenFlow Protocol Extensions for 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). "Huawei Exec: SDN se ha 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 ecológica: asignación de recursos energéticamente eficiente basada en NFV/SDN". Transacciones IEEE sobre comunicaciones y redes ecológicas . 4 (3): 873–889. doi :10.1109/TGCN.2020.2982821. ISSN  2473-2400. S2CID  216188024.
  31. ^ "Libros blancos". Opennetworking.org . Consultado el 26 de octubre de 2014 .
  32. ^ Montazerolghaem, Ahmadreza.; Yaghmaee, MH; Leon-Garcia, A. (2017). "OpenSIP: Hacia una red SIP definida 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 múltiples usuarios 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". Transacciones IEEE sobre gestión de redes y servicios . 17 (2): 736–749. arXiv : 1905.12219 . 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}}: Requiere citar revista |journal=( ayuda )
  38. ^ Ahmed, R.; Boutaba, R. (2014). "Consideraciones de diseño para la gestión de redes definidas por software de área amplia". Revista IEEE Communications . 52 (7): 116–123. 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 USENIX, Ser. OSDI'10 . Vancouver, Canadá.
  40. ^ Tuncer, Daphne; Charalambides, Marinos; Clayman, Stuart; Pavlou, George (marzo de 2015). "Gestión y control adaptativo de recursos en redes definidas por software". IEEE Transactions on Network and Service Management . 12 (1): 18–33. 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 de actualidad en redes definidas por software - HotSDN '12 . p. 7. doi :10.1145/2342441.2342444. ISBN 9781450314770. Número de identificación del sujeto  1770114.
  42. ^ Hu, Yan-nan; Wang, Wen-Dong; Gong, Xiang-Yang; Que, Xi-Rong; Cheng, Shi-Duan (2012). "Sobre la colocación de controladores en redes definidas por software". Revista de Universidades de Correos y Telecomunicaciones de China . 19 : 92–171. doi :10.1016/S1005-8885(11)60438-X.
  43. ^ Ros, Francisco Javier; Ruiz, Pedro Miguel (2014). "Cinco nueves de la fiabilidad en dirección sur en redes definidas por software". Actas del tercer taller sobre temas de actualidad en redes definidas por software . pp. 31–36. doi :10.1145/2620728.2620752. ISBN 9781450329897. Número de identificación del sujeto  17088018.
  44. ^ Tuncer, Daphne; Charalambides, Marinos; Clayman, Stuart; Pavlou, George (2015). "Sobre la colocación de la funcionalidad de gestión y control en redes definidas por software". 2015 11.ª Conferencia internacional sobre gestión de redes y servicios (CNSM). págs. 360–365. doi :10.1109/CNSM.2015.7367383. ISBN 978-3-9018-8277-7.S2CID6977724  .​
  45. ^ Wang, An; Guo, Yang; Hao, Fang; Lakshman, T.; Chen, Songqing (2 de diciembre de 2014). "Scotch: Escalado elástico del plano de control de 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 - la 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. Número de identificación del sujeto  17491115.
  47. ^ Chuluundorj, Zorigtbaatar; Taylor, Curtis; Walls, Robert; Shue, Craig (6 de diciembre de 2021). "¿Puede ayudar el usuario? Aprovechar las acciones del usuario para la creación de perfiles de red". 2021 Octava Conferencia Internacional sobre Sistemas Definidos por Software (SDS) . págs. 1–8. doi :10.1109/SDS54264.2021.9732164. ISBN 978-1-6654-5820-7.S2CID244036711  .​
  48. ^ Lei, Yunsen; Lanson, Julian; Kaldawy, Remy; Estrada, Jeffrey; Shue, Craig (11 de noviembre de 2020). "¿Pueden los SDNS basados ​​en host rivalizar con las capacidades de ingeniería de tráfico de los SDNS basados ​​en conmutadores?". 2020 11.ª Conferencia internacional sobre la red del futuro (NoF) . págs. 91–99. doi :10.1109/NoF50125.2020.9249110. ISBN 978-1-7281-8055-7. Número de identificación del sujeto  221505891.
  49. ^ "OpenFlow: Proactivo vs. Reactivo". NetworkStatic.net . 2013-01-15 . Consultado el 2014-07-01 .
  50. ^ "Reactivo, proactivo, predictivo: modelos SDN | F5 DevCentral". Devcentral.f5.com . 2012-10-11 . Consultado el 2016-06-30 .
  51. ^ Pentikousis, Kostas; Wang, Yan; Hu, Weihua (2013). "Mobileflow: Hacia redes móviles definidas por software". Revista IEEE Communications . 51 (7): 44–53. 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. pp. 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. Número de identificación del sujeto  2453962.
  54. ^ Liyanage, Madhusanka; Ylianttila, Mika; Gurtov, Andrei (2014). "Securing the Control Channel of Software-Defined Mobile Networks" (Protección del 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. Número de identificación del sujeto  1378181.
  55. ^ Haranas, Mark (8 de octubre de 2016). "16 productos de redes de moda que hacen vibrar 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 . 2016-02-10 . Consultado el 2016-06-27 .
  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 de actualidad en redes definidas por software . págs. 50–60.
  60. ^ Scott-Hayward, Sandra; O'Callaghan, Gemma; Sezer, Sakir (2013). "Seguridad SDN: una encuesta". Future Networks and Services (SDN4FNS), 2013 IEEE SDN para . págs. 1–7.
  61. ^ Benton, Kevin; Camp, L Jean; Small, Chris (2013). "Evaluación de vulnerabilidad de Openflow". Actas del segundo taller ACM SIGCOMM sobre temas de actualidad 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 SDN y redes convencionales". IEEE Communications Surveys and Tutorials . próxima a aparecer. arXiv : 1703.06992 . Código Bibliográfico :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". Redes de computadoras . 62 : 122–136. doi :10.1016/j.bjp.2013.10.014.
  64. ^ Braga, Rodrigo; Mota, Edjard; Passito, Alexandre (2010). "Detección de ataques de inundación DDoS ligeros mediante NOX/OpenFlow". Redes informáticas locales (LCN), 2010, 35.ª conferencia del IEEE sobre . págs. 408–415.
  65. ^ Feamster, Nick (2010). "Subcontratación de la seguridad de redes domésticas". Actas del taller ACM SIGCOMM de 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 maint: location (link)
  67. ^ Jafarian, Jafar Haadi; Al-Shaer, Ehab; Duan, Qi (2012). "Mutación aleatoria del anfitrión en flujo abierto: defensa transparente de objetivos móviles utilizando redes definidas por software". Actas del primer taller sobre temas de actualidad 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 de defensa de objetivos móviles (PDF) . Consultado el 16 de febrero de 2022 .
  69. ^ ab Sherwood, Rob; Gibb, Glen; Yap, Kok-Kiong; Appenzeller, Guido; Casado, Martin; McKeown, Nick; Parulkar, Guru (2009). "Flowvisor: una capa de virtualización de red". Consorcio OpenFlow Switch, Tech. Rep .
  70. ^ Al-Shaer, Ehab y Al-Haj, Saeed (2010). "FlowChecker: análisis de configuración y verificación de infraestructuras OpenFlow federadas". Actas del tercer taller de ACM sobre configuración de seguridad segura 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. pp. 796–801.
  73. ^ B. Pfaf; et al. (28 de febrero de 2011). "OpenFlow Switch Specification" (PDF) . Consultado el 8 de julio de 2017 .
  74. ^ T. Zhu; et al. (18 de octubre de 2016). "MCTCP: TCP de multidifusión robusto y consciente 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. Número de identificación del sujeto  28159768.
  75. ^ M. Noormohammadpour; et al. (10 de julio de 2017). "DCCast: transferencias eficientes de punto a multipunto entre 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. ^ ab William, Stalling (2016). "Fundamentos de las redes modernas: SDN, NFV, QoE, IoT y la nube". Pearson Education .
  78. ^ Rowayda, A. Sadek (mayo de 2018). "Una arquitectura de red definida por software (SDN) basada en Internet de las cosas (IoT) ágil". Revista egipcia de informática . 42 (2): 13–29.
  79. ^ "Plataforma para infraestructura física y virtual de múltiples proveedores".
  80. ^ Graham, Finnie (diciembre de 2012). "El papel del DPI en un mundo SDN". Libro Blanco .
  81. ^ Series, Y. (mayo de 2015). "Infraestructura de información global, aspectos del protocolo de Internet y redes de próxima generación". Serie UIT-T Y.2770, Suplemento sobre casos de uso y escenarios de aplicación de DPI .
  82. ^ Canovas, Alejandro (2020). "Un sistema robusto de gestión de tráfico multimedia basado en SDN utilizando 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). doi :10.1002/ett.3643. hdl : 10251/186852 . S2CID  182028234.