b'\n_START_ARTICLE_\nRedes definidas por software\n_START_PARAGRAPH_\nLas redes definidas por software (en ingl\xc3\xa9s Software Defined Networking, SDN) son un conjunto de t\xc3\xa9cnicas relacionadas con el \xc3\xa1rea de redes computacionales, cuyo objetivo es facilitar la implementaci\xc3\xb3n e implantaci\xc3\xb3n de servicios de red de una manera determinista, din\xc3\xa1mica y escalable, evitando al administrador de red gestionar dichos servicios a bajo nivel. Todo esto se consigue mediante la separaci\xc3\xb3n del plano de control (software) del plano de datos (hardware).\xe2\x80\x8b\n_START_SECTION_\nHistoria\n_START_PARAGRAPH_\nGracias a SDN, el dise\xc3\xb1o y gesti\xc3\xb3n de redes se ha vuelto m\xc3\xa1s innovador en los \xc3\xbaltimos a\xc3\xb1os. Sin embargo, esta tecnolog\xc3\xada no es resultado de una s\xc3\xbabita aparici\xc3\xb3n, sino de una larga historia de innovaciones dirigidas a hacer m\xc3\xa1s programables las redes._NEWLINE_La historia de SDN comienza 20 a\xc3\xb1os atr\xc3\xa1s, m\xc3\xa1s o menos en el comienzo de lo que hoy conocemos como Internet, el cual, debido a su \xc3\xa9xito, intensific\xc3\xb3 la necesidad de gestionar y evolucionar las infraestructuras de redes, es decir, hacerlas programables. A partir de este momento, la historia se divide en tres etapas diferenciadas: redes activas (1995 a 2000 aprox.), separaci\xc3\xb3n del plano de control del plano de datos (2001-2007 aprox.) y la aparici\xc3\xb3n de la interfaz de programaci\xc3\xb3n de aplicaciones de Openflow (2007-2010 aprox.).\xe2\x80\x8b  En 2014 Avaya hizo una demostraci\xc3\xb3n de redes definidas por software usando Shortest Path Bridging y OpenStack, eliminando la configuraci\xc3\xb3n Manual.\xe2\x80\x8b\xe2\x80\x8b\n_START_SECTION_\nRedes activas\n_START_PARAGRAPH_\nEl despegue de Internet, a principio de los 90, provoc\xc3\xb3 que las aplicaciones antiguas fueran superadas por otras m\xc3\xa1s novedosas. El aumento del uso de estas llev\xc3\xb3 a los investigadores a dise\xc3\xb1ar y probar nuevos protocolos de red. Sin embargo, despu\xc3\xa9s de este proceso, estos protocolos deb\xc3\xadan ser estandarizados por el IETF, proceso muy lento que frustraba a muchos investigadores._NEWLINE_Como respuesta, algunos investigadores apostaron por un enfoque de apertura del control de las redes, an\xc3\xa1logo a reprogramar un PC aut\xc3\xb3nomo con relativa facilidad. Como las redes convencionales no son programables, surgieron las redes activas orientadas hacia el control de la red, conceptualizando una interfaz de programaci\xc3\xb3n (API) que expone los recursos (procesamiento, almacenamiento, colas de paquetes, etc) en nodos de red individuales y soporta la construcci\xc3\xb3n de funcionalidades personalizadas para aplicar a un subconjunto de paquetes que pasan a trav\xc3\xa9s del nodo. Sin embargo, hab\xc3\xada muchos otros que defend\xc3\xadan la simplicidad de la red como \xc3\xbanica forma de que Internet tuviese \xc3\xa9xito. El programa de investigaci\xc3\xb3n de las redes activas se dedic\xc3\xb3 por lo tanto, a explorar alternativas a los servicios proporcionados por Internet v\xc3\xada IP o ATM._NEWLINE_El impulso tecnol\xc3\xb3gico que alent\xc3\xb3 a las redes activas permiti\xc3\xb3 reducir el coste computacional, avanzar en lenguajes de programaci\xc3\xb3n y en la tecnolog\xc3\xada de m\xc3\xa1quinas virtuales. Un catalizador importante en este ecosistema fue el aumento de inter\xc3\xa9s de agencias, que supuso la creaci\xc3\xb3n de programas como el Active Networks program del DARPA, desde mediados de los 90 hasta principios de los 2000._NEWLINE_Las redes activas, por lo tanto, aunque no tuvieron un despliegue extendido, ofrecieron contribuciones relacionadas con SDN como funciones programables en la red, virtualizaci\xc3\xb3n de redes y la visi\xc3\xb3n de una arquitectura unificada en distintos aparatos de red como cortafuegos, IDS, NAT, etc.\xe2\x80\x8b\n_START_SECTION_\nSeparaci\xc3\xb3n de plano de control y datos\n_START_PARAGRAPH_\nA principios de los 2000, el aumento del volumen de tr\xc3\xa1fico y la necesidad de unas redes de confianza, predecibles y manejables, llev\xc3\xb3 a los investigadores a buscar mejores enfoques para ciertas funciones dentro de la gesti\xc3\xb3n de redes como la ingenier\xc3\xada de tr\xc3\xa1fico, cuyos recursos y m\xc3\xa9todos usando protocolos de enrutamiento convencionales eran muy escasos._NEWLINE_Los enrutadores y conmutadores convencionales, ten\xc3\xadan una estrecha integraci\xc3\xb3n entre los planos de control y de datos, que realizaba depuraci\xc3\xb3n de problemas de configuraci\xc3\xb3n o control del comportamiento del enrutamiento, una tarea muy desafiante y complicada. Para enfrentarse a dicha tarea, la idea de separar ambos planos empez\xc3\xb3 a florecer con distintos enfoques._NEWLINE_Debido al crecimiento de Internet, las empresas de equipos hardware comenzaron a implementar la l\xc3\xb3gica de reenv\xc3\xado de paquetes en hardware (plano de datos), separada del plano de control y los ISPs a luchar para poder gestionar sus redes crecientes y poder aportar a sus clientes servicios que las hiciesen m\xc3\xa1s seguras (como las VPN). Todo esto dio lugar a dos innovaciones principales: una interfaz abierta entre ambos planos, como ForCES (separaci\xc3\xb3n del elemento de control y reenv\xc3\xado) estandarizada por la IETF y la interfaz Netlink a la funcionalidad de reenv\xc3\xado de paquetes a nivel de n\xc3\xbacleo de Linux; y un control l\xc3\xb3gico centralizado de la red, como con RCP (plataforma de control de enrutamiento), arquitecturas SoftRouter y el protocolo PCE (Path Computation Element) del IETF, ambos conceptos clave en dise\xc3\xb1os futuros de SDN.\xe2\x80\x8b\n_START_SECTION_\nAparici\xc3\xb3n de la API de Openflow\n_START_PARAGRAPH_\nPara abordar la visi\xc3\xb3n de separaci\xc3\xb3n de plano de datos y de control, se empez\xc3\xb3 a investigar nuevas arquitecturas para control l\xc3\xb3gico centralizado. El proyecto 4D, uno de los frutos de estas investigaciones, establec\xc3\xada cuatro capas principales: el plano de datos, para procesar paquetes bas\xc3\xa1ndose en reglas configurables; el plano de descubrimiento, encargado de coleccionar medidas topol\xc3\xb3gicas y del tr\xc3\xa1fico; el plano de diseminaci\xc3\xb3n, para instalar reglas de procesado de paquetes; y el plano de decisi\xc3\xb3n, que consist\xc3\xada en controladores l\xc3\xb3gicos centralizados que convert\xc3\xadan objetivos a nivel de red en estado de manejo de paquetes. Numerosos grupos de investigaci\xc3\xb3n comenzaron el desarrollo de sistemas basados en este enfoque, y en particular, el proyecto Ethane, y su predecesor directo SANE. El despliegue operacional de este proyecto en la universidad de Stanford, comenz\xc3\xb3 la etapa de creaci\xc3\xb3n de Openflow, y en particular, el dise\xc3\xb1o simple de switch del proyecto Ethane, se convirti\xc3\xb3 en la base de la API de Openflow._NEWLINE_A mediados de la primera d\xc3\xa9cada del siglo XXI, diversos grupos de investigaci\xc3\xb3n y empresas empezaron a interesarse por la experimentaci\xc3\xb3n de redes a escala, debido al \xc3\xa9xito de infraestructuras experimentales como PlanetLab y Emulab, y la disponibilidad de m\xc3\xa1s fondos por parte del gobierno para invertir en este sector. Uno de los resultados de este entusiasmo fue la creaci\xc3\xb3n de GENI (Global Environment for Networking Innovations) y el programa EU FIRE. Al mismo tiempo, en la universidad de Stanford, un grupo de investigadores cre\xc3\xb3 el  Clean Slate Program, enfocado en la experimentaci\xc3\xb3n en redes universitarias m\xc3\xa1s tratables y locales, que dio lugar al protocolo Openflow._NEWLINE_Gracias a la adopci\xc3\xb3n de Openflow en las empresas, que abrieron sus API para permitir a los programadores controlar ciertos comportamientos de reenv\xc3\xado, la versi\xc3\xb3n inicial de este protocolo se estableci\xc3\xb3 en los switches a trav\xc3\xa9s de una simple actualizaci\xc3\xb3n de firmware, sin necesidad de actualizar el hardware._NEWLINE_Openflow, aunque utilice muchos de los principios de anteriores trabajos en la separaci\xc3\xb3n de planos, tambi\xc3\xa9n aporta bastantes contribuciones como la generalizaci\xc3\xb3n de dispositivos de red y funciones, la visi\xc3\xb3n de un sistema operativo de red y t\xc3\xa9cnicas de gesti\xc3\xb3n distribuida del estado de aparatos de red entre otras.\xe2\x80\x8b\n_START_SECTION_\nSDN no es OpenFlow\n_START_PARAGRAPH_\nA menudo se apunta a OpenFlow como sin\xc3\xb3nimo de SDN, pero en realidad, es simplemente un elemento que forma parte de la arquitectura SDN. OpenFlow es un est\xc3\xa1ndar abierto para un protocolo de comunicaciones que permite al plano de control interactuar con el plano de datos (OpenFlow, sin embargo, no es el \xc3\xbanico protocolo disponible o en desarrollo para SDN, aunque s\xc3\xad est\xc3\xa1 convirti\xc3\xa9ndose en el modelo est\xc3\xa1ndar de implementaci\xc3\xb3n de una SDN).\xe2\x80\x8b\n_START_SECTION_\nConcepto de SDN\n_START_PARAGRAPH_\nLas redes definidas por software (SDN) constan de una arquitectura de red cuyo dinamismo, manejabilidad, rentabilidad y adaptabilidad permiten que sea adecuada para la naturaleza din\xc3\xa1mica y de alto consumo de ancho de banda de las aplicaciones modernas. Como hemos visto en apartados anteriores, SDN separa el control de la red de las funciones de reenv\xc3\xado con una API bien definida entre ambos, permitiendo la programabilidad del control de red y la abstracci\xc3\xb3n de la infraestructura subyacente.\xe2\x80\x8b\n_START_SECTION_\nFuncionamiento de SDN\n_START_PARAGRAPH_\nLos proveedores de redes SDN ofrecen una amplia variedad de arquitecturas competentes, centradas en el objetivo comentado anteriormente: separar el plano de control del plano de datos, y formadas por un controlador SDN, una API hacia el sur (southbound API) y una API hacia el norte (northbound API).\xe2\x80\x8b\n_START_SECTION_\nControlador SDN\n_START_PARAGRAPH_\nUn controlador SDN en una red SDN toma el papel del cerebro de dicha red, es decir, el punto de control estrat\xc3\xa9gico que retransmite informaci\xc3\xb3n a los conmutadores y enrutadores de debajo (a trav\xc3\xa9s del API sur) y a las aplicaciones y la l\xc3\xb3gica de negocio encima (a trav\xc3\xa9s del API norte). Recientemente, se persigue la tarea de asociar dominios de controladores SDN, usando interfaces de aplicaciones comunes, como los protocolos Openflow y OVSDB (Open Virtual Switch DataBase). _NEWLINE__NEWLINE_Un controlador SDN se basa t\xc3\xadpicamente en un conjunto de m\xc3\xb3dulos pluggable (que se pueden conectar y desconectar libre y f\xc3\xa1cilmente), que realizan diversas tareas de red, como realizar un inventario de todos los aparatos de red disponibles en \xc3\xa9sta, colectar sus capacidades, agrupar estad\xc3\xadsticas de red, etc.\xe2\x80\x8b\n_START_SECTION_\nNorthbound y Southbound API\n_START_PARAGRAPH_\nComo coment\xc3\xa1bamos en el subapartado anterior, estas interfaces sirven para conectar el controlador SDN a los aparatos de red por debajo (sur) y por otro a los servicios y aplicaciones por encima (norte)._NEWLINE_Las API sur facilitan el control en la red, permitiendo al controlador realizar cambios din\xc3\xa1micos de acuerdo a las demandas en tiempo real y las necesidades. Openflow, desarrollado por la ONF (Open Networking Foundation) es la primera y m\xc3\xa1s conocida de estas interfaces. Adem\xc3\xa1s de \xc3\xa9sta, Cisco OpFlex es otra bien conocida.\xe2\x80\x8b_NEWLINE_Las API norte en cambio, pueden ser usadas para facilitar la innovaci\xc3\xb3n y permitir la organizaci\xc3\xb3n y automatizaci\xc3\xb3n de la red para suplir las necesidades de las diferentes aplicaciones a trav\xc3\xa9s de la programabilidad de la red SDN. Se podr\xc3\xada decir que estas interfaces son las m\xc3\xa1s cr\xc3\xadticas en un entorno SDN, debido a que soportan una gran variedad de aplicaciones y servicios por encima y por lo tanto con algunas de ellas no funciona correctamente. Hay una amplia variedad de posibles interfaces de este tipo situadas en diferentes lugares de la pila para controlar los diferentes tipos de aplicaciones a trav\xc3\xa9s del controlador SDN. Sin embargo, estas interfaces son el componente m\xc3\xa1s indeterminado de todo el entorno SDN, lo que ha resultado en un enfoque por parte de la ONF hacia este componente.\xe2\x80\x8b\n_START_SECTION_\nModelos de despliegue de SDN\n_START_PARAGRAPH_\nHay dos modelos: proactivo y reactivo. Cuando un flujo llega a un switch se realiza un mapeo de la tabla de flujos. En el caso de que no se encuentre coincidencia, se env\xc3\xada una petici\xc3\xb3n al controlador para instrucciones m\xc3\xa1s extensas. En modo reactivo, el controlador act\xc3\xbaa despu\xc3\xa9s de estas peticiones y crea una regla en la tabla de flujos para el paquete correspondiente si es necesario. En modo proactivo, sin embargo, el controlador llena entradas de la tabla de flujos para cada posible coincidencia de tr\xc3\xa1fico para ese switch, algo parecido con las t\xc3\xadpicas entradas de tablas de enrutamiento. Adem\xc3\xa1s de estos modelos por separados, se puede combinar en una red ambos modelos en forma de un h\xc3\xadbrido, para aportar las ventajas de ambos.\xe2\x80\x8b\n_START_SECTION_\nOpen Networking Foundation\n_START_PARAGRAPH_\nLa Open Networking Foundation (ONF) es una organizaci\xc3\xb3n impulsada por los usuarios dedicada a la promoci\xc3\xb3n y adopci\xc3\xb3n de SDN a trav\xc3\xa9s del desarrollo de est\xc3\xa1ndares abiertos. Esta organizaci\xc3\xb3n, enfatiza la colaboraci\xc3\xb3n y el proceso abierto de desarrollo conducido por los usuarios, dando como resultado el mantenimiento del est\xc3\xa1ndar abierto Openflow, el primer est\xc3\xa1ndar SDN y un elemento vital para las arquitecturas abiertas de SDN._NEWLINE_Hoy en d\xc3\xada las comunidades de esta organizaci\xc3\xb3n siguen analizando los requerimientos de SDN y mejorando el est\xc3\xa1ndar Openflow, para beneficiar SDN con nuevos est\xc3\xa1ndares y suplir las necesidades de despliegues comerciales._NEWLINE_\xe2\x80\x8b\n_START_SECTION_\nConclusi\xc3\xb3n\n_START_PARAGRAPH_\nSDN provee una nueva arquitectura de red din\xc3\xa1mica que transforma las redes troncales en plataformas de distribuci\xc3\xb3n de servicios._NEWLINE_En cuesti\xc3\xb3n de manejo de redes, cada vez se confiar\xc3\xa1 m\xc3\xa1s y m\xc3\xa1s en el software, que acelerar\xc3\xa1 la innovaci\xc3\xb3n de \xc3\xa9stas, como ha conseguido en los dominios de computaci\xc3\xb3n y almacenamiento. Con todas estas ventajas que permite el uso de software, SDN est\xc3\xa1 en el camino de convertirse en la nueva regla para redes en un futuro cercano.\xe2\x80\x8b'