1. Einführung (Introduction)
Differentiated Services sollen einen Rahmen und Bausteine bereitstellen, um die Bereitstellung skalierbarer Dienstdifferenzierung im Internet zu ermöglichen. Der Differentiated Services-Ansatz zielt darauf ab, die Bereitstellung zu beschleunigen, indem die Architektur in zwei Hauptkomponenten unterteilt wird, von denen eine recht gut verstanden ist und die andere gerade erst verstanden wird. Dabei orientieren wir uns am ursprünglichen Design des Internet, bei dem die Entscheidung getroffen wurde, die Weiterleitungs- und Routing-Komponenten zu trennen. Die Paketweiteleitung ist die relativ einfache Aufgabe, die auf Paketbasis so schnell wie möglich ausgeführt werden muss. Die Weiterleitung verwendet den Paketheader, um einen Eintrag in einer Routingtabelle zu finden, der die Ausgangsschnittstelle des Pakets bestimmt. Das Routing setzt die Einträge in dieser Tabelle und muss möglicherweise eine Reihe von Transit- und anderen Richtlinien widerspiegeln sowie Routenausfälle verfolgen. Routingtabellen werden als Hintergrundprozess zur Weiterleitungsaufgabe gepflegt. Darüber hinaus ist das Routing die komplexere Aufgabe und hat sich in den letzten 20 Jahren weiterentwickelt.
Analog dazu enthält die Differentiated Services-Architektur zwei Hauptkomponenten. Eine ist das recht gut verstandene Verhalten im Weiterleitungspfad und die andere ist die komplexere und noch aufkommende Hintergrundrichtlinien- und Zuweisungskomponente, die die im Weiterleitungspfad verwendeten Parameter konfiguriert. Die Weiterleitungspfad-Verhaltensweisen umfassen die differentielle Behandlung, die ein einzelnes Paket erhält, wie sie durch Warteschlangendienst-Disziplinen und/oder Warteschlangenverwaltungs-Disziplinen implementiert wird. Diese Per-Hop-Verhaltensweisen (Per-Hop Behaviors, PHB) sind nützlich und in Netzwerkknoten erforderlich, um eine differentielle Behandlung von Paketen bereitzustellen, unabhängig davon, wie wir End-to-End- oder Intra-Domain-Dienste konstruieren. Unser Fokus liegt auf der allgemeinen Semantik der Verhaltensweisen und nicht auf den spezifischen Mechanismen, die zu ihrer Implementierung verwendet werden, da sich diese Verhaltensweisen weniger schnell entwickeln werden als die Mechanismen.
Per-Hop-Verhaltensweisen und Mechanismen zu ihrer Auswahl auf Paketbasis können heute in Netzwerkknoten bereitgestellt werden, und es ist dieser Aspekt der Differentiated Services-Architektur, der zuerst angegangen wird. Darüber hinaus kann der Weiterleitungspfad erfordern, dass eine gewisse Überwachung, Kontrolle und Formung des Netzwerkverkehrs durchgeführt wird, der für eine „spezielle" Behandlung vorgesehen ist, um Anforderungen im Zusammenhang mit der Bereitstellung der speziellen Behandlung durchzusetzen. Mechanismen für diese Art von Traffic Conditioning sind ebenfalls recht gut verstanden. Die breite Bereitstellung solcher Traffic Conditioner ist auch wichtig, um die Konstruktion von Diensten zu ermöglichen, obwohl ihre tatsächliche Verwendung beim Aufbau von Diensten sich im Laufe der Zeit entwickeln kann.
Die Konfiguration von Netzwerkelementen in Bezug darauf, welche Pakete eine spezielle Behandlung erhalten und welche Arten von Regeln auf die Nutzung von Ressourcen angewendet werden sollen, ist weit weniger gut verstanden. Dennoch ist es möglich, nützliche Differentiated Services in Netzwerken bereitzustellen, indem einfache Richtlinien und statische Konfigurationen verwendet werden. Wie in [ARCH] beschrieben, gibt es eine Reihe von Möglichkeiten, Per-Hop-Verhaltensweisen und Traffic Conditioner zu komponieren, um Dienste zu erstellen. Dabei wird zusätzliche Erfahrung gewonnen, die komplexere Richtlinien und Zuweisungen leiten wird. Die grundlegenden Verhaltensweisen im Weiterleitungspfad können gleich bleiben, während sich diese Komponente der Architektur entwickelt. Erfahrungen mit dem Aufbau solcher Dienste werden noch einige Zeit andauern, daher vermeiden wir die Standardisierung dieser Konstruktion, da sie verfrüht ist. Darüber hinaus werden viele Details des Dienstaufbaus durch rechtliche Vereinbarungen zwischen verschiedenen Geschäftseinheiten abgedeckt, und wir vermeiden dies, da es weit außerhalb des Geltungsbereichs der IETF liegt.
Dieses Dokument konzentriert sich auf die Weiterleitungspfad-Komponente. Im Paketweiterleitungspfad werden Differentiated Services realisiert, indem der in einem Feld im IP-Paketheader enthaltene Codepoint auf eine bestimmte Weiterleitungsbehandlung oder Per-Hop-Verhaltensweise (PHB) an jedem Netzwerkknoten entlang seines Pfades abgebildet wird. Die Codepoints können aus einer Menge obligatorischer Werte gewählt werden, die später in diesem Dokument definiert sind, aus einer Menge empfohlener Werte, die in zukünftigen Dokumenten definiert werden, oder können eine rein lokale Bedeutung haben. PHBs werden voraussichtlich durch den Einsatz einer Reihe von Warteschlangendienst- und/oder Warteschlangenverwaltungs-Disziplinen in der Ausgangsschnittstellen-Warteschlange eines Netzwerkknotens implementiert: zum Beispiel gewichtetes Round-Robin (WRR) Warteschlangenservice oder Drop-Präferenz-Warteschlangenverwaltung.
Die Markierung wird von Traffic Conditionern an Netzwerkgrenzen durchgeführt, einschließlich der Ränder des Netzwerks (First-Hop-Router oder Quellhost) und administrativen Grenzen. Traffic Conditioner können die Primitive von Markierung, Messung, Kontrolle und Formung umfassen (diese Mechanismen werden in [ARCH] beschrieben). Dienste werden durch die Verwendung bestimmter Paketklassifizierungs- und Traffic-Conditioning-Mechanismen an Grenzen in Verbindung mit der Verkettung von Per-Hop-Verhaltensweisen entlang des Transitpfades des Verkehrs realisiert. Ein Ziel der Differentiated Services-Architektur ist es, diese Bausteine für zukünftige Erweiterbarkeit zu spezifizieren, sowohl hinsichtlich der Anzahl und Art der Bausteine als auch der daraus aufgebauten Dienste.
Die in diesem Memo verwendete Terminologie ist in Abschnitt 2 definiert. Die Definition des Differentiated Services-Felds (DS-Feld) wird in Abschnitt 3 gegeben. In Abschnitt 4 diskutieren wir den Wunsch nach teilweiser Rückwärtskompatibilität mit der aktuellen Verwendung des IPv4 Precedence-Felds. Als Lösung führen wir Class Selector Codepoints und Class Selector Compliant PHBs ein. Abschnitt 5 präsentiert Richtlinien für die Standardisierung von Per-Hop-Verhaltensweisen. Abschnitt 6 diskutiert Richtlinien für die Zuweisung von Codepoints. Abschnitt 7 behandelt Sicherheitsüberlegungen.
Dieses Dokument ist eine prägnante Beschreibung des DS-Felds und seiner Verwendungen. Es ist dazu gedacht, zusammen mit der Differentiated Services-Architektur [ARCH] gelesen zu werden.
Die Schlüsselwörter „muss (MUST)", „darf nicht (MUST NOT)", „erforderlich (REQUIRED)", „muss (SHALL)", „darf nicht (SHALL NOT)", „sollte (SHOULD)", „sollte nicht (SHOULD NOT)", „empfohlen (RECOMMENDED)", „kann (MAY)" und „optional (OPTIONAL)" in diesem Dokument sind wie in [RFC2119] beschrieben zu interpretieren.