Resumen
- RFC 5151 extiende RSVP-TE para LSP que cruzan sistemas autónomos, áreas IGP u overlays GMPLS.
- El ingress limita opciones y cada frontera aplica política local para señalización contigua, anidada o cosida.
- Una frontera expande saltos laxos y puede seleccionar la salida sin revelar el cálculo interno.
- Por confidencialidad, un PathErr específico puede convertirse en un fallo genérico de todo el dominio.
- La frontera no puede suprimir el error salvo mientras intenta un crankback permitido.
- Si el intento posterior funciona, descarta el PathErr retenido; si no, debe enviarlo hacia el ingress.
- Los saltos internos del RRO pueden agregarse o eliminarse, pero la propia frontera tiene que aparecer.
- El filtrado no impide la señalización y, aun así, puede volver inoperable el diagnóstico de gestión.
- Fast Reroute pierde información para elegir etiquetas y merge point cuando el RRO se reduce.
- Reemplazar el destinatario de Notify habilita acción local, pero exige procesar y reenviar a través de más fronteras.
- El bit 4 exige un LSP contiguo y registra el método; no certifica visibilidad, protección ni entrega.
- La garantía necesita recibos separados de solicitud, decisión, divulgación, reintentos, camino oculto, recuperación y tráfico.
Notify convierte una dirección en una cadena
Los mensajes Notify de GMPLS pueden viajar directamente en vez de hop por hop. Una frontera interesada en observar el evento para activar protección local puede modificar los objetos Notify Request y colocar su propia dirección.
El beneficio es claro: la autoridad que puede conmutar recibe pronto el aviso. El coste también está escrito. Algunas notificaciones destinadas al ingress deben examinarse, procesarse y reenviarse en las fronteras. La RFC señala que esa carga crece linealmente con el número de dominios.
Además, cada administrador puede filtrar o modificar mensajes originados dentro de su dominio para proteger seguridad o confidencialidad. Una confirmación en la primera frontera prueba recepción local, no entrega de contenido equivalente al destinatario original. El seguimiento debe conservar destinatario inicial, cada sustitución, transformación y acuse posterior.
El LSP combina métodos y propietarios
En un LSP contiguo, la sesión RSVP y el LSP ID se mantienen a lo largo del trayecto. El anidamiento introduce H-LSP para transportar el servicio. El stitching concatena segmentos con sesiones separadas y otra sesión e2e. Un mismo camino puede usar métodos distintos por dominio.
El ingress puede restringir la elección, pero cada frontera conserva política propia. Un dominio puede preferir stitching para controlar su reoptimización interna. Si el ingress exige continuidad, el conflicto puede acabar en rechazo; entonces debe buscar otro dominio, relajar la condición o no prestar el servicio.
El estado “establecido” oculta este reparto. Para explicar un incidente hay que saber qué método eligió cada autoridad, qué segmento controla y qué detalle acordó exponer.
La expansión ERO ocurre donde termina la visibilidad
El ERO recibido por una frontera refleja cálculos y políticas anteriores. Un dominio puede rechazar un objeto que identifica nodos internos y devolver Inter-domain explicit route rejected; también puede descartar silenciosamente el Path o usar otro error cuando la seguridad lo requiere.
Un salto laxo IP o AS debe expandirse localmente. Si no queda subobjeto después de la frontera, el destino de la Session RSVP actúa como siguiente salto laxo. Si el ERO apunta a un enlace TE construido por un H-LSP o segmento, no se permite señalización contigua ordinaria: las capacidades, los parámetros y la política determinan anidamiento o stitching.
La ruta resultante registra lo que cada dominio aceptó señalar. No conserva todos los candidatos, restricciones privadas o riesgos compartidos que guiaron la elección.
PathErr conserva el fallo y puede perder su causa
Un error de establecimiento vuelve hacia el ingress y pasa por cada frontera. Cuando la confidencialidad es una exigencia concreta, la frontera puede sustituir “falló este nodo por esta causa” por “falló el dominio”. Los nodos que no son fronteras no deberían modificar el mensaje, y una frontera no debería hacerlo sin esa necesidad.
La regla evita suprimir el fallo, pero reduce su granularidad. El ingress puede automatizar una decisión con el código agregado y seguir sin saber qué recurso o política interna causó el problema. El dato detallado debe conservarse en el dominio con un identificador que permita reconstruirlo bajo un proceso de escalado.
Los valores IANA 103, 104, 28 y 29 estabilizan términos para política y routing. No demuestran que la causa concreta haya cruzado la frontera ni que un operador implemente el comportamiento.
Crankback suspende la conclusión
Al recibir PathErr, una frontera puede retenerlo mientras intenta otra ruta interna o dominio descendente, siempre que la política y los parámetros Path lo permitan. Si el intento posterior funciona, debe descartar el error. Si todos fallan, tiene que transmitirlo hacia arriba y puede agregar detalle de crankback.
Durante ese intervalo, el silencio no es éxito. Es una conclusión pendiente. Incluso cuando el error acaba descartado correctamente, el nuevo LSP necesita un recibo de establecimiento y una observación de datos. El historial de intentos explica por qué cambió la ruta y qué riesgo pudo introducirse.
Confundir “no llegó PathErr” con “nunca hubo fallo” destruye precisamente la evidencia que crankback fue diseñado para manejar.
Un RRO filtrado mantiene el esqueleto administrativo
Una frontera puede reemplazar una secuencia de hops internos por el identificador del dominio o eliminarla y dejar solo nodos fronterizos. No puede ocultar su propia presencia; debe incluirse en el RRO.
Esa representación es conforme. La señalización sigue funcionando. Pero la RFC advierte que la pérdida puede inutilizar el diagnóstico o exigir coordinación entre administradores. El esqueleto muestra dónde cambia la autoridad, no qué ocurre entre dos bordes.
Fast Reroute también consume el RRO para determinar etiquetas y el merge point aguas abajo. Una política suficiente para ocultar topología puede hacer menos eficiente un procedimiento automático sin romper el LSP actual.
Diversidad exige conocer el riesgo protegido
Las reglas interdominio también afectan bypass tunnels, detour LSP y recuperación de segmento. Cuando la ruta de protección contiene saltos laxos, quien los expande necesita el camino protegido entre PLR y MP para evitar los mismos enlaces, nodos o grupos de riesgo.
RRO, DETOUR y route exclusion aportan pruebas; PCE coordinados pueden calcular con más contexto. Si ningún actor ve ambos caminos, la etiqueta “diverso” no basta. El contrato puede preservar confidencialidad mediante comprobaciones dentro del dominio y una afirmación verificable, sin publicar cada hop.
El recibo debe nombrar conjunto de riesgo, versiones de caminos, exclusiones aplicadas y resultado de conmutación. La mera existencia del backup solo demuestra inventario.
El bit contiguo fija la construcción
El ingress usa el bit 4 Contiguous LSP para prohibir nesting y stitching. Los nodos de tránsito no pueden cambiarlo. Una frontera capaz actúa según la petición y, si existe RRO, marca su comportamiento en un subobjeto Attributes.
Quien reconoce el bit pero no puede cumplir devuelve Routing Problem 28. Quien no reconoce TLV o bit lo reenvía sin modificar. La reacción del ingress a ese PathErr queda fuera del RFC.
El mecanismo demuestra que se pidió y declaró una técnica. No obliga a publicar topología interna, mantener causa exacta, construir protección diversa ni verificar tráfico.
La suma de decisiones locales puede degradar el conjunto
El ingress inicia make-before-break en un LSP contiguo. En anidamiento o stitching, un dominio puede reoptimizar su segmento mientras conserva entrada y salida. Esa autonomía limita el alcance de cambio.
Un dominio puede no actuar porque considera aceptable su servicio, mientras la acumulación preocupa al head end. Puede ignorar una petición global. La reoptimización local tampoco puede escoger nuevas fronteras; la de extremo a extremo sí.
La operación necesita registrar quién observó degradación, solicitudes, respuestas, caminos y efecto medido. Ninguna transición de control sustituye el resultado del usuario.
Fuentes
- RFC 5151, HTML
- RFC 5151, texto
- Registro de RFC Editor
- Registro de IETF Datatracker
- Historial de RFC 5151
- Referencias de RFC 5151
- Errata de RFC 5151
- RFC 3209
- RFC 3473
- RFC 4206
- RFC 4420
- RFC 5150
- RFC 4726
- RFC 4208
- RFC 4920
- RFC 4090
- RFC 4873
- RFC 4874
- RFC 4655
- RFC 4216
- RFC 4105
- RFC 2747
- RFC 5152
- Parámetros RSVP de IANA
- 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