0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | D | T | R | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
Die ersten drei Bit bilden zusammen das PRECEDENCE Feld und können die Reihenfolge beeinflussen, in der ein Router Pakete weiterleitet (Queueing). Die nächsten drei bzw. vier Bit (D, T, R, C) können die Wegewahl des Routers (Routing) beeinflussen, im Fall daß dieser über mehrere gleichwertige Routen zu einem Zielnetz verfügt. DiffServ (Differentiated Services) nutzt das ToS Feld für ähnliche Zwecke, aber auf unterschiedliche Art und Weise.
Ein Aprilscherz zur PRECEDENCE findet sich in der c't 7/1999, Seite 194: Surfen auf der Überholspur [ € ].
Anfänglich wurde das ToS Feld in RFC 791 (Internet Protocol, September 1981) definiert. Eine veränderte Nutzung wurde in RFC 1349 (Type of Service in the Internet Protocol Suite, Juli 1992) angeregt. Dort wurden verschiedenen IP Applikationen sinnvolle ToS Werte zugeordnet und die D,T,R-Bits um das Cost Bit ergänzt. Die Nutzung dieser Features blieb in der Praxis hinter den Erwartungen zurück und man suchte schließlich nach einer Möglichkeit diese acht Bits anderweitig zu nutzen. In RFC2474, 4.2.1, IP Precedence History and Evolution in Brief liest man dazu: Although early BBN IMPs implemented the Precedence feature, early commercial routers and UNIX IP forwarding code generally did not.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DSCP | C U |
+-----+-----+-----+-----+-----+-----+-----+-----+
DSCP: differentiated services codepoint
CU: currently unused
DiffServ schließlich ist erstmals in RFC 2474 (Definition of the Differentiated Services Field in the IPv4 and IPv6 Headers, Dezember 1998) definiert. Hierbei werden nur die ersten sechs Bit (DSCP - Differentiated Services Code Point) des nun Differentiated Services (DS) genannten Felds verwendet. Weitere Informationen zu DiffServ findet man in einem White Paper von Juniper: Supporting Differentiated Service Classes in Large IP Networks und Cisco: DiffServ - The Scalable End-to-End QoS Model
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
DSCP: differentiated services codepoint
ECN: Explicit Congestion Notification
1999 wurde dann mit dem RFC 2481 (A Proposal to add ECN to IP, Januar 1999) ein erster Vorschlag unterbreitet, die letzten zwei Bits (6, 7) für einen Early Congestion Notification Mechanismus zu nutzen. Mit dem RFC 3168 (The Addition of ECN to IP, September 2001) wurde diese Methode zum offiziellen Standard. Mehr Informationen zum Thema ECN findet man in ECN in TCP/IP von Sally Floyd.
Kennzeichnet die Länge des gesamten IP Pakets, also Header plus Daten. Mit seinen sechzehn Bit kann das Total Length Feld eine maximale IP Paketlänge von 216-1 ( =65.535) Bytes darstellen; das ist somit die maximale IP Paketgröße.
Ethernet Frames mußten zwecks Kollisionserkennung in shared media Umgebungen mindestens 64 Byte lang sein. Der Payload eines solchen Frames muß demnach mindestens 46 Byte lang sein. Es gibt jedoch PDUs mit geringerer Länge, z.B. ARP Nachrichten. Um hier die geforderte Mindestlänge einzuhalten werden an das Ende der ARPDU so viele (mehr oder minder zufällige) Auffüllbits angefügt - das sogenannte Padding, bis die minimale Framelänge erreicht ist. IEEE-konforme Ethernet Frames kennzeichnen das Ende des eigentlichen Payloads und den Beginn des Padding mit Hilfe des Längenfelds im Frame-Header. Ethernet II Frames bieten diesen Service nicht. Deswegen muß jedes PDU, das in einem Ethernet II Frame enkapsuliert wird, selbst die Information über seine Länge, in irgendeiner Form, tragen.
Bei IP wird diese Aufgabe dediziert vom TL-Feld übernommen, welches die Länge des IP Headers und der Nutzdaten zusammenfaßt, aber eben die Padding Bytes ausläßt.