Resumen

  • RFC 9571 lleva la medición de RFC 6374 a LSP MPLS genéricos y multipunto-a-punto mediante Synonymous Flow Labels que separan lotes.
  • Pertenecer al lote no demuestra que el receptor haya drenado reordenamiento, interfaces, núcleos y tuberías antes de leer el contador.
  • El recibo completo conserva alcance, etiqueta, ventana, espera, regla de conciliación, método, configuración y efecto posterior sin convertirlos en un solo dato.

La resta parecía definitiva

El emisor contó 50.000 paquetes con una SFL. El receptor devolvió 49.998. Dos pérdidas parecen una conclusión elemental. Sin embargo, esa aritmética compara estados tomados en instantes distintos: el contador de salida ya cerró mientras el de entrada puede seguir recibiendo incrementos atrasados.

RFC 9571 enumera las causas concretas. ECMP puede reordenar datos respecto del mensaje de medición. Los paquetes pueden terminar en interfaces diferentes. Varios núcleos pueden actualizar estado sin una frontera simultánea. La agregación de enlaces añade otra separación y algunos dispositivos tienen tuberías largas entre procesar y contabilizar.

Por eso la SFL no es un acuse de cierre. Es una marca de pertenencia. El emisor completa el lote y espera hasta tener confianza en que todos sus paquetes pudieron llegar antes de enviar la Query con la misma SFL. El protocolo mejora la pregunta; la operación aún debe justificar cuándo la formula.

RFC 9571 amplía el lugar donde se puede preguntar

Publicado en mayo de 2024 como Proposed Standard del IETF, el documento extiende el modelo de RFC 6374, originalmente centrado en MPLS-TP, a MPLS genérico. Añade el caso multipunto-a-punto y productos más ricos de pérdida y demora.

En un LSP multipunto-a-punto no aparece una dirección fuente ordinaria en el paquete MPLS. Un total en el destino no basta para atribuir el resultado a un ingress. La medición necesita contexto específico de origen. La unidad auditable no es “el LSP” de forma abstracta, sino una población con FEC, origen, destino, SFL, lote, sesión y punto de contador.

Esta precisión también limita la ambición. Una estadística bien atribuida sigue describiendo lo visto entre puntos de observación. No acredita la causa ni el resultado de la aplicación.

Dos calendarios comparten paquetes

Las ventanas de pérdida suelen ser largas; las de demora pueden empezar y terminar dentro de ellas. RFC 9571 permite ejecutarlas a la vez, pero advierte que sólo son relativamente independientes. Si se solapan, quizá haya que acortar la de demora o alargar la de pérdida para conciliar contadores.

Un paquete marcado para demora puede pertenecer además al lote de pérdida A. El equipo puede actualizar dos contadores o resolver la duplicación al informar. Si la marca de demora cruza de A a B, hay que elegir a qué lote se asigna y retrasar la Query hasta que lleguen todos los paquetes pertinentes.

Las reglas simplificadoras convierten esa elección en algo comprobable: quien mide demora debe poder y estar configurado para medir pérdida; la ventana de demora termina dentro de la de pérdida; el segundo lote de demora da tiempo a que se complete el primero. El operador fija el parámetro temporal. La etiqueta no lo adivina.

El método forma parte del resultado

Los time buckets cuentan paquetes según intervalos entre llegadas. Después de crear o cambiar los límites, el receptor responde con cero hasta completar un período entero. Ese cero significa que la configuración todavía no cubre la ventana, no que la variación observada sea nula.

La variante estadística entrega número de paquetes, suma, mínimo, máximo y suma de cuadrados. Otra variante permite calcular una media con suma de marcas de tiempo o con primer y último instante más el número de observaciones. El muestreo selecciona ciertos paquetes y define la ventana entre lecturas. Son productos diferentes.

Guardar sólo “latencia = X” borra la población, el algoritmo y la fase de configuración. Además, la sección 10 dice que la medición combinada de pérdida y demora mediante SFL no está soportada actualmente. Un sistema no puede inferir una capacidad de la cercanía entre campos.

El TLV recompone contexto perdido, no crea verdad

El mensaje de medición sigue la pila MPLS del tráfico y añade GAL; el tipo ACH indica qué se mide. Cierto hardware elimina la pila antes de entregar el paquete al manejador OAM. El TLV SFL vuelve a proporcionar SFL, FEC, grupo de gestión e índice.

El índice es una ayuda pactada en configuración. El TLV debe viajar sobre UDP y también en los demás casos salvo que otro mecanismo, fuera del alcance del RFC, demuestre que no hace falta. En topologías que no sean el retorno in-band punto-a-punto se necesita asimismo información de retorno.

Estas condiciones muestran por qué “recibí una respuesta” no basta. Hace falta probar que la respuesta se asocia al lote correcto y que el contexto no fue sustituido. RFC 9571 reconoce que un atacante capaz de corromper el TLV puede alterar la medición sin que el receptor RFC 6374 lo detecte.

De la métrica al servicio queda otro tramo

Una ventana cerrada puede sostener una afirmación rigurosa sobre pérdida o demora entre dos observadores. No demuestra que el usuario percibiera una interrupción, que no hubiera retransmisión, que el SLA use los mismos límites o que esa ruta represente otra población.

También hay una contrapartida de privacidad: más granularidad de origen y flujo expone más identidad. El RFC menciona cifrar el control, rotar etiquetas y usar varias a la vez. La capacidad de observar debe acompañarse de una decisión sobre quién puede solicitarla y conservarla.

Fuentes

Fuentes