IntServ

1. Model Best-Effort w Internecie

Tradycyjny internet działa w modelu dostarczania "najlepszych starań" (best-effort). Sieć przekazuje pakiety zgodnie z dostępnymi zasobami, bez rezerwacji przepustowości i bez określania parametrów opóźnienia oraz strat. Model nie rozróżnia znaczenia pakietu dla aplikacji, więc obsługa zależy od bieżącego obciążenia i konfiguracji urządzeń. Dla wielu wczesnych zastosowań, takich jak e-mail czy transfer plików, było to wystarczające. Gdy pakiet został opóźniony lub utracony, Protokół Kontroli Transmisji (TCP) retransmitował dane, co wydłużało pobieranie. Retransmisja przywraca kompletność strumienia, lecz zwiększa czas transferu.

Aplikacje czasu rzeczywistego, takie jak Voice over IP (VoIP), transmisja wideo na żywo i gry online, mają wymagania dotyczące opóźnienia oraz jego zmienności. Pakiet audio rozmowy telefonicznej, który dociera z opóźnieniem 500 milisekund, trafia do odbiorcy po wykorzystaniu odpowiadającego mu fragmentu rozmowy. Zmienność opóźnienia (jitter) i utrata pakietów podczas przeciążenia pogarszają odbiór takich usług. Wymagania dotyczące terminów i kolejności dostarczenia nie są w tym modelu rejestrowane na ścieżce. Router nie zna terminu odtworzenia pakietu przez odbiornik. Potrzebna była architektura opisująca przewidywalne parametry obsługi ruchu.

2. IntServ i rezerwacja zasobów

Model Zintegrowanych Usług (IntServ) został opisany przez IETF jako architektura dla usług wymagających określonych parametrów. Jej podstawą jest jawna rezerwacja zasobów dla przepływu. Aplikacja otrzymuje parametry wybranej klasy usługi po przejściu kontroli przyjęcia.

Aplikacja korzystająca z IntServ sygnalizuje wymagania i żąda zasobów potrzebnych do ich spełnienia. Rezerwacja jest sprawdzana na każdym routerze wzdłuż ścieżki od nadawcy do odbiorcy. Gdy routery zaakceptują wymagany udział przepustowości, buforów i obsługi kolejek, przepływ otrzymuje uzgodnione parametry od końca do końca. Brak zasobów na jednym z routerów prowadzi do odrzucenia żądania i przekazania informacji o nieudanej rezerwacji. Rezerwacja obejmuje urządzenia pośrednie, dlatego decyzja nie jest podejmowana wyłącznie przez hosta końcowego. Zgodność z opisem ruchu pozostaje warunkiem wykorzystania uzgodnionych parametrów. Taki mechanizm daje jawny i mierzalny poziom QoS.

3. Mechanizmy IntServ

Architektura IntServ jest zbudowana na trzech podstawowych, współdziałających koncepcjach: przepływie, rezerwacji zasobów i kontroli przyjęć.

A. Przepływy danych

IntServ operuje pojęciem przepływu. Jest to rozpoznawalny strumień danych jednej aplikacji. Rozmowa VoIP między dwoma użytkownikami stanowi jeden przepływ, strumień wideo z serwera do użytkownika kolejny, a transfer pliku następny. Do identyfikacji przepływu używa się zwykle adresów źródłowych i docelowych oraz numerów portów. Na tej podstawie router może przypisać strumieniowi odrębny profil obsługi. Routery muszą identyfikować pakiety przepływu, aby zastosować przypisaną mu usługę.

B. Rezerwacja zasobów

Aplikacja inicjuje rezerwację, określając charakterystykę ruchu i wymagany poziom usługi. Sygnalizacja przekazuje te parametry do urządzeń na ścieżce. Opis ruchu pozwala urządzeniom ocenić, czy żądana obsługa mieści się w dostępnej pojemności. Parametry obejmują między innymi średnią szybkość i dopuszczalny impuls. Sieć uwzględnia dwa podstawowe zasoby:

• Przepustowość: Część przepustowości łącza jest przypisana do przepływu, aby mógł przesyłać dane z wymaganą szybkością podczas obsługi pozostałego ruchu. Przydział nie oznacza, że łącze jest zajęte wyłącznie dla tego przepływu. Przydział jest kontrolowany przez harmonogramowanie routera.
• Przestrzeń buforowa: Parametry obsługi określają miejsce dla pakietów przepływu w buforach routera. Pozwala to obsłużyć niewielkie impulsy ruchu bez odrzucenia zgodnego pakietu i uwzględnić kolejki w obliczeniu opóźnienia. Rozmiar bufora musi uwzględniać charakterystykę impulsu określoną w opisie ruchu. Bufor ogranicza odrzucenia wynikające z krótkotrwałego napływu.

C. Kontrola przyjęcia

Kontrola przyjęcia porównuje żądanie z bieżącymi zobowiązaniami i dostępnymi zasobami routera. Router akceptuje rezerwację, gdy po jej dodaniu nadal może obsłużyć istniejące przepływy zgodnie z ich parametrami. W przeciwnym razie odrzuca żądanie. Kontrola działa lokalnie w każdym urządzeniu, a wynik wszystkich decyzji wyznacza możliwość ustanowienia usługi na całej ścieżce. Odrzucenie nowego żądania nie narusza istniejących rezerwacji. Takie sprawdzenie chroni rezerwacje już ustanowione przed nadmiernym obciążeniem.

4. RSVP: Protokół Sygnalizacyjny dla IntServ

Mechanizmem, którego aplikacje używają do przekazywania wymagań i ustanawiania rezerwacji, jest Protokół Rezerwacji Zasobów (RSVP). RSVP jest protokołem sterowania siecią. Przenosi komunikaty PATH i RESV oraz stan sygnalizacyjny, a dane aplikacji są przesyłane osobno. RSVP stosuje stan miękki, który jest odświeżany okresowymi komunikatami. Brak odświeżenia powoduje wygaśnięcie rezerwacji. Komunikaty PATH i RESV odświeżają stan po zmianach topologii.

Podstawowy przebieg PATH i RESV

Podstawowy przebieg RSVP obejmuje dwa kierunki wymiany komunikatów PATH i RESV.

1. Krok 1: Komunikat PATH (Nadawca do Odbiorcy)

   Proces rozpoczyna się od nadawcy danych, na przykład serwera wideo. Aplikacja nadawcy wysyła komunikat RSVP PATH do adresu odbiorcy. Komunikat przechodzi trasą wyznaczoną dla danych. Router obsługujący IntServ zapisuje stan ścieżki, w tym adres poprzedniego przeskoku, aby można było kierować komunikat RESV w stronę nadawcy. Stan PATH jest tworzony na każdym routerze, a kolejna wiadomość PATH może go odświeżyć. Po zmianie trasy stan ścieżki może zostać utworzony ponownie. PATH nie rezerwuje zasobów.

2. Krok 2: Komunikat RESV (Odbiorca do Nadawcy)

   Gdy PATH dociera do odbiorcy, na przykład klienta wideo, odbiorca tworzy komunikat RSVP RESV (Rezerwacja). Komunikat zawiera żądaną usługę, na przykład przepustowość 5 Mbps, i wraca do nadawcy ścieżką ustaloną przez PATH.

   Komunikat RESV przechodzi przez kolejne routery w stronę nadawcy. Każdy router na ścieżce wykonuje następujące czynności:

   • Moduł kontroli przyjęć routera bada żądanie rezerwacji.
   • Sprawdza swoje dostępne zasoby przepustowości i buforów, aby zobaczyć, czy może zaspokoić żądanie.
   • Jeśli może, alokuje zasoby, aktualizuje stan rezerwacji i przekazuje komunikat RESV do następnego routera w stronę nadawcy.
   • Jeśli nie może zaspokoić żądania, odrzuca je i wysyła komunikat o błędzie rezerwacji z powrotem do odbiorcy.

   Jeśli RESV dotrze do pierwotnego nadawcy, każdy router na ścieżce zaakceptował i zapisał rezerwację. Uzgodniona usługa od końca do końca obowiązuje dla ruchu zgodnego z parametrami, więc nadawca może rozpocząć transmisję. Odrzucenie na dowolnym routerze przerywa ustanawianie rezerwacji. Przepływ danych nie jest przenoszony przez RSVP. Po ustanowieniu rezerwacji korzysta z normalnego przekazywania IP.

Rezerwacja RSVP jest inicjowana przez odbiorcę. Model obsługuje również multicast, w którym jeden nadawca przesyła dane do wielu odbiorców. Każdy odbiorca może wysłać własne żądanie rezerwacji dopasowane do potrzeb i przepustowości jego łącza. Taki przebieg pozwala odbiorcom zgłaszać zapotrzebowanie niezależnie od nadawcy.

5. Klasy Usług IntServ

IntServ definiuje dwie podstawowe klasy usług, o które może wnioskować aplikacja.

• Usługa Gwarantowana (Guaranteed Service)

  Usługa gwarantowana zapewnia matematycznie wyznaczalne, deterministyczne górne ograniczenie opóźnienia pakietów od końca do końca. Aplikacja opisuje ruch za pomocą modelu wiadra żetonów, który określa średnią szybkość i dopuszczalny impuls. Dla ruchu zgodnego z profilem usługa zapewnia brak strat z powodu przepełnienia kolejki oraz dostarczenie w obliczonym limicie opóźnienia, przy założeniu sprawnych elementów sieci i niezmienionej trasy. Warunek zgodności ogranicza ruch poza zadanym profilem. Ten wariant służy aplikacjom czasu rzeczywistego wymagającym ścisłych parametrów czasowych.

• Usługa o Kontrolowanym Obciążeniu (Controlled-Load Service)

  Usługa o kontrolowanym obciążeniu nie określa ścisłego liczbowego ograniczenia opóźnienia. Jej celem jest wydajność zbliżona do tej, którą ten sam przepływ otrzymałby w nieprzeciążonej sieci best-effort. Brak ścisłego limitu nie oznacza rezerwacji bez kontroli przyjęcia. Aplikacja nadal potrzebuje własnego mechanizmu odtwarzania czasu i buforowania, dlatego wariant ten pasuje do adaptacyjnych usług czasu rzeczywistego tolerujących zmienność opóźnienia.

6. Skalowalność IntServ

Parametry dla poszczególnych przepływów wymagają stanu rezerwacji oraz sygnalizacji w urządzeniach na ścieżce. Stan RSVP jest odświeżany, więc duża liczba przepływów zwiększa także ruch sygnalizacyjny. W dużych domenach liczba takich wpisów ogranicza skalowalność IntServ.

• Stan na przepływ: Router rdzeniowy w dużej sieci ISP może obsługiwać dużą liczbę jednoczesnych przepływów. W modelu IntServ przechowuje się oddzielny wpis rezerwacji dla każdego przepływu. Wpis zawiera parametry i stan obsługi związany z przepływem. Taki wzrost liczby wpisów zwiększa wymagania pamięciowe i obliczeniowe urządzenia.
• Narzut sygnalizacyjny: Komunikaty RSVP zużywają przepustowość oraz czas procesora routera. W dużej sieci komunikaty PATH i RESV ustanawiają, odświeżają i usuwają stan rezerwacji. Odświeżanie powtarza się przez cały czas trwania usługi.
• Złożoność: Implementacja i zarządzanie IntServ oraz RSVP w dużej sieci wielodostawczej wymaga uzgodnienia stanu, sygnalizacji i polityk między domenami. Koordynacja obejmuje również zgodność klas usług i polityk.

Z tych powodów IntServ rzadko stosuje się w dużych sieciach publicznych. Model pasuje do mniejszych, kontrolowanych sieci prywatnych, na przykład firmowych sieci wideokonferencyjnych i przemysłowych systemów sterowania, w których liczba przepływów pozostaje możliwa do obsługi. Mniejsza skala ułatwia utrzymanie stanu i kontrolę przyjęcia. Model IntServ stanowi punkt odniesienia dla agregowania stanu przez DiffServ. Rozszerzenia RSVP-TE wykorzystują RSVP do ustanawiania tuneli LSP w MPLS i mogą korzystać z rezerwacji zasobów.