1. Problem Internetu "Best-Effort"

Tradycyjny internet działa w oparciu o model dostarczania "najlepszych starań" (best-effort). Oznacza to, że sieć dokłada wszelkich starań, aby dostarczyć Twoje pakiety danych, ale nie daje absolutnie żadnych obietnic. Dla wielu wczesnych zastosowań, takich jak e-mail czy transfer plików, było to wystarczające. Jeśli niektóre pakiety były opóźnione lub utracone, Protokół Kontroli Transmisji (TCP) po prostu je retransmitował, a użytkownik ledwo to zauważał, poza nieco dłuższym czasem pobierania.

Jednak wraz z rozwojem aplikacji czasu rzeczywistego, takich jak Voice over IP (VoIP), streaming wideo na żywo i gry online, model best-effort okazał się nieadekwatny. W tych zastosowaniach czas jest wszystkim. Pakiet audio rozmowy telefonicznej, który dociera z 500-milisekundowym opóźnieniem, jest całkowicie bezużyteczny; moment w rozmowie już minął. Nieprzewidywalność sieci, ze zmiennymi opóźnieniami (jitter) i potencjalną utratą pakietów podczas przeciążenia, uniemożliwiła zapewnienie spójnego, wysokiej jakości doświadczenia dla tych wrażliwych na czas usług. Potrzebna była nowa architektura, która mogłaby zapewnić jawne, przewidywalne gwarancje dotyczące wydajności sieci.

2. Wprowadzenie Zintegrowanych Usług (IntServ): Filozofia Rezerwacji

Model Zintegrowanych Usług (IntServ) został opracowany przez IETF jako kompleksowe rozwiązanie tego problemu. Fundamentalna filozofia IntServ polega na odejściu od podejścia "miejmy nadzieję, że się uda" na rzecz modelu jawnej rezerwacji zasobów.

Główna idea IntServ polega na tym, że zanim aplikacja wyśle jakiekolwiek dane, musi najpierw zasygnalizować swoje potrzeby sieci i zażądać rezerwacji zasobów niezbędnych do ich zaspokojenia. Rezerwacja ta musi być dokonana na każdym routerze wzdłuż całej ścieżki od nadawcy do odbiorcy. Jeśli każdy router na ścieżce zgodzi się, że ma wystarczające zasoby (przepustowość i przestrzeń buforową) i zaakceptuje rezerwację, aplikacja otrzymuje gwarancję od końca do końca dla swoich danych. Jeśli choćby jeden router na ścieżce nie może zapewnić żądanych zasobów, rezerwacja kończy się niepowodzeniem, a aplikacja jest powiadamiana, że nie może uzyskać pożądanej jakości usługi. To podejście zapewnia "twardy QoS", co oznacza, że gwarancje są jawne i mierzalne.

3. Główne Mechanizmy IntServ

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

A. Przepływy Danych: Identyfikacja Konwersacji

IntServ nie zarządza ruchem w sposób ogólny. Zamiast tego działa na pojęciu przepływu. Przepływ to określony, dający się odróżnić strumień danych z pojedynczej aplikacji. Na przykład rozmowa VoIP między dwoma użytkownikami to jeden przepływ, strumień wideo z serwera do użytkownika to inny przepływ, a transfer pliku to trzeci. Routery w sieci IntServ muszą być w stanie identyfikować pakiety należące do określonych przepływów, aby zastosować do nich odpowiednią, zarezerwowaną usługę.

B. Rezerwacja Zasobów: Żądanie Gwarancji

Aplikacja inicjuje rezerwację, określając charakterystykę swojego ruchu i wymagany poziom usług. Odbywa się to za pomocą protokołu sygnalizacyjnego. Sieć rezerwuje następnie dwa podstawowe zasoby wzdłuż wyznaczonej ścieżki:

• Przepustowość: Pewna część przepustowości łącza jest odkładana na bok dla danego przepływu, zapewniając, że może on przesyłać dane z wymaganą szybkością, nawet gdy łącze jest zajęte.
• Przestrzeń Buforowa: Część pamięci routera jest rezerwowana dla pakietów danego przepływu. Zapewnia to, że w przypadku wystąpienia małych impulsów, pakiety mogą być kolejkowane bez odrzucania, co jest niezbędne do zapewnienia gwarancji opóźnienia.

C. Kontrola Przyjęć: Strażnik Sieci

Centralnym elementem modelu IntServ jest kontrola przyjęć. Kiedy żądanie nowej rezerwacji dociera do routera, router ten musi wykonać obliczenia. Sprawdza swoje bieżące zobowiązania co do zasobów w stosunku do całkowitych dostępnych zasobów. Musi odpowiedzieć na pytanie: "Jeśli zaakceptuję ten nowy przepływ, czy nadal będę w stanie honorować wszystkie obietnice, które już złożyłem istniejącym przepływom?". Jeśli odpowiedź brzmi tak, akceptuje rezerwację. Jeśli odpowiedź brzmi nie, odrzuca żądanie. Ten proces działa jak strażnik, zapobiegając nadmiernemu obciążeniu sieci i zapewniając, że raz dana gwarancja jest zawsze dotrzymywana.

4. RSVP: Protokół Sygnalizacyjny dla IntServ

Mechanizmem, którego aplikacje używają do komunikowania swoich potrzeb sieci i ustanawiania rezerwacji, jest Protokół Rezerwacji Zasobów (RSVP). RSVP to protokół sygnalizacyjny, co oznacza, że nie przenosi on samych danych aplikacji; przenosi tylko komunikaty niezbędne do skonfigurowania ścieżki dla tych danych.

Dwuetapowy Proces Rezerwacji

RSVP ustanawia rezerwacje przy użyciu dwuetapowego procesu obejmującego komunikaty `PATH` i `RESV`.

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

   Proces rozpoczyna się od nadawcy danych (np. serwera wideo). Aplikacja nadawcy wysyła komunikat RSVP `PATH` przeznaczony na adres IP odbiorcy. Ten komunikat `PATH` podróżuje przez sieć, podążając tą samą trasą, którą będą podążać rzeczywiste pakiety danych. Kiedy przechodzi przez każdy router obsługujący IntServ, router sprawdza komunikat i tworzy "stan ścieżki". Ten wpis stanu rejestruje poprzedni przeskok, tworząc w zasadzie ślad, który wyznacza ścieżkę powrotną do nadawcy. Komunikat `PATH` nie dokonuje żadnych rezerwacji; jedynie ustanawia ścieżkę zwrotną dla żądania rezerwacji.

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

   Kiedy komunikat `PATH` dociera do odbiorcy danych (np. klienta wideo), aplikacja odbierająca zna teraz ścieżkę do nadawcy. Odbiorca jest odpowiedzialny za zainicjowanie faktycznej rezerwacji. Tworzy komunikat RSVP `RESV` (Rezerwacja), określając pożądaną jakość usług (np. "Potrzebuję 5 Mbps przepustowości"). Ten komunikat `RESV` jest następnie wysyłany z powrotem w kierunku nadawcy, podążając ścieżką zwrotną ustanowioną przez komunikat `PATH`.

   W miarę jak komunikat `RESV` podróżuje z przeskoku na przeskok z powrotem do nadawcy, każdy router na ścieżce go przechwytuje. Na każdym routerze dzieje się co następuje:

   • 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 niezbędne zasoby, aktualizuje swój wewnętrzny stan, aby odzwierciedlić to nowe zobowiązanie, i przekazuje komunikat `RESV` do następnego routera w górę ścieżki.
   • Jeśli nie może zaspokoić żądania, odrzuca je i wysyła komunikat o błędzie rezerwacji z powrotem do odbiorcy.

   Jeśli komunikat `RESV` pomyślnie dotrze do pierwotnego nadawcy, oznacza to, że każdy router wzdłuż ścieżki zaakceptował i ustanowił rezerwację. Istnieje teraz gwarantowany kanał od końca do końca, a nadawca może zacząć przesyłać swoje dane z zapewnieniem, że sieć zapewni żądaną Jakość Usługi.

To podejście zorientowane na odbiorcę jest kluczową cechą projektową RSVP. Naturalnie wspiera scenariusze multicast, w których jeden nadawca przesyła dane do wielu odbiorców. Każdy odbiorca może złożyć własne, niezależne żądanie rezerwacji, dostosowane do jego specyficznych potrzeb i przepustowości łącza.

5. Klasy Usług IntServ

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

• Usługa Gwarantowana (Guaranteed Service)

  Jest to najwyższy poziom usług w IntServ. Zapewnia ona twarde, matematycznie udowadnialne, deterministyczne (nie statystyczne) górne ograniczenie opóźnienia pakietów od końca do końca. Aplikacja żądająca tej usługi określa swoje charakterystyki ruchu za pomocą modelu wiadra żetonów. Dokonując rezerwacji usługi gwarantowanej, aplikacja ma pewność, że jej pakiety nigdy nie zostaną odrzucone z powodu przepełnienia kolejki (o ile pozostaje w swoim profilu ruchu) i dotrą w ramach obliczonego limitu opóźnienia. Usługa ta jest idealna dla wysoce nietolerancyjnych aplikacji czasu rzeczywistego, które wymagają ścisłych gwarancji czasowych.

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

  Usługa ta zapewnia mniej rygorystyczny, ale wciąż bardzo niezawodny poziom usług. Nie zapewnia ona ścisłego numerycznego ograniczenia opóźnienia, ale gwarantuje wydajność "ściśle odpowiadającą wydajności, jaką ten sam przepływ otrzymałby w nieprzeciążonej sieci best-effort". W istocie ma na celu sprawienie, aby aplikacja czuła się, jakby działała w lekko obciążonej sieci, nawet gdy sieć jest zajęta. Jest odpowiednia dla szerszego zakresu adaptacyjnych aplikacji czasu rzeczywistego, które mogą tolerować niewielkie wahania opóźnień, ale wciąż wymagają lepszej wydajności niż standardowy model best-effort.

6. Pięta Achillesowa: Problem Skalowalności IntServ

Chociaż koncepcja zapewnienia twardych gwarancji dla poszczególnych przepływów jest potężna, model IntServ cierpi na fatalną wadę, która uniemożliwiła jego szerokie wdrożenie: głęboki brak skalowalności.

• Utrzymywanie Stanu na Przepływ:Największym problemem jest ilość stanu, jaką routery muszą utrzymywać. Router rdzeniowy w dużej sieci ISP może obsługiwać miliony jednoczesnych przepływów. W modelu IntServ ten router musiałby przechowywać oddzielny wpis stanu rezerwacji dla każdego z tych przepływów. Ta "eksplozja stanu" wymagałaby ogromnych ilości pamięci i mocy obliczeniowej, co czyni implementację w rdzeniu sieci zbyt kosztowną i złożoną.
• Narzut Sygnalizacyjny: Same komunikaty RSVP zużywają przepustowość sieci i cykle procesora routera. W dużej sieci ciągły strumień komunikatów `PATH` i `RESV` do ustanawiania, zrywania i odświeżania stanów generowałby znaczny narzut.
• Złożoność: Ogólna złożoność implementacji i zarządzania IntServ i RSVP w dużej, wielodostawczej sieci, takiej jak internet, jest niezwykle wysoka.

Z powodu tych problemów ze skalowalnością, IntServ jest prawie nigdy nieużywany w publicznym internecie. Jego zastosowanie ogranicza się do mniejszych, kontrolowanych sieci prywatnych (np. dedykowanych firmowych sieci wideokonferencyjnych, przemysłowych systemów sterowania), gdzie liczba przepływów jest możliwa do zarządzania, a potrzeba twardych gwarancji przeważa nad złożonością. Mimo ograniczonego wdrożenia, koncepcje zapoczątkowane przez IntServ położyły kluczowe podwaliny pod bardziej skalowalne modele QoS, takie jak DiffServ, oraz protokoły inżynierii ruchu, takie jak MPLS-TE.