RSVP e MPLS: Analisi e Sperimentazione

di Protocolli per Applicazioni Avanzate in

Rete Geograca
Alessandro Canzian
18 Marzo 1998
2
Indice

Introduzione 7
1 Dati e Servizi 11
1.1 Il traco dei dati . . . . . . . . . . . . . . . . . . . . . . 11
1.2 I servizi di Internet . . . . . . . . . . . . . . . . . . . . . 13
1.3 Qualita o Equita . . . . . . . . . . . . . . . . . . . . . . 15
1.4 QoS e CoS . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.5 Routing e Switching . . . . . . . . . . . . . . . . . . . . 18
2 ReSerVation Protocol 19
2.1 Elementi del protocollo RSVP . . . . . . . . . . . . . . . 20
2.1.1 Architettura . . . . . . . . . . . . . . . . . . . . . 20
2.1.2 Flusso dei dati . . . . . . . . . . . . . . . . . . . 21
2.1.3 Meccanismo di prenotazione . . . . . . . . . . . . 22
2.1.4 Stili di prenotazione . . . . . . . . . . . . . . . . 23
2.1.5 Sessione RSVP . . . . . . . . . . . . . . . . . . . 26
2.2 Merging delle prenotazioni . . . . . . . . . . . . . . . . . 28
2.3 Soft state . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4 Formato dei messaggi RSVP . . . . . . . . . . . . . . . . 31
2.4.1 Messaggi di percorso . . . . . . . . . . . . . . . . 32
2.4.2 Messaggi di prenotazione . . . . . . . . . . . . . . 34
2.4.3 Messaggi di errore e di conferma . . . . . . . . . . 34
2.4.4 Messaggi di rilascio della prenotazione . . . . . . 36
2.5 Interoperabilita . . . . . . . . . . . . . . . . . . . . . . . 36

3
4

3 Test di RSVP 39
3.1 Finalita del test . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 Descrizione della rete di test . . . . . . . . . . . . . . . . 40
3.3 Congurazione degli apparati . . . . . . . . . . . . . . . 41
3.4 Verica del funzionamento . . . . . . . . . . . . . . . . . 42
3.5 Prestazioni . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.5.1 Flussi riservati vs ussi Best-Eort UDP . . . . . 45
3.5.2 Flusso riservato vs usso Best-Eort TCP . . . . 49
3.6 Scalabilita di RSVP . . . . . . . . . . . . . . . . . . . . . 50
3.6.1 Verica del comportamento . . . . . . . . . . . . 51
3.6.2 Cause . . . . . . . . . . . . . . . . . . . . . . . . 53
3.7 Prove di funzionalita del multicast . . . . . . . . . . . . . 54
3.7.1 Sessioni Multicast . . . . . . . . . . . . . . . . . . 54
3.8 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . 58
4 Multiprotocol Label Switching 61
4.1 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.1.1 Forwarding . . . . . . . . . . . . . . . . . . . . . 64
4.1.2 Elementi di controllo . . . . . . . . . . . . . . . . 65
4.1.3 Supporto alla Qualita di Servizio . . . . . . . . . 66
4.2 Impiego di Tag Switching con ATM . . . . . . . . . . . . 68
4.3 Gestione del traco . . . . . . . . . . . . . . . . . . . . . 69
5 Realizzazione di una rete basata su Tag Switching 71
5.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2 Struttura della rete . . . . . . . . . . . . . . . . . . . . . 72
5.3 Congurazione della rete . . . . . . . . . . . . . . . . . . 75
5.4 Veriche di funzionamento . . . . . . . . . . . . . . . . . 77
5.4.1 Connettivita della rete . . . . . . . . . . . . . . . 77
5.4.2 Funzionalita . . . . . . . . . . . . . . . . . . . . . 77
5.4.3 Round Trip Time e Route Recovery Time . . . . 79
5.5 Misura delle prestazioni . . . . . . . . . . . . . . . . . . 81
5.5.1 Prestazioni di ussi TCP con e senza
Tag Switching . . . . . . . . . . . . . . . . . . . . 81
Introduzione 5

5.5.2 Prestazioni di ussi UDP con e senza

Tag Switching . . . . . . . . . . . . . . . . . . . . 90
5.6 Funzionamento del Trac Engineering . . . . . . . . . . 93
5.7 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . 96
Conclusioni 99
A Lista degli acronimi 105
B Congurazione dei dispositivi 107
B.1 Switch LS 1010 . . . . . . . . . . . . . . . . . . . . . . . 107
B.2 Router 7505 . . . . . . . . . . . . . . . . . . . . . . . . . 116
Bibliograa a
6 Introduzione
Introduzione

Nel panorama dei protocolli di rete TCP/IP occupa un ruolo domi-

nante. La rete Internet e diventata parte della cultura popolare ed i
computer interconnessi con TCP/IP giocano oggi un ruolo chiave nel
campo della ricerca, dell'industria, ma anche in quello delle attivita
commerciali, dei servizi e dell'intrattenimento.
La crescita continua del numero di utenti, fra l'altro, costituisce il
migliore stimolo per lo sviluppo di nuove applicazioni, alcune originali,
altre meno, comunque sempre piu esigenti nelle richieste di prestazioni
dalla rete.
Questo fenomeno, forse inatteso, certamente sottostimato, ha decre-
tato su scala mondiale il successo dell'Internet Protocol, ma al tempo
stesso ha messo in evidenza i suoi limiti. Da un lato la crescita del nu-
mero di computer collegati ha portato all'esaurimento dello spazio di
indirizzi e all'esplosione delle dimensioni delle tabelle di instradamen-
to. Dall'altro, sul piano delle applicazioni, e il protocollo di trasporto
che si rivela inadeguato. Infatti Internet ore un servizio di consegna
dei dati di tipo best-eort, i pacchetti spediti vengono inoltrati non
appena le risorse sono disponibili, ma non esiste nessuna garanzia sui
tempi di consegna. Questo servizio e eciente per un grande numero
di applicazioni, ma per molte altre e del tutto insuciente.
Per orire un supporto adeguato alle audio e videoconferenze e piu
in generale a tutte le applicazioni in tempo reale si e reso necessario
arricchire TCP con degli strumenti che ne aiutano la gestione, come
il Real Time Control Protocol (RTCP) o che permettono di riservare
delle risorse di rete da utilizzare in modo esclusivo, come il resource
ReSerVation set-up Protocol (RSVP).

7
8 Introduzione

Far fronte alle esigenze sempre crescenti di qualita di servizio signi-

ca sviluppare la rete nella direzione delle necessita delle applicazioni,
ma signica anche dare una ulteriore spinta allo sviluppo delle appli-
cazioni stesse, che trovano risposte concrete alle necessita di real time
delivery. Le sde aperte dall'uso delle telecomunicazioni come potente
strumento di sviluppo nelle altre discipline (il telelavoro, la telemedici-
na, l'insegnamento a distanza e molte altre ancora) vedono nei servizi
a valore aggiunto la concreta possibilita di essere realizzate.
L'intento dei progettisti di Internet e quello di riuscire in breve
tempo a garantire qualita di servizio (QoS) alle applicazioni con tec-
niche che possano essere utilizzate in sistemi di grandi e grandissime
dimensioni.
Uno stimolo ulteriore alla evoluzione della rete viene dall' amplia-
mento di banda a disposizione. Per esempio l'Asinchronous Transfert
Mode (ATM), che ore prestazioni sempre piu elevate sia in termini di
velocita che di tasso di perdita.
Il nodo cruciale che l'Internet Engineering Task Force (IETF) ha
dovuto arontare e stato coniugare le esigenze di servizio dierenziato
di vari tipi di utenti o di gruppi di utenti, con la necessita di creare
delle classi di ussi con le medesime esigenze di servizio, per ridurre
la complessita dei sistemi di segnalazione. Da un lato le applicazioni
gradirebbero un trattamento personalizzato della sessione end-to-end
fra duo o piu host, per usufruire di un servizio che dinamicamente si
adatta ai loro bisogni e ottimizza l'utilizzo delle risorse di trasmissio-
ne. Dall'altro, un router di backbone che gestisce migliaia di sessio-
ni contemporaneamente, deve necessariamente usare delle tecniche di
aggregazione dei ussi di dati per operare in maniera eciente.
A questo proposito una delle proposte piu interessanti e il Multi-
Protocol Label Switching (MPLS). Esso abbina le funzionalita di IP
alla velocita tipica della commutazione. In questo modo rende piu ef-
ciente l'instradamento e permette agevolmente di suddividere i ussi
di dati in classi, che in seguito potranno subire trattamenti dierenziati.

Gli obiettivi di questa tesi sono principalmente due:

Introduzione 9

descrivere le proposte di IETF per quel che riguarda la QoS:il

protocollo RSVP per la prenotazione di risorse di rete e i proto-
colli di tipo MPLS per eettuare l'instradamento dei pacchetti in
maniera eciente
eseguire dei test sia per vericare il funzionamento del protocollo
di prenotazione RSVP, che della tecnica di instradamento di tipo
label switching.

Il carattere sperimentale che la tesi assume ha permesso di acqui-

sire familiarita con le tecniche di congurazione degli apparati e di
approfondire l'analisi delle implementazioni di tali protocolli.
RSVP ha dimostrato di essere un metodo di segnalazione eciente
che consente di realizzare la prenotazione delle risorse di rete in ambito
locale e anche geograco. RSVP presenta dei limiti teorici di appli-
cabilita in reti di scala geograca che solo in parte e stato possibile
vericare sperimentalmente a causa del limitato numero di sessioni che
le macchine a nostra disposizione riescono a generare.
La tecnica di instradamento Label Switching ha confermato nei test
quello che prometteva nelle speciche, ovvero di essere un sistema molto
semplice e lineare di instradamento dei pacchetti di dati nella rete. Il
\banco di prova" che si e realizzato ha mostrato la piena funzionalita
delle principali caratteristiche di MPLS, anche se le dimensioni della
rete e il traco che abbiamo generato, pur essendo consistenti, non
sono quelli di un collegamento di backbone.
Comunque sia, la misura delle prestazioni permette di eettuare
delle prime valutazioni di merito sulle implementazioni prese in esame,
che inserite in contesti piu ampi, costituiscono motivo di discussione
sulla opportunita di certe scelte sistemistiche.

Le fasi di sviluppo e ricerca di questa tesi si sono svolte presso il

CNAF, che e il Centro Nazionale per la ricerca e lo sviluppo nelle tec-
nologie informatiche e telematiche per le Applicazioni nel settore della
Fisica, di Bologna. E l'ente che gestisce la rete dell'Istituto Nazionale di
10 Introduzione

Fisica Nucleare (INFNet) e partecipa alla pianicazione della rete del-

la ricerca italiana. Attualmente e coinvolto nel progetto di una nuova
rete per la ricerca in Italia (GARR-B). Il CNAF ha messo a disposizio-
ne tutte le macchine necessarie per l'esecuzione dei test, oltre che alla
fondamentale partecipazione dei suoi ricercatori.

Sommario
In una prima parte la tesi aronta le questioni rigardanti i servizi oerti
da Internet e la loro integrazione nella rete. Poi segue una descrizione
del protocollo RSVP di cui vengono messe in evidenza le caratteristi-
che principali ed il funzionamento. Una terza sezione e dedicata alla
verica sperimentale del protocollo RSVP: su di un collegamento ATM
con Zurigo e stato possibile controllare il funzionamento ed eettuare
misure di prestazioni su ussi prenotati e/o best-eort.
Il quarto capitolo e dedicato alla descrizione del protocollo di label swi-
tching MPLS, in particolare si e entrati nel dettaglio del Tag Switching,
che e una particolare implementazione CISCO di questa tecnica in via
di standardizzazione. Nel quinto capitolo viene descritta la realizza-
zione ed il test di una rete basata su tag switching che ha collegato
il CNAF di Bologna con altri 5 nodi dislocati in Francia, Svizzera,
Austria, Germania e Spagna.
Capitolo 1
Dati e Servizi

1.1 Il traco dei dati

I dati scambiati dalle applicazioni sulle reti di telcomunicazioni possono
essere classicati in base alle loro caratteristiche, come si puo vedere
nello schema della gura 1.1 .
Una prima, ma fondamentale, distinzione va fatta fra il traco in
tempo reale e quello che non lo e, che viene chiamato genericamente
traco di dati. Il traco di dati viene originato da applicazioni come
telnet, www, ftp, email ecc. Queste sono applicazioni elastiche che
attendono l'arrivo di tutti i pacchetti che sono stati trasmessi. Se si
vericano dei lunghi ritardi la prestazione diminuisce, ma il risultato
complessivo della trasmissione non viene compromesso. Una ulteriore
distinzione deve essere fatta fra applicazioni interattive, che richiedono
ritardi contenuti, e applicazioni non interattive che tollerano bene anche
ritardi maggiori.
Le applicazioni in tempo reale invece generano un traco che non
tollera i lunghi ritardi e le sue variazioni, ma, nella migliore delle ipotesi,
riesce ad adattarsi a brevi ritardi senza pregiudicare il buon esito della
trasmissione.
Il traco dati viene generato dalle applicazioni in modo saltuario
e imprevedibile, il usso viene emesso alla massima velocita consentita
dal collegamento no al suo termine e poi puo passare molto tempo
prima che ne venga generato dell'altro. Si dice che ha caratteristiche

11
12 Dati e Servizi

Trafficio Internet

Traffico Traffico
Tempo-Reale Dati

Applicazioni rigide e Applicazioni Traffico Traffico Traffico

Burst Bulk Bulk
non tolleranti Tolleranti
interattivo interattivo Asincrono
Emulazione
di VIC,VAT Telnet, X ftp, www Email
circuito

Figura 1.1: Applicazioni e diversi tipi di traco in Internet

Bursty.
Il traco in tempo reale, invece, viene generato con una cadenza
regolare, la riproduzione di segnali audio e video si ottiene prelevando
dei campioni di dati ad intervalli costanti. Questi vengono accumulati
dentro a dei pacchetti e inviati a destinazione. Il ricevitore deve aprire
i pacchetti e riprodurre correttamente i segnali. All'interno della rete,
che e di tipo connection-less, i tempi di transito possono essere molto
diversi l'uno dall'altro. Il ricevitore quindi, per non avere distorsione del
segnale, dovra porre in un buer i pacchetti che arrivano per riprodurli
al momento opportuno. Tutti i dati che arrivano in tempo vengono
utilizzati per la ricostruzione del segnale, quelli che arrivano dopo sono
scartati, causando dei buchi nella sua riproduzione.
L'entita del ritardo massimo pero, deve essere contenuta nelle ap-
plicazioni interattive, come le conversazioni telefoniche, dove anche un
ritardo di qualche decimo di secondo diviene fastidiosamente avvertibi-
le.

Per caratterizzare un usso di dati in tempo reale si puo utilizzare

un modello detto token bucket lter. Il token bucket e determinato da
due parametri: la velocita r e la profondita b. Nel modello rappresen-
tato nella gura 1.2 il bucket viene riempito in modo continuo di token
1.2 I servizi di Internet 13

Figura 1.2: Modello di un ltro Token-Bucket

alla velocita r, al piu vi saranno b token al suo interno. Ogni volta

che viene emesso un pacchetto di dati di dimensione d altrettanti token
vengono estratti dal bucket. I pacchetti vengono inviati solo quando ci
sono sucienti token nel bucket. In questo modo si ottiene un usso di
dati parametrizzato la cui bit-rate, a lungo termine, sara proprio r e la
massima dimensione del burst e pari a b.

1.2 I servizi di Internet

Il modello di riferimento dell'Internet Protocol tradizionale ore ad ogni
pacchetto che transita sulla rete la medesima qualita di servizio. Il
gruppo di lavoro di IETF che si occupa dei Servizi Integrati di Internet
2], si propone di orire alle applicazioni la possibilita di scegliere il
servizio che meglio si adatta alle caratteristiche dei ussi di dati che
generano.
A tal ne sono stati elaborati tre modelli di consegna dei dati,
al tradizionale Best-Eort si sono aggiunti il Controlled-Load 3], e il
Guaranteed-Service 4].
14 Dati e Servizi

Servizio Best-E ort

La rete consegna i pacchetti non appena possibile, secondo una poli-
tica di gestione rst-in, rst-out (FIFO). Tutti i pacchetti ricevono il
medesimo trattamento e non esiste nessuna informazione riguardo al
ritardo con cui questo puo avvenire. Il servizio di consegna best-eort
puo essere utilizzato da tutte le applicazioni elastiche, che non vengono
inuenzate dal ritardo di consegna e dalle sue possibili variazioni.
Servizio Controlled-Load
Per le applicazioni in tempo reale che sopportano lievi ritardi e modeste
variazioni della sua durata e previsto il modello di consegna Controlled-
Load. La rete non fornisce nessuna garanzia quantitativa, ma assicu-
ra che in condizioni di sovraccarico del collegamento il servizio non e
peggiore di quello che si ha con la consegna best-eort sul link scarico.
L'utilizzatore deve comunicare l'entita del traco che deve gene-
rare con una specica di token-bucket, la rete deve assicurare che per
quel usso saranno disponibili sucienti risorse, almeno no a quando
rimarra conforme alle speciche annunciate.
Tutti i pacchetti conformi verranno consegnati con breve riterdo e
con un valore basso del tasso di perdita dei pacchetti. In modo piu spe-
cico si puo dire che il massimo ritardo di accodamento non dovrebbe
essere maggiore del tempo richiesto per smaltire un burst della massi-
ma dimensione alla velocita di trasmissione dei pacchetti richiesta. La
perdita di pacchetti totale non dovrebbe eccedere di molto la perdita
del mezzo trasmissivo, vale a dire che la perdita dovuta alla congestione
dovrebbe tendere a zero.
Servizio Garantito
Le applicazioni rigide e intolleranti, che non si adeguano a ritardi an-
che minimi di consegna, devono far riferimento al Guaranteed Quali-
ty of Service. Esso ore ai ussi che sono conformi alle speciche di
token-bucket un preciso limite al ritardo e perdita di pacchetti prati-
camente nulla. La rete non minimizza la variazione dei ritardi, sem-
1.3 Qualit
a o Equita 15

plicemente controlla il massimo ritardo di accodamento dei pacchetti.

L'applicazione puo regolare l'istante di riproduzione del segnale in modo
che tutti i pacchetti siano arrivati in tempo.
Il massimo ritardo di accodamento per un usso conforme ad un
token-bucket ( ) inviato su di una linea con banda e al piu:
r b R ,
b=R

a condizione che la banda disponibile sul collegamento sia maggiore

R

o uguale alla velocita con cui vengono generati i campioni. Se questa

r

condizione viene sempre consentita, il ritardo di accodamento e limitato

dal tempo che l'ultimo pacchetto di un burst di dimensione rimane in
b

coda per ogni tratto del collegamento. Questo viene denito modello
uido del servizio, ma nella realta ci si discosta da questa situazione
ottimale di utilizzo della banda e risulta necessario adottare dei termini
correttivi.
Per determinare il ritardo complessivo di consegna bisogna tene-
re conto anche del tempo di propagazione del segnale lungo tutto il
percorso dei dati.
L'applicazione sulla base dei termini correttivi e del tempo di la-
tenza del segnale sul collegamento ssa l'istante di riproduzione allo
scadere del massimo ritardo garantito. Nella maggior parte dei casi i
pacchetti arrivano prima del ritardo limite consentito e il ricevitore si
dovra occupare della loro memorizzazione.

1.3 Qualita o Equita

I servizi integrati di Internet orono alle applicazioni la capacita di sce-
gliere fra diversi livelli di qualita nel servizio di consegna dei pacchetti
di dati. La necessita di dierenziare i servizi nasce nel momento in
cui bisogna rispondere alle esigenze di un numero elevato di utenti che
hanno caratteristiche diverse. Per sviluppare un sistema che comples-
sivamente risponda a queste caratteristiche gli elementi indispensabili
sono essenzialmente due:
i dispositivi lungo l'intero percorso di consegna dei pacchetti di
dati devono supportare dei meccanismi di controllo della qualita
di servizio fornita
16 Dati e Servizi

le applicazioni devono avere a disposizione un protocollo per dia-

logare con gli elementi di rete e denire la QoS di cui hanno
bisogno.
Il primo punto viene assolto dai servizi di controllo della qualita
di cui si e parlato nella sezione precedente, mentre il secondo compito
spetta al Resorce ReSerVation Protocol (RSVP) 1].

La realizzazione dei Servizi Integrati di Internet e un progetto ambi-

zioso, che apre numerosi argomenti di discussione. Infatti la comunita
scientica e divisa sul comportamento che la rete dovrebbe tenere in
condizioni di sovraccarico. Alcuni pensano che alcuni ussi debbano
continuare a ottenere un buon livello del servizio, a scapito degli al-
tri, ed e quello che avviene con la prenotazione delle risorse. Altri
sono convinti che tutti i ussi dovrebbero ricevere lo stesso servizio,
degradandolo per ciascuno nella medesima misura. In questo modo il
comportamento della rete e piu fair, visto che con la prima soluzione
non a tutti i ussi e consentito di fare la prenotazione di risorse, quindi
non tutti gli utenti sono uguali per la rete. Al di la delle discussioni
di natura non specicamente sistemistica con ogni probabilita Internet
non verra risparmiata dalla commercializzazione delle sue risorse: chi
paghera avra il miglior servizio, e questo avverra comunque, con RSVP,
o con qualsiasi altra forma di dierenziazione dei servizi che potra sop-
piantarlo.

In una rete a commutazione di pacchetto i ussi di dati in tempo re-

ale sorono pesantemente le situazioni di congestione. La prenotazione
delle risorse assicura che non venga accettato piu traco di quello che
puo essere smaltito con la qualita di servizio richiesta dalle applicazio-
ni, ma questo non e l'unico approccio possibile. I problemi dovuti alla
congestione potrebbereo essere risolti adattando i ricevitori a regolare il
punto di riproduzione in accordo alle variazioni del ritardo. Le sorgenti
inoltre durante la congestione potrebbero commutare su algoritmi di
codica dei dati meno dispendiosi. Tuttavia, una banda minima deve
1.4 QoS e CoS 17

sempre essere garantita al usso dei dati, ma questo non e sempre vero
con la Internet attuale.
Inoltre opinioni autorevoli sostengono che in futuro la banda cessera
di essere un problema, perche la crescita delle richieste delle applicazio-
ni sara inferiore alle capacita che la tecnologia mettera a disposizione
delle reti. D'altro canto questa disponibilita oggi ancora non c'e, quin-
di per valutare se utilizzare la prenotazione di risorse o meno bisogna
stabilire in che termini conviene allocare una quantita di banda ade-
guata alle reali necessita, facendosi carico dell'over-head del protocollo
di gestione delle risorse , oppure sovradimensionare i collegamenti in
modo da scongiurare la congestione.

1.4 QoS e CoS

La Qualita di Servizio (QoS) e un modo per distinguere il traco sul-
la rete rispondendo a criteri specici, per esempio la percentuale di
pacchetti persi, o il ritardo di accodamento e le sue variazioni, oppure
ancora la bit-rate del usso dei dati. In questo modo l'allocazione delle
risorse puo essere adattata alle esigenze degli utenti. L'approccio alla
QoS di RSVP e molto generale, ed e quanto di meglio possa desiderare
un'applicazione, ma e molto dicile implementare questa granularita
dell'oerta dei servizi in modo scalabile. Anche l'approccio utilizzato da
ATM, che prevede l'allocazione per usso delle risorse, rende necessario
l'impiego di un protocollo di segnalazone end-to-end e di meccanismi
per specicare le caratteristiche del traco. Tutto questo comporta
costi elevati in termini di complessita.
Le Classi di Servizio (CoS) invece, permettono di orire servizi dif-
ferenziati a piu ussi in maniera aggregata, in modo da ridurre il lavoro
di elaborazione degli apparati di instradamento. Il concetto di usso e
sostituito da quello di \classe", i pacchetti provenienti da diversi ussi
vengono associati ai conni della rete e ricevono un servizio che per-
mette loro di soddisfare le richieste degli end-systems. In questo modo
la complessita degli apparati si sposta gradualmente dal nucleo (core)
verso i bordi della rete (the edge), permettendo di ottenere prestazioni
18 Dati e Servizi

migliori di quelle attuali.

1.5 Routing e Switching

L'operazione di inoltro dei dati, nel corso degli ultimi anni, e diventata
critica. Le capacita di gestire servizi a valore aggiunto e l'esigenza di
farlo per un numero crescente di utenti ha complessivamente aumentato
il carico che le risorse di elaborazione dei router devono sopportare.
Nel frattempo la velocita di commutazione dei moderni switch ad alte
prestazioni e cresciuta e questo non ha fatto che accentuare il divario
fra le prestazioni oerte dagli apparati di livello 2 ed il collo di bottiglia
costituito dallo strato di rete.
I costruttori di apparati di interconnessione hanno proposto delle
soluzioni che cercano di combinare le funzioni di routing di strato 3
e quelle di switching dello strato 2. Fra le numerose novita che un
approccio di questo tipo puo orire e interessante notare la possibilita
di gestire la qualita di servizio non per ogni pacchetto, come richiedono
gli algoritmi di Classicazione e di Scheduling di RSVP, ma orientandosi
al usso.
Il MultiProtocol Label Switching rende possibile un passo importante
nella direzione delle Classi di Servizio. Una possibilita e che la QoS
venga stabilita in modo statico denendo due classi, la premium e la
best-eort, con cui i ussi sceglieranno di essere consegnati. Questo
metodo e nettamente in antitesi al modello di prenotazione on demand
di RSVP. Allo stesso tempo e integrabile con RSVP, ne puo addirittura
sfruttare il metodo di segnalazione, e costituisce un ecace rimedio per
alcuni dei problemi di scalabilita che, come si avra modo di vedere in
seguito, limitano i suoi impieghi.