Résumé
- La RFC 9893 organise un contrôle proactif : un modem crédite une fenêtre repérée par un FID, puis le routeur ne peut envoyer une trame classée que si le solde couvre tous ses octets, surcharge MAC comprise.
- Le Grant exprime une permission à l’interface routeur-modem et le Status le compteur vu par le routeur. Aucun des deux n’atteste l’arrivée dans la file, la transmission sur le lien, la réception distante ou la réussite métier.
Le tableau de supervision racontait une histoire rassurante. Les nouveaux crédits avaient été reçus, les débits comptables du routeur retombaient juste et aucun identifiant inconnu n’apparaissait. Le tableau du service, lui, signalait des opérations absentes au site distant. Pour expliquer l’écart, il fallait cesser de demander au registre des crédits ce qui s’était passé après sa dernière frontière observable.
La RFC 9893 complète DLEP par deux messages et cinq Data Items réutilisables. Le protocole de base de la RFC 8175 relie deux pairs, un routeur et un modem, afin d’échanger des informations de contrôle sur un lien variable. Il ne proposait ni identification fine des flux ni contrôle de leur émission. Le crédit change l’ordre de l’action : le routeur attend que le modem annonce de la place au lieu d’envoyer jusqu’à recevoir un ordre de pause.
Cette prévention limite certaines pertes, mais son domaine reste local. Une fenêtre correspond en principe à une file virtuelle ou physique du modem. Elle peut être partagée entre plusieurs flux ou réservée à un groupe plus étroit. Elle régit uniquement le trafic allant du routeur vers le modem. Elle ne réserve ni le spectre, ni un créneau futur, ni la capacité du destinataire.
Avant le solde vient la classification. La RFC 9892 définit un TID pour un ensemble de classes et un FID pour chaque flux qui le compose. Le modem associe ensuite le TID à une destination DLEP. Ces numéros ne sont pas universels : ils valent chez le modem qui les émet, et le FID ne désigne sa fenêtre que pendant une session donnée.
Cette portée interdit une jointure paresseuse. Après une reconnexion, le même FID peut décrire une autre file ou un autre classement. Un dossier de preuve doit donc conserver l’identité du routeur et du modem, l’instance de session, la génération du classificateur, la destination, le TID, le FID et la politique de joker. Sans classificateur correspondant, le routeur ne doit pas envoyer. Sans joker, un paquet non reconnu doit être rejeté.
Les cinq Data Items distribuent les responsabilités. Initialization crée ou met à jour la fenêtre d’un FID. Association relie le TID d’un classement à une destination. Grant ajoute des octets. Status expose le solde que croit posséder le routeur. Request sollicite de nouveaux octets pour une ou toutes les fenêtres. Le mot « état » ne doit pas effacer l’auteur ni le temps de chacune de ces assertions.
Dans un Grant, Additional Credits est un entier non signé de 64 bits. Zéro signifie qu’aucun crédit supplémentaire n’est fourni. Le modem peut augmenter le solde lorsque sa capacité de transmission ou sa file locale offre davantage de place que la valeur précédemment annoncée. La traduction entre la surcharge de sa technologie et le décompte normalisé peut être approximative. Un Grant est donc une décision fondée sur une vue locale, pas une garantie que cette vue restera vraie au moment où arrivera la prochaine trame.
Le débit du routeur est, lui aussi, borné. Il doit vérifier que la fenêtre couvre le paquet entier, puis compter les octets de trame, d’en-tête et de terminaison MAC visibles sur son lien avec le modem. S’il envoie, il soustrait ce total. Cette trace établit une classification, une décision d’envoi et un calcul. Elle ne montre pas que le micrologiciel a admis le paquet, que la bonne file l’a conservé, que l’ordonnanceur lui a donné un tour ou que le support distant l’a acquitté.
Status n’est pas une sonde de file. C’est la vue courante du routeur, envoyée pour synchroniser les pairs. Le modem la compare à son propre état restant et peut réinitialiser la fenêtre ou corriger les Grants futurs si l’écart dépasse ce que les trames observées expliquent. La norme prévoit donc des divergences licites. Leur correction prouve un réajustement du plan de contrôle, non le parcours individuel des paquets pendant l’intervalle.
Une phrase de la RFC protège particulièrement bien contre l’excès de confiance : les journaux décrits sont déclenchés par le contenu des Data Items reçus; aucune activité du plan de données ne produit à elle seule ces messages. Un journal DLEP silencieux peut coexister avec une perte à l’admission du modem, une file saturée, des reprises radio épuisées ou une application qui refuse l’opération.
L’extension Diffserv de la RFC 9894 permet d’associer des DSCP aux fenêtres. Un routeur peut toutefois disposer de moins de files ou de combinaisons que le modem; il utilisera alors un sous-ensemble ou réinitialisera la session. La RFC 2474 définit le codepoint et le comportement par saut. La RFC 2475 situe classification, marquage, mise en forme et police dans une composition de service. Le traitement d’un saut ne devient pas, par répétition dans un tableau de bord, une promesse de bout en bout.
La pause de la RFC 8651 offre le contraste utile : pause et reprise ne concernent elles aussi que le canal de données entre routeur et modem. Le crédit peut agir plus tôt qu’une pause, sans pour autant gagner une compétence sur le lien distant.
Une clôture sérieuse assemble donc plusieurs témoins. Au contrôle DLEP — négociation, session, classificateur, Initialization, Association, Grant, Status et Request — s’ajoutent la décision du routeur et son débit MAC. Puis viennent les preuves propres au modem : arrivée à l’interface, admission, occupation, rejet et vidage. Le support fournit tentative, reprise, échec ou acquittement. Le nœud distant atteste la réception. L’application, enfin, atteste autorisation et commit.
La primauté du code en exécution de Heng Lu n’accorde à aucun écran une souveraineté par agrégation. Chaque composant peut parler de ce qu’il observe. La spécification initiale minimale explique pourquoi l’interopérabilité commune doit rester mince, tandis que cadence des Grants, nombre de files, cartographie DSCP, alarmes et conservation demeurent des décisions locales et réversibles.
La bonne question de direction n’est pas « avions-nous du crédit ? » Elle est : quelle session a permis à quel paquet de franchir quelle interface, et quels témoins indépendants démontrent tous les franchissements suivants ?
Sources
- https://www.rfc-editor.org/rfc/rfc9893.html
- https://www.rfc-editor.org/rfc/rfc8175.html
- https://www.rfc-editor.org/rfc/rfc9892.html
- https://www.rfc-editor.org/rfc/rfc9894.html
- https://www.rfc-editor.org/rfc/rfc8651.html
- https://www.rfc-editor.org/rfc/rfc2474.html
- https://www.rfc-editor.org/rfc/rfc2475.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/on-data-sovereignty-technical-vs-practical-realities/
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

