4. Definizioni storiche dei codepoint e requisiti PHB (Historical Codepoint Definitions and PHB Requirements)
Il campo DS avrà una compatibilità all'indietro limitata con la pratica attuale, come descritto in questa sezione. La compatibilità all'indietro è affrontata in due modi. Innanzitutto, ci sono comportamenti per hop già ampiamente utilizzati (ad esempio, quelli che soddisfano i requisiti di accodamento di priorità IPv4 specificati in [RFC1812]), e desideriamo consentirne l'uso continuato nei nodi conformi DS. Inoltre, ci sono alcuni codepoint che corrispondono all'uso storico del campo IP Precedence e riserviamo questi codepoint per mappare a PHB che soddisfano i requisiti generali specificati nella Sez. 4.2.2.2, sebbene i PHB di servizi differenziati specifici mappati da questi codepoint possano (MAY) avere specifiche aggiuntive.
Non viene fatto alcun tentativo di mantenere la compatibilità all'indietro con i bit "DTR" o TOS dell'ottetto TOS IPv4, come definito in [RFC791].
4.1 Un PHB predefinito (A Default PHB)
Un PHB "predefinito" deve (MUST) essere disponibile in un nodo conforme DS. Questo è il comune comportamento di inoltro best-effort disponibile nei router esistenti come standardizzato in [RFC1812]. Quando non sono in atto altri accordi, si presume che i pacchetti appartengano a questo aggregato. Tali pacchetti possono (MAY) essere inviati in una rete senza aderire a regole particolari e la rete consegnerà il maggior numero possibile di questi pacchetti il più rapidamente possibile, soggetto ad altri vincoli di politica delle risorse. Un'implementazione ragionevole di questo PHB sarebbe una disciplina di accodamento che invia pacchetti di questo aggregato ogni volta che il link di output non è richiesto per soddisfare un altro PHB. Una politica ragionevole per costruire servizi garantirebbe che l'aggregato non sia "affamato". Ciò potrebbe essere applicato da un meccanismo in ciascun nodo che riserva alcune risorse minime (ad esempio, buffer, larghezza di banda) per aggregati di comportamento predefinito. Ciò consente ai mittenti che non sono consapevoli dei servizi differenziati di continuare a utilizzare la rete nello stesso modo di oggi. L'impatto dell'introduzione di servizi differenziati in un dominio sulle aspettative di servizio dei suoi clienti e peer è una questione complessa che coinvolge decisioni politiche del dominio ed è 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) mappare a un PHB che soddisfa queste specifiche. Il codepoint scelto per il comportamento predefinito è compatibile con la pratica esistente [RFC791]. Dove un codepoint non è mappato a un PHB standardizzato o di uso locale, dovrebbe (SHOULD) essere mappato al PHB predefinito.
Un pacchetto inizialmente contrassegnato per il comportamento predefinito può (MAY) essere ricontrassegnato con un altro codepoint quando passa un confine in un dominio DS in modo che venga inoltrato utilizzando un PHB diverso all'interno di quel dominio, possibilmente soggetto a qualche accordo negoziato tra i domini peer.
4.2 Uso passato e futuro del campo IP Precedence (Once and Future IP Precedence Field Use)
Desideriamo mantenere una qualche forma di compatibilità all'indietro con gli usi attuali del campo IP Precedence: bit 0-2 dell'ottetto TOS IPv4. Esistono router che utilizzano il campo IP Precedence per selezionare trattamenti di inoltro per hop diversi in modo simile all'uso qui proposto per il campo DSCP. Pertanto, un'architettura di servizi differenziati prototipo semplice può essere rapidamente implementata configurando appropriatamente questi router. Inoltre, i sistemi IP oggi comprendono la posizione del campo IP Precedence, e quindi se questi bit vengono utilizzati in modo simile quando viene implementata l'attrezzatura conforme DS, è improbabile che si verifichino guasti significativi durante l'implementazione iniziale. 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 impiegati in modo simile a, o che comprende, gli usi implementati del campo IP Precedence.
4.2.1 Storia ed evoluzione breve di IP Precedence
Il campo IP Precedence è in qualche modo un 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 tre bit potrebbe assumere furono assegnati a vari usi, incluso il traffico di controllo di rete, il 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 si presumeva che tutti i valori del campo IP Precedence avessero significato oltre i confini, ad esempio "La designazione di precedenza del controllo di rete è destinata ad essere utilizzata solo all'interno di una rete. L'uso e il controllo effettivi di tale designazione spettano a ciascuna rete." [RFC791]
Sebbene i primi BBN IMP implementassero la funzionalità Precedence, i primi router commerciali e il codice di inoltro IP UNIX generalmente non lo facevano. Man mano che le reti diventavano più complesse e i requisiti dei clienti crescevano, i fornitori di router commerciali svilupparono modi per implementare vari tipi di servizi di accodamento, incluso l'accodamento prioritario, che erano generalmente basati su politiche codificate in filtri nei router, che esaminavano indirizzi IP, numeri di protocollo IP, porte TCP o UDP e altri campi di intestazione. IP Precedence era ed è tra le opzioni che tali filtri possono esaminare.
In breve, IP Precedence è ampiamente implementato e ampiamente utilizzato, se non esattamente nel modo previsto in [RFC791]. Questo è stato riconosciuto in [RFC1122], che afferma che mentre l'uso del campo IP Precedence è valido, l'assegnazione specifica delle priorità in [RFC791] era meramente storica.
4.2.2 Sussunzione di IP Precedence nei codepoint del selettore di classe
Una specifica dei trattamenti di inoltro dei pacchetti selezionati dal campo IP Precedence oggi dovrebbe essere abbastanza generale; probabilmente non abbastanza specifica per costruire servizi prevedibili nel framework dei servizi differenziati. Per preservare una compatibilità all'indietro parziale con gli usi attuali noti del campo IP Precedence senza sacrificare la flessibilità futura, abbiamo adottato l'approccio di descrivere i requisiti minimi su un insieme di PHB compatibili con la maggior parte dei trattamenti di inoltro implementati selezionati dal campo IP Precedence. Inoltre, forniamo un insieme di codepoint che devono (MUST) mappare a PHB che soddisfano questi requisiti minimi. I PHB mappati da questi codepoint possono (MAY) avere un elenco più dettagliato di specifiche oltre a quelle richieste qui indicate. Altri codepoint possono (MAY) mappare a questi stessi PHB. Ci riferiamo a questo insieme di codepoint come codepoint del selettore di classe (Class Selector Codepoints), e i requisiti minimi per i PHB a cui questi codepoint possono mappare sono chiamati requisiti PHB del selettore di classe (Class Selector PHB Requirements).
4.2.2.1 I codepoint del selettore di classe
I valori del campo DS di xxx000|xx, o DSCP = xxx000 e sottocampo CU non specificato, sono riservati come un insieme di codepoint del selettore di classe. I PHB mappati da questi codepoint devono (MUST) soddisfare i requisiti PHB del selettore di classe oltre a preservare il requisito PHB predefinito sul codepoint 000000 (Sez. 4.1).
4.2.2.2 I requisiti PHB del selettore di classe
Ci riferiamo a un codepoint del selettore di classe con un valore numerico maggiore di un altro codepoint del selettore di classe come avente un ordine relativo superiore, mentre un codepoint del selettore di classe con un valore numerico minore di un altro codepoint del selettore di classe si dice che abbia un ordine relativo inferiore. L'insieme di PHB mappati dagli otto codepoint del selettore di classe deve (MUST) produrre almeno due classi di traffico inoltrate indipendentemente, e i PHB selezionati da un codepoint del selettore di classe dovrebbero (SHOULD) dare ai pacchetti una probabilità di inoltro tempestivo non inferiore a quella data ai pacchetti contrassegnati con un codepoint del selettore di classe di ordine relativo inferiore, in condizioni operative ragionevoli e carichi di traffico. Un pacchetto scartato è considerato un caso estremo di inoltro intempestivo. Inoltre, i PHB selezionati dai codepoint 11x000 devono (MUST) dare ai pacchetti un trattamento di inoltro preferenziale 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 codepoint del selettore di classe distinti dovrebbero (SHOULD) essere inoltrati indipendentemente; cioè, i pacchetti contrassegnati con codepoint del selettore di classe diversi possono (MAY) essere riordinati. Un nodo di rete può (MAY) imporre limiti sulla quantità delle risorse del nodo che possono essere utilizzate da ciascuno di questi PHB.
I gruppi PHB la cui specifica soddisfa questi requisiti sono denominati PHB conformi al selettore di classe (Class Selector Compliant PHBs).
I requisiti PHB del selettore di classe sul codepoint 000000 sono compatibili con quelli elencati per il PHB predefinito nella Sez. 4.1.
4.2.2.3 Uso dei requisiti PHB del selettore di classe per la compatibilità IP Precedence
Un nodo di rete conforme DS può essere implementato 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) mappare a tale insieme di PHB. Poiché è anche possibile mappare più codepoint allo stesso PHB, il fornitore o l'amministratore di rete può (MAY) configurare il nodo di rete per mappare i codepoint ai PHB indipendentemente dai bit 3-5 del campo DSCP per produrre una rete compatibile con l'uso storico di IP Precedence. Quindi, ad esempio, il codepoint 011010 mapperebbe allo stesso PHB del codepoint 011000.
4.2.2.4 Meccanismi di esempio per l'implementazione di gruppi PHB conformi al selettore di classe
I PHB conformi al selettore di classe possono essere realizzati da una varietà di meccanismi, inclusi strict priority queueing, weighted fair queueing (WFQ), WRR o varianti [RPS, HPFQA, DRR], o Class-Based Queuing [CBQ]. La distinzione tra PHB e meccanismi è descritta più dettagliatamente nella Sez. 5.
È importante notare che questi meccanismi potrebbero essere disponibili tramite altri PHB (standardizzati o meno) disponibili nell'equipaggiamento di un particolare fornitore. Ad esempio, documenti futuri potrebbero standardizzare un gruppo PHB Strict Priority Queueing per un insieme di codepoint raccomandati. Un amministratore di rete potrebbe configurare questi router per selezionare i PHB Strict Priority Queueing con codepoint xxx000 in conformità con i requisiti di questo documento.
Come ulteriore esempio, un altro fornitore potrebbe impiegare un meccanismo CBQ nei suoi router. Il meccanismo CBQ potrebbe essere utilizzato per implementare i PHB Strict Priority Queueing così come un insieme di PHB conformi al selettore di classe con una gamma di funzionalità più ampia di quella disponibile in un insieme di PHB che non fanno altro che soddisfare i requisiti minimi PHB del selettore di classe.
4.3 Riepilogo (Summary)
Questo documento definisce i codepoint xxx000 come i codepoint del selettore di classe, dove i PHB selezionati da questi codepoint devono (MUST) soddisfare i requisiti PHB del selettore di classe descritti nella Sez. 4.2.2.2. Questo viene fatto per preservare un livello utile di compatibilità all'indietro con gli usi attuali del campo IP Precedence in Internet senza limitare indebitamente la flessibilità futura. Inoltre, il codepoint 000000 è utilizzato come valore PHB predefinito per Internet e, come tale, non è configurabile. I restanti sette codepoint del selettore di classe diversi da zero sono configurabili solo nella misura in cui mappano a PHB che soddisfano i requisiti nella Sez. 4.2.2.2.