Résumé

  • La RFC 9893 est un document IETF sur le chemin Standards Track. Elle définit deux messages DLEP et cinq Data Items réutilisables pour le contrôle par fenêtres de crédit.
  • Le modem fournit l’initialisation, associe la classification aux destinations et accorde les crédits. Le routeur expose son état de fenêtre et peut en demander, mais une demande n’est pas en elle-même une autorisation d’émettre.
  • Pour envoyer, il faut un classificateur correspondant, une fenêtre FID associée, assez de crédits restants et un comptage en octets incluant la surcharge MAC. Sans classificateur générique, un paquet non associé est abandonné.

DLEP organise l’échange de contrôle entre routeur et modem. La RFC 8175 fournit la session de base et la sémantique d’erreur des Data Items. La RFC 9893 ajoute le mécanisme de fenêtre de crédit, tandis que la RFC 9892 fournit la structure de classification TID/FID consommée par ce mécanisme. Un TID relie une classification à une destination ; un FID identifie une fenêtre de crédits. Ces valeurs n’ont de portée que pour le modem qui les émet et des TID qui se chevauchent sont invalides. Elles ne constituent donc pas une nomenclature universelle des files ou des domaines.

La séquence opérationnelle est stricte. Le modem initialise l’association, associe la classification pertinente et accorde une fenêtre. Le routeur observe l’état et peut demander des crédits. Chaque émetteur ne peut avoir qu’un seul Credit Control Message en attente jusqu’à la réception de la réponse correspondante. Cette règle évite de traiter plusieurs mises à jour non résolues comme une suite de permissions déjà ordonnée. Le crédit est exprimé en octets, pas en paquets, et la surcharge MAC est incluse.

Un paquet dont le comptage dépasserait le crédit disponible de la fenêtre associée ne peut pas être envoyé, même si son seul contenu utile semble tenir.

La fenêtre peut atteindre son maximum configuré : le crédit supplémentaire sature à ce maximum et ne crée pas une permission illimitée. Si le maximum diminue, le modem devrait continuer à traiter les paquets admissibles déjà en vol et retenir de nouveaux crédits jusqu’à ce que la fenêtre concernée soit repassée sous le nouveau maximum. Il s’agit d’une transition d’état du contrôle, non d’une preuve concernant la géométrie d’une file physique. Si aucun classificateur ne correspond et qu’aucun générique n’existe, l’abandon du paquet est la conséquence du protocole ; les sources n’en déduisent pas une politique de déploiement particulière.

Inconnues et limites. Les sources n’établissent ni la fréquence des déploiements ni une amélioration mesurée des performances, et elles ne définissent pas de correspondance universelle entre fenêtres logiques et files physiques. La cadence des accords, la géométrie des files, les seuils de retour arrière et la télémétrie restent des choix d’implémentation ou d’exploitation. Aucune source n’établit une confiance inter-domaines dans DSCP, VLAN ou d’autres marqueurs de classification. L’état de crédit est une permission de transmettre, pas un synonyme de politique de file ou de capacité.

Sources

  • RFC 9893, spécification Standards Track des fenêtres de crédit.
  • RFC 8175, session DLEP de base et sémantique des Data Items.
  • RFC 9892, structure de classification utilisée par la boucle.

Fixtures de vérification

  1. Ajustement exact : configurer une fenêtre TID/FID correspondante avec 1 500 octets restants ; un paquet compté à 1 500, surcharge MAC comprise, peut passer, tandis qu’un paquet compté à 1 501 ne le peut pas.
  2. Aucune correspondance : envoyer un paquet sans classificateur correspondant ni générique ; vérifier son abandon plutôt que l’invention d’une fenêtre par défaut.
  3. Ordre des contrôles : émettre un Credit Control Message, tenter d’en émettre un second avant la réponse et vérifier la règle du message unique en attente.
  4. Réduction et saturation : remplir une fenêtre jusqu’à son maximum, réduire ce maximum alors que du trafic admissible est en vol, puis vérifier qu’aucun nouveau crédit n’est accordé avant le passage sous la nouvelle limite.

Parcours de décision de l’opérateur : vérifier d’abord l’association TID/FID et l’absence de chevauchement des TID ; examiner ensuite l’état, les messages en attente et le comptage en octets ; tester enfin les paquets sans correspondance et les changements de maximum. La décision d’activer une extension ne vient qu’après ces contrôles, avec des éléments de retour arrière distincts des exigences RFC.