¿Cuáles son los componentes básicos de SDN?

Para comprender las redes definidas por software (SDN), es posible que encuentre muchos términos relacionados con esta tecnología. Algunos de estos términos son exclusivos de SDN, mientras que otros no son específicos de SDN pero se utilizan a menudo para describir diseños de SDN. Es útil comprender estos términos y su contexto semántico. A continuación nos centramos en comprender las tres categorías técnicas básicas relacionadas con SDN: controlador, red de conmutación y red superpuesta. Controlador Un concepto importante en SDN es un dispositivo llamado controlador que se comunica con todos los dispositivos de red en un dominio, aprende la topología de la red y programa la red desde un punto central y omnisciente. Se puede decir que el controlador SDN cambia el modelo de programación de red de un modelo distribuido (los dispositivos de red que se comunican entre sí determinan la ruta de reenvío) a un modelo centralizado. La programación centralizada de la red es un valor importante que el controlador aporta al negocio. Conceptualmente, el controlador se puede utilizar para implementar completamente políticas comerciales para una red, independientemente de los dispositivos de la red. El controlador se comporta de manera muy similar a una capa de middleware de red que abstrae los componentes físicos subyacentes de la red, como conmutadores, enrutadores, firewalls y dispositivos de equilibrio de carga. El uso de un controlador SDN para programar la red elimina la necesidad de que los operadores de red utilicen métodos tradicionales (como interfaces de línea de comandos) para programar dispositivos de red individuales. Además, se pueden crear paradigmas de reenvío de red propietarios en función de los requisitos de políticas de seguridad o costos. El controlador completa la programación de la red a través de software, razón por la cual SDN tiene una gran flexibilidad. El controlador es a la vez la plataforma de ejecución del software y una puerta de enlace de comunicación para el software. La mayoría de las arquitecturas de controladores son modulares, lo que permite que el controlador utilice muchos métodos diferentes para comunicarse con una variedad de dispositivos de red diferentes. Pensar en el controlador SDN como middleware significa que su comunicación va en dos direcciones. La mayor parte de la discusión hasta ahora ha girado en torno a las comunicaciones hacia el sur. Es decir, el controlador programa dispositivos de red y recibe datos de esos dispositivos, lo que constituye una comunicación en dirección sur. Un ejemplo de comunicación en dirección sur es un controlador que utiliza OpenFlow para programar las tablas de reenvío de los conmutadores de red. La otra dirección es la comunicación en dirección norte. La comunicación entre cada aplicación que desea programar la red y el controlador se denomina norte. Un ejemplo de comunicación en dirección norte es una aplicación como vCloud Director de VMware que realiza solicitudes de servicio de configuración de red a través del controlador. Switch Cuando se habla de SDN, el dispositivo del que mucha gente puede estar hablando es un switch, especialmente un switch Ethernet. Los conmutadores Ethernet han aumentado en velocidad y densidad para proporcionar enlaces ascendentes a hosts de centros de datos, centros blade y almacenamiento Ethernet. Con la llegada de la virtualización de servidores, el conmutador de software del hipervisor se está volviendo cada vez más importante. Puede detectar servidores virtuales y tarjetas de red virtuales, agregar tráfico dentro y fuera del hipervisor y enviarlo a la red física. Tanto los conmutadores de hardware como los de software desempeñan un papel importante en SDN. En primer lugar, el controlador puede programar y controlar la tabla de reenvío del conmutador. Teniendo en cuenta que los conmutadores de software generalmente residen en el borde de la red, ha surgido el concepto de "borde de software inteligente". Los diseñadores de redes que soportan bordes blandos inteligentes consideran que los conmutadores de software que se ejecutan en el hipervisor son un lugar ideal porque pueden instalar funciones de red enriquecidas y, al mismo tiempo, dejar los conmutadores de hardware físicos ejecutándose en un entorno de configuración relativamente simple. En el diseño SDN del borde suave inteligente, el controlador puede implementar políticas de reenvío, QoS y seguridad a través de conmutadores suaves. Por ejemplo, los conmutadores de software pueden tener listas de acceso, parámetros de QoS de velocidad limitada y priorización del tráfico, así como reenvío inteligente aplicado a puertos virtuales. Cuando los datos de la red salen del hipervisor, se someten a detección de cumplimiento de seguridad, configuración de velocidad y encapsulación. Colocar todas estas funciones en el borde de la red permite que los conmutadores de hardware centrales solo realicen tráfico rápido. No todas las redes permiten diseños inteligentes de borde suave y no todos los casos de uso viables de SDN utilizarán conmutadores suaves. Para SDN, los conmutadores de hardware seguirán desempeñando un papel en tareas como la implementación de políticas de servicios de extremo a extremo, el control del tráfico y la aplicación de la seguridad. Además, todavía hay una cierta cantidad de configuración básica que se realizará en los conmutadores de hardware, sin importar cuán inteligente sea la red perimetral. El principal protocolo hacia el sur utilizado por los controladores para programar el comportamiento de reenvío de los conmutadores de hardware y software es OpenFlow.

La Open Network Foundation (ONF) está promoviendo rápidamente el estándar del protocolo OpenFlow (OF). ONF es una organización compuesta principalmente por proveedores de redes y miembros proveedores de servicios y opera a puerta cerrada. La especificación OpenFlow de la fundación ha lanzado actualmente PF 1.0, que se ve a menudo en entornos de producción. El próximo paso que se lanzará, OF 1.3, será principalmente para la mayoría de los fabricantes de conmutadores; OF 1.4 está actualmente en desarrollo. Tenga en cuenta que, si bien OpenFlow se puede implementar completamente en un conmutador de software como Open vSwitch, ha resultado difícil traducir OF a código que el chip de red del conmutador de hardware (ASIC) pueda ejecutar. Aunque hay informes de que pronto se lanzarán nuevos chips que pueden manejar OF mejor, cuando los usuarios evalúen la utilidad de OF, definitivamente lo probarán junto con sus redes existentes para garantizar que las funciones OF requeridas se puedan utilizar de la manera más eficiente posible. Posiblemente ampliable para soportar sus aplicaciones. Para la comunicación en dirección norte, el controlador suele proporcionar una API. Una API REST (Transferencia de Estado Representacional) es probablemente la más utilizada. Una API REST es muy parecida a un servidor HTTP y utiliza métodos familiares como GET y POST para intercambiar datos e instrucciones. La API proporciona un método para que las aplicaciones del controlador le indiquen lo que sucederá en la red. Vale la pena señalar que, además de OF, algunos fabricantes ya han lanzado algunas API especializadas en dirección sur. Esto se debe en parte a que OF tiene un conjunto de instrucciones limitado y, a veces, es difícil de implementar en chips tradicionales.