www.eprace.edu.pl » sieci-ipv6 » Architektury sieciowe z gwarancją parametrów QoS, przegląd rozwiązań. » Architektura usług zintegrowanych

Architektura usług zintegrowanych

W 1994 roku przez organizację IETF został opracowany model usług zintegrowanych IntServ (ang. Integrated Services) [56]. Projekt ten został opracowany z myślą o gwarantowaniu jakości usług dla indywidualnych strumieni, tj. sekwencji pakietów mających jedno określone źródło i jedno miejsce docelowe.

W każdym elemencie sieci muszą występować mechanizmy sterowania jakością usług, tj. rutery i inne urządzenia sieciowe muszą rozpoznawać i obsługiwać protokoły związane z rezerwacją zasobów, ponadto, aplikacja musi mieć zdolność do określania i przekazywania do sieci wymagań dotyczących jakości usługi.

Rys. 4.1. Elementy składowe modelu usług zintegrowanych

Model IntServ określa trzy typy usług zarządzania ruchem sieciowym:

Usługa ta zapewnia górną granicę wartości opóźnień, wymaganą przepływność oraz dopuszczalny procent utraty pakietów. Przeznaczona jest dla aplikacji, które wymagają reżimu czasu rzeczywistego.

Usługa ta zapewnia małe średnie opóźnienie pakietów oraz niski procent straty pakietów. Przeznaczona jest dla elastycznych aplikacji, które nie wymagają obsługi w czasie rzeczywistym, jednak muszą mieć zapewniony określony przedział czasowy.

W ramach tej usługi, transmisja danych odbywa się o możliwie najwyższej przepustowości, bez żadnych gwarancji parametrów przesyłu danych. Jest to standardowy sposób obsługi pakietów w sieci Internet.

Tabela 3 zestawia najważniejsze parametry każdej z wymienionych usług w architekturze IntServ.

Kontrola dostępu AC (ang. Admission Control) jest niezbędna nowe strumienie muszą mieć zagwarantowaną jakość usług bez negatywnego wpływu na już obsługiwane strumienie. Jest ona wywoływana przez komunikaty protokołu 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.

Architektura IntServ wymaga rezerwacji zasobów, w związku z tym istnieje konieczność zastosowania protokołu sygnalizacyjnego dla zestawienia połączenia w sieci.

W tym celu został opracowany protokół RSVP (ang. Resource Reservation Protocol)[34][57]. Przykładowy przepływ wiadomości sygnalizacyjnych w protokole RSVP przedstawia Rysunek 4.2. Żądanie rezerwacji zasobów jest inicjowane przez stronę nadawczą, która wysyła wiadomość typu PATH. Każdy kolejny ruter , do którego przybywa pakiet PATH, zapamiętuje adres poprzedniego rutera, a w jego miejsce wpisuje swój adres i przesyła pakiet do następnego rutera na ścieżce. Po dotarciu do stacji odbiorczej, z otrzymanych danych sporządzany jest pakiet RESV, nazywany żądaniem rezerwacji. RESV. W przypadku, gdy na trasie pakietu PATH występuje łącze, które parametrami nie odpowiada wymaganiom żądania, wyszukiwana jest inna trasa, a jeśli takiej nie ma, wysyłany jest komunikat zwrotny i operacja jest anulowana.

Rys. 4.2. Przepływ wiadomości sygnalizacyjnych w protokole RSVP

Żądanie rezerwacji składa się z dwóch obiektów, FlowSpec i FilterSpec zwanych deskryptorem przepływu (ang. Flow Descriptor). FlowSpec specyfikuje żądania QoS, natomiast FilterSpec definiuje zbiór pakietów zachowujących się według FlowSpec.

Obiekt FlowSpec składa się z klasy usługi, specyfikacji rezerwacji (Rspec) określającej QoS, oraz specyfikacji ruchu (Tspec) opisującej przepływ danych.

W tabeli 2 pokazany został układ oraz zadania powyższych pól w deskryptorze przepływu.


Tabela 2. Zadania pól w deskryptorze przepływu
FilterSpec FlowSpec
Identyfikacja pakietów należących do danego przepływu. Tspec Rspec
Algorytmy kształtowania przepływu ruchu, np. algorytm cieknącego wiadra Parametry QoS np. pasmo, opóźnienia.

Po przyjęciu komunikatu RESV, ruter wykorzystuje FilterSpec do ustawienia parametrów klasyfikatora, a FlowSpec do ustawienia parametrów w mechanizmie warstwy łącza danych. Następnie kieruje pakiet do sąsiedniego rutera, 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ę.


Tabela 3. Zestawienie usług dla architektury IntServ

Guaranteed Quality of Service Controlled–load Service Best Effort
Parametry Tspec

Rspec

Tspec

Brak Rspec

Brak
QoS Górna granica opóźnień,

brak strat pakietów

Best Effort w obszarze nieprzeciążonej sieci Brak
Kontrola ruchu Kontrola dostępu,

kontrola szeregowania pakietów

Kontrola dostępu,

kontrola szeregowania pakietów

Kolejka FIFO

Rozwiązanie IntServ zapewnia gwarancję jakości parametrów dla połączeń typu punkt – punkt. Ponadto każde urządzenie sieciowe na trasie połączenia przechowuje w buforze dane o rezerwacji. Wiążą się z tym wysokie koszty implementacji i ograniczona skalowalność. Z tych powodów model IntServ zaczął tracić na znaczeniu.

Jednak optymalizacja modelu [19] [14], rozwój technologii MPLS (ang. Multiprotocol Label Switching) [52] stosowanej przez rutery szkieletowe, w której trasowanie pakietów zostało zastąpione przez tzw. przełączanie etykiet, wzrost zapotrzebowania na rozwiązania typu punkt-punkt [18], oraz obniżenie kosztów elementów składowych sieci, spowodowały przywrócenie znaczenia modelu IntServ.



komentarze

Copyright © 2008-2010 EPrace oraz autorzy prac.