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.
Model IntServ określa trzy typy usług zarządzania ruchem sieciowym:
Usługę, która ściśle gwarantuje parametry połączenia (ang. Guaranteed Quality of Service) [55].
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ługę zapewniającą pewną jakość obsługi (ang. Controlled–load Service) [58]
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.
Usługę bez zapewnienia parametrów transmisji (ang. Best Effort)
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.
Żą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.
| 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ę.
| 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.