IntServ (Integrated Services)

Prace IETF zmierzające do zdefiniowania mechanizmów jakości usług opartych na protokole IP sięgają początku lat 90. ubiegłego stulecia. Pierwszy model, nazwany Integrated Services, został opracowany z myślą o dostarczeniu jakości usług – QoS (Quality of Services) – od początku do końca dla indywidualnych strumieni, czyli sekwencji pakietów mającej jedno określone źródło i jedno miejsce docelowe. Został on opisany w RFC 1633. Protokół IntServ nie ma osobnego RFC – rozszerzenie Integrated Services powstało znacznie wcześniej niż skrót.

IntServ opiera się na dwóch kluczowych zasadach. Po pierwsze, w każdym elemencie sieci są potrzebne mechanizmy sterowania jakością usług, a po drugie – aplikacja musi mieć zdolność przekazywania do sieci swoich wymagań dotyczących jakości usług. Elementem sieci w kategoriach IntServ może być pojedynczy węzeł, jak na przykład ruter, podsieć lub większa jednostka ATM czy szkielet DiffServ.

IntServ wnosi do sieci IP usługi czasu rzeczywistego i prawie rzeczywistego, w tym sterowanie ruchem wieloadresowym oraz zapobieganie przeciążeniom, a także zwykłe usługi, charakteryzujące najczęściej Internet. IntServ jest zaliczany do protokołów pierwszej generacji. Ze wspomnianej grupy IETF wyłonił się zespół, który opracował protokół drugiej generacji – DiffServ. Z różnych przyczyn, ale głównie z niedostatków skalowalności, IntServ tracił na znaczeniu. Jednak w kilku ostatnich latach ranga RSVP nieustannie rosła, wraz rozwojem MPLS, i tym samym model IntServ, silnie związany z protokołem sygnalizacji, został również ożywiony. Sieci IP IntServ/RSVP mogą współpracować z sieciami DiffServ i MPLS.

Zgodnie z koncepcją IntServ aplikacje mogą wybierać dla swoich przepływów osobne ścieżki, obsługiwane z określoną jakością QoS, wynikającą z kryteriów klasyfikacji ruchu, wymaganego pasma, charakterystyk strumieni oraz innych deskryptorów ruchu. Obsługa ruchu w rodzaju wideokonferencji czy transmisji na żywo wymaga gwarancji, a tych nie można udzielić bez rezerwacji. Dlatego DiffServ jest bardzo ściśle związany z protokołem RSVP, opisanym dokładniej w pierwszej części Vademecum. RSVP przewiduje, że zasoby będą rezerwowane dla każdego strumienia, wymagającego QoS, na każdym ruterze znajdującym się na ścieżce między nadawcą a odbiorcą. Rutery na tej ścieżce są poznawane w procesie sygnalizacji. Muszą one przechowywać parametry każdego konkretnego strumienia.

Protokół IntServ określa trzy typy usług: CL (Controlled Load), GS (Guaranteed Quality of Service), BE (Best Effort).

1. Cel usługi CL (Controlled Load), opisanej w RFC 2221, jest uwidoczniony w nazwie – sterowanie obciążeniem. Usługa jest zbliżona do dostarczania pakietów w sieci o niewielkim obciążeniu, a więc na miarę aplikacji wrażliwych na przeciążenia w sieci, takich jak przesyłanie dźwięku lub obrazu wideo niekoniecznie ściśle w czasie rzeczywistym: adaptacyjnych czasu rzeczywistego – kiedy odbiorca może w pewnym zakresie eliminować skutki zmiennego opóźnienia drogą modyfikowania strumienia wyjściowego, dźwiękowych – jeśli w reakcji na niespodziewany wzrost opóźnienia można wstawiać okresy ciszy czy wreszcie aplikacji wideo – jeśli odbiorca może skompensować wzrost opóźnienia albo przez niewielkie spowolnienie transmisji, albo wstawianie takich samych ramek. Elementy sieci otrzymują zgłoszenia wymagań od aplikacji w specjalnych ramkach rezerwacyjnych, nazywanych tokenami. W wymaganiach podawane są wartości następujących parametrów: maksymalna szybkość transmisji (B/s), minimalna długość datagramu (B), maksymalna długość pakietu, szybkość wyjścia bufora (B/s) i rozmiar bufora (B).
2. Usługa GS (Guaranted Quality of Service) gwarantuje wymaganą przepływność, górną granicę wartości opóźnień oraz dopuszczalny procent utraty pakietów, a więc jest przeznaczona dla aplikacji czasu rzeczywistego. Została scharakteryzowana w RFC 2212. Aplikacja zgłasza tu swoje wymagania za pośrednictwem takiego samego tokena jak w CL. Akceptacja pakietów może się jednak odbywać na obrzeżach sieci lub buforach tych węzłów drzewa sieci, gdzie łączą się różne strumienie. W pierwszym przypadku decyzję o przyjęciu bądź odrzuceniu podejmuje element sieci na podstawie porównania istniejących zasobów z wymaganiami zawartymi w tokenie. Jeśli zasoby nie będą wystarczające, to zgłoszenie pochodzące od danej aplikacji zostanie odrzucone. Ten mechanizm akceptacji nosi nazwę normalnego. Z kolei w drugim z mechanizmów – przekształceniowym – są podejmowane próby dostosowania ruchu do wymagań. Jeśli się jednak nie powiodą, to zostanie zgłoszony błąd.
3. W przypadku usługi BE (Best Effort) – ruch jest obsługiwany w miarę możliwości, jak w dowolnie obciążonym Internecie.

Podczas definiowania i modyfikowania IntServ twórcy skupili się nie tylko na funkcjach takich, jak klasyfikacja pakietów, szeregowanie i kontrola dopuszczania, ale i na kilku innych. Wszystkie ważniejsze ogniwa, składające się na architekturę protokołu IntServ, przedstawia rysunek 248. Pakiet jest przyporządkowany do określonej klasy, dzięki czemu można sterować ruchem sieciowym. Przynależność do klasy zależy od zawartości znanego pola z nagłówka IP. Na podstawie klasy i adresu docelowego można wyznaczyć odcinek trasy pakietu, odpowiadający pojedynczemu skokowi. Pakiety w tej samej klasie są tak samo przetwarzane przez program szeregujący pakiety (packet scheduler), który zarządza ich ekspedycją, używając kolejek, liczników czasu oraz pozostałych mechanizmów. Ogólnie ustalaniem kolejek dla każdego portu oraz odrzucaniem pakietów, jeśli to konieczne, zajmuje się moduł zarządzania kolejkami, oparty na polityce kolejkowania. Polityka ta określa, jak transmitować pakiety znajdujące się w kolejkach do tego samego portu wyjściowego i jakich używać kryteriów odrzucania, powiązanych z czasem, ażeby zapobiec przeciążeniom i zapewnić wymagany poziom QoS.

Kontrola dopuszczenia (admission control) została uznana za niezbędną – nowe strumienie muszą mieć zagwarantowaną jakość usług bez negatywnego wpływu na już dopuszczone strumienie. Jest ona wywoływana przez protokół rezerwacji podczas każdego zgłoszenia nowego strumienia. O wyniku kontroli decyduje udział zasobów w obsłudze bieżących strumieni i obciążeniu sieci.

Model IntServ wyróżnia się kilkoma cechami.

1. protokół RSVP został tak zaprojektowany, że może współpracować zarówno z dobrze poznanymi protokołami trasowania, jak i tymi, które pojawią się w przyszłości.
2. gwarantowaniem wartości opóźnienia, które nie wymaga komentarza.
3. WFG może tu zapewnić kontrolowane, wspólne wykorzystanie kanałów. Cel tej usługi nie polega na ograniczaniu wartości opóźnień, lecz na ograniczaniu ruchu przeciążającego kanał. Jeśli przy tym kanał ma dużą przepływność, to można stosować dowolne kombinacje ruchu. W podobny sposób wykorzystuje się WFQ i jego odmiany na ruterach i stosuje do dzielenia ruchu na klasy, oparte na takich parametrach, jak typ protokołu lub aplikacji.

• WFQ (Weighted Fair Queuing) – protokół kolejkowania pakietów, zaprojektowany w Cisco Systems, współpracujący często z RSVP. W sieciach zagrożonych przeciążeniem jest nawet domyślnym algorytmem tworzenia kolejek. WFQ 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 wyższa jest liczba pakietów oraz ich długość. WFQ jest prosty w konfigurowaniu i skutecznie zapobiega zdominowaniu łącza przez jeden strumień, ale nie radzi sobie wystarczająco z opóźnieniami i kontrolą pasma.
• CBWFQ (Class Based WFQ) – udoskonalona wersja protokołu WFQ. CBWFQ przypisuje kolejce, oprócz wagi, także klasę, która ma przyporządkowany udział w pasmie łącza. Bardziej złożony program schedulera umożliwi takie pobieranie pakietów, że pasmo przyporządkowane klasie nie zostanie przekroczone.
• PQWFQ (Priority Queuing WFQ) – udoskonalona wersja protokołu WFQ. Poszerza on WFQ o kolejkę priorytetową, obsługiwaną przed wszystkimi pozostałymi kolejkami. Program schedulera pobiera najpierw pakiet z kolejki priorytetowej, a następnie z kolejki WFQ.

Największa wada IntServ ma swoje podłoże w niewielkiej skalowalności RSVP, zwłaszcza w sieciach szkieletowych. Ponadto zasoby ruterów, niezbędne do przetwarzania i przechowywania wszystkich informacji RSVP, zwiększają się proporcjonalnie do liczby strumieni QoS. Muszą to być bardzo wydajne urządzenia, a ze statystyk ruchu wynika, że większość połączeń IP od początku do końca trwa stosunkowo krótko.

Oprócz RSVP każdy węzeł IntServ musi mieć zaimplementowane mechanizmy sterowania przyjęciem zgłoszeń, klasyfikowania ruchu i zarządzania kolejkowaniem, stanowiące w sumie duże wymagania dla ruterów czy przełączników.