4. Définitions historiques des points de code et exigences PHB (Historical Codepoint Definitions and PHB Requirements)

Le champ DS aura une compatibilité ascendante limitée avec la pratique actuelle, comme décrit dans cette section. La compatibilité ascendante est abordée de deux manières. Premièrement, il existe des comportements par saut déjà largement utilisés (par exemple, ceux satisfaisant les exigences de mise en file d'attente de priorité IPv4 spécifiées dans [RFC1812]), et nous souhaitons permettre leur utilisation continue dans les nœuds conformes DS. De plus, il existe certains points de code qui correspondent à l'utilisation historique du champ de priorité IP et nous réservons ces points de code pour mapper vers des PHB qui répondent aux exigences générales spécifiées dans la Sec. 4.2.2.2, bien que les PHB de services différenciés spécifiques mappés par ces points de code puissent (MAY) avoir des spécifications supplémentaires.

Aucune tentative n'est faite pour maintenir la compatibilité ascendante avec les bits « DTR » ou TOS de l'octet TOS IPv4, comme défini dans [RFC791].

4.1 Un PHB par défaut (A Default PHB)

Un PHB « par défaut » doit (MUST) être disponible dans un nœud conforme DS. Il s'agit du comportement de transmission au mieux (best-effort) courant disponible dans les routeurs existants tel que standardisé dans [RFC1812]. Lorsqu'aucun autre accord n'est en place, il est supposé que les paquets appartiennent à cet agrégat. De tels paquets peuvent (MAY) être envoyés dans un réseau sans respecter de règles particulières et le réseau livrera autant de ces paquets que possible et aussi rapidement que possible, sous réserve d'autres contraintes de politique de ressources. Une implémentation raisonnable de ce PHB serait une discipline de mise en file d'attente qui envoie les paquets de cet agrégat chaque fois que le lien de sortie n'est pas requis pour satisfaire un autre PHB. Une politique raisonnable pour construire des services garantirait que l'agrégat ne soit pas « affamé ». Cela pourrait être imposé par un mécanisme dans chaque nœud qui réserve des ressources minimales (par exemple, tampons, bande passante) pour les agrégats de comportement par défaut. Cela permet aux expéditeurs qui ne sont pas conscients des services différenciés de continuer à utiliser le réseau de la même manière qu'aujourd'hui. L'impact de l'introduction de services différenciés dans un domaine sur les attentes de service de ses clients et pairs est une question complexe impliquant des décisions politiques du domaine et est en dehors du champ d'application de ce document. Le point de code recommandé (RECOMMENDED) pour le PHB par défaut est le motif binaire 000000 ; la valeur 000000 doit (MUST) mapper vers un PHB qui répond à ces spécifications. Le point de code choisi pour le comportement par défaut est compatible avec la pratique existante [RFC791]. Lorsqu'un point de code n'est pas mappé vers un PHB standardisé ou d'utilisation locale, il devrait (SHOULD) être mappé vers le PHB par défaut.

Un paquet initialement marqué pour le comportement par défaut peut (MAY) être remarqué avec un autre point de code lorsqu'il passe une limite dans un domaine DS afin qu'il soit transmis en utilisant un PHB différent dans ce domaine, éventuellement sous réserve d'un accord négocié entre les domaines pairs.

4.2 Utilisation passée et future du champ de priorité IP (Once and Future IP Precedence Field Use)

Nous souhaitons maintenir une certaine forme de compatibilité ascendante avec les utilisations actuelles du champ de priorité IP : bits 0-2 de l'octet TOS IPv4. Il existe des routeurs qui utilisent le champ de priorité IP pour sélectionner différents traitements de transmission par saut d'une manière similaire à l'utilisation proposée ici pour le champ DSCP. Ainsi, une architecture de services différenciés prototype simple peut être rapidement déployée en configurant de manière appropriée ces routeurs. De plus, les systèmes IP comprennent aujourd'hui l'emplacement du champ de priorité IP, et donc si ces bits sont utilisés de manière similaire lorsque l'équipement conforme DS est déployé, des défaillances importantes ne sont pas probables pendant le déploiement précoce. En d'autres termes, la conformité DS stricte n'a pas besoin d'être omniprésente même au sein du réseau d'un seul fournisseur de services si les bits 0-2 du champ DSCP sont utilisés d'une manière similaire à, ou englobant, les utilisations déployées du champ de priorité IP.

4.2.1 Historique et évolution brève de la priorité IP

Le champ de priorité IP est en quelque sorte un précurseur du champ DS. La priorité IP et le champ de priorité IP ont été définis pour la première fois dans [RFC791]. Les valeurs que le champ de priorité IP à trois bits pourrait prendre ont été attribuées à diverses utilisations, y compris le trafic de contrôle réseau, le trafic de routage et divers niveaux de privilège. Le niveau de privilège le plus bas était considéré comme « trafic de routine ». Dans [RFC791], la notion de priorité était définie largement comme « Une mesure indépendante de l'importance de ce datagramme ». Toutes les valeurs du champ de priorité IP n'étaient pas supposées avoir une signification au-delà des limites, par exemple « La désignation de priorité de contrôle réseau est destinée à être utilisée uniquement au sein d'un réseau. L'utilisation et le contrôle réels de cette désignation dépendent de chaque réseau. » [RFC791]

Bien que les premiers BBN IMP aient implémenté la fonctionnalité de priorité, les premiers routeurs commerciaux et le code de transmission IP UNIX ne l'ont généralement pas fait. À mesure que les réseaux devenaient plus complexes et que les exigences des clients augmentaient, les fournisseurs de routeurs commerciaux ont développé des moyens d'implémenter divers types de services de mise en file d'attente, y compris la mise en file d'attente prioritaire, qui étaient généralement basés sur des politiques codées dans des filtres dans les routeurs, qui examinaient les adresses IP, les numéros de protocole IP, les ports TCP ou UDP et d'autres champs d'en-tête. La priorité IP était et est parmi les options que ces filtres peuvent examiner.

En bref, la priorité IP est largement déployée et largement utilisée, sinon exactement de la manière prévue dans [RFC791]. Cela a été reconnu dans [RFC1122], qui indique que bien que l'utilisation du champ de priorité IP soit valide, l'affectation spécifique des priorités dans [RFC791] était simplement historique.

4.2.2 Subsomption de la priorité IP dans les points de code de sélecteur de classe

Une spécification des traitements de transmission de paquets sélectionnés par le champ de priorité IP aujourd'hui devrait être assez générale ; probablement pas assez spécifique pour construire des services prévisibles dans le cadre des services différenciés. Pour préserver une compatibilité ascendante partielle avec les utilisations actuelles connues du champ de priorité IP sans sacrifier la flexibilité future, nous avons adopté l'approche de décrire les exigences minimales sur un ensemble de PHB qui sont compatibles avec la plupart des traitements de transmission déployés sélectionnés par le champ de priorité IP. De plus, nous donnons un ensemble de points de code qui doivent (MUST) mapper vers des PHB répondant à ces exigences minimales. Les PHB mappés par ces points de code peuvent (MAY) avoir une liste de spécifications plus détaillée en plus de celles requises énoncées ici. D'autres points de code peuvent (MAY) mapper vers ces mêmes PHB. Nous appelons cet ensemble de points de code les points de code de sélecteur de classe (Class Selector Codepoints), et les exigences minimales pour les PHB vers lesquels ces points de code peuvent mapper sont appelées les exigences PHB de sélecteur de classe (Class Selector PHB Requirements).

4.2.2.1 Les points de code de sélecteur de classe

Les valeurs de champ DS de xxx000|xx, ou DSCP = xxx000 et sous-champ CU non spécifié, sont réservées en tant qu'ensemble de points de code de sélecteur de classe. Les PHB mappés par ces points de code doivent (MUST) satisfaire les exigences PHB de sélecteur de classe en plus de préserver l'exigence PHB par défaut sur le point de code 000000 (Sec. 4.1).

4.2.2.2 Les exigences PHB de sélecteur de classe

Nous appelons un point de code de sélecteur de classe avec une valeur numérique plus grande qu'un autre point de code de sélecteur de classe comme ayant un ordre relatif supérieur, tandis qu'un point de code de sélecteur de classe avec une valeur numérique plus petite qu'un autre point de code de sélecteur de classe est dit avoir un ordre relatif inférieur. L'ensemble des PHB mappés par les huit points de code de sélecteur de classe doit (MUST) produire au moins deux classes de trafic transférées indépendamment, et les PHB sélectionnés par un point de code de sélecteur de classe devraient (SHOULD) donner aux paquets une probabilité de transmission opportune qui n'est pas inférieure à celle donnée aux paquets marqués avec un point de code de sélecteur de classe d'ordre relatif inférieur, dans des conditions de fonctionnement raisonnables et des charges de trafic. Un paquet rejeté est considéré comme un cas extrême de transmission intempestive. De plus, les PHB sélectionnés par les points de code 11x000 doivent (MUST) donner aux paquets un traitement de transmission préférentiel par comparaison au PHB sélectionné par le point de code 000000 pour préserver l'utilisation courante des valeurs de priorité IP 110 et 111 pour le trafic de routage.

De plus, les PHB sélectionnés par des points de code de sélecteur de classe distincts devraient (SHOULD) être transférés indépendamment ; c'est-à-dire que les paquets marqués avec différents points de code de sélecteur de classe peuvent (MAY) être réordonnés. Un nœud réseau peut (MAY) imposer des limites sur la quantité des ressources du nœud qui peuvent être utilisées par chacun de ces PHB.

Les groupes PHB dont la spécification satisfait ces exigences sont appelés PHB conformes au sélecteur de classe (Class Selector Compliant PHBs).

Les exigences PHB de sélecteur de classe sur le point de code 000000 sont compatibles avec celles listées pour le PHB par défaut dans la Sec. 4.1.

4.2.2.3 Utilisation des exigences PHB de sélecteur de classe pour la compatibilité de priorité IP

Un nœud réseau conforme DS peut être déployé avec un ensemble d'un ou plusieurs groupes PHB conformes au sélecteur de classe. Ce document indique que l'ensemble de points de code xxx000 doit (MUST) mapper vers un tel ensemble de PHB. Comme il est également possible de mapper plusieurs points de code vers le même PHB, le fournisseur ou l'administrateur réseau peut (MAY) configurer le nœud réseau pour mapper les points de code vers les PHB indépendamment des bits 3-5 du champ DSCP pour produire un réseau compatible avec l'utilisation historique de la priorité IP. Ainsi, par exemple, le point de code 011010 mapperait vers le même PHB que le point de code 011000.

4.2.2.4 Exemples de mécanismes pour implémenter des groupes PHB conformes au sélecteur de classe

Les PHB conformes au sélecteur de classe peuvent être réalisés par divers mécanismes, y compris la mise en file d'attente à priorité stricte, la mise en file d'attente équitable pondérée (WFQ), WRR, ou variants [RPS, HPFQA, DRR], ou la mise en file d'attente basée sur les classes [CBQ]. La distinction entre les PHB et les mécanismes est décrite plus en détail dans la Sec. 5.

Il est important de noter que ces mécanismes pourraient être disponibles via d'autres PHB (standardisés ou non) qui sont disponibles dans l'équipement d'un fournisseur particulier. Par exemple, des documents futurs peuvent standardiser un groupe PHB de mise en file d'attente à priorité stricte pour un ensemble de points de code recommandés. Un administrateur réseau pourrait configurer ces routeurs pour sélectionner les PHB de mise en file d'attente à priorité stricte avec des points de code xxx000 conformément aux exigences de ce document.

Comme autre exemple, un autre fournisseur pourrait utiliser un mécanisme CBQ dans ses routeurs. Le mécanisme CBQ pourrait être utilisé pour implémenter les PHB de mise en file d'attente à priorité stricte ainsi qu'un ensemble de PHB conformes au sélecteur de classe avec une gamme de fonctionnalités plus large que celle disponible dans un ensemble de PHB qui ne feraient que satisfaire les exigences minimales PHB de sélecteur de classe.

4.3 Résumé (Summary)

Ce document définit les points de code xxx000 comme les points de code de sélecteur de classe, où les PHB sélectionnés par ces points de code doivent (MUST) répondre aux exigences PHB de sélecteur de classe décrites dans la Sec. 4.2.2.2. Cela est fait pour préserver un niveau utile de compatibilité ascendante avec les utilisations actuelles du champ de priorité IP dans Internet sans limiter indûment la flexibilité future. De plus, le point de code 000000 est utilisé comme valeur PHB par défaut pour Internet et, en tant que tel, n'est pas configurable. Les sept points de code de sélecteur de classe non nuls restants ne sont configurables que dans la mesure où ils mappent vers des PHB qui répondent aux exigences de la Sec. 4.2.2.2.

---