4. Historical Codepoint Definitions and PHB Requirements (Definizioni storiche dei codepoint e requisiti PHB)

Il campo DS ha una compatibilità all'indietro limitata con la pratica corrente, come descritto in questa sezione. La compatibilità all'indietro viene affrontata in due modi. In primo luogo, ci sono comportamenti per-hop che sono già ampiamente utilizzati (ad esempio, quelli che soddisfano i requisiti di accodamento IPv4 Precedence specificati in [RFC1812]) e desideriamo consentire il loro uso continuo nei nodi conformi DS. Inoltre, ci sono diversi codepoint che corrispondono all'uso storico del campo IP Precedence, e riserviamo questi codepoint per essere mappati a PHB che soddisfano i requisiti generali specificati nella Sezione 4.2.2.2. Tuttavia, i PHB dei servizi differenziati specifici a cui questi codepoint sono mappati possono (MAY) avere specifiche aggiuntive.

Non viene fatto alcun tentativo di mantenere la compatibilità all'indietro con i bit "DTR" o TOS dell'ottetto TOS di IPv4 definiti in [RFC791].

4.1 A Default PHB (Un PHB predefinito)

Un PHB "predefinito" (default) deve (MUST) essere disponibile in un nodo conforme DS; questo è il comportamento di inoltro best-effort (best-effort forwarding behavior) comunemente disponibile nei router esistenti standardizzati in [RFC1812]. In assenza di altri accordi, si presume che i pacchetti appartengano a questo aggregato. Tali pacchetti possono (MAY) essere inviati alla rete senza rispettare alcuna regola particolare e la rete consegnerà il maggior numero possibile di questi pacchetti il più rapidamente possibile, soggetta ad altri vincoli di politica delle risorse. Un'implementazione ragionevole di questo PHB è una disciplina di accodamento che trasmette pacchetti di questo aggregato quando il link di uscita non è richiesto per soddisfare un altro PHB. Una politica ragionevole per la costruzione di servizi è garantire che l'aggregato non sia "affamato" (starved), il che potrebbe essere imposto da un meccanismo in ciascun nodo che riserva risorse minime (ad esempio, buffer, larghezza di banda) per l'aggregato di comportamento predefinito. Ciò consente ai mittenti inconsapevoli dei servizi differenziati di continuare a utilizzare la rete come fanno oggi. Le implicazioni dell'introduzione di servizi differenziati in un dominio sulle aspettative di servizio dei clienti e dei peer sono una questione complessa che coinvolge decisioni politiche da parte del dominio e sono al di fuori dell'ambito di questo documento.

Il codepoint raccomandato (RECOMMENDED) per il PHB predefinito è il pattern di bit '000000'; il valore '000000' deve (MUST) essere mappato a un PHB che soddisfa queste specifiche. Il codepoint scelto per il comportamento predefinito è compatibile con la pratica esistente [RFC791]. Se un codepoint non è mappato a un PHB di standardizzazione o di uso locale, dovrebbe (SHOULD) essere mappato al PHB predefinito.

I pacchetti marcati inizialmente per il comportamento predefinito possono (MAY) essere ri-marcati con un altro codepoint quando attraversano un confine in un dominio DS e possono essere inoltrati con un PHB diverso all'interno di quel dominio, soggetto a qualche accordo negoziato tra domini peer.

4.2 Once and Future IP Precedence Field Use (Uso passato e futuro del campo IP Precedence)

Desideriamo mantenere una qualche forma di compatibilità all'indietro con l'uso corrente del campo IP Precedence (bit 0-2 dell'ottetto TOS di IPv4). Ci sono router che utilizzano il campo IP Precedence per selezionare diversi trattamenti di inoltro per-hop in modo simile a quello qui proposto per il campo DSCP. Pertanto, configurando correttamente questi router, un'architettura prototipo semplice di servizi differenziati può essere rapidamente deployata. Inoltre, poiché i sistemi IP di oggi comprendono la posizione del campo IP Precedence, è meno probabile che si verifichino fallimenti catastrofici durante il deployment iniziale se questi bit vengono utilizzati in modo simile quando vengono deployate le apparecchiature conformi DS. In altre parole, la conformità DS rigorosa non deve essere onnipresente, anche all'interno della rete di un singolo fornitore di servizi, se i bit 0-2 del campo DSCP vengono utilizzati in modo simile o inclusivo rispetto all'uso deployato del campo IP Precedence.

4.2.1 IP Precedence History and Evolution in Brief (Storia ed evoluzione di IP Precedence in breve)

Il campo IP Precedence è, per così dire, il precursore del campo DS. IP Precedence e il campo IP Precedence furono definiti per la prima volta in [RFC791]. I valori che il campo IP Precedence a 3 bit può assumere furono assegnati a vari usi, inclusi traffico di controllo di rete, traffico di routing e vari livelli di privilegio. Il livello più basso di privilegio era considerato "traffico di routine". In [RFC791], la nozione di Precedence era definita in modo ampio come "Una misura indipendente dell'importanza di questo datagramma". Non tutti i valori del campo IP Precedence dovevano avere un significato attraverso i confini. Ad esempio, "La designazione di priorità di Network Control è destinata ad essere utilizzata solo all'interno di una rete. L'uso effettivo e il controllo di questa designazione dipendono da ogni rete." [RFC791]

I primi IMP BBN implementarono la funzionalità Precedence, ma i primi router commerciali e il codice di inoltro IP UNIX generalmente non lo implementarono. Man mano che le reti diventavano più complesse e i requisiti dei clienti aumentavano, i fornitori di router commerciali svilupparono modi per implementare vari tipi di servizi di accodamento, incluso l'accodamento prioritario (priority queueing). Questi erano generalmente basati su politiche codificate in filtri nel router che esaminavano indirizzi IP, numeri di protocollo IP, porte TCP o UDP e altri campi di header. IP Precedence era una delle opzioni che questi filtri potevano esaminare.

In sintesi, IP Precedence non è ampiamente deployato e ampiamente utilizzato, se non come previsto in [RFC791]. Ciò fu riconosciuto in [RFC1122], che affermò che l'uso del campo IP Precedence era valido, ma le assegnazioni di priorità specifiche di [RFC791] erano semplicemente storiche.

4.2.2 Subsuming IP Precedence into Class Selector Codepoints (Incorporazione di IP Precedence nei codepoint selettori di classe)

Una specifica del trattamento di inoltro dei pacchetti selezionato oggi dal campo IP Precedence dovrebbe essere abbastanza generale; forse non abbastanza specifica per costruire servizi prevedibili nel framework dei servizi differenziati. Per mantenere la compatibilità all'indietro parziale con l'uso corrente noto del campo IP Precedence senza sacrificare la flessibilità futura, abbiamo adottato un approccio che descrive i requisiti minimi per un insieme di PHB compatibili con la maggior parte dei trattamenti di inoltro deployati selezionati dal campo IP Precedence. Inoltre, forniamo un insieme di codepoint che devono (MUST) essere mappati a PHB che soddisfano questi requisiti minimi. I PHB a cui questi codepoint sono mappati possono (MAY) avere un elenco di specifiche più dettagliate oltre a quelle minime qui indicate. Altri codepoint possono (MAY) essere mappati agli stessi PHB di questi. Chiamiamo questo insieme di codepoint i Class Selector Codepoints e chiamiamo i requisiti minimi per i PHB a cui questi codepoint possono essere mappati i Class Selector PHB Requirements.

4.2.2.1 The Class Selector Codepoints (I codepoint selettori di classe)

I valori del campo DS 'xxx000|xx', o DSCP = 'xxx000' con sottocampo CU non specificato, sono riservati come insieme di Class Selector Codepoints. I PHB a cui questi codepoint sono mappati devono (MUST) soddisfare i Class Selector PHB Requirements oltre a mantenere i requisiti del PHB predefinito (Sezione 4.1) per il codepoint '000000'.

4.2.2.2 The Class Selector PHB Requirements (I requisiti PHB del selettore di classe)

Un Class Selector Codepoint con un valore numerico maggiore di un altro Class Selector Codepoint si dice che abbia un ordine relativo più alto (higher relative order), e un Class Selector Codepoint con un valore numerico inferiore a un altro Class Selector Codepoint si dice che abbia un ordine relativo più basso (lower relative order). L'insieme dei PHB a cui gli otto Class Selector Codepoints sono mappati deve (MUST) produrre almeno due classi di traffico inoltrate indipendentemente, e il PHB selezionato da un Class Selector Codepoint dovrebbe (SHOULD) dare a un pacchetto una probabilità di inoltro tempestivo (probability of timely forwarding) non inferiore a quella data ai pacchetti marcati con un Class Selector codepoint di ordine relativo inferiore, in condizioni operative e carichi di traffico ragionevoli. Un pacchetto scartato è considerato un caso estremo di inoltro intempestivo (extreme case of untimely forwarding). Inoltre, il PHB selezionato dai codepoint '11x000' deve (MUST) dare a un pacchetto un trattamento di inoltro preferenziale (preferential forwarding treatment) rispetto al PHB selezionato dal codepoint '000000' per preservare l'uso comune dei valori IP Precedence '110' e '111' per il traffico di routing.

Inoltre, i PHB selezionati da diversi Class Selector Codepoints dovrebbero (SHOULD) essere inoltrati indipendentemente; cioè, i pacchetti marcati con diversi Class Selector Codepoints possono (MAY) essere riordinati. Un nodo di rete può (MAY) imporre limiti alla quantità di risorse del nodo disponibili per ciascuno di questi PHB.

Un gruppo PHB con una specifica che soddisfa questo requisito è chiamato PHB conformi al selettore di classe (Class Selector Compliant PHBs).

I Class Selector PHB Requirements per il codepoint '000000' sono compatibili con quelli elencati per il PHB predefinito nella Sezione 4.1.

4.2.2.3 Using the Class Selector PHB Requirements for IP Precedence Compatibility (Utilizzo dei requisiti PHB del selettore di classe per la compatibilità IP Precedence)

Un nodo di rete conforme DS può essere deployato con un insieme di uno o più gruppi PHB conformi al selettore di classe. Questo documento afferma che l'insieme di codepoint 'xxx000' deve (MUST) essere mappato a tale insieme di PHB. Dato che è anche consentito mappare più codepoint allo stesso PHB, un fornitore o amministratore di rete può (MAY) configurare un nodo di rete per mappare i codepoint ai PHB indipendentemente dai bit 3-5 del campo DSCP, producendo una rete compatibile con l'uso storico di IP Precedence. Così, ad esempio, il codepoint '011010' verrebbe mappato allo stesso PHB del codepoint '011000'.

4.2.2.4 Example Mechanisms for Implementing Class Selector Compliant PHB Groups (Meccanismi di esempio per l'implementazione di gruppi PHB conformi al selettore di classe)

Un PHB conforme al selettore di classe può essere realizzato da vari meccanismi, incluso l'accodamento prioritario rigoroso (strict priority queueing), accodamento equo ponderato (weighted fair queueing, WFQ), WRR o varianti [RPS, HPFQA, DRR], o accodamento basato su classi (Class-Based Queuing) [CBQ]. La differenza tra PHB e meccanismi è descritta più dettagliatamente nella Sezione 5.

È importante notare che questi meccanismi potrebbero essere disponibili tramite altri PHB (standardizzati o meno) disponibili su particolari apparecchiature del fornitore. Ad esempio, un documento futuro potrebbe standardizzare un gruppo PHB di accodamento prioritario rigoroso (Strict Priority Queueing PHB Group) per un insieme di codepoint raccomandati. Un amministratore di rete può configurare questi router per selezionare il PHB di accodamento prioritario rigoroso con i codepoint 'xxx000', in conformità con i requisiti di questo documento.

Come ulteriore esempio, un altro fornitore potrebbe adottare il meccanismo CBQ su un router. Il meccanismo CBQ può essere utilizzato per implementare un insieme di PHB conformi al selettore di classe che hanno una gamma di capacità più ampia di quella disponibile con un insieme di PHB che soddisfano solo i requisiti minimi del PHB del selettore di classe, oltre a implementare un PHB di accodamento prioritario rigoroso.

4.3 Summary (Riepilogo)

Questo documento definisce i codepoint 'xxx000' come Class Selector Codepoints. I PHB selezionati da questi codepoint devono (MUST) soddisfare i Class Selector PHB Requirements descritti nella Sezione 4.2.2.2. Ciò è stato fatto per mantenere un livello utile di compatibilità all'indietro con l'uso corrente del campo IP Precedence su Internet senza limitare eccessivamente la flessibilità futura. Inoltre, il codepoint '000000' viene utilizzato come valore PHB predefinito di Internet ed è quindi non configurabile. Gli altri sette Class Selector codepoints non nulli sono configurabili solo nella misura in cui sono mappati a PHB che soddisfano i requisiti della Sezione 4.2.2.2.