En nuestro artículo anterior, tuvimos una buena descripción general de SDN como tecnología, por qué es necesaria y cómo la industria de TI la está adoptando. Ahora, profundicemos un poco más y comprendamos la arquitectura de SDN y el papel del protocolo Openflow en la implementación de la tecnología.
SDN consiste en términos generales en tres capas:
- Capa de aplicación
- Capa de control
- Capa de infraestructura
Tratemos de comprender estas capas con un enfoque de abajo hacia arriba.
Capa de infraestructura se compone de varios equipos de red que forman una red subyacente para reenviar el tráfico de la red. Podría ser un conjunto de conmutadores de red y enrutadores en el centro de datos. Esta capa sería la física sobre la cual se establecería la virtualización de la red a través de la capa de control (donde los controladores SDN se ubicarían y administrarían la red física subyacente).
Capa de control es la tierra del plano de control donde residiría la lógica inteligente en los controladores SDN para controlar la infraestructura de la red. Esta es el área en la que todos los proveedores de redes están trabajando para crear sus propios productos para el marco y el controlador SDN. Aquí, en esta capa, se escribe mucha lógica comercial en el controlador para obtener y mantener diferentes tipos de información de red, detalles de estado, detalles de topología, detalles de estadísticas y más.
Dado que el controlador SDN es para administrar redes, debe tener una lógica de control para casos de uso de redes del mundo real, como conmutación, enrutamiento, VPN L2, VPN L3, reglas de seguridad de firewall, DNS, DHCP y agrupación. Varios proveedores de redes e incluso comunidades de código abierto están trabajando en la implementación de estos casos de uso en sus controladores SDN. Una vez que se implementan, estos servicios exponen sus API (generalmente basadas en REST) a la capa superior (capa de aplicación), algo que facilita la vida de los administradores de red que luego usan aplicaciones sobre los controladores SDN para configurar, administrar y monitorear la red subyacente. La capa de control se encuentra en el medio y expone dos tipos de interfaces:hacia el norte y hacia el sur.
- Interfaz hacia el norte :está destinado a la comunicación con la capa de aplicación superior y, en general, se realiza a través de las API REST de los controladores SDN. S interfaz de salida :está destinado a la comunicación con la capa inferior de infraestructura de elementos de red y, en general, se realiza a través de protocolos hacia el sur:Openflow, Netconf, Ovsdb, etc.
Capa de aplicación es un área abierta para desarrollar la mayor cantidad de aplicaciones innovadoras posible aprovechando toda la información de la red sobre la topología de la red, el estado de la red, las estadísticas de la red, etc. Puede haber varios tipos de aplicaciones que se pueden desarrollar, como las relacionadas con la automatización de la red, la configuración de la red y administración, monitoreo de red, solución de problemas de red, políticas de red y seguridad. Estas aplicaciones SDN pueden proporcionar varias soluciones integrales para redes de centros de datos y empresas del mundo real. Los proveedores de redes están presentando su conjunto de aplicaciones SDN. Por ejemplo, Brocade tiene las siguientes aplicaciones muy útiles:
- Optimizador de flujo de Brocade
- Enrutador virtual Brocade
- Asesor de la red Brocade
HPE también es un proveedor que tiene una tienda de aplicaciones SDN que también contiene muchas aplicaciones SDN de diferentes compañías. Por ejemplo:
- Optimizador de red HPE
- Protector de red HPE
- Visualizador de redes HPE
- NEC UNC para controlador HP SDN VAN
- Equilibrador de carga Aricent SDN
- Dirección de flujo inteligente TechM
- Equilibrador de carga del servidor TechM
Como mencionamos brevemente Openflow en el artículo anterior, ahora cubriremos los detalles de la comunicación hacia el sur desde la capa de control hasta la capa de infraestructura (conmutadores de red) a través del protocolo Openflow.
Openflow ha sido fundamental en la revolución de SDN en el sentido de que ha sido clave para mostrar la separación del plano de control del plano de datos. Openflow es la especificación estándar proporcionada por Open Networking Foundation (ONF) y está evolucionando con el tiempo con soporte para varios requisitos de las redes mundiales actuales. La versión actual del protocolo Openflow es 1.5.1.
Openflow es un protocolo que brinda especificaciones estándar para la comunicación entre el controlador SDN y el equipo de red (generalmente conmutadores). Permite que los controladores de SDN tomen decisiones de enrutamiento y permite que las reglas de reenvío, las reglas de seguridad se inserten en los conmutadores en la red subyacente.
El controlador y los conmutadores de SDN deben implementar las especificaciones de Openflow para que puedan comprender el lenguaje común de los mensajes de Openflow. Para controlar los conmutadores de red, el controlador SDN insertará reglas en los conmutadores para que puedan tomar decisiones cuando el tráfico de la red los golpee. Los conmutadores deben mantener dichas reglas en la tabla Openflow . Según Openflow, estas reglas se denominan "flujos" y se almacenan en "tablas de flujo".
En términos generales, los flujos transportan tres tipos de información:
- Campos de coincidencia:definirán los criterios para hacer coincidir los paquetes en función de sus campos de encabezado:L2 (direcciones ethernet de origen y destino, ID de VLAN, prioridad de VLAN, etc.), L3 (IPv4/ Dirección de destino de origen IPv6, tipo de protocolo, DSCP, etc.), campos L4 (puerto de destino de origen TCP/UDP/SCTP), campos ARP, campos ICMP, campos MPLS, etc.
- Acciones:definirán qué hacer con un paquete si coincide con los criterios. Las acciones serían como colocar, reenviar en algún puerto del conmutador, modificar el paquete (empujar/quitar ID de VLAN, empujar/quitar etiqueta MPLS, incrementar/decrementar IP TTL), reenviar a cola específica de puerto, etc.
- Contadores:para realizar un seguimiento de cuántos paquetes coincidieron con el flujo
Para ser específicos, los flujos contienen más información que se puede consultar con más detalle en las especificaciones de Openflow.
El canal o conexión Openflow es una configuración entre el conmutador y el controlador para que el controlador pueda comunicarse con el conmutador para configurarlo, administrarlo y monitorearlo. Según las especificaciones de Openflow, Openflow se ejecuta en una conexión TCP o TLS y el controlador escucha la conexión en el puerto 6653. Se espera que el interruptor inicie la conexión y envíe una solicitud de conexión al controlador.
Opcionalmente, la conexión también se puede iniciar desde el lado del controlador y, en este caso, el interruptor estará en modo pasivo para escuchar la conexión. Ya sea desde cualquier lado, sería una configuración de conexión TCP o TLS normal, una vez que se establece, los mensajes de Openflow se intercambian a través de una conexión TCP o TLS. Por ejemplo, a continuación se muestra el comando del conmutador virtual Openflow de código abierto (OpenVswitch) para iniciar la conexión TCP con el controlador:
ovs-vsctl set-controller <sampleBridgeName> tcp:192.168.56.101:6653
Aquí, 192.168.56.101 es la IP del controlador y 6653 es el puerto del controlador en el que estaría escuchando la conexión.
Openflow define varios mensajes para permitir la comunicación entre el conmutador y el controlador, incluidos los mensajes de establecimiento de conexión, los mensajes de configuración, los mensajes de estadísticas del conmutador, los mensajes de mantenimiento, los mensajes de eventos asíncronos, los mensajes de error, los mensajes del experimentador y más.
Entendamos brevemente sobre los mensajes de Openflow:
- Una vez que se establece la conexión TCP, ambas entidades intercambian un mensaje HELLO de Openflow para negociar la versión de Openflow en la que se llevará a cabo una mayor comunicación. Es necesario, ya que es posible que el interruptor y el controlador se ejecuten en una versión de Openflow diferente. Ambos estarán de acuerdo en la versión más alta admitida.
- Después de que se realiza la negociación de la versión, el controlador primero envía un mensaje de solicitud de función Openflow para obtener principalmente el ID de la ruta de datos del mensaje de respuesta del interruptor y para determinar qué características admite el interruptor.
- Para configurar el interruptor para manejar el tráfico de la red, se pueden enviar mensajes de Openflow como entradas de flujo desde el controlador. Estos se mantienen en tablas de flujo dentro de los interruptores.
- Para agrupar entradas de flujo, el controlador puede configurar grupos a través de mensajes de grupo que se pueden almacenar en tablas de grupos dentro de los interruptores.
- Para obtener detalles de estadísticas del conmutador, se pueden enviar mensajes de Openflow como estadísticas de flujo, estadísticas de puertos, estadísticas de colas, estadísticas de grupos, estadísticas de tablas, etc. desde el controlador.
- Para verificar el estado de la conexión, se pueden enviar mensajes Openflow de solicitud y respuesta de eco desde el controlador o el interruptor.
- Los mensajes Openflow asincrónicos, como la eliminación de la regla de flujo del conmutador, el error de aplicación de la configuración del conmutador, el estado del puerto activo/inactivo del conmutador, etc., se pueden enviar desde el conmutador al controlador de actualización.
Hasta ahora, hemos analizado la arquitectura SDN, sus capas y el papel de Openflow para realizar el principio central de SDN para separar el plano de control del plano de datos. Ahora necesitamos ver cómo el controlador podría usar Openflow para configurar y administrar la red subyacente.
Básicamente, el controlador necesitaría implementar algún código de complemento de Openflow mediante el cual pueda enviar, recibir y comprender mensajes de Openflow hacia y desde los conmutadores de Openflow en la red subyacente.
Para configurar los conmutadores Openflow, el controlador debe insertar reglas de flujo en las tablas de conmutadores Openflow en función de las cuales este último puede manejar el tráfico de red que los golpea. El mensaje de Openflow para las entradas de flujo tiene un gran conjunto de campos de tupla para los criterios de coincidencia (campos L2, L3, L4, etc.) de los paquetes que provienen de la red, lo que en conjunto ayudaría a configurar las reglas de ACL, las reglas de política de seguridad, las reglas de ancho de banda de limitación de velocidad de QoS, reglas de enrutamiento, reglas de duplicación de puertos y reglas de modificación de paquetes.
Para monitorear los switches Openflow , Openflow proporciona varios mensajes de solicitud y respuesta para obtener información de estadísticas del switch y de la red y mensajes de eventos para actualizar el controlador sobre cambios manuales o fallas ocurridas en el lado del switch, incluido el evento de eliminación de flujo, cambios de estado del puerto UP/DOWN y más.
Para realizar algunas tareas específicas del proveedor en los conmutadores Openflow, Openflow proporciona mensajes experimentales en los que los proveedores tienen libertad para definir el cuerpo del mensaje e intercambiar información personalizada entre el controlador y los conmutadores. Así es como Openflow está siendo utilizado por muchas aplicaciones SDN para proporcionar soluciones para facilitar el control y la gestión de la red.
This article is co-authored by Tarun Thakur.
Referencias:
- https://www.sdxcentral.com/sdn/definitions/inside-sdn-architecture/
- https://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf
- http://noviflow.com/the-basics-of-sdn-and-the-openflow-network-architecture/