¿Será MPLS más eficiente si se implementa utilizando redes definidas por software?

Por mucho que respeto a Tony, hay un caso de uso donde la configuración tradicional de RSVP o LDP simplemente falla.

Vincularé esto a SDN al final, tengan paciencia conmigo.

Pensemos en cómo funciona la red telefónica (pre-VoIP). Levantas el teléfono. Obtiene tono de marcado, lo que significa que tiene una conexión activa a la red. Ingresa el número de teléfono (para ser precisos, la dirección E.164 de la estación de terminación), y hay una pausa …

En esta pausa, la red SS7 está descubriendo cómo tallar una ruta dedicada de 56 kbps fuera de la red, conectándolo con la estación de terminación. Esto se hace COMPLETAMENTE fuera de banda en relación con la red que eventualmente llevará la conversación.

Si no hay una ruta, se ocupa rápidamente, lo que indica que la llamada no se puede completar en este momento (o si algo está realmente roto, se obtiene una grabación de voz). De lo contrario, la ruta está configurada y su llamada se enruta. Una vez que el camino está abierto, la terminal receptora suena o le da una señal de ocupado diciendo que no está disponible (o lo deja en el correo de voz, o lo reenvía, o cualquier otra cantidad de cosas, mencionado porque conozco a alguien, en algún lugar se quejará si Yo no).

Por lo tanto, la señalización fuera de banda implica buscar en varias bases de datos, calcular el enrutamiento (basado en métricas de menor costo, donde “costo” es $$$ no “distancia”), y un montón de otras operaciones realizadas en paralelo, y es horriblemente eficiente teniendo en cuenta todo el trabajo que se debe hacer en un período de tiempo muy corto.

Ahora, digamos que quiero configurar una ruta similar usando RSVP. Daré una explicación muy simplificada de cómo funciona.

Para empezar. RSVP ni siquiera mira el enrutamiento, solo cuenta con que “funcione”. El remitente envía un paquete de solicitud al receptor, y el receptor inicia el proceso de RSVP. En ese enrutador a lo largo de la ruta de regreso al receptor se hacen preguntas: ¿es POSIBLE asignar el ancho de banda deseado (o QoS) en la ruta y está PERMITIDO? Si la respuesta a ambas es “sí”, se envía un mensaje de confirmación diciendo “se ve bien hasta aquí”, esa parte se “bloquea”. Ahora “poseo” capacidad en ese camino.

Repetimos hasta llegar al destino.

Ah, y este es un gran “OH”, ¿qué sucede si en algún momento NO PUEDO tener la capacidad? MMMMmmm’k. Reenrutamos desde allí en el siguiente camino más preferido, y continuamos. No es problema. ¿Excepto que si eso también tiene capacidad limitada?

Es completamente posible que (a) no se establezca una ruta completa y (b) que tome un tiempo darse cuenta de eso. Lo cual no es completamente diferente a conseguir una red “ocupada rápidamente”, aparte del proceso está completamente serializado, en lugar de ejecutarse en paralelo.

Y existe este otro inconveniente ENORME: ¿qué sucede si quiero reservar esta capacidad para un futuro? ¿Como decir que quiero reservar 600 Mbps para alimentar el flujo de video HD producido desde un estadio al enlace ascendente de la red (de televisión) a las 2 p.m.del domingo dentro de dos semanas?

No hay forma de hacerlo en una red IP, hoy, en absoluto.

Entonces, volviendo a los SDN …

En Enron Broadband, nosotros (yo y Larry Ciscon, principalmente) ideamos una forma de hacer todo esto en paralelo. Mantuvo una base de datos de compromisos de capacidad (y el momento en que se comprometieron y la duración) y, por lo tanto, supo en cualquier momento en cada ruta e interfaz de la red cuánta capacidad dedicada se requería y cuánto se requeriría en cualquier momento. Punto en el futuro.

Por lo tanto, una solicitud de “puedo tener capacidad X de aquí para allá” fue manejada por alguna búsqueda de DB, un pequeño ejercicio de teoría de gráficos, y se resolvió al instante.

Y ahí es donde se descompuso. En 1999, no había un “SDN”: teníamos que escribir código que actualizara manualmente los enrutadores centrales de Cisco utilizando la CLI, esperar scripts y un montón de kludgery.

Hoy, podría hacer lo mismo con un SDN y eliminarlo en un período muy corto de tiempo.

Si tienes una hora para matar y quieres ver una presentación que hice sobre esto en octubre de 1999, aquí tienes.

iBand3 1999 Keynote de cierre

No, SDN no mejorará su eficiencia. No se pueden obtener ganancias haciendo la configuración de LSP a través del controlador que a través de RSVP o LDP. Y, por supuesto, el controlador lo hace más complicado.

Donde el controlador puede contribuir es si la red está haciendo ingeniería de tráfico. Allí, el controlador puede hacer una optimización global de una manera que simplemente no es visible para los enrutadores individuales. Tenga en cuenta que esto no tiene por qué ser un controlador SDN, ya lo ha hecho antes un software de ingeniería de tráfico centralizado.