Bajt TOS przez lata miał wiele różnych zastosowań, został zdefiniowany w różny sposób przez 5 różnych dokumentów RFC (RFC 791 ↓, RFC 1122 ↓, RFC 1349 ↓, RFC 2474 ↓, oraz RFC 3168 ↓.) Cała historia bajtu TOS jest opisana w 22. sekcji dokumentu RFC 3168 ↓.
Typy usług
8 bitów w nagłówku IP jest zarezerwowanych dla TOS. Mogą one zostać podzielone na 5 podpól:
3 najstarsze bity zawierają wartości od 0 do 7 i używane są do oznaczania ważności datagramu. Domyślną wartością jest 0 (im wartość wyższa tym datagram ważniejszy).
Router utrzymuje wartość TOS dla każdej trasy w swojej tablicy routingu. Trasy wyuczone poprzez protokoły nieobsługujące TOS otrzymują domyślną wartość 0. Routery używają TOS do wybierania trasy dla pakietu.
Proces wyboru trasy dla pakietu z określonym TOS:
Router znajduje w swojej tablicy routingu wszystkie dostępne trasy do celu.
Jeżeli żadna trasa do celu nie istnieje, router odrzuca pakiet z powodu nieosiągalności celu.
Jeżeli istnieje jedna lub więcej tras z TOS pasującym do pakietu, router wybiera tę o najlepszej metryce.
Jeżeli znalezienie trasy o podanym TOS nie powiedzie się, router powtarza krok i ustawia wymagany TOS na 0.
Jeżeli router nie znajdzie trasy, odrzuca pakiet z powodu nieosiągalności celu. Router zwraca wtedy błąd ICMP Cel Nieosiągalny (Destination Unreachable) oraz precyzuje kod: Sieć Nieosiągalna z Typem Usługi (kod 11) (Network Unreachable with Type of Service (code 11)) lub Host Nieosiągalny z Typem Usługi (kod 12) (Host Unreachable with Type of Service (code 12)).
“Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice” by John Evans, Clarence Filsfils (Morgan Kaufmann, 2007, ISBN 978-0123705495)
K.K.NicholsK.K., S.S.BlakeS.S., F.F.BakerF.F., D.D.BlackD.D., Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, IETF, grudzień 1998, DOI: 10.17487/RFC2474, ISSN2070-1721, OCLC943595667(ang.).