Resource Reservation Protocol

Z Wikipedii, wolnej encyklopedii
Skocz do: nawigacji, wyszukiwania

RSVP (ang. Resource ReSerVation Protocol, pol. protokół rezerwacji zasobów) – 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 (rutują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[edytuj | edytuj kod]

  • 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[edytuj | edytuj kod]

  1. Flowspec
  2. Filterspec

Zasada działania[edytuj | edytuj kod]

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[edytuj | edytuj kod]

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

Historia[edytuj | edytuj kod]

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

Związane dokumenty RFC[edytuj | edytuj kod]

Chronologicznie, tytuły w oryginale, kursywą oznaczono dokumenty o kategorii innej, niż "Standards Track":

  • RFC 2205wrzesień 1997 – Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification
  • RFC 2206 – RSVP Management Information Base using SMIv2 (Proposed)
  • RFC 2207 – RSVP Extensions for IPSEC Data Flows (Proposed)
  • RFC 2208 – Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment (Informational)
  • RFC 2209 – Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules (Informational)
  • RFC 2210wrzesień 1997 – The Use of RSVP with IETF Integrated Services
  • RFC 2211wrzesień 1997 – Specification of the Controlled-Load Network Element Service
  • RFC 2212wrzesień 1997 – Specification of Guaranteed Quality of Service
  • RFC 2961 – RSVP Refresh Overhead Reduction Extensions (Proposed)
  • RFC 2745 – RSVP Diagnostic Messages (Proposed)
  • RFC 2746 – RSVP Operation Over IP Tunnels (Proposed)
  • RFC 2747 – RSVP Cryptographic Authentication (Proposed)
  • RFC 2750styczeń 2000 – RSVP Extensions for Policy Control
  • RFC 3097 – RSVP Cryptographic Authentication-New Message Type (Proposed)
  • RFC 3175wrzesień 2001 – Aggregation of RSVP for IPv4 and IPv6 Reservations
  • RFC 3270maj 2002 – Multi-Protocol Label Switching (MPLS) Support of Differentiated Services
  • RFC 3477styczeń 2003 – Signalling Unnumbered Links in Resource ReSerVation Protocol – Traffic Engineering (RSVP-TE)
  • RFC 3936październik 2004 – Procedures for Modifying the Resource reSerVation Protocol (RSVP)
  • RFC 4208październik 2005 – Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model
  • RFC 4420luty 2006 – Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
  • RFC 4495maj 2006 – A Resource Reservation Protocol (RSVP) Extension for the Reduction of Bandwidth of a Reservation Flow
  • RFC 4558czerwiec 2006 – Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement
  • RFC draft – (praca w toku) – Extensions to RSVP-TE for Point-to-Multipoint TE LSPs

Linki zewnętrzne[edytuj | edytuj kod]