1. Introduzione
In un dominio MPLS [MPLS_ARCH], quando un flusso di dati attraversa un percorso comune, può essere stabilito un Label Switched Path (LSP) utilizzando i protocolli di segnalazione MPLS. All'LSR di ingresso (ingress Label Switch Router), a ogni pacchetto viene assegnata un'etichetta e il pacchetto viene trasmesso a valle. In ogni LSR lungo l'LSP, l'etichetta viene usata per inoltrare il pacchetto al next hop.
In un dominio Differentiated Service (Diff-Serv) [DIFF_ARCH] si dice che tutti i pacchetti IP che attraversano un collegamento e richiedono lo stesso comportamento Diff-Serv costituiscono un Behavior Aggregate (BA). Al nodo di ingresso del dominio Diff-Serv, i pacchetti vengono classificati e marcati con un Diff-Serv Code Point (DSCP) che corrisponde al loro Behavior Aggregate. In ogni nodo di transito, il DSCP viene usato per selezionare il Per Hop Behavior (PHB) che determina il trattamento di scheduling e, in alcuni casi, la probabilità di scarto per ciascun pacchetto.
Questo documento specifica una soluzione per supportare i Behavior Aggregate Diff-Serv i cui PHB corrispondenti sono attualmente definiti (in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) su una rete MPLS. Questa soluzione offre inoltre la flessibilità per un facile supporto dei PHB che potranno essere definiti in futuro.
Questa soluzione si basa sull'uso combinato di due tipi di LSP:
-
LSP che possono trasportare più Ordered Aggregate, così che il campo EXP dell'intestazione MPLS Shim trasmetta all'LSR il PHB da applicare al pacchetto (coprendo sia le informazioni sul trattamento di scheduling del pacchetto sia la sua drop precedence).
-
LSP che trasportano solo un singolo Ordered Aggregate, così che il trattamento di scheduling del pacchetto sia dedotto dall'LSR esclusivamente dal valore dell'etichetta del pacchetto, mentre la drop precedence del pacchetto è trasmessa nel campo EXP dell'intestazione MPLS Shim oppure nel meccanismo di scarto selettivo specifico del livello di collegamento di incapsulamento (ATM, Frame Relay, 802.1).
Come indicato in [DIFF_HEADER], "Service providers are not required to use the same node mechanisms or configurations to enable service differentiation within their networks, and are free to configure the node parameters in whatever way that is appropriate for their service offerings and traffic engineering objectives". Pertanto, la soluzione definita in questo documento dà ai Service Provider flessibilità nella selezione di come le classi di servizio Diff-Serv sono sottoposte a Routing o Traffic Engineering all'interno del loro dominio (ad es., classi di servizio distinte supportate tramite LSP distinti e sottoposte a Routing separatamente, oppure tutte le classi di servizio supportate sullo stesso LSP e sottoposte a Routing insieme).
Poiché MPLS è orientato al percorso, può potenzialmente fornire capacità di protezione e ripristino più rapide e prevedibili di fronte a cambiamenti di topologia rispetto ai sistemi IP con routing hop by hop convenzionale. In questo documento ci riferiamo a tali capacità come "protezione MPLS". Sebbene tali capacità e i meccanismi associati siano al di fuori dell'ambito di questa specifica, notiamo che esse possono offrire livelli di protezione diversi a LSP diversi. Poiché la soluzione presentata qui consente ai Service Provider di scegliere come le classi di servizio Diff-Serv sono mappate sugli LSP, la soluzione dà inoltre ai Service Provider flessibilità sul livello di protezione fornito alle diverse classi di servizio Diff-Serv (ad es., alcune classi di servizio possono essere supportate da LSP protetti mentre altre classi di servizio sono supportate da LSP non protetti).
Inoltre, la soluzione specificata in questo documento ottiene la conservazione dello spazio delle etichette e riduce il volume di segnalazione di set-up/tear-down delle etichette, dove possibile, ricorrendo a più LSP per un dato Forwarding Equivalent Class (FEC) [MPLS_ARCH] solo quando è utile o necessario.
Questa specifica consente il supporto dei Differentiated Services sia per il traffico IPv4 sia per il traffico IPv6 trasportato su una rete MPLS. Questo documento descrive solo le operazioni per l'unicast. Il supporto del multicast è oggetto di studio futuro.
La soluzione descritta in questo documento non esclude l'uso segnalato o configurato dei bit EXP per supportare Explicit Congestion Notification [ECN] contemporaneamente a Diff-Serv su MPLS. Tuttavia, le tecniche per supportare ECN in un ambiente MPLS sono al di fuori dell'ambito di questo documento.
1.1. Terminologia
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in RFC 2119.
Si assume che il lettore sia familiare con la terminologia di [MPLS_ARCH], [MPLS_ENCAPS], [MPLS_ATM], [MPLS_FR], inclusi i seguenti:
-
FEC: Forwarding Equivalency Class
-
FTN: FEC-To-NHLFE Map
-
ILM: Incoming Label Map
-
LC-ATM: Label Switching Controlled-ATM (interface)
-
LC-FR: Label Switching Controlled-Frame Relay (interface)
-
LSP: Label Switched Path
-
LSR: Label Switch Router
-
MPLS: Multi-Protocol Label Switching
-
NHLFE: Next Hop Label Forwarding Entry
Si assume che il lettore sia familiare con la terminologia di [DIFF_ARCH], [DIFF_HEADER], [DIFF_AF], [DIFF_EF], inclusi i seguenti:
-
AF: Assured Forwarding
-
BA: Behavior Aggregate
-
CS: Class Selector
-
DF: Default Forwarding
-
DSCP: Differentiated Services Code Point
-
EF: Expedited Forwarding
-
PHB: Per Hop Behavior
Si assume che il lettore sia familiare con la terminologia di [DIFF_NEW], inclusi i seguenti:
-
OA: Ordered Aggregate. L'insieme di Behavior Aggregate che condividono un vincolo di ordinamento.
-
PSC: PHB Scheduling Class. L'insieme di uno o più PHB che sono applicati al/i Behavior Aggregate appartenente/i a un dato OA. Ad esempio, AF1x è un PSC che comprende i PHB AF11, AF12 e AF13. EF è un esempio di PSC che comprende un singolo PHB, il PHB EF.
Sono inoltre usati i seguenti acronimi:
-
CLP: Cell Loss Priority
-
DE: Discard Eligibility
-
SNMP: Simple Network Management Protocol
Infine, i seguenti acronimi sono definiti in questa specifica:
-
E-LSP: EXP-Inferred-PSC LSP
-
L-LSP: Label-Only-Inferred-PSC LSP
1.2. EXP-Inferred-PSC LSPs (E-LSP)
Un singolo LSP può essere usato per supportare uno o più OA. Tali LSP possono supportare fino a otto BA di un dato FEC, indipendentemente da quanti OA coprano questi BA. Con tali LSP, il campo EXP dell'intestazione MPLS Shim viene usato dall'LSR per determinare il PHB da applicare al pacchetto. Ciò include sia il PSC sia la drop preference.
Ci riferiamo a tali LSP come "EXP-inferred-PSC LSPs" (E-LSP), poiché il PSC di un pacchetto trasportato su questo LSP dipende dal valore del campo EXP per quel pacchetto.
Il mapping dal campo EXP al PHB (cioè al PSC e alla drop precedence) per un dato tale LSP è esplicitamente segnalato al set-up dell'etichetta oppure si basa su un mapping preconfigurato.
Le operazioni dettagliate degli E-LSP sono specificate nella sezione 3 più avanti.
1.3. Label-Only-Inferred-PSC LSPs (L-LSP)
Può essere stabilito un LSP separato per una singola coppia <FEC, OA>. Con tali LSP, il PSC è esplicitamente segnalato al momento dell'establishment dell'etichetta, così che dopo l'establishment dell'etichetta l'LSR possa dedurre esclusivamente dal valore dell'etichetta il PSC da applicare a un pacchetto etichettato. Quando si usa l'intestazione Shim, la Drop Precedence che deve essere applicata dall'LSR al pacchetto etichettato è trasmessa all'interno dell'intestazione MPLS Shim del pacchetto etichettato usando il campo EXP. Quando l'intestazione Shim non è usata (ad es., MPLS Over ATM), la Drop Precedence che deve essere applicata dall'LSR al pacchetto etichettato è trasmessa all'interno dell'incapsulamento dell'intestazione del livello di collegamento usando campi di drop precedence specifici del livello di collegamento (ad es., ATM CLP).
Ci riferiamo a tali LSP come "Label-Only-Inferred-PSC LSPs" (L-LSP) poiché il PSC può essere completamente dedotto dall'etichetta senza alcuna altra informazione (ad es., indipendentemente dal valore del campo EXP). Le operazioni dettagliate degli L-LSP sono specificate nella sezione 4 più avanti.
1.4. Operazioni complessive
Per un dato FEC, e salvo le restrizioni specifiche del media identificate nelle sezioni 7, 8 e 9 più avanti, questa specifica consente una qualsiasi delle seguenti combinazioni all'interno di un dominio MPLS Diff-Serv:
-
zero o un numero qualsiasi di E-LSP, e
-
zero o un numero qualsiasi di L-LSP.
L'amministratore di rete seleziona la combinazione effettiva di LSP dall'insieme delle combinazioni consentite e seleziona come i Behavior Aggregate sono effettivamente trasportati su questa combinazione di LSP, al fine di adattarsi al meglio al proprio ambiente e agli obiettivi in termini di supporto Diff-Serv, Traffic Engineering e protezione MPLS. I criteri per selezionare tale combinazione sono al di fuori dell'ambito di questa specifica.
Per un dato FEC, può esserci più di un LSP che trasporta lo stesso OA, ad esempio a scopo di bilanciamento del carico dell'OA; tuttavia, al fine di rispettare i vincoli di ordinamento, tutti i pacchetti di un dato microflow, che potenzialmente si estendono su più BA di un dato Ordered Aggregate, MUST essere trasportati sullo stesso LSP. Viceversa, ogni LSP MUST essere in grado di supportare tutti i BA (attivi) di un dato OA.
Esempi di scenari di deployment sono forniti a titolo informativo nell'APPENDICE A.
1.5. Relazione tra Label e FEC
- [MPLS_ARCH] afferma nella sezione
2.1. Overview' che:Some routers analyze a packet's network layer header not merely to choose the packet's next hop, but also to determine a packet's "precedence" or "class of service". They may then apply different discard thresholds or scheduling disciplines to different packets. MPLS allows (but does not require) the precedence or class of service to be fully or partially inferred from the label. In this case, one may say that the label represents the combination of a FEC and a precedence or class of service.'
In linea con ciò, osserviamo che:
-
Con gli E-LSP, l'etichetta rappresenta la combinazione di un FEC e dell'insieme di BA trasportati sull'E-LSP. Laddove tutti i BA supportati sono trasportati su un E-LSP, l'etichetta rappresenta allora il FEC completo.
-
Con gli L-LSP, l'etichetta rappresenta la combinazione di un FEC e di un OA.
1.6. Prenotazione di banda per E-LSP e L-LSP
Indipendentemente da quale protocollo di label binding sia usato, gli E-LSP e gli L-LSP possono essere stabiliti con o senza prenotazione di banda.
Stabilire un E-LSP o un L-LSP con prenotazione di banda significa che i requisiti di banda per l'LSP sono segnalati al momento dell'establishment dell'LSP. Tali requisiti di banda segnalati possono essere usati dagli LSR al momento dell'establishment per eseguire il controllo di ammissione dell'LSP segnalato sulle risorse Diff-Serv provisionate (ad es., via configurazione, SNMP o protocolli di policy) per il/i PSC rilevante/i. Tali requisiti di banda segnalati possono anche essere usati dagli LSR al momento dell'establishment per eseguire aggiustamenti alle risorse Diff-Serv associate al/i PSC rilevante/i (ad es., aggiustare il peso di scheduling del PSC).
Si noti che stabilire un E-LSP o un L-LSP con prenotazione di banda non significa che sia richiesto lo scheduling per-LSP. Poiché gli E-LSP e gli L-LSP sono specificati in questo documento per il supporto dei Differentiated Services, il trattamento di inoltro richiesto (scheduling e politica di scarto) è definito dal PHB Diff-Serv appropriato. Questo trattamento di inoltro MUST essere applicato dall'LSR alla granularità del BA e MUST essere conforme alla specifica del PHB rilevante.
Quando i requisiti di banda sono segnalati all'establishment di un L-LSP, la banda segnalata è ovviamente associata al PSC dell'L-LSP. Pertanto, gli LSR che usano la banda segnalata per eseguire il controllo di ammissione possono eseguire il controllo di ammissione sulle risorse Diff-Serv che sono dedicate al PSC (ad es., sulla banda garantita al PSC tramite il suo peso di scheduling).
Quando i requisiti di banda sono segnalati all'establishment di un E-LSP, la banda segnalata è associata collettivamente all'intero LSP e quindi all'insieme di PSC trasportati. Pertanto, gli LSR che usano la banda segnalata per eseguire il controllo di ammissione possono eseguire il controllo di ammissione su risorse globali che sono condivise dall'insieme di PSC (ad es., sulla banda totale del collegamento).
Esempi di scenari in cui la prenotazione di banda non è usata e di scenari in cui la prenotazione di banda è usata sono forniti a titolo informativo nell'APPENDICE B.