Résumé

  • La RFC 9894 est un document IETF sur le chemin Standards Track, qui définit une extension DLEP de fenêtres de crédit conscientes de Diffserv, partagées ou propres à une destination.
  • Le type d’extension 6 doit être déclaré dans l’élément de données Extensions Supported. Un participant ne doit pas émettre les éléments de données de l’extension si le message d’initialisation reçu ne déclarait pas le soutien du pair.
  • L’annonce implique la fermeture de dépendances : messages, éléments de données, classification Diffserv et traitement pertinents des RFC 9892 et RFC 9893 doivent être pris en charge.
  • Lorsqu’une fenêtre de crédit est utilisée, le routeur ne doit pas envoyer au modem de trafic dépourvu de crédits disponibles.

La RFC 9894 assemble deux mécanismes, et non un simple indicateur facultatif. La RFC 9892 fournit la classification du trafic ; la RFC 9893 fournit le contrôle des fenêtres de crédit. Ensemble, ils associent destinations DLEP et valeurs DSCP à des fenêtres logiques. Une fenêtre peut être partagée entre plusieurs destinations ou dédiée à une destination. Les sources ne fixent ni correspondance DSCP-fenêtre universelle ni nombre obligatoire de files.

La portée doit être vérifiée. Un caractère générique peut inclure les flux existants et ceux qui apparaîtront ensuite ; la RFC 9894 recommande donc d’éviter les jokers lorsqu’ils ne sont pas nécessaires. Si la classification Diffserv et la classification Ethernet correspondent toutes deux, la RFC 9892 donne la priorité à Ethernet. Un test qui ne couvre qu’un marquage DSCP isolé est incomplet.

Le parcours d’admission est séquentiel. Confirmer d’abord la déclaration du pair pendant l’initialisation. Vérifier ensuite la fermeture RFC 9892/RFC 9893 dans l’implémentation locale. Comparer enfin les fenêtres annoncées par le modem avec les files et combinaisons réellement disponibles sur le routeur. Installer uniquement le sous-ensemble pris en charge, consigner l’exclusion et signaler l’écart par les mécanismes ordinaires de gestion. Si aucune forme sûre n’est représentable, réinitialiser la session au lieu d’accepter une capacité inexacte.

Une fixture de vérification peut annoncer une fenêtre partagée, une fenêtre propre à une destination et une plage DSCP dépassant les combinaisons du routeur. Le résultat attendu est un sous-ensemble visible ou une réinitialisation, avec rapport de gestion. Ajouter un joker et un nouveau flux pour vérifier son expansion ; un paquet correspondant aux deux familles de classification pour vérifier la priorité Ethernet ; puis épuiser une fenêtre et vérifier l’absence d’envoi sans crédit. Répéter l’initialisation sans soutien du pair et vérifier que les éléments de données de l’extension ne sont pas émis.

La sécurité appartient à l’admission. Un message DLEP injecté qui redimensionne une fenêtre peut provoquer un déni de service ; les mécanismes de sécurité de la RFC 8175 s’appliquent à l’extension. Tester les redimensionnements authentifiés et rejetés, ainsi que leur visibilité dans la session et la gestion.

Les sources n’établissent ni prévalence de déploiement, ni gain de performance mesuré, ni correspondance universelle. Elles ne définissent pas non plus un nombre obligatoire de files, une CLI propriétaire, un module YANG, un seuil de télémétrie ou un délai de retour arrière. La fiabilité des marquages DSCP entre domaines administratifs reste une question d’exploitation, non un résultat établi par la RFC 9894.

Sources

  • RFC 9894 — extension DLEP de fenêtre de crédit Diffserv.
  • RFC 9892 — classification du trafic DLEP.
  • RFC 9893 — contrôle des fenêtres de crédit DLEP.
  • RFC 8175 — protocole de base et sécurité DLEP.
  • RFC 2475 — architecture Diffserv.