Llegamos a ustedes gracias a:



Reportajes y análisis

OpenFlow no es el único camino a la revolución de la red

[12/12/2011] API y protocolos de mensajería, incluyendo algunas que son las normas, pueden permitir que los usuarios construyan redes definidas por software. La cuestión clave, sin embargo, es que no todo el mundo implementa las mismas, o las aplica de la misma manera. ¿OpenFlow nos llevará a todos por el mismo camino hacia el nirvana SDN?
OpenFlow es una API de código abierto definida para permitir que switches y routers de múltiples proveedores puedan ser programables mediante el software en un elemento de control central . Está diseñada para gestionar y dirigir el tráfico entre los routers y switches de diferentes proveedores mediante la separación de la programación de routers y switches del hardware subyacente, con el fin de garantizar la coherencia en la gestión del flujo y la ingeniería.
Los defensores del OpenFlow señalan que la API, el protocolo, y el SDN, en general, abrirán las redes a una mayor innovación, proporcionando un nivel de abstracción, o virtualización, entre el control de la red y la infraestructura física.
"La mayoría de las aplicaciones que vemos que son muy útiles en todo SDN (como los centros de datos virtuales, multiusuario), son cosas cuya construcción no puedo imaginar sin OpenFlow", señala Kyle Forster, co-fundador de Big Switch Networks, un fabricante de controladores OpenFlow.
"Todos reconocemos que la gestión de redes que abarcan múltiples centros de datos, que pueden o no ser propiedad de la empresa, se está convirtiendo en algo demasiado complejo, independientemente de todos los otros avances que se hicieron", señala Derek Silva, analista de Grupo Info-Tech Research en London, Ontario. "La gestión de la red debe ser más fácil, y creo que la visión desarrollada por el movimiento SDN y la evangelizadora de OpenFlow, Open Networking Foundation, es probablemente la mejor manera de hacer que suceda".
Pero hay otras consideraciones en juego, como dónde ubicar físicamente los controladores de flujo, y estas consideraciones han hecho que algunos vean más allá de OpenFlow.
"La discusión OpenFlow asume que el controlador está en un dispositivo independiente", afirma Peter Christy, co-fundador del Internet Research Group, una consultora de Los Altos, California. "Una configuración SDN razonable es distribuir el software del controlador en cada uno de los switches. En caso de que el controlador de SDN se distribuya a cada uno de los switches, no tendría sentido implementar un protocolo de comunicación formal dentro de la caja".
Christy señala que un SDN que distribuye el controlador a los switches podría mejorar el rendimiento de la comunicación entre el interruptor y el controlador, y mejorar el funcionamiento de la SDN. Él dice que la arquitectura QFabric de Juniper es un ejemplo de SDN con un plano de control distribuido.
Arista Networks señala que sus clientes pueden implementar SDN utilizando los controladores o el control distribuido de la red. La compañía agrega que hay pros y contras en ambos enfoques, pero que ambos están obligados a implementar un amplio SDN.
Arista define cuatro "pilares" de la red de nubes definidas por software: la topología de la nube, el control distribuido, la virtualización y administración/automatización de redes. OpenFlow es una API entre varias que se pueden utilizar en el pilar de la administración/automatización de la SDN, si es basada en el controlador, de acuerdo con Arista. Otros son los CLI existentes, SNMP, XMPP, Netconf, OpenStack, y las API de software de virtualización vSphere de VMware, añade Arista.
Hay casos de uso para cada uno, según Jayshree Ullal, CEO de Arista. Para OpenFlow, ella ve el caso de uso como la redirección de paquetes dinámicos para la agregación de la red, intercepción legal/CALEA, e implementaciones segmentadas de redes de topología agnóstica.
Si se traduce en una amplia adopción aún está por verse. "A mayores implementaciones, más fuerte será su plazo de aplicación", añade.
La red definida por software tiene la oportunidad de estar en todas partes, agrega. Pero si OpenFlow será la única API, u OpenStack, o Netconf o XMPP, o VMware u otro hipervisor es difícil de predecir. Ullal que dice que todas prometen virtualización de red de topología agnóstica optimizada para el uso y la movilidad de la carga de trabajo.
En el VMworld, Arista demostró cómo construir nubes con el aprovisionamiento de un solo toque de máquinas virtuales y hasta 50 mil nodos de la red utilizando las herramientas en su software de sistema operativo EOS y la interfase CloudVision. XMPP es la API en CloudVision.
"No hay razón para que mañana no pueda ser una API OpenFlow o u OpenStack", señala Ullal. "Pero aquí tenemos una interfase bien definida. Hoy hacemos Netconf y XMPP porque eran fáciles de implementar, con especificaciones bien definidas y había un cierto interés de los clientes por ellas".
Ullal agrega que EOS de Arista soportará un conjunto de API para los diferentes "casos de uso" que los clientes exigen. En este momento, Arista está detectando la demanda inicial de OpenFlow entre instituciones de investigación, y en los centros de datos para reorientar los flujos a los toques y agregadores de golpes.
"Una nueva tecnología no excluye el enfoque pragmático de también mejorar las tecnologías existentes", señala con respecto a la SDN. "En los entornos operacionales donde prevalece la herencia, la mejora de las tecnologías existentes es aún más importante que la innovación".
En lugar de que OpenFlow dirija los SDN, los SDN impulsarán OpenFlow, cree Ullal.
"La combinación de OpenFlow con API SDN es vital para que OpenFlow sea implementado ampliamente", añade ella.
Forster de Big Switch agrega que las SDN no tendrían el bombo o el impulso en el mercado del que disfrutan hoy en día si no fuera por OpenFlow. Y con las miles de API que cada uno ha adaptado a un determinado "caso de uso", lo que significa que tiene que haber menos para programar.
Con respecto al XMPP, Forster añade que es "inteligente", pero no oculta la complejidad de los scripts de automatización escritos en ella.
"XMPP no le permite escribir un script en Perl que se pueda revertir (comandos no deseados)", agrega. "Las secuencias de comandos Perl que escribe en la parte superior para la automatización todavía son bastante complicados".
Pero lo que no es discutible es la visibilidad que OpenFlow le está trayendo a las SDN, y viceversa.
"OpenFlow es crítico, y no porque sea la respuesta", añade André Kindness, analista de Forrester Research. "Es una de las respuestas. Pero es la única que más se usa porque hay muchas comunidades que trabajan en ella. Hay una enorme cantidad de poder mental trabajando en ello. Está generando muchas discusiones y nuevas formas de pensamientos. Tenemos una buena carrera de caballos pasando por aquí".
Jim Duffy, Network World (EE.UU.)