Résumé

  • Une agrégation de traitement réunit plusieurs classes Diffserv dans un même comportement de transmission sans nécessairement leur attribuer le même DSCP.
  • La classe exprime le besoin de bout en bout ; l’agrégat décrit ce qu’un segment choisit de faire localement.
  • L’agrégat doit satisfaire l’exigence la plus stricte de ses membres, et non leur moyenne.
  • Les classes réunies devraient avoir des profils de trafic et des besoins de perte, délai et gigue suffisamment proches.
  • L’identité de chaque classe de bout en bout ne doit pas disparaître, car le domaine suivant peut agréger autrement.
  • La méthode recommandée garde les DSCP originaux et les classe vers une file commune sans les réécrire.
  • Si un domaine impose une marque locale, il doit restaurer l’indication originale à la sortie ; un tunnel n’est qu’un moyen de garde.
  • Le contrôle d’admission ou le conditionnement demeure propre à chaque classe avant un éventuel contrôle supplémentaire de la somme.
  • Les quatre agrégats proposés sont un exemple adaptable, ni une norme minimale ni une preuve de capacité.
  • Vitesse de lien, profondeur de file, algorithme d’ordonnancement, taux d’utilisation, tailles de paquets et rafales déterminent la sûreté réelle du regroupement.
  • Une valeur MPLS Traffic Class transporte une décision de domaine ; elle ne certifie ni la file installée ni le comportement observé.
  • La gouvernance honnête conserve séparément marque reçue, traduction locale, restauration, admission, ressources, mesure et résultat applicatif.

La frontière où une marque devient locale

Un paquet arrive chez un opérateur avec un DSCP qui représente sa classe de service de bout en bout. L’opérateur ne possède peut-être que quatre traitements dans son cœur. Il peut donc envoyer plusieurs valeurs vers la même file. Il peut aussi, pour des raisons d’architecture interne, remplacer la valeur reçue par une marque locale.

Ce geste est permis par la RFC 5127, mais il crée une obligation de conservation. La marque locale n’annule pas l’identité antérieure. À la sortie du domaine, l’indication d’origine doit être restaurée afin que le réseau suivant puisse prendre sa propre décision. Le domaine intermédiaire obtient un pouvoir de traduction, pas un pouvoir de redéfinition mondiale.

Le cas est révélateur parce que les paquets peuvent continuer à circuler même si la restauration échoue. Il n’y a pas nécessairement de panne franche. Le destinataire voit du trafic, mais le réseau suivant classe désormais le flux avec une information altérée. Une continuité apparente peut donc masquer une rupture de sens.

Pour rendre cette frontière auditable, il faut quatre observations : le DSCP d’entrée, la représentation locale, l’état d’encapsulation ou de table qui garde l’original, puis le DSCP de sortie. Il faut ensuite vérifier la classification effective du domaine suivant. Un document de configuration ne remplace aucune de ces observations.

Une file commune ne crée pas une promesse commune

La RFC distingue l’agrégat de traitement d’un agrégat de comportement. Le premier peut contenir plusieurs DSCP et ne concerne que le traitement de transmission partagé. Les classes membres continuent à porter des besoins applicatifs distincts.

Cette distinction impose la règle la plus exigeante du document : l’agrégat doit répondre aux exigences les plus strictes de ses membres. Une classe qui tolère un délai moyen ne peut pas abaisser le niveau dû à une classe extrêmement sensible à la gigue. Faire la moyenne reviendrait à convertir une obligation précise en statistique confortable.

Mais « répondre à la plus stricte » n’est pas un chiffre de capacité fourni par le texte. La règle fixe un plancher d’ingénierie. Les données réelles — débit admis, distribution des tailles, corrélation des rafales, poids d’ordonnancement et charge après reroutage — déterminent si ce plancher est atteint.

La recommandation de réunir des classes similaires évite certaines collisions, sans les supprimer. Deux applications peuvent avoir le même objectif de délai et des rafales très différentes. Une petite signalisation périodique et une vidéo interactive peuvent être sensibles au temps, tout en occupant la file de manière incomparable.

La garde de l’identité permet la pluralité des domaines

Pourquoi conserver le DSCP original si le cœur n'utilise qu'une seule file ? Parce qu'un autre domaine peut disposer de davantage de traitements, appliquer un autre contrat ou refuser une classe. La compression locale ne doit pas empêcher une décision future plus fine.

La RFC 5127 rejoint ici le principe de spécification initiale minimale : un domaine peut adopter quatre agrégats, trois, cinq ou un autre ensemble. Le schéma proposé n'est ni minimum ni maximum. Sa validité dépend de la capacité et des besoins locaux.

La liberté locale ne fonctionne que si l'interface reste lisible. À une frontière interopérateur, la relation devrait être définie en classes de service, non selon le nom propriétaire d'une file interne. « Temps réel Or » chez un fournisseur n'oblige pas le suivant à construire la même file. Il doit cependant comprendre la classe reçue et déclarer le sort qu'il lui réserve.

La preuve de passage doit donc contenir l'accord, la marque, la politique d'entrée, la décision d'admission et la mesure. Voir EF des deux côtés prouve la présence de la valeur à deux instants. Cela ne démontre pas le comportement de chaque saut situé entre eux.

Deux admissions, deux questions

Chaque agrégat dispose de ressources limitées. La RFC recommande donc un contrôle ou conditionnement par classe et permet ensuite un contrôle sur la somme. Ces étages ne sont pas interchangeables.

Le compteur individuel vérifie qu'une classe respecte son enveloppe. Le compteur global vérifie que l'ensemble reste dans le budget de la file. Une classe peut dépasser son contrat tandis que la somme reste basse parce qu'une autre est inactive. À l'inverse, toutes les classes peuvent respecter leur plafond et produire ensemble une pointe corrélée que le budget commun n'absorbe pas.

Dans le premier scénario, le problème est l'équité et l'application de l'accord. Dans le second, le problème est le modèle de dimensionnement. Les deux peuvent produire la même perte finale. Sans les reçus séparés, l'enquête attribuera le symptôme au mauvais acteur.

Les historiques aident, mais la RFC oppose implicitement un service point-à-point prévisible à un service multipoint plus variable. Un historique de moyenne ne garantit pas une pointe future. Plus l'agrégat réunit de membres, plus la covariance compte.

Les quatre couleurs ne sont qu'un exemple

Le document illustre quatre familles : Network Control, Real-Time, Assured Elastic et Elastic. L'exemple permet de discuter des compromis, pas de certifier une architecture.

Network Control vise les échanges nécessaires à la survie du réseau sous forte charge. Le texte distingue même le contrôle du client de celui du fournisseur. Les placer sous le seul mot « contrôle » effacerait la question de savoir quel plan de commande reçoit quelles ressources.

Real-Time regroupe téléphonie, signalisation, conférence, interactivité et vidéo de diffusion. Son comportement prévisible suppose une admission en bordure et des limites exécutoires. Si cette hypothèse manque, le nom de la file ne la crée pas.

Assured Elastic conserve des niveaux de probabilité de perte. Elastic peut faire tomber CS1 avant Default/CS0. Une même classe d'ordonnancement peut donc encore produire des destins différents. L'opérateur doit publier le mécanisme de rejet et mesurer son effet sous congestion.

La vitesse n'est pas la marge

La RFC observe que des liens plus rapides peuvent permettre davantage d'agrégation, à condition que l'utilisation reste dans le niveau prévu. Le conditionnel protège toute la phrase.

La vitesse nominale ne décrit ni la charge actuelle ni la charge après une panne. Une protection MPLS ou un reroutage IP peut déplacer plusieurs agrégats vers un chemin de secours. Le lien reste rapide sur la fiche technique et devient insuffisant pour le mélange réel.

Une file profonde absorbe une rafale mais ajoute du délai. Une file courte protège le délai en exposant davantage de pertes. L'ordonnanceur, les tailles de paquets et les taux d'émission transforment encore le résultat. Aucune de ces propriétés ne se lit dans les six bits du DSCP.

La validation sérieuse reproduit les scénarios : trafic normal, rafales simultanées, lien majeur perdu, politique modifiée, nouvelle classe admise et restauration de marque après tunnel. L'absence d'alarme en régime calme n'est pas une preuve.

MPLS garde la décision dans le domaine

L'annexe propose des valeurs EXP pour représenter les agrégats sur un E-LSP. RFC 5462 a ensuite nommé ce champ Traffic Class. Ce changement terminologique ne rend pas la signification globale.

Chaque domaine MPLS contrôle son allocation. Sur un E-LSP, les bits contribuent à inférer la classe d'ordonnancement ; sur un L-LSP, un seul PHB Scheduling Class appartient au chemin et l'agrégat devient une décision par LSP. Le label et les bits décrivent le transport prévu. La table installée décrit la configuration. Les compteurs et sondes décrivent l'exécution.

Le cas CS1 est particulièrement utile : le document note qu'il peut être affamé sous congestion dans l'exemple Elastic. Cette possibilité peut être cohérente avec une politique basse priorité. Elle ne définit ni quantité minimale livrée ni durée acceptable d'affamement.

Ce que les archives ne prouvent pas

Les fiches RFC Editor et Datatracker prouvent l'identité et le statut Informational de la RFC 5127. IANA prouve l'enregistrement de codepoints. Les RFC de base définissent DSCP, architecture Diffserv, AF, EF, marqueurs et transport MPLS. Les textes ultérieurs prouvent l'évolution de la documentation.

Ils ne prouvent pas qu'un fournisseur nommé suit la recommandation, qu'il utilise quatre files, restaure les marques, applique l'admission, évite l'affamement ou respecte un SLA actuel. Le paquet de sources ne contient ni recensement de déploiement, ni trace de paquet, ni incident mesuré, ni résultat client. L'analyse reste donc celle d'un mécanisme et de ses limites probatoires.

Sources