Resource Reservation Protocol: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
FrescoBot (discussione | contributi)
m Bot: apostrofo dopo l'articolo indeterminativo
Funzionalità collegamenti suggeriti: 3 collegamenti inseriti.
 
(26 versioni intermedie di 20 utenti non mostrate)
Riga 1:
{{F|protocolli di rete|settembre 2011|Questa voce manca completamente di fonti}}
{{nota disambigua|altri significati dell'acronimo|[[Rsvp|Répondez, s'il vous plaît]]}}
IlIn protocollo[[telecomunicazioni]] '''RSVP''' ('''Resource Reservation Protocol''') è un [[protocollo di prenotazionerete|protocollo]] di livello trasporto (nello stack TCP/IP) usato da alcune classi di servizio [[Integrated services|IntServ][http://it.wikipedia.org/wiki/Integrated_services], e che differisce in modo sostanziale dai protocolli di segnalazione convenzionali usati nelle [[rete di telecomunicazioni|reti]] orientate alla [[connessione (informatica)|connessione]].
 
==Descrizione==
Uno dei presupposti chiave di RSVP è quello di non togliere nulla alla robustezza attuale delle reti prive di connessione, tali reti si basano sul fatto di non avere informazioni di stato (o averne pochissime) memorizzate al proprio interno, pertanto è possibile che i [[router]] interrompano bruscamente il proprio funzionamento e si riavviino o che le linee di collegamento si guastino e poi riprendano la propria operatività, senza che la connettività tra i nodi terminali sia compromessa.
 
Uno dei presupposti chiave di RSVP è quello di non togliere nulla alla robustezza attuale delle reti prive di connessione,; tali reti si basano sul fatto di non avere informazioni di stato (o averne pochissime) memorizzate al proprio interno, pertanto è possibile che i [[router]] interrompano bruscamente il proprio funzionamento e si riavviino o che le linee di collegamento si guastino e poi riprendano la propria operatività, senza che la connettività tra i nodi terminali sia compromessa.
 
Il protocollo RSVP cerca di mantenere viva questa robustezza usando il concetto di ''stato soft'' nei router: lo stato soft, al contrario dello ''stato hard'' che si usa nelle reti orientate alla connessione, non ha bisogno di essere rimosso esplicitamente quando non è più necessario perché scade dopo un periodo di tempo opportuno se non viene periodicamente aggiornato.
 
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[[Mbone]].
 
 
== Step principali ==
 
=== 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 contentecontenente i datiil FlowSpec. eOgni router valuterà tramite l'Admission Control. Ognise routertale valutatraffico iè campiaccettabile dalla rete, aggiornae in caso aggiunge al Packet Classifier le informazioni su tale traffico iricavate relatividal parametriFilterSpec, e al Packet [[Scheduler]] le informazioni tratte dal FlowSpec per poter fare un corretto scheduling. Inoltre aggiorna il timer associato allo stato RESV e inoltra il pacchetto al router indicato nel Phop, fonofino al mittente originale. In caso il traffico non sia accettabile dalla rete, viene generato un messaggio di errore.
 
Applicare RSVP con [[Integrated services|IntServ]] porta ad avere una scarsa [[scalabilità]], in quanto è necessario mantenere le informazioni di stato per ciascun microflusso, e il numero di questi microflussi può risultare molto elevato (basti pensare che solitamente un microflusso è individuato da 5-tuple: [[indirizzo IP]] sorgente, indirizzo IP destinazione, porta sorgente, porta destinazione e protocol ID). È tuttavia errato pensare che sia RSVP a essere poco scalabile. Infatti può essere utilizzato con successo nel campo dell'[[MPLS]], laddove l'approccio non è a microflusso ma a flussi aggregati.
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.
 
{{Portale|telematica}}
 
[[Categoria:Protocolli livello rete]]
 
[[ar:آر إس في بي]]
[[ca:Rsvp]]
[[cs:Resource reservation protocol]]
[[de:Resource Reservation Protocol]]
[[en:Resource reservation protocol]]
[[es:Protocolo de reserva de recursos]]
[[fr:Resource Reservation Protocol]]
[[ja:Resource Reservation Protocol]]
[[ko:자원 예약 프로토콜]]
[[pl:Resource Reservation Protocol]]
[[ru:RSVP]]
[[sv:Resursreservationsprotokoll]]
[[zh:资源预留协议]]