3. Differentiated Services Field Definition (Definizione del campo dei servizi differenziati)

Un campo di header alternativo, chiamato campo DS, è definito per sostituire le definizioni esistenti dell'ottetto TOS di IPv4 [RFC791] e dell'ottetto Traffic Class di IPv6 [IPv6].

Sei bit del campo DS sono utilizzati come codepoint (DSCP, Differentiated Services Codepoint) per selezionare il PHB che un pacchetto subisce presso ciascun nodo. Un campo di due bit attualmente non utilizzato (CU, Currently Unused) è riservato, la cui definizione e interpretazione sono al di fuori dell'ambito di questo documento. I nodi conformi ai servizi differenziati devono ignorare il valore dei bit CU quando determinano il comportamento per-hop da applicare a un pacchetto ricevuto.

La struttura del campo DS è la seguente:

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   |         DSCP          |  CU   |
   +---+---+---+---+---+---+---+---+

     DSCP: differentiated services codepoint
     CU:   currently unused

Nella notazione dei valori DSCP 'xxxxxx' (dove 'x' può essere uguale a '0' o '1') utilizzata in questo documento, il bit più a sinistra indica il bit 0 del campo DS (come sopra) e il bit più a destra indica il bit 5.

Gli implementatori dovrebbero notare che il campo DSCP è largo 6 bit. Un nodo conforme DS deve (MUST) selezionare il PHB facendo corrispondere l'intero campo DSCP a 6 bit, ad esempio trattando il valore del campo come un indice di tabella da utilizzare per selezionare un particolare meccanismo di elaborazione dei pacchetti implementato su quel dispositivo. I valori del campo CU devono (MUST) essere ignorati dalla selezione del PHB. Il campo DSCP è definito come un campo non strutturato (unstructured field) per facilitare le definizioni future dei comportamenti per-hop.

La mappatura dei codepoint ai PHB deve (MUST) essere configurabile, con alcune eccezioni indicate di seguito. Un nodo conforme DS deve (MUST) supportare l'equivalente logico di una tabella di mappatura configurabile dei codepoint ai PHB. Le specifiche PHB devono (MUST) includere un codepoint predefinito raccomandato, che deve (MUST) essere univoco per i codepoint nello spazio standard (standard space) (vedere Sezione 6). Le implementazioni dovrebbero (should) supportare la mappatura codepoint-PHB predefinita raccomandata nella configurazione predefinita. Gli operatori possono scegliere di utilizzare un codepoint diverso per un PHB in aggiunta a o al posto del predefinito raccomandato. Se gli operatori scelgono di farlo, devono essere consapevoli che il re-marking del campo DS ai confini amministrativi può essere necessario, anche se entrambi i lati del confine implementano lo stesso PHB.

Vedere [ARCH] per un'ulteriore discussione sul re-marking.

L'eccezione alla configurabilità generale riguarda i codepoint 'xxx000', descritti nelle Sezioni 4.2.2 e 4.3.

I pacchetti ricevuti con un codepoint non riconosciuto dovrebbero (SHOULD) essere inoltrati come se fossero marcati per il comportamento Default (vedere Sezione 4), e quel codepoint non dovrebbe (SHOULD NOT) essere modificato. Tali pacchetti non devono (MUST NOT) causare il malfunzionamento di un nodo di rete.

La struttura del campo DS presentata sopra non è compatibile con la definizione esistente dell'ottetto TOS di IPv4 in [RFC791]. La presunzione è che i domini DS si proteggeranno deployando nodi di confine di re-marking, così come le reti che utilizzano le designazioni Precedence RFC 791. Le procedure operative appropriate dovrebbero (SHOULD) seguire [RFC791], che afferma: "Se l'uso effettivo di queste designazioni di priorità è una preoccupazione per una particolare rete, è responsabilità di quella rete controllare l'accesso e l'uso di tali priorità." La convalida dei valori del campo DS a un confine DS ha senso comunque, poiché i nodi a monte possono facilmente impostarlo su qualsiasi valore. I domini DS che non sono isolati da nodi di confine configurati correttamente possono offrire un servizio imprevedibile.

I nodi possono (MAY) riscrivere il campo DS secondo necessità per fornire un servizio locale o end-to-end desiderato. La specifica delle traduzioni del campo DS ai confini DS è oggetto di accordi sul livello di servizio (service level agreements) tra fornitori e utenti ed è al di fuori dell'ambito di questo documento. Con i PHB standardizzati, i fornitori possono costruire servizi da un insieme ben noto di trattamenti di inoltro dei pacchetti che ci si può aspettare siano presenti sulle apparecchiature di molti fornitori.