RSVP (określony w specyfikacji RFC 2205, uaktualnionej przez RFC 2750) jest protokołem konfigurowania rezerwacji zasobów, zaprojektowanym dla sieci usług zintegrowanych. Aplikacje proszą RSVP, aby ten zażądał określonej jakości usług typu end-to-end dla strumienia danych, a RSVP rezerwuje gwarantowane zasoby QoS. Zasoby dostarczane przez RSVP obsługują protokoły routingu emisji pojedynczej i multiemisji, i dają się skalować do dużych grup dostaw multiemisji.
Host odbierający wykorzystuje RSVP, aby żądać określonej jakości usługi dla konkretnego strumienia danych od źródła danych. Żądanie rezerwacji RSVP składa się z określenia pożądanej jakości usługi typu end-to-end oraz z definicji zestawu pakietów, które mają tę QoS otrzymać. RSVP stosowany jest w środowiskach, gdzie rezerwacje QoS obsługiwane są poprzez ponowną alokację, a nie dodawanie zasobów. W przypadku ruchu multiemisji host wysyła komunikaty protokołu zarządzania grupami internetowymi (IGMP), aby dołączyć do grupy, a następnie wysyła komunikaty RSVP, aby zarezerwować zasoby na ścieżce (ścieżkach) dostaw tej grupy. IGMP opisany jest w rozdziale 5.
RSVP zapewnia dostęp do usług zintegrowanych sieci rozległej, w związku z czym wszystkie hosty, routery i inne elementy infrastruktury sieciowej pomiędzy odbiorcą a nadawcą muszą obsługiwać RSVP. Jeżeli jakiś router albo przełącznik nie jest zgodny z RSVP, to komunikaty rezerwacji przenikają przez przeskok i jakość usługi typu end-to-end nie może być zagwarantowana.
Jeżeli wszystkie elementy na trasie są zgodne z RSVP, to każdy z nich rezerwuje zasoby systemowe — takie jak szerokość pasma, procesor, bufory pamięci — aby zaspokoić żądanie QoS. Komunikaty kontrolne jakości usługi protokołu RSVP są również wysyłane, aby zarezerwować zasoby na wszystkich węzłach (rouerach i hostach) na (odwrotnej) ścieżce dostaw do nadawcy. Na każdym z węzłów na ścieżce odbiorca — nadawca, RSVP dokonuje rezerwacji zasobów dla żądanego strumienia. Na każdym z węzłów pośrednich podejmowane są na żądanie dwa rodzaje działań:
· Żądanie zostaje spełnione lub odrzucone zgodnie z kontrolą wpływu danych i zasad. Kontrola wpływu danych ustala, czy dany węzeł ma dostępną wystarczającą ilość zasobów, a kontrola zasad ustala, czy użytkownik posiada upoważnienie do dokonywania rezerwacji. Jeżeli rezerwacja zostanie odrzucona, RSVP zwróci odpowiedniemu odbiorcy (odbiorcom) komunikat o błędzie, a aplikacja ustali czy wysłać dane teraz (za pomocą dostarczania przy użyciu dostępnych możliwości), czy zaczekać i ponowić żądanie później. Jeżeli rezerwacja może zostać przyjęta, to węzeł konfiguruje klasyfikator pakietów, aby wybrać właściwe pakiety danych przychodzących oraz harmonogram pakietów, aby zaimplementować żądaną QoS na interfejsie wychodzącym.
· Żądanie jest propagowane do węzłów znajdujących się wyżej w kierunku odpowiednich nadawców.
Protokół transmituje również komunikaty rozmontowania, które uwalniają zasoby.
RSVP jest protokołem o zmiennym stanie i wymaga, aby rezerwacja była okresowo odświeżana. Informacje dotyczące rezerwacji, albo stan rezerwacji, są buforowane w pamięci podręcznej każdego z przeskoków. Jeżeli protokół routingu sieciowego zmieni ścieżkę danych, to RSVP automatycznie zainstaluje stan rezerwacji na nowej trasie. Jeżeli nie zostaną otrzymane komunikaty odświeżania, to rezerwacje ulegną przedatowaniu i zostaną porzucone.
Protokół jest inicjowany przez odbiorcę, ponieważ inicjacja przez nadawcę nie daje się skalować do dużych scenariuszy multiemisji, które mają niejednorodnych odbiorców. Każdy z odbiorców dokonuje swojej własnej rezerwacji, a wszelkie różnice pomiędzy rezerwacjami rozpoznawane są przez RSVP. Jeżeli różni odbiorcy wymagają różnych zasobów, to zarówno nadawca, jak i routery scalają żądania rezerwacji przyjmując maksymalne żądane wartości.