OpenFlow es una tecnología de switching que surgió a raíz del proyecto de Investigación: “OpenFlow: Enabling Innovation in Campus Networks” de 2008 en la Universidad de Stanford. Se define como un protocolo emergente y abierto de comunicaciones que permite a un servidor de software determinar el camino de reenvío de paquetes que debería seguir en una red de switches. Con el protocolo OpenFlow, una red puede ser gestionada como un todo, no como un número de dispositivos que gestionar individualmente, es el propio servidor el que dice a los switches dónde deben enviar los paquetes. Con esta tecnología, las decisiones que impliquen el movimiento de paquetes están centralizadas, por lo que la red puede ser programada independientemente de los switches. En un switch convencional, el reenvío de paquetes Datapath y el encaminamiento de alto nivel (control path) se realizan en el mismo dispositivo, sin embargo en los switches OpenFlow ambos se separan. Con OpenFlow, una parte del datapath reside en el mismo switch, pero es un controlador el que realiza las decisiones de encaminamiento de alto nivel. Ambos elementos se comunican por medio del protocolo OpenFlow. Esta metodología, conocida como SDN permite una mayor efectividad en el uso de los recursos de la red que en una red convencional. OpenFlow está pensada para afrontar la movilidad de máquinas virtuales (VM), redes con misiones críticas o redes NGN móviles.
Historia
El Open Flow Switch Consortium ha mantenido la especificación hasta hace poco, cuando la Open Networking Foundation anunció que asumiría esa responsabilidad. En 2011 la ONF (Open Networking Foundation ) se fundó con el objetivo de estandarizar las tecnologías emergentes impulsando el software a la vanguardia de la gestión de red y de los centros de datos. Mientras que la primera versión del protocolo OpenFlow (versión 1.1) se lanzó en febrero de 2011, la segunda (versión 1.2) fue supervisada por la ONF que tiene el control sobre la especificación. Actualmente la versión en vigor es la 1.4.0. Miembros fundadores que podemos citar son Google, Facebook y Microsoft, a los que se han ido añadiendo: Allied Telesis, Citrix, Cisco, Dell, HP, F5 Networks, IBM, NEC, Huawei, Juniper Networks, Oracle y VMware, todas ellas grandes empresas del sector de las telecomunicaciones.
Propuesta
Lo que propone OpenFlow: una manera para que los investigadores puedan experimentar con protocolos en las redes que se usan a diario. Además supone un compromiso pragmático: por una parte permite a los investigadores experimentar con switches heterogéneos de manera uniforme a la velocidad de la línea y con una densidad de puertos muy alta. Por otra parte, los fabricantes no tienen que exponer los procesos internos de sus switches. La propuesta de OpenFlow es muy clara: permitir que los investigadores puedan evaluar sus ideas en un entorno de trabajo real y ser un componente muy útil en los bancos de pruebas a gran escala.
Antecedentes
Las redes se han convertido en una parte crítica de la estructura de negocios, casas, escuelas… Este éxito presenta dos caras: por una parte es bueno para los investigadores, su trabajo es más relevante, pero sus posibilidades de realizar grandes avances y experimentos son más remotas. No hay ninguna manera práctica de experimentar con nuevos protocolos de encaminamiento, alternativas a IP) con configuraciones lo suficientemente realistas. El gran obstáculo que presentan las redes actuales es la incapacidad de poder trabajar con tráficos reales. Para que una tecnología se despliegue extensamente se debe ganar la confianza suficiente por parte de los especialistas. La idea de este tipo de plataforma no es original, aunque con OpenFlow se pretende obtener un rendimiento mayor. Como antecedente tenemos a la red GENI , una red cuya propuesta es facilitar el poder experimentar con nuevas arquitecturas de red y sistemas distribuidos. Estas redes programables llaman a routers/switches programables que, usando la virtualización, pueden procesar paquetes de experimentos aislados entre sí simultáneamente. Introducimos por tanto un nuevo término en las redes, que está cobrando mucho protagonismo en los últimos tiempos.
El Switch OpenFlow
La idea básica es simple: explotar el hecho de que la mayoría de los switches Ethernet contienen tablas de flujos (Flow-Tables), que trabajan a la velocidad de la línea para implementar firewalls, NAT, QoS y recolectar estadísticas. Aunque las Tablas de Flujos que maneja cada fabricante son propias, se han aprovechado características observadas y comunes a todas ellas. Precisamente eso es lo que ofrece OpenFlow, un protocolo abierto para poder programar las tablas de flujo en diferentes switches y routers. Los administradores de la red solo necesitarían dividir el tráfico entre producción y el dedicado a la investigación. De esta manera, se conseguiría experimentar con nuevos protocolos, nuevos modelos de seguridad, esquemas de direccionamiento, incluso alternativas para IP y en definitiva una innovación mayor. Visto de esta manera, OpenFlow podría ser una generalización de las VLAN´s. El tráfico de producción no se vería afectado ya que está aislado y se procesaría de la misma manera que se ha estado realizando hasta hoy día. Las acciones que pueden soportar los switches OpenFlow son extensibles, si bien es necesario tener unas características mínimas y comunes a todos ellos.
Partes de un Switch OpenFlow
Un switch OpenFlow consiste en al menos tres partes:
Tabla de flujos: con una acción asociada a cada entrada de la tabla, indicando al switch cómo debe procesar ese flujo Canal seguro: que conecte el switch a un proceso de control remoto (controlador), permitiendo comandos y paquetes se puedan enviar entre el switch y el controlador usando el protocolo OpenFlow Controlador: Un controlador añade y elimina entradas en la tabla de flujos para poder permitir los experimentos.
Un controlador estático podría ser una simple aplicación funcionando en un PC que añadirá estáticamente flujos y que puede interconectarse a su vez a una serie de ordenadores con funciones de analizadores de tráfico. Existen también controladores más sofisticados que dinámicamente añaden/eliminan flujos. De esta manera, un Administrador de Red será capaz de gestionar todos los flujos y cómo serán procesados. Un controlador de estas características podría ser soportado por varios investigadores, cada uno con diferentes cuentas y permisos, permitiendo que todos ellos puedan realizar múltiples experimentos con diferentes conjuntos de flujos. El protocolo del controlador del switch trabaja sobre la capa TLS (Transport Layer Security) o conexiones TCP sin seguridad.
Tipos de Switches
Existen dos tipos de switches: aquellos switches OpenFlow-only (solo OpenFlow) que no son compatibles con las capas 2 y 3 convencionales y los híbridos.
Switches OpenFlow-only Un switch que soporta OpenFlow, contiene múltiples tablas de flujos, y cada flujo contiene múltiples entradas de flujo. El procesado define cómo los paquetes interactuarán con estas tablas de flujos. Requiere que tenga al menos una tabla de flujo y opcionalmente más. Cuantas menos entradas más simplificado será el procesado.
La figura muestra un ejemplo de un switch OpenFlow:
En este contexto los flujos están ampliamente definidos, solo están limitados por las capacidades de una determinada implementación de la Tabla de Flujo. Por ejemplo un flujo puede ser una conexión TCP, o todos los paquetes de una determinada dirección MAC o IP, todos los paquetes con la misma etiqueta VLAN, o todos los paquetes de un mismo puerto del switch. Para experimentos que no incluyen paquetes IPv4 , un flujo podría ser definido para que todos los paquetes cumplan una cabecera específica (no estándar). En la sección ejemplos se explicará más ampliamente este concepto.
Switches OpenFlow-híbridos Switches que soportan tanto la operación OpenFlow como el Switching Ethernet convencional. Operaciones habituales pueden ser: Switching Ethernet de Capa 2, aislamiento de tráfico con VLAN, nivel 3 o de routing (IPV4, IPV6), listas de acceso o QoS. Estos switches deberán proveer un mecanismo de clasificación fuera de OpenFlow que enrute el tráfico o bien ser procesado por OpenFlow. Por ejemplo, un switch deberá usar una etiqueta VLAN o puerto de entrada para decidir si se procesa el paquete de una manera u otra o debe redirigirlos hacia el procesador OpenFlow. Este mecanismo de clasificación sale fuera del ámbito de la especificación. El protocolo OpenFlow permite que el switch sea controlado por dos o más controladores para incrementar el rendimiento y la robustez del sistema. A continuación se muestra una posible configuración de este tipo de switches, en el que todas las tablas de flujos se gestionan por el mismo controlador.
Como funciona OpenFlow
Los switches tradicionales usan STP, SPB, TRILL para determinar cómo se reenvían los paquetes. OpenFlow traslada esta decisión de reenvío de los switches a los controladores, típicamente un servidor o una estación de trabajo. Una aplicación de gestión se ejecutará en las interfaces del controlador que une todos los switches en la red, facilitando la configuración de caminos de reenvío que utilizarán todo el ancho de banda disponible. La especificación define el protocolo entre el controlador y los switches y un conjunto de operaciones que se pueden realizar entre ellos. Las instrucciones de reenvío se basan en el flujo, que consiste en que todos los paquetes comparten una serie de características comunes. Existen infinidad de parámetros que pueden especificarse para definir un flujo. Entre los posibles criterios podemos incluir los puertos por donde se reciben los paquetes cuando llegan, el puerto Ethernet de origen, la etiqueta VLAN, el destino Ethernet o el puerto IP y otro número de características de los paquetes. Un nuevo flujo se debe crear cuando un paquete que llega no encuentra ninguna coincidencia con ninguna entrada de la tabla. El switch debería tener configurado un descartado de paquetes para el flujo que no haya sido definido, pero en la mayoría de los casos, el paquete será enviado al controlador. El controlador entonces define un nuevo flujo para ese paquete y crea una o más entradas para la tabla. Este envía la entrada o entradas al switch para que sean añadidas a las tablas de flujo. Finalmente, el paquete se envía de vuelta al switch para ser procesado con las nuevas entradas creadas.
Flujos
Cada flujo de entrada tiene asociada una acción simple. Las tres básicas son:
Reenvío de flujo de paquetes a un puerto dado (o puertos). Esto permite que los paquetes sean encaminados a través de la red. En la mayoría de los switches sucede a la velocidad de la línea. Encapsulación y reenvío de este flujo de paquetes al controlador. El paquete será enviado al Canal Seguro, donde se encapsula y se envía al controlador. Típicamente se usa para el primer paquete en un nuevo flujo, para que el controlador pueda decidir si el flujo debe ser añadido a la tabla de flujos. También se puede usar para reenviar todos los paquetes al controlador para que sean procesados. Descartar este flujo de paquetes. Puede ser usado por seguridad , para parar ataques de denegación de servicio o reducir el falso tráfico de descubrimiento broadcast desde los hosts finales.
Tablas de Flujos
Una entrada de flujo tendrá este formato:
Se identifica principalmente por sus coincidencias y prioridad. Ambos campos identifican un flujo único en la Tabla de Flujos. Podemos citar 3 campos principales:
La cabecera del paquete que define el flujo. La acción, que define como deben ser procesados los paquetes. Las estadísticas que llevan la monitorización del número de paquetes y los bytes de cada flujo y el tiempo desde el cual el último paquete coincidió el flujo (esto permite el borrado automático de flujos inactivos).