Zusammenfassung

  • RFC 795 ordnete die Felder des ursprünglichen IP-Type-of-Service – Vorrang, Verzögerung, Durchsatz und Zuverlässigkeit – den tatsächlichen Dienstoptionen von AUTODIN II, ARPANET, PRNET und SATNET zu.
  • Dabei gingen Unterscheidungen verloren: PRNET kannte keine Vorranganzeige, ARPANET nur ein Prioritätsbit; verschiedene Bitmuster führten zum selben lokalen Dienst, und 111 war in zwei Tabellen ein Fehler.

Ein IP-Paket gibt eine Bestellung auf: schnell, zuverlässig, bitte vor den anderen. Bei PRNET trifft es auf ein Netz ohne Prioritätsschalter. Jon Postel machte aus diesem Problem im September 1981 die RFC 795. Sie besteht aus Zuordnungstabellen für vier Netze. Das klingt trocken, bis man bemerkt, wie viele feierliche Wünsche des gemeinsamen IP-Headers auf dem Weg zum nächsten Netz eine schlichtere Übersetzung brauchen.

Das damalige Type-of-Service-Feld umfasste acht Bits. Drei standen für Vorrang, je eines für geringe Verzögerung, hohen Durchsatz und hohe Zuverlässigkeit, zwei blieben reserviert. Die Vorrangstufen reichten von Routine bis Netzsteuerung; dazwischen lag unter anderem „Flash Override“. Der Absender konnte seine Wünsche in einer einheitlichen Sprache formulieren. Gleich darauf erklärte Postel, die einzelnen Netze hätten sehr verschiedene konkrete Dienstmöglichkeiten. Seine Tabellen nahmen diese Verschiedenheit ernst.

AUTODIN II trennte Kategorien für die Verkehrsannahme von Anwendungstypen. Die Annahmekategorien ließen sich einigermaßen direkt auf den IP-Vorrang beziehen. Die Anwendungstypen waren ein engeres Menü: I/A bevorzugte geringe Verzögerung, B1 Durchsatz, B2 Durchsatz samt Zuverlässigkeit und Q/R die normale Einstellung. Bei der Rückübersetzung der drei DTR-Bits fielen mehrere Werte auf Q/R oder I/A zusammen. Das Muster 111 endete mit „error“. Drei Häkchen auf der Bestellung erzeugten keinen fünften Anwendungstyp.

ARPANET bot ein einzelnes Prioritätsbit, das zum obersten Bit des IP-Vorrangs passte. Die weiteren Entscheidungen betrafen normale Nachrichten vom Typ 0 oder unkontrollierte vom Typ 3 sowie ein oder mehrere Pakete. Typ 3 mit mehreren Paketen war nicht erlaubt. Viele DTR-Muster ergaben denselben Typ 0 mit mehreren Paketen; 100 und 110 wählten Typ 3 mit einem Paket, 101 Typ 0 mit einem, 111 wiederum einen Fehler. Mehr Felder im Auftrag bedeuteten hier oft dieselbe Fahrkarte.

PRNET hatte gar keine Vorranganzeige. Es unterschied Stations- von Punkt-zu-Punkt-Routing und bestätigte den Empfang wahlweise oder nicht. Postels Tabelle ließ den Verzögerungswunsch die Route und den Zuverlässigkeitswunsch die Bestätigung beeinflussen. Ein anderer Durchsatzwunsch änderte die Kombination aus Route und Bestätigung in mehreren Zeilen nicht. Das Paket durfte „wichtig“ heißen, doch dem lokalen Netz fehlte dafür ein eigener Hebel.

SATNET hatte ebenfalls keine Vorranganzeige, dafür viele andere Schalter: Block oder Strom, vier Verzögerungsstufen, zwei Strategien für die Haltezeit und drei Zuverlässigkeitsstufen. Postel zählte 2 × 4 × 2 × 3 = 48 Kombinationen. Mit drei IP-DTR-Bits war diese ganze Auswahl nicht einzeln zu benennen. Eine Übersetzungsregel musste aus der knappen Bitte eine konkrete lokale Einstellung auswählen.

Diese vier Seiten erzählen von Interoperabilität ohne Zaubertrick. Die Netze konnten die gleiche IP-Sprache entgegennehmen und trotzdem unterschiedliche Dienste bereitstellen. Postel vermerkte, wo ein Wunsch zum Fehler führte, wo zwei Wünsche denselben Dienst ergaben und wo ein Netz gar keinen entsprechenden Knopf besaß. Genau diese unbequemen Zeilen machten aus einem gemeinsamen Formular eine brauchbare Ingenieursanleitung.