La Open Networking Foundation (ONF), organización dedicada a acelerar el desarrollo y adopción de Software-Defined Networking (SDN), anunciaba a mediados de octubre haber completado la primera prueba de concepto (PoC) de SDN en el backhaul utilizando equipos de diferentes fabricantes. La idea era demostrar cómo ONF está intentando crear un ambiente abierto para el desarrollo de SDN.
El PoC fue llevado a cabo con la colaboración de Telefónica e IMDEA Networks Institute y con el apoyo de la Universidad Carlos III de Madrid. En la prueba participaron Ceragon Networks, Coriant, Ericsson, Huawei, NEC y SM Optics. TeleSemana.com contactó con todas ellas para saber sus impresiones sobre los resultados de esta prueba. En esta primera entrevista conversamos con Bill Kaufmann, gerente de grupo de marketing y planeamiento SDN de Coriant.
Durante mucho tiempo, los operadores han advertido que las redes de transporte podrían ser un importante obstáculo financiero para sus operaciones si no se construyen de manera diferente. ¿Es SDN la respuesta a ese dilema?
No hay duda de que los requisitos de ancho de banda están continuamente creciendo en las redes de transporte móviles. Si bien es inevitable que las compañías tengan que seguir invirtiendo en sus redes de backhaul, SDN puede ser una herramienta para mejorar la utilización de la red mediante el enrutamiento de manera más eficiente del tráfico a través de la red. El exceso de capacidad se aprovisiona comúnmente en las redes de transporte para proteger contra las posibles interrupciones en la red. Durante el funcionamiento normal, esto da lugar a recursos de red infrautilizados. Además, el uso estable de tráfico por lo general suele ser del 60 a 70 por ciento de la capacidad total del enlace para dar cabida a los patrones de tráfico y sus picos. Esta combinación de criterios de diseño conduce a redes que operan a solo al 30 40 por ciento de su capacidad potencial. Al centralizar las decisiones de enrutamiento y permitiendo un plano de control más dinámico, se pueden aplicar nuevas políticas de optimización de la red como, por ejemplo, volver a enrutar subidas repentinas del tráfico a través de rutas alternativas en función de la congestión, o haciendo uso de rutas de protección cuando estén disponibles para dar cabida a estallidos de tráfico imprevistos.
En términos prácticos, ¿Cómo se implementa SDN en redes con grandes cantidades de equipo legado?
La migración de redes tradicionales a las redes controladas por SDN es quizás el desafío técnico más crítico para los proveedores de servicio. El diseño del controlador SDN puede ayudar a superar este reto. La clave de la eficiencia resultante de SDN se consigue gracias a la posibilidad de programar una red a través de un conjunto de APIs de software abierto. Una vez que las aplicaciones pueden tratar a la red como un recurso programable y hacer las solicitudes de servicio de la red sin ningún conocimiento subyacente de los elementos de la red, es posible un nuevo conjunto de modelos de servicio. Es el trabajo del controlador mantener una topología de red detallada y traducir las solicitudes de servicio API en comandos de configuración de hardware. Mientras la interfaz northbound sea consistente, la interfaz hacia los elementos de red (southbound) puede ser de un protocolo de legado, como por ejemplo SNMP o NETCONF, o un protocolo más reciente, como OpenFlow. Las diferencias se enmascaran de las aplicaciones del operador, que direcciona todos los requisitos de los servicios a través de una API común y, de esta manera, los equipos,de legado y los nuevos elementos de la red se convierten en parte de un recurso programable común.
¿Cuán maduro es SDN para la red de transporte según los resultados del PoC que tuvo lugar en Madrid?
El PoC en Madrid fue un esfuerzo conjunto con Telefónica utilizando routers de Coriant para interconectar radios microondas de varios vendedores. Todos los dispositivos de la red fueron controlados por un controlador de código abierto. El PoC demostró cómo un plano de control SDN podría ser utilizado para adaptar el ancho de banda del enlace configurado en routers según el estado de enlace subyacente del transporte de radio microondas. Mientras que el PoC demostró esta capacidad en un laboratorio, los conceptos fundamentales detrás de esta demostración se conocen bien y no es descabellado pensar que un nivel similar de funcionalidad podría integrarse en los ensayos de la red en producción en los próximos 12 meses.
¿Cuál es el impacto de SDN en el Capex y Opex? ¿Y por qué?
Los beneficios de Capex con SDN se derivan de un uso más eficiente de los recursos de la red. La naturaleza relativamente estática de las redes actuales significa que el exceso de capacidad se debe reservar para adaptarse a los patrones de tráfico, así como a rutas de protección para soportar escenarios de recuperación de desastres. La asignación de ancho de banda más flexible en respuesta a las necesidades del tráfico de aplicaciones permite una mejor utilización de red. Hemos estimado en un estudio de Coriant que estas mejoras en la eficiencia generan ahorros de Capex de hasta un 35 por ciento en la red de transporte.
Gracias a SDN, los beneficios en el Opex son el resultado de un entorno de gestión y control de red simplificado. Con la presentación de una visión simplificada de la red a las herramientas de gestión de nivel superior, el costo y la complejidad de la definición de nuevos servicios y el desarrollo de la conectividad a los nuevos servicios de los operadores se reduce significativamente a medida que nuevos servicios y recursos de la red se pueden implementar de manera más eficiente.
¿Cómo pueden las soluciones SDN de código abierto afectar la relación entre los operadores y los proveedores de equipos?
Un objetivo subyacente de SDN es permitir a la red adaptarse a las aplicaciones, y no obligar a las aplicaciones a adaptarse a la red. Los objetivos de SDN tales como el desarrollo de interfaces programables y plataformas de control escalables permiten a las compañías hacer realidad la visión de una red basada en aplicaciones. A medida que esta visión se cristaliza, los operadores adquieren la habilidad de diseñar aplicaciones que exigen servicios de red bajo demanda a través de APIs estandarizados, esperando que estos servicios serán inicializados en tiempo real y a pedido. La relación entre el operador y el proveedor se convierte en mucho más flexible debido a la aparición de nuevos puntos de integración multi-capa, multi-dominio, y multi vendedor.
¿Su organización apoya SDNv2 para la red de transporte?
Las discusiones sobre SDNv2 han planteado varias preguntas importantes acerca de los supuestos originales alrededor de SDN. SDNv2 fue pensado para ser un nuevo enfoque de SDN más apropiado para las redes de transporte de los operadores en relación con el entorno de red de los centros de datos. Esto afecta al valor de SDN en las redes de transporte de los operadores de varias formas.
Mientras que el SDN basado en OpenFlow ha encontrado un cierto éxito en los centros de datos, donde los conmutadores de la capa dos predominan, no ha tenido el mismo nivel de éxito en las WAN de los operadores donde los servicios IP/MPLS son más comunes.
Los conceptos SDN originales se enfocaban en el reenvío de paquetes y conmutación, pero un gran número de dispositivos de red son compatibles con las funcionalidades de las capas cuatro a la siete y que ahora son un candidato ideal para NFV. Estos también deben integrarse en la arquitectura SDN.
Por último, no es suficiente que la red solamente de apoyo de enrutamiento y conmutación para transportar tráfico. Servicios generadores de ingresos —por ejemplo, redes privadas virtuales, circuitos, etc.— también necesitan ser apoyados en el borde de la red y deben ser parte de cualquier diseño SDN.
Estos conceptos fundamentales están alineados con la opinión que tiene Coriant sobre la evolución de SDN. Mientras OpenFlow ha sido una parte de las PoCs y demostraciones de los proveedores de servicios, las redes de transporte en general requieren un conjunto mucho más amplio de funciones de transporte y de servicios IP/MPLS, incluyendo protocolos OAM, una diversa de gestión del tráfico y una amplia variedad de opciones de resistencia de la red. En lugar de depender de OpenFlow, ha sido un enfoque alternativo común el uso de protocolos de gestión existentes para configurar los enrutadores, pero desarrollados en las APIs de los controladores SDN que permiten a las aplicaciones hacer solicitudes de servicio a la capa de red. Es entonces el papel del controlador traducir estas solicitudes a los elementos de la red. El resultado es el soporte para el conjunto completo de funciones de red necesarios para construir una red de transporte. A medida que las funciones de las capas cuatro a la siete —cortafuegos, NAT, DPI, balanceo de carga, entre otras— se mueven a plataformas virtuales, los APIs abiertos disponibles en el controlador SDN proporcionan un punto de integración para activar la conectividad bajo demanda de estas nuevas instancias de servicio. Por último, la creciente distribución de servicios a lo largo redes metro lleva a una arquitectura inteligente IP/MPLS y dispositivos virtuales en el borde, y una estructura de control integrado para apoyar el nuevo entorno de servicio mucho más dinámico.
