Resumen

  • Un TID reúne reglas de clasificación y cada FID identifica un flujo dentro de ese conjunto, siempre con alcance local al módem. Ni el número ni una coincidencia del encabezado prueban el tratamiento posterior.
  • El router valida y reemplaza el conjunto completo, resuelve reglas explícitas, comodines y la precedencia Ethernet sobre Diffserv. Sólo una extensión negociada da uso al FID, y el plano de datos exige pruebas adicionales.

Un contador de cero provocó una conclusión equivocada. La consola decía que la lista de DSCP tenía cero elementos y el informe afirmó que aquel flujo no aceptaba tráfico. En RFC 9892, ese cero podía significar exactamente lo contrario: un comodín para todo DSCP que no tuviera una asignación explícita.

La confusión no era aritmética. Era una pérdida de contexto.

El RFC define un Traffic Classification Data Item para DLEP. El módem agrupa una combinación de identificadores del plano de datos bajo un TID y asigna un FID a cada flujo descrito en un Sub-Data Item. Los primeros formatos reconocen valores Diffserv y Ethernet. La estructura es extensible y puede servir a mecanismos distintos.

Por diseño, el formato identifica y no ejecuta. La especificación dice que el uso real es dependiente de la extensión. Saber qué paquete pertenece a un FID no establece qué destino, cola, pausa, crédito o métrica consumirá esa clasificación.

Un cero necesita el nombre de su campo

RFC 9892 admite cero Sub-Data Items en un conjunto. En ese nivel, cero significa que ningún tráfico debe coincidir con el TID. Dentro de un Sub-Data Item Diffserv, en cambio, cero DSCP crea la regla genérica para los valores no asignados de manera explícita. En Ethernet ocurre un patrón semejante con los PCP, mientras que un VID cero ordena ignorar el VLAN Identifier.

Estos estados no pueden guardarse como un único default. Uno niega todas las coincidencias. Otro captura el resto. El tercero elimina una dimensión de la comparación. La cifra carece de autoridad sin el tipo, la posición estructural y las reglas de la extensión.

Lo mismo vale para TID y FID. Sus valores pertenecen al espacio local del módem. El TID 4 de un equipo y el TID 4 de otro no forman una identidad común. Una base de datos que usa la pareja numérica como clave global mezclará sesiones, configuraciones y posiblemente propietarios diferentes.

RFC 8175 sitúa DLEP entre un router y su módem sobre un enlace local. Cada conexión mantiene su sesión y negocia sus extensiones. La señalización por el medio adjunto queda fuera del protocolo base. La evidencia mínima debe incluir módem, router, sesión, mensaje, instante y extensión; el número solo no basta.

El registro IANA de parámetros DLEP asigna el tipo 29 a Traffic Classification y registra los subtipos Diffserv y Ethernet. Esa coordinación permite que implementaciones distintas reconozcan el formato. No demuestra que una sesión lo haya negociado ni que el router haya instalado algo.

El conjunto nuevo sustituye al anterior

El módem puede enviar clasificaciones durante la inicialización o actualizarlas en una Session Update. Si el router encuentra un TID existente, debe sustituir la información correspondiente y actualizar el estado asociado según lo que requiera el uso.

La unidad de cambio es el conjunto. No es correcto sumar cada Sub-Data Item a una colección histórica y tratar todos como vigentes. Tampoco es suficiente conservar sólo el último sin la relación con su predecesor. La operación necesita una vista actual; la auditoría necesita versiones completas y la hora de reemplazo.

Los Sub-Data Items no tienen orden semántico. Un FID menor no gana, el primer elemento no tiene prioridad y ordenar la presentación no reconstruye la política. La selección surge de reglas expresas.

En Diffserv, el receptor valida antes de usar. Cada DS Field debe aparecer una sola vez en todo el Traffic Classification Data Item. Un valor repetido en dos subelementos distintos invalida el conjunto; no crea dos alternativas. El control debe ejecutarse sobre la totalidad, incluso si la telemetría llegó fragmentada.

RFC 2474 define al clasificador como la entidad que selecciona paquetes según el contenido del encabezado y reglas establecidas. Luego un nodo asigna el DSCP a un per-hop behavior, a menudo implementado mediante disciplinas de cola. Seleccionar, programar y prestar un servicio son actos diferentes.

La arquitectura Diffserv de RFC 2475 añade la frontera administrativa. Marcado, clasificación y acondicionamiento forman parte de políticas de dominio. Un código que cruza dominios no lleva consigo una garantía universal de tratamiento.

Cuando dos reglas coinciden, una debe perder

La clasificación Ethernet puede combinar VLAN y PCP. Las asignaciones explícitas de VLAN se prueban antes de la asignación por defecto. Si un paquete coincide al mismo tiempo con un Sub-Data Item Diffserv y otro Ethernet, RFC 9892 impone la información VLAN/PCP.

Por eso, un registro que diga «DSCP 46 coincidió» puede ser verdadero y aun así no explicar la decisión. Hace falta guardar el candidato Ethernet, la regla explícita o genérica, el resultado de validación del conjunto y la precedencia que escogió el FID.

La precedencia tampoco prueba el trato. Indica qué clasificación debe usarse cuando se superponen dos lenguajes de encabezado. Después viene la extensión consumidora.

RFC 9894 usa estos elementos en la extensión Diffserv Aware Credit Window. Los participantes anuncian el soporte al inicializar la sesión. Quien declara la extensión debe implementar los mensajes, elementos y procesos de RFC 9892 y RFC 9893. Sin negociación, los elementos de esa extensión no deben emitirse.

RFC 9893 aporta la asociación entre TID, destino DLEP y ventana de crédito. Un TID no se usa para el control de crédito si no aparece en el elemento de asociación, y los TID de ventanas distintas no pueden solaparse.

Éste es el límite con el artículo ya publicado sobre RFC 9893. Aquel trabajo analiza por qué un crédito permite un envío local pero no demuestra entrega. Aquí la pregunta es anterior: qué conjunto era válido, qué regla ganó y si alguna extensión le dio significado al FID.

Autenticar al emisor no verifica el resultado

RFC 9892 advierte que un atacante que suplante a un participante DLEP podría inyectar otro clasificador y cambiar el mapeo hacia las colas, provocando demora, congestión o pérdida. Las protecciones de transporte y de capa 2 señaladas por RFC 8175 reducen esa posibilidad.

Una sesión segura establece el origen del mensaje. No demuestra que la política fuera adecuada, que el router la programara en hardware ni que un paquete concreto recibiera el resultado esperado. La autenticidad y el efecto son dos columnas.

Un expediente sólido conserva la identidad del par, la sesión, el hash del mensaje y el resultado de validación. Después enlaza el FID elegido, la extensión, el destino, el estado pretendido, el estado observado, los contadores y la recepción remota. Si una transición carece de prueba, no se hereda el éxito anterior.

La idea coincide con la primacía del código en ejecución de Heng Lu: el estándar crea una posibilidad coordinada y la operación confirma la realidad. La especificación inicial mínima permite compartir el formato sin apropiarse de las decisiones locales de cola, capacidad y riesgo.

En Capas de realidad y poder simbólico, una palabra se vuelve poder cuando absorbe hechos que no observa. Clasificado no debe significar a la vez recibido, válido, asociado, instalado y entregado.

El clasificador nombró el flujo. El sistema todavía debía demostrar quién usó ese nombre y qué ocurrió después.

Fuentes