Resource Reservation Protocol

RSVP (ang. Resource Reservation Protocol) – protokół dla sieci zintegrowanych usług IntServ (ang. integrated services), które do transmisji danych wymagają określonej przepustowości łącza – np. dla transmisji strumieniowych audio lub wideo poprzez Internet. Protokół RSVP umożliwia aplikacji inicjującej transmisję danych strumieniowych zgłoszenie węzłom sieci (hostom) wymagań dotyczących przepustowości łącza i na ich podstawie dokonuje rezerwacji zasobów na każdym węźle wzdłuż trasy przesyłu danych, zapewniając potrzebną przepustowość całego połączenia oraz jakość przekazu, QoS (ang. Quality of Service).

RSVP nie jest protokołem trasowania (routującym), ale został zaprojektowany do współpracy z obecnymi i przyszłymi protokołami trasowania.

Jego rozszerzenie, RSVP-TE, jest używany jako protokół dystrybucji etykiet w technologiach MPLS oraz GMPLS

Cechy protokołu RSVP

• jest niezależny od protokołów trasowania;
• obsługuje transmisję jednokierunkową (simpleks) typu unicast, czyli do jednego odbiorcy (punkt-punkt) oraz multicast, czyli do wielu odbiorców;
• umożliwia aplikacji odbiorcy inicjującej przesyłanie danych zarezerwowanie przepustowości połączenia, a następnie zarządzanie zarezerwowanymi na węzłach sieciowych zasobami i zwolnienie ich po zakończeniu transmisji;
• wymaga okresowego odnawiania dokonanych na każdym węźle rezerwacji, co umożliwia dostosowanie do zmieniającego się ruchu w sieci;
• oferuje dużą skalowalność.

RSVP może być używany zarówno przez hosty jak i rutery w celu zgłaszania zapotrzebowania lub dostarczania usług konkretnej jakości (QoS) dla strumieni danych różnych aplikacji. RSVP definiuje sposób w jaki aplikacje zgłaszają potrzebę rezerwacji oraz zwalniają je po zakończeniu korzystania z połączenia.

Kluczowe idee

1. Flowspec
2. Filterspec

Zasada działania

Protokół RSVP przeprowadza rezerwację począwszy od odbiorcy lub grupy odbiorców w konfiguracji wielopunktu (multipoint). To pozornie dziwne rozwiązanie okazuje się w praktyce szczególnie przydatne właśnie w konfiguracjach punkt-wielopunkt i wielopunkt-wielopunkt. Kiedy do wielopunktu dochodzi nowy punkt, może on dołączyć do rezerwacji znacznie prościej niż mógłby to wykonać za niego nadawca.

Wpisywaniem QoS w odpowiednie strumienie danych zajmuje się wieloczłonowy mechanizm sterowania ruchem (traffic control), złożony w warstwie niższej z klasyfikatora pakietów (classifier) i programu porządkowania pakietów (packet scheduler). Pierwszy z nich wybiera trasę i klasy usług dla każdego pakietu, zgodnie ze statusem rezerwacji, a drugi - przechowuje tabelę przepływu i przydziela zasoby transmisji dla każdego interfejsu związanego z medium określonego łącza danych. Te ostatnie funkcje może spełniać każdy inny mechanizm zależny od warstwy łącza danych.

Funkcjonowanie wspomnianych członów zależy od dwu lokalnych modułów decyzyjnych (MD), od których w istocie rozpoczyna się cały proces rezerwacji: AC (Admission Control) i PC (Policy Control). AC sprawdza, czy zasoby sieciowe węzła są wystarczające do spełnienia życzeń QoS określonej aplikacji, a PC bada uprawnienia administracyjne do ubiegania się o rezerwację zasobów. Jeśli obydwa warunki będą spełnione równocześnie, do klasyfikatora i modułu interfejsu warstwy łącza danych (scheduler) zostaną wprowadzone parametry, jakie serwisy protokołów RSVP i trasowania otrzymały od aplikacji drogą wymiany specjalnych pakietów Path i Resv. W przeciwnym razie w stronę aplikacji ubiegającej się o rezerwację zostanie wysłane zawiadomienie o błędzie (error notification).

Adresowanie grupowe IP (multicasting IP) jest najlepszym sposobem rozsyłania datagramów do wielu punktów przeznaczenia. Transmisje grupowe są sygnalizowane adresami klasy D. Grupy są dynamiczne: stacja może przyłączyć się do grupy lub zrezygnować z niej w dowolnej chwili, musi być tylko przystosowana programowo do wysyłania i odbierania datagramów w trybie multicast. Ta funkcja IP nie ogranicza się tylko do jednej fizycznej podsieci, interfejsy propagują także informacje o przynależności do grupy i zarządzają trasowaniem w taki sposób, że każde urządzenie odbiera kopię każdego datagramu wysyłanego do grupy.

Urządzenia przekazują interfejsom swoją przynależność do grupy za pośrednictwem protokołu IGMP (Internet Group Management Protocol). Protokół ten został stworzony dla zapewnienia skuteczności w optymalnym wykorzystywaniu pasma (zasobów sieciowych). W większości przypadków ruch IGMP polega na okresowym wysyłaniu komunikatów przez interfejs zarządzający wielopunktem i jednej odpowiedzi dla każdej grupy urządzeń w podsieci. Na tym protokole opiera się również inicjowanie sesji grupowej RSVP. W trybie unicast do protokołu IGMP dochodzi jeszcze protokół PIM (Protocol-Independent Multicast).

Po uaktywnieniu grupy z pośrednictwem IGMP potencjalny nadawca sporządza wiadomość Path RSVP i kieruje ją pod adres docelowy IP. Wśród wielu ważnych informacji zawartych w takim pakiecie znajduje się jedna szczególna, przenoszona przez obiekt o nazwie SENDER_TEMPLATE: wzorzec danych nadawcy, opisujący w taki sposób dane jego aplikacji, że odbiorca może jednoznacznie określić zasoby niezbędne do przeprowadzenia transmisji. Wszystkie inne informacje są również przenoszone przez odpowiednie obiekty.

Każdy kolejny router RSVP, do którego przybywa pakiet Path, zapamiętuje adres poprzedniego routera, a w jego miejsce wpisuje swój adres i przesyła pakiet do następnego routera na ścieżce. W końcu pakiet Path dociera do stacji odbiorczej, która na podstawie otrzymanych danych sporządza pakiet Resv RSVP, nazywany żądaniem rezerwacji. Resv, podobnie jak Path, składa się z odpowiednich obiektów.

Podstawowe żądanie rezerwacji zawiera obiekt FLOWSPEC i FILTER_SPEC. Ta para obiektów nosi nazwę deskryptora strumienia (flow descriptor). FLOWSPEC specyfikuje życzenia QoS, a FILTER_SPEC wraz ze specyfikacją sesji definiują zbiór pakietów danych - strumień - przyjmujących QoS określony przez FLOWSPEC. Tak przygotowany pakiet zostaje wysłany do routera, skąd nadeszła wiadomość Path. Router może przyjąć lub odrzucić taką wiadomość. Po przyjęciu Resv router wykorzystuje FILTER_SPEC do ustawienia parametrów klasyfikatora, a FLOWSPEC do ustawienia parametrów w module scheduler lub w innym mechanizmie warstwy łącza danych, a następnie kieruje pakiet do sąsiedniego routera, którego adres zapamiętał podczas transmisji pakietu Path.

Rezerwacja zostanie zakończona, kiedy wiadomości Resv dotrą do nadawcy wiadomości Path. Aplikacja stacji nadawczej może wtedy rozpocząć transmisję, na przykład wideokonferencji lub audiokonferencji. Ponieważ jednak transmisje różnią się właściwościami, projektodawcy wprowadzili różne style rezerwacji. Informacje o stylach rezerwacji przenosi obiekt o takiej samej nazwie - STYLE, zawsze w pakiecie Resv.

Żądanie rezerwacji propaguje się w stronę odpowiednich nadawców. Zbiór tych nadawców - scope - jest dziedziną żądania. Explicit określa listę wybranych nadawców, a wildcard - wszystkich nadawców do określonej sesji.

RSVP określa również dwa sposoby rezerwacji dla różnych nadawców w tej samej sesji: distinct - oddzielnie dla każdego nadawcy oraz shared - rezerwacja wspólna dla wszystkich pakietów od wybranych nadawców. Dziedzina i sposoby dają w sumie cztery możliwe kombinacje, z których zdefiniowano na razie trzy. Styl FF jest preferowany dla transmisji wideo, a SE i WF dla różnych transmisji audio.

Informacje o potrzebnym stylu przenosi obiekt STYLE w 24-bitowym polu Option Vector. Dwa najmniej znaczące bity tego pola zawierają kod sposobu rezerwowania zasobów, a trzy następne - kod dziedziny. Na przykład Explicit ma kod dwójkowy 010, a shared - 10. Po złożeniu będzie to liczba 10010, odpowiadająca stylowi SE. W zapisie szesnastkowym otrzymuje się 000012 i tę wartość przenosi obiekt STYLE w Przykładzie wiadomości Resv. Styl WF ma kod dwójkowy 10001, a FF-01010. Pozostałe bity pola Option Vector - 19 najstarszych - przenoszą na razie same zera.

Specyfikacje RSVP zawierają precyzyjne opisy dróg przemierzanych przez wszystkie wiadomości. Na wiadomość składają się sekwencje różnych obiektów. Specyfikacje definiują nie tylko obiekty, ale również porządek, w jakim będą one występowały w wiadomościach.

Inne aspekty

1. Szyfrowanie
2. Zgłaszanie błędów
3. Funkcja diagnostyczna

Historia

Pierwsza wersja RSVP została opracowana przez agencję IETF w 1997 i opublikowana jako RFC 2205.

Związane dokumenty RFC

Chronologicznie:

• R.R. Braden R.R. i inni, Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification, RFC 2205, IETF, wrzesień 1997, DOI: 10.17487/RFC2205, ISSN 2070-1721, OCLC 943595667  (ang.).
• F.F. Baker F.F., J.J. Krawczyk J.J., A.A. Sastry A.A., RSVP Management Information Base using SMIv2, RFC 2206, IETF, wrzesień 1997, DOI: 10.17487/RFC2206, ISSN 2070-1721, OCLC 943595667  (ang.).
• L.L. Berger L.L., T.T. O'Malley T.T., RSVP Extensions for IPSEC Data Flows, RFC 2207, IETF, wrzesień 1997, DOI: 10.17487/RFC2207, ISSN 2070-1721, OCLC 943595667  (ang.).
• A.A. Mankin A.A. i inni, Resource ReSerVation Protocol (RSVP) -- Version 1 Applicability Statement Some Guidelines on Deployment, RFC 2208, IETF, wrzesień 1997, DOI: 10.17487/RFC2208, ISSN 2070-1721, OCLC 943595667  (ang.).
• R.R. Braden R.R., L.L. Zhang L.L., Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules, RFC 2209, IETF, wrzesień 1997, DOI: 10.17487/RFC2209, ISSN 2070-1721, OCLC 943595667  (ang.).
• J.J. Wroclawski J.J., The Use of RSVP with IETF Integrated Services, RFC 2210, IETF, wrzesień 1997, DOI: 10.17487/RFC2210, ISSN 2070-1721, OCLC 943595667  (ang.).
• J.J. Wroclawski J.J., Specification of the Controlled-Load Network Element Service, RFC 2211, IETF, wrzesień 1997, DOI: 10.17487/RFC2211, ISSN 2070-1721, OCLC 943595667  (ang.).
• S.S. Shenker S.S., C.C. Partridge C.C., R.R. Guerin R.R., Specification of Guaranteed Quality of Service, RFC 2212, IETF, wrzesień 1997, DOI: 10.17487/RFC2212, ISSN 2070-1721, OCLC 943595667  (ang.).
• L.L. Berger L.L. i inni, RSVP Refresh Overhead Reduction Extensions, RFC 2961, IETF, kwiecień 2001, DOI: 10.17487/RFC2961, ISSN 2070-1721, OCLC 943595667  (ang.).
• A.A. Terzis A.A. i inni, RSVP Diagnostic Messages, RFC 2745, IETF, styczeń 2000, DOI: 10.17487/RFC2745, ISSN 2070-1721, OCLC 943595667  (ang.).
• A.A. Terzis A.A. i inni, RSVP Operation Over IP Tunnels, RFC 2746, IETF, styczeń 2000, DOI: 10.17487/RFC2746, ISSN 2070-1721, OCLC 943595667  (ang.).
• F.F. Baker F.F., B.B. Lindell B.B., M.M. Talwar M.M., RSVP Cryptographic Authentication, RFC 2747, IETF, styczeń 2000, DOI: 10.17487/RFC2747, ISSN 2070-1721, OCLC 943595667  (ang.).
• S.S. Herzog S.S., RSVP Extensions for Policy Control, RFC 2750, IETF, styczeń 2000, DOI: 10.17487/RFC2750, ISSN 2070-1721, OCLC 943595667  (ang.).
• R.R. Braden R.R., L.L. Zhang L.L., RSVP Cryptographic Authentication -- Updated Message Type Value, RFC 3097, IETF, kwiecień 2001, DOI: 10.17487/RFC3097, ISSN 2070-1721, OCLC 943595667  (ang.).
• F.F. Baker F.F. i inni, Aggregation of RSVP for IPv4 and IPv6 Reservations, RFC 3175, IETF, wrzesień 2001, DOI: 10.17487/RFC3175, ISSN 2070-1721, OCLC 943595667  (ang.).
• F. LeF.L. Faucheur F. LeF.L. i inni, Multi-Protocol Label Switching (MPLS) Support of Differentiated Services, RFC 3270, IETF, maj 2002, DOI: 10.17487/RFC3270, ISSN 2070-1721, OCLC 943595667  (ang.).
• K.K. Kompella K.K., Y.Y. Rekhter Y.Y., Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE), RFC 3477, IETF, styczeń 2003, DOI: 10.17487/RFC3477, ISSN 2070-1721, OCLC 943595667  (ang.).
• K.K. Kompella K.K., J.J. Lang J.J., Procedures for Modifying the Resource reSerVation Protocol (RSVP), BCP 96, RFC 3936, IETF, październik 2004, DOI: 10.17487/RFC3936, ISSN 2070-1721, OCLC 943595667  (ang.).
• G.G. Swallow G.G. i inni, Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model, RFC 4208, IETF, październik 2005, DOI: 10.17487/RFC4208, ISSN 2070-1721, OCLC 943595667  (ang.).
• A.A. Farrel A.A. i inni, Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE), RFC 4420, IETF, luty 2006, DOI: 10.17487/RFC4420, ISSN 2070-1721, OCLC 943595667  (ang.).
• J.J. Polk J.J., S.S. Dhesikan S.S., A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow, RFC 4495, IETF, maj 2006, DOI: 10.17487/RFC4495, ISSN 2070-1721, OCLC 943595667  (ang.).
• Z.Z. Ali Z.Z. i inni, Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement, RFC 4558, IETF, czerwiec 2006, DOI: 10.17487/RFC4558, ISSN 2070-1721, OCLC 943595667  (ang.).
• R.R. Aggarwal R.R., D.D. Papadimitriou D.D., S.S. Yasukawa S.S., Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs), RFC 4875, IETF, maj 2007, DOI: 10.17487/RFC4875, ISSN 2070-1721, OCLC 943595667  (ang.).
• A.A. Farrel A.A. i inni, Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE), RFC 5420, IETF, luty 2009, DOI: 10.17487/RFC5420, ISSN 2070-1721, OCLC 943595667  (ang.).
• L.L. Berger L.L., G.G. Swallow G.G., Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes Objects, RFC 6510, IETF, luty 2012, DOI: 10.17487/RFC6510, ISSN 2070-1721, OCLC 943595667  (ang.).

Linki zewnętrzne

• Strona Projektu RSVP na www.isi.edu. [dostęp 2010-09-06]. (ang.).
• Internetworking Technology Handbook - Resource-Reservation Protocol (RSVP). [dostęp 2010-09-06]. (ang.).