Resumen

  • RFC 5160 evita encadenar obligaciones remotas: cada proveedor garantiza únicamente el rendimiento al atravesar su dominio y contrata con el vecino inmediato.
  • Cuando cambia la ruta hay que recomponer la prueba con los dominios realmente usados, sus mediciones coetáneas, la capacidad admitida y el camino inverso; la mera continuidad contractual no basta.

La pantalla conserva cinco acuerdos en verde. El tráfico, sin embargo, ya no pasa por los cinco dominios que justificaron el cálculo de ayer. Ésa es la diferencia entre una relación válida y un servicio probado.

Por qué el contrato no debía seguir toda la ruta

RFC 5160 examina primero una alternativa: que un proveedor prometa a su vecino el rendimiento hasta un destino lejano, incluyendo varios dominios que no controla. Una avería convertiría la cadena de transporte en cadena de responsabilidad. La reclamación avanzaría de socio contractual en socio contractual hasta localizar al causante, y el resarcimiento tendría que regresar.

En Internet, esas cadenas son dinámicas y reúnen empresas que quizá no se conocen o compiten. Además, un acuerdo local podría sostener muchas promesas externas. Renegociarlo obligaría a considerar contratos remotos de los que el operador ni siquiera es parte. El documento llama a este bloqueo la trampa de la cadena de proveedores y advierte de una infraestructura “glaciada”.

La solución reduce el alcance: cada proveedor responde sólo del cruce de su propio dominio ante vecinos directos. La autonomía para cambiar y sustituir rutas se preserva. La consecuencia es que ninguna de esas piezas posee por sí sola el resultado completo.

La unión conoce al vecino, no al destino

El marco representa la capacidad interna como una clase QoS local, l-QC, con límites de retardo unidireccional, variación y pérdida. Un proveedor enlaza su clase con la del dominio descendente usando únicamente lo que sabe de ambas. No emplea información de más de un dominio de distancia.

Una Meta-QoS-Class fija las condiciones que dos clases locales deben compartir para enlazarse. Puede identificar aplicaciones, intervalos de rendimiento, restricciones al tráfico y relación entre recursos y carga. El ancho de banda se negocia fuera de la MQC; disponibilidad y tiempo de reparación también pueden requerir cláusulas separadas.

La etiqueta común acredita compatibilidad vecinal. No acredita que el paquete tomara ese enlace, que hubiera capacidad disponible ni que el resto del camino siguiera dentro del mismo plano. Tampoco suma por sí sola retardo, variación y pérdida.

La reconvergencia rompe la herencia de la prueba

El RFC imagina anuncios de ruta a los que cada sistema autónomo añade sus valores de QoS. En su ejemplo, dos dominios aportan 30 y 20 milisegundos, y el proveedor de entrada añade 20 para estimar 70 frente a una petición de 100. Es un ejemplo arquitectónico, no una medición desplegada.

La operación sólo es defendible si los tres valores pertenecen a la ruta efectiva y al mismo intervalo. Cuando BGP selecciona otra secuencia, la nueva ruta no hereda las mediciones de la anterior. Puede haber acuerdos válidos con todos los nuevos vecinos y aun así no existir una suma verificable.

Además, optimizar varios atributos no produce siempre un ganador. Un trayecto puede tener menor retardo y otro menos pérdida. Si todos eligen el que parece mejor, la concentración puede degradarlo: el riesgo QA-rush descrito por el documento. La decisión de encaminamiento debe observarse después de aplicarse.

Los servicios bidireccionales añaden otra ruptura. Los acuerdos son unidireccionales y el retorno puede atravesar proveedores distintos. La reconvergencia de una sola dirección cambia sólo la mitad del servicio, pero invalida cualquier indicador agregado que no conserve ambas rutas.

Un recibo que sobreviva al cambio

El registro operativo debe vincular, con hora y versión, la solicitud del cliente, las rutas real de ida y vuelta, cada acuerdo aplicable, el mapeo l-QC en cada frontera, la carga admitida frente al ancho de banda, las mediciones por dominio, la fórmula de composición, el resultado en los extremos y la atribución de la incidencia.

Así puede preservarse la libertad que busca RFC 5160 sin venderla como certeza inexistente. Si la ruta cambia, el servicio puede continuar en mejor esfuerzo; la conectividad no prueba que sobrevivió la calidad solicitada. Si todos los dominios cumplen sus límites pero la suma excede el umbral, el fallo está en la decisión de ensamblaje, no necesariamente en un operador.

Fuentes