Model RSVP

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 - schedulera. 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).

Na podstawie informacji IGMP potencjalny nadawca sporządza wiadomość Path RSVP i kieruje ją pod adres docelowy IP. Wśród informacji zawartych w takim pakiecie znajduje się jedna szczególna, przenoszona przez obiekt o nazwie SENDER_TEMPLATE. 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 obiektów.

Podstawowe żądanie rezerwacji zawierają obiekty FLOWSPEC i FILTER_SPEC. Noszą one nazwę deskryptora strumienia. FLOWSPEC specyfikuje życzenia QoS, a FILTER_SPEC wraz ze specyfikacją sesji definiuje 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 wideo- 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 nazwie STYLE, zawsze w pakiecie Resv.

Pakiety RSVP są transportowane w polu danych pakietów IPv6 lub IPv4. Wartość 46 w odpowiednim polu nagłówka sygnalizuje, że w polu danych IP znajduje się właśnie pakiet RSVP. W strefie „Wiadomość”, po nagłówku RSVP, umieszcza się różne sekwencje najważniejszych elementów protokołu RSVP - obiektów.

Implementacje RSVP

RSVP jest protokołem sygnalizacji. Węzłom na ścieżce do odbiorców sygnalizuje nadejście strumienia danych, odpowiadającego określonej jakości usług. Wszystkie operacje przeprowadza się na strumieniu kierowanym do jednego lub wielu odbiorców. Strumień jest identyfikowany przez adres IP lub port przeznaczenia albo etykietę przepływu (flow label w IPv6). Te dobrze zdefiniowane mechanizmy ułatwiają implementację algorytmów kolejkowania, podwyższających skuteczność protokołu. Ale odpowiedzialność za spełnianie QoS spada na oprogramowanie routera.

RSVP w kategoriach operatora jest protokołem ściśle związanym z rezerwacją, która musi być przeprowadzona we wszystkich węzłach sieci na ścieżce do odbiorcy lub na ścieżkach określonych przez multicast. Aplikowanie algorytmów sterujących kolejkami i priorytetami staje się tu tak samo ważne jak sam protokół. Jednak swoboda w ich implementowaniu może doprowadzić do różnych konfliktów.

RSVP współpracuje często z protokołem WFQ (Weighted Fair Queuing) zaprojektowanym w Cisco Systems. W sieciach zagrożonych przeciążeniem jest on nawet domyślnym algorytmem tworzenia kolejek. FWQ wydziela z przestrzeni buforowej dla każdego strumienia osobną kolejkę i współpracuje z schedulerem. Liczba kolejek w razie potrzeby może przekroczyć 1000. Każdej kolejce jest przypisana waga tym wyższa, im większa jest liczba pakietów oraz ich długość. FWQ jest prosty w konfigurowaniu i skutecznie zapobiega zdominowaniu łącza przez jeden strumień, ale nie radzi sobie wystarczająco z opóźnieniami i kontrolą pasma.