Protokół rezerwacji zasobów RSVP (Resource reSerVation Protocol) jest wykorzystywany przez hosty do żądania określonej jakości usługi QoS od sieci dla konkretnego strumienia danych (stream) lub przepływu (flow) aplikacji. Jest również stosowany przez routery do dostarczania żądań jakości usług QoS do wszystkich węzłów na ścieżce danego przepływu i ustanawiania oraz utrzymywania stanu dla dostarczenia żądanej usługi.

Żądania RSVP (Resource Reservation Protocol) skutkują ogólnie zarezerwowaniem określonych zasobów w każdym węźle wzdłuż ścieżki danych. RSVP (Resource Reservation Protocol) żąda zasobów dla pojedynczego kierunku strumienia (simplex). RSVP (Resource Reservation Protocol) traktuje nadawcę logicznie oddzielnie niż odbiorcę pomimo, że ten sam proces aplikacji może w tym samym czasie działać zarówno jako nadawca jak i odbiorca. Protokół działa na szczycie IPv4 i IPv6, zajmując miejsce protokołu transportowego w stosie protokołów. Jednak RSVP (Resource Reservation Protocol) nie przenosi danych aplikacji, ale jest raczej internetowym protokołem sterowania, jak ICMP, IGMP lub protokoły routingu. Tak jak implementacja protokołów zarządzania i routingu, implementacja RSVP jest typowo wykonywana w tle, a nie w ścieżce przekazywania danych.

Model działania RSVP 

RSVP (Resource Reservation Protocol) nie jest sam w sobie protokołem routingu, jest zaprojektowany do działania z bieżącymi i przyszłymi unicastowymi i multicastowymi protokołami routingu. Proces RSVP (Resource Reservation Protocol) odpytuje lokalną bazę danych routingu w celu uzyskania trasy. W przypadku multicastu, host wysyła wiadomość IGMP, aby przyłączyć się do grupy multicastowej a następnie wysyła wiadomość RSVP by zarezerwować zasoby wzdłuż ścieżki dostarczającej informacje tej grupie. Protokoły routingu określają, gdzie pakiety zostaną przekazane, natomiast RSVP jest tylko zainteresowany jakością usług QoS dla tych pakietów, które są przekazywane zgodnie z routingiem.

Jakość usług jest implementowana dla konkretnego strumienia danych przez mechanizmy nazywane sterowaniem ruchu (traffic controll). Mechanizmy te zawierają klasyfikator pakietów, sterowanie dostępem i szeregowanie pakietów lub inne mechanizmy zależne od warstwy łącza danych, które określają, kiedy konkretny pakiet zostanie przekazany. Klasyfikator pakietów wyznacza klasę QoS ( i może także trasę) dla każdego pakietu. Dla każdego interfejsu wychodzącego, mechanizm szeregowania pakietów osiąga (pilnuje) obiecanych parametrów QoS. Sterowanie ruchem implementuje w ten sposób model usług QoS zdefiniowany przez grupę roboczą Integrated Services Working Group.

W czasie zestawiania rezerwacji zasobów, żądanie QoS RSVP jest przekazywane do dwóch lokalnych modułów decyzyjnych: sterowania dostępem (admission control) i sterowania polityk (policy control). Admission control określa czy węzeł ma wystarczająco dostępnych zasobów do zapewnienia żądanych QoS. Policy control określa czy użytkownik ma administracyjne uprawnienia do realizacji rezerwacji. Jeśli oba sprawdzenia będą pozytywne, to parametry zostaną ustawione w klasyfikatorze pakietów i interfejsie warstwy łącza danych (np. dla szeregowania pakietów) by uzyskać pożądane QoS. Jeśli sprawdzenia będą negatywne, RSVP zwraca informacje o błędzie do procesu aplikacji, która zapoczątkowała żądanie.

Architektura RSVP (Resource Reservation Protocol) zakłada, że poszczególne stany dla RSVP i sterowania ruchem są budowane i niszczone przyrostowo w routerach i hostach. W tym celu RSVP jest protokołem typu soft state, co oznacza, że RSVP wysyła okresowo wiadomości odświeżające by utrzymywać stany wzdłuż zarezerwowanej ścieżki. W przypadku braku wiadomości odświeżającej, stan ulega automatycznemu przeterminowaniu i jest kasowany.

Podsumowując RSVP (Resource Reservation Protocol) ma następujące cechy:

• RSVP tworzy rezerwację dla aplikacji unikastowych i multicastowych, adaptując się dynamicznie do zmian w członkostwie grupy, jak i zmian w trasach;
• RSVP jest simpleksowy, tzn. robi rezerwację dla jednokierunkowego strumienia danych;
• RSVP jest zorientowany na odbiornik, tzn. odbiornik strumienia danych inicjuje i utrzymuje rezerwacją zasobów wykorzystywaną dla tego strumienia; 
• RSVP utrzymuje stany „soft” w routerach i hostach, wprowadzając wsparcie dla dynamicznych zmian członkostwa i automatycznej adaptacji do zmian routingu;
• RSVP nie jest protokołem routingu, ale jest zależny od protokołów routingu;
• RSVP transportuje i utrzymuje parametry sterowania ruchem (traffic control) i sterowania polityk (policy control), które są nieprzeźroczyste dla RSVP;
• RSVP udostępnia kilka modeli rezerwacji lub tzw. stylów rezerwacji, by dopasować się do aplikacji;
• RSVP działa transparentnie dla routerów, które go nie obsługują;
• RSVP obsługuje zarówno IPv4 jak i IPv6.