4. Historische Codepoint-Definitionen und PHB-Anforderungen (Historical Codepoint Definitions and PHB Requirements)

Das DS-Feld wird eine begrenzte Rückwärtskompatibilität mit der aktuellen Praxis haben, wie in diesem Abschnitt beschrieben. Die Rückwärtskompatibilität wird auf zwei Arten angegangen. Erstens gibt es Per-Hop-Verhaltensweisen, die bereits weit verbreitet sind (z.B. solche, die die in [RFC1812] spezifizierten IPv4-Precedence-Queueing-Anforderungen erfüllen), und wir möchten deren fortgesetzte Verwendung in DS-konformen Knoten ermöglichen. Darüber hinaus gibt es einige Codepoints, die der historischen Verwendung des IP-Precedence-Felds entsprechen, und wir reservieren diese Codepoints, um auf PHBs abzubilden, die die in Abschnitt 4.2.2.2 spezifizierten allgemeinen Anforderungen erfüllen, obwohl die spezifischen Differentiated Services-PHBs, auf die diese Codepoints abbilden, zusätzliche Spezifikationen haben können (MAY).

Es wird kein Versuch unternommen, die Rückwärtskompatibilität mit den "DTR"- oder TOS-Bits des IPv4-TOS-Oktetts aufrechtzuerhalten, wie in [RFC791] definiert.

4.1 Ein Standard-PHB (A Default PHB)

Ein "Standard"-PHB muss (MUST) in einem DS-konformen Knoten verfügbar sein. Dies ist das übliche Best-Effort-Weiterleitungsverhalten, das in bestehenden Routern verfügbar ist, wie in [RFC1812] standardisiert. Wenn keine anderen Vereinbarungen bestehen, wird angenommen, dass Pakete zu diesem Aggregat gehören. Solche Pakete können (MAY) ohne Einhaltung besonderer Regeln in ein Netzwerk gesendet werden, und das Netzwerk wird so viele dieser Pakete wie möglich und so schnell wie möglich liefern, vorbehaltlich anderer Ressourcenrichtlinien-Einschränkungen. Eine vernünftige Implementierung dieses PHB wäre eine Warteschlangen-Disziplin, die Pakete dieses Aggregats sendet, wann immer der Ausgangslink nicht erforderlich ist, um ein anderes PHB zu erfüllen. Eine vernünftige Richtlinie für die Konstruktion von Diensten würde sicherstellen, dass das Aggregat nicht "ausgehungert" wird. Dies könnte durch einen Mechanismus in jedem Knoten durchgesetzt werden, der einige minimale Ressourcen (z.B. Puffer, Bandbreite) für Standard-Verhaltensaggregate reserviert. Dies ermöglicht es Sendern, die nicht Differentiated Services-bewusst sind, das Netzwerk weiterhin auf die gleiche Weise wie heute zu nutzen. Die Auswirkung der Einführung von Differentiated Services in eine Domain auf die Diensterwartungen ihrer Kunden und Peers ist eine komplexe Angelegenheit, die Richtlinienentscheidungen der Domain beinhaltet und außerhalb des Geltungsbereichs dieses Dokuments liegt. Der empfohlene (RECOMMENDED) Codepoint für das Standard-PHB ist das Bitmuster 000000; der Wert 000000 muss (MUST) auf ein PHB abbilden, das diese Spezifikationen erfüllt. Der für das Standardverhalten gewählte Codepoint ist mit der bestehenden Praxis [RFC791] kompatibel. Wenn ein Codepoint nicht auf ein standardisiertes oder lokales PHB abgebildet ist, sollte (SHOULD) er auf das Standard-PHB abgebildet werden.

Ein Paket, das anfänglich für das Standardverhalten markiert ist, kann (MAY) beim Durchgang einer Grenze in eine DS-Domain mit einem anderen Codepoint neu markiert werden, sodass es innerhalb dieser Domain mit einem anderen PHB weitergeleitet wird, möglicherweise vorbehaltlich einer ausgehandelten Vereinbarung zwischen den Peer-Domains.

4.2 Vergangene und zukünftige Verwendung des IP-Precedence-Felds (Once and Future IP Precedence Field Use)

Wir möchten eine gewisse Form der Rückwärtskompatibilität mit den gegenwärtigen Verwendungen des IP-Precedence-Felds aufrechterhalten: Bits 0-2 des IPv4-TOS-Oktetts. Es gibt Router, die das IP-Precedence-Feld verwenden, um unterschiedliche Per-Hop-Weiterleitungsbehandlungen auf ähnliche Weise auszuwählen wie hier für das DSCP-Feld vorgeschlagen. Daher kann eine einfache Prototyp-Differentiated-Services-Architektur durch entsprechende Konfiguration dieser Router schnell bereitgestellt werden. Darüber hinaus verstehen IP-Systeme heute die Position des IP-Precedence-Felds, und wenn diese Bits auf ähnliche Weise verwendet werden, wenn DS-konforme Ausrüstung bereitgestellt wird, sind während der frühen Bereitstellung keine signifikanten Ausfälle wahrscheinlich. Mit anderen Worten, strikte DS-Konformität muss nicht allgegenwärtig sein, selbst innerhalb des Netzwerks eines einzelnen Dienstanbieters, wenn die Bits 0-2 des DSCP-Felds auf eine Weise verwendet werden, die den bereitgestellten Verwendungen des IP-Precedence-Felds ähnelt oder diese umfasst.

4.2.1 IP-Precedence-Geschichte und kurze Evolution

Das IP-Precedence-Feld ist so etwas wie ein Vorläufer des DS-Felds. IP-Precedence und das IP-Precedence-Feld wurden erstmals in [RFC791] definiert. Die Werte, die das Drei-Bit-IP-Precedence-Feld annehmen könnte, wurden verschiedenen Verwendungen zugewiesen, einschließlich Netzwerk-Kontrollverkehr, Routing-Verkehr und verschiedenen Privilegstufen. Die niedrigste Privilegstufe wurde als "Routineverkehr" betrachtet. In [RFC791] wurde die Vorstellung von Precedence breit definiert als "Eine unabhängige Maßnahme der Wichtigkeit dieses Datagramms." Es wurde nicht angenommen, dass alle Werte des IP-Precedence-Felds über Grenzen hinweg Bedeutung haben, zum Beispiel "Die Netzwerk-Kontroll-Precedence-Bezeichnung soll nur innerhalb eines Netzwerks verwendet werden. Die tatsächliche Verwendung und Kontrolle dieser Bezeichnung liegt bei jedem Netzwerk." [RFC791]

Obwohl frühe BBN IMPs die Precedence-Funktion implementierten, taten dies frühe kommerzielle Router und UNIX-IP-Weiterleitungscode im Allgemeinen nicht. Als Netzwerke komplexer wurden und Kundenanforderungen wuchsen, entwickelten kommerzielle Router-Anbieter Möglichkeiten, verschiedene Arten von Queueing-Diensten zu implementieren, einschließlich Priority-Queueing, die im Allgemeinen auf in Filtern in den Routern codierten Richtlinien basierten, die IP-Adressen, IP-Protokollnummern, TCP- oder UDP-Ports und andere Header-Felder untersuchten. IP-Precedence war und ist eine der Optionen, die solche Filter untersuchen können.

Kurz gesagt, IP-Precedence ist weit verbreitet und wird häufig verwendet, wenn auch nicht genau auf die in [RFC791] beabsichtigte Weise. Dies wurde in [RFC1122] anerkannt, das besagt, dass die Verwendung des IP-Precedence-Felds zwar gültig ist, die spezifische Zuweisung der Prioritäten in [RFC791] jedoch lediglich historisch war.

4.2.2 Subsumption von IP-Precedence in Class Selector Codepoints

Eine Spezifikation der Paketweiterleitungsbehandlungen, die heute durch das IP-Precedence-Feld ausgewählt werden, müsste ziemlich allgemein sein; wahrscheinlich nicht spezifisch genug, um daraus vorhersagbare Dienste im Differentiated-Services-Framework zu bauen. Um eine teilweise Rückwärtskompatibilität mit bekannten aktuellen Verwendungen des IP-Precedence-Felds zu bewahren, ohne zukünftige Flexibilität zu opfern, haben wir den Ansatz gewählt, Mindestanforderungen an eine Menge von PHBs zu beschreiben, die mit den meisten der bereitgestellten Weiterleitungsbehandlungen kompatibel sind, die durch das IP-Precedence-Feld ausgewählt werden. Darüber hinaus geben wir eine Menge von Codepoints an, die auf PHBs abbilden müssen (MUST), die diese Mindestanforderungen erfüllen. Die PHBs, auf die diese Codepoints abbilden, können (MAY) zusätzlich zu den hier angegebenen erforderlichen eine detailliertere Liste von Spezifikationen haben. Andere Codepoints können (MAY) auf dieselben PHBs abbilden. Wir bezeichnen diese Menge von Codepoints als Class Selector Codepoints, und die Mindestanforderungen für PHBs, auf die diese Codepoints abbilden können, werden Class Selector PHB Requirements genannt.

4.2.2.1 Die Class Selector Codepoints

Die DS-Feldwerte von xxx000|xx oder DSCP = xxx000 und CU-Subfeld nicht spezifiziert, sind als eine Menge von Class Selector Codepoints reserviert. PHBs, auf die diese Codepoints abbilden, müssen (MUST) die Class Selector PHB-Anforderungen zusätzlich zur Beibehaltung der Standard-PHB-Anforderung für Codepoint 000000 (Abschnitt 4.1) erfüllen.

4.2.2.2 Die Class Selector PHB-Anforderungen

Wir bezeichnen einen Class Selector Codepoint mit einem größeren numerischen Wert als einen anderen Class Selector Codepoint als eine höhere relative Ordnung habend, während ein Class Selector Codepoint mit einem kleineren numerischen Wert als ein anderer Class Selector Codepoint als eine niedrigere relative Ordnung habend bezeichnet wird. Die Menge von PHBs, auf die die acht Class Selector Codepoints abbilden, muss (MUST) mindestens zwei unabhängig weitergeleitete Verkehrsklassen ergeben, und PHBs, die durch einen Class Selector Codepoint ausgewählt werden, sollten (SHOULD) Paketen eine Wahrscheinlichkeit rechtzeitiger Weiterleitung geben, die nicht niedriger ist als die, die Paketen gegeben wird, die mit einem Class Selector Codepoint niedrigerer relativer Ordnung markiert sind, unter vernünftigen Betriebsbedingungen und Verkehrslasten. Ein verworfenes Paket wird als ein extremer Fall verspäteter Weiterleitung betrachtet. Darüber hinaus müssen (MUST) PHBs, die durch Codepoints 11x000 ausgewählt werden, Paketen eine bevorzugte Weiterleitungsbehandlung im Vergleich zu dem durch Codepoint 000000 ausgewählten PHB geben, um die übliche Verwendung der IP-Precedence-Werte 110 und 111 für Routing-Verkehr zu bewahren.

Darüber hinaus sollten (SHOULD) PHBs, die durch verschiedene Class Selector Codepoints ausgewählt werden, unabhängig weitergeleitet werden; das heißt, Pakete, die mit verschiedenen Class Selector Codepoints markiert sind, können (MAY) neu geordnet werden. Ein Netzwerkknoten kann (MAY) Grenzen für die Menge der Knotenressourcen durchsetzen, die von jedem dieser PHBs genutzt werden können.

PHB-Gruppen, deren Spezifikation diese Anforderungen erfüllt, werden als Class Selector Compliant PHBs bezeichnet.

Die Class Selector PHB-Anforderungen für Codepoint 000000 sind mit denen kompatibel, die für das Standard-PHB in Abschnitt 4.1 aufgeführt sind.

4.2.2.3 Verwendung der Class Selector PHB-Anforderungen für IP-Precedence-Kompatibilität

Ein DS-konformer Netzwerkknoten kann mit einer Menge von einer oder mehreren Class Selector Compliant PHB-Gruppen bereitgestellt werden. Dieses Dokument besagt, dass die Menge von Codepoints xxx000 auf eine solche Menge von PHBs abbilden muss (MUST). Da es auch möglich ist, mehrere Codepoints auf dasselbe PHB abzubilden, kann (MAY) der Anbieter oder der Netzwerkadministrator den Netzwerkknoten so konfigurieren, dass Codepoints unabhängig von den Bits 3-5 des DSCP-Felds auf PHBs abgebildet werden, um ein Netzwerk zu erzeugen, das mit der historischen IP-Precedence-Verwendung kompatibel ist. So würde beispielsweise Codepoint 011010 auf dasselbe PHB abbilden wie Codepoint 011000.

4.2.2.4 Beispielmechanismen für die Implementierung von Class Selector Compliant PHB-Gruppen

Class Selector Compliant PHBs können durch eine Vielzahl von Mechanismen realisiert werden, einschließlich Strict Priority Queueing, Weighted Fair Queueing (WFQ), WRR oder Varianten [RPS, HPFQA, DRR] oder Class-Based Queuing [CBQ]. Die Unterscheidung zwischen PHBs und Mechanismen wird in Abschnitt 5 detaillierter beschrieben.

Es ist wichtig zu beachten, dass diese Mechanismen möglicherweise durch andere PHBs (standardisiert oder nicht) verfügbar sind, die in der Ausrüstung eines bestimmten Anbieters verfügbar sind. Zum Beispiel können zukünftige Dokumente eine Strict Priority Queueing PHB-Gruppe für eine Menge empfohlener Codepoints standardisieren. Ein Netzwerkadministrator könnte diese Router so konfigurieren, dass sie die Strict Priority Queueing PHBs mit Codepoints xxx000 in Übereinstimmung mit den Anforderungen dieses Dokuments auswählen.

Als weiteres Beispiel könnte ein anderer Anbieter einen CBQ-Mechanismus in seinen Routern einsetzen. Der CBQ-Mechanismus könnte verwendet werden, um die Strict Priority Queueing PHBs sowie eine Menge von Class Selector Compliant PHBs mit einer breiteren Palette von Funktionen zu implementieren, als in einer Menge von PHBs verfügbar wäre, die nicht mehr als die minimalen Class Selector PHB-Anforderungen erfüllen.

4.3 Zusammenfassung (Summary)

Dieses Dokument definiert Codepoints xxx000 als die Class Selector Codepoints, wobei PHBs, die durch diese Codepoints ausgewählt werden, die in Abschnitt 4.2.2.2 beschriebenen Class Selector PHB-Anforderungen erfüllen müssen (MUST). Dies wird getan, um ein nützliches Maß an Rückwärtskompatibilität mit den aktuellen Verwendungen des IP-Precedence-Felds im Internet zu bewahren, ohne die zukünftige Flexibilität übermäßig einzuschränken. Darüber hinaus wird Codepoint 000000 als Standard-PHB-Wert für das Internet verwendet und ist daher nicht konfigurierbar. Die verbleibenden sieben von Null verschiedenen Class Selector Codepoints sind nur insoweit konfigurierbar, als sie auf PHBs abbilden, die die Anforderungen in Abschnitt 4.2.2.2 erfüllen.

---