Esto no es nuevo. Llevamos hablando sobre SDN bastante tiempo. La idea que lo sustenta es sencilla, pero algo esquiva, y en ocasiones no bien explicada o entendida. Si vamos a la definición más extendida SDN es una arquitectura de red programable y adaptable, en la cual el plano de control reside en entidades centralizadas que poseen toda la información sobre el estado y pueden actuar sobre toda la configuración de la red para su adaptación a diferentes usos.
En realidad, de alguna manera las redes de comunicación IP siempre han sido «Software Defined» en el sentido de que su configuración no era totalmente estática y encontrábamos distintas piezas de software (protocolos de routing, sistemas de gestión) que podían actuar en determinados momentos sobre la misma. Si es cierto que nodo a nodo la configuración era en la mayoría de los casos estática y cambiarla para adaptarse a un entorno cambiante era un proceso complicado y farragoso, porque suponía actuar sobre potencialmente muchos nodos de forma coordinada.
La diferencia básica ahora es que existe una entidad centralizada (un «controlador») que conoce el estado dinámico de la red, y puede actuar sobre las configuraciones de manera coordinada y prácticamente simultánea. De esta forma, es posible que con relativamente poco esfuerzo podamos programar e instruir a la red para adaptarse a las circunstancias, modificar su modo de operación o reaccionar a cambios no programados. Esta programación normalmente se efectúa por un interfaz programático, un API que nos permite además automatizar el proceso.
Es decir, en lugar de tener que ir nodo por nodo actuando sobre la configuración individual, podemos atacar a una entidad que maneja el plano de control de la red, que a su vez actuará sobre los nodos necesarios para modificar la configuración de forwarding. Tomemos por ejemplo el caso de que por requisitos de negocio es necesario que una determinada aplicación utilice un camino de mínima latencia. En el caso de una red «tradicional» cambiaríamos las propiedades de las colas de prioridad y la clasificación del tráfico en cada uno de los nodos de manera separada, nodo a nodo. En una red de arquitectura SDN actuaríamos sobre el controlador mediante un interfaz que nos permitiría simplemente especificar que la aplicación X debe recibir el tratamiento T, el controlador se ocuparía de traducir esa intención en una ristra de configuraciones para cada uno de los nodos, propagar los cambios y asegurarse de que se ejecutan. Tareas que, normalmente, llevaba a cabo el pobre operador de red en horas intempestivas y armado de plantillas y un sistema de automatización en el mejor de los casos.
De hecho, este «intent networking» fué una de las primeras aplicaciones en las que los fabricantes de equipamiento (como Cisco) pensaron para las arquitecturas de SDN. Lo que pasa es que los clientes, que son más listos normalmente, enseguida vieron una posibilidad muy interesante para ellos: una forma de configurar y administrar redes que permitía de forma sencilla operar y mantener varias mallas de conectividad sobre diferentes sustratos. ¿Cómo se come esto? Bueno, es la única manera que se me ha ocurrido para no hablar de overlays y underlays, voy a intentar explicarlo
Vamos a ver, imaginemos que la corporación XYZ contrata servicios de conectividad de red al operador ABC para interconectar sus cientos de sedes y proporcionarles acceso a Internet. El operador ABC ofrece una conectividad orientada a negocios, normalmente basada en una red MPLS-VPN, con SLA (Service Level Agreement) estricto y una conectividad orientada al público general cubriendo el acceso a Internet con unos requisitos de disponibilidad generalmente buenos, buena capacidad, pero sin SLA estricto. Además, sobre MPLS se ofrecen generalmente otro tipo de servicios avanzados como acceso a gateways multimedia, servicios cloud de la operadora, presencia Internet, etc. Problema: el coste del Mbps en estas redes es considerablemente más alto que en las redes «públicas» de acceso a Internet, para que nos entendamos, las redes de acceso residencial. Es decir, tenemos dos sustratos, dos underlays diferentes cada uno con unas características de caudal, coste y disponibilidad. Si fuéramos capaces de generar un esquema de conectividad entre los nodos de la red utilizando esos dos sustratos podríamos concebir el encaminar el tráfico de nuestras aplicaciones por el sustrato/underlay que más nos conviniese, en función de los requisitos de las mismas. Por ejemplo, una aplicación de colaboración multimedia requiere latencia mínima y un caudal predecible, y si es crítica para nuestro negocio además querremos que siempre esté disponible. Otras aplicaciones pueden no tener esos requisitos, por lo que podríamos encaminar el tráfico de la aplicación de colaboración sobre el sustrato MPLS, mientras que otras aplicaciones menos críticas o con menos demanda las podríamos encaminar a través del sustrato Internet público. Requeriríamos menos caudal en la red MPLS, y por lo tanto nos podríamos permitir unos gastos menores en esa conectividad que es más cara de por sí. En la siguiente entrada hablaremos un poco más sobre esta capacidad.