1. Introduction (Introduzione)
I Servizi Differenziati (Differentiated Services) mirano a fornire un framework e dei componenti di base per consentire il deployment di una discriminazione di servizio scalabile (scalable service discrimination) su Internet. L'approccio dei servizi differenziati cerca di accelerare il deployment separando l'architettura in due componenti principali, uno dei quali è abbastanza ben compreso e l'altro sta appena iniziando ad essere compreso. A questo riguardo, è guidata dal design originale di Internet che ha separato le componenti di inoltro (forwarding) e routing. L'inoltro dei pacchetti (packet forwarding) è un compito relativamente semplice che deve essere eseguito il più rapidamente possibile pacchetto per pacchetto. L'inoltro utilizza l'header del pacchetto per trovare una voce in una tabella di routing, che determina l'interfaccia di uscita del pacchetto. Il routing imposta le voci in quella tabella e deve riflettere varie scelte di transito e altre politiche, e potrebbe anche dover tracciare i guasti delle route. La tabella di routing viene mantenuta come processo in background rispetto al compito di inoltro. Inoltre, il routing è un compito più complesso e ha continuato ad evolversi negli ultimi vent'anni.
Allo stesso modo, l'architettura dei servizi differenziati comprende due componenti principali: un comportamento abbastanza ben compreso nel percorso di inoltro (forwarding path) e una componente di politica e allocazione (allocation) in background più complessa e ancora in via di sviluppo che configura i parametri utilizzati nel percorso di inoltro. Il comportamento del percorso di inoltro include il trattamento differenziale (differential treatment) che i singoli pacchetti subiscono, implementato da discipline di servizio di coda (queue service disciplines) e/o discipline di gestione della coda (queue management disciplines). Questi comportamenti per-hop (per-hop behaviors) sono utili e necessari sui nodi di rete per fornire un trattamento differenziato dei pacchetti, indipendentemente da come vengono costruiti i servizi end-to-end o intra-dominio. Ci concentriamo sulla semantica generale (general semantics) dei comportamenti piuttosto che sui meccanismi specifici utilizzati per implementarli, perché questi comportamenti dovrebbero evolvere meno rapidamente dei meccanismi.
I comportamenti per-hop e i meccanismi per selezionarli pacchetto per pacchetto possono essere deployati nei nodi di rete oggi, ed è questo aspetto dell'architettura dei servizi differenziati che viene affrontato per primo. Inoltre, nel percorso di inoltro, può essere necessario eseguire monitoraggio (monitoring), policing e shaping sul traffico di rete designato per un trattamento "speciale" al fine di far rispettare i requisiti associati alla fornitura di un trattamento speciale. I meccanismi per questo tipo di condizionamento del traffico (traffic conditioning) sono anche abbastanza ben compresi. Il deployment diffuso di tali condizionatori di traffico è anche importante per consentire la costruzione di servizi, ma il loro uso effettivo nella costruzione di servizi può evolvere nel tempo.
La configurazione degli elementi di rete riguardo a quali pacchetti ricevono un trattamento speciale e quali tipi di regole applicare all'uso delle risorse è molto meno ben compresa. Tuttavia, è possibile deployare servizi differenziati utili in una rete utilizzando politiche semplici e configurazione statica. Come descritto in [ARCH], ci sono molti modi per configurare i comportamenti per-hop e i condizionatori di traffico per creare servizi. Questo processo fornirà esperienza aggiuntiva per guidare politiche e allocazione più complesse. I comportamenti di base del percorso di inoltro possono rimanere gli stessi mentre questa componente dell'architettura evolve. Poiché l'esperienza di costruzione di tali servizi continuerà per un po' di tempo, evitiamo di standardizzare questa costruzione poiché sarebbe prematura. Inoltre, evitiamo molti dei dettagli della costruzione del servizio perché sono coperti da contratti legali tra entità diverse, il che è al di fuori dell'ambito dell'IETF.
Questo documento si concentra sulla componente del percorso di inoltro. Nel percorso di trasmissione dei pacchetti, i servizi differenziati vengono realizzati mappando un codepoint (codepoint) contenuto in un campo dell'header del pacchetto IP a un particolare trattamento di inoltro (forwarding treatment), o comportamento per-hop (per-hop behavior, PHB), presso ciascun nodo di rete lungo il suo percorso. Il codepoint può essere uno di un insieme di valori obbligatori (mandatory values) definiti in questo documento, uno di un insieme di valori raccomandati (recommended values) da definire in documenti futuri, oppure può avere un significato puramente locale. Si prevede che il PHB venga implementato impiegando varie discipline di servizio di coda e/o di gestione della coda sulle interfacce di uscita dei nodi di rete: ad esempio, servizio di coda weighted round-robin (WRR) o gestione della coda con priorità di scarto (drop-preference).
La marcatura (marking) viene eseguita da condizionatori di traffico ai confini della rete (first-hop router o source host), inclusi i confini amministrativi. I condizionatori di traffico possono includere primitive di marcatura, misurazione (metering), policing e shaping (questi meccanismi sono descritti in [ARCH]). I servizi vengono realizzati attraverso l'uso di particolari meccanismi di classificazione dei pacchetti e condizionamento del traffico ai confini e dalla concatenazione (concatenation) di comportamenti per-hop lungo il percorso di transito del traffico. L'obiettivo dell'architettura dei servizi differenziati è specificare questi componenti di base per l'estensibilità futura, sia nel numero e nei tipi di componenti che nei servizi costruiti da essi.
La terminologia utilizzata in questo memo è definita nella Sezione 2. La definizione del campo dei servizi differenziati (DS field) è presentata nella Sezione 3. La Sezione 4 affronta il desiderio di compatibilità all'indietro parziale con l'uso corrente del campo IPv4 Precedence; la soluzione introduce i Codepoint Selettori di Classe (Class Selector Codepoints) e il PHB Conforme al Selettore di Classe (Class Selector Compliant PHB). La Sezione 5 presenta linee guida per la standardizzazione dei comportamenti per-hop. La Sezione 6 tratta le linee guida per l'assegnazione dei codepoint. La Sezione 7 tratta le considerazioni sulla sicurezza.
Questo documento è una descrizione concisa del campo DS e del suo uso. È destinato ad essere letto in congiunzione con l'architettura dei servizi differenziati [ARCH].
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" devono essere interpretate come descritto in [RFC2119].