Resumen

  • RFC 5150 forma un LSP de extremo a extremo al coser segmentos GMPLS dedicados llamados S-LSP.
  • Cada S-LSP puede asociarse con un solo LSP e2e y entrega a esa asociación todo su ancho de banda.
  • El origen pide la costura mediante el bit 5 de LSP_ATTRIBUTES y el extremo devuelve el bit listo en el RRO.
  • Una salida capaz asigna una etiqueta no nula; si reconoce pero no soporta la función, usa Routing Problem 30.
  • El intercambio declara preparación del segmento, no la instalación posterior del reenvío completo.
  • La topología TE puede mostrar adyacencia entre extremos aunque no exista forwarding adjacency en datos.
  • Label y Upstream Label del salto e2e sobre el S-LSP carecen de significado y deben ignorarse.
  • La continuidad depende de swaps locales en ambos bordes y, en servicio bidireccional, en ambos sentidos.
  • El RRO e2e registra el extremo del enlace S-LSP, no sus nodos o enlaces internos.
  • Las sesiones del segmento y del LSP e2e se desmontan de forma independiente y pueden dejar estados distintos.
  • La autenticación RSVP protege vecinos de control, no la interfaz de datos descrita ni el tráfico de usuario.
  • Preparación, reserva, swaps, tramo interno, recuperación y entrega requieren comprobantes separados.

Una relación no crea un único ciclo de vida

El S-LSP tiene su propia sesión RSVP. El LSP e2e que lo utiliza tiene otra. La costura vincula sus funciones de reenvío, pero RFC 5150 mantiene independientes sus procedimientos de desmontaje. Una sesión puede usar ADMIN_STATUS para retirarse con gracia mientras la otra elimina estado de inmediato.

Cuando termina el LSP e2e, se liberan su estado RSVP, etiquetas y reserva de ancho de banda sobre el segmento. Si el S-LSP fue provisionado de forma estática, puede permanecer. Si nació dinámicamente por aquella solicitud, la política local puede retirarlo cuando quede sin uso.

La recomendación de esperar unos 30 segundos antes de borrar el segmento dinámico busca evitar una ráfaga simultánea de errores RSVP y mensajes de teardown. Ese temporizador organiza eventos; no demuestra que apareció una ruta alternativa ni que la aplicación se recuperó.

La caída del segmento abre una obligación, no la cierra

Un S-LSP puede ser desmontado por su ingreso, su egreso o un nodo de su trayecto. Esa eliminación debería tratarse como un fallo del LSP e2e asociado y debería activar recuperación o desmontaje. La especificación deja fuera de alcance el procedimiento exacto de señalización para esa respuesta.

Por eso, segment down y recovery triggered no equivalen a service restored. Se necesita conocer qué política eligió la respuesta, qué sesión cambió, si se liberaron los recursos anteriores, dónde apareció el nuevo estado y si un flujo real cruzó el reemplazo.

El problema se agrava porque el RRO del LSP e2e no enumera el interior del S-LSP. Registra el identificador de su enlace TE o su extremo, mientras los nodos y enlaces intermedios deben quedar ocultos para ese salto. El fallo interno puede no aparecer en el documento e2e que parecía completo.

Estar listo no significa estar cosido

Antes de usar un segmento, su head end coloca LSP stitching desired en el bit 5 del TLV Attributes Flags. Un egreso participante devuelve una etiqueta no nula y marca LSP segment stitching ready en el subobjeto Attributes del RRO. El ingreso no puede usar un segmento cuyo bit vuelva desactivado.

La respuesta distingue soporte, rechazo e ignorancia. Si el egreso entiende la solicitud pero no puede cumplirla, envía PathErr con Routing Problem y valor 30 Stitching unsupported. Si conoce el objeto pero no reconoce el TLV o el bit, puede ignorarlo.

La marca lista certifica esa preparación protocolaria. No inspecciona los swaps que se programarán cuando llegue la solicitud e2e. Tampoco consulta el interior del segmento ni espera un paquete de usuario. Convertirla en una luz de servicio disponible cambia el objeto de la afirmación.

Las etiquetas sin significado mantienen la forma del protocolo

La solicitud e2e debe coincidir en tipo de conmutación y considerar ERO, ancho de banda y política TE local. Sobre el salto S-LSP, un LSP bidireccional lleva Upstream Label en Path y recibe Label en Resv. Pero no hay forwarding adjacency entre los extremos del segmento.

La consecuencia es excepcional y explícita: cualquier valor puede utilizarse, las etiquetas no tienen significado de reenvío entre esos extremos y los destinatarios no deben procesarlas. La presencia del objeto conserva el procedimiento RSVP-TE; no prueba una entrada de forwarding asociada a ese valor.

El dato útil vive en otra parte. El ingreso debe conmutar el tráfico e2e entrante hacia el S-LSP. El egreso debe sacar el tráfico del segmento hacia la porción e2e siguiente. En bidireccional, hacen falta acciones inversas. Un Resv exitoso sin lectura de ambos bordes deja abierta una falla unidireccional.

Una adyacencia de base de datos no es una adyacencia física

El segmento puede anunciarse como enlace TE y participar en el cálculo de rutas. Sus extremos parecen adyacentes en esa topología aunque el camino cruce varios nodos. La publicidad ni siquiera es requisito para coser; si se usa, añade tamaño y complejidad a la base de estado de enlace.

Una vez asignado a un LSP e2e, el ancho no reservado del S-LSP debería pasar a cero para impedir una segunda admisión. Varios segmentos pueden agruparse en un enlace TE, pero cada componente mantiene la exclusividad de una asociación.

Esto protege la contabilidad de admisión. No mide rendimiento, diversidad, congestión ni entrega. Tampoco convierte el S-LSP en jerarquía: un H-LSP puede transportar varios LSP de capa superior con etiquetas significativas; el S-LSP sirve a uno en la misma capa.

El canal de control tiene otra identidad

Los mensajes RSVP pueden viajar por una interfaz distinta de la fibra o enlace que describen. Las asociaciones de seguridad deben unirse a los vecinos comunicantes mediante sus direcciones IP, no a una interfaz de datos que puede variar con el routing. La autenticación protege el intercambio de control bajo esa relación.

No protege por extensión los swaps ni el payload. El bit 5 registrado por IANA y el subcódigo 30 permiten interoperar en la conversación. La errata verificada corrige una frase editorial sobre objeto, TLV y bit. Nada de ello prueba una implementación concreta o un servicio vivo.

La evidencia completa conserva ambos relojes: creación del segmento, declaración lista, unión e2e, lecturas de los bordes, estado interno, tráfico, inicio de teardown, política de recuperación y resultado final. Si se pierde esa secuencia, un segmento persistente puede confundirse con un servicio que nunca sobrevivió.

Fuentes

  1. RFC 5150, HTML
  2. RFC 5150, texto
  3. Registro de RFC Editor
  4. Registro de IETF Datatracker
  5. Historia de RFC 5150
  6. Referencias de RFC 5150
  7. Erratas de RFC 5150
  8. RFC 4206
  9. RFC 3209
  10. RFC 3473
  11. RFC 4420
  12. RFC 3477
  13. RFC 4201
  14. RFC 4203
  15. RFC 4205
  16. RFC 2747
  17. RFC 3032
  18. RFC 5151
  19. Parámetros RSVP de IANA
  20. Minimum Initial Specification
  21. On Reality Layers
  22. Running-Code Primacy