Résumé

  • Le champ TOS d'IPv4 exprimait déjà des préférences sans offrir de garantie. DiffServ en a tiré une architecture où six bits sélectionnent un comportement par saut et où les décisions coûteuses se concentrent aux frontières.
  • Les groupes AF et EF normalisent des briques observables, non un contrat de bout en bout. Un domaine reste libre de mesurer, remettre en marque, ramener au service par défaut ou rejeter un trafic venu d'ailleurs.

Le marquage arrive avant la preuve

Un flux de voix quitte un réseau d'entreprise avec le codepoint associé à Expedited Forwarding. Dans ce premier domaine, un classificateur connaît peut-être le client, un policer connaît son débit autorisé et un ordonnanceur a réellement réservé une capacité. Quelques microsecondes plus tard, le paquet atteint un autre opérateur. La valeur est toujours là; le dossier qui lui donnait sens ne l'est pas.

Le routeur d'entrée ne peut déduire des six bits ni l'identité du client, ni le profil acheté, ni la disponibilité de la file rapide. Il doit confronter le paquet à ses propres règles. Conserver la marque est une décision. La remplacer par le comportement par défaut en est une autre. Dans les deux cas, le réseau destinataire agit dans le cadre de DiffServ.

La frontière ne casse donc pas la promesse du protocole. Elle révèle que le protocole n'avait jamais fait cette promesse à la place de l'opérateur.

Le TOS de 1981 conseillait le réseau

Dans RFC 791, l'en-tête IPv4 comportait un octet Type of Service. Trois bits formaient une précédence; d'autres indiquaient une préférence pour un faible délai, un fort débit ou une grande fiabilité. L'idée était élégante: exprimer un besoin abstrait, puis laisser chaque technologie sous-jacente choisir le traitement disponible.

La limite figurait déjà dans le texte. La précédence Network Control était destinée à l'intérieur d'un réseau. Son usage et son contrôle appartenaient à ce réseau, qui devait empêcher les abus s'il jugeait ces niveaux sensibles. L'émetteur pouvait écrire une valeur; il ne se délivrait pas lui-même une autorisation.

Onze ans plus tard, RFC 1349 qualifia explicitement le mécanisme de consultatif. Il ne convenait pas à une demande de garantie. Un réseau homogène pouvait n'avoir aucune meilleure route à offrir, et le champ ne savait pas demander un nombre précis de kilobits par seconde. Le souhait voyageait; la ressource ne naissait pas avec lui.

DiffServ a choisi l'agrégat plutôt que le dossier individuel

À l'échelle d'Internet, conserver dans le cœur un état par application, par client ou par microflux aurait été une charge considérable. Les deux textes fondateurs de décembre 1998, RFC 2474 et RFC 2475, ont déplacé l'intelligence.

Les six bits de poids fort de l'ancien octet TOS et de la Traffic Class IPv6 sont devenus le champ Differentiated Services. La valeur DSCP sélectionne, dans chaque nœud, un Per-Hop Behavior. Les deux bits restants ont ensuite servi à ECN; ils ne prolongent pas le pouvoir de DiffServ.

Le codepoint et le comportement ne sont pas synonymes. Plusieurs valeurs peuvent sélectionner le même PHB; certaines peuvent n'avoir qu'une signification locale. Un PHB décrit le traitement extérieurement observable d'un agrégat sur un nœud: ordonnancement, capacité de tampon, probabilité de rejet. Ce qui est normalisé est une propriété mesurable de la machine en fonctionnement, non le nom commercial d'un service mondial.

Le domaine est une unité de politique

RFC 2475 appelle DS domain un ensemble continu de nœuds administrés avec une même politique de fourniture et des définitions cohérentes de PHB. Les routeurs intérieurs peuvent ainsi traiter des agrégats sans conserver le contrat de chaque client. La complexité demeure à l'entrée et à la sortie.

À ces frontières, un conditionneur peut classer sur plusieurs champs, mesurer un débit, marquer ou remarquer, mettre en forme une rafale, ou éliminer l'excédent. Le paquet entre dans le cœur seulement après cette opération de confiance. La petite taille du champ est rendue possible par tout ce qui reste hors du champ: identité, profil, facturation, responsabilité et capacité installée.

Le domaine est donc moins une enceinte physique qu'une étendue de décision. Deux réseaux reliés par un câble ne deviennent pas une seule autorité de file d'attente.

AF ne fixe pas la quantité d'assurance

RFC 2597 a défini Assured Forwarding en 1999: quatre classes, chacune dotée de trois précédences de rejet. En congestion, les paquets d'une même classe portant la plus forte précédence de rejet doivent courir un risque de perte supérieur. L'ordre d'un même microflux doit toutefois être préservé.

La grille paraît précise, mais elle ne dit pas quelle part de bande passante ou de mémoire doit recevoir chaque classe. L'assurance effective dépend des ressources que le fournisseur lui attribue, de la charge et du profil appliqué à l'entrée. Un nœud conforme à DiffServ n'est d'ailleurs pas obligé d'implémenter AF.

Le bord peut remodeler le trafic, accroître ou réduire sa précédence de rejet, le déplacer vers une autre classe ou l'éliminer. Les étiquettes communes permettent la coordination; elles ne retirent pas au fournisseur la décision d'allocation.

EF reste une propriété d'un nœud

Le nom Expedited Forwarding évoque plus volontiers une voie garantie. RFC 3246, publié en 2002, exige d'un nœud qui revendique EF un service au moins égal à un débit configuré et décrit comment borner son comportement. Puis il s'arrête: le texte porte sur un nœud. Une collection de nœuds est hors de son périmètre, et EF n'est pas obligatoire pour être conforme à DiffServ.

Une faible latence sur un trajet suppose donc que chaque nœud concerné dispose de ressources et que les arrivées restent compatibles avec les conditions qui maintiennent les files courtes. La bonne conduite d'un routeur ne contraint pas le suivant. Cette modestie rend le PHB vérifiable au lieu d'en faire une garantie invérifiable.

Le contrat ne se compresse pas en six bits

L'architecture parlait de SLA et de Traffic Conditioning Agreement. RFC 3260 a ensuite distingué ces accords, qui peuvent contenir prix et disponibilité, des paramètres techniques SLS et TCS. Ce raffinement admet que la norme ne peut écrire les relations économiques dans un en-tête.

Un domaine sans accord de service amélioré avec son voisin peut remettre un DSCP à zéro. Une valeur inacceptable peut être modifiée ou le paquet rejeté. Une valeur inconnue, après le contrôle d'entrée, devrait normalement sélectionner le comportement par défaut plutôt qu'un privilège inventé. Le propriétaire des files demeure le principal qui engage les ressources.

Cette autonomie n'interdit pas les services interdomaines. Elle leur impose une chaîne explicite: accords, profils compatibles, traductions connues et capacité réelle sur chaque segment.

Une valeur falsifiable exige un contrôle

Tout logiciel peut tenter d'inscrire un codepoint privilégié. DiffServ ne le prend donc pas pour une preuve d'identité. Les RFC décrivent le vol de service: un trafic non autorisé peut épuiser la capacité réservée et transformer la fraude en déni de service. La première défense est le conditionnement aux frontières, complété par l'intégrité de l'infrastructure interne.

Les tunnels ne suppriment pas la question. Lorsqu'un en-tête interne réapparaît dans un nouveau domaine, le point de sortie assume une fonction d'entrée. Une protection cryptographique peut prouver que la valeur n'a pas changé; elle ne crée pas l'engagement commercial du réseau qui la reçoit.

Les nouveaux médias ont confirmé la nécessité de traduire

RFC 7657 rappelait encore en 2015 qu'un terminal ne peut savoir quel PHB un codepoint de classe sélectionne dans un réseau donné, et encore moins de bout en bout. CS1 peut correspondre à un service à effort réduit, mais aussi au service par défaut, à un autre traitement, à une remarque ou à un rejet.

En 2018, RFC 8325 a traité la rencontre avec IEEE 802.11. Le DSCP d'IP et la User Priority du Wi-Fi appartiennent à deux espaces différents. Le point d'accès doit établir une correspondance; faute de service équivalent, il peut revenir au défaut. Recopier une valeur n'est pas transporter sa constitution.

Une couche commune assez mince pour rester légitime

DiffServ n'a pas échoué à centraliser la qualité de service. Il a réussi à ne pas le faire. Le standard a fourni des signes communs et des comportements de nœud testables. Les opérateurs ont gardé l'allocation, l'admission et la traduction. Les clients et pairs ont gardé les accords qui transforment une préférence en service.

Les six bits pouvaient demander. Le code en fonctionnement pouvait répondre. Le domaine suivant restait libre parce qu'aucun paquet ne peut s'attribuer une créance sur une ressource qu'il ne possède pas.

Sources et limites

RFC 791 et RFC 1349 établissent l'histoire du TOS; RFC 2474 et RFC 2475 définissent le champ et l'architecture; RFC 2597, RFC 3246 et RFC 3260 précisent AF, EF et les accords; RFC 7657 et RFC 8325 documentent les limites ultérieures. Ces textes ne décrivent ni les configurations actuelles d'un opérateur, ni les droits d'un client, ni les performances mesurées d'un trajet.