1. Introduction

Les Services Différenciés (Differentiated Services) visent à fournir un cadre et des éléments constitutifs pour permettre le déploiement d'une discrimination de service évolutive (scalable service discrimination) sur Internet. L'approche des services différenciés cherche à accélérer le déploiement en séparant l'architecture en deux composants principaux, dont l'un est assez bien compris et l'autre commence tout juste à être compris. À cet égard, elle s'inspire de la conception originale d'Internet qui a séparé les composants de transmission (forwarding) et de routage (routing). La transmission de paquets (packet forwarding) est une tâche relativement simple qui doit être effectuée aussi rapidement que possible paquet par paquet. La transmission utilise l'en-tête de paquet pour trouver une entrée dans une table de routage, qui détermine l'interface de sortie du paquet. Le routage définit les entrées dans cette table et doit refléter divers choix d'acheminement et autres politiques, et peut également devoir suivre les pannes de route. La table de routage est maintenue comme un processus en arrière-plan de la tâche de transmission. De plus, le routage est une tâche plus complexe et a continué d'évoluer au cours des vingt dernières années.

De même, l'architecture des services différenciés comprend deux composants principaux: un comportement assez bien compris dans le chemin de transmission (forwarding path) et un composant de politique et d'allocation (allocation) en arrière-plan plus complexe et encore en développement qui configure les paramètres utilisés dans le chemin de transmission. Le comportement du chemin de transmission comprend le traitement différentiel (differential treatment) que subissent les paquets individuels, implémenté par des disciplines de service de file d'attente (queue service disciplines) et/ou des disciplines de gestion de file d'attente (queue management disciplines). Ces comportements par saut (per-hop behaviors) sont utiles et nécessaires sur les nœuds réseau pour fournir un traitement différencié des paquets, indépendamment de la manière dont les services de bout en bout ou intra-domaine sont construits. Nous nous concentrons sur la sémantique générale (general semantics) des comportements plutôt que sur les mécanismes spécifiques utilisés pour les implémenter, car ces comportements sont susceptibles d'évoluer moins rapidement que les mécanismes.

Les comportements par saut et les mécanismes pour les sélectionner paquet par paquet peuvent être déployés dans les nœuds réseau aujourd'hui, et c'est cet aspect de l'architecture des services différenciés qui est abordé en premier. De plus, dans le chemin de transmission, il peut être nécessaire d'effectuer une surveillance (monitoring), un contrôle (policing) et une mise en forme (shaping) sur le trafic réseau désigné pour un traitement "spécial" afin d'appliquer les exigences associées à la fourniture d'un traitement spécial. Les mécanismes de ce type de conditionnement de trafic (traffic conditioning) sont également assez bien compris. Le déploiement généralisé de tels conditionneurs de trafic est également important pour permettre la construction de services, mais leur utilisation réelle dans la construction de services peut évoluer dans le temps.

La configuration des éléments réseau quant aux paquets qui reçoivent un traitement spécial et aux types de règles à appliquer à l'utilisation des ressources est beaucoup moins bien comprise. Néanmoins, il est possible de déployer des services différenciés utiles dans un réseau en utilisant des politiques simples et une configuration statique. Comme décrit dans [ARCH], il existe de nombreuses façons de configurer les comportements par saut et les conditionneurs de trafic pour créer des services. Ce processus fournira une expérience supplémentaire pour guider les politiques et l'allocation plus complexes. Les comportements de base du chemin de transmission peuvent rester les mêmes pendant que ce composant de l'architecture évolue. Comme l'expérience de la construction de tels services se poursuivra pendant un certain temps, nous évitons de standardiser cette construction car elle serait prématurée. De plus, nous évitons beaucoup des détails de la construction de services car ils sont couverts par des contrats juridiques entre différentes entités, ce qui est hors du champ d'application de l'IETF.

Ce document se concentre sur le composant du chemin de transmission. Dans le chemin de transmission de paquets, les services différenciés sont réalisés en mappant un point de code (codepoint) contenu dans un champ de l'en-tête de paquet IP à un traitement de transmission particulier (forwarding treatment), ou comportement par saut (per-hop behavior, PHB), à chaque nœud réseau le long de son chemin. Le point de code peut être l'un d'un ensemble de valeurs obligatoires (mandatory values) définies dans ce document, l'un d'un ensemble de valeurs recommandées (recommended values) à définir dans des documents futurs, ou il peut avoir une signification purement locale. Il est prévu que le PHB soit mis en œuvre en employant diverses disciplines de service de file d'attente et/ou de gestion de file d'attente sur les interfaces de sortie des nœuds réseau: par exemple, le service de file d'attente à tour de rôle pondéré (weighted round-robin, WRR) ou la gestion de file d'attente avec priorité d'abandon (drop-preference).

Le marquage (marking) est effectué par les conditionneurs de trafic aux limites du réseau (first-hop router ou source host), y compris les limites administratives. Les conditionneurs de trafic peuvent inclure des primitives de marquage, de mesure (metering), de contrôle et de mise en forme (ces mécanismes sont décrits dans [ARCH]). Les services sont réalisés par l'utilisation de mécanismes particuliers de classification de paquets et de conditionnement de trafic aux limites et par la concaténation (concatenation) de comportements par saut le long du chemin de transit du trafic. L'objectif de l'architecture des services différenciés est de spécifier ces éléments constitutifs pour l'extensibilité future, à la fois dans le nombre et les types de composants ainsi que dans les services construits à partir de ceux-ci.

La terminologie utilisée dans ce mémo est définie à la Section 2. La définition du champ de services différenciés (DS field) est présentée à la Section 3. La Section 4 traite du désir d'une compatibilité ascendante partielle avec l'utilisation actuelle du champ IPv4 Precedence; la solution introduit des points de code sélecteurs de classe (Class Selector Codepoints) et un comportement par saut conforme au sélecteur de classe (Class Selector Compliant PHB). La Section 5 présente des directives pour la standardisation des comportements par saut. La Section 6 traite des directives pour l'attribution des points de code. La Section 7 traite des considérations de sécurité.

Ce document est une description concise du champ DS et de son utilisation. Il est destiné à être lu en conjonction avec l'architecture des services différenciés [ARCH].

Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" doivent être interprétés comme décrit dans [RFC2119].