Resumen
- RFC 5152 permite calcular un LSP TE entre dominios por secciones cuando el ingress no dispone del trayecto completo.
- Cada frontera expande la parte que le corresponde con información TE y política locales, y puede elegir el punto de salida.
- El ERO admite saltos strict y loose, de modo que control previo y delegación dinámica pueden convivir.
- La siguiente frontera puede descubrirse con IGP, BGP o información de política, o estar configurada de antemano.
- Si el siguiente dominio no satisface las restricciones, devuelve PathErr y una frontera anterior puede intentar otro egress mediante crankback.
- El head end también puede cambiar la secuencia, repetir por sospecha de TED obsoleta o relajar restricciones.
- Un éxito después de relajar la petición no demuestra que la petición anterior pudiera cumplirse.
- El RFC afirma que el cálculo por dominio no garantiza encontrar el trayecto óptimo entre dominios.
- El problema de trapping muestra que una primera ruta válida puede impedir hallar una segunda diversa aunque exista una pareja diversa.
- La ausencia de una segunda ruta depende de la primera elección, el orden, la visibilidad, el algoritmo y las exclusiones.
- La reoptimización local puede mejorar segmentos sin cambiar las fronteras que originaron la composición deficiente.
- La garantía exige recibos separados para cada objetivo, intento, salida, cambio de restricción, reserva, protección y resultado de tráfico.
Cambiar la pregunta puede convertir el fallo en éxito
Cuando una frontera downstream no encuentra una sección que cumpla el conjunto de restricciones, envía PathErr hacia arriba. Si el crankback está autorizado, una frontera previa puede seleccionar otra salida. Si no, detiene la señalización y deja que el error llegue al head end.
La cabeza puede usar otra secuencia de saltos loose. También puede repetir la misma cuando sospecha que una base IGP-TE de un dominio posterior estaba desactualizada. Otra opción es relajar una o más restricciones. Las tres acciones son razonables; sus conclusiones no son intercambiables.
Repetir sin cambios pregunta si el estado se actualizó. Cambiar de egress prueba otra rama. Relajar ancho de banda, prioridad o exclusión pregunta si puede construirse un servicio diferente. Un panel que conserva solo el último estado verde borra cuál de esas preguntas recibió respuesta.
El cálculo viaja dentro del camino que está construyendo
En RFC 5152, los nodos que calculan una sección siempre quedan sobre el LSP resultante. El Path lleva la información conocida hasta la próxima frontera y la finalidad del servicio. Puede incluir fronteras posteriores, pero no necesita transportar un camino end-to-end completo.
Cada ABR o ASBR resuelve su dominio y entrega al siguiente una decisión ya tomada. Si dentro de un AS hay varias áreas o subdominios, el mismo procedimiento puede aplicarse de forma recursiva. La arquitectura conserva autonomía y evita publicar el grafo entero.
Al mismo tiempo, vuelve secuencial la composición. El primer dominio no solo encuentra una ruta local: elige qué problema quedará para los demás. Una salida válida puede consumir la combinación que habría permitido satisfacer el objetivo conjunto.
Los saltos loose son delegaciones verificables
El ERO puede contener todo el camino strict, un tramo strict inicial seguido de fronteras, una lista completa de fronteras o únicamente la frontera actual y el destino. Un operador puede mezclar elementos strict y loose.
El elemento strict se procesa con las reglas normales de RSVP-TE. El loose o un nodo abstracto de varios LSR exige que la frontera lo expanda. Esa mezcla permite control donde hay visibilidad y decisión local donde no la hay.
Sin embargo, el ERO terminado no revela el árbol de búsqueda. Para auditarlo hacen falta la versión de TED, las fronteras consideradas, su orden, los candidatos eliminados y la función objetivo. De otro modo, una ruta aceptada parece la única posible cuando solo fue la primera que sobrevivió.
Una frontera alcanzable no es una promesa TE downstream
Cuando el siguiente hop no figura en la TED, la frontera comprueba que se encuentra fuera del dominio, que se cumplen las condiciones de conmutación de paquetes y control in-band, y que existe reachability IP. Si falla, devuelve Routing Problem.
El auto-discovery puede usar IGP, BGP o información de política. Sin él, la salida debe aparecer como siguiente hop accesible o llegar por otro esquema; en caso contrario, el cálculo fracasa.
Reachability prueba que la solicitud puede alcanzar el próximo responsable. No reserva sus recursos ni compara el efecto de esa salida sobre una pareja. El recibo de descubrimiento debe permanecer separado del recibo de cálculo TE y de cualquier declaración de diversidad.
El primer LSP puede fabricar la imposibilidad del segundo
El ejemplo del RFC escoge primero A-B-C-D. Tras fijarlo, no queda un camino diverso. Sin embargo, si se hubiera tratado el problema como pareja, A-C-D y A-B-D estaban disponibles.
Por eso una primera ruta completamente válida puede ser la causa algorítmica del fallo posterior. No hace falta un enlace roto, una frontera maliciosa ni un error de protocolo. Basta con optimizar el objeto equivocado en el orden equivocado.
“No se encontró backup” debe traducirse como una afirmación condicionada: con esta primera ruta, este conjunto de exclusiones, estas versiones de topología y este método. El salto a “no existe diversidad” exige una búsqueda o una prueba más amplia.
La diversidad se define antes de calcular
Dos trayectos son diversos respecto de algo. Puede ser un enlace, nodo, emplazamiento, SRLG, frontera o clase de riesgo. Sin esa definición, “diverso” es una imagen, no una propiedad comprobable.
Si el producto prometido es una pareja, la función objetivo debe poseer ambas rutas desde el comienzo. Calcular el mejor camino individual y después cualquier camino que no lo toque no equivale a seleccionar la mejor pareja.
RFC 5152 permite elegir la técnica por LSP y menciona PCE cuando se necesitan rutas óptimas o conjuntos diversos. Esa referencia no convierte PCE en oráculo. El resultado sigue dependiendo del grafo recibido, su vigencia, la política, el algoritmo y los riesgos representados.
Reoptimizar puede conservar el mismo conjunto de fronteras
En un LSP contiguo, el head end controla make-before-break y puede recibir aviso de una ruta mejor. En un servicio stitched o nested, cada dominio puede reoptimizar su S-LSP o H-LSP localmente, con frecuencia y criterios propios, de forma transparente a la cabeza.
Un operador que no acepte esa transparencia puede requerir notificación de los eventos mediante RFC 4736. Aun así, mientras las fronteras loose permanezcan, la mejora interna atraviesa la misma secuencia de dominios.
La acción puede reducir métrica o liberar ancho de banda dentro de cada área sin corregir la composición que bloquea una pareja. El informe debe decir qué superficie cambió: tramo interno, frontera, secuencia completa o las dos rutas como conjunto.
La confidencialidad limita el intercambio y la fuerza de la conclusión
El procedimiento no aumenta la topología intercambiada entre ASes. Los dominios conservan sus grafos privados y ejecutan el cálculo donde reside la información. Esa propiedad reduce exposición y facilita cooperación entre autoridades distintas.
Las fronteras deben poder rechazar expansiones ERO no permitidas, aplicar contratos de ancho de banda y prioridad, limitar solicitudes y errores, filtrar salida y autenticar RSVP. La protección FRR de nodos fronterizos puede exigir coordinación adicional de claves.
Un mensaje autenticado demuestra quién solicitó el trabajo permitido. No demuestra que el algoritmo comparó todas las combinaciones, que una relajación conservó el servicio, que una pareja imposible lo es físicamente ni que el tráfico se recuperó.
Fuentes
- RFC 5152, HTML
- RFC 5152, texto
- Registro del RFC Editor
- Registro en IETF Datatracker
- Historial de RFC 5152
- Referencias de RFC 5152
- Erratas de RFC 5152
- RFC 3209
- RFC 3473
- RFC 5151
- RFC 5150
- RFC 4920
- RFC 4655
- RFC 4726
- RFC 4105
- RFC 4216
- RFC 4736
- RFC 2747
- RFC 3097
- RFC 3630
- RFC 4203
- RFC 4205
- RFC 6805
- RFC 8694
- Minimum Initial Specification
- On Reality Layers
- Running-Code Primacy
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance