1. Introduction (Einführung)

Differentiated Services (Differenzierte Dienste) zielen darauf ab, einen Rahmen und Bausteine bereitzustellen, um die Bereitstellung skalierbarer Dienstdifferenzierung (scalable service discrimination) im Internet zu ermöglichen. Der Ansatz der differenzierten Dienste versucht, die Bereitstellung zu beschleunigen, indem die Architektur in zwei Hauptkomponenten aufgeteilt wird, von denen eine ziemlich gut verstanden ist und die andere gerade erst verstanden wird. In dieser Hinsicht wird sie von der ursprünglichen Gestaltung des Internets geleitet, die die Weiterleitungs- (forwarding) und Routing-Komponenten getrennt hat. Die Paketweiterleitung (packet forwarding) ist eine relativ einfache Aufgabe, die paketweise so schnell wie möglich ausgeführt werden muss. Die Weiterleitung verwendet den Paket-Header, um einen Eintrag in einer Routing-Tabelle zu finden, die die Ausgangsschnittstelle des Pakets bestimmt. Das Routing setzt die Einträge in dieser Tabelle und muss verschiedene Transitpolitiken und andere Richtlinien widerspiegeln und möglicherweise auch Routenausfälle verfolgen. Die Routing-Tabelle wird als Hintergrundprozess zur Weiterleitungsaufgabe aufrechterhalten. Darüber hinaus ist das Routing eine komplexere Aufgabe und hat sich in den letzten zwanzig Jahren weiterentwickelt.

Ebenso umfasst die Architektur der differenzierten Dienste zwei Hauptkomponenten: ein ziemlich gut verstandenes Verhalten im Weiterleitungspfad (forwarding path) und eine komplexere und noch in der Entwicklung befindliche Hintergrund-Politik- und Zuweisungskomponente (allocation), die die im Weiterleitungspfad verwendeten Parameter konfiguriert. Das Verhalten des Weiterleitungspfads umfasst die differenzielle Behandlung (differential treatment), die einzelne Pakete erfahren, implementiert durch Warteschlangen-Service-Disziplinen (queue service disciplines) und/oder Warteschlangen-Management-Disziplinen (queue management disciplines). Diese Per-Hop-Verhalten (per-hop behaviors) sind nützlich und notwendig auf Netzwerkknoten, um eine differenzierte Behandlung von Paketen bereitzustellen, unabhängig davon, wie End-to-End- oder domäneninterne Dienste konstruiert werden. Wir konzentrieren uns auf die allgemeine Semantik (general semantics) der Verhalten und nicht auf die spezifischen Mechanismen, die zu ihrer Implementierung verwendet werden, da diese Verhalten weniger schnell weiterentwickelt werden als die Mechanismen.

Die Per-Hop-Verhalten und die Mechanismen zu ihrer paketweisen Auswahl können heute in Netzwerkknoten bereitgestellt werden, und es ist dieser Aspekt der Architektur der differenzierten Dienste, der zuerst angegangen wird. Darüber hinaus kann es im Weiterleitungspfad erforderlich sein, eine Überwachung (monitoring), Policing und Shaping des Netzwerkverkehrs durchzuführen, der für eine "spezielle" Behandlung vorgesehen ist, um Anforderungen im Zusammenhang mit der Bereitstellung einer speziellen Behandlung durchzusetzen. Mechanismen für diese Art der Verkehrskonditionierung (traffic conditioning) sind ebenfalls ziemlich gut verstanden. Eine breite Bereitstellung solcher Verkehrskonditionierer ist auch wichtig, um die Konstruktion von Diensten zu ermöglichen, aber ihre tatsächliche Verwendung bei der Konstruktion von Diensten kann sich im Laufe der Zeit entwickeln.

Die Konfiguration von Netzwerkelementen in Bezug darauf, welche Pakete eine spezielle Behandlung erhalten und welche Arten von Regeln auf die Ressourcennutzung angewendet werden sollen, ist viel weniger gut verstanden. Dennoch ist es möglich, nützliche differenzierte Dienste in einem Netzwerk bereitzustellen, indem einfache Richtlinien und statische Konfiguration verwendet werden. Wie in [ARCH] beschrieben, gibt es viele Möglichkeiten, Per-Hop-Verhalten und Verkehrskonditionierer zu konfigurieren, um Dienste zu erstellen. Dieser Prozess wird zusätzliche Erfahrungen liefern, um komplexere Richtlinien und Zuweisungen zu leiten. Die grundlegenden Verhalten des Weiterleitungspfads können gleich bleiben, während sich diese Komponente der Architektur weiterentwickelt. Da die Erfahrung mit der Konstruktion solcher Dienste eine Weile andauern wird, vermeiden wir es, diese Konstruktion zu standardisieren, da sie verfrüht wäre. Darüber hinaus vermeiden wir viele der Details der Dienstkonstruktion, da sie durch rechtliche Verträge zwischen verschiedenen Entitäten abgedeckt werden, was außerhalb des Anwendungsbereichs der IETF liegt.

Dieses Dokument konzentriert sich auf die Weiterleitungspfadkomponente. Im Paketübertragungspfad werden differenzierte Dienste realisiert, indem ein Codepunkt (codepoint), der in einem Feld des IP-Paket-Headers enthalten ist, auf eine bestimmte Weiterleitungsbehandlung (forwarding treatment) oder ein Per-Hop-Verhalten (per-hop behavior, PHB) an jedem Netzwerkknoten entlang seines Pfades abgebildet wird. Der Codepunkt kann einer aus einem Satz obligatorischer Werte (mandatory values) sein, die in diesem Dokument definiert sind, einer aus einem Satz empfohlener Werte (recommended values), die in zukünftigen Dokumenten definiert werden sollen, oder er kann eine rein lokale Bedeutung haben. Es wird erwartet, dass das PHB durch den Einsatz verschiedener Warteschlangen-Service-Disziplinen und/oder Warteschlangen-Management-Disziplinen auf den Ausgangsschnittstellen von Netzwerkknoten implementiert wird: zum Beispiel Weighted Round-Robin (WRR) Warteschlangen-Service oder Drop-Preference Warteschlangen-Management.

Die Markierung (marking) wird von Verkehrskonditionierern an den Netzwerkgrenzen (first-hop router oder source host) durchgeführt, einschließlich administrativer Grenzen. Verkehrskonditionierer können Markierungs-, Mess- (metering), Policing- und Shaping-Primitive umfassen (diese Mechanismen sind in [ARCH] beschrieben). Dienste werden durch die Verwendung bestimmter Paketklassifizierungs- und Verkehrskonditionierungsmechanismen an den Grenzen und durch die Verkettung (concatenation) von Per-Hop-Verhalten entlang des Transitpfads des Verkehrs realisiert. Das Ziel der Architektur der differenzierten Dienste ist es, diese Bausteine für zukünftige Erweiterbarkeit zu spezifizieren, sowohl in Bezug auf die Anzahl und Arten von Komponenten als auch auf die daraus konstruierten Dienste.

Die in diesem Memo verwendete Terminologie ist in Abschnitt 2 definiert. Die Definition des Differentiated Services Field (DS field) wird in Abschnitt 3 dargestellt. Abschnitt 4 befasst sich mit dem Wunsch nach teilweiser Abwärtskompatibilität mit der aktuellen Verwendung des IPv4 Precedence-Feldes; die Lösung führt Class Selector Codepoints und Class Selector Compliant PHB ein. Abschnitt 5 präsentiert Richtlinien für die Standardisierung von Per-Hop-Verhalten. Abschnitt 6 behandelt Richtlinien für die Zuweisung von Codepunkten. Abschnitt 7 behandelt Sicherheitsüberlegungen.

Dieses Dokument ist eine prägnante Beschreibung des DS-Feldes und seiner Verwendung. Es ist dazu bestimmt, in Verbindung mit der Differentiated Services Architecture [ARCH] gelesen zu werden.

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" sollten wie in [RFC2119] beschrieben interpretiert werden.