Tipus de servei

El camp de tipus de servei (ToS) és el segon byte de la capçalera IPv4. Ha tingut diversos propòsits al llarg dels anys i ha estat definit de diferents maneres per cinc RFC.

Abans de la redefinició, el camp ToS podria especificar la prioritat d'un datagrama i sol·licitar una ruta per a un servei de baixa latència, d'alt rendiment o altament fiable. En funció d'aquests valors de ToS, un paquet es col·locaria en una cua de sortida prioritzada, o agafaria una ruta amb latència, rendiment o fiabilitat adequades. A la pràctica, el camp ToS mai va tenir un ús generalitzat fora de les xarxes del Departament de Defensa dels EUA. No obstant això, una gran part del treball experimental, d'investigació i de desplegament s'ha centrat en com fer ús d'aquests vuit bits, donant lloc a la definició actual del camp DS.^[1]

La redefinició moderna del camp ToS, que també s'utilitza per al camp Traffic Class en paquets IPv6, és un camp de serveis diferenciats (camp DS) de 8 bits que consisteix en un camp de punt de codi de serveis diferenciats (DSCP) de 6 bits i un camp de notificació explícita de congestió (ECN) de 2 bits. Tot i que els serveis diferenciats són una mica compatibles amb ToS, ECN no ho és.^[2]

Història

El camp Tipus de servei de la capçalera IP es va definir originalment a RFC 791 i des d'aleshores s'ha interpretat per a la Precedència IP i el ToS. La definició es va derivar en gran part d'una especificació del DoD dels EUA JANAP-128, que defineix la precedència dels missatges. Va definir un mecanisme per assignar una precedència a cada paquet IP, així com un mecanisme per sol·licitar un tractament específic com ara alt rendiment, alta fiabilitat o baixa latència, etc. A l'actualització RFC 1349 s'introdueix el bit Cost monetari (aquest bit). anteriorment estava marcat com a "Reservat per a ús futur"). La secció 2.4 de [rfc:1583 la RFC 1583] (OSPFv2) introdueix un mètode d'encaminament compatible amb ToS.

A la pràctica, només la part del camp de Precedència IP es va utilitzar fora de les xarxes del Departament de Defensa dels EUA: com més gran sigui el valor del camp Precedència IP, més alta serà la prioritat del paquet IP. Algunes xarxes del Departament de Defensa dels EUA van utilitzar el bit de retard per a la selecció de rutes entre els camins de cable oceànic i els camins de comunicació per satèl·lit (SATCOM) quan existien tots dos camins. IPv6 mai ha tingut un camp ToS "tradicional" semblant a IPv4, en part perquè els autors eren conscients dels esforços de DiffServ en la seva redacció ([rfc:2460 RFC 2460,] secció 7).

A [rfc:2474 la RFC 2474] es va canviar la definició d'aquest camp sencer. Ara s'anomena camp "DS" (Serveis diferenciats, "DiffServ") i els 6 bits superiors contenen un valor anomenat "DSCP" (punt de codi de serveis diferenciats). Els 3 bits superiors de DS mantenen la compatibilitat amb IP Precedence. Des de [rfc:3168 la RFC 3168], els dos bits restants (els dos bits menys significatius) s'utilitzen per a la notificació de congestió explícita.

[rfc:8622 L'RFC 8622] ha afegit DS de menor esforç (LE) per al trànsit que pot ser anticipat per un altre trànsit (trànsit de millor esforç). Està pensat per al trànsit en segon pla de baixa precedència, com ara transferències massives de dades amb poca prioritat en el temps.

Assignació

Precedència i ToS

Abans de la seva obsoletació, el camp Tipus de servei es va definir de la següent manera a [rfc:791 la RFC 791] :

7	6	5	4	3	2	1	0
Precedència			Tipus de Servei			No utilitzat (0)

La precedencia era un camp de 3 bits que tracta els paquets d'alta prioritat com a més importants que altres paquets. Si un encaminador està congestionat i necessita descartar alguns paquets, primer descartarà els paquets que tinguin la prioritat més baixa. Tot i que el camp de precedència formava part de la versió IP 4, mai es va utilitzar.

[rfc:1349 La RFC 1349] va introduir un camp addicional "de baix cost". Els quatre bits de ToS disponibles ara es converteixen en:

7	6	5	4	3	2	1	0
(Precedència IP)			retard baix	rendiment	fiabilitat	baix cost (RFC 1349 )	(Ha de ser zero)

El nom aquí segueix la convenció dels sistemes operatius Unix.^[3] RFC 1349 i RFC 1060 només mostren exemples d'un bit utilitzat alhora per als valors per defecte de l'aplicació, tot i que RFC 791 esmenta que com a màxim dues de les tres indicacions que té s'han d'establir nominalment. Un d'aquests usos es coneix de mod_iptos.^[4]

Com que els darrers tres bits van passar per moltes definicions abans de [rfc:2474 la RFC 2474] (vegeu més avall), la documentació i les implementacions poden ser confuses i contradictòries.

DSCP i ECN

[rfc:2474 La RFC 2474] (que es va publicar el desembre de 1998) reservava els primers sis bits del camp DS (o IPv4 ToS) per al punt de codi de serveis diferenciats (DSCP), i [rfc:3168 la RFC 3168] reservava els dos últims bits per a la notificació de congestió explícita.

7	6	5	4	3	2	1	0
DSCP						ECN

Referències

↑ «IPv4 Header Structure and Fields Explained» (en anglès britànic). [Consulta: 15 novembre 2023].
↑ «Are IPv4 type of service and IPv6 traffic class equivalent to each other or is traffic class IPv6 specific?» (en anglès). [Consulta: 15 novembre 2023].
↑ «openbsd/src:sys/netinet/ip.h» (en anglès). GitHub. [Consulta: 10 octubre 2018].
↑ Gaudet, Dean. «mod_iptos.c (mod_iptos 1.0)» (en anglès). Arxivat de l'original el 10 October 2018. [Consulta: 10 octubre 2018].

[1] «IPv4 Header Structure and Fields Explained» (en anglès britànic). [Consulta: 15 novembre 2023].

[2] «Are IPv4 type of service and IPv6 traffic class equivalent to each other or is traffic class IPv6 specific?» (en anglès). [Consulta: 15 novembre 2023].

[obsd-ip-3] «openbsd/src:sys/netinet/ip.h» (en anglès). GitHub. [Consulta: 10 octubre 2018].

[mod_iptos-4] Gaudet, Dean. «mod_iptos.c (mod_iptos 1.0)» (en anglès). Arxivat de l'original el 10 October 2018. [Consulta: 10 octubre 2018].

[1]

[2]

[3]

[4]