La tecnología de redes definidas por software ( SDN ) es un enfoque de la gestión de redes que permite una configuración de red dinámica y programáticamente eficiente para mejorar el rendimiento y la supervisión de la red, haciéndola más parecida a la computación en la nube que a la gestión de red tradicional. [1] SDN está destinado a abordar el hecho de que la arquitectura estática de las redes tradicionales es descentralizada y compleja, mientras que las redes actuales requieren más flexibilidad y fácil resolución de problemas. SDN intenta centralizar la inteligencia de la red en un componente de la red disociando el proceso de reenvío de paquetes de red (plano de datos) del proceso de enrutamiento (plano de control). [2] ElEl 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 inteligente tiene sus propios inconvenientes cuando se trata de seguridad, [1] escalabilidad y elasticidad [1] y este es el principal problema de SDN.
SDN se asoció comúnmente con el protocolo OpenFlow (para la comunicación remota con elementos del plano de red con el fin de determinar la ruta de los paquetes de red a través de conmutadores de red ) desde la aparición de este último en 2011. Sin embargo, desde 2012 [3] [4] OpenFlow para muchos empresas ya no es una solución exclusiva, agregaron técnicas propietarias. Estos incluyen el entorno de red abierta 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). [5]
La tecnología SDN está disponible actualmente para aplicaciones de control industrial que requieren una conmutación por error extremadamente rápida, denominada Red definida por software (SDN) de tecnología operativa (OT). La tecnología OT SDN es un enfoque para administrar el control de acceso a la red y la entrega de paquetes Ethernet en hardware reforzado ambientalmente para redes de infraestructura crítica. OT SDN abstrae la gestión del plano de control de los interruptores que lo centralizan en el controlador de flujo y aplica SDN como el plano de control subyacente en el interruptor. El plano de control heredado se elimina simplificando el conmutador mientras se centraliza la gestión del plano de control. El estándar de plano de control común utilizado en OT SDN es OpenFlow, lo que lo hace interoperable con otras soluciones SDN, con la diferencia de que OpenFlow es el único plano de control en el conmutador y que el conmutador retiene los flujos a través de los ciclos de encendido y todos los flujos y la redundancia están diseñados de forma proactiva para el tráfico para que los interruptores puedan realizar el reenvío para el que están configurados con o sin el controlador de flujo en línea. OT SDN proporciona ventajas para las redes industriales en forma de rendimiento, ciberseguridad y conciencia de la situación. Las ventajas de rendimiento se logran a través de contingencias de ingeniería de tráfico proactivas utilizando grupos de Fast Failover en OpenFlow, lo que da como resultado la recuperación de la red de fallas de enlaces o conmutadores en microsegundos, no en milisegundos, como la tecnología de árbol de expansión. Otra ventaja de rendimiento es que la mitigación de bucles se realiza mediante la planificación de rutas de tráfico y no los puertos bloqueados, lo que permite al propietario del sistema utilizar activamente todos los puertos. Las ventajas de ciberseguridad de OT SDN es que los conmutadores están denegados de forma predeterminada y los flujos son las reglas que permiten el reenvío del tráfico. Esto proporciona un fuerte control de acceso a la red donde los paquetes se pueden inspeccionar desde la capa 1 hasta la capa 4 del modelo OSI en cada salto. Las vulnerabilidades de seguridad del plano de control heredado se eliminan ya que el plano de control heredado ya no existe. La suplantación de la tabla MAC y la suplantación de BPDU ya no son posibles porque ninguna de las dos existe en los conmutadores OT SDN. La rotación y el reconocimiento de la red ya no funcionan con la programación de flujo adecuada, ya que solo se aprueba el reenvío del tráfico permitido combinando la ubicación física y la ruta con el filtrado de paquetes virtuales. Las ventajas de la conciencia situacional de OT SDN brindan al propietario de la red la visibilidad de qué dispositivos hay en su red y qué conversaciones pueden y están sucediendo y con quién pueden ocurrir esas conversaciones. La tecnología de red OT SDN permite que las redes Ethernet cumplan con los exigentes requisitos de intercambio de mensajes de comunicación de medición y control para la infraestructura crítica y simplemente proporciona al propietario del sistema control sobre qué dispositivos pueden conectarse a la red, dónde pueden conectarse esos dispositivos y qué conversaciones puede realizar cada dispositivo. tengo.
La investigación de SDN continúa ya que se están desarrollando muchos emuladores con fines de investigación, como vSDNEmul, [6] EstiNet, [7] Mininet [8], etc.
Historia
La historia de los principios SDN se remonta a la separación del plano de control y de datos que se utilizó por primera vez en la red telefónica pública conmutada como una forma de simplificar el aprovisionamiento y la gestión mucho antes de que esta arquitectura comenzara a utilizarse en las 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 en un estándar de interfaz propuesto publicado en 2004 apropiadamente llamado "Separación de elementos de reenvío y control" (ForCES). [9] El Grupo de Trabajo de ForCES también propuso una Arquitectura de SoftRouter complementaria. [10] primeras normas adicionales de la IETF que persiguen el control de separarse de datos incluyen el Netlink Linux como un protocolo IP Servicios [11] y A Path Computation Element (PCE) basado en la arquitectura. [12]
Estos primeros intentos no lograron ganar terreno por dos razones. Una es que muchos en la comunidad de Internet consideraron que separar el control de los datos era riesgoso, especialmente debido a la posibilidad de una falla en el plano de control. La segunda 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 daría lugar a una mayor competencia.
El uso de software de código abierto en arquitecturas de plano de datos / control dividido tiene sus raíces en el proyecto Ethane en el departamento de ciencias de la computación de Stanford. El diseño de interruptor simple de Ethane llevó a la creación de OpenFlow. [13] Una API para OpenFlow se creó por primera vez en 2008. [14] Ese mismo año fue testigo de la creación de NOX, un sistema operativo para redes. [15]
Varias solicitudes de patente fueron presentadas por investigadores independientes en 2007 que describen aplicaciones prácticas para SDN, [16] sistema operativo para redes, [17] unidades de computación de infraestructura de red como una CPU de múltiples núcleos, [18] y un método para la segmentación de red virtual basado en funcionalidad. [19] Estas aplicaciones se hicieron públicas en 2009, y dado que estas patentes también fueron abandonadas, toda la información contenida en las patentes de forma gratuita para uso público y no puede ser patentada por nadie.
El trabajo en OpenFlow continuó en Stanford, incluso con la creación de bancos de pruebas para evaluar el uso del protocolo en una sola red de campus, así como en la WAN como columna vertebral para conectar múltiples campus. [20] En entornos académicos, había algunas redes de investigación y producción basadas en conmutadores OpenFlow de NEC y Hewlett-Packard ; así como basado en las cajas blancas de Quanta Computer , a partir de aproximadamente 2009. [21]
Más allá de la academia, Nicira realizó las primeras implementaciones en 2010 para controlar OVS desde Onix, desarrollado conjuntamente con NTT y Google. Un despliegue notable fue Google despliegue B4 's en 2012. [22] [23] Más tarde, Google reconoció su primer OpenFlow con Onix despliegues en sus centros de datos al mismo tiempo. [24] Otro gran despliegue conocido es el de China Mobile . [25]
La Open Networking Foundation se fundó en 2011 para promover SDN y OpenFlow .
En el 2014 Interop and Tech Field Day, Avaya demostró las redes definidas por software utilizando el puente de ruta más corto ( IEEE 802.1aq ) y OpenStack como un campus automatizado, extendiendo la automatización desde el centro de datos hasta el dispositivo final, eliminando el aprovisionamiento manual de la prestación de servicios. . [26] [27]
Concepto
Las arquitecturas SDN desacoplan el control de la red y las funciones de reenvío, lo que permite que el control de la red se vuelva directamente programable y que la infraestructura subyacente se abstraiga de las aplicaciones y los servicios de red. [28]
El protocolo OpenFlow se puede utilizar en tecnologías SDN. La arquitectura SDN es:
- Directamente programable : control de red es directamente programable ya que se desacopla de funciones de reenvío.
- Ágil : abstraer el control del reenvío permite a los administradores ajustar dinámicamente el flujo de tráfico en toda la red para satisfacer las necesidades cambiantes.
- Gestionado de forma centralizada : La inteligencia de red es (lógicamente) centralizada en controladores basados en software SDN que mantienen una visión global de la red, que aparece a aplicaciones y motores de políticas como un solo interruptor, lógica.
- Programación configurada : SDN permite a los administradores de red configurar, administrar, asegurar y recursos de la red Optimizar muy rápidamente a través de dinámicas, programas automatizados SDN, que pueden escribir ellos mismos porque los programas no dependen de software propietario. [29]
- Y proveedor neutral basada en estándares abiertos : Cuando se implementa a través de estándares abiertos, SDN simplifica el diseño y operación de la red porque las instrucciones son proporcionados por los controladores de SDN en lugar de múltiples dispositivos, proveedores específicos y protocolos.
La necesidad de una nueva arquitectura de red
La explosión de los dispositivos y el 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 las redes a reexaminar las arquitecturas de redes tradicionales. [30] 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 predominaba la informática cliente-servidor, pero una arquitectura estática de este tipo no se adapta a las necesidades de almacenamiento e informática dinámicas de los entornos de operadores, campus y centros de datos empresariales de hoy en día. [31] Algunas de las tendencias informáticas clave que impulsan la necesidad de un nuevo paradigma de red incluyen:
- Cambiando 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 en las que 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 genera una oleada de tráfico de máquina a máquina "este-oeste" antes de devolver los datos al final. dispositivo de usuario en el patrón de tráfico clásico "norte-sur". Al mismo tiempo, los usuarios están cambiando los patrones de tráfico de la red a medida que presionan para acceder a contenido y aplicaciones corporativos desde cualquier tipo de dispositivo (incluido el suyo), conectándose desde cualquier lugar y en cualquier momento. Por último, muchos administradores de centros de datos empresariales están contemplando un modelo de computación de servicios públicos, que podría incluir una nube privada, una nube pública o una combinación de ambas, lo que da como resultado 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. TI está bajo presión para acomodar estos dispositivos personales de una manera detallada mientras protege los datos corporativos y la propiedad intelectual y cumple con los mandatos de cumplimiento.
- El auge de los servicios en la nube
- Las empresas han adoptado con entusiasmo los servicios en la nube tanto públicos como privados, lo que ha dado como resultado un crecimiento sin precedentes de estos servicios. Las unidades de negocios empresariales ahora quieren la agilidad para acceder a aplicaciones, infraestructura y otros recursos de TI bajo demanda y a la carta. Para aumentar la complejidad, la planificación de TI para los servicios en la nube debe realizarse en un entorno de mayor seguridad, cumplimiento y requisitos de auditoría, junto con reorganizaciones, consolidaciones y fusiones comerciales que pueden cambiar los supuestos de la noche a la mañana. La provisión de autoservicio, ya sea en una nube pública o privada, requiere un escalado 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 "macrodatos" o mega conjuntos de datos actuales requiere un procesamiento paralelo masivo en miles de servidores, todos los cuales necesitan conexiones directas entre sí. El aumento de los mega 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 hiperescala se enfrentan a la abrumadora tarea de escalar la red a un tamaño previamente inimaginable, manteniendo la conectividad de cualquiera a cualquier sin fallar. [32]
- Uso de energía en grandes centros de datos
- A medida que surgieron Internet de las cosas , la computación en la nube y SaaS , la necesidad de centros de datos más grandes ha aumentado 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 [33] . También las técnicas para mejorar el control de la eficiencia energética de avión están siendo investigado [34] .
Componentes arquitectónicos
La siguiente lista define y explica los componentes arquitectónicos: [35]
- 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 internos de toma de decisiones. 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 abstraído, 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 a cargo 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 control a 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 el corte de los recursos de la red.
- Ruta de datos SDN
- SDN Datapath es un dispositivo de red lógico que expone visibilidad y control indiscutible sobre sus capacidades de procesamiento de datos y reenvío anunciadas. La representación lógica puede abarcar todos o un subconjunto de los recursos del sustrato físico. Una ruta de datos SDN 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 de la ruta de datos o las funciones de terminación o procesamiento de tráfico interno. Uno o más SDN Datapaths pueden estar contenidos en un solo elemento de red (físico): una combinación física integrada de recursos de comunicaciones, administrada como una unidad. También se puede definir una ruta de datos SDN a través de múltiples elementos de red física. 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 el corte de SDN Datapath, la interoperabilidad con redes que no son SDN, ni la funcionalidad de procesamiento de datos, que puede incluir la capa 4 de OSI. -7 funciones.
- Control SDN a interfaz de plano de datos (CDPI)
- SDN CDPI es la interfaz definida entre un controlador SDN y una ruta de datos SDN, que proporciona al menos (i) control programático de todas las operaciones de reenvío, (ii) publicidad de capacidades, (iii) informes de estadísticas y (iv) notificación de eventos. Un valor de SDN radica en la expectativa de que el CDPI se implemente de una manera abierta, neutral e interoperable con respecto al proveedor.
- Interfaces SDN en dirección norte (NBI)
- Las SDN NBI 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 funciones (longitud). Uno de los valores de SDN radica en la expectativa de que estas interfaces se implementen de manera abierta, interoperable y neutral para el proveedor.
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 visión 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 soluciones jerárquicas, [36] [37] controladores distribuidos operan en una vista de red con particiones, mientras que las decisiones que requieren el conocimiento de toda la red son tomadas por un controlador de raíz lógica centralizada. En enfoques distribuidos, [38] [39] 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 el número y la ubicación de las entidades de control. Un parámetro importante a considerar al hacerlo es el retardo de propagación entre los controladores y los dispositivos de red, [40] especialmente en el contexto de grandes redes. Otros objetivos que se han considerado incluyen la confiabilidad de la ruta de control, [41] la tolerancia a fallas [42] y los requisitos de la aplicación. [43]
Reenvío de flujo SDN (sdn)
- Proactivo vs reactivo vs híbrido [44] [45]
- OpenFlow usa tablas TCAM para enrutar secuencias de paquetes (flujos) . Si los flujos llegan a un interruptor, se realiza una búsqueda de la tabla de flujo. Dependiendo de la implementación de la tabla de flujo, esto se hace en una tabla de flujo de software si se usa un vSwitch o en un ASIC si se implementa en hardware. En el caso de que no se encuentre un flujo coincidente, se envía una solicitud al controlador para obtener más instrucciones. Esto se maneja en uno de tres modos diferentes. En modo reactivo, el controlador actúa después de estas solicitudes y crea e instala una regla en la tabla de flujo para el paquete correspondiente si es necesario. 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 por adelantado. Este modo se puede comparar con las entradas típicas de la tabla de enrutamiento actual, 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 en el 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 TCAM) y no se agrega ningún retraso. El tercer modo, el modo híbrido, sigue la flexibilidad de un modo reactivo para un conjunto de tráfico y el reenvío de baja latencia (modo proactivo) para el resto del tráfico.
Aplicaciones
SDMN
La red móvil definida por software (SDMN) [46] [47] es un enfoque para el diseño de redes móviles en el que todas las características específicas del protocolo se implementan en software, maximizando el uso de hardware y software genérico y básico tanto en la red central como en Red de acceso por radio . [48] Se propone como una extensión del paradigma SDN para incorporar funcionalidades específicas de la red móvil . [49] 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 red de área extensa (WAN) logró utilizando los principios de la creación de redes definidas por software. [50] El principal impulsor de SD-WAN es reducir los costos WAN usando líneas arrendadas más asequibles y disponibles en el mercado, como una alternativa o sustitución parcial de más caros MPLS líneas. 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. [51]
SD-LAN
Una SD-LAN es una red de área local (LAN) en torno a los principios de la creación de redes definidas por software, aunque existen diferencias fundamentales en la topología de la red, la seguridad, la visibilidad y control de aplicaciones, gestión y calidad de servicio. [52] SD-LAN desacopla la gestión de control y los planos de datos para permitir una arquitectura basada en políticas para las LAN inalámbricas y cableadas. 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. [53]
Seguridad usando 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 del controlador y su capacidad para reprogramar el plano de datos en cualquier momento. Si bien la seguridad de la arquitectura SDN en sí sigue siendo una cuestión abierta que ya se ha estudiado un par de veces en la comunidad de investigación, [54] [55] [56] [57] los siguientes párrafos 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 basadas en el controlador SDN, con diferentes objetivos en mente. La detección y mitigación de denegación de servicio distribuido (DDoS), [58] [59] así como la propagación de botnets [60] y gusanos, [61] son algunos casos de uso concretos de tales aplicaciones: básicamente, la idea consiste en recolectar redes periódicamente estadísticas del plano de reenvío de la red de manera estandarizada (por ejemplo, utilizando Openflow), y luego aplique algoritmos de clasificación en esas estadísticas para detectar cualquier anomalía 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 algunos algoritmos de defensa de objetivos móviles (MTD). Los algoritmos MTD se utilizan normalmente para hacer que cualquier ataque a un sistema o red determinado sea más difícil de lo habitual al ocultar o cambiar periódicamente las propiedades clave de ese sistema o red. En las redes tradicionales, implementar algoritmos MTD no es una tarea trivial, ya que es difícil construir una autoridad central capaz de determinar, para cada parte del sistema a proteger, qué propiedades clave se ocultan o cambian. En una red SDN, estas tareas se vuelven más sencillas gracias a la centralidad del controlador. Una aplicación puede, por ejemplo, asignar periódicamente IP virtuales a hosts dentro de la red, y luego el controlador realiza el mapeo de IP virtual / IP real. [62] Otra aplicación puede simular algunos falsos puertos abiertos / cerrados / filtrados en hosts al azar en la red a fin de añadir ruido significativo durante la fase de reconocimiento (por ejemplo, exploración) realizado por un atacante. [63]
También se puede obtener un valor adicional con respecto a la seguridad en redes habilitadas para SDN utilizando FlowVisor [64] y FlowChecker [65] respectivamente. El primero intenta utilizar un solo plano de reenvío de hardware que comparte múltiples redes lógicas separadas. Siguiendo este enfoque, los mismos recursos de hardware se pueden usar para fines de producción y desarrollo, así como para separar el monitoreo, la configuración y el tráfico de Internet, donde cada escenario puede tener su propia topología lógica que se llama segmento. Junto con este enfoque, FlowChecker [64] realiza la validación de nuevas reglas de OpenFlow que son implementadas por los usuarios utilizando su propio segmento.
Las aplicaciones del controlador SDN se implementan principalmente en escenarios a gran escala, lo que requiere verificaciones exhaustivas de posibles errores de programación. Un sistema para hacer esto llamado NICE se describió en 2012. [66] La introducción de una arquitectura de seguridad global requiere un enfoque integral y prolongado de SDN. Desde que se introdujo, 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). [67]
Entrega de datos grupales mediante SDN
Las aplicaciones distribuidas que se ejecutan en los centros de datos generalmente replican datos con el propósito de sincronización, resistencia a fallas, equilibrio de 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 fallas 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 confiable de datos grupales (RGDD).
Los conmutadores SDN se pueden utilizar para RGDD mediante la instalación de reglas que permiten el reenvío a varios puertos de salida. Por ejemplo, OpenFlow proporciona soporte para tablas de grupos desde la versión 1.1 [68] lo que hace que esto sea posible. Con SDN, un controlador central puede configurar de manera cuidadosa e inteligente árboles de reenvío para RGDD. Estos árboles se pueden construir prestando atención a la congestión de la red / estado de carga para mejorar el rendimiento. Por ejemplo, MCTCP [69] 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 [70] y QuickCast [71] son enfoques para la replicación rápida y eficiente de datos y contenido en centros de datos a lo largo de WAN privadas.
Relación con NFV
NFV función de red de virtualización es un concepto que complementa SDN. Por lo tanto, NFV no depende de los conceptos SDN o 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 suelen utilizar 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). [72] El programa híbrido SDN-NFV se proporcionó para capacidades de alta eficiencia, elásticas y escalables NFV destinado a acelerar la innovación y el aprovisionamiento de servicios utilizando tecnologías de virtualización de TI estándar. [72] [73] 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, se proporciona agilidad NFV 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 orquestación y redes existentes. Sin embargo, existen beneficios inherentes al aprovechar los conceptos SDN para implementar y administrar una infraestructura NFV, particularmente cuando se mira 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. [74]
Relación con DPI
La inspección profunda de paquetes de DPI proporciona a la red con reconocimiento de aplicaciones, mientras que SDN proporciona aplicaciones con reconocimiento de red. [75] Aunque SDN cambiará radicalmente las arquitecturas de red genéricas, debería hacer frente al trabajo con arquitecturas de red tradicionales para ofrecer una alta interoperabilidad. La nueva arquitectura de red basada SDN debe considerar todas las posibilidades que se ofrecen actualmente en dispositivos o software independientes que no sean los principales dispositivos de reenvío (routers y switches), tales como el DPI, aparatos de seguridad [76]
Ver también
- Redes activas
- Frenetic (lenguaje de programación)
- IEEE 802.1aq
- Kit de desarrollo de plano de datos Intel (DPDK)
- Lista de software del controlador SDN
- Virtualización de funciones de red
- ONOS
- Proyecto OpenDaylight
- SD-WAN
- Centro de datos definido por software
- Red móvil definida por software
- Protección definida por software
Referencias
- ^ a b c Benzekki, Kamal; El Fergougui, Abdeslam; Elbelrhiti Elalaoui, Abdelbaki (2016). "Redes definidas por software (SDN): una encuesta". Redes de seguridad y comunicación . 9 (18): 5803–5833. doi : 10.1002 / seg.1737 .
- ^ 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 . doi : 10.1007 / s10586-020-03134-x . ISSN 1.386 hasta 7.857 .
- ^ "Las redes definidas por software no son OpenFlow, proclaman las empresas" . searchsdn.techtarget.com .
- ^ "InCNTRE de OpenFlow SDN pruebas de trabajos de laboratorio hacia SDN producto certificado" .
- ^ "Predicción de la adopción de SD-WAN" . gartner.com. 2015-12-15 . Consultado el 27 de junio de 2016 .
- ^ Farias, Fernando NN; Junior, Antônio de O .; da Costa, Leonardo B .; Pinheiro, Billy A .; Abelém, Antônio JG (28 de agosto de 2019). "vSDNEmul: un emulador de red definido por software basado en la virtualización de contenedores". arXiv : 1908.10980 [ cs.NI ].
- ^ Wang, S .; Chou, C .; Yang, C. (septiembre de 2013). "Simulador y emulador de redes de flujo abierto EstiNet". Revista de comunicaciones IEEE . 51 (9): 110-117. doi : 10.1109 / MCOM.2013.6588659 . ISSN 1558-1896 . S2CID 14375937 .
- ^ Oliveira, RLS de; Schweitzer, CM; Shinoda, AA; Ligia Rodrigues Prete (junio de 2014). "Uso de Mininet para emulación y creación de prototipos de redes definidas por software". 2014 IEEE Conferencia Colombiana de Comunicaciones y Computación (COLCOM) : 1–6. doi : 10.1109 / ColComCon.2014.6860404 . ISBN 978-1-4799-4340-1. S2CID 17915639 .
- ^ L. Yang (Intel Corp.), R. Dantu (Univ. Del Norte de Texas), T. Anderson (Intel Corp.) y R. Gopal (Nokia) (abril de 2004). "Marco de Reenvío y Separación de Elementos de Control (ForCES)" .CS1 maint: varios nombres: lista de autores ( enlace )
- ^ TV Lakshman, T. Nandagopal, R. Ramjee, K. Sabnani y T. Woo (noviembre de 2004). "La arquitectura de SoftRouter" (PDF) .CS1 maint: varios nombres: lista de autores ( enlace )
- ^ J. Salim (Znyx Networks), H. Khosravi (Intel), A. Kleen (Suse) y A. Kuznetsov (INR / Swsoft) (julio de 2003). "Netlink Linux como un protocolo de servicios IP" .CS1 maint: varios nombres: lista de autores ( enlace )
- ^ 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)" .CS1 maint: varios nombres: lista de autores ( enlace )
- ^ Martìn Casado, Michael J. Freedman, Justin Pettit, Jianying Luo y Nick McKeown (Universidad de Stanford) (agosto de 2007). "Etano: tomar el control de la empresa" (PDF) .CS1 maint: varios nombres: lista de autores ( enlace )
- ^ 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 las redes de campus" (PDF) .CS1 maint: varios nombres: lista de autores ( enlace )
- ^ 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) .CS1 maint: varios nombres: lista de autores ( enlace )
- ^ [1] , "Elemento de red e infraestructura para un sistema de gestión de riesgos de red", publicado 2007-08-07
- ^ [2] , "Software para una infraestructura en tiempo real", publicado el 17 de julio de 2008
- ^ [3] , "CPU de varios núcleos", publicado el 3 de julio de 2008
- ^ [4] , "Gestión de interacciones de red mediante marcos de interés y anillos de liquidación", publicado el 21 de enero de 2009
- ^ "GENI. Topología Campus OpenFlow" . 2011.
- ^ Kuang-Ching “KC” Wang (3 de octubre de 2011). "Software Defined Networking y OpenFlow para las universidades: La motivación, estrategia y Usos" (PDF) .
- ^ 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) (del 12 al 16 de agosto de 2013). "B4: Experiencia con una WAN definida por software implementada globalmente" (PDF) .CS1 maint: varios nombres: lista de autores ( enlace )
- ^ brent salisbury (14 de mayo de 2013). "Dentro de Google definida por software de red" .
- ^ 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 Clos topologías y control centralizado de la red de centros de datos de Google" .CS1 maint: varios nombres: lista de autores ( enlace )
- ^ " " MPLS-TP OpenFlow Protocolo Extensiones para SPTN "se convierte en un estándar formal de la ONF por aprobación unánime" . 27 de junio de 2017.
- ^ Camille Campbell (6 de febrero de 2014). "Avaya presenta innovaciones en redes en el 'Día de campo tecnológico ' " .
- ^ Elizabeth Miller Coyne (23 de septiembre de 2016). "Huawei Exec: SDN se convierte en un 'término completamente sin sentido ' " .
- ^ "Definición de redes definidas por software (SDN)" . Opennetworking.org . Consultado el 26 de octubre de 2014 .
- ^ Montazerolghaem, Ahmadreza; Yaghmaee, Mohammad Hossein; Leon-García, Alberto (septiembre de 2020). "Red multimedia de nube verde: 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 .
- ^ "Libros blancos" . Opennetworking.org . Consultado el 26 de octubre de 2014 .
- ^ Montazerolghaem, Ahmadreza .; Yaghmaee, MH; León-García, A. (2017). "OpenSIP: Hacia redes SIP definidas por software". Transacciones IEEE sobre gestión de redes y servicios . PP (99): 184-199. arXiv : 1709.01320 . Código bibliográfico : 2017arXiv170901320M . doi : 10.1109 / tnsm.2017.2741258 . ISSN 1932-4537 . S2CID 3.873.601 .
- ^ 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 inquilinos para la transmisión de big data basada en la nube". Revista de aplicaciones informáticas y de red . 126 : 133-149. doi : 10.1016 / j.jnca.2018.11.005 .
- ^ Assefa, Beakal Gizachew; Özkasap, Öznur (junio de 2020). "RESDN: A Novel Métricas y método para la Energía Eficiente de enrutamiento en redes definidas de software" . Transacciones IEEE sobre gestión de redes y servicios . 17 (2): 736-749. doi : 10.1109 / TNSM.2020.2973621 .
- ^ 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 utilizando controladores de múltiples núcleos" . Energías . 14 (11): 3161. doi : 10.3390 / en14113161 .
- ^ "Descripción general de la arquitectura SDN" (PDF) . Opennetworking.org . Consultado el 22 de noviembre de 2014 .
- ^ SH Yeganeh, Y. Ganjali, "Kandoo: un marco para la descarga eficiente y escalable de aplicaciones de control", actas de HotSDN, Helsinki, Finlandia, 2012.
- ^ R. Ahmed, R. Boutaba, "Consideraciones de diseño para la gestión de redes de área amplia de software definidos," Revista de Comunicaciones, IEEE, vol. 52, no. 7, págs. 116-123, julio de 2014.
- ^ T. Koponen et al, "Onix: A Distributed plataforma de control para redes de producción a gran escala," procedimiento USENIX, Ser. OSDI'10, Vancouver, Canadá, 2010.
- ^ D. Tuncer, M. Charalambides, S. Clayman, G. Pavlou, "Gestión y control de recursos adaptativos en redes definidas por software", Gestión de redes y servicios, IEEE Transactions on, vol. 12, no. 1, págs. 18–33, marzo de 2015.
- ^ B. Heller, R. Sherwood, y N. McKeown, "El controlador de colocación problema," procedimientos de HotSDN'12 2012.
- ^ YN Hu, WD Wang, XY Gong, XR Que, SD Cheng, "Sobre la colocación de controladores en redes definidas por software", Revista de Universidades de Correos y Telecomunicaciones de China, vol. 19, Suplemento 2, no. 0, págs.92-171, 2012.
- ^ FJ Ros, PM Ruiz, "cinco nueves de fiabilidad hacia el sur en las redes definidas por software, los" procedimientos de HotSDN'14 de 2014.
- ^ D. Tuncer, M. Charalambides, S. Clayman, G. Pavlou, "Sobre la ubicación de la funcionalidad de gestión y control en redes definidas por software", actas del segundo taller internacional IEEE sobre gestión de sistemas SDN y NFV (ManSDN / NFV) , Barcelona, España, noviembre de 2015.
- ^ "OpenFlow: proactivo vs reactivo" . NetworkStatic.net . 2013-01-15 . Consultado el 1 de julio de 2014 .
- ^ "Reactivo, proactivo, predictivo: modelos SDN | F5 DevCentral" . Devcentral.f5.com . 2012-10-11 . Consultado el 30 de junio de 2016 .
- ^ Pentikousis, Kostas; Wang, Yan; Hu, Weihua (2013). "Mobileflow: Hacia redes móviles definidas por software". Revista de comunicaciones IEEE . 51 (7): 44–53. doi : 10.1109 / MCOM.2013.6553677 . S2CID 10655582 .
- ^ 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.
- ^ Jose Costa-Requena, Jesús Llorente Santos, Vicent Ferrer Guasch, Kimmo Ahokas, Gopika Premsankar, Sakari Luukkainen, Ijaz Ahmed, Madhusanka Liyanage, Mika Ylianttila, Oscar López Pérez, Mikel Uriarte Itzazelaia, Edgardo Montes de Oca, SDN y NFV Integración en Arquitectura de Red Móvil Generalizada , en Proc. de la Conferencia Europea de Redes y Comunicaciones (EUCNC), París, Francia. Junio de 2015.
- ^ Madhusanka Liyanage, Mika Ylianttila, Andrei Gurtov, Fijación del Canal de Control de Redes Móviles definidas en software , en Proc. del 15º Simposio Internacional de IEEE sobre el mundo de las redes inalámbricas, móviles y multimedia (WoWMoM), Sydney, Australia. Junio de 2014.
- ^ Haranas, Mark (8 de octubre de 2016). "16 productos de redes calientes que ponen el chisporroteo en SD-WAN" . CRN . Consultado el 1 de noviembre de 2016 .
- ^ "SD-WAN: Qué es y por qué lo usarás algún día" . networkworld.com. 2016-02-10 . Consultado el 27 de junio de 2016 .
- ^ Serries, William (12 de septiembre de 2016). "SD-LAN y WAN-SD: Deux Enfoques DIFFERENTES pour le Software Defined Networking" . ZDNet . Consultado el 1 de noviembre de 2016 .
- ^ Kerravala, Zeus (13 de septiembre de 2016). "Aerohive presenta la LAN definida por software" . Mundo de la red . Consultado el 1 de noviembre de 2016 .
- ^ Kreutz, Diego; Ramos, Fernando; Verissimo, Paulo (2013). "Hacia redes definidas por software seguras y confiables". Actas del segundo taller de ACM SIGCOMM sobre temas candentes en redes definidas por software . págs. 50–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.
- ^ Benton, Kevin; Campamento, L Jean; Pequeño, Chris (2013). "Evaluación de vulnerabilidades de Openflow". Actas del segundo taller de ACM SIGCOMM sobre temas candentes en redes definidas por software . págs. 151-152.
- ^ 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 convencionales y SDN". Encuestas y tutoriales de comunicaciones de IEEE . a aparecer. arXiv : 1703.06992 . Código bibliográfico : 2017arXiv170306992A .
- ^ Giotis, K; Argyropoulos, Christos; Androulidakis, Georgios; Kalogeras, Dimitrios; Maglaris, Vasilis (2014). "La combinación de OpenFlow y sFlow para una detección de anomalías eficaz y escalable y mecanismo de mitigación en entornos SDN" . Redes informáticas . 62 : 122-136. doi : 10.1016 / j.bjp.2013.10.014 .
- ^ Braga, Rodrigo; Mota, Edjard; Passito, Alexandre (2010). "Detección ligera de ataques de inundación DDoS usando NOX / OpenFlow". Redes de computadoras locales (LCN), 2010 IEEE 35th Conference on . págs. 408–415.
- ^ Feamster, Nick (2010). "Tercerización de la seguridad de la red doméstica". Actas del taller 2010 ACM SIGCOMM sobre redes domésticas . págs. 37–42.
- ^ 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.Mantenimiento de CS1: ubicación ( enlace )
- ^ Jafarian, Jafar Haadi; Al-Shaer, Ehab; Duan, Qi (2012). "Mutación de host aleatorio de flujo abierto: defensa de objetivo móvil transparente utilizando redes definidas por software". Actas del primer taller sobre temas candentes en redes definidas por software . págs. 127-132.
- ^ Kampanakis, Panos; Perros, Harry; Beyene, Tsegereda. Soluciones basadas en SDN para la protección de red de Moving Target Defense (PDF) . Consultado el 23 de julio de 2014 .
- ^ a b Sherwood, Rob; Gibb, Glen; Yap, Kok-Kiong; Appenzeller, Guido; Casado, Martín; McKeown, Nick; Parulkar, Guru (2009). "Flowvisor: una capa de virtualización de redes". Consorcio OpenFlow Switch, Tech. Rep .
- ^ Al-Shaer, Ehab y Al-Haj, Saeed (2010). "FlowChecker: Análisis de configuración y verificación de infraestructuras OpenFlow federadas". Actas de la tercera taller de ACM sobre assurable y la configuración de seguridad utilizable . págs. 37–44.
- ^ Canini, Marco; Venzano, Daniele; Peresini, Peter; Kostic, Dejan; Rexford, Jennifer; et al. (2012). Una buena manera de solicitudes Prueba OpenFlow . INDE. págs. 127–140.
- ^ Bernardo y Chua (2015). Introducción y análisis de la arquitectura de seguridad SDN y NFV (SA-SECA) . 29th IEEE AINA 2015. págs. 796–801.
- ^ B. Pfaf; et al. (28 de febrero de 2011). "Especificación del conmutador OpenFlow" (PDF) . Consultado el 8 de julio de 2017 .
- ^ 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 24 Simposio Internacional sobre Calidad de Servicio (IWQoS) . IEEE. págs. 1-10. doi : 10.1109 / IWQoS.2016.7590433 . ISBN 978-1-5090-2634-0. S2CID 28159768 .
- ^ 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 .
- ^ M. Noormohammadpour; et al. (2018). QuickCast: rápido y eficiente Transferencias entre el centro de datos mediante el reenvío del árbol de cohortes . arXiv : 1801.00837 . Código bibliográfico : 2018arXiv180100837N . doi : 10.31219 / osf.io / uzr24 . Consultado el 23 de enero de 2018 .
- ^ a b William, Stalling (2016). "Fundamentos de las redes modernas: SDN, NFV, QoE, IoT y Cloud". Educación de Pearson .
- ^ Rowayda, A. Sadek (mayo de 2018). "Una arquitectura de red definida por software (SDN) basada en Internet de las cosas ágil (IoT)". Revista Egipcia de Ciencias de la Computación . 42 (2): 13-29.
- ^ Plataforma para múltiples proveedores de infraestructura virtual y física
- ^ Graham, Finnie (diciembre de 2012). "El papel de DPI en un mundo SDN". Libro blanco .
- ^ Series, Y. (mayo de 2015). "Infraestructura de información global, aspectos de protocolo de Internet y redes de próxima generación". Serie ITU-T Y.2770, Suplemento sobre casos de uso de DPI y escenarios de aplicación .