1. Introduzione (Introduction)
I servizi differenziati (Differentiated Services) sono destinati a fornire un framework e blocchi costitutivi per consentire la distribuzione di una discriminazione del servizio scalabile in Internet. L'approccio dei servizi differenziati mira ad accelerare la distribuzione separando l'architettura in due componenti principali, una delle quali è abbastanza ben compresa e l'altra sta appena iniziando a essere compresa. In questo, siamo guidati dal design originale di Internet dove è stata presa la decisione di separare i componenti di inoltro e routing. L'inoltro dei pacchetti è il compito relativamente semplice che deve essere eseguito su base per pacchetto il più rapidamente possibile. L'inoltro utilizza l'intestazione del pacchetto per trovare una voce in una tabella di routing che determina l'interfaccia di output del pacchetto. Il routing imposta le voci in quella tabella e potrebbe dover riflettere una serie di politiche di transito e altre nonché tenere traccia dei guasti delle route. Le tabelle di routing sono mantenute come processo in background rispetto al compito di inoltro. Inoltre, il routing è il compito più complesso ed è continuato a evolversi negli ultimi 20 anni.
Analogamente, l'architettura dei servizi differenziati contiene due componenti principali. Una è il comportamento abbastanza ben compreso nel percorso di inoltro e l'altra è il componente di politica e allocazione in background più complesso e ancora emergente che configura i parametri utilizzati nel percorso di inoltro. I comportamenti del percorso di inoltro includono il trattamento differenziale che un singolo pacchetto riceve, come implementato dalle discipline di servizio di coda e/o dalle discipline di gestione della coda. Questi comportamenti per hop (Per-Hop Behaviors, PHB) sono utili e richiesti nei nodi di rete per fornire un trattamento differenziato dei pacchetti, indipendentemente da come costruiamo servizi end-to-end o intra-dominio. Il nostro focus è sulla semantica generale dei comportamenti piuttosto che sui meccanismi specifici utilizzati per implementarli, poiché questi comportamenti evolveranno meno rapidamente dei meccanismi.
I comportamenti per hop e i meccanismi per selezionarli su base per pacchetto possono essere distribuiti nei nodi di rete oggi ed è questo aspetto dell'architettura dei servizi differenziati che viene affrontato per primo. Inoltre, il percorso di inoltro può richiedere che venga eseguito un certo monitoraggio, controllo e modellamento sul traffico di rete designato per un trattamento "speciale" al fine di far rispettare i requisiti associati alla fornitura del trattamento speciale. Anche i meccanismi per questo tipo di condizionamento del traffico (Traffic Conditioning) sono abbastanza ben compresi. L'ampia distribuzione di tali condizionatori di traffico è importante anche per consentire la costruzione di servizi, sebbene il loro uso effettivo nella costruzione di servizi possa evolversi nel tempo.
La configurazione degli elementi di rete rispetto a quali pacchetti ricevono un trattamento speciale e quali tipi di regole devono essere applicate all'uso delle risorse è molto meno ben compresa. Tuttavia, è possibile distribuire servizi differenziati utili nelle reti utilizzando politiche semplici e configurazioni statiche. Come descritto in [ARCH], ci sono diversi modi per comporre comportamenti per hop e condizionatori di traffico per creare servizi. Nel processo, si acquisisce esperienza aggiuntiva che guiderà politiche e allocazioni più complesse. I comportamenti di base nel percorso di inoltro possono rimanere gli stessi mentre questo componente dell'architettura evolve. Le esperienze con la costruzione di tali servizi continueranno per un certo tempo, quindi evitiamo di standardizzare questa costruzione in quanto è prematura. Inoltre, molti dei dettagli della costruzione del servizio sono coperti da accordi legali tra diverse entità commerciali e lo evitiamo in quanto è molto al di fuori dell'ambito dell'IETF.
Questo documento si concentra sul componente del percorso di inoltro. Nel percorso di inoltro dei pacchetti, i servizi differenziati sono realizzati mappando il codepoint contenuto in un campo nell'intestazione del pacchetto IP a un particolare trattamento di inoltro, o comportamento per hop (PHB), a ciascun nodo di rete lungo il suo percorso. I codepoint possono essere scelti da un insieme di valori obbligatori definiti più avanti in questo documento, da un insieme di valori raccomandati da definire in documenti futuri, o possono avere un significato puramente locale. I PHB dovrebbero essere implementati utilizzando una gamma di discipline di servizio di coda e/o di gestione della coda sulla coda dell'interfaccia di output di un nodo di rete: ad esempio, il servizio di coda round-robin ponderato (WRR, Weighted Round-Robin) o la gestione della coda con preferenza di scarto.
La marcatura viene eseguita da condizionatori di traffico ai confini della rete, inclusi i bordi della rete (router di primo hop o host sorgente) e i confini amministrativi. I condizionatori di traffico possono includere le primitive di marcatura, misurazione, controllo e modellamento (questi meccanismi sono descritti in [ARCH]). I servizi sono realizzati mediante l'uso di particolari meccanismi di classificazione dei pacchetti e condizionamento del traffico ai confini accoppiati con la concatenazione di comportamenti per hop lungo il percorso di transito del traffico. Un obiettivo dell'architettura dei servizi differenziati è specificare questi blocchi costitutivi per l'estensibilità futura, sia del numero e tipo di blocchi costitutivi sia dei servizi costruiti da essi.
La terminologia utilizzata in questo memo è definita nella Sez. 2. La definizione del campo dei servizi differenziati (campo DS) è fornita nella Sez. 3. Nella Sez. 4, discutiamo il desiderio di compatibilità parziale all'indietro con l'uso corrente del campo IP Precedence di IPv4. Come soluzione, introduciamo i codepoint del selettore di classe (Class Selector Codepoints) e i PHB conformi al selettore di classe (Class Selector Compliant PHBs). La Sez. 5 presenta le linee guida per la standardizzazione dei comportamenti per hop. La Sez. 6 discute le linee guida per l'allocazione dei codepoint. La Sez. 7 copre le considerazioni sulla sicurezza.
Questo documento è una descrizione concisa del campo DS e dei suoi usi. È destinato a essere letto insieme all'architettura dei servizi differenziati [ARCH].
Le parole chiave "deve (MUST)", "non deve (MUST NOT)", "richiesto (REQUIRED)", "deve (SHALL)", "non deve (SHALL NOT)", "dovrebbe (SHOULD)", "non dovrebbe (SHOULD NOT)", "raccomandato (RECOMMENDED)", "può (MAY)" e "opzionale (OPTIONAL)" in questo documento devono essere interpretate come descritto in [RFC2119].