5. Per-Hop Behavior Standardization Guidelines (Richtlinien zur Standardisierung von Per-Hop-Verhalten)

Die Verhaltensmerkmale (behavioral characteristics) von PHBs sollten standardisiert werden, nicht die spezifischen Algorithmen oder Mechanismen, die zu ihrer Implementierung verwendet werden. Ein Knoten kann eine (möglicherweise große) Menge von Parametern haben, die zur Steuerung verwendet werden können, wie Pakete auf Ausgangsschnittstellen geplant werden (z.B. N getrennte Warteschlangen mit konfigurierbaren Prioritäten, Warteschlangenlängen, Round-Robin-Gewichten, Drop-Algorithmen, Drop-Prioritäts-Gewichten und -Schwellenwerten). Um den Unterschied zwischen PHBs und Mechanismen zu veranschaulichen, weisen wir darauf hin, dass ein Class Selector Compliant PHB durch mehrere Mechanismen, allein oder in Kombination, implementiert werden kann, einschließlich Strict Priority Queuing, WFQ, WRR oder Varianten [HPFQA, RPS, DRR] oder CBQ [CBQ].

PHBs können einzeln oder in Gruppen (group) spezifiziert werden. Eine PHB-Gruppe besteht typischerweise aus einer Reihe von zwei oder mehr PHBs, die aufgrund einer gemeinsamen Einschränkung (common constraint), die für jedes PHB in der Gruppe gilt, wie z.B. Warteschlangen-Service oder Warteschlangen-Management-Richtlinie, nur gleichzeitig sinnvoll spezifiziert und implementiert werden können. Eine PHB-Gruppenspezifikation sollte (SHOULD) die Bedingungen beschreiben, unter denen ein Paket neu markiert werden kann, um ein anderes PHB innerhalb der Gruppe auszuwählen. Es wird empfohlen (RECOMMENDED), dass PHB-Implementierungen keine Paketumsortierung innerhalb eines Mikroflusses (microflow) einführen. PHB-Gruppenspezifikationen müssen (MUST) die Auswirkungen der Paketumsortierung (packet re-ordering implications) identifizieren, die für jedes einzelne PHB auftreten können, und diejenigen, die auftreten können, wenn verschiedene Pakete innerhalb eines Mikroflusses für verschiedene PHBs innerhalb der Gruppe markiert sind.

Nur Per-Hop-Verhalten, die nicht durch bestehende PHB-Standards beschrieben werden und die implementiert, bereitgestellt und als nützlich erwiesen wurden, sollten (SHOULD) standardisiert werden. Da die derzeitige Erfahrung mit differenzierten Diensten ziemlich begrenzt ist, wäre es verfrüht, präzise Spezifikationen für diese Per-Hop-Verhalten anzunehmen.

Jedes standardisierte PHB muss (MUST) einen empfohlenen (RECOMMENDED) Codepunkt haben, der ihm zugeordnet ist und aus dem Raum von 32 Codepunkten zugewiesen wird (siehe Abschnitt 6). Der Codepunkt-Raum ist im definierten Raum ('xxx000') absichtlich spärlich (intentionally sparse), da diese Spezifikation Raum im Codepunkt-Raum für die Entwicklung lässt.

Netzwerkgeräte-Anbieter sind frei, die Parameter und Funktionen bereitzustellen, die sie für nützlich oder vermarktbar halten. Wenn ein bestimmtes standardisiertes PHB in einem Knoten implementiert ist, kann (MAY) der Anbieter jeden Algorithmus verwenden, der die Definition des PHB gemäß dem Standard erfüllt. Die Fähigkeiten eines Knotens und seine besondere Konfiguration bestimmen die verschiedenen Möglichkeiten, wie er Pakete behandeln kann.

Dienstanbieter müssen nicht dieselben Knotenmechanismen oder -konfigurationen verwenden, um Dienstdifferenzierung in ihrem Netzwerk zu ermöglichen, und sind frei, Knotenparameter auf eine Weise zu konfigurieren, die ihren Dienstbereitstellungs- und Traffic-Engineering-Zielen entspricht. Im Laufe der Zeit können bestimmte gemeinsame Per-Hop-Verhalten evolvieren (d.h. solche, die besonders nützlich für die Implementierung von End-to-End-Diensten sind), und diese können (MAY) mit bestimmten EXP/LU-PHB-Codepunkten des DS-Feldes für die Verwendung über Domänengrenzen hinweg verknüpft werden (siehe Abschnitt 6). Diese PHBs sind Kandidaten für zukünftige Standardisierung.

Es wird empfohlen (RECOMMENDED), dass standardisierte PHBs gemäß den in [ARCH] dargestellten Richtlinien spezifiziert werden.