3. Differentiated Services Field Definition (Définition du champ des services différenciés)

Un champ d'en-tête alternatif, appelé le champ DS, est défini pour remplacer les définitions existantes de l'octet TOS IPv4 [RFC791] et de l'octet Traffic Class 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 subit à chaque nœud. Un champ de deux bits actuellement non utilisé (CU, Currently Unused) est réservé dont la définition et l'interprétation sont hors du champ d'application de ce document. Les nœuds conformes aux services différenciés doivent ignorer la valeur des bits CU lors de la détermination du comportement par saut à appliquer à un paquet reçu.

La structure du champ DS est la suivante:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   |         DSCP          |  CU   |
   +---+---+---+---+---+---+---+---+

     DSCP: differentiated services codepoint
     CU:   currently unused

Dans la notation de valeur DSCP 'xxxxxx' (où 'x' peut être égal à '0' ou '1') utilisée dans ce document, le bit le plus à gauche indique le bit 0 du champ DS (comme ci-dessus) et le bit le plus à droite indique le bit 5.

Les implémenteurs doivent noter que le champ DSCP est de 6 bits de large. Un nœud conforme DS doit (MUST) sélectionner le PHB en faisant correspondre l'ensemble du champ DSCP de 6 bits, par exemple en traitant la valeur du champ comme un index de table à utiliser pour sélectionner un mécanisme de traitement de paquets particulier implémenté sur cet appareil. Les valeurs du champ CU doivent (MUST) être ignorées par la sélection du PHB. Le champ DSCP est défini comme un champ non structuré (unstructured field) pour faciliter les définitions futures de comportements par saut.

Le mappage des points de code aux PHB doit (MUST) être configurable, à quelques exceptions près notées ci-dessous. 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 (standard space) (voir Section 6). Les implémentations devraient (should) prendre en charge le mappage point de code-PHB par défaut recommandé en configuration par défaut. Les opérateurs peuvent choisir d'utiliser un point de code différent pour un PHB en plus ou à la place du défaut recommandé. Si les opérateurs choisissent de le faire, ils doivent être conscients que le re-marquage (re-marking) du champ DS aux limites administratives peut être nécessaire, même si les deux côtés de la limite implémentent le même PHB.

Voir [ARCH] pour une discussion plus approfondie du re-marquage.

L'exception à la configurabilité générale concerne les points de code 'xxx000', décrits aux Sections 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 (Default) (voir Section 4), et ce point de code ne devrait pas (SHOULD NOT) être modifié. De tels paquets ne doivent pas (MUST NOT) faire dysfonctionner un nœud réseau.

La structure du champ DS présentée ci-dessus n'est pas compatible avec la définition existante de l'octet TOS IPv4 dans [RFC791]. La présomption est que les domaines DS se protégeront en déployant des nœuds de limite de re-marquage, tout comme les réseaux utilisant les désignations de Precedence RFC 791. Les procédures opérationnelles appropriées devraient (SHOULD) suivre [RFC791], qui stipule: "Si l'utilisation réelle de ces désignations de priorité est une préoccupation pour un réseau particulier, il incombe à ce réseau de contrôler l'accès et l'utilisation de ces priorités." La validation des valeurs du champ DS à une limite DS a du sens de toute façon, car les nœuds en amont peuvent facilement le définir à n'importe quelle valeur. Les domaines DS qui ne sont pas isolés par des nœuds de limite correctement configurés peuvent offrir un service imprévisible.

Les nœuds peuvent (MAY) réécrire le champ DS au besoin pour fournir un service local ou de bout en bout souhaité. La spécification des traductions du champ DS aux limites DS est le sujet d'accords de niveau de service (service level agreements) entre les fournisseurs et les utilisateurs et est hors du champ d'application de ce document. Avec les PHB standardisés, les fournisseurs peuvent construire des services à partir d'un ensemble bien connu de traitements de transmission de paquets qui peuvent être présents sur l'équipement de nombreux fournisseurs.