Resumen

  • RFC 9894 es un documento IETF de Standards Track que define la extensión DLEP de ventanas de crédito conscientes de Diffserv, tanto compartidas como específicas de destino.
  • El tipo de extensión 6 debe declararse en el elemento de datos Extensions Supported. Un participante no debe emitir los elementos de datos de la extensión si el mensaje de inicialización recibido no indicaba el soporte del par.
  • Anunciarla implica una clausura de dependencias: deben estar soportados los mensajes, elementos de datos, clasificación Diffserv y procesamiento pertinentes de RFC 9892 y RFC 9893.
  • Cuando se usan ventanas de crédito, el router no debe enviar al módem tráfico que no disponga de créditos.

RFC 9894 une dos mecanismos, no una bandera independiente. RFC 9892 aporta la clasificación del tráfico y RFC 9893 el control de ventanas de crédito. Juntos relacionan destinos DLEP y valores DSCP con ventanas lógicas. Una ventana puede compartirse entre varios destinos o dedicarse a uno concreto. Las fuentes no fijan una correspondencia universal DSCP-ventana ni un número obligatorio de colas.

El alcance también importa. Un comodín puede abarcar flujos existentes y flujos que aparezcan después; por eso RFC 9894 recomienda evitarlo cuando no sea necesario. Si coinciden la clasificación Diffserv y la clasificación Ethernet, RFC 9892 otorga precedencia a Ethernet. Probar sólo un paquete con una marca DSCP no demuestra que el sistema resuelva correctamente la colisión.

El camino de admisión es verificable. Primero hay que confirmar la declaración del par durante la inicialización. Después se comprueba la clausura local de RFC 9892/RFC 9893. A continuación se comparan las ventanas anunciadas por el módem con las colas y combinaciones que el router puede realizar. Se instala sólo el subconjunto compatible, se documenta lo que queda fuera y se informa del desajuste mediante los mecanismos ordinarios de gestión. Si no existe una forma compatible, se reinicia la sesión en vez de aceptar una imagen de capacidad falsa.

Una fixture concreta puede anunciar una ventana compartida, otra específica de destino y un conjunto de DSCP que exceda las combinaciones disponibles en el router. El resultado esperado es un subconjunto visible o un reinicio, junto con un registro de gestión. Añadir un comodín y un flujo nuevo para comprobar su expansión; enviar un paquete que coincida con ambas familias para comprobar la precedencia Ethernet; agotar una ventana y verificar que no se envía tráfico sin crédito. Repetir la inicialización sin soporte del par y confirmar que no se emiten elementos de datos de la extensión.

La seguridad forma parte de la admisión. Un mensaje DLEP inyectado que redimensione una ventana puede causar una denegación de servicio; los mecanismos de seguridad de RFC 8175 se aplican a la extensión. Hay que probar intentos de redimensionamiento autenticados y rechazados, y observar su visibilidad en la sesión y en la gestión.

Las fuentes no establecen prevalencia de despliegue, mejora de rendimiento medida ni una asignación universal. Tampoco definen una cantidad obligatoria de colas, una CLI propietaria, un módulo YANG, un umbral de telemetría o un temporizador de reversión. La confianza en las marcas DSCP entre dominios administrativos sigue siendo una preocupación del operador, no un resultado demostrado por RFC 9894.

Fuentes

  • RFC 9894 — extensión DLEP de ventana de crédito Diffserv.
  • RFC 9892 — clasificación de tráfico DLEP.
  • RFC 9893 — control de ventanas de crédito DLEP.
  • RFC 8175 — protocolo base y mecanismos de seguridad DLEP.
  • RFC 2475 — arquitectura Diffserv.