5. Directives de normalisation des comportements par saut (Per-Hop Behavior Standardization Guidelines)
Les caractéristiques comportementales d'un PHB doivent être standardisées, et non les algorithmes particuliers ou les mécanismes utilisés pour les implémenter. Un nœud peut avoir un ensemble (éventuellement important) de paramètres qui peuvent être utilisés pour contrôler la manière dont les paquets sont planifiés sur une interface de sortie (par exemple, N files d'attente séparées avec des priorités définissables, des longueurs de file d'attente, des poids round-robin, un algorithme de rejet, des poids et seuils de préférence de rejet, etc.). Pour illustrer la distinction entre un PHB et un mécanisme, nous soulignons que les PHB conformes au sélecteur de classe peuvent être implémentés par plusieurs mécanismes, notamment : la mise en file d'attente à priorité stricte, WFQ, WRR ou leurs variantes [HPFQA, RPS, DRR], ou CBQ [CBQ], de manière isolée ou combinée.
Les PHB peuvent être spécifiés individuellement ou en tant que groupe (un PHB unique est un cas particulier d'un groupe PHB). Un groupe PHB se compose généralement d'un ensemble de deux PHB ou plus qui ne peuvent être spécifiés et implémentés de manière significative que simultanément, en raison d'une contrainte commune s'appliquant à chaque PHB du groupe, telle qu'une politique de service de file d'attente ou de gestion de file d'attente. Une spécification de groupe PHB devrait (SHOULD) décrire les conditions dans lesquelles un paquet pourrait être remarqué pour sélectionner un autre PHB au sein du groupe. Il est recommandé (RECOMMENDED) que les implémentations PHB n'introduisent aucune réorganisation de paquets au sein d'un microflux. Les spécifications de groupe PHB doivent (MUST) identifier toutes les implications possibles de réorganisation de paquets qui peuvent se produire pour chaque PHB individuel, et 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 une norme PHB existante, 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 est prématuré d'hypothéquer la spécification exacte de ces comportements par saut.
Chaque PHB standardisé doit (MUST) avoir un point de code recommandé (RECOMMENDED) associé, alloué dans un espace de 32 points de code (voir Sec. 6). Cette spécification a laissé de la place dans l'espace des points de code pour permettre l'évolution, donc l'espace défini (xxx000) est intentionnellement clairsemé.
Les fournisseurs d'équipements réseau sont libres d'offrir tous les paramètres et capacités jugés utiles ou commercialisables. Lorsqu'un PHB particulier standardisé est implémenté dans un nœud, un fournisseur peut (MAY) utiliser n'importe quel algorithme qui satisfait la définition du PHB selon la norme. Les capacités du nœud et sa configuration particulière déterminent les différentes façons dont les paquets peuvent être traités.
Les fournisseurs de services ne sont pas tenus d'utiliser les mêmes mécanismes ou configurations de nœud pour permettre la différenciation de service au sein de leurs réseaux, et sont libres de configurer les paramètres du nœud de la manière appropriée pour leurs offres de service et leurs objectifs d'ingénierie du trafic. Au fil du temps, certains comportements par saut communs sont susceptibles d'é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 dans le champ DS, permettant une utilisation au-delà des limites de domaine (voir Sec. 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 énoncées dans [ARCH].