5. Richtlinien zur Standardisierung von Per-Hop-Verhaltensweisen (Per-Hop Behavior Standardization Guidelines)
Die Verhaltensmerkmale eines PHB sollen standardisiert werden, nicht die speziellen Algorithmen oder Mechanismen, die zu ihrer Implementierung verwendet werden. Ein Knoten kann eine (möglicherweise große) Menge von Parametern haben, die verwendet werden können, um zu steuern, wie Pakete auf eine Ausgangsschnittstelle geplant werden (z.B. N separate Warteschlangen mit einstellbaren Prioritäten, Warteschlangenlängen, Round-Robin-Gewichten, Drop-Algorithmus, Drop-Präferenzgewichten und Schwellenwerten usw.). Um die Unterscheidung zwischen einem PHB und einem Mechanismus zu veranschaulichen, weisen wir darauf hin, dass Class Selector Compliant PHBs durch mehrere Mechanismen implementiert werden könnten, einschließlich: Strict Priority Queueing, WFQ, WRR oder Varianten [HPFQA, RPS, DRR] oder CBQ [CBQ], isoliert oder in Kombination.
PHBs können einzeln oder als Gruppe spezifiziert werden (ein einzelnes PHB ist ein Spezialfall einer PHB-Gruppe). Eine PHB-Gruppe besteht normalerweise aus einer Menge von zwei oder mehr PHBs, die aufgrund einer gemeinsamen Einschränkung, die auf jedes PHB innerhalb der Gruppe anwendbar ist, wie z.B. eine Warteschlangen-Service- oder Warteschlangenverwaltungsrichtlinie, nur sinnvoll gleichzeitig spezifiziert und implementiert werden können. Eine PHB-Gruppenspezifikation sollte (SHOULD) Bedingungen beschreiben, unter denen ein Paket neu markiert werden könnte, um ein anderes PHB innerhalb der Gruppe auszuwählen. Es wird empfohlen (RECOMMENDED), dass PHB-Implementierungen keine Paket-Neuordnung innerhalb eines Microflows einführen. PHB-Gruppenspezifikationen müssen (MUST) alle möglichen Paket-Neuordnungsauswirkungen identifizieren, die für jedes einzelne PHB auftreten können, und die auftreten können, wenn verschiedene Pakete innerhalb eines Microflows für verschiedene PHBs innerhalb der Gruppe markiert sind.
Nur diejenigen Per-Hop-Verhaltensweisen, die nicht durch einen bestehenden PHB-Standard beschrieben werden und die implementiert, eingesetzt und als nützlich erwiesen wurden, sollten (SHOULD) standardisiert werden. Da die aktuelle Erfahrung mit Differentiated Services recht begrenzt ist, ist es verfrüht, die genaue Spezifikation dieser Per-Hop-Verhaltensweisen zu hypothetisieren.
Jedes standardisierte PHB muss (MUST) einen zugehörigen empfohlenen (RECOMMENDED) Codepoint haben, der aus einem Raum von 32 Codepoints zugewiesen wird (siehe Abschnitt 6). Diese Spezifikation hat im Codepoint-Raum Platz gelassen, um Evolution zu ermöglichen, daher ist der definierte Raum (xxx000) absichtlich spärlich.
Netzwerkausrüstungsanbieter sind frei, beliebige Parameter und Fähigkeiten anzubieten, die als nützlich oder vermarktbar erachtet werden. Wenn ein bestimmtes, standardisiertes PHB in einem Knoten implementiert wird, kann (MAY) ein Anbieter jeden Algorithmus verwenden, der die Definition des PHB gemäß dem Standard erfüllt. Die Fähigkeiten des Knotens und seine spezielle Konfiguration bestimmen die verschiedenen Wege, wie Pakete behandelt werden können.
Dienstanbieter sind nicht verpflichtet, dieselben Knotenmechanismen oder Konfigurationen zu verwenden, um Dienstdifferenzierung innerhalb ihrer Netzwerke zu ermöglichen, und sind frei, die Knotenparameter auf jede Weise zu konfigurieren, die für ihre Dienstangebote und Verkehrstechnikziele geeignet ist. Im Laufe der Zeit werden sich wahrscheinlich bestimmte gemeinsame Per-Hop-Verhaltensweisen entwickeln (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-Codepoints im DS-Feld assoziiert werden, was die Verwendung über Domaingrenzen hinweg ermöglicht (siehe Abschnitt 6). Diese PHBs sind Kandidaten für zukünftige Standardisierung.
Es wird empfohlen (RECOMMENDED), dass standardisierte PHBs gemäß den in [ARCH] festgelegten Richtlinien spezifiziert werden.