4. Historical Codepoint Definitions and PHB Requirements (Définitions historiques des points de code et exigences PHB)
Le champ DS a 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 qui satisfont les exigences de mise en file d'attente IPv4 Precedence spécifiées dans [RFC1812]) et nous souhaitons permettre leur utilisation continue dans les nœuds conformes DS. De plus, il existe plusieurs points de code correspondant à l'utilisation historique du champ IP Precedence, et nous réservons ces points de code pour être mappés à des PHB qui satisfont les exigences générales spécifiées à la Section 4.2.2.2. Cependant, les PHB de services différenciés spécifiques auxquels ces points de code sont mappés peuvent (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 définis dans [RFC791].
4.1 A Default PHB (Un PHB par défaut)
Un PHB "par défaut" (default) doit (MUST) être disponible dans un nœud conforme DS; c'est le comportement de transmission au mieux (best-effort forwarding behavior) couramment disponible dans les routeurs existants standardisés dans [RFC1812]. En l'absence d'autres accords, on suppose que les paquets appartiennent à cet agrégat. De tels paquets peuvent (MAY) être soumis au 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 est une discipline de mise en file d'attente qui transmet des paquets de cet agrégat lorsque la liaison de sortie n'est pas requise pour satisfaire un autre PHB. Une politique raisonnable pour la construction de services est de s'assurer que l'agrégat ne soit pas "affamé" (starved), ce qui pourrait être mis en œuvre par un mécanisme dans chaque nœud qui réserve des ressources minimales (par exemple, tampons, bande passante) pour l'agrégat de comportement par défaut. Cela permet aux expéditeurs inconscients des services différenciés de continuer à utiliser le réseau comme ils le font aujourd'hui. Les implications de l'introduction de services différenciés dans un domaine sur les attentes de service des clients et des pairs sont une question complexe impliquant des décisions politiques par le domaine et sont hors du champ d'application de ce document.
Le point de code recommandé (RECOMMENDED) pour le PHB par défaut est le motif de bits '000000'; la valeur '000000' doit (MUST) être mappée à un PHB qui satisfait ces spécifications. Le point de code choisi pour le comportement par défaut est compatible avec la pratique existante [RFC791]. Si un point de code n'est pas mappé à un PHB de standardisation ou d'utilisation locale, il devrait (SHOULD) être mappé au PHB par défaut.
Les paquets marqués initialement pour le comportement par défaut peuvent (MAY) être re-marqués avec un autre point de code lorsqu'ils traversent une limite dans un domaine DS et peuvent être transférés avec un PHB différent dans ce domaine, sous réserve d'un certain accord négocié entre domaines pairs.
4.2 Once and Future IP Precedence Field Use (Utilisation passée et future du champ IP Precedence)
Nous souhaitons maintenir une certaine forme de compatibilité ascendante avec l'utilisation actuelle du champ IP Precedence (bits 0-2 de l'octet TOS IPv4). Il existe des routeurs qui utilisent le champ IP Precedence pour sélectionner différents traitements de transmission par saut de manière similaire à celle proposée ici pour le champ DSCP. Par conséquent, en configurant correctement ces routeurs, une architecture de services différenciés prototype simple peut être déployée rapidement. De plus, comme les systèmes IP d'aujourd'hui comprennent la position du champ IP Precedence, il y a moins de chances qu'il y ait des échecs catastrophiques lors du déploiement initial si ces bits sont utilisés de manière similaire lorsque l'équipement conforme DS est déployé. 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 inclusive à l'utilisation déployée du champ IP Precedence.
4.2.1 IP Precedence History and Evolution in Brief (Histoire et évolution de IP Precedence en bref)
Le champ IP Precedence est, pour ainsi dire, le précurseur du champ DS. IP Precedence et le champ IP Precedence ont été définis pour la première fois dans [RFC791]. Les valeurs que le champ IP Precedence de 3 bits peut prendre ont été affectées à divers usages, notamment 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 du "trafic de routine". Dans [RFC791], la notion de Precedence était définie de manière générale comme "Une mesure indépendante de l'importance de ce datagramme". Toutes les valeurs du champ IP Precedence n'étaient pas censées avoir une signification à travers les limites. Par exemple, "La désignation de priorité de contrôle réseau (Network Control) est destinée à être utilisée uniquement dans un réseau. L'utilisation réelle et le contrôle de cette désignation dépendent de chaque réseau." [RFC791]
Les premiers IMP BBN implémentaient la fonctionnalité Precedence, mais les premiers routeurs commerciaux et le code de transmission IP UNIX ne l'implémentaient généralement pas. À 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 (priority queueing). Celles-ci étaient généralement basées sur des politiques codées dans des filtres dans le routeur qui examinaient les adresses IP, les numéros de protocole IP, les ports TCP ou UDP et d'autres champs d'en-tête. IP Precedence était l'une des options que ces filtres pouvaient examiner.
En résumé, IP Precedence n'est pas largement déployé et largement utilisé, sinon comme prévu dans [RFC791]. Cela a été reconnu dans [RFC1122], qui a déclaré que l'utilisation du champ IP Precedence était valide, mais que les affectations de priorité spécifiques de [RFC791] étaient simplement historiques.
4.2.2 Subsuming IP Precedence into Class Selector Codepoints (Subsomption de IP Precedence dans les points de code sélecteurs de classe)
Une spécification du traitement de transmission de paquets sélectionné aujourd'hui par le champ IP Precedence devrait être assez générale; peut-être pas assez spécifique pour construire des services prévisibles dans le cadre des services différenciés. Pour maintenir une compatibilité ascendante partielle avec l'utilisation actuelle connue du champ IP Precedence sans sacrifier la flexibilité future, nous avons adopté une approche qui décrit les exigences minimales pour un ensemble de PHB compatibles avec la plupart des traitements de transmission déployés sélectionnés par le champ IP Precedence. De plus, nous fournissons un ensemble de points de code qui doivent (MUST) être mappés à des PHB qui satisfont ces exigences minimales. Les PHB auxquels ces points de code sont mappés peuvent (MAY) avoir une liste de spécifications plus détaillées en plus de celles minimales énoncées ici. D'autres points de code peuvent (MAY) être mappés aux mêmes PHB que ceux-ci. Nous appelons cet ensemble de points de code les points de code sélecteurs de classe (Class Selector Codepoints) et nous appelons les exigences minimales pour les PHB auxquels ces points de code peuvent être mappés les exigences de PHB sélecteur de classe (Class Selector PHB Requirements).
4.2.2.1 The Class Selector Codepoints (Les points de code sélecteurs de classe)
Les valeurs du champ DS 'xxx000|xx', ou DSCP = 'xxx000' avec le sous-champ CU non spécifié, sont réservées comme l'ensemble des points de code sélecteurs de classe. Les PHB auxquels ces points de code sont mappés doivent (MUST) satisfaire les exigences de PHB sélecteur de classe en plus de conserver les exigences de PHB par défaut (Section 4.1) pour le point de code '000000'.
4.2.2.2 The Class Selector PHB Requirements (Les exigences de PHB sélecteur de classe)
Un point de code sélecteur de classe avec une valeur numérique plus grande qu'un autre point de code sélecteur de classe est dit avoir un ordre relatif supérieur (higher relative order) et un point de code sélecteur de classe avec une valeur numérique plus petite qu'un autre point de code sélecteur de classe est dit avoir un ordre relatif inférieur (lower relative order). L'ensemble des PHB auxquels les huit points de code sélecteurs de classe sont mappés doit (MUST) produire au moins deux classes de trafic transférées indépendamment, et le PHB sélectionné par un point de code sélecteur de classe devrait (SHOULD) donner à un paquet une probabilité de transmission opportune (probability of timely forwarding) non inférieure à celle donnée aux paquets marqués avec un point de code sélecteur de classe d'ordre relatif inférieur, dans des conditions de fonctionnement et des charges de trafic raisonnables. Un paquet abandonné est considéré comme un cas extrême de transmission inopportune (extreme case of untimely forwarding). De plus, le PHB sélectionné par les points de code '11x000' doit (MUST) donner à un paquet un traitement de transmission préférentiel (preferential forwarding treatment) par rapport au PHB sélectionné par le point de code '000000' afin de préserver l'utilisation courante des valeurs IP Precedence '110' et '111' pour le trafic de routage.
De plus, les PHB sélectionnés par différents points de code sélecteurs de classe devraient (SHOULD) être transférés indépendamment; c'est-à-dire que les paquets marqués avec différents points de code sélecteurs de classe peuvent (MAY) être réordonnés. Un nœud réseau peut (MAY) imposer des limites à la quantité de ressources du nœud disponibles pour chacun de ces PHB.
Un groupe PHB avec une spécification qui satisfait cette exigence est appelé PHB conformes au sélecteur de classe (Class Selector Compliant PHBs).
Les exigences de PHB sélecteur de classe pour le point de code '000000' sont compatibles avec celles listées pour le PHB par défaut à la Section 4.1.
4.2.2.3 Using the Class Selector PHB Requirements for IP Precedence Compatibility (Utilisation des exigences de PHB sélecteur de classe pour la compatibilité IP Precedence)
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 stipule que l'ensemble de points de code 'xxx000' doit (MUST) être mappé à un tel ensemble de PHB. Étant donné qu'il est également permis de mapper plusieurs points de code au même PHB, un fournisseur ou un administrateur réseau peut (MAY) configurer un nœud réseau pour mapper des points de code au PHB indépendamment des bits 3-5 du champ DSCP, produisant un réseau compatible avec l'utilisation historique de IP Precedence. Ainsi, par exemple, le point de code '011010' serait mappé au même PHB que le point de code '011000'.
4.2.2.4 Example Mechanisms for Implementing Class Selector Compliant PHB Groups (Exemples de mécanismes pour implémenter des groupes PHB conformes au sélecteur de classe)
Un PHB conforme au sélecteur de classe peut être réalisé par divers mécanismes, notamment la mise en file d'attente prioritaire stricte (strict priority queueing), la mise en file d'attente équitable pondérée (weighted fair queueing, WFQ), WRR ou des variantes [RPS, HPFQA, DRR], ou la mise en file d'attente basée sur les classes (Class-Based Queuing) [CBQ]. La différence entre les PHB et les mécanismes est décrite plus en détail à la Section 5.
Il est important de noter que ces mécanismes pourraient être disponibles via d'autres PHB (standardisés ou non) disponibles dans un équipement de fournisseur particulier. Par exemple, un document futur pourrait standardiser un groupe PHB de mise en file d'attente prioritaire stricte (Strict Priority Queueing PHB Group) pour un ensemble de points de code recommandés. Un administrateur réseau peut configurer ces routeurs pour sélectionner le PHB de mise en file d'attente prioritaire stricte avec les points de code 'xxx000', conformément aux exigences de ce document.
Comme autre exemple, un autre fournisseur pourrait adopter le mécanisme CBQ sur un routeur. Le mécanisme CBQ peut être utilisé pour implémenter un ensemble de PHB conformes au sélecteur de classe qui ont une gamme de capacités plus large que celle disponible avec un ensemble de PHB qui satisfait uniquement les exigences minimales de PHB sélecteur de classe, en plus d'implémenter un PHB de mise en file d'attente prioritaire stricte.
4.3 Summary (Résumé)
Ce document définit les points de code 'xxx000' comme points de code sélecteurs de classe. Les PHB sélectionnés par ces points de code doivent (MUST) satisfaire les exigences de PHB sélecteur de classe décrites à la Section 4.2.2.2. Cela a été fait pour maintenir un niveau utile de compatibilité ascendante avec l'utilisation actuelle du champ IP Precedence sur Internet sans restreindre indûment la flexibilité future. De plus, le point de code '000000' est utilisé comme valeur de PHB par défaut d'Internet et n'est donc pas configurable. Les sept autres points de code sélecteurs de classe non nuls ne sont configurables que dans la mesure où ils sont mappés à des PHB qui satisfont les exigences de la Section 4.2.2.2.