5. Per-Hop Behavior Standardization Guidelines (Directives de standardisation des comportements par saut)

Les caractéristiques comportementales (behavioral characteristics) des PHB devraient être standardisées, et non les algorithmes ou mécanismes spécifiques utilisés pour les implémenter. Un nœud peut avoir un ensemble (éventuellement grand) de paramètres qui peuvent être utilisés pour contrôler comment les paquets sont planifiés sur les interfaces de sortie (par exemple, N files d'attente distinctes avec des priorités configurables, des longueurs de file d'attente, des poids de tour de rôle, des algorithmes d'abandon, des poids et seuils de priorité d'abandon). Pour illustrer la différence entre les PHB et les mécanismes, nous soulignons qu'un PHB conforme au sélecteur de classe peut être implémenté par plusieurs mécanismes, seuls ou en combinaison, notamment la mise en file d'attente prioritaire stricte, WFQ, WRR ou des variantes [HPFQA, RPS, DRR], ou CBQ [CBQ].

Les PHB peuvent être spécifiés individuellement ou en groupe (group). Un groupe PHB se compose généralement d'un ensemble de deux ou plusieurs PHB qui ne peuvent être spécifiés et implémentés de manière significative que simultanément, en raison d'une contrainte commune (common constraint) qui s'applique à chaque PHB du groupe, comme le service de file d'attente ou la politique de gestion de file d'attente. Une spécification de groupe PHB devrait (SHOULD) décrire les conditions dans lesquelles un paquet peut être re-marqué pour sélectionner un autre PHB dans le groupe. Il est recommandé (RECOMMENDED) que les implémentations PHB n'introduisent pas de réordonnancement de paquets au sein d'un microflux (microflow). Les spécifications de groupe PHB doivent (MUST) identifier les implications de réordonnancement de paquets (packet re-ordering implications) qui peuvent se produire pour chaque PHB individuel, et celles qui peuvent se produire si différents paquets au sein d'un microflux sont marqués pour différents PHB au sein du groupe.

Seuls les comportements par saut qui ne sont pas décrits par les normes PHB existantes et qui ont été implémentés, déployés et se sont révélés utiles devraient (SHOULD) être standardisés. Étant donné que l'expérience actuelle avec les services différenciés est assez limitée, il serait prématuré de supposer des spécifications précises pour ces comportements par saut.

Chaque PHB standardisé doit (MUST) avoir un point de code recommandé (RECOMMENDED) qui lui est associé, attribué à partir de l'espace de 32 points de code (voir Section 6). L'espace de points de code est intentionnellement clairsemé (intentionally sparse) dans l'espace défini ('xxx000'), car cette spécification laisse de la place dans l'espace de points de code pour l'évolution.

Les fournisseurs d'équipement réseau sont libres de fournir les paramètres et fonctionnalités qu'ils jugent utiles ou commercialisables. Si un PHB standardisé particulier est implémenté dans un nœud, le fournisseur peut (MAY) utiliser n'importe quel algorithme qui satisfait la définition du PHB conformément à la norme. Les capacités d'un nœud et sa configuration particulière déterminent les différentes façons dont il peut traiter les paquets.

Les fournisseurs de services n'ont pas besoin d'utiliser les mêmes mécanismes ou configurations de nœud pour permettre la différenciation de service dans leur réseau, et sont libres de configurer les paramètres de nœud de la manière qui convient à leurs objectifs de fourniture de services et d'ingénierie du trafic. Au fil du temps, certains comportements par saut communs particuliers peuvent évoluer (c'est-à-dire ceux qui sont particulièrement utiles pour implémenter des services de bout en bout) et ceux-ci peuvent (MAY) être associés à des points de code PHB EXP/LU particuliers du champ DS pour une utilisation à travers les limites de domaine (voir Section 6). Ces PHB sont des candidats pour une standardisation future.

Il est recommandé (RECOMMENDED) que les PHB standardisés soient spécifiés conformément aux directives présentées dans [ARCH].