Resumen

  • RFC 3429 asignó el valor reservado 14 de MPLS a OAM Alert Label para reconocer paquetes OAM del plano de usuario; no definió con ello todas las funciones de Y.1711.
  • Con PHP, el LSR penúltimo podía retirar la etiqueta superior y conservar la etiqueta OAM y su carga útil hasta un egreso MPLS compatible. El caso de un nodo que no entiende etiquetas era distinto y quedó fuera del ámbito de Y.1711 entonces.
  • El TTSI que viajaba dentro del paquete ayudaba a identificar el LSR de ingreso. No demostraba que el LSP estuviera sano, que llegara el tráfico del cliente ni que se atendiera una alarma.

Penultimate-hop popping (PHP) parece una optimización local: el LSR penúltimo retira la etiqueta superior y el de salida evita una búsqueda adicional. Sin embargo, el comportamiento cambia según lo que queda debajo. En paquetes de usuario, el egreso puede continuar con el protocolo de red que corresponda. Un paquete de operación y mantenimiento necesita conservar una señal que impida confundirlo con ese tráfico normal.

El RFC 3429 asignó para ello el valor 14, uno de los valores reservados por el formato de pila de etiquetas de RFC 3032. La denominación, OAM Alert Label, identifica paquetes MPLS OAM del plano de usuario. La reserva no constituye por sí sola un sistema de supervisión, no describe todos los campos de su carga útil y no obliga a cualquier router a procesarla.

Una etiqueta de control y otra que sí aparece en el paquete

Conviene no confundir el valor 14 con implicit-null, el valor 3. Este último se anuncia en el plano de control para pedir PHP, pero nunca aparece en la encapsulación: indica al penúltimo LSR que retire la etiqueta superior en lugar de sustituirla. En el escenario que describe RFC 3429, la etiqueta OAM sí permanece en el paquete. El penúltimo LSR elimina la etiqueta superior ordinaria y reenvía intactas la etiqueta OAM y la carga útil.

El diseño reparte el trabajo entre documentos. La recomendación Y.1711 de la UIT-T describe funciones OAM y el contenido de sus mensajes. RFC 3031 establece la arquitectura MPLS y el tratamiento de PHP. RFC 3429 asigna el identificador que permite clasificar el paquete en la capa MPLS. Una etiqueta registrada puede señalar qué debe mirar el receptor; no demuestra que ese receptor tenga el mecanismo para mirarla.

El límite está en el equipo de salida

RFC 3429 describe dos situaciones en que se solicita PHP. En la primera, el egreso sigue siendo un LSR MPLS, con planos de control y datos, pero pide retirar la etiqueta porque no puede realizar dos búsquedas a velocidad de línea. El LSR penúltimo quita la etiqueta superior y conserva la etiqueta OAM. Si el egreso también implementa MPLS OAM, reconoce el marcador que ahora queda arriba de la pila y procesa el paquete.

El TTSI (Trail Termination Source Identifier) dentro de la carga útil identifica el LSR de ingreso que originó el mensaje, según el mecanismo descrito. El dato sobrevive a la retirada de la etiqueta superior porque no dependía de ella. Pero su alcance termina ahí: identificar el origen de una prueba no demuestra que todos los saltos observaran el mismo estado, que el trayecto inverso funcione o que una aplicación remota recibiera datos.

La segunda situación es distinta. El nodo final no tiene capacidad para buscar o procesar etiquetas MPLS y no reconoce paquetes etiquetados. También puede pedir PHP, pero no se convierte por ello en terminación de OAM. RFC 3429 dice expresamente que las funciones Y.1711 de aquel momento solo se podían aplicar a la primera situación. La segunda quedaba para estudio futuro; también se reservaba para más adelante el caso carrier supporting carrier.

El RFC 3031 ayuda a entender por qué el silencio no debe “repararse” por intuición. Un LSR que recibe una etiqueta no válida normalmente debe descartar el paquete, salvo que exista una forma segura de saber que reenviarlo sin etiqueta no causará daño. Quitar cualquier etiqueta desconocida y tratar lo restante como IP puede cambiar su significado o exponer tráfico. Cuando un egreso no procesa OAM, RFC 3429 prevé el descarte; ese resultado es una falta de observación, no un certificado de salud ni una explicación completa de la causa.

El registro preserva el nombre, no la capacidad

El registro IANA de valores de etiqueta MPLS mantiene el valor 14 como OAM Alert Label y cita RFC 3429. La estabilidad del registro permite que especificaciones distintas compartan un significado. No revela qué equipos actuales implementan Y.1711, en qué LSP se usa PHP o qué contador expone un fabricante.

Publicado como RFC Informational en noviembre de 2002, el documento no es un informe de adopción. Su aportación histórica es la frontera entre coordinación y ejecución: una función definida por la UIT-T, una etiqueta reservada en el espacio MPLS del IETF y una condición explícita de capacidad en el extremo. La etiqueta hace posible una interpretación común; no entrega por sí misma un servicio de supervisión.

Para evaluar una ruta concreta hacen falta recibos separados: la solicitud de implicit-null, la operación realizada por el LSR penúltimo, la pila que recibe el egreso, el soporte de MPLS OAM, la lectura del TTSI y el resultado de la función correspondiente. Después se necesita evidencia del tráfico del servicio. “Etiqueta 14 registrada”, “OAM habilitado” y “LSP disponible” pertenecen a capas distintas; ninguna frase sustituye a las demás ni prueba la entrega al cliente.

Fuentes