Test bed per la valutazione della Qualità del Servizio in reti ottiche ...

__________________________________________________________________
sufficienti per soddisfare la richiesta. Se in tutti i nodi presenti sul cammino questi
controlli hanno un esito positivo allora vengono allocate lungo l'intero percorso
dalla sorgente al destinatario le risorse necessarie al trasporto del flusso di dati in
questione con la QoS richiesta.
In ogni nodo i messaggi Resv provenienti dai nodi a valle e relativi allo stesso
flusso di dati vengono fusi insieme prima di essere ulteriormente propagati verso
la sorgente; se ad un nodo giungono due richieste di prenotazione da parte di due
host relative allo stesso flusso di dati, tale nodo propaga verso la sorgente di tale
flusso un'unica richiesta contenente la QoS più stringente in termini di qualità.
Figura 10: Schema semplificato dello scambio dei messaggi RSVP tra sorgenti e destinatari
Le risorse allocate in ciascun nodo e necessarie ad assicurare ad un certo flusso di
dati la QoS richiesta non vengono tenute riservate indefinitamente, dopo un certo
periodo di tempo vengono liberate. Quindi gli host sorgente e ricevente
rispettivamente devono periodicamente inviare dei messaggi Path e Resv di
“refresh” per notificare ai nodi l'intenzione di continuare a ricevere con una certa
QoS una data sessione. Il meccanismo di refresh permette inoltre al protocollo
RSVP di adattarsi in maniera dinamica ai cambiamenti dei percorsi di
instradamento seguiti dai dati.
Nel protocollo RSVP sono previsti due tipi di messaggi di errore: ResvErr e
PathErr. Il messaggio di tipo PathErr è semplicemente trasmesso verso l'host
sorgente che ha causato l'errore e non provoca alcun cambiamento nei router che
attraversa. Sono pochi i motivi che possono causare un PathErr. Ad esempio
un'applicazione potrebbe specificare nel messaggio Path parametri di traffico non
congruenti, oppure indicare nell'identificatore di sessione un numero di porta
incompatibile col valore di ProtocolID.
68