3. Definizione del campo Differentiated Services (Differentiated Services Field Definition)
È definito un campo di intestazione sostitutivo, chiamato campo DS (DS Field), che è destinato a sostituire le definizioni esistenti dell'ottetto TOS IPv4 [RFC791] e dell'ottetto Traffic Class IPv6 [IPv6].
Sei bit del campo DS sono utilizzati come codepoint (DSCP, Differentiated Services Codepoint) per selezionare il PHB che un pacchetto sperimenta in ciascun nodo. Un campo di due bit attualmente inutilizzato (CU, Currently Unused) è riservato e la sua definizione e interpretazione sono al di fuori dell'ambito di questo documento. Il valore dei bit CU viene ignorato dai nodi conformi ai servizi differenziati quando si determina il comportamento per hop da applicare a un pacchetto ricevuto.
La struttura del campo DS è presentata di seguito:
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| DSCP | CU |
+---+---+---+---+---+---+---+---+
DSCP: differentiated services codepoint (codepoint di servizi differenziati)
CU: currently unused (attualmente inutilizzato)
In una notazione di valore 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 mostrato sopra), e il bit più a destra indica il bit 5.
Gli implementatori dovrebbero notare che il campo DSCP è largo sei bit. I nodi conformi DS devono (MUST) selezionare i PHB confrontando l'intero campo DSCP a 6 bit, ad esempio, trattando il valore del campo come un indice di tabella che viene utilizzato per selezionare un particolare meccanismo di gestione dei pacchetti che è stato implementato in quel dispositivo. Il valore del campo CU deve (MUST) essere ignorato dalla selezione PHB. Il campo DSCP è definito come un campo non strutturato per facilitare la definizione di futuri comportamenti per hop.
Con alcune eccezioni note di seguito, la mappatura dei codepoint ai PHB deve (MUST) essere configurabile. Un nodo conforme DS deve (MUST) supportare l'equivalente logico di una tabella di mappatura configurabile dai codepoint ai PHB. Le specifiche PHB devono (MUST) includere un codepoint predefinito raccomandato, che deve (MUST) essere unico per i codepoint nello spazio standard (vedi Sez. 6). Le implementazioni dovrebbero (SHOULD) supportare le mappature raccomandate da codepoint a PHB nella loro configurazione predefinita. Gli operatori possono scegliere di utilizzare codepoint diversi per un PHB, sia in aggiunta che al posto del predefinito raccomandato. Si noti che se gli operatori scelgono di farlo, la rimarcatura dei campi DS potrebbe essere necessaria ai confini amministrativi anche se gli stessi PHB sono implementati su entrambi i lati del confine.
Vedere [ARCH] per ulteriori discussioni sulla rimarcatura.
Le eccezioni alla configurabilità generale riguardano i codepoint xxx000 e sono indicate nelle Sez. 4.2.2 e 4.3.
I pacchetti ricevuti con un codepoint non riconosciuto dovrebbero (SHOULD) essere inoltrati come se fossero contrassegnati per il comportamento predefinito (vedi Sez. 4), e i loro codepoint non dovrebbero essere modificati. Tali pacchetti non devono (MUST NOT) causare il malfunzionamento del nodo di rete.
La struttura del campo DS mostrata sopra è incompatibile con la definizione esistente dell'ottetto TOS IPv4 in [RFC791]. La presunzione è che i domini DS si proteggano distribuendo nodi di confine di rimarcatura, come dovrebbero fare le reti che utilizzano le designazioni di priorità RFC 791. La procedura operativa corretta dovrebbe (SHOULD) seguire [RFC791], che afferma: "Se l'uso effettivo di queste designazioni di priorità è motivo di preoccupazione per una particolare rete, è responsabilità di quella rete controllare l'accesso a, e l'uso di, tali designazioni di priorità." La convalida del valore del campo DS ai confini DS ha senso in ogni caso poiché un nodo a monte può facilmente impostarlo su qualsiasi valore arbitrario. I domini DS che non sono isolati da nodi di confine adeguatamente configurati possono fornire un servizio imprevedibile.
I nodi possono (MAY) riscrivere il campo DS secondo necessità per fornire un servizio locale o end-to-end desiderato. Le specifiche delle traduzioni dei campi DS ai confini DS sono oggetto di accordi di livello di servizio tra fornitori e utenti e sono al di fuori dell'ambito di questo documento. I PHB standardizzati consentono ai fornitori di costruire i loro servizi da un insieme ben noto di trattamenti di inoltro dei pacchetti che ci si può aspettare siano presenti nelle apparecchiature di molti fornitori.