Gamers ahora disponen en Latam de SSD más fría
Como es usual con las nuevas tecnologías, no hay una definición universalmente aceptada sobre lo que significa Software Defined Networking (SDN) -o redes definidas por software. En el último año o dos, la mayoría de las definiciones se han centrado en desasociarse del plano de control de red desde el plano del renvío de red.
La disociación de los planos de control y renvío de la red no es un concepto nuevo. Es una característica clave de MPLS, y también es una característica de muchas redes Wi-Fi contemporáneas. Sin embargo, si se mira a SDN estrictamente como la desvinculación del plano de control de red desde el plano de renvío de red, entonces su valor se limita a funciones como la reducción de la latencia de red.
La definición de SDN que está surgiendo actualmente se centra menos en el desacoplamiento y más en proporcionar interfases de programación en el equipo de red, haya o no una separación de planos de control y renvío. Una razón secundaria para este cambio de enfoque se debe a que Cisco anunció recientemente que como parte de su oferta de SDN, proporcionará API en las múltiples plataformas que ellos proporcionan.
Este no es solo un enfoque de Cisco, ya que otros fabricantes, incluyendo Arista, Extreme y Juniper, actualmente proporcionan acceso directo a sus productos. Una ventaja de este enfoque es que permite el acceso muy detallado y el control de los elementos de red; sin embargo, no proporciona un punto central de control y es específico del proveedor. Mientras que algunos vendedores de servicios de red pueden adoptar este enfoque en el corto plazo, es poco probable que ganen muchos adeptos en el mercado empresarial dentro del futuro previsible.
Una razón más poderosa para el cambio de enfoque de la definición de SDN es que si SDN se ve como proveedor de interfases de programación en equipos de red, entonces su valor es mucho más amplio. Visto de esta manera, SDN permite que las organizaciones de TI remplacen una interfase manual de los equipos de red, con una interfase de programación que pueda permitir la automatización de tareas como la configuración y administración de políticas y también pueda habilitar la red para responder dinámicamente a los requerimientos de la aplicación.
Con una definición más común de SDN, el control global de la red se consigue mediante la centralización lógica de la función de plano de control, y la organización de operaciones de red puede hacer frente a un grupo de dispositivos de red como una sola entidad. Con un SDN, los flujos de red se controlan en el nivel de la abstracción de la red global, en lugar de en el nivel de los dispositivos individuales, por lo general, pero no siempre, con la ayuda del protocolo OpenFlow.
Arquitectura SDN
El grupo que más se asocia con el desarrollo de normas basadas en SDN es la Open Networking Foundation (ONF). La ONF se puso en marcha en el 2011 y tiene como visión hacer que el SDN basado en OpenFlow sea la nueva norma para las redes. Para lograr esta visión, la ONF ha asumido la responsabilidad de conducir la estandarización del protocolo OpenFlow. La amplitud del ecosistema SDN se refleja en el hecho de que la ONF en la actualidad cuenta con más de 70 miembros de diversos tipos, incluyendo a los proveedores que proporcionan el silicio, así como los switches, dispositivos de red, controladores, equipos de prueba, servicios de telecomunicaciones, servicios de centros de datos de hiper-escala y los teléfonos inteligentes.
Una arquitectura de capas para SDN se muestra en la figura 1. En esta arquitectura, la funcionalidad del plano de control se centraliza en el software del controlador de SDN. La mayor parte del tiempo que se ha discutido SDN, el protocolo OpenFlow se utiliza para programar el comportamiento de renvío del switch. Hay, sin embargo, alternativas al uso de OpenFlow, incluyendo Extensible Messaging and Presence Protocol (XMPP), Network Configuration Protocol (Netcong) y OpenStack de Rackspace y la NASA.
En este modelo, las aplicaciones se escriben en un conjunto de API que son proporcionadas por el controlador SDN. Desafortunadamente, estas API no están normalizadas, por lo que una aplicación que se ejecuta en un controlador SDN determinado, tendría que ser modificado para funcionar en otro controlador SDN. Ejemplos de las aplicaciones centradas en la red que podrían ejecutarse en un controlador SDN se dan a continuación.
El controlador SDN soporta un número de unidades que controlan el comportamiento de los elementos subyacentes de la red, de modo que la red va a proporcionar los servicios de red deseados. El controlador proporciona funcionalidad de gestión de plano como el rendimiento y gestión de fallas a través de SNMP y otros protocolos estándar, y por lo general ocupa la gestión de configuración de los dispositivos de OpenFlow con el fin de proporcionar topología de la red, el renvío, QoS, y de gestión de enlace.
OpenFlow
Los switches y routers Ethernet más modernos contienen tablas de flujo (por lo general con el soporte de apoyo de memoria de contenido ternario direccionable) que funcionan a velocidad de la línea y se utilizan para realizar funciones de desvío basadas en la capa 2,3, y 4 encabezados de los paquetes. Mientras que cada tabla de flujo del proveedor es diferente, hay un conjunto común de funciones soportadas por una amplia variedad de switches y routers. Este conjunto común de funciones es aprovechado por OpenFlow, que es un protocolo abierto entre un controlador central OpenFlow y un switch de OpenFlow y que, como se ha señalado, se puede utilizar para programar el comportamiento de renvío del switch.
Con OpenFlow, un solo controlador central puede programar todos los switches físicos y virtuales en una red. Si bien es posible implementar SDN con un solo controlador, vendedores como Big Switch y NEC han anunciado un clúster de producción de alta disponibilidad, o su intención de aplicar un conjunto de controladores. Es probable que IBM haga lo mismo.
El protocolo OpenFlow se desarrolló en Stanford, y la v1.0 fue publicada a finales del 2009 y la v1.1 a principios del 2011. En marzo del 2011 se creó la ONF y los derechos de propiedad intelectual de OpenFlow fueron transferidos a ella. Parte de la tarea de la ONF es controlar y comercializar OpenFlow. Con ese objetivo en mente, la ONF publicó recientemente OpenFlow v1.3 y en marzo del 2012, la ONF patrocinó un evento de interoperabilidad que estaba abierto a todos los miembros de la ONF. Un total de 14 empresas y dos instituciones de investigación participaron en el evento, que se centró en la norma OpenFlow v1.0. La información sobre las pruebas hechas y las lecciones aprendidas se pueden encontrar en el documento de la ONF Interoperability Event.
En un switch de OpenFlow, todas las funciones de control de un interruptor tradicional (por ejemplo, los protocolos de enrutamiento que se utilizan para construir bases de renvío de información (FIB)) se ejecutan en el controlador central OpenFlow. Un switch con OpenFlow habilitado (llamado switch OpenFlow híbrido en V1.1) ofrece el servicio de renvío y el bridging y routing tradicionales de Ethernet. Los switches híbridos permiten el bridging/routing tradicional y de OpenFlow para compartir la misma infraestructura de Ethernet.
Muchos swithces de capa 3/3 de alta funcionalidad pueden convertirse a switches OpenFlow híbridos por la relativamente simple adición de un agente OpenFlow en firmware soportado por el Network Operating System (NOS) del switch nativo. Alternativamente, una vez que los fabricantes de semiconductores hayan producido chips que efectivamente procesan el protocolo OpenFlow, un switch de OpenFlow sería extremadamente sencillo y barato de construir, ya que tendría muy poco software residente y no requeriría una potente CPU o una memoria de gran tamaño para soportar la extensiva funcionalidad de control que viene envasada típicamente en el NOS tradicional.
Hay muchas maneras en que la centralización del control, la programación y las características de renvío de flujo de OpenFlow se pueden aprovechar para dar valor a las organizaciones de TI. Por ejemplo, uno de los principales beneficios de OpenFlow es la naturaleza centralizada de la FIB. La centralización permite que las rutas óptimas se calculen de manera determinista para cada flujo, aprovechando un modelo completo de la topología de extremo a extremo de la red. Basado en la comprensión de los niveles de servicio requeridos para cada tipo de flujo, el controlador OpenFlow centralizado puede aplicar los principios de ingeniería de tráfico para asegurar que cada flujo sea mantenido de forma apropiada. Una ventaja de esta capacidad es que permite que la red responda dinámicamente a los requisitos de la aplicación. También permite una notable mejor utilización de la red sin sacrificar la calidad del servicio.
Otro beneficio es que los switches OpenFlow pueden filtrar los paquetes a medida que entran en la red; y, por lo tanto, estos interruptores pueden actuar como firewalls simples en el borde de la red. Con los switches OpenFlow que soportan la modificación del encabezado del paquete, una característica opcional en OpenFlow v1.0, el controlador OpenFlow también será capaz de hacer que el switch redirija cierto flujo de tráfico sospechoso hacia capas superiores de seguridad, como sistemas IDS/IPS, firewalls de aplicaciones y dispositivos de prevención de pérdida de datos (DLP, Data Loss Prevention).
Los switches OpenFlow que soportan la modificación de encabezados de los paquetes también podrán funcionar como un simple y rentable dispositivo de equilibrio de carga. Con la funcionalidad de modificación, un nuevo flujo puede convertirse en una nueva entrada de la tabla de flujo que está dirigida a un servidor seleccionado por las políticas de equilibrio de carga del controlador OpenFlow. Con el fin de crear las políticas de equilibrio de carga basadas en la carga del servidor, el controlador OpenFlow tendría que supervisar al grupo de servidores que informan de los niveles actuales de carga.
Llamado a la acción
No hay duda de que SDN puede aportar un valor muy importante para las organizaciones de TI. Tampoco hay duda de que en el entorno actual, SDN solo es apropiado para los primeros adoptantes. Dada la falta de madurez de los productos actuales, estándares y API, cualquier organización de TI que está buscando implementar SDN en el corto plazo solo debe hacerlo de una manera un tanto limitada, como la aplicación de SDN para un caso de uso muy específico.
Además, dado el estado embrionario del mercado, no se puede asumir la interoperabilidad de los productos que dicen soportar a las mismas normas relacionadas con SDN, por lo que las organizaciones solo deben trabajar con los proveedores que han demostrado un alto nivel de interoperabilidad.
Sin embargo, dada la combinación de las enormes inversiones que están haciendo los vendedores, junto con la ola actual de adquisiciones, el paisaje SDN probablemente cambie notablemente en los próximos 12 a 18 meses. Las organizaciones de TI pueden esperar una serie en curso de los anuncios, tanto en términos de nuevos productos, protocolos nuevos o mejorados y una prueba más de la interoperabilidad. Las organizaciones de TI también pueden esperar que los bloques básicos de construcción de una SDN, tales como los protocolos y API, se estabilicen.
Suponiendo que todo eso suceda, hay dos eventos que tienen que ocurrir para que SDN pase de ser estrictamente para los primeros usuarios a estar listo para el mercado general. Uno de ellos es la disponibilidad de la funcionalidad que permite a las organizaciones administrar eficazmente esta nueva forma de trabajo en red. El segundo, es la disponibilidad de una amplia gama de aplicaciones que aprovechen el control centralizado inherente en la mayoría de las formas de una SDN, y que responda a la pregunta que todos los altos gerentes de TI le preguntarán: “¿Por qué debemos gastar nuestros recursos en SDN? ¿Cuáles son los beneficios exactos?”
Jim Metzler, Network World
