Llegamos a ustedes gracias a:



Reportajes y análisis

SDN: Las partes fundamentales

[02/07/2013] Cuando se habla de software defined networking, uno encuentra muchos términos que son utilizados junto con la tecnología. Algunos de los términos son únicos del SDN, mientras que otros describen tecnologías que, aunque no son únicas, son frecuentemente utilizadas en los diseños de SDN.
Es útil entender estos términos y su contexto. Daremos una mirada a tres categorías básicas de terminologías que se relacionan con el SDN: controladores, switching y overlay networks.
Controladores
Una de las grandes ideas del SDN es que un dispositivo llamado controlador conversa con todos los dispositivos de la red en un dominio, aprende la topología de la red, y programa a la red desde un punto de omnisciencia central. Un controlador SDN cambia el modelo de programación de la red de ser algo distribuido (los dispositivos de la red se comunican unos con otros para determinar las trayectorias de reenvío) a algo centralizado.
La programación centralizada de la red es el valor significativo que un controlador ofrece a la empresa. Conceptualmente, un controlador puede ser utilizado para desplegar políticas del negocio a una red de manera holística e independiente del dispositivo. El controlador actúa como una capa de middleware de red que abstrae los componentes de la red física subyacente como los switches, routers, firewalls y balanceadores de carga.
Con un controlador SDN que programa la red, los operadores ya no se encuentran en posición de tener que programar los dispositivos de red de manera individual a través de medios tradicionales, como la interfase de líneas de comando. Además, se pueden crear paradigmas únicos de reenvío de la red en base a criterios, como los costos o los requerimientos de la política de seguridad.
Un controlador lleva a cabo la programación de la red vía software, y es en este software en donde se encuentra la promesa de flexibilidad de la SDN. El controlador es una plataforma en la cual corre el software, y a la vez es un gateway de comunicaciones a través del cual se puede comunicar el software. La mayoría de las arquitecturas de los controladores son modulares, lo cual permite al controlador comunicarse con diferentes tipos de dispositivos usando diferentes métodos de acuerdo a cómo se necesiten.
Si pensamos nuevamente en el controlador de SDN como middleware, existen dos direcciones de comunicación. La más discutida a la fecha son las comunicaciones inferiores (southbound). Cuando un controlador está programando los dispositivos de red y recibiendo datos de ellos, se dice que esto es la comunicación inferior. Un ejemplo de comunicación inferior es cuando el controlador programa las tablas de reenvío de los switches de la red usando OpenFlow. La otra dirección es la superior. Las comunicaciones entre las aplicaciones que desean programar la red y el controlador, son descritas como comunicaciones superiores. Un ejemplo de comunicación superior es cuando la aplicación vCloud Director de VMware solicita servicios de provisionamiento de red vía un controlador.
Switching
Cuando se trata de SDN, quizás el dispositivo del que más se habla es el switch de red, de los switches Ethernet en particular. Por años, los switches Ethernet han crecido en velocidad y densidad, proporcionando a los centros de datos uplinks para sus hosts, blade centers y almacenamiento Ethernet. Con el advenimiento de la virtualización de servidores gracias a los hipervisores, el switch de software también se ha hecho importante, agregando tráfico y sacándolo fuera del hipervisor hacia la red física.
Tanto el switch de hardware como el de software tienen importantes papeles dentro del SDN, como también sus tablas de reenvío que son programadas por un controlador. Dado que los switches de software residen en los extremos de la red, ha surgido el concepto de smart soft edge.
Los diseñadores de redes que defienden las smart soft edges sienten que el switch de software que corre en un hipervisor es un buen lugar para instalar funcionalidades de red ricas, dejando que los switches físicos corran una configuración más simple. En un diseño de SDN smart soft edge los controladores aplican el reenvío, QoS y las políticas de seguridad en los switches de software de la red.
Por ejemplo, el switch de software puede acceder a listas, parámetros QoS para limitar las tasas y la priorización del tráfico, e inteligencia de reenvío aplicada a los puertos virtuales. Para el momento en que los datos de red han dejado el hipervisor, ya han sido probados para comprobar si cumplen con la seguridad, han pasado por el rate shape y han sido encapsulados (si se requiere). Colocar todas estas funciones en el extremo de la red permite que los switches principales de hardware se concentren en el rápido transporte del tráfico.
No todas las redes se prestan para la inteligencia, el soft edge design, ni tampoco todos los casos concebibles de uso del SDN pueden ser alcanzables por un soft switch. Aún hay un papel que tiene que desarrollar el SDN con los switches de hardware en tareas como el despliegue de políticas de negocio end to end, direccionamiento del tráfico y cumplimiento de la seguridad. Además, aún hay una cierta cantidad de configuraciones básicas que se tienen que hacer al switch de hardware, sin importar que tan inteligente sea el extremo de la red.
El protocolo inferior (southbound) primario utilizado por un controlador para programar el comportamiento de reenvío tanto de los switches de hardware como de software es OpenFlow. OpenFlow (OF) es un protocolo cuyo estándar tiene un rápido desarrollo gracias a la Open Networking Foundation.
La ONF es una organización solo para miembros conformada básicamente por proveedores de networking y proveedores de servicios, los cuales operan tras puertas cerradas. Sus especificaciones OpenFlow son publicadas al momento de liberarse. La especificación OF1.0 se le ve mayormente en los equipos de producción; la OF1.3 es el probable siguiente paso para la mayoría de los proveedores de switches. La OF1.4 se encuentra en desarrollo al momento de terminar esta nota.
Hay que tener en cuenta que aunque OpenFlow se implementa completamente en los switches de software como el Open vSwitch, OF se ha mostrado difícil de traducir para los chips de red (ASIC) en los switches de hardware. Aunque se dice que ya viene un nuevo chip que puede manejar mejor el OF, los clientes que se encuentran evaluando la utilidad del OF en combinación con su actual hardware de red deben realizar meticulosas pruebas para asegurarse que la función de OF que se requiere va a crecer tanto como se le necesite para soportar su aplicación.
Para las comunicaciones superiores (northbound), los controladores frecuentemente ofrecen APIs. Quizás la más común es la REST (representational state transfer). Las APIs REST intercambian datos e instrucciones de manera similar a los servidores HTTP, usando métodos familiares como GET y POST. Las APIs proporcionan una forma para que las aplicaciones externas al controlador le digan a éste que debería pasar en la red.
En particular, han surgido APIs específicas de ciertos proveedores para la dirección inferior (southbound) además del OF. Esto se debe en parte al limitado conjunto de comandos de OF y a la, en ocasiones, difícil implementación en los silicios legacy. A pesar de soportar OpenFlow, Cisco es un ejemplo de proveedor que enfatiza las APIs vía su iniciativa ONE, argumentando que sus APIs permiten a los programadores de la red aprovechar plenamente las capacidades de su hardware.
Overlays
Otro término que surge frecuentemente en las conversaciones sobre el SDN es el de las overlay networks. En términos simples, los overlays se utilizan para crear contenedores de redes virtuales que se encuentran lógicamente aislados unos de otros, aunque comparten la misma red física subyacente.
Los ingenieros de red que están familiarizados con la muy utilizada Generic Routing Encapsulation (GRE) van a captar rápidamente el concepto de overlay. Un paquete (o marco) es encapsulado dentro de otro; el paquete encapsulado es reenviado a un endpoint por un túnel en donde es desencapsulado. El paquete original luego es enviado a su destino. Los overlays aprovechan esta técnica de paquete dentro de otro paquete para ocultar de manera segura las redes unas de otras y de segmentos transversos de red que de otra forma conformarían barreras. La extensión Layer 2 y los multiusuarios son casos de uso conocidos para los overlays.
Se han lanzado y promovido varios protocolos de overlay por parte de los organismos de estandarización en los pasados años, impulsados por la capacidad de los centros de datos virtuales de trasladar un host a cualquier lugar, en cualquier momento. Algunos controladores SDN usan overlays como su medio de transporte elegido para construir un puente entre los hosts desperdigados por todo el centro de datos; los soft switches generalmente sirven como final del túnel. La Virtual eXtensible LAN (VXLAN) tiene en estos momentos el respaldo más amplio de la industria, ya que Cisco, Brocade y VMware, entre otros, se encuentran comprometidos con el overlay. El fin de los túneles VXLAN en hardware es soportado por los switches de Arista y Brocade. El que VXLAN concluya en hardware mina la ola de adopción por parte de la industria, ya que los overlays generalmente concluyen en switches de software.
VXLAN encapsula los marcos de Layer 2 dentro de un paquete UDP de Layer 3. Esto permite que los hosts dentro de un segmento VXLAN se comuniquen unos con otros tal y como si estuvieran en la misma red de Layer 2, a pesar de que puedan estar separados por una o más redes de Layer 3.
Además, ya que VXLANA preserva todo el marco de Layer 2, los tags de VLAN también se preservan, lo cual permite que existan varias redes de Layer 3 dentro de un segmento de VXLAN. Los clientes (también conocidos como tenants) dentro del segmento VXLAN ven una red muy similar a la que suelen ver, mientras que la red subyacente sólo ve los paquetes de VXLAN identificados por un ID de segmento.
Cada red VXLAN se encuentra identificada por un ID de segmento en la cabecera VXLAN; este ID tiene una longitud de 24 bits, lo que permite que 16 millones de tenants compartan la misma infraestructura de red, mientras que al mismo tiempo se mantienen aislados unos de otros.
VXLAN ha sido criticada por depender del multicast IP para llevar las emisiones, unicast desconocidas y tráfico multicast originado dentro de las redes de tenants. Muchas redes físicas no tienen habilitado el ruteo multicast, y los ingenieros que no están familiarizados con el multicast lo ven como una herramienta intimidatoria para el despliegue, debido a su potencial complejidad. Por este motivo, algunos proveedores que usan VXLAN como overlay lo están desplegando con una inteligencia mejorada y proporcionada por un controlador SDN de tal forma que la necesidad de ruteo multicast queda obviada.
De manera similar a la VXLAN, la Network Virtualization with GRE (NVGRE) define las redes de tenants usando un identificador de 24 bits, que se encuentra en este caso en el campo principal del encabezado de GRE. NVGRE es con mucho una tecnología de Microsoft y es el overlay de elección en Hyper-V.
NVGRE se diferencia de VXLAN por no requerir multicast para llevar la emisión, unicast desconocido, y el multicast entre los endpoints. En cambio, el módulo Windows Network Virtualization (un switch de Layer 3) incorporado en Hyper-V se encuentra pre poblado con todos los mapeos de endpoints hosts-to-tunnel de PowerShell cmdlets. Esto elimina la necesidad de flooding, ya que no hay algo así como un endpoint desconocido en este enfoque.
Aunque VMware se encuentra firmemente detrás de VXLAN, el overlay conocido como Stateless Transport Tunneling (STT) también se encuentra bajo la marca de VMware con la adquisición de Nicira por parte de VMware. STT es una parte de la Network Virtualization Platform de Nicira, y es destacable mayormente debido a que el formato de encapsulamiento aprovecha una capacidad de hardware de la interfase de red moderna para llevar los grandes bloques de datos hacia segmentos más pequeños.
Llamado TCP segmentation offload, un NIC con capacidad TSO se hace cargo de la segmentación, liberando la CPU de un servidor para otras tareas. El futuro del STT es ambiguo, considerando que la VXLAN ya tiene soporte de VMware así como soporte de la industria.
Además de VXLAN, NVGRE y STT, otro overlay en desarrollo que merece la pena seguir es el Network Virtualization Overlays (NVO3). El NVO3 está siendo desarrollado por un grupo de trabajo de IETF. Los problemas del NVO3 son similares a los problemas que enfrentan los overlays ya mencionados; a decir, aislamiento del tráfico, libertad del tenant para usar el esquema de direcciones que elija, y colocar máquinas virtuales en cualquier lugar de la red, sin preocuparse de la separación del Layer 3 que se encuentra en el core subyacente. La forma en que el NVO3 se va a desarrollar y qué encapsulamiento será usado sigue en verse, pero se está configurando de acuerdo a los casos de uso enviados por los participantes en el grupo de trabajo.
Conclusión
Las tres principales categorías de terminología que hemos discutido pueden juntarse como: Un controlador central omnisciente descubre la topología de los switches de la red, ya sea que se trate de switches de software en un hipervisor o switches de hardware que se encuentran en el rack de un centro de datos.
Este controlador central actúa como un middleware entre las aplicaciones en una dirección superior (northbound) y los switches en una dirección inferior. Las aplicaciones superiores articulan políticas de negocio, configuración de red y similares para el controlador; el controlador traduce estas políticas y configuraciones en directivas de programación inferiores (southbound) dirigidas a los switches de la red.
El protocolo inferior (southbound) más utilizado es OpenFlow, pero los desafíos que modernizan a OpenFlow para al hardware de red existente ha hecho que los proveedores promuevan la programación de la red vía APIs.
En esta plataforma de programabilidad de red y abstracción de dispositivos físicos se añaden los overlays. Éstos permiten que los proveedores de nube y las empresas que desean soportar multitenancy para separar de manera segura el tráfico de sus clientes unos de otros, mientras que al mismo tiempo permiten que sus hosts virtuales residan en cualquier lugar dentro de un centro de datos.
Ethan Banks, propietario, Packet Pushers Interactive, Network World (EE.UU.)