3. Définition du champ de services différenciés (Differentiated Services Field Definition)
Un champ d'en-tête de remplacement, appelé champ DS (DS Field), est défini, qui est destiné à remplacer les définitions existantes de l'octet TOS IPv4 [RFC791] et de l'octet de classe de trafic IPv6 [IPv6].
Six bits du champ DS sont utilisés comme point de code (DSCP, Differentiated Services Codepoint) pour sélectionner le PHB qu'un paquet expérimente à chaque nœud. Un champ de deux bits actuellement inutilisé (CU, Currently Unused) est réservé et sa définition et son interprétation sont hors du champ d'application de ce document. La valeur des bits CU est ignorée par les nœuds conformes aux services différenciés lors de la détermination du comportement par saut à appliquer à un paquet reçu.
La structure du champ DS est présentée ci-dessous :
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DSCP | CU |
+---+---+---+---+---+---+---+---+
DSCP: differentiated services codepoint (point de code de services différenciés)
CU: currently unused (actuellement inutilisé)
Dans une notation de valeur DSCP xxxxxx (où x peut être égal à 0 ou 1) utilisée dans ce document, le bit le plus à gauche signifie le bit 0 du champ DS (comme indiqué ci-dessus), et le bit le plus à droite signifie le bit 5.
Les implémenteurs doivent noter que le champ DSCP a une largeur de six bits. Les nœuds conformes DS doivent (MUST) sélectionner les PHB en faisant correspondre le champ DSCP entier de 6 bits, par exemple, en traitant la valeur du champ comme un index de table qui est utilisé pour sélectionner un mécanisme particulier de traitement de paquets qui a été implémenté dans ce dispositif. La valeur du champ CU doit (MUST) être ignorée par la sélection PHB. Le champ DSCP est défini comme un champ non structuré pour faciliter la définition de futurs comportements par saut.
À quelques exceptions près notées ci-dessous, le mappage des points de code aux PHB doit (MUST) être configurable. Un nœud conforme DS doit (MUST) prendre en charge l'équivalent logique d'une table de mappage configurable des points de code aux PHB. Les spécifications PHB doivent (MUST) inclure un point de code par défaut recommandé, qui doit (MUST) être unique pour les points de code dans l'espace standard (voir Sec. 6). Les implémentations devraient (SHOULD) prendre en charge les mappages recommandés de point de code à PHB dans leur configuration par défaut. Les opérateurs peuvent choisir d'utiliser des points de code différents pour un PHB, soit en plus soit à la place du défaut recommandé. Notez que si les opérateurs choisissent de le faire, le re-marquage des champs DS peut être nécessaire aux limites administratives même si les mêmes PHB sont implémentés des deux côtés de la limite.
Voir [ARCH] pour une discussion plus approfondie sur le re-marquage.
Les exceptions à la configurabilité générale concernent les points de code xxx000 et sont notées dans les Sec. 4.2.2 et 4.3.
Les paquets reçus avec un point de code non reconnu devraient (SHOULD) être transférés comme s'ils étaient marqués pour le comportement par défaut (voir Sec. 4), et leurs points de code ne devraient pas être modifiés. De tels paquets ne doivent pas (MUST NOT) provoquer un dysfonctionnement du nœud réseau.
La structure du champ DS présentée ci-dessus est incompatible avec la définition existante de l'octet TOS IPv4 dans [RFC791]. La présomption est que les domaines DS se protègent en déployant des nœuds de limite de re-marquage, comme devraient le faire les réseaux utilisant les désignations de priorité RFC 791. La procédure opérationnelle correcte devrait (SHOULD) suivre [RFC791], qui stipule : « Si l'utilisation réelle de ces désignations de priorité est préoccupante pour un réseau particulier, il est de la responsabilité de ce réseau de contrôler l'accès à, et l'utilisation de, ces désignations de priorité. » La validation de la valeur du champ DS aux limites DS est sensée dans tous les cas, car un nœud en amont peut facilement le définir à n'importe quelle valeur arbitraire. Les domaines DS qui ne sont pas isolés par des nœuds de limite convenablement configurés peuvent fournir un service imprévisible.
Les nœuds peuvent (MAY) réécrire le champ DS selon les besoins pour fournir un service local ou de bout en bout souhaité. Les spécifications de traductions de champ DS aux limites DS sont le sujet d'accords de niveau de service entre fournisseurs et utilisateurs, et sont hors du champ d'application de ce document. Les PHB standardisés permettent aux fournisseurs de construire leurs services à partir d'un ensemble bien connu de traitements de transmission de paquets qui peuvent être attendus dans l'équipement de nombreux fournisseurs.