RFC 3270 - Supporto dei servizi differenziati da parte di MPLS

Network Working Group F. Le Faucheur, Editor Request for Comments: 3270 L. Wu Category: Standards Track B. Davie Cisco Systems S. Davari PMC-Sierra Inc. P. Vaananen Nokia R. Krishnan Axiowave Networks P. Cheval Alcatel J. Heinanen Song Networks May 2002

             Multi-Protocol Label Switching (MPLS)
               Support of Differentiated Services

Stato di questo promemoria

Questo documento specifica un protocollo del percorso di standardizzazione Internet per la comunità Internet e sollecita discussioni e suggerimenti per migliorarlo. Per lo stato e il livello di standardizzazione di questo protocollo, consultare l'edizione corrente degli "Internet Official Protocol Standards" (STD 1). La distribuzione di questo promemoria non è soggetta a limitazioni.

Avviso sul copyright

Sommario

Questo documento definisce una soluzione flessibile per il supporto dei Differentiated Services (Diff-Serv) su reti Multi-Protocol Label Switching (MPLS).

Questa soluzione consente all'amministratore di rete MPLS di selezionare come i Behavior Aggregate (BA) Diff-Serv sono mappati sui Label Switched Path (LSP) in modo da soddisfare al meglio gli obiettivi di Diff-Serv, Traffic Engineering e protezione all'interno della propria rete. Ad esempio, questa soluzione consente all'amministratore di rete di decidere se diversi insiemi di BA devono essere mappati sullo stesso LSP oppure su LSP distinti.

Indice

Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminologia . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 EXP-Inferred-PSC LSPs (E-LSP) . . . . . . . . . . . . . . . . . 6 1.3 Label-Only-Inferred-PSC LSPs (L-LSP). . . . . . . . . . . . . . 7 1.4 Operazioni complessive. . . . . . . . . . . . . . . . . . . . . 7 1.5 Relazione tra Label e FEC . . . . . . . . . . . . . . . . . . . 8 1.6 Prenotazione di banda per E-LSP e L-LSP . . . . . . . . . . . . 8
Modello di inoltro delle etichette per gli LSR Diff-Serv e modelli di tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1 Modello di inoltro delle etichette per gli LSR Diff-Serv. . . . 9 2.2 Determinazione del PHB in ingresso. . . . . . . . . . . . . . .10 2.3 Determinazione del PHB in uscita con condizionamento del traffico opzionale . . . . . . . . . . . . . . . . . . . . . . . . . . .11 2.4 Inoltro delle etichette . . . . . . . . . . . . . . . . . . . .11 2.5 Codifica delle informazioni Diff-Serv nel livello di incapsulamento. . . . . . . . . . . . . . . . . . . . . . . . .13 2.6 Modelli di tunneling Diff-Serv su MPLS. . . . . . . . . . . . .13
Operazioni dettagliate degli E-LSP . . . . . . . . . . . . . . .22 3.1 Definizione di E-LSP. . . . . . . . . . . . . . . . . . . . . .22 3.2 Popolamento del mapping Encaps-->PHB' per un E-LSP in ingresso 23 3.3 Determinazione del PHB in ingresso su un E-LSP in ingresso. . .23 3.4 Popolamento dell'insieme di mapping PHB-->Encaps' per un E-LSP in uscita . . . . . . . . . . . . . . . . . . . . . . . . . . .24 3.5 Codifica delle informazioni Diff-Serv nel livello di incapsulamento su un E-LSP in uscita. . . . . . . . . . . . . .26 3.6 Merge di E-LSP. . . . . . . . . . . . . . . . . . . . . . . . .27
Operazioni dettagliate degli L-LSP. . . . . . . . . . . . . . .28 4.1 Definizione di L-LSP. . . . . . . . . . . . . . . . . . . . . .28 4.2 Popolamento del mapping Encaps-->PHB' per un L-LSP in ingresso 28 4.3 Determinazione del PHB in ingresso su un L-LSP in ingresso. . .30 4.4 Popolamento dell'insieme di mapping PHB-->Encaps' per un L-LSP in uscita . . . . . . . . . . . . . . . . . . . . . . . . . . .31 4.5 Codifica delle informazioni Diff-Serv nel livello di incapsulamento su un L-LSP in uscita. . . . . . . . . . . . . .33 4.6 Merge di L-LSP. . . . . . . . . . . . . . . . . . . . . . . . .34
Estensione RSVP per il supporto Diff-Serv. . . . . . . . . . . .34 5.1 Formato dei messaggi RSVP correlati a Diff-Serv . . . . . . . .34 5.2 Oggetto DIFFSERV. . . . . . . . . . . . . . . . . . . . . . . .35 5.3 Gestione dell'oggetto DIFFSERV. . . . . . . . . . . . . . . . .37 5.4 Non-supporto dell'oggetto DIFFSERV. . . . . . . . . . . . . . .40 5.5 Codici di errore per Diff-Serv. . . . . . . . . . . . . . . . .40 5.6 Tipo di servizio Intserv. . . . . . . . . . . . . . . . . . . .41
Estensioni LDP per il supporto Diff-Serv . . . . . . . . . . . .41 6.1 Diff-Serv TLV . . . . . . . . . . . . . . . . . . . . . . . . .42 6.2 Valori del Status Code Diff-Serv. . . . . . . . . . . . . . . .44 6.3 Messaggi LDP correlati a Diff-Serv. . . . . . . . . . . . . . .44 6.4 Gestione del Diff-Serv TLV. . . . . . . . . . . . . . . . . . .46 6.5 Non-gestione del Diff-Serv TLV. . . . . . . . . . . . . . . . .49 6.6 Informazioni di banda . . . . . . . . . . . . . . . . . . . . .49
Supporto MPLS di Diff-Serv su interfacce PPP, LAN, Non-LC-ATM e Non-LC-FR. . . . . . . . . . . . . . . . . . . . . . . . . . . .49
Supporto MPLS di Diff-Serv su interfacce LC-ATM. . . . . . . . .50 8.1 Uso delle classi di traffico ATM e dei meccanismi di Traffic Management. . . . . . . . . . . . . . . . . . . . . . . . . . .50 8.2 Implementazione di LSR con interfacce LC-ATM. . . . . . . . . .50
Supporto MPLS di Diff-Serv su interfacce LC-FR . . . . . . . . .51 9.1 Uso dei parametri di traffico Frame Relay e dei meccanismi di Traffic Management. . . . . . . . . . . . . . . . . . . . . . .51 9.2 Implementazione di LSR con interfacce LC-FR . . . . . . . . . .51
Considerazioni IANA . . . . . . . . . . . . . . . . . . . . . .52
Considerazioni sulla sicurezza. . . . . . . . . . . . . . . . .52
Ringraziamenti. . . . . . . . . . . . . . . . . . . . . . . . .52 APPENDICE A. Esempi di scenari di deployment. . . . . . . . . . . .53 APPENDICE B. Esempi di scenari di prenotazione di banda . . . . . .58 Riferimenti . . . . . . . . . . . . . . . . . . . . . . . . . . . .60 Indirizzi degli autori. . . . . . . . . . . . . . . . . . . . . . .62 Dichiarazione completa di copyright . . . . . . . . . . . . . . . .64

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.

2. Modello di inoltro delle etichette per gli LSR Diff-Serv e modelli

di tunneling

2.1 Modello di inoltro delle etichette per gli LSR Diff-Serv

Poiché diversi Ordered Aggregate di un dato FEC possono essere trasportati su LSP diversi, la decisione di label swapping di un LSR Diff-Serv dipende chiaramente dal Behavior Aggregate del pacchetto inoltrato. Inoltre, poiché il campo IP DS di un pacchetto inoltrato può non essere direttamente visibile a un LSR, il modo per determinare il PHB da applicare a un pacchetto ricevuto e per codificare il PHB in un pacchetto trasmesso è diverso da quello di un router Diff-Serv non MPLS.

Pertanto, per descrivere l'inoltro delle etichette da parte degli LSR Diff-Serv, modelliamo il comportamento di label switching Diff-Serv dell'LSR, composto da quattro fasi:

Determinazione del PHB in ingresso (Incoming PHB Determination) (A)
Determinazione del PHB in uscita con condizionamento del traffico opzionale (Outgoing PHB Determination with Optional Traffic Conditioning) (B)
Inoltro delle etichette (Label Forwarding) (C)
Codifica delle informazioni Diff-Serv nel livello di incapsulamento (Encoding of Diff-Serv information into Encapsulation Layer) (EXP, CLP, DE, User_Priority) (D)

Ciascuna fase è descritta in maggiore dettaglio nelle sezioni seguenti.

Ovviamente, per applicare la differenziazione di servizio Diff-Serv, l'LSR MUST anche applicare il trattamento di inoltro corrispondente al PHB in uscita.

Questo modello è illustrato di seguito:

--Inc_label(s)()------------------------>I===I--Outg_label(s)(&)--> \ I I
---->I===I I C I -->I===I--Encaps-> I A I I===I--Outg_PHB->I===I I D I (&) -Encaps->I===I--Inc_PHB->I B I \ /->I===I () I===I --------+ ----Forwarding--> Treatment (PHB)

"Encaps" designa le informazioni correlate a Diff-Serv codificate nel livello di incapsulamento MPLS (ad es., campo EXP, ATM CLP, Frame Relay DE, 802.1 User_Priority)

(*) quando l'LSR si comporta come un nodo di ingresso MPLS, il pacchetto in ingresso può essere ricevuto non etichettato.

(&) quando l'LSR si comporta come un nodo di uscita MPLS, il pacchetto in uscita può essere trasmesso non etichettato.

Questo modello è presentato qui per descrivere le operazioni funzionali degli LSR Diff-Serv e non vincola l'implementazione effettiva.

2.2 Determinazione del PHB in ingresso

Questa fase determina a quale Behavior Aggregate appartiene il pacchetto ricevuto.

2.2.1 Determinazione del PHB in ingresso considerando una voce dello

  stack di etichette

Le sezioni 3.3 e 4.3 forniscono i dettagli su come eseguire la determinazione del PHB in ingresso considerando una data voce dello stack di etichette ricevuta e/o le informazioni di incapsulamento MPLS in ingresso ricevute, a seconda del tipo di LSP in ingresso e a seconda dell'incapsulamento MPLS in ingresso.

La sezione 2.6 fornisce i dettagli su quale voce dello stack di etichette considerare per la determinazione del PHB in ingresso a seconda del modo di tunneling Diff-Serv supportato.

2.2.2 Determinazione del PHB in ingresso considerando l'intestazione IP

La sezione 2.6 fornisce i dettagli su quando l'intestazione IP deve essere considerata per la determinazione del PHB in ingresso, a seconda del modello di tunneling Diff-Serv supportato. Nei casi in cui l'intestazione IP deve essere usata, questa fase opera esattamente come con un router IP Diff-Serv non MPLS e usa il campo DS per determinare il PHB in ingresso.

2.3 Determinazione del PHB in uscita con condizionamento del traffico

opzionale

La fase di condizionamento del traffico è opzionale e può essere usata su un LSR per eseguire il condizionamento del traffico, inclusa la demozione o la promozione del Behavior Aggregate. Essa è al di fuori dell'ambito di questa specifica. Ai fini della specifica dell'inoltro Diff-Serv su MPLS, notiamo semplicemente che il PHB che deve essere effettivamente applicato e trasmesso agli LSR a valle da un LSR (indicato come "PHB in uscita"), può essere diverso dal PHB che era stato associato al pacchetto dall'LSR precedente (indicato come "PHB in ingresso").

Quando la fase di condizionamento del traffico non è presente, il "PHB in uscita" è semplicemente identico al "PHB in ingresso".

2.4 Inoltro delle etichette

[MPLS_ARCH] descrive come il label swapping è eseguito dagli LSR sui pacchetti etichettati in ingresso usando un Incoming Label Map (ILM), dove ciascuna etichetta in ingresso è mappata su una o più NHLFE. [MPLS_ARCH] descrive inoltre come l'imposizione delle etichette è eseguita dagli LSR sui pacchetti non etichettati in ingresso usando un FEC-to-NHLFEs Map (FTN), dove ciascun FEC in ingresso è mappato su una o più NHLFE.

Un Diff-Serv Context per un'etichetta è composto da:

`tipo di LSP (cioè E-LSP o L-LSP)'
`PHB supportati'
`mapping Encaps-->PHB' per un'etichetta in ingresso
`insieme di mapping PHB-->Encaps' per un'etichetta in uscita

La presente specifica definisce che un Diff-Serv Context è memorizzato nell'ILM per ciascuna etichetta in ingresso.

[MPLS_ARCH] afferma che la `NHLFE may also contain any other information needed in order to properly dispose of the packet'. In conformità con ciò, la presente specifica definisce che un Diff-Serv Context è memorizzato nella NHLFE per ciascuna etichetta in uscita che è sottoposta a swap o push.

Queste informazioni di Diff-Serv Context sono popolate nell'ILM e nel FTN al momento dell'establishment dell'etichetta.

Se l'etichetta corrisponde a un E-LSP per il quale non è stato esplicitamente segnalato un mapping EXP<-->PHB' al set-up dell'LSP, i PHB supportati' sono popolati con l'insieme di PHB del mapping `EXP<-->PHB' preconfigurato, che è discusso più avanti nella sezione 3.2.1.

Se l'etichetta corrisponde a un E-LSP per il quale è stato esplicitamente segnalato un mapping EXP<-->PHB' al set-up dell'LSP, i PHB supportati' sono popolati con l'insieme di PHB del mapping `EXP<-->PHB' segnalato.

Se l'etichetta corrisponde a un L-LSP, i `PHB supportati' sono popolati con l'insieme di PHB che formano il PSC che è segnalato al set-up dell'LSP.

I dettagli su come sono popolati il mapping Encaps-->PHB' o l'insieme di mapping PHB-->Encaps' sono definiti più avanti nelle sezioni 3 e 4.

[MPLS_ARCH] afferma inoltre che:

"If the ILM [respectively, FTN] maps a particular label to a set of NHLFEs that contain more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the ILM [respectively, FTN] map a label [respectively, a FEC] to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths."

In conformità con ciò, la presente specifica consente che un'etichetta in ingresso [rispettivamente un FEC] possa essere mappata, a fini Diff-Serv, su più NHLFE (ad esempio laddove NHLFE diverse corrispondono a etichette di uscita che supportano insiemi di PHB diversi). Quando un'etichetta [rispettivamente un FEC] mappa su più NHLFE, l'LSR Diff-Serv MUST scegliere una delle NHLFE il cui Diff-Serv Context indica che supporta il PHB in uscita del pacchetto inoltrato.

Quando un'etichetta [rispettivamente un FEC] mappa su più NHLFE che supportano il PHB in uscita, la procedura per sceglierne una tra quelle è al di fuori dell'ambito di questo documento. Questa situazione può essere incontrata laddove si desidera fare bilanciamento del carico di un Behavior Aggregate su più LSP. In tali situazioni, al fine di rispettare i vincoli di ordinamento, tutti i pacchetti di un dato microflow MUST essere trasportati sullo stesso LSP.

2.5 Codifica delle informazioni Diff-Serv nel livello di

incapsulamento

Questa fase determina come codificare i campi che trasmettono le informazioni Diff-Serv nel pacchetto trasmesso (ad es., MPLS Shim EXP, ATM CLP, Frame Relay DE, 802.1 User_Priority).

2.5.1 Codifica delle informazioni Diff-Serv nella voce di etichetta

  trasmessa

Le sezioni 3.5 e 4.5 forniscono i dettagli su come eseguire la codifica delle informazioni Diff-Serv in una data voce dello stack di etichette trasmessa e/o nelle informazioni di incapsulamento MPLS trasmesse, a seconda del tipo di LSP in uscita corrispondente e a seconda dell'incapsulamento MPLS.

La sezione 2.6 fornisce i dettagli su in quale voce dello stack di etichette eseguire la codifica delle informazioni Diff-Serv a seconda del modo di tunneling Diff-Serv supportato.

2.5.2 Codifica delle informazioni Diff-Serv nell'intestazione IP

  trasmessa

Per eseguire la codifica delle informazioni Diff-Serv nell'intestazione IP del pacchetto trasmesso, questa fase opera esattamente come con un router IP Diff-Serv non MPLS e codifica il DSCP del PHB in uscita nel campo DS.

La sezione 2.6 fornisce i dettagli su quando la codifica delle informazioni Diff-Serv deve essere eseguita nell'intestazione IP trasmessa a seconda del modo di tunneling Diff-Serv supportato.

2.6 Modelli di tunneling Diff-Serv su MPLS

2.6.1 Modelli di tunneling Diff-Serv

[DIFF_TUNNEL] considera l'interazione dei Differentiated Services con tunnel IP di varie forme. Gli LSP MPLS non sono una forma di "tunnel IP" poiché l'intestazione di incapsulamento MPLS non contiene un'intestazione IP e pertanto gli LSP MPLS non sono considerati in [DIFF_TUNNEL]. Tuttavia, sebbene non siano una forma di "tunnel IP", gli LSP MPLS sono una forma di "tunnel".

Dal punto di vista Diff-Serv, gli LSP condividono un certo numero di caratteristiche comuni con i tunnel IP:

I nodi intermedi (cioè i nodi da qualche parte lungo l'estensione dell'LSP) vedono e operano solo sulle informazioni Diff-Serv "esterne".
Gli LSP sono unidirezionali.
Le informazioni Diff-Serv "esterne" possono essere modificate in uno qualsiasi dei nodi intermedi.

Tuttavia, dal punto di vista Diff-Serv, gli LSP hanno anche una proprietà distintiva rispetto ai tunnel IP:

In generale non esiste un comportamento analogo al Penultimate Hop Popping (PHP) usato con i tunnel IP. Inoltre, il PHP fa sì che le informazioni Diff-Serv "esterne" associate all'LSP non siano visibili all'egress dell'LSP. In situazioni in cui queste informazioni non sono significative all'Egress dell'LSP, ciò non è ovviamente un problema. In situazioni in cui queste informazioni sono significative all'Egress dell'LSP, allora devono in qualche modo essere trasportate con altri mezzi.

I due modelli concettuali per il tunneling Diff-Serv su tunnel IP definiti in [DIFF_TUNNEL] sono applicabili e utili a Diff-Serv su MPLS ma le rispettive operazioni dettagliate sono in qualche misura diverse su MPLS. Questi due modelli sono il modello Pipe e il modello Uniform. Le loro operazioni su MPLS sono specificate nelle sezioni seguenti. La discussione e la definizione di modelli di tunneling alternativi sono al di fuori dell'ambito di questa specifica.

2.6.2 Modello Pipe

Con il modello Pipe, i tunnel MPLS (alias LSP) sono usati per nascondere i nodi MPLS intermedi tra l'Ingress e l'Egress dell'LSP dalla prospettiva Diff-Serv.

In questo modello, i pacchetti sottoposti a tunneling devono trasmettere due pezzi di informazioni Diff-Serv significativi:

le informazioni Diff-Serv che sono significative per i nodi intermedi lungo l'estensione dell'LSP, incluso l'Egress dell'LSP (che indichiamo come "Informazioni Diff-Serv dell'LSP"). Queste Informazioni Diff-Serv dell'LSP non sono significative oltre l'Egress dell'LSP: che il Traffic Conditioning nei nodi intermedi sull'estensione dell'LSP influenzi o meno le informazioni Diff-Serv dell'LSP, queste informazioni Diff-Serv aggiornate non sono considerate significative oltre l'Egress dell'LSP e sono ignorate.
le informazioni Diff-Serv che sono significative oltre l'Egress dell'LSP (che indichiamo come "Informazioni Diff-Serv tunnelizzate"). Queste informazioni devono essere trasmesse dall'Ingress dell'LSP all'Egress dell'LSP. Queste informazioni Diff-Serv non sono significative per i nodi intermedi sull'estensione dell'LSP.

Il funzionamento del modello Pipe senza PHP è illustrato di seguito:

        ========== LSP =============================>

            ---Swap--(M)--...--Swap--(M)--Swap----
           /        (outer header)                \
         (M)                                      (M)
         /                                          \

--(m)-Push.................(m).....................Pop--(m)--> I (inner header) E (M*)

(M) rappresenta le "Informazioni Diff-Serv dell'LSP" (m) rappresenta le "Informazioni Diff-Serv tunnelizzate" (*) L'Egress dell'LSP considera le informazioni Diff-Serv dell'LSP ricevute nell'intestazione esterna (cioè prima del pop) al fine di applicare il suo trattamento di inoltro Diff-Serv (cioè il PHB effettivo) I rappresenta il nodo di ingresso dell'LSP E rappresenta il nodo di uscita dell'LSP

Con il modello Pipe, le "Informazioni Diff-Serv dell'LSP" devono essere trasmesse all'Egress dell'LSP così che esso applichi il suo trattamento di inoltro basandosi su di esse. Anche le "Informazioni Diff-Serv tunnelizzate" devono essere trasmesse all'Egress dell'LSP così che possano essere trasmesse ulteriormente a valle.

Poiché entrambe richiedono che le informazioni Diff-Serv siano trasmesse all'Egress dell'LSP, il modello Pipe opera solo senza PHP.

Il modello Pipe è particolarmente appropriato per ambienti in cui:

la nube a monte dell'interfaccia in ingresso dell'Ingress dell'LSP e la nube a valle dell'interfaccia in uscita dell'Egress dell'LSP sono in domini Diff-Serv che usano un insieme comune di policy di provisioning del servizio Diff-Serv e di definizioni di PHB, mentre l'LSP attraversa uno (o più) dominio/i Diff-Serv che usa/usano un insieme diverso di policy di provisioning del servizio Diff-Serv e di definizioni di PHB
l'interfaccia in uscita dell'Egress dell'LSP è nell'(ultimo) dominio Diff-Serv attraversato dall'LSP.

Come esempio, si consideri il caso in cui un service provider offre un servizio MPLS VPN (si veda [MPLS_VPN] per un esempio di architettura MPLS VPN) inclusa la differenziazione Diff-Serv. Si dica che una collezione di siti è interconnessa tramite un tale servizio MPLS VPN. Ora si dica che questa collezione di siti è gestita sotto un'amministrazione comune e supporta anche la differenziazione di servizio Diff-Serv. Se l'amministrazione dei siti VPN e il Service

Provider non condividono esattamente la stessa policy Diff-Serv (ad esempio non supportando lo stesso numero di PHB), allora il funzionamento di Diff-Serv nel modello Pipe sul servizio MPLS VPN consentirebbe alla policy Diff-Serv dei siti VPN di operare in modo coerente attraverso il sito VPN di ingresso e il sito VPN di uscita e in modo trasparente sul dominio Diff-Serv del Service Provider. Può essere utile vedere tali LSP come elementi che collegano i domini Diff-Serv ai loro endpoint in una singola regione Diff-Serv rendendo questi endpoint virtualmente contigui anche se possono essere fisicamente separati da nodi di rete intermedi.

Il modello Pipe MUST essere supportato.

Per il supporto del modello Pipe su un dato LSP senza PHP, un LSR esegue la determinazione del PHB in ingresso e la codifica delle informazioni Diff-Serv nel modo seguente:

quando riceve un pacchetto non etichettato, l'LSR esegue la determinazione del PHB in ingresso considerando l'intestazione IP ricevuta.
quando riceve un pacchetto etichettato, l'LSR esegue la determinazione del PHB in ingresso considerando la voce di etichetta esterna nello stack di etichette ricevuto. In particolare, quando deve essere eseguita un'operazione di pop per l'LSP considerato, l'LSR esegue la determinazione del PHB in ingresso PRIMA del pop.
quando esegue un'operazione di push per l'LSP considerato, l'LSR:

o codifica le informazioni Diff-Serv corrispondenti al PHB IN USCITA nella voce di etichetta trasmessa corrispondente all'etichetta sottoposta a push.

o codifica le informazioni Diff-Serv corrispondenti al PHB IN INGRESSO nell'intestazione incapsulata (voce di etichetta sottoposta a swap oppure intestazione IP).
quando esegue un'operazione di solo swap per l'LSP considerato, l'LSR codifica le informazioni Diff-Serv nella voce di etichetta trasmessa che contiene l'etichetta sottoposta a swap
quando esegue un'operazione di pop per l'LSP considerato, l'LSR non esegue la codifica delle informazioni Diff-Serv nell'intestazione esposta dall'operazione di pop (cioè l'LSR lascia l'intestazione esposta "così com'è").

2.6.2.1 Modello Short Pipe

Il modello Short Pipe è una variazione opzionale del modello Pipe descritto sopra. L'unica differenza è che, con il modello Short Pipe,

il trattamento di inoltro Diff-Serv all'Egress dell'LSP è applicato basandosi sulle "Informazioni Diff-Serv tunnelizzate" (cioè le informazioni Diff-Serv trasmesse nell'intestazione incapsulata) piuttosto che sulle "Informazioni Diff-Serv dell'LSP" (cioè le informazioni Diff-Serv trasmesse nell'intestazione di incapsulamento).

Il funzionamento del modello Short Pipe senza PHP è illustrato di seguito:

        ========== LSP =============================>

            ---Swap--(M)--...--Swap--(M)--Swap----
           /        (outer header)                \
         (M)                                      (M)
         /                                          \

--(m)-Push.................(m).....................Pop--(m)--> I (inner header) E

(M) rappresenta le "Informazioni Diff-Serv dell'LSP" (m) rappresenta le "Informazioni Diff-Serv tunnelizzate" I rappresenta il nodo di ingresso dell'LSP E rappresenta il nodo di uscita dell'LSP

Poiché l'Egress dell'LSP applica il suo trattamento di inoltro basandosi sulle "Informazioni Diff-Serv tunnelizzate", le "Informazioni Diff-Serv dell'LSP" non devono essere trasmesse dal nodo penultimo all'Egress dell'LSP. Pertanto il modello Short Pipe può anche operare con PHP.

Il funzionamento del modello Short Pipe con PHP è illustrato di seguito:

       =========== LSP ============================>

            ---Swap--(M)--...--Swap------
           /       (outer header)        \
         (M)                             (M)
         /                                 \

--(m)-Push.................(m).............Pop-(m)--E--(m)--> I (inner header) P (M*)

(M) rappresenta le "Informazioni Diff-Serv dell'LSP" (m) rappresenta le "Informazioni Diff-Serv tunnelizzate" (*) Il penultimo LSR considera le informazioni Diff-Serv dell'LSP ricevute nell'intestazione esterna (cioè prima del pop) al fine di applicare il suo trattamento di inoltro Diff-Serv (cioè il PHB effettivo) I rappresenta il nodo di ingresso dell'LSP P rappresenta il nodo penultimo dell'LSP E rappresenta il nodo di uscita dell'LSP

Il modello Short Pipe è particolarmente appropriato per ambienti in cui:

la nube a monte dell'interfaccia in ingresso dell'Ingress dell'LSP e la nube a valle dell'interfaccia in uscita dell'Egress dell'LSP sono in domini Diff-Serv che usano un insieme comune di policy di provisioning del servizio Diff-Serv e di definizioni di PHB, mentre l'LSP attraversa uno (o più) dominio/i Diff-Serv che usa/usano un insieme diverso di policy di provisioning del servizio Diff-Serv e di definizioni di PHB
l'interfaccia in uscita dell'Egress dell'LSP è nello stesso dominio Diff-Serv della nube a valle di essa.

Poiché ciascuna interfaccia in uscita dell'Egress dell'LSP è nello stesso dominio Diff-Serv della nube a valle di essa, ciascuna interfaccia in uscita può potenzialmente essere in un dominio Diff-Serv diverso, e l'Egress dell'LSP deve essere configurato con consapevolezza di ogni policy Diff-Serv corrispondente. Questo overhead operativo è giustificato in alcune situazioni in cui le rispettive policy Diff-Serv a valle sono più adatte a offrire la differenziazione di servizio su ciascuna interfaccia di uscita rispetto alla policy Diff-Serv comune usata sull'estensione dell'LSP. Un esempio di tale situazione è dove un Service Provider offre un servizio MPLS VPN e dove alcuni utenti VPN richiedono che la propria policy Diff-Serv VPN sia applicata per controllare la differenziazione di servizio sul collegamento dedicato dall'Egress dell'LSP al sito VPN di destinazione, piuttosto che la policy Diff-Serv del Service Provider.

Il modello Short Pipe MAY essere supportato.

Per il supporto del modello Short Pipe su un dato LSP senza PHP, un LSR esegue la determinazione del PHB in ingresso e la codifica delle informazioni Diff-Serv nello stesso modo del modello Pipe con la seguente eccezione:

quando riceve un pacchetto etichettato, l'LSR esegue la determinazione del PHB in ingresso considerando l'intestazione (voce di etichetta o intestazione IP) che è usata per eseguire l'inoltro effettivo. In particolare, quando deve essere eseguita un'operazione di pop per l'LSP considerato, l'LSR esegue la determinazione del PHB in ingresso DOPO il pop.

Per il supporto del modello Short Pipe su un dato LSP con PHP, un LSR esegue la determinazione del PHB in ingresso e la codifica delle informazioni Diff-Serv nello stesso modo che senza PHP con le seguenti eccezioni:

il penultimo LSR esegue la determinazione del PHB in ingresso considerando la voce di etichetta esterna nello stack di etichette ricevuto. In altre parole, quando deve essere eseguita un'operazione di pop per l'LSP considerato, il penultimo LSR esegue la determinazione del PHB in ingresso PRIMA del pop.

Si noti che il comportamento del penultimo LSR nel modo Short Pipe con PHP è identico al comportamento dell'Egress dell'LSP nel modo Pipe (necessariamente senza PHP).

2.6.3 Modello Uniform

Con il modello Uniform, i tunnel MPLS (alias LSP) sono visti come artefatti del percorso end-to-end dal punto di vista Diff-Serv. I tunnel MPLS possono essere usati a fini di inoltro ma non hanno un impatto significativo su Diff-Serv. In questo modello, qualsiasi pacchetto contiene esattamente un pezzo di informazioni Diff-Serv che è significativo ed è sempre codificato nella voce di etichetta più esterna (o nel DSCP IP laddove il pacchetto IP è trasmesso non etichettato, ad esempio all'egress dell'LSP). Qualsiasi informazione Diff-Serv codificata altrove (ad es., in voci di etichetta più profonde) non ha significato per i nodi intermedi o per l'egress del tunnel ed è ignorata. Se il Traffic Conditioning nei nodi intermedi sull'estensione dell'LSP influenza le informazioni Diff-Serv "esterne", le informazioni Diff-Serv aggiornate sono quelle considerate significative all'egress dell'LSP.

Il funzionamento del modello Uniform senza PHP è illustrato di seguito:

         ========== LSP =============================>

             ---Swap--(M)--...-Swap--(M)--Swap----
            /         (outer header)              \
          (M)                                     (M)
          /                                         \

--(M)--Push...............(x).......................Pop--(M)-> I (inner header) E

(M) rappresenta le informazioni Diff-Serv significative codificate nell'intestazione corrispondente. (x) rappresenta informazioni Diff-Serv non significative. I rappresenta il nodo di ingresso dell'LSP E rappresenta il nodo di uscita dell'LSP

Il funzionamento del modello Uniform con PHP è illustrato di seguito:

         ========== LSP =========================>

             ---Swap-(M)-...-Swap------
            /        (outer header)    \
          (M)                          (M)
          /                              \

--(M)--Push..............(x)............Pop-(M)--E--(M)-> I (inner header) P

Il modello Uniform per Diff-Serv su MPLS è tale che, dalla prospettiva Diff-Serv, le operazioni sono esattamente identiche alle operazioni se MPLS non fosse usato. In altre parole, MPLS è interamente trasparente alle operazioni Diff-Serv.

L'uso del modello Uniform consente agli LSP di attraversare i confini dei domini Diff-Serv senza alcuna altra misura in atto se non un Traffic Conditioning Agreement inter-dominio al confine fisico tra i domini Diff-Serv e che opera esclusivamente sull'intestazione "esterna", poiché le informazioni Diff-Serv significative sono sempre visibili e modificabili nella voce di etichetta più esterna.

Il modello Uniform MAY essere supportato.

Per il supporto del modello Uniform su un dato LSP, un LSR esegue la determinazione del PHB in ingresso e la codifica delle informazioni Diff-Serv nel modo seguente:

quando riceve un pacchetto non etichettato, l'LSR esegue la determinazione del PHB in ingresso considerando l'intestazione IP ricevuta.
quando riceve un pacchetto etichettato, l'LSR esegue la determinazione del PHB in ingresso considerando la voce di etichetta esterna nello stack di etichette ricevuto. In particolare, quando deve essere eseguita un'operazione di pop per l'LSP considerato, l'LSR esegue la determinazione del PHB in ingresso PRIMA del pop.
quando esegue un'operazione di push per l'LSP considerato, l'LSR codifica le informazioni Diff-Serv nella voce di etichetta trasmessa corrispondente all'etichetta sottoposta a push. Le informazioni Diff-Serv codificate nell'intestazione incapsulata (voce di etichetta sottoposta a swap oppure intestazione IP) non hanno importanza.
quando esegue un'operazione di solo swap per l'LSP considerato, l'LSR codifica le informazioni Diff-Serv nella voce di etichetta trasmessa che contiene l'etichetta sottoposta a swap.
quando si usa il PHP, il penultimo LSR deve essere consapevole dell'insieme di mapping PHB-->Encaps' per l'etichetta corrispondente all'intestazione esposta (o del mapping PHB-->DSCP') al fine di eseguire la codifica delle informazioni Diff-Serv. I metodi per fornire questa consapevolezza del mapping sono al di fuori dell'ambito di questa specifica. Come esempio, il mapping PHB-->DSCP' può essere configurato localmente. Come altro esempio, in alcuni ambienti può essere appropriato per il penultimo LSR assumere che l'insieme di mapping PHB-->Encaps' da usare per l'etichetta in uscita nell'intestazione esposta sia l'`insieme di mapping PHB-->Encaps' che sarebbe usato dall'LSR se l'LSR non stesse facendo PHP. Si noti inoltre che questa specifica assume che il penultimo LSR non esegua label swapping sulla voce di etichetta esposta dall'operazione di pop (e di fatto che non guardi nemmeno l'etichetta esposta). Di conseguenza, possono applicarsi restrizioni alla codifica delle informazioni Diff-Serv che può essere eseguita dal penultimo LSR. Ad esempio, questa specifica non consente situazioni in cui il penultimo LSR fa pop di un'etichetta corrispondente a un E-LSP che supporta due PSC, mentre l'intestazione esposta dal pop contiene valori di etichetta per due L-LSP ciascuno dei quali supporta un PSC, poiché la codifica delle informazioni Diff-Serv richiederebbe di selezionare un'etichetta o l'altra.

Si noti che i comportamenti dell'LSR per i modelli Pipe, Short Pipe e Uniform differiscono solo quando si esegue un push o un pop. Pertanto, gli LSR intermedi che eseguono solo operazioni di swap per un LSP si comportano esattamente allo stesso modo, indipendentemente dal fatto che stiano operando nel modello Pipe, Short Pipe o Uniform. Con un'implementazione Diff-Serv che supporta più modelli di tunneling, solo gli LSR che si comportano come Ingress dell'LSP, penultimo LSR o Egress dell'LSP devono essere configurati per operare in un particolare modello. La segnalazione per associare un modello di tunneling Diff-Serv su base per-LSP non rientra nell'ambito di questa specifica.

2.6.4 Gerarchia

Attraverso il meccanismo dello stack di etichette, MPLS consente al tunneling degli LSP di annidarsi a qualsiasi profondità. Osserviamo che con tale annidamento, il push di livello N+1 ha luogo su un LSR successivo (o sullo stesso) rispetto all'LSR che esegue il push per il livello N, mentre il pop di livello N+1 ha luogo su un LSR precedente (o sullo stesso) rispetto all'LSR che esegue il pop del livello N. Per un dato LSP di livello N, l'LSR di Ingress che esegue il push e l'LSR che esegue il pop (penultimo LSR o Egress dell'LSP) devono operare nello stesso modello di tunneling (cioè Pipe, Short Pipe o Uniform). Tuttavia, non vi è alcun requisito di modelli di tunneling coerenti tra i livelli, così che LSP a livelli diversi possono operare in modelli di tunneling diversi.

Le operazioni gerarchiche sono illustrate di seguito nel caso di due livelli di tunnel:

           +--------Swap--...---+
          /    (outmost header)  \
         /                        \
       Push(2).................(2)Pop
       / (outer header)             \
      /                              \

---Push(1)........................(1)Pop-->> (inner header)

(1) Modello di tunneling 1 (2) Modello di tunneling 2

Il modello di tunneling 2 può essere lo stesso del o può essere diverso dal modello di tunneling 1.

Per un dato LSP di livello N, l'LSR deve eseguire la determinazione del PHB in ingresso e la codifica delle informazioni Diff-Serv come specificato nelle sezioni 2.6.2, 2.6.2.1 e 2.6.3 secondo il modello di tunneling di questo LSP di livello N e indipendentemente dal modello di tunneling di LSP di altri livelli.

3. Operazioni dettagliate degli E-LSP

3.1 Definizione di E-LSP

Gli E-LSP sono definiti nella sezione 1.2.

All'interno di un dato dominio MPLS Diff-Serv, tutti gli E-LSP che si basano sul mapping preconfigurato sono in grado di trasportare lo stesso insieme comune di 8, o meno, BA. Ciascuno di quegli E-LSP può effettivamente trasportare questo insieme completo di BA oppure un qualsiasi sottoinsieme arbitrario di esso.

Per un dato FEC, due dati E-LSP che usano un mapping `EXP<-->PHB' segnalato possono supportare gli stessi o diversi insiemi di Ordered Aggregate.

3.2 Popolamento del mapping `Encaps-->PHB' per un E-LSP in ingresso

Questa sezione definisce come il mapping `Encaps-->PHB' del Diff-Serv Context è popolato per un E-LSP in ingresso al fine di consentire la determinazione del PHB in ingresso.

Il mapping Encaps-->PHB' per un E-LSP è sempre della forma mapping EXP-->PHB'.

Se l'etichetta corrisponde a un E-LSP per il quale non è stato esplicitamente segnalato un mapping EXP<-->PHB' al set-up dell'LSP, il mapping EXP-->PHB' è popolato basandosi sul mapping `EXP<-->PHB' preconfigurato che è discusso più avanti nella sezione 3.2.1.

Se l'etichetta corrisponde a un E-LSP per il quale è stato esplicitamente segnalato un mapping EXP<-->PHB' al set-up dell'LSP, il mapping EXP-->PHB' è popolato secondo il mapping `EXP<-->PHB' segnalato.

3.2.1 Mapping `EXP<-->PHB' preconfigurato

Gli LSR che supportano E-LSP che usano il mapping EXP<-->PHB' preconfigurato devono consentire la configurazione locale di questo mapping EXP<-->PHB'. Questo mapping si applica a tutti gli E-LSP stabiliti su questo LSR senza un mapping esplicitamente segnalato al momento del set-up.

Il mapping `EXP<-->PHB' preconfigurato deve essere coerente a ogni hop dell'E-LSP attraverso il dominio MPLS Diff-Serv attraversato dall'LSP oppure deve essere eseguita un'appropriata rimarcazione del campo EXP da parte dell'LSR ogni volta che un mapping preconfigurato diverso è usato sulle interfacce di ingresso e di uscita.

Nel caso in cui il mapping EXP<-->PHB' preconfigurato non sia stato effettivamente configurato dall'amministratore di rete, l'LSR dovrebbe usare un mapping EXP<-->PHB' preconfigurato predefinito che mappa tutti i valori EXP sul PHB Default.

3.3 Determinazione del PHB in ingresso su un E-LSP in ingresso

Questa sezione definisce come la determinazione del PHB in ingresso è eseguita quando la voce di etichetta considerata nello stack di etichette ricevuto corrisponde a un E-LSP. Ciò richiede che il mapping `Encaps-->PHB' sia popolato come definito nella sezione 3.2.

Quando si considera una voce di etichetta corrispondente a un E-LSP in ingresso per la determinazione del PHB in ingresso, l'LSR:

determina il mapping EXP-->PHB' cercando il mapping Encaps-->PHB' del Diff-Serv Context associato nell'ILM con l'etichetta E-LSP in ingresso considerata.
determina il PHB in ingresso cercando il campo EXP della voce di etichetta considerata nella tabella del mapping `EXP-->PHB'.

3.4 Popolamento dell'`insieme di mapping PHB-->Encaps' per un E-LSP in

uscita

Questa sezione definisce come l'`insieme di mapping PHB-->Encaps' del Diff-Serv Context è popolato al set-up dell'etichetta per un E-LSP in uscita al fine di consentire la codifica delle informazioni Diff-Serv nel livello di incapsulamento.

3.4.1 Mapping `PHB-->EXP'

Un E-LSP in uscita deve sempre avere un mapping PHB-->EXP' come parte dell'insieme di mapping PHB-->Encaps' del suo Diff-Serv Context.

Se l'etichetta corrisponde a un E-LSP per il quale non è stato esplicitamente segnalato un mapping EXP<-->PHB' al set-up dell'LSP, questo mapping PHB-->EXP' è popolato basandosi sul mapping `EXP<-->PHB' preconfigurato che è discusso sopra nella sezione 3.2.1.

Se l'etichetta corrisponde a un E-LSP per il quale è stato esplicitamente segnalato un mapping EXP<-->PHB' al set-up dell'LSP, il mapping PHB-->EXP' è popolato secondo il mapping `EXP<-->PHB' segnalato.

3.4.2 Mapping `PHB-->CLP'

Se l'LSP esce su un'interfaccia ATM che non è controllata dal label switching, allora un mapping PHB-->CLP' è aggiunto all'insieme di mapping PHB-->Encaps' per questo LSP in uscita. Questo mapping `PHB-->CLP' è popolato nel modo seguente:

è una funzione dei PHB supportati su questo LSP, e può usare le voci di mapping rilevanti per questi PHB dal mapping `PHB-->CLP' predefinito definito nella sezione 3.4.2.1. Possono essere usati mapping diversi da quello definito nella sezione 3.4.2.1. In particolare, se un mapping dai PHB al CLP sarà standardizzato in futuro per le operazioni di Diff-Serv su ATM, un tale mapping standardizzato potrà allora essere usato.

Ad esempio, se l'etichetta in uscita corrisponde a un LSP che supporta il PSC AF1, allora il mapping `PHB-->CLP' può essere popolato con:

     PHB                CLP Field

     AF11       ---->      0
     AF12       ---->      1
     AF13       ---->      1
     EF         ---->      0

Si noti che in questo caso l'insieme di mapping PHB-->Encaps' contiene sia un mapping PHB-->EXP' sia un mapping `PHB-->CLP'.

3.4.2.1 Mapping `PHB-->CLP' predefinito

     PHB                CLP Bit

     DF         ---->      0
     CSn        ---->      0
     AFn1       ---->      0
     AFn2       ---->      1
     AFn3       ---->      1
     EF         ---->      0

3.4.3 Mapping `PHB-->DE'

Se l'LSP esce su un'interfaccia Frame Relay che non è controllata dal label switching, un mapping PHB-->DE' è aggiunto all'insieme di mapping PHB-->Encaps' per questo LSP in uscita ed è popolato nel modo seguente:

è una funzione dei PHB supportati su questo LSP, e può usare le voci di mapping rilevanti per questi PHB dal mapping `PHB-->DE' predefinito definito nella sezione 3.4.3.1. Possono essere usati mapping diversi da quello definito nella sezione 3.4.3.1. In particolare, se un mapping dai PHB al DE sarà standardizzato in futuro per le operazioni di Diff-Serv su Frame Relay, un tale mapping standardizzato potrà allora essere usato.

Si noti che in questo caso l'insieme di mapping PHB-->Encaps' contiene sia un mapping PHB-->EXP' sia un mapping `PHB-->DE'.

3.4.3.1 Mapping `PHB-->DE' predefinito

     PHB                 DE Bit

      DF       ---->       0
      CSn      ---->       0
      AFn1     ---->       0
      AFn2     ---->       1
      AFn3     ---->       1
      EF       ---->       0

3.4.4 Mapping `PHB-->802.1'

Se l'LSP esce su un'interfaccia LAN su cui sono supportate più classi di traffico 802.1 come da [IEEE_802.1], allora un mapping PHB-->802.1' è aggiunto all'insieme di mapping PHB-->Encaps' per questo LSP in uscita. Questo mapping `PHB-->802.1' è popolato nel modo seguente:

è una funzione dei PHB supportati su questo LSP, e usa le voci di mapping rilevanti per questi PHB dal mapping `PHB-->802.1' preconfigurato definito nella sezione 3.4.4.1.

Si noti che l'insieme di mapping PHB-->Encaps' contiene allora sia un mapping PHB-->EXP' sia un mapping `PHB-->802.1'.

3.4.4.1 Mapping `PHB-->802.1' preconfigurato

Al momento della produzione di questa specifica, non esiste un mapping standardizzato dai PHB alle classi di traffico 802.1. Di conseguenza, un LSR che supporta più classi di traffico 802.1 su interfacce LAN deve consentire la configurazione locale di un mapping `PHB-->802.1'. Questo mapping si applica a tutti gli LSP in uscita stabiliti dall'LSR su tali interfacce LAN.

3.5 Codifica delle informazioni Diff-Serv nel livello di

incapsulamento su un E-LSP in uscita

Questa sezione definisce come codificare le informazioni Diff-Serv nel livello di incapsulamento MPLS per una data voce di etichetta trasmessa corrispondente a un E-LSP in uscita. Ciò richiede che l'`insieme di mapping PHB-->Encaps' sia popolato come definito nella sezione 3.4.

L'LSR determina prima l'`insieme di mapping PHB-->Encaps' del Diff-Serv Context associato all'etichetta corrispondente nella NHLFE.

3.5.1 Mapping `PHB-->EXP'

Se l'insieme di mapping PHB-->Encaps' contiene un mapping della forma mapping PHB-->EXP', allora l'LSR:

determina il valore da scrivere nel campo EXP della voce di etichetta del livello corrispondente cercando il "PHB in uscita" in questa tabella del mapping `PHB-->EXP'.

3.5.2 Mapping `PHB-->CLP'

Se l'insieme di mapping PHB-->Encaps' contiene un mapping della forma mapping PHB-->CLP', allora l'LSR:

determina il valore da scrivere nel campo CLP dell'intestazione di incapsulamento ATM, cercando il "PHB in uscita" in questa tabella del mapping `PHB-->CLP'.

3.5.3 Mapping `PHB-->DE'

Se l'insieme di mapping PHB-->Encaps' contiene un mapping della forma mapping PHB-->DE', allora l'LSR:

determina il valore da scrivere nel campo DE dell'intestazione di incapsulamento Frame Relay, cercando il "PHB in uscita" in questa tabella del mapping `PHB-->DE'.

3.5.4 Mapping `PHB-->802.1'

Se l'insieme di mapping PHB-->Encaps' contiene un mapping della forma mapping PHB-->802.1', allora l'LSR:

determina il valore da scrivere nel campo User_Priority del Tag Control Information dell'intestazione di incapsulamento 802.1 [IEEE_802.1], cercando il "PHB in uscita" in questa tabella del mapping 'PHB-->802.1'.

3.6 Merge di E-LSP

In un dominio MPLS, due o più LSP possono essere uniti (merged) in un LSP in un LSR. Gli E-LSP sono compatibili con il merge di LSP sotto la seguente condizione:

  Gli E-LSP possono essere uniti in un solo LSP se supportano
  esattamente lo stesso insieme di BA.

Per gli E-LSP che usano un mapping `EXP<-->PHB' segnalato, la condizione di merge di cui sopra MUST essere applicata dagli LSR attraverso un controllo esplicito al set-up dell'etichetta che esattamente lo stesso insieme di PHB sia supportato sugli LSP uniti.

Per gli E-LSP che usano il mapping EXP<-->PHB' preconfigurato, poiché i PHB supportati su un E-LSP non sono segnalati al momento dell'establishment, un LSR non può basarsi sulle informazioni di segnalazione per applicare il merge di cui sopra. Tuttavia tutti gli E-LSP che usano il mapping EXP<-->PHB' preconfigurato sono tenuti a supportare lo stesso insieme di Behavior Aggregate all'interno di un dato dominio MPLS Diff-Serv. Pertanto, il merge di E-LSP che usano il mapping `EXP<-->PHB' preconfigurato è consentito all'interno di un dato dominio MPLS Diff-Serv.

4. Operazioni dettagliate degli L-LSP

4.1 Definizione di L-LSP

Gli L-LSP sono definiti nella sezione 1.3.

4.2 Popolamento del mapping `Encaps-->PHB' per un L-LSP in ingresso

Questa sezione definisce come il mapping `Encaps-->PHB' del Diff-Serv Context è popolato al set-up dell'etichetta per un L-LSP in ingresso al fine di consentire la determinazione del PHB in ingresso.

4.2.1 Mapping `EXP-->PHB'

Se l'LSR termina il livello MPLS Shim su questo L-LSP in ingresso e l'L-LSP entra su un'interfaccia che non è né ATM né Frame Relay, allora il mapping `Encaps-->PHB' è popolato nel modo seguente:

è effettivamente un mapping `EXP-->PHB'
questo mapping è una funzione del PSC che è trasportato su questo LSP, e deve usare le voci di mapping rilevanti per questo PSC dal mapping `EXP/PSC-->PHB' obbligatorio definito nella sezione 4.2.1.1.

Ad esempio, se l'etichetta in ingresso corrisponde a un L-LSP che supporta il PSC AF1, allora il mapping `Encaps-->PHB' sarà popolato con:

  EXP Field              PHB

      ---->    AF11
      ---->    AF12
      ---->    AF13

Un LSR che supporta L-LSP su interfacce PPP e interfacce LAN è un esempio di LSR che termina il livello Shim su interfacce di ingresso che non sono né ATM né Frame Relay.

Se l'LSR termina il livello MPLS Shim su questo L-LSP in ingresso e l'L-LSP entra su un'interfaccia ATM o Frame Relay, allora il mapping `Encaps-->PHB' è popolato nel modo seguente:

dovrebbe essere effettivamente un mapping EXP-->PHB'. Modi opzionali alternativi di popolare il mapping Encaps-->PHB' potrebbero essere definiti in futuro (ad es., usando un mapping 'CLP/EXP--> PHB' o un mapping 'DE/EXP-->PHB') ma sono al di fuori dell'ambito di questo documento.
quando il mapping Encaps-->PHB' è un mapping EXP-->PHB', questo mapping EXP-->PHB' è una funzione del PSC che è trasportato sull'L-LSP, e deve usare le voci di mapping rilevanti per questo PSC dal mapping EXP/PSC-->PHB' obbligatorio definito nella sezione 4.2.1.1.

Un Edge-LSR di un dominio ATM-MPLS o di un dominio FR-MPLS è un esempio di LSR che termina il livello shim su un'interfaccia di ingresso ATM/FR.

4.2.1.1 Mapping `EXP/PSC --> PHB' obbligatorio

  EXP Field      PSC             PHB

        DF    ---->    DF
        CSn   ---->    CSn
        AFn   ---->    AFn1
        AFn   ---->    AFn2
        AFn   ---->    AFn3
        EF    ---->    EF

4.2.2 Mapping `CLP-->PHB'

Se l'LSR non termina un livello MPLS Shim su questa etichetta in ingresso e usa l'incapsulamento ATM (cioè è un ATM-LSR), allora il mapping `Encaps-->PHB' per questo L-LSP in ingresso è popolato nel modo seguente:

è effettivamente un mapping `CLP-->PHB'
il mapping è una funzione del PSC che è trasportato su questo LSP, e dovrebbe usare le voci di mapping rilevanti per questo PSC dal mapping `CLP/PSC-->PHB' predefinito definito nella sezione 4.2.2.1.

Ad esempio, se l'etichetta in ingresso corrisponde a un L-LSP che supporta il PSC AF1, allora il mapping `Encaps-->PHB' dovrebbe essere popolato con:

  CLP Field              PHB

    0          ---->    AF11
    1          ---->    AF12

4.2.2.1 Mapping `CLP/PSC --> PHB' predefinito

  CLP Bit      PSC             PHB

        DF    ---->    DF
        CSn   ---->    CSn
        AFn   ---->    AFn1
        AFn   ---->    AFn2
        EF    ---->    EF

4.2.3 Mapping `DE-->PHB'

Se l'LSR non termina un livello MPLS Shim su questa etichetta in ingresso e usa l'incapsulamento Frame Relay (cioè è un FR-LSR), allora il mapping `Encaps-->PHB' per questo L-LSP in ingresso è popolato nel modo seguente:

è effettivamente un mapping `DE-->PHB'
il mapping è una funzione del PSC che è trasportato su questo LSP, e dovrebbe usare le voci di mapping rilevanti per questo PSC dal mapping `DE/PSC-->PHB' predefinito definito nella sezione 4.2.3.1.

4.2.3.1 Mapping `DE/PSC --> PHB' predefinito

  DE Bit      PSC             PHB

        DF    ---->    DF
        CSn   ---->    CSn
        AFn   ---->    AFn1
        AFn   ---->    AFn2
        EF    ---->    EF

4.3 Determinazione del PHB in ingresso su un L-LSP in ingresso

Questa sezione definisce come la determinazione del PHB in ingresso è eseguita quando la voce di etichetta considerata nello stack di etichette ricevuto corrisponde a un L-LSP. Ciò richiede che il mapping `Encaps-->PHB' sia popolato come definito nella sezione 4.2.

Quando si considera una voce di etichetta corrispondente a un L-LSP in ingresso per la determinazione del PHB in ingresso, l'LSR determina prima il mapping `Encaps-->PHB' associato all'etichetta corrispondente.

4.3.1 Mapping `EXP-->PHB'

Se il mapping Encaps-->PHB' è della forma mapping EXP-->PHB', allora l'LSR:

determina il PHB in ingresso guardando il campo EXP della voce di etichetta considerata e usando il mapping `EXP-->PHB'.

4.3.2 Mapping `CLP-->PHB'

Se il mapping Encaps-->PHB' è della forma mapping CLP-->PHB', allora l'LSR:

determina il PHB in ingresso guardando il campo CLP dell'incapsulamento del livello ATM e usando il mapping `CLP-->PHB'.

4.3.3 Mapping `DE-->PHB'

Se il mapping Encaps-->PHB' è della forma mapping DE-->PHB', allora l'LSR:

determina il PHB in ingresso guardando il campo DE dell'incapsulamento Frame Relay e usando il mapping `DE-->PHB'.

4.4 Popolamento dell'`insieme di mapping PHB-->Encaps' per un L-LSP in

uscita

Questa sezione definisce come l'`insieme di mapping PHB-->Encaps' del Diff-Serv Context è popolato al set-up dell'etichetta per un L-LSP in uscita al fine di consentire la codifica delle informazioni Diff-Serv.

4.4.1 Mapping `PHB-->EXP'

Se l'LSR usa un livello MPLS Shim su questo L-LSP in uscita, allora un mapping PHB-->EXP' è aggiunto all'insieme di mapping PHB-->Encaps' per questo L-LSP in uscita. Questo mapping `PHB-->EXP' è popolato nel modo seguente:

è una funzione del PSC supportato su questo LSP, e deve usare le voci di mapping rilevanti per questo PSC dal mapping `PHB-->EXP' obbligatorio definito nella sezione 4.4.1.1.

Ad esempio, se l'etichetta in uscita corrisponde a un L-LSP che supporta il PSC AF1, allora il seguente mapping PHB-->EXP' è aggiunto all'insieme di mapping PHB-->Encaps':

     PHB                EXP Field

     AF11       ---->      001
     AF12       ---->      010
     AF13       ---->      011

4.4.1.1 Mapping `PHB-->EXP' obbligatorio

     PHB                EXP Field

     DF         ---->      000
     CSn        ---->      000
     AFn1       ---->      001
     AFn2       ---->      010
     AFn3       ---->      011
     EF         ---->      000

4.4.2 Mapping `PHB-->CLP'

Se l'L-LSP esce su un'interfaccia ATM (cioè è un ATM-LSR oppure è un LSR basato su frame che invia pacchetti su un'interfaccia LC-ATM o su un'interfaccia ATM che non è controllata dal label switching), allora un mapping PHB-->CLP' è aggiunto all'insieme di mapping PHB-->Encaps' per questo L-LSP in uscita.

Se l'L-LSP esce su un'interfaccia ATM che non è label-controlled, il mapping `PHB-->CLP' è popolato come da sezione 3.4.2.

Se l'L-LSP esce su un'interfaccia LC-ATM, il mapping `PHB-->CLP' è popolato nel modo seguente:

è una funzione del PSC supportato su questo LSP, e dovrebbe usare le voci di mapping rilevanti per questo PSC dal mapping `PHB-->CLP' predefinito definito nella sezione 3.4.2.1.

Si noti che se l'LSR è un LSR basato su frame che supporta un L-LSP uscente su un'interfaccia ATM, allora l'insieme di mapping PHB-->Encaps' contiene sia un mapping PHB-->EXP' sia un mapping PHB-->CLP'. Se l'LSR è un ATM-LSR che supporta un L-LSP, allora l'insieme di mapping PHB-->Encaps' contiene solo un mapping `PHB-->CLP'.

4.4.3 Mapping `PHB-->DE'

Se l'L-LSP esce su un'interfaccia Frame Relay (cioè è un LSR che invia pacchetti su un'interfaccia LC-FR o su un'interfaccia Frame Relay che non è controllata dal label switching), un mapping PHB-->DE' è aggiunto all'insieme di mapping PHB-->Encaps' per questo L-LSP in uscita.

Se l'L-LSP esce su un'interfaccia FR che non è controllata dal label switching, il mapping `PHB-->DE' è popolato come da sezione 3.4.3.

Se l'L-LSP esce su un'interfaccia LC-FR, il mapping `PHB-->DE' è popolato nel modo seguente:

è una funzione del PSC supportato su questo LSP, e dovrebbe usare le voci di mapping rilevanti per questo PSC dal mapping `PHB-->DE' predefinito definito nella sezione 3.4.3.1.

Si noti che se l'LSR è un Edge-LSR che supporta un L-LSP uscente su un'interfaccia LC-FR, allora l'insieme di mapping PHB-->Encaps' contiene sia un mapping PHB-->EXP' sia un mapping PHB-->DE'. Se l'LSR è un FR-LSR che supporta un L-LSP, allora l'insieme di mapping PHB-->Encaps' contiene solo un mapping `PHB-->DE'.

4.4.4 Mapping `PHB-->802.1'

Se l'LSP esce su un'interfaccia LAN su cui sono supportate più classi di traffico 802.1, come definito in [IEEE_802.1], allora un mapping `PHB-->802.1' è aggiunto come da sezione 3.4.4.

4.5 Codifica delle informazioni Diff-Serv nel livello di

incapsulamento su un L-LSP in uscita

Questa sezione definisce come codificare le informazioni Diff-Serv nel livello di incapsulamento MPLS per una voce di etichetta trasmessa corrispondente a un L-LSP in uscita. Ciò richiede che l'`insieme di mapping PHB-->Encaps' sia popolato come definito nella sezione 4.4.

L'LSR determina prima l'`insieme di mapping PHB-->Encaps' del Diff-Serv Context associato all'etichetta corrispondente nella NHLFE e poi esegue la codifica corrispondente come specificato nelle sezioni 3.5.1, 3.5.2, 3.5.3 e 3.5.4.

4.6 Merge di L-LSP

In un dominio MPLS, due o più LSP possono essere uniti in un LSP in un LSR. Gli L-LSP sono compatibili con il merge di LSP sotto la seguente condizione:

  Gli L-LSP possono essere uniti in un solo L-LSP se supportano lo
  stesso PSC.

La condizione di merge di cui sopra MUST essere applicata dagli LSR, attraverso un controllo esplicito al set-up dell'etichetta, che lo stesso PSC sia supportato sugli LSP uniti.

Si noti che quando gli L-LSP si uniscono, la banda disponibile per il PSC a valle del punto di merge deve essere sufficiente a trasportare la somma del traffico unito. Ciò è particolarmente importante nel caso del traffico EF. Ciò può essere assicurato in più modi (ad esempio via provisioning, oppure via segnalazione di banda e controllo di ammissione esplicito).

5. Estensione RSVP per il supporto Diff-Serv

L'architettura MPLS non assume un singolo protocollo di distribuzione delle etichette. [RSVP_MPLS_TE] definisce l'estensione a RSVP per stabilire LSP nelle reti MPLS. Questa sezione specifica le estensioni a RSVP, oltre a quelle definite in [RSVP_MPLS_TE], per stabilire LSP che supportano i Differentiated Services nelle reti MPLS.

5.1 Formato dei messaggi RSVP correlati a Diff-Serv

In questo documento è definito un nuovo oggetto RSVP: l'oggetto DIFFSERV. La descrizione dettagliata di questo oggetto è fornita più avanti. Questo nuovo oggetto è applicabile ai messaggi Path. Questa specifica definisce solo l'uso dell'oggetto DIFFSERV nei messaggi Path usati per stabilire LSP Tunnel in conformità con [RSVP_MPLS_TE] e che quindi contengono un oggetto Session con un C-Type uguale a LSP_TUNNEL_IPv4 e contengono un oggetto LABEL_REQUEST.

Le restrizioni definite in [RSVP_MPLS_TE] per il supporto dell'establishment di LSP Tunnel via RSVP sono anche applicabili all'establishment di LSP Tunnel che supportano Diff-Serv: ad esempio, sono supportati solo LSP unicast e gli LSP multicast sono per studio futuro.

Questo nuovo oggetto DIFFSERV è opzionale rispetto a RSVP così che le implementazioni RSVP generali non interessate al set-up di LSP MPLS non devono supportare questo oggetto.

L'oggetto DIFFSERV è opzionale per il supporto degli LSP Tunnel come definiti in [RSVP_MPLS_TE]. Un LSR capace di Diff-Serv che supporta E-LSP che usano il mapping EXP<-->PHB' preconfigurato in conformità con questa specifica MAY supportare l'oggetto DIFFSERV. Un LSR capace di Diff-Serv che supporta E-LSP che usano un mapping EXP<-->PHB' segnalato in conformità con questa specifica MUST supportare l'oggetto DIFFSERV. Un LSR capace di Diff-Serv che supporta L-LSP in conformità con questa specifica MUST supportare l'oggetto DIFFSERV.

5.1.1 Formato del messaggio Path

Il formato del messaggio Path è il seguente:

     <Path Message> ::=       <Common Header> [ <INTEGRITY> ]
                              <SESSION> <RSVP_HOP>
                              <TIME_VALUES>
                              [ <EXPLICIT_ROUTE> ]
                              <LABEL_REQUEST>
                              [ <SESSION_ATTRIBUTE> ]
                              [ <DIFFSERV> ]
                              [ <POLICY_DATA> ... ]
                              [ <sender descriptor> ]

     <sender descriptor> ::=  <SENDER_TEMPLATE> <SENDER_TSPEC>
                              [ <ADSPEC> ]
                              [ <RECORD_ROUTE> ]

5.2 Oggetto DIFFSERV

I formati dell'oggetto DIFFSERV sono mostrati di seguito. Attualmente ci sono due possibili C_Type. Il Type 1 è un oggetto DIFFSERV per un E-LSP. Il Type 2 è un oggetto DIFFSERV per un L-LSP.

5.2.1. Oggetto DIFFSERV per un E-LSP:

class = 65, C_Type = 1

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Reserved                                       | MAPnb |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            MAP (1)                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  //                               ...                            //
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            MAP (MAPnb)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Reserved : 28 bits
     Questo campo è riservato. Deve essere impostato a zero in
     trasmissione e deve essere ignorato in ricezione.

  MAPnb : 4 bits
     Indica il numero di voci MAP incluse nell'oggetto DIFFSERV.
     Questo può essere impostato a qualsiasi valore da 0 a 8.

  MAP : 32 bits
     Ciascuna voce MAP definisce il mapping tra un valore del campo
     EXP e un PHB. La voce MAP ha il seguente formato:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Reserved     | EXP |             PHBID             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Reserved : 13 bits
     Questo campo è riservato. Deve essere impostato a zero in
     trasmissione e deve essere ignorato in ricezione.

  EXP : 3 bits
     Questo campo contiene il valore del campo EXP per il mapping
     `EXP<-->PHB' definito in questa voce MAP.

  PHBID : 16 bits
     Questo campo contiene il PHBID del PHB per il mapping
     `EXP<-->PHB' definito in questa voce MAP. Il PHBID è codificato
     come specificato in [PHBID].

5.2.2 Oggetto DIFFSERV per un L-LSP:

class = 65, C_Type = 2

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Reserved               |             PSC               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Reserved : 16 bits
     Questo campo è riservato. Deve essere impostato a zero in
     trasmissione e deve essere ignorato in ricezione.

  PSC : 16 bits
     Il PSC indica una PHB Scheduling Class da supportare
     dall'LSP. Il PSC è codificato come specificato in [PHBID].

5.3 Gestione dell'oggetto DIFFSERV

Per stabilire un tunnel LSP con RSVP, il mittente crea un messaggio Path con un tipo di sessione di LSP_Tunnel_IPv4 e con un oggetto LABEL_REQUEST come da [RSVP_MPLS_TE].

Per stabilire un tunnel E-LSP con RSVP che usa il mapping `EXP<-->PHB' preconfigurato, il mittente crea un messaggio Path:

con un tipo di sessione di LSP_Tunnel_IPv4,
con l'oggetto LABEL_REQUEST, e
senza l'oggetto DIFFSERV.

Per stabilire un tunnel E-LSP con RSVP che usa il mapping `EXP<-->PHB' preconfigurato, il mittente MAY in alternativa creare un messaggio Path:

con un tipo di sessione di LSP_Tunnel_IPv4,
con l'oggetto LABEL_REQUEST, e
con l'oggetto DIFFSERV per un E-LSP che non contiene voci MAP.

Per stabilire un tunnel E-LSP con RSVP che usa un mapping `EXP<-->PHB' segnalato, il mittente crea un messaggio Path:

con un tipo di sessione di LSP_Tunnel_IPv4,
con l'oggetto LABEL_REQUEST,
con l'oggetto DIFFSERV per un E-LSP che contiene una voce MAP per ciascun valore EXP da supportare su questo E-LSP.

Per stabilire con RSVP un tunnel L-LSP, il mittente crea un messaggio Path:

con un tipo di sessione di LSP_Tunnel_IPv4,
con l'oggetto LABEL_REQUEST,
con l'oggetto DIFFSERV per un L-LSP che contiene la PHB Scheduling Class (PSC) supportata su questo L-LSP.

Se un messaggio path contiene più oggetti DIFFSERV, solo il primo è significativo; i successivi oggetti DIFFSERV devono essere ignorati e non inoltrati.

Ciascun LSR lungo il percorso registra l'oggetto DIFFSERV, quando presente, nel suo path state block.

Se un oggetto DIFFSERV non è presente nel messaggio Path, l'LSR SHOULD interpretare ciò come una richiesta di un E-LSP che usa il mapping `EXP<-->PHB' preconfigurato. Tuttavia, a fini di retrocompatibilità con altre opzioni di Quality of Service non Diff-Serv consentite da [RSVP_MPLS_TE] come Integrated Services Controlled Load o Guaranteed Services, l'LSR MAY supportare un'opzione di "override" configurabile. Quando questa "opzione di override" è configurata, l'LSR interpreta un messaggio path senza un oggetto Diff-Serv come una richiesta di un LSP con tale Quality of Service non Diff-Serv.

Se un oggetto DIFFSERV per un E-LSP che non contiene voci MAP è presente nel messaggio Path, l'LSR MUST interpretare ciò come una richiesta di un E-LSP che usa il mapping EXP<-->PHB' preconfigurato. In particolare, ciò consente a un LSR con l'"opzione di override" configurata di supportare E-LSP con mapping EXP<-->PHB' preconfigurato, contemporaneamente a LSP con Quality of Service non Diff-Serv.

Se un oggetto DIFFSERV per un E-LSP che contiene almeno una voce MAP è presente nel messaggio Path, l'LSR MUST interpretare ciò come una richiesta di un E-LSP con mapping `EXP<-->PHB' segnalato.

Se un oggetto DIFFSERV per un L-LSP è presente nel messaggio Path, l'LSR MUST interpretare ciò come una richiesta di un L-LSP.

L'LSR di destinazione di un E-LSP o di un L-LSP risponde al messaggio Path contenente l'oggetto LABEL_REQUEST inviando un messaggio Resv:

con l'oggetto LABEL
senza un oggetto DIFFSERV.

Assumendo che la label request sia accettata e che un'etichetta sia allocata, gli LSR Diff-Serv (mittente, destinazione, nodi intermedi) devono:

aggiornare il Diff-Serv Context associato agli LSP stabiliti nel loro ILM/FTN come specificato nelle sezioni precedenti (etichetta in ingresso e in uscita),
installare il trattamento di inoltro Diff-Serv richiesto (comportamento di scheduling e di dropping) per questa NHLFE (etichetta in uscita).

Un LSR che riconosce l'oggetto DIFFSERV e che riceve un messaggio path che contiene l'oggetto DIFFSERV ma che non contiene un oggetto LABEL_REQUEST oppure che non ha un tipo di sessione di LSP_Tunnel_IPv4, invia un PathErr verso il mittente con il codice di errore Diff-Serv Error' e un valore di errore di Unexpected DIFFSERV object'. Questi sono definiti più avanti nella sezione 5.5.

Un LSR che riceve un messaggio Path con l'oggetto DIFFSERV per E-LSP, che riconosce l'oggetto DIFFSERV ma non supporta il particolare PHB codificato in una o più delle voci MAP, invia un PathErr verso il mittente con il codice di errore Diff-Serv Error' e un valore di errore di Unsupported PHB'. Questi sono definiti più avanti nella sezione 5.5.

Un LSR che riceve un messaggio Path con l'oggetto DIFFSERV per E-LSP, che riconosce l'oggetto DIFFSERV ma determina che il mapping EXP<-->PHB' segnalato non è valido, invia un PathErr verso il mittente con il codice di errore Diff-Serv Error' e un valore di errore di Invalid EXP<-->PHB mapping'. Questi sono definiti più avanti nella sezione 5.5. Il mapping EXP<-->PHB' segnalato nell'oggetto DIFFSERV per un E-LSP non è valido quando:

il campo MAPnb non è nell'intervallo da 0 a 8 oppure
un dato valore EXP compare in più di una voce MAP, oppure
la codifica del PHBID non è valida.

Un LSR che riceve un messaggio Path con l'oggetto DIFFSERV per L-LSP, che riconosce l'oggetto DIFFSERV ma non supporta il particolare PSC codificato nel campo PSC, invia un PathErr verso il mittente con il codice di errore Diff-Serv Error' e un valore di errore di Unsupported PSC'. Questi sono definiti più avanti nella sezione 5.5.

Un LSR che riceve un messaggio Path con l'oggetto DIFFSERV, che riconosce l'oggetto DIFFSERV ma che non è in grado di allocare il contesto Diff-Serv per-LSP richiesto, invia un PathErr con il codice di errore "Diff-Serv Error" e il valore di errore "Per-LSP context allocation failure". Questi sono definiti più avanti nella sezione 5.5.

Un LSR Diff-Serv MUST gestire le situazioni in cui la label request non può essere accettata per ragioni diverse da quelle già discusse in questa sezione, in conformità con [RSVP_MPLS_TE] (ad es., prenotazione rifiutata dal controllo di ammissione, un'etichetta non può essere associata).

5.4 Non-supporto dell'oggetto DIFFSERV

Un LSR che non riconosce il Class-Num dell'oggetto DIFFSERV MUST comportarsi in conformità con le procedure specificate in [RSVP] per un Class-Num sconosciuto il cui formato è 0bbbbbbb, cioè deve inviare un PathErr con il codice di errore `Unknown object class' verso il mittente.

Un LSR che riconosce il Class-Num dell'oggetto DIFFSERV ma non riconosce il C-Type dell'oggetto DIFFSERV deve comportarsi in conformità con le procedure specificate in [RSVP] per un C-type sconosciuto, cioè deve inviare un PathErr con il codice di errore `Unknown object C-Type' verso il mittente.

In entrambe le situazioni, ciò fa fallire il set-up del percorso. Il mittente dovrebbe notificare alla gestione che un L-LSP non può essere stabilito e dovrebbe possibilmente prendere azioni per ritentare l'establishment dell'LSP senza l'oggetto DIFFSERV (ad es., tentare di usare E-LSP con mapping `EXP<-->PHB' preconfigurato come strategia di fall-back).

5.5 Codici di errore per Diff-Serv

Nelle procedure descritte sopra, certi errori devono essere segnalati come un Diff-Serv Error'. Il valore del codice di errore Diff-Serv Error' è 27.

Quanto segue definisce i valori di errore per il Diff-Serv Error:

  Value    Error

     Unexpected DIFFSERV object
     Unsupported PHB
     Invalid `EXP<-->PHB mapping'
     Unsupported PSC
     Per-LSP context allocation failure

5.6 Tipo di servizio Intserv

Sia gli E-LSP sia gli L-LSP possono essere stabiliti con o senza prenotazione di banda.

Come specificato in [RSVP_MPLS_TE], per stabilire un E-LSP o un L-LSP con prenotazione di banda, si usa il servizio Controlled Load di Int-Serv (o possibilmente Guaranteed Service) e la banda è segnalata nel SENDER_TSPEC (rispettivamente FLOWSPEC) del messaggio path (rispettivamente Resv).

Come specificato in [RSVP_MPLS_TE], per stabilire un E-LSP o un L-LSP senza prenotazione di banda, si usa il Null Service specificato in [NULL].

Si noti che questa specifica definisce l'uso di E-LSP e L-LSP per il supporto del solo servizio Diff-Serv. Indipendentemente dal servizio Intserv (Controlled Load, Null Service, Guaranteed Service,...) e indipendentemente dal fatto che la prenotazione sia con o senza prenotazione di banda, gli E-LSP e gli L-LSP sono definiti qui per il supporto dei servizi Diff-Serv. Il supporto dei servizi Int-Serv su un backbone MPLS Diff-Serv è al di fuori dell'ambito di questa specifica.

Si noti inoltre che questa specifica non si interessa dell'oggetto DCLASS definito in [DCLASS], poiché questo oggetto trasmette informazioni sui valori DSCP, che non sono rilevanti all'interno della rete MPLS.

6. Estensioni LDP per il supporto Diff-Serv

L'architettura MPLS non assume un singolo protocollo di distribuzione delle etichette. [LDP] definisce il Label Distribution Protocol e il suo uso per l'establishment di label switched path (LSP) nelle reti MPLS. Questa sezione specifica le estensioni a LDP per stabilire LSP che supportano i Differentiated Services nelle reti MPLS.

In questo documento è definito un nuovo LDP TLV:

il Diff-Serv TLV

La descrizione dettagliata di questo TLV è fornita più avanti.

Il nuovo Diff-Serv TLV è opzionale rispetto a LDP. Un LSR capace di Diff-Serv che supporta E-LSP che usano il mapping EXP<-->PHB' preconfigurato in conformità con questa specifica MAY supportare il Diff-Serv TLV. Un LSR capace di Diff-Serv che supporta E-LSP che usano il mapping EXP<-->PHB' segnalato in conformità con questa specifica MUST supportare il Diff-Serv TLV. Un LSR capace di Diff-Serv che supporta L-LSP in conformità con questa specifica MUST supportare il Diff-Serv TLV.

6.1 Diff-Serv TLV

Il Diff-Serv TLV ha i seguenti formati:

Diff-Serv TLV per un E-LSP:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |U|F|  Diff-Serv (0x0901)       |      Length                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |T|        Reserved                                     | MAPnb |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            MAP (1)                            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 ...

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                            MAP (MAPnb)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  T:1 bit
     Tipo di LSP. Questo è impostato a 0 per un E-LSP

  Reserved : 27 bits
     Questo campo è riservato. Deve essere impostato a zero in
     trasmissione e deve essere ignorato in ricezione.

  MAPnb : 4 bits
     Indica il numero di voci MAP incluse nell'oggetto DIFFSERV.
     Questo può essere impostato a qualsiasi valore da 1 a 8.









  MAP : 32 bits
     Ciascuna voce MAP definisce il mapping tra un valore del campo
     EXP e un PHB. La voce MAP ha il seguente formato:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Reserved     | EXP |             PHBID             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Reserved : 13 bits
     Questo campo è riservato. Deve essere impostato a zero in
     trasmissione e deve essere ignorato in ricezione.

  EXP : 3 bits
     Questo campo contiene il valore del campo EXP per il mapping
     `EXP<-->PHB' definito in questa voce MAP.

  PHBID : 16 bits
     Questo campo contiene il PHBID del PHB per il mapping
     `EXP<-->PHB' definito in questa voce MAP. Il PHBID è codificato
     come specificato in [PHBID].

Diff-Serv TLV per un L-LSP:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |U|F| Type = PSC (0x0901)       |      Length                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |T|        Reserved             |              PSC              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  T:1 bit
     Tipo di LSP. Questo è impostato a 1 per un L-LSP

  Reserved : 15 bits
     Questo campo è riservato. Deve essere impostato a zero in
     trasmissione e deve essere ignorato in ricezione.

  PSC : 16 bits
     Il PSC indica una PHB Scheduling Class da supportare
     dall'LSP. Il PSC è codificato come specificato in [PHBID].

6.2 Valori del Status Code Diff-Serv

I seguenti valori sono definiti per il campo Status Code del Status TLV:

     Status Code                             E   Status Data

     Unexpected Diff-Serv TLV                0   0x01000001
     Unsupported PHB                         0   0x01000002
     Invalid `EXP<-->PHB mapping'            0   0x01000003
     Unsupported PSC                         0   0x01000004
     Per-LSP context allocation failure      0   0x01000005

6.3 Messaggi LDP correlati a Diff-Serv

6.3.1 Messaggio Label Request

Il formato del messaggio Label Request è esteso come segue, per includere opzionalmente il Diff-Serv TLV:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Request (0x0401) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diff-Serv TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3.2 Messaggio Label Mapping

Il formato del messaggio Label Mapping è esteso come segue, per includere opzionalmente il Diff-Serv TLV:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Label Mapping (0x0400) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diff-Serv TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3.3 Messaggio Label Release

Il formato del messaggio Label Release è esteso come segue, per includere opzionalmente lo Status TLV:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0|   Label Release (0x0403)   |      Message Length            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Message ID                                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     FEC TLV                                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Label TLV (optional)                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Status TLV (optional)                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3.4 Messaggio Notification

Il formato del messaggio Notification è esteso come segue, per includere opzionalmente il Diff-Serv TLV:

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Notification (0x0001) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diff-Serv TLV (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.4 Gestione del Diff-Serv TLV

6.4.1 Gestione del Diff-Serv TLV in modalità Downstream Unsolicited

Questa sezione descrive le operazioni quando si usa la modalità Downstream Unsolicited.

Quando si alloca un'etichetta per un E-LSP che deve usare il mapping `EXP<-->PHB' preconfigurato, un LSR Diff-Serv a valle emette un messaggio Label Mapping senza il Diff-Serv TLV.

Quando si alloca un'etichetta per un E-LSP che deve usare un mapping `EXP<-->PHB' segnalato, un LSR Diff-Serv a valle emette un messaggio Label Mapping con il Diff-Serv TLV per un E-LSP che contiene una voce MAP per ciascun valore EXP da supportare su questo E-LSP.

Quando si alloca un'etichetta per un L-LSP, un LSR Diff-Serv a valle emette un messaggio Label Mapping con il Diff-Serv TLV per un L-LSP che contiene la PHB Scheduling Class (PSC) da supportare su questo L-LSP.

Assumendo che il set-up dell'etichetta abbia successo, gli LSR a valle e a monte devono:

aggiornare il Diff-Serv Context associato agli LSP stabiliti nel loro ILM/FTN come specificato nelle sezioni precedenti (etichetta in ingresso e in uscita),
installare il trattamento di inoltro Diff-Serv richiesto (comportamento di scheduling e di dropping) per questa NHLFE (etichetta in uscita).

Un LSR Diff-Serv a monte che riceve un messaggio Label Mapping con più Diff-Serv TLV considera solo il primo come significativo. L'LSR deve ignorare e non inoltrare i successivi Diff-Serv TLV.

Un LSR Diff-Serv a monte che riceve un messaggio Label Mapping, con il Diff-Serv TLV per un E-LSP e non supporta il particolare PHB codificato in una o più delle voci MAP, deve rifiutare il mapping inviando un messaggio Label Release che include il Label TLV e lo Status TLV con uno Status Code di `Unsupported PHB'.

Un LSR Diff-Serv a monte che riceve un messaggio Label Mapping con il Diff-Serv TLV per un E-LSP e determina che il mapping EXP<-->PHB' segnalato non è valido, deve rifiutare il mapping inviando un messaggio Label Release che include il Label TLV e lo Status TLV con uno Status Code di Invalid EXP<-->PHB mapping'. Il mapping `EXP<-->PHB' segnalato nell'oggetto DIFFSERV per un E-LSP non è valido quando:

il campo MAPnb non è nell'intervallo da 1 a 8, oppure
un dato valore EXP compare in più di una voce MAP, oppure
la codifica del PHBID non è valida

Un LSR Diff-Serv a monte che riceve un messaggio Label Mapping con il Diff-Serv TLV per un L-LSP contenente un valore PSC che non è supportato, deve rifiutare il mapping inviando un messaggio Label Release che include il Label TLV e lo Status TLV con uno Status Code di `Unsupported PSC'.

6.4.2 Gestione del Diff-Serv TLV in modalità Downstream on Demand

Questa sezione descrive le operazioni quando si usa la modalità Downstream on Demand.

Quando si richiede un'etichetta per un E-LSP che deve usare il mapping `EXP<-->PHB' preconfigurato, un LSR Diff-Serv a monte invia un messaggio Label Request senza il Diff-Serv TLV.

Quando si richiede un'etichetta per un E-LSP che deve usare un mapping `EXP<-->PHB' segnalato, un LSR Diff-Serv a monte invia un messaggio Label Request con il Diff-Serv TLV per un E-LSP che contiene una voce MAP per ciascun valore EXP da supportare su questo E-LSP.

Quando si richiede un'etichetta per un L-LSP, un LSR Diff-Serv a monte invia un messaggio Label Request con il Diff-Serv TLV per un L-LSP che contiene il PSC da supportare su questo L-LSP.

Un LSR Diff-Serv a valle che invia un messaggio Label Mapping in risposta a un messaggio Label Request per un E-LSP o un L-LSP non deve includere un Diff-Serv TLV in questo messaggio Label Mapping. Assumendo che il set-up dell'etichetta abbia successo, gli LSR a valle e a monte devono:

aggiornare il Diff-Serv Context associato agli LSP stabiliti nel loro ILM/FTN come specificato nelle sezioni precedenti (etichetta in ingresso e in uscita),
installare il trattamento di inoltro Diff-Serv richiesto (comportamento di scheduling e di dropping) per questa NHLFE (etichetta in uscita).

Un LSR Diff-Serv a monte che riceve un messaggio Label Mapping contenente un Diff-Serv TLV in risposta al suo messaggio Label Request, deve rifiutare il label mapping inviando un messaggio Label Release che include il Label TLV e lo Status TLV con uno Status Code di `Unexpected Diff-Serv TLV'.

Un LSR Diff-Serv a valle che riceve un messaggio Label Request con più Diff-Serv TLV considera solo il primo come significativo. L'LSR deve ignorare e non inoltrare i successivi Diff-Serv TLV.

Un LSR Diff-Serv a valle che riceve un messaggio Label Request con il Diff-Serv TLV per un E-LSP e non supporta il particolare PHB codificato in una (o più) delle voci MAP, deve rifiutare la richiesta inviando un messaggio Notification che include lo Status TLV con uno Status Code di `Unsupported PHB'.

Un LSR Diff-Serv a valle che riceve un messaggio Label Request con il Diff-Serv TLV per un E-LSP e determina che il mapping EXP<-->PHB' segnalato non è valido, deve rifiutare la richiesta inviando un messaggio Notification che include lo Status TLV con uno Status Code di Invalid EXP<-->PHB mapping'. Il mapping `EXP<-->PHB' segnalato nel DIFFSERV TLV per un E-LSP non è valido quando:

il campo MAPnb non è nell'intervallo da 1 a 8, oppure
un dato valore EXP compare in più di una voce MAP, oppure
la codifica del PHBID non è valida

Un LSR Diff-Serv a valle che riceve un messaggio Label Request con il Diff-Serv TLV per un L-LSP contenente un valore PSC che non è supportato, deve rifiutare la richiesta inviando un messaggio Notification che include lo Status TLV con uno Status Code di `Unsupported PSC'.

Un LSR Diff-Serv a valle che riconosce il Type del Diff-Serv TLV in un messaggio Label Request ma non è in grado di allocare le informazioni di contesto per-LSP richieste, deve rifiutare la richiesta inviando un messaggio Notification che include lo Status TLV con uno Status Code di `Per-LSP context allocation failure'.

Un LSR Diff-Serv a valle che riconosce il Type del Diff-Serv TLV in un messaggio Label Request e supporta il PSC richiesto ma non è in grado di soddisfare la label request per altre ragioni (ad es., nessuna etichetta disponibile), deve inviare un messaggio Notification in conformità con le procedure LDP esistenti [LDP] (ad es., con uno Status Code `No Label Resource'). Questo messaggio Notification deve includere il Diff-Serv TLV richiesto.

6.5 Non-gestione del Diff-Serv TLV

Un LSR che non riconosce il Type del Diff-Serv TLV, alla ricezione di un messaggio Label Request o di un messaggio Label Mapping contenente il Diff-Serv TLV, deve comportarsi in conformità con le procedure specificate in [LDP] per un TLV sconosciuto i cui bit U e F sono impostati a 0, cioè deve ignorare il messaggio e restituire un messaggio Notification con Status `Unknown TLV'.

6.6 Informazioni di banda

Le informazioni di banda possono anche essere segnalate al momento dell'establishment di E-LSP e L-LSP, ad esempio a scopo di Traffic Engineering, usando il Traffic Parameters TLV come descritto in [MPLS CR LDP].

7. Supporto MPLS di Diff-Serv su interfacce PPP, LAN, Non-LC-ATM e

Non-LC-FR

Le operazioni generali per il supporto MPLS di Diff-Serv, incluse le operazioni di inoltro delle etichette e di set-up degli LSP, sono specificate nelle sezioni precedenti. Questa sezione descrive le operazioni specifiche richieste per il supporto MPLS di Diff-Serv su interfacce PPP, interfacce LAN, interfacce ATM che non sono label controlled e interfacce Frame Relay che non sono label controlled.

Su queste interfacce, questa specifica consente una qualsiasi delle seguenti combinazioni di LSP per FEC:

Zero o un numero qualsiasi di E-LSP, e
Zero o un numero qualsiasi di L-LSP.

Un LSR capace di Diff-Serv MUST supportare E-LSP che usano il mapping `EXP<-->PHB' preconfigurato su queste interfacce.

Un LSR capace di Diff-Serv MAY supportare E-LSP che usano il mapping `EXP<-->PHB' segnalato e L-LSP su queste interfacce.

8. Supporto MPLS di Diff-Serv su interfacce LC-ATM

Questa sezione descrive le operazioni specifiche richieste per il supporto MPLS di Diff-Serv su interfacce ATM controllate dal label switching (LC-ATM).

Questo documento consente un numero qualsiasi di L-LSP per FEC all'interno di un dominio MPLS ATM Diff-Serv. Gli E-LSP non sono supportati su interfacce LC-ATM.

8.1 Uso delle classi di traffico ATM e dei meccanismi di Traffic

Management

L'uso delle "ATM service categories" specificate dall'ATM Forum, delle "ATM Transfer Capabilities" specificate dall'ITU-T o di classi di traffico ATM specifiche del fornitore è al di fuori dell'ambito di questa specifica. L'unico requisito per un'implementazione conforme è che il comportamento di inoltro sperimentato da un Behavior Aggregate inoltrato su un L-LSP dall'ATM LSR MUST essere conforme alle specifiche del PHB Diff-Serv corrispondenti.

Poiché c'è solo un bit (CLP) per codificare il valore di drop precedence del PHB su collegamenti ATM, solo due diversi livelli di drop precedence sono supportati negli ATM LSR. Le sezioni 4.2.2 e 4.4.2 definiscono come i tre livelli di drop precedence degli Ordered Aggregate AFn sono mappati su questi due livelli di drop precedence ATM. Questo mapping è in conformità con i requisiti specificati in [DIFF_AF] per il caso in cui sono supportati solo due livelli di drop precedence.

Per evitare di scartare parti dei pacchetti, i meccanismi di frame discard, come Early Packet Discard (EPD) (si veda [ATMF_TM]) SHOULD essere abilitati negli ATM-LSR per tutti i PHB descritti in questo documento.

8.2 Implementazione di LSR con interfacce LC-ATM

Un LSR capace di Diff-Serv MUST supportare L-LSP su interfacce LC-ATM. Questa specifica assume che gli Edge-LSR del dominio ATM-LSR usino il metodo di incapsulamento "shim header" definito in [MPLS_ATM]. Le operazioni senza l'incapsulamento "shim header" sono al di fuori dell'ambito di questa specifica.

9. Supporto MPLS di Diff-Serv su interfacce LC-FR

Questa sezione descrive le operazioni specifiche richieste per il supporto MPLS di Diff-Serv su interfacce Frame Relay controllate dal label switching (LC-FR).

Questo documento consente un numero qualsiasi di L-LSP per FEC all'interno di un dominio MPLS Frame Relay Diff-Serv. Gli E-LSP non sono supportati su interfacce LC-FR.

9.1 Uso dei parametri di traffico Frame Relay e dei meccanismi di

Traffic Management

L'uso dei parametri di traffico Frame Relay come specificati dall'ITU-T e dal Frame Relay-Forum o di meccanismi di traffic management Frame Relay specifici del fornitore è al di fuori dell'ambito di questa specifica. L'unico requisito per un'implementazione conforme è che il comportamento di inoltro sperimentato da un Behavior Aggregate inoltrato su un L-LSP dal Frame Relay LSR MUST essere conforme alle specifiche del PHB Diff-Serv corrispondenti.

Poiché c'è solo un bit (DE) per codificare il valore di drop precedence del PHB su collegamenti Frame Relay, solo due diversi livelli di drop precedence sono supportati nei Frame Relay LSR. Le sezioni 4.2.3 e 4.4.3 definiscono come i tre livelli di drop precedence degli Ordered Aggregate AFn sono mappati su questi due livelli di drop precedence Frame Relay. Questo mapping è in conformità con i requisiti specificati in [DIFF_AF] per il caso in cui sono supportati solo due livelli di drop precedence.

9.2 Implementazione di LSR con interfacce LC-FR

Un LSR capace di Diff-Serv MUST supportare L-LSP su interfacce LC-Frame Relay.

Questa specifica assume che gli Edge-LSR del dominio FR-LSR usino il metodo di "generic encapsulation" come raccomandato in [MPLS_FR]. Le operazioni senza la "generic encapsulation" sono al di fuori dell'ambito di questa specifica.

10. Considerazioni IANA

Questo documento definisce un certo numero di oggetti con implicazioni per IANA.

Questo documento definisce nella sezione 5.2 un nuovo oggetto RSVP, l'oggetto DIFFSERV. Questo oggetto ha richiesto un numero dallo spazio definito in [RSVP] per quegli oggetti che, se non compresi, causano il rifiuto dell'intero messaggio RSVP con un codice di errore di "Unknown Object Class". Tali oggetti sono identificati da uno zero nel bit più significativo del class number. All'interno di quello spazio, questo oggetto ha richiesto un numero dallo spazio "IETF Consensus". "65" è stato allocato da IANA per l'oggetto DIFFSERV.

Questo documento definisce nella sezione 5.5 un nuovo codice di errore RSVP, "Diffserv Error". Il codice di errore "27" è stato assegnato da IANA al "Diffserv Error". Questo documento definisce i valori da 1 a 5 del campo value da usare all'interno dell'oggetto ERROR_SPEC per questo codice di errore. Le allocazioni future di valori in questo spazio dovrebbero essere gestite da IANA usando la policy First Come First Served definita in [IANA].

Questo documento definisce nella sezione 6.1 un nuovo LDP TLV, il Diffserv TLV. Il numero per questo TLV è stato assegnato per consenso del working group secondo le policy definite in [LDP].

Questo documento definisce nella sezione 6.2 cinque nuovi valori di LDP Status Code per condizioni di errore correlate a Diffserv. I valori per lo Status Code sono stati assegnati per consenso del working group secondo le policy definite in [LDP].

11. Considerazioni sulla sicurezza

Questo documento non introduce alcun nuovo problema di sicurezza oltre a quelli inerenti a Diff-Serv, MPLS e RSVP, e può usare gli stessi meccanismi proposti per quelle tecnologie.

12. Ringraziamenti

Questo documento ha beneficiato di discussioni con Eric Rosen, Angela Chiu e Carol Iturralde. Ha anche attinto dal lavoro svolto da D. Black riguardo all'interazione tra Diff-Serv e tunnel IP.

APPENDICE A. Esempi di scenari di deployment

Questa sezione non fornisce specifiche aggiuntive ed è qui solo per fornire esempi di come questo approccio flessibile per il supporto Diff-Serv su MPLS possa essere dispiegato. I pro e i contro delle varie opzioni di deployment per ambienti particolari sono al di fuori dell'ambito di questo documento.

A.1 Scenario 1: 8 (o meno) BA, nessun Traffic Engineering, nessuna protezione MPLS

Un Service Provider che esegue 8 (o meno) BA su MPLS, non eseguendo Traffic engineering, non usando la protezione MPLS e usando l'incapsulamento MPLS Shim Header nella propria rete, può scegliere di eseguire Diff-Serv su MPLS usando un singolo E-LSP per FEC stabilito via LDP. Inoltre il Service Provider può scegliere di usare il mapping `EXP<-->PHB' preconfigurato.