Passa al contenuto principale

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:

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

    • 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

(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 P rappresenta il nodo penultimo dell'LSP E rappresenta il nodo di uscita dell'LSP

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.