Resumen

  • RFC 9893 es un documento IETF de estado Standards Track que define dos mensajes DLEP y cinco Data Items reutilizables para el control mediante ventanas de crédito.
  • El módem emite la inicialización, asocia la clasificación con destinos y concede créditos. El router informa de su visión del estado de la ventana y puede solicitarlos, pero una solicitud no equivale a permiso para transmitir.
  • Antes de enviar hacen falta un clasificador coincidente, una ventana FID asociada, créditos disponibles suficientes y un conteo en octetos que incluya la sobrecarga MAC. Sin un clasificador comodín, el paquete no coincidente se descarta.

DLEP intercambia información de control de enlace entre router y módem. RFC 8175 aporta la sesión base y la semántica de errores de los Data Items; RFC 9893 añade el mecanismo de ventanas de crédito; RFC 9892 aporta la estructura de clasificación TID/FID que consume ese mecanismo. Un TID vincula una clasificación con un destino y un FID identifica una ventana de crédito. Esos valores solo son significativos para el módem que los emite, y los TID solapados son inválidos. No son un sistema universal para nombrar colas o dominios.

La secuencia operacional está limitada por reglas concretas. El módem inicializa la relación, asocia la clasificación correspondiente y concede una ventana. El router observa el estado y puede pedir créditos. Cada emisor solo puede tener un Credit Control Message pendiente hasta que llegue la respuesta correspondiente. Esta invariante impide tratar varias actualizaciones de control sin resolver como una corriente ordenada de permisos. El crédito se expresa en octetos, no en paquetes, e incluye la sobrecarga MAC.

Un paquete cuyo conteo supere el crédito disponible de su ventana asociada no puede enviarse, aunque su carga útil aislada parezca caber.

La ventana puede alcanzar su máximo configurado: el crédito se satura en ese máximo y no genera un permiso ilimitado. Si el máximo se reduce, el módem debería seguir procesando los paquetes que ya están en vuelo y cumplen los requisitos, y retener nuevos créditos hasta que la ventana afectada baje del nuevo máximo. Es una transición del estado de control, no una afirmación sobre la geometría de una cola física. Si no hay coincidencia y tampoco existe un comodín, descartar el paquete es una consecuencia del protocolo; las fuentes no lo presentan como prueba de una política concreta de despliegue.

Desconocidos y límites. Ninguna fuente establece la prevalencia de despliegue, una mejora de rendimiento medida o una correspondencia universal entre ventanas lógicas y colas físicas. La cadencia de concesión, la geometría de colas, los umbrales de reversión y la telemetría siguen siendo decisiones de implementación u operación. Ninguna fuente establece confianza entre dominios en DSCP, VLAN u otras marcas de clasificación. El estado de crédito es permiso para transmitir, no sinónimo de política de cola o capacidad.

Fuentes

  • RFC 9893, especificación Standards Track del control por créditos.
  • RFC 8175, sesión base de DLEP y semántica de Data Items.
  • RFC 9892, estructura de clasificación usada por el bucle.

Fixtures de verificación

  1. Ajuste exacto: configurar una ventana TID/FID coincidente con 1.500 octetos disponibles; un paquete cuyo conteo completo, incluida la sobrecarga MAC, sea 1.500 puede pasar, mientras que uno contado como 1.501 no puede.
  2. Sin coincidencia: enviar un paquete sin clasificador coincidente ni comodín; verificar el descarte en lugar de inferir una ventana predeterminada.
  3. Orden de control: enviar un Credit Control Message, intentar un segundo antes de recibir la respuesta y verificar la invariante de un solo mensaje pendiente.
  4. Reducción y saturación: llenar una ventana hasta su máximo, reducirlo mientras hay tráfico que cumple los requisitos en vuelo y verificar que no llegan nuevos créditos hasta quedar por debajo del nuevo límite.

Ruta de decisión del operador: comprobar primero la asociación TID/FID y que no haya TID solapados; revisar después el estado, los mensajes pendientes y el conteo en octetos; probar luego el tráfico sin coincidencia y los cambios del máximo. Solo después decidir si se habilita una extensión, manteniendo la evidencia de reversión separada de las exigencias de las RFC.