DiffServ over MPLS - Fondazione Ugo Bordoni

Transcript

DiffServ over MPLS
Il DiffServ over MPLS è una tecnica per incanalare il traffico IP in Classi di servizio e gestire
quindi la Qualità del Servizio mediante le creazione di opportune tecniche che garantiscono la
priorità nel trattamento del traffico.
1 DiffServ (Differentiated Services)
La tecnologia DiffServ si fonda sul meccanismo di allocazione preferenziale delle risorse: vengono
introdotti dei livelli di priorità e in base ad essi il traffico viene trattato in un determinato modo. Il
concetto di flusso informativo, introdotto nel IntServ, non ha più significato in questo modello: i
router non devono più gestire una connessione per ogni flusso ma prendono decisioni direttamente
sul singolo datagramma.
L’informazione sul trattamento che un datagramma deve ricevere è trasportata dal datagramma
stesso evitando così la necessità dello scambio delle informazioni di controllo tra i routers e il
mantenimento degli stati nei sistemi attraversati (tramite RSVP).
L’idea del DiffServ è quella di fornire differenti servizi creando delle classi con diverse priorità; per
fare questo viene usato il campo DSCP ( DiffServ Code Point), ottenuto dal campo type-of-service
(TOS) del pacchetto IPv4 o dal campo traffic class di IPv6. Con le classi di servizio tutti i
datagrammi vengono riuniti in pochi flussi aggregati, BA 1 – Behaviour Aggregate, ai quali sono
assegnati diversi trattamenti all’interno della rete.
All’interno della rete non esiste nessuna richiesta fatta da un flusso per ottenere un determinato
trattamento in termini di QoS.
1
Behaviour Aggregate ( BA): un insieme di pacchetti con lo stesso DSCP che attraversano un link in una particolare
direzione
Fondazione Ugo Bordoni © 2007 – Tutti i diritti riservati
http:// www.fub.it
email: [email protected]
Il meccanismo DiffServ può essere riassunto nel modo seguente:
- ai bordi della rete i singoli pacchetti vengono classificati dagli Edge Router 2 che marcano il
campo DSCP presente nella loro intestazione in base ai requisisti prestazionali richiesti;
- ogni valore del campo DSCP corrisponde ad una classe di servizio e tutti i pacchetti aventi lo
stesso campo DSCP riceveranno lo stesso trattamento all’interno della rete;
- i pacchetti, una volta classificati, vengono immessi nella rete;
- all’interno della rete in ogni router vengono definiti i PHB 3 ( Per Hop Behaviour) ovvero i
comportamenti corrispondenti alle classi di servizio con le quali sono classificati i pacchetti;
- quando un pacchetto arriva in un Core Router 4 , quest’ultimo esamina il campo DSCP e tratterà il
pacchetto in base alla classe di servizio corrispondente.
Si osservi inoltre che DiffServ specifica solo il campo DSCP, e dunque le classi di servizio, e i
PHBs dei routers mentre spetta all’operatore decidere quali particolari prestazioni far corrispondere
alla singola coppia DSCP-PHB; inoltre DiffServ non specifica dei servizi: il servizio percepito
dall’utente è semplicemente il risultato dei vari PHB. Come per la tecnologia IntServ, un utente che
vuole ricevere un servizio differenziato si deve accordare con il Service Provider stipulando un
SLA.
2
Edge Router: sono i router ai bordi di un dominio DS. Essi svolgono le funzioni fondamentali che prevede
l’architettura DiffServ quali la classificazione dei pacchetti, la marcatura del campo DSCP e la policing-shaping del
traffico.
3
Per Hop Behaviour ( PHB ): una descrizione del modo di instradare un particolare aggregato da parte di un router DS,
così come lo si vede esternamente; è definito dai parametri dell’algoritmo di scheduling, dalla quota di buffer e dalla
quota di banda che di fatto consentono di ottenere un diverso servizio
4
Core Router: sono router ad altissima capacità all’interno del dominio DS. Essi hanno il solo compito di eseguire i
PHB sui datagrammi già classificati e marcati dagli edge-router
http:// www.fub.it
1.1 Il campo DSCP
Il campo DSCP è composto di sei bit ed è usato per identificare i flussi appartenenti ad un aggregato
e associarli ad un PHB, deriva dal campo TOS ( Type Of Service ) introdotto già da tempo in IPv4.
Figura 1: Campo DSCP ottenuto dalla ridefinizione del campo TOS
Come si vede dalla figura il campo TOS è stato ridefinito dal IETF appositamente per DiffServ: i
sei bit più significativi sono stati definiti DSCP mentre gli ultimi due rappresentano il campo CU
che per ora non viene utilizzato e che si raccomanda di non utilizzare in nessuna implementazione.
1.2 PHB: Per-Hop Behaviour
Nell’architettura DiffServ abbiamo, oltre al Best Effort, due classi di servizio:
Figura 2: Classi di Servizio nella metodologia DiffServ
http:// www.fub.it
1- Expedited Forwarding:
Il PHB Expedited Forwarding permette di offrire le
prestazioni di una linea dedicata virtuale, caratterizzata da:
•
•
•
•
basse perdite;
basse latenze;
basso jitter;
garanzia di larghezza di banda.
Il concetto su cui si basa l’implementazione di questo PHB è la seguente: gli eventi che
introducono variabilità nelle caratteristiche dette sopra si collocano nelle code dei router e
sono causati dalla differenza tra la velocità di trasmissione del flusso aggregato in entrata e
quella riservata a quella determinata coda in uscita. Per l’Expedited Forwarding deve essere
sempre garantita l’assenza di congestione della coda associata ad esso e tale garanzia deve
essere salvaguardata indipendentemente dall'intensità del resto del traffico appartenente ad
altri PHB: le varie classi di servizio non si devono influenzare tra loro. Un modo per
implementare questo PHB consiste nel predisporre una coda con priorità superiore: per
evitare interferenze (pre-emptions) non dovrebbero essere tuttavia presenti altre code a
priorità superiore.
2-Assured Forwarding : Il PHB Assured Forwarding rappresenta un servizio end-to-end
con caratteristiche di garanzia sul recapito del pacchetto;viene definita una certa larghezza di
banda "di profilo", ed il traffico che rientra in quella larghezza di banda viene recapitato con
alta probabilità. L’ Assured Forwarding permette di configurare diversi livelli di affidabilità
e di priorità di inoltro del traffico. Sono presenti quattro classi di servizio e per ognuna ci
sono tre differenti livelli relativi di scarto (drop); i pacchetti vengono marcati e inseriti in
una delle classi in base ai servizi sottoscritti dal cliente e in caso di congestione i nodi
scartano in base ai livelli di priorità. Questo PHB si adatta molto bene a tutte quelle
applicazioni che non hanno richieste assolute di banda ma che hanno bisogno di una priorità
maggiore del normale traffico.
http:// www.fub.it
1.3
SCHEDULING E ALGORITMI
Per implementare il DiffServ si necessita di una gestione ottimale delle code presenti nei routers e
per farlo bisogna ricorrere ad opportune procedure di scheduling. Lo Scheduling è il meccanismo
con il quale si programma in quale sequenza e modo devono essere servite le code, nel caso di
buffer multiplo, o i pacchetti, nel caso di buffer singolo. Nel Test-bed sperimentale che verrà
descritto dettagliatamente nel Capitolo 3 sono presenti due router Juniper provvisti di quattro code
e quindi gli algoritmi che più interessano sono quelli a buffer multiplo.
Figura 3: Struttura di un router a buffer multiplo con queuing e scheduling
La maggior parte degli algoritmi a buffer multiplo sono basati sulla tecnica Round-Robin perchè è
la più adatta quando si vogliono isolare più flussi. Il funzionamento del Round-Robin è il seguente:
lo scheduler scorre tutte le code ciclicamente e se quella che sta analizzando non è vuota spedisce il
primo pacchetto presente, altrimenti passa alla coda successiva. Questo algoritmo dipende dalla
lunghezza media dei pacchetti presenti nelle code e non dalla lunghezza effettiva. Per ovviare
questo problema viene introdotto il cosiddetto quantum che rappresenta numero di byte che lo
scheduler può spedire da ogni coda in un determinato istante.
L’algoritmo che utilizza il quantum viene detto Deficit Round-Robin ( DRR ) e funziona nel modo
seguente: prima di servire la coda lo scheduler confronta la grandezza del pacchetto con il valore
del quantum; se il pacchetto è maggiore del quantum non viene spedito e il quantum incrementa
altrimenti il pacchetto viene spedito e il quantum decrementato al valore della grandezza del
pacchetto spedito.
http:// www.fub.it
WRR: Weighted Round Robin
Questa tecnica, che poi è quella implementata nei router Juniper utilizzati, prende in considerazione
il peso di ogni classe di servizio: i pesi determinano il numero massimo di ottetti che possono uscire
da una coda nello stesso turno. In questo modo ad ogni coda viene riservata una percentuale di
banda differente e quindi le code a più alta priorità verranno servite più spesso rispetto a quelle con
più bassa priorità: è come se nel DRR ci fossero valori di quantum diversi per ogni coda.
Priority queuing
Il concetto di base di questo algoritmo è di assegnare ad ogni classe di servizio un numero che
rappresenta la sua priorità. La classe con priorità più alta sarà servita ad ogni giro dello scheduler e,
finché questa avrà pacchetti da servire, essi saranno spediti. Non appena la coda si svuota lo
scheduler passa a servire i pacchetti di quella successiva, finché anche questi non terminano e cosi
via. Quando un pacchetto arriva nella coda con priorità minore, questa viene servita non appena lo
scheduler finisce di spedire i pacchetti del servizio corrente. Il difetto di questo algoritmo è che le
classi con priorità minore possono cadere in starvation, e cioè non vengono servite per molto tempo
in presenza di un flusso continuo di pacchetti appartenenti a classi a priorità maggiore. Una
soluzione a tale problema è il quantum, come per il WRR, che limita il numero di ottetti che
possono essere spediti consecutivamente da una stessa coda.
Controllo della Congestione
Il controllo della congestione delle code interne ai router è molto importante per ottimizzare le
prestazioni di rete. Come visto precedentemente il tempo di ritardo dei pacchetti (one-way delay), è
costituito dalla somma di tre fattori di cui solo uno è altamente variabile: il tempo di accodamento.
Inizialmente è stata utilizzata la tecnica F.I.F.O. ( First In First Out): se il ritmo di entrata dei
pacchetti è maggiore di quello di uscita, questi vengono memorizzati e quando la coda si riempie
vengono scartati. Questa tecnica è molto semplice ma ha degli svantaggi che la rendono inefficiente
nelle reti multiservizio:
http:// www.fub.it
-
se le code sono troppo piene i ritardi dei pacchetti aumentano notevolmente;
-
ci possono essere problemi di sincronizzazione in quanto i pacchetti scartati sono
spesso consecutivi;
-
le sorgenti a ritmo variabile, che in alcuni momenti raggiungono picchi alti di traffico,
sono penalizzate rispetto alle sorgenti a ritmo costante.
Di seguito vengono descritti i principali algoritmi oggi utilizzati nei router per il controllo ottimale
della congestione delle code.
R.E.D. ( Random Early Discard ): I router in cui è implementato questo algoritmo scartano uno o
più pacchetti prima che la coda si sia completamente riempita. Ogni volta che un pacchetto arriva,
l’algoritmo RED calcola la lunghezza media della coda, avg , e il router può assumere tre
comportamenti:
- se tale lunghezza è inferiore ad una soglia minima, la coda viene considerata non congestionata e
il router memorizza i pacchetti;
- se la lunghezza media è maggiore della soglia massima, la coda è considerata congestionata e il
router scarta i pacchetti con probabilità del 100%;
- se la lunghezza media si trova tra la soglia minima e massima, l’algoritmo calcola la probabilità
di scarto dei pacchetti in base alla congestione della coda.
Figura 4: Probabilità di scarto dei pacchetti al variare della lunghezza media della coda.
http:// www.fub.it
Come si vede in figura, all’aumentare della congestione della coda, indicata dal parametro avg,
viene scartato un numero sempre maggiore di pacchetti fino ad arrivare alla soglia massima thmax
dopo la quale tutti i pacchetti entranti vengono scartati.
Usando lo scarto probabilistico si evita la cancellazione di pacchetti consecutivi e la probabilità di
cancellazione non è casuale ma calcolata sulla base del numero di pacchetti del flusso di
appartenenza presenti nella coda.
Lo svantaggio di questo algoritmo è che funziona male nel caso in cui i flussi che congestionano la
coda siano “non-responsive” : se infatti si è in presenza di multimedia non adattativi, ovvero se le
sorgenti non possono abbassare le velocità di emissione, la coda rimarrà sempre congestionata e i
pacchetti verranno continuamente scartati.
Weighted R.E.D.: Questo algoritmo è una evoluzione del RED appena visto ed è stato proposto
originariamente dal CISCO. Rispetto al precedente vengono usati differenti parametri per i vari
flussi entranti: in questo modo, infatti, è possibile differenziare la distribuzione dei pacchetti persi.
Questa soluzione può non essere però conforme al modello DiffServ, infatti con il WRED i router
devono memorizzare i parametri delle code per ogni singolo flusso e questo comporta problemi di
scalabilità, tipici delle architetture ATM per le quali è stato realizzato questo algoritmo.
Figura 5: Andamento della funzione di probabilità di cancellazione nel WRED
http:// www.fub.it
RED with IN and OUT ( RIO ): Questo algoritmo è tra i primi che supportano i servizi
differenziati. Inizialmente RIO supportava due livelli di precedenza (In e Out), ma in seguito, è
stato modificato per essere in grado supportarne di più. Le differenza rispetto alle altre metodologie
riguarda soprattutto la grandezza media delle code. A differenza del WRED, RIO calcola questo
valore per ogni livello di precedenza, ovvero il valore avgn viene aggiornato ogni volta che arriva
nella coda un pacchetto con precedenza n. In questo modo è possibile isolare le probabilità di
eliminazione per ogni livello di precedenza. Per esempio per cancellare un pacchetto di bassa
precedenza deve verificarsi un eccesso di pacchetti con lo stesso livello, invece per eliminarne uno
con alta precedenza, basta che si verifichi un eccesso generale di pacchetti.
Per potenziare l’algoritmo RIO è previsto l’uso di differenti parametri (pmax, thmin e thmax) per ogni
livello di precedenza, come per il WRED. In questo modo, potrebbero essere usate soglie meno
rigide, per far sì che la grandezza media delle code per i pacchetti con alta priorità possa aumentare
più rapidamente rispetto al WRED o al RED, rendendo così questo sistema applicabile nella rete.
1.4
Coesistenza IntServ , DiffServ
Il modello DiffServ nasce per far fronte ai problemi di scalabilità di IntServ e si basa su un concetto
completamente diverso dal suo predecessore. Nel IntServ l’applicazione che richiede una certa QoS
deve generare un’informazione di controllo ( tramite protocollo RSVP ) per avvertire tutti i router
coinvolti nel cammino origine-destinazione di trattare il suo flusso informativo in un determinato
modo. Perchè la rete possa garantire le prestazioni richieste, ogni router deve mantenere delle
opportune informazioni di stato ( ad esempio la banda e il buffer da riservare a un certo flusso
informativo) che vengono aggiornate durante la connessione. Nella metodologia IntServ la gestione
della QoS è su base flusso e ogni router deve avere informazioni di stato per tutti i flussi che lo
attraversano, in quella DiffServ invece viene meno la necessità di memorizzare le informazioni di
stato del singolo flusso in quanto non vi è più riservazione delle risorse, infatti vengono definiti dei
PHB. Quindi se per IntServ si hanno garanzie maggiori delle prestazioni ma problemi di scalabilità
legati al numero di flussi da gestire, il DiffServ risulta invece essere una architettura molto meno
complessa ma tuttavia manca della capacità di “isolare” le singole richieste di QoS.
http:// www.fub.it
Anche se queste tecnologie sono state definite separatamente, non è detto che debbano essere
utilizzate in modo esclusivo. IntServ è efficiente nelle piccole reti, come ad esempio le LAN, dove i
flussi da gestire sono pochi e non si hanno problemi di scalabilità; DiffServ al contrario consente la
gestione della QoS per grossi aggregati di traffico e può quindi essere implementato su reti trasporto
metropolitane o backbone. Uno scenario futuro di rete multiservizio con gestione della QoS
potrebbe essere il seguente:
Figura 6: Architettura di rete con metodogie DiffServ e IntServ
2 DIFFSERV OVER MPLS
Le condizioni da soddisfare per la QoS si possono riassumere come segue:
•
È necessaria l’allocazione garantita di una certa misura di risorse trasmissive in tutto il
percorso effettuato dai dati dell’applicazione di interesse. Questa condizione di tipo end-toend non deve venire meno neanche in situazioni di congestione o malfunzionamento di nodi
della rete.E’ necessaria inoltre la funzione di Admission Control;
•
Il flusso dati dell’applicazione deve sperimentare nei nodi della rete un trattamento
specifico, scelto tra diverse possibili classi di servizio, che rispetti determinati vincoli sulla
perdita di pacchetti e sui ritardi nelle code.
http:// www.fub.it
La metodologia DiffServ rappresenta un primo reale passo avanti per l’implementazione e gestione
della QoS nelle reti fisse ma è anche da considerarsi incompleta in quanto non offre le garanzie
quantitative end-to-end richieste dal primo dei due requisiti. MPLS (Multiprotocol Label Switching)
è una architettura di rete emersa negli ultimi anni e spesso viene erroneamente citata come
architettura per la qualità del servizio; in realtà essa non fornisce di per sé alcun meccanismo per la
gestione della QoS. Ciò che MPLS offre è la possibilità di lavorare in un ambiente connection
oriented, nel quale è possibile riservare risorse ed utilizzare in modo efficiente la rete mediante
applicazioni di traffic engineering. MPLS è quindi un’architettura che può fornire il supporto per
una completa gestione end-to-end della QoS.
2.1
L’architettura MPLS
Un dominio MPLS è costituito da una serie di nodi contigui che supportano la tecnologia
Multiprotocol Label Switching, detti LSR (Label Switching Router). In questo scenario sono di
particolare importanza i nodi al confine del dominio, che nella terminologia MPLS vengono
chiamati LER (Label Edge Router). Essi rappresentano l’interfaccia del dominio MPLS con il resto
della rete, quindi devono implementare sia l’algoritmo di forwarding label switching sia quello
tradizionale IP. Un altro loro compito è quello di assegnare le label al traffico in ingresso. Un
percorso effettuato dai pacchetti instradati tramite label switching all’interno del dominio MPLS
prende il nome di LSP (Label Switched Path). Da un punto di vista funzionale, l’architettura MPLS
può essere divisa (come del resto anche l’architettura tradizionale IP) in componente di forwarding
e componente di controllo. La componente di forwarding consiste nella procedura mediante la quale
in un nodo si estraggono dai pacchetti le informazioni per identificare l’appropriato next hop nella
forwarding table. Un LER esegue il mapping del traffico in classi di equivalenza per il forwarding
(FEC), ossia in gruppi di pacchetti che devono essere tutti inoltrati nella stessa maniera. Di seguito
associa l’etichetta ai pacchetti in base alla loro FEC di appartenenza. All’interno del dominio
MPLS, ogni LSR ha una tabella di forwarding nella quale ad un determinato label corrisponde un
next hop. L’indirizzo di destinazione finale dei pacchetti non è più preso in considerazione nelle
decisioni riguardo al loro inoltro. Un parametro importante per la componente di forwarding è la
http:// www.fub.it
granularità con cui i flussi in ingresso al dominio MPLS vengono associati nelle FEC. In linea
teorica sarebbe possibile associare una diversa etichetta ad ogni singolo flusso, ma questo
comporterebbe i medesimi problemi dell’architettura IntServ. Il pregio di MPLS da questo punto di
vista è la possibilità di selezionare arbitrariamente i criteri per l’aggregazione di più flussi in classi
di equivalenza per il forwarding.
Dal momento che solo alcuni protocolli di livello 3 (ATM, Frame Relay) supportano la presenza di
un label, si è deciso di creare in ambito MPLS un header di 32 bit da inserire tra quello di livello 2 e
quello di livello 3, detto shim header. Tutti i protocolli di livello 3 che non prevedono la presenza di
una label (tra i quali rientra IP) possono fare uso dello shim header per trasportare le informazioni
per il label switching.
Figura 7: Shim Header MPLS
Il campo di 20 bit Label è l’etichetta vera e propria. Il campo Exp, di tre bit, è stato riservato ad uso
sperimentale ed è spesso utilizzato per il supporto della QoS in ambito MPLS.
La componente di controllo nell’architettura MPLS consiste nelle procedure utilizzate per
scambiare informazioni di routing tra gli LSR e per convertire tali informazioni in una tabella di
forwarding. Come la componente di controllo dell’architettura tradizionale IP, anche quella di
MPLS include dei protocolli di routing come ad esempio OSPF ( Open Shortest Path First ). Per la
creazione delle tabelle di forwarding sono però necessarie in un LSR ulteriori funzionalità oltre ai
protocolli di routing. Un LSR, infatti, deve essere in grado di creare associazioni (bindings) tra
label e FEC, informare gli altri LSR dei bindings ed aggiornare le tabelle di forwarding in base ai
bindings creati localmente e a quelli di cui viene informato dagli altri LSR. I protocolli di routing
consentono di effettuare il passaggio da FEC a next hop; le procedure di creazione e distribuzione
dei bindings portano alla conversione da FEC a label. Complessivamente si ottiene la relazione tra
label e next hop necessaria per la creazione delle tabelle di forwarding,
http:// www.fub.it
Figura 8: Procedura per la creazione della Forwarding Table
La distribuzione delle label bindings tra gli LSR viene affidata preferibilmente a protocolli
tradizionali come RSVP ma può anche essere demandata ad un apposito protocollo detto LDP
(Label Distribution Protocol).
2.2
MPLS e ingegneria del traffico
L’architettura MPLS è nata per aumentare le prestazioni dei nodi della rete, introducendo per il
forwarding un campo di dimensione fissa che consentisse un processing più rapido dei pacchetti.
Tuttavia questo tipo di necessità è progressivamente venuto meno in conseguenza delle continue
innovazioni tecnologiche che hanno portato a router sempre più veloci. Il vero vantaggio di MPLS,
che non rientrava tra i suoi scopi originari, è quello di consentire ai Service Provider di
implementare il TE (traffic engineering) nelle reti, aumentandone l’efficienza e le prestazioni. Il TE
permette di bilanciare il traffico in una rete in modo da non avere link congestionati né scarsamente
utilizzati, cosa che porta ad un pieno sfruttamento della rete, con il conseguente guadagno per i
provider che possono servire più utenza a parità di risorse. Inoltre il TE consente l’allocazione delle
risorse trasmissive per un aggregato di flussi, rendendo possibile lo sviluppo di meccanismi di QoS
end-to-end.
http:// www.fub.it
Figura 9: Rete MPLS
Lo sviluppo del TE ha importanti implicazioni per le procedure di routing. Nell’architettura IP
tradizionale la selezione del percorso per l’instradamento del traffico viene effettuata minimizzando
una determinata metrica, rappresentata ad esempio dal numero di nodi attraversati o dalla somma di
termini di costo assegnati staticamente ai link. La conseguenza di ciò è uno sbilanciamento del
traffico che viene instradato per la maggior parte su percorsi preferenziali risultando spesso soggetti
a congestione. In questo contesto poco flessibile mancano le premesse per poter sviluppare il TE.
MPLS supera i limiti dell’architettura tradizionale supportando un nuovo tipo di routing, detto
Constraint-based Routing (CR). L’idea alla base di questa innovazione sta nel fatto che per avere
un routing efficiente bisogna instradare il traffico lungo percorsi a costo minimo, rispettando
contemporaneamente determinati vincoli (constraints) sullo sfruttamento delle risorse di rete. Per
poter effettuare il CR sono necessarie funzionalità aggiuntive nella rete, tra le quali la presenza di
protocolli di routing opportunamente estesi (come ad esempio OSPF-TE o ISIS-TE) per portare le
informazioni relative al TE. Servono poi algoritmi per il calcolo dei percorsi che rispettino i vincoli,
ed un protocollo per l’allocazione delle risorse esteso per il TE; il più famoso è senz’altro RSVP-TE
(ReSerVation Protocol with Tunneling Extension), che è molto utilizzato per la distribuzione dei
label nelle reti che implementano il traffic engineering e la QoS.
http:// www.fub.it
2.3
Implementazione della QoS DiffServ su MPLS
L ‘architettura MPLS grazie ai protocolli di routing estesi per fornire TE può offrire un ambiente
connection-oriented, necessario per l’implementazione della QoS, garantendo risorse trasmissive ad
aggregati di traffico ma non discriminando i pacchetti nel trattamento ad essi riservato nei nodi.
L’architettura DiffServ, invece, permette la classificazione dei pacchetti in BA e il loro trattamento
diversificato rappresentato dai PHB. L’integrazione delle due architetture porta quindi allo sviluppo
di una meccanismo per gestire in modo completo la QoS.
Affinché MPLS possa supportare DiffServ, è necessario che gli LSR riescano a distinguere i vari
pacchetti in base al loro DSCP per inoltrarli secondo il PHB corrispondente. Sorge allora un
problema in quanto gli LSR si basano esclusivamente sulla label dello shim header MPLS per il
forwarding dei pacchetti, e non esaminano l’header IP. Le soluzioni che sono state proposte sono
due:
- E-LSP ( Experimental bit inferred LSP ) : Viene utilizzato il campo EXP dello shim header
come sostituto del campo DSCP per portare l’informazione sul DSCP all’interno del dominio
MPLS. L’inconveniente di questo approccio consiste nella dimensione del campo EXP, di soli tre
bit contro i sei del campo DSCP: in questo modo si possono supportare al massimo otto diversi
DSCP e quindi otto diversi PHB. Nel caso di una rete nella quale siano effettivamente implementati
o richiesti al massimo otto PHB, le funzioni DiffServ possono essere esplicate semplicemente
leggendo negli LSR il valore del campo Exp ed assegnando di conseguenza i pacchetti al corretto
BA. Questo metodo ha il pregio di essere semplice e non richiedere alcuna segnalazione di controllo
aggiuntiva.
Figura 10: I bit del campo TOS o i primi 3 bit del campo DSCP sono copiati nel campo Exp ai bordi della rete.
http:// www.fub.it
- L-LSP ( Label inferred LSP ) : La seconda soluzione proposta è utile qualora si debbano
trattare più di otto PHB. In tal caso il campo Exp non è più sufficiente, e lo shim header necessita di
essere in qualche modo rivisitato per consentire il trasporto dell’informazione sul DSCP. Si è deciso
di incrementare il significato del campo label, che deve indicare sia l’appartenenza ad una certa
FEC che l’appartenenza ad un certo BA; il campo Exp viene in questo caso utilizzato per esprimere
il valore della drop precedence, in modo da trattare i pacchetti secondo l’opportuno PHB. Parlando
ad esempio della categoria di PHB AF, nella label si troverebbe l’informazione sullo scheduling e
quindi riguardo alla coda sulla quale instradare il pacchetto; nel campo Exp si troverebbe il valore
(tra i tre possibili per ogni classe di scheduling di AF) della drop precedence.
Figura 11: Il PHB è indicato dal valore della label mentre la drop precedence dal valore del campo Exp.
E’ necessario far confluire i pacchetti del medesimo BA in un L-LSP comune, poiché sono destinati
tutti alla stessa coda: un L-LSP può trasportare una sola classe di servizio. Questo modo di
procedere consente di avere quanti PHB si vogliano, a spese di una complicazione nella
componente di controllo MPLS. Infatti è necessario estendere i protocolli per la distribuzione dei
binding tra label e FEC, che adesso devono includere anche il binding tra label e PHB. La
distribuzione deve essere effettuata al momento della creazione di un L-LSP.
Le due alternative per gli LSP con supporto di DiffServ non sono mutuamente esclusive e possono
coesistere non solo a livello di dominio MPLS ma anche a livello di un singolo link.
http:// www.fub.it

DiffServ over MPLS - Fondazione Ugo Bordoni

Transcript

Documenti analoghi

Il computer nella vita quotidiana La comunicazione in Rete

cisco mpls cef ldp router id traffic eng reoptimize tag switching

Dario Di Zenobio (FUB)

la rete metropolitana MPLS avviata dall`Università del Salento

interferenze tra segnale TV e reti di telefonia

last minute giugno 14-15-16 - Fonte del Benessere Resort

software - Maurizio Gambino.it

Massimiliano Sbaraglia Network Engineer

forniture di beni e servizi informatici del settore ICT e IOT. (http://ted