Resource Reservation Protocol: differenze tra le versioni

Versione delle 05:36, 6 feb 2008

Versione delle 16:52, 30 mar 2008

Riga 7:

Un'altra caratteristica di RSVP è quella di supportare i flussi [[multicast]] con la stessa efficacia di quella offerta ai flussi [[unicast]]. Questo protocollo fa uso di un approccio orientato ai destinatari. Piuttosto che lasciare il compito al mittente di tenere traccia di un numero di destinatari potenzialmente elevato, è più sensato che siano i destinatari a gestire le proprie necessità, come un unica persona che parla e tante che ascoltano una lezione tenuta su una rete MBone.

== Step principali ==

Il protocollo RSVP si basa su due step.

Un primo detto di ''downstream'' in cui il mittente indirizza un pacchetto PATH verso il primo router del percorso fino all'host destinatario. Nel suddetto pacchetto sono indicati il Phop, Sender_Tspec e Adspec. Il Phop è l'indirizzo del router al passo precedente, mentre Sender_Tspec e Adspec includono informazioni sulle caratteristiche richieste alla linea che si intende prenotare. Quando un router riceve il PATH, aggiorna le sue informazioni, aggiorna il timer della prenotazione ed inoltra il PATH al router successivo, dopo aver modificato il campo Phop.

Nella seconda fase, quella di ''upstream'', viene spedito a ritroso un pacchetto RESV contente i dati FlowSpec e Admission Control. Ogni router valuta i campi, aggiorna i relativi parametri, aggiorna il timer associato allo stato RESV e inoltra il pacchetto al router indicato nel Phop, fono al mittente originale.

Tra i principali side-effects del protocollo RSVP, va segnalata la scarsa scalabilità; se infatti il meccanismo è indubbiamente funzionale, nel caso di un utilizzo massiccio per grandi quantità di dati, l'overhead generato può risultato eccessivo per i router, sia per quanto riguarda la banda, sia per la semplice elaborazione.