Resumen

  • RFC 6426 amplía LSP ping para la verificación de conectividad MPLS-TP bajo demanda y el trazado de rutas. El Requester elige la sonda, la encapsulación, el TTL, el modo de respuesta y la solicitud opcional de ruta inversa; el Responder solo aporta evidencia que puede validar en su posición.
  • Una respuesta puede identificar un punto intermedio seleccionado por la expiración del TTL, no el extremo. Recibirla no autoriza por sí solo una conclusión de servicio bidireccional.
  • El Requester debe validar interfaz, pila de etiquetas, FEC aplicable, identidad y modo de respuesta; si está presente un TLV Reverse-path Target FEC Stack, también debe validarlo. Si la validación falla, debe descartar la respuesta y conviene informar del fallo.

Qué significa el paquete

La operación encapsulada en IP utiliza una dirección de 127/8 y UDP dentro de la pila MPLS. La operación no IP usa el Associated Channel Header (ACH), sin depender del enrutamiento IP. En operación ACH no IP con modo de respuesta 4, la respuesta debe viajar por el LSP inverso mediante ACH, sin IP ni UDP. Un nodo sin ese camino de retorno debería descartar la solicitud; el silencio no es evidencia positiva de un retorno sano.

La autoridad del Requester y la del Responder son distintas. El Requester selecciona un FEC de LSP estático o de pseudowire (PW), la secuencia de TTL, el modo de respuesta y el bit R, que solicita información del FEC inverso. El Responder solo puede comunicar lo que es válido en el punto donde recibe la solicitud. No debe activar R en una respuesta Echo. Cuando R estaba activado en la solicitud, el Responder debería incluir un TLV Reverse-path Target FEC Stack. Los LSP co-rutados y los LSP bidireccionales asociados pueden usar un FEC inverso diferente. Una respuesta sin evidencia R/TLV no demuestra ningún FEC inverso.

En el trazado, la expiración provocada por TTL dirige las solicitudes a puntos concretos del LSP. DSMAP y DDMAP ayudan a relacionar destinos y respuestas; no convierten una respuesta intermedia en evidencia del extremo. Los TLV Source Identifier y Destination Identifier hacen explícitos origen, destino y contexto administrativo. Entre límites administrativos se recomiendan los TLV Source Identifier para filtrar fuentes inesperadas o desconocidas.

El GAL transporta OAM y no es la etiqueta FEC objetivo que se verifica. No debe recibir un TLV FEC Nil ni aparecer en DSMAP o DDMAP, aunque los TLV de interfaz y pila de etiquetas sí lo incluyan. Confundir GAL con el FEC objetivo produce una validación falsa.

Fixture concreto de verificación

El operador prueba un FEC de LSP provisionado estáticamente 10.0.0.1/32 o un FEC de PW, envía una sonda MPLS con TTL 2, registra el modo de respuesta 4 y solicita información inversa activando R. La captura debe correlacionar Source Identifier, Destination Identifier, identidad del respondedor, interfaz de entrada, pila completa de etiquetas, FEC objetivo, TLV Reverse-path Target FEC Stack cuando esté presente, encapsulación ACH o 127/8-más-UDP y el punto donde expiró el TTL. Solo se acepta la respuesta si la interfaz y la pila local coinciden con el FEC esperado y cualquier pila inversa presente valida contra el inventario del Requester. R debe estar ausente en la respuesta. Fuente inesperada, etiquetas discordantes, FEC inverso inválido o interfaz no válida significan: descartar, registrar e informar del fallo de validación.

Hay que repetir distintos TTL para separar el extremo previsto de los respondedores intermedios. En P2MP con direccionamiento IP es obligatorio admitir los procedimientos de RFC 6425; sin direccionamiento IP se aplican los procedimientos no IP de RFC 6426. Se debe identificar la rama y no asumir que una respuesta representa todas las hojas. Un nodo que no admita el modo de respuesta solicitado, o no pueda usarlo, debe descartar la solicitud. No debe usarse ACH para CV bajo demanda con ECMP: la cabecera ACH puede cambiar el hash y la sonda puede seguir una ruta distinta de la del tráfico de datos.

RFC 4379 aporta los procedimientos base de LSP ping; RFC 5586 define el transporte G-ACh; RFC 5860 trata los requisitos de OAM MPLS-TP; RFC 5884 aporta el contexto BFD/MPLS. RFC 5920 cubre el marco de seguridad MPLS, RFC 5921 la arquitectura del perfil de transporte, RFC 6370 los identificadores y RFC 6371 el marco OAM y su límite de autoridad.

El mecanismo permite a los operadores interrogar rutas estáticas y no IP, localizar puntos de tránsito y separar evidencia hacia delante de evidencia de retorno. Es bajo demanda, no una garantía continua. El paquete de hechos no aporta información sobre adopción de proveedores, prevalencia del despliegue, latencia o pérdida de sondas, historial de incidentes, valor comercial ni resultados de clientes; todo ello sigue siendo desconocido. Aquí no se establece ninguna alegación.

Fuentes