Aplicaciones Northbound OpenFlow: ¡Cuidate Cisco!

Noticias

Aplicaciones Northbound OpenFlow: ¡Cuidate Cisco!

Brad Casemore, Colaborador

En sus inicios, la Open Networking Foundation puso un fuerte énfasis en el establecimiento de OpenFlow como un medio de separar físicamente el plano de control y el plano de datos en la red y facilitar un medio de comunicación entre los dos. La ONF vio la funcionalidad de los OpenFlow en el enfoque “Southbound” como la base esencial sobre la cual podría edificarse un software definido en la red.

Ahora que la piedra angular del OpenFlow está en su lugar (aunque el protocolo continuará evolucionando y madurando), la ONF parece dispuesta a seguir adelante con otros aspectos de SDN, incluyendo aplicaciones Northbound de OpenFlow. La semana pasada se anunciaron cuatro nuevas iniciativas, una de las cuales se enfocará en la Northbound Application Interface (API), o NB-API.

Como lo hace notar el comunicado de prensa de la ONF, los desarrolladores de aplicaciones de control de la red prefieren codificar “para el Northbound de un controlador OpenFlow.” Para que esto ocurra, la iniciativa catalogará y caracterizará las APIs existentes como un primer paso hacia la evaluación de las necesidades del mercado.

La iniciativa NB-API de la ONF se presagiaba en una “carta de enlace“ enviada en junio por Dan Pitt, Director Ejecutivo de la ONF al Internet Engineering Task Force (IETF). Escribió que la “ONF aún no tenía estandarizada, o determinado la naturaleza de la interface Nortbound del controlador,” pero que estaba interesada en “el uso potencial de casos SDN desarrollados por el IETF con el fin de demostrar como estos pueden ser expresados con las construcciones de la ONF, posiblemente como funciones directas del controlador.”

Porqué las aplicaciones Northbound OpenFlow son una amenaza para Cisco

Obviamente, la ONF está estudiando el tema NB-API dentro del contexto de OpenFlow y controladores OpenFlow. Esto es diferente de como Cisco Systems ve el mundo con su Cisco ONE y el OnePK API. Cisco, por supuesto, quiere que su hardware de conmutación patentado tenga un papel destacado en Northbound para el suministro de datos analíticos y de inteligencia para los programadores.

Cisco reconoce a regañadientes a OpenFlow pero, en el mundo ideal del gigante de las redes, los switches OpenFlow no proliferan, los controladores basados en el servidor podrían no desacoplar el plano de control del plano de datos y el Application-Specific Integrated Circuit, o ASIC, basado en que el hardware de red seguiría siendo un terreno distinto de diferenciación competitiva sustentable, márgenes robustos y posición privilegiada en el mundo de la computación en la nube.

La ONF se establece en un resultado diametralmente opuesto. Cualquiera que haya visto, escuchado o leído los escritos de las presentaciones de la ONF sabe que la ONF prevé que “la creación de redes viene a ser una parte de la informática,” sirviendo efectivamente como un elemento respetuoso de la infraestructura virtualizada. La ONF dice que su misión es poner el poder en las manos de los clientes en lugar de en los vendedores, y hacer que la red sea más sensible a las necesidades de quienes la operan y usarla en lugar de los imperativos de negocio a corto plazo de quienes venden el engranaje. La ONF, sus tecnologías y su papel como catalizador del movimiento de SDN probablemente representan una mayor amenaza para los intereses comerciales a largo plazo de Cisco que lo que hacen los competidores convencionales de Cisco en “redes heredadas.”

 

La ONF, sus tecnologías y su papel como catalizador del movimiento de SDN probablemente representan una mayor amenaza para los intereses comerciales a largo plazo de Cisco

 

 

Cisco, como ya lo señalé, nunca antes había encontrado este tipo de desafío de un cliente-líder por el lado de la demanda. La ONF es cuidadosamente dirigida y controlada por organizaciones de clientes que se niegan a permitir que los proveedores formen parte de su junta directiva y toman con cautela las agendas conducidas por ellos. No hay razón para pensar que va a ceder el control de la agenda SDN a la comunidad de proveedores.

También la ONF no muestra prisa para estandarizar sobre una API Northbound. Siguiendo las convenciones del mundo de desarrollo del software en lugar de los rituales de incubación de protocolo de la IETF, la ONF se conforma con permitir que el mercado decida sobre el asunto, justo como especuló Roy Chua el mes pasado en Central SDN.

Los controladores que se adopten y que desarrollen prósperos ecosistemas tienden a definir la primacía de las APIs específicas de Northbound.


Unirse a la conversación Comenta

Compartir
Comentas

    Resultados

    Contribuye a la conversacion

    Todos los campos son obligatorios. Los comentarios aparecerán en la parte inferior del artículo