Protokół rezerwacji zasobów RSVP, (ang. Resource ReserVation Protocol), jest protokołem sygnalizacyjnym typu soft state, czyli programowalnego (tymczasowego) stanu. RSVP zostało pierwotnie opracowane jako protokół sygnalizacyjny dla aplikacji, które chcą zakomunikować sieci swoje wymagania, co do QoS oraz dla sieci w celu zarezerwowania odpowiednich zasobów, aby spełnić wymagania na jakość usług (QoS).

Jak zatem przebiega wymiana informacji w RSVP (Resource ReserVation Protocol)? Węzeł wysyłający informacje (węzeł źródłowy) wysyła wiadomość PATH do odbiorcy, z tymi samymi adresami źródła i przeznaczenia, jak ruch, który węzeł wysyłający generuje. Wiadomość PATH zawiera następujące informacje o wysyłającym:

(1) Tspec określający charakterystykę ruchu,

(2) Template czyli wzór określający format ruchu oraz

(3) opcjonalnie Adspec, który jest używany do obsługi koncepcji jednego przejścia z rozgłoszeniem informacji (OPWA ang. one pass with advertising).

Każdy pośredni router wzdłuż ścieżki, przekazuje wiadomość PATH do następnego skoku (następnego routera) zdeterminowanego przez protokół routingu. Po otrzymaniu wiadomości PATH, odbiorca odpowiada wiadomością RESV, która zawiera deskryptory przepływu używane do żądanej rezerwacji zasobów. Wiadomość RESV jest przenoszona do węzła źródłowego (wysyłającego) w kierunku przeciwnym wzdłuż ścieżki, którą przebyła wiadomość PATH. Każdy router pośredniczący wzdłuż ścieżki może odrzucić lub zaakceptować żądaną rezerwację w wiadomości RESV. Jeśli rezerwacja zostanie odrzucona, to router odrzucający wysyła wiadomość o błędzie do odbiorcy i proces sygnalizacyjny zostaje przerwany. Jeśli żądanie zostanie zaakceptowane, to pasmo łącza i odpowiednia wielkość buforu zostanie przydzielona potokowi oraz związana ze stanem potoku informacja jest instalowana w routerze (rys.1).

Rys. 1 Rezerwowanie pasma przez RSVP dla jednokierunkowego strumienia danych

Sporną kwestią w pierwotnej specyfikacji RSVP (Resource ReserVation Protocol) była skalowalność. Ponieważ rezerwacje są wymagane dla mikrostrumieni, w związku z tym ilość stanów zarządzanych przez element sieciowy rośnie liniowo wraz z liczbą mikrostrumieni.

RSVP (Resource ReserVation Protocol) zostało ostatecznie zmodyfikowane i rozszerzone na wiele różnych sposobów, aby osłabić problemy skalowania. W rezultacie powstał uniwersalny protokół sygnalizacyjny dla sieci Internet. Dla przykładu, RSVP (Resource ReserVation Protocol) został rozszerzony o możliwość rezerwowania zasobów dla agregowanych strumieni, o zestawianie jawnej ścieżki przełączanej (LSP ang. Label Switched Path) w MPLS, a także o możliwość wykonywania innych funkcji sygnalizacyjnych w Internecie (co pozwala na wprowadzenie połączeniowości w MPLS dającej inżunierią ruchu - traffic engineering). Jest także szereg propozycji ograniczenia ilości wiadomości odświeżających, wymaganych do zarządzania zestawionej sesji RSVP.

W prace nad aspektami RSVP (Resource ReserVation Protocol) zostało zaangażowanych szereg grup roboczych IETF, zarówno pierwotna grupa robocza RSVP, jak i grupa MPLS, grupa Protokołu Przydziału Zasobów (ang. Resource Allocation Protocol) oraz grupy Struktury Reguł (ang. Policy Framework).