1. Wstęp
Powszechnie zauważalna staje się tendencja zmiany oblicza protokołu IP. Zmiany te prowadzą Internet w stronę silnie skomercjalizowanej sieci globalnej. Wśród dynamicznie rozwijających się usług internetowych wyróżnić możemy: telefonię IP, usługi bankowe (home banking), edukacyjne (home education), transmisję sygnałów radiowych i telewizyjnych (Internet broadcasting) oraz wideo na żądanie (video on demand). Nowo wprowadzone aplikacje wymagające utrzymania wartości parametrów jakościowych na określonym poziomie to aplikacje transmitujące dźwięk i obraz w czasie rzeczywistym oraz aplikacje przesyłające dane, dla których dostarczenia wymagane jest małe opóźnienie. Komercjalizacja niesie ze sobą konieczność wdrożenia mechanizmów umożliwiających zróżnicowanie obsługi pakietów w zależności od potrzeb. Czynnik ekonomiczny w przypadku budowy nowych sieci IP należy uznać za decydujący, ponieważ rozwój infrastruktury sieci wymaga ogromnych inwestycji.
Obecna generacja sieci Internet bazuje na protokole IPv4 (Internet Protocol) i realizuje przekaz pakietów na zasadzie best-effort, co nie zapewnia żadnej jakości obsługi. Oznacza to, że sposób obsługi pakietów zależy od obecnie istniejących warunków ruchowych, nie zależy natomiast od rodzaju aplikacji generujących pakiety. Dodatkowo sieć nie realizuje żadnej polityki przyjmowania lub odrzucania nowych połączeń, zaś sterowanie liczbą pakietów napływających do sieci jest przeniesione do użytkownika.
Pojawia się potrzeba stworzenia zintegrowanej sieci, która umożliwiłaby przesyłanie pakietów pochodzących z aplikacji o różnych wymaganiach jakości obsługi QoS (Quality of Service), gdyż dotychczasowy sposób obsługi stał się niewystarczający. Zapewnienie wielousługowego charakteru sieci IP i stworzenie sieci QoS IP wymaga wprowadzenia zróżnicowanych usług sieciowych, podobnie jak ma to miejsce w sieci ATM (Asynchronous Transfer Mode). Usługi te powinny różnić się pomiędzy sobą takimi parametrami jak: dostępne pasmo, maksymalne opóźnienie, zmienność opóźnienia, poziom strat pakietów, stopa błędów. Żądany poziom obsługi może być zapewniony poprzez działania w wielu płaszczyznach. Mają na niego wpływ: ruting, algorytmy szeregowania i zarządzania kolejkami w węzłach, funkcje przyjmowania nowych zgłoszeń i sterowania ruchem.
Aby sprostać tym wymaganiom organizacja IETF (Internet Engineering Task Force) zaproponowała techniki - IntServ (Integrated Services), DiffServ (Differentiated Services) mające na celu poprawę jakości obsługi w sieci Internet oraz standard MPLS (Multi Protocol Label Switching) umożliwiający usprawnienie transportu pakietów IP w warstwach 2 i 3. Pierwsza z nich oparta jest o model rezerwacji zasobów i dzięki wprowadzeniu protokołu RSVP (Resorce Reservation Protocol) umożliwia zestawianie w sieci połączeń o wymaganych parametrach jakościowych. Wiąże się to jednak ze znacznym skomplikowaniem architektury węzłów. Alternatywnym rozwiązaniem jest architektura DiffServ, znacznie uproszczona w stosunku do architektury IntServ. Zamiast traktować każde połączenie w sieci oddzielnie, agreguje ona strumienie danych w odpowiednie dla nich klasy. Dopiero klasom przypisany jest określony poziom jakości obsługi.
Zaproponowana przez IETF technika MPLS to zupełnie nowe podejście do komutacji pakietów. Istotą tej techniki jest dołączanie do każdego pakietu krótkiej etykiety w urządzeniu - ruterze brzegowym domeny MPLS. Wewnątrz domeny MPLS dołączone do pakietów etykiety służą do podejmowania decyzji, dokąd kierować pakiet. Mimo, iż MPLS zawiera pewne mechanizmy QoS, to jednak głównym zadaniem tej techniki jest poprawa skalowalności sieci IP dzięki ulepszonej inżynierii obsługi ruchu.
Celem pracy jest przedstawienie i analiza standardów wspierających jakość usług w sieciach IP. Przedstawiono najistotniejsze cechy modeli IntServ, DiffServ oraz MPLS pod względem zapewnienia jakości usług w relacji od końca do końca (end-to-end). Nieco uwagi poświęcono możliwościom praktycznego zastosowania tych technik w różnych obszarach sieci oraz zagadnieniom ich współpracy.
Decydujące znaczenie w ocenie wydajności działania mechanizmów zapewniających odpowiednią jakość usług QoS mają pomiary w istniejącej sieci. W pracy zaprezentowano koncepcję systemu pomiarowego służącego do monitorowania parametrów QoS realizowanych usług sieciowych jako istotny element utrzymania sieci. W pracy zawarto opis wzajemnych relacji pomiędzy Dostawcą Usług a Klientem; punktów pomiarowych; metryk QoS; metodologii pomiarowej oraz prezentacji wyników pomiarowych.
2. Protokół TCP/IP
Zestaw protokołów TCP/IP pozwala na komunikowanie się komputerów różnej mocy obliczeniowej, pochodzących od różnych producentów i pracujących pod kontrolą różnych systemów operacyjnych. Jest to zdumiewające zjawisko, ponieważ wykorzystanie TCP/IP znacznie przekroczyło zakładany na początku zakres zastosowań. To, co pod koniec lat 60 rozpoczęto jako finansowany przez rząd projekt badawczy zmierzający do opracowania sieci pakietowej, w latach 90 zmieniło się w powszechnie używaną formę sieci łączącej miliony komputerów. Jest to naprawdę system otwarty, ponieważ zestaw protokołów i jego kolejne implementacje są w prawie niezmienionej formie powszechnie dostępne w sieci, bezpłatnie lub za niewielką opłatą. Podstawą tego, co powszechnie nazywane jest światowym Internetem lub po prostu Internetem, jest globalna sieć WAN (Wide Area Network), w której pracują miliony komputerów.
2.1. Warstwy sieci
Protokoły sieciowe opracowywane są zwykle z uwzględnieniem warstwowego modelu sieci, w którym kolejne warstwy odpowiedzialne są za różne aspekty komunikacji. Zestaw protokołów, taki jak TCP/IP, jest kombinacją różnych protokołów działających w kilku warstwach. Zestaw protokołów TCP/IP rozważa się zwykle jako system czterowarstwowy, jak pokazano na rysunku 2.1. [1].
Rysunek 2.1. Cztery warstwy protokołów TCP/IP
Każda z tych warstw odpowiedzialna jest, za co innego:
Warstwa łącza, nazywana czasami warstwą łącza danych lub warstwą dostępu do sieci, zawiera zwykle programy obsługi urządzeń wchodzące w skład systemu operacyjnego i odpowiadające im karty interfejsów sieciowych w komputerze. Razem tworzą one zestaw obsługujący wszystkie sprzętowe szczegóły związane z fizycznym dołączeniem komputera do kabla sieciowego (lub innych mediów, jakie zostały użyte do budowy sieci komputerowej).
Warstwa sieci nazywana czasami warstwą Internetu obsługuje ruch pakietów w sieci. W tym miejscu następuje na przykład ruting pakietów. W zestawie protokołów TCP/IP warstwę tę tworzą: IP (Internet Protocol), ICMP (Internet Control Message Protocol) i IGMP (Internet Group Management Protocol).
Warstwa transportowa zapewnia przepływ danych pomiędzy dwoma hostami, obsługując znajdującą się nad nią warstwę aplikacji. W skład TCP/IP wchodzą dwa całkowicie różne protokoły warstwy transportowej: TCP (Transmission Control Protocol) i UDP (User Datagram Protocol). Protokół TCP zapewnia niezawodny przepływ danych pomiędzy dwoma hostami. Zajmuje się takimi funkcjami, jak dzielenie danych przekazywanych mu przez aplikacje na kawałki wielkości odpowiadającej warstwie sieci znajdującej się poniżej. Ponadto potwierdza on odebranie pakietów, określa czasy pozwalające hostowi, z którym następuje wymiana danych, na potwierdzenie ich odbioru i tak dalej. Ponieważ warstwa transportowa zapewnia niezawodny przepływ danych, warstwa aplikacji nie musi już się tym zajmować. Z drugiej strony, protokół UDP umożliwia znacznie prostsze usługi dla warstwy aplikacji. Przesyła między hostami pakiety danych, zwane datagramami, nie gwarantując jednak, że dotrą one do punktu przeznaczenia. W tym przypadku, jeśli żądany jest jakiś poziom niezawodności przesyłania danych, to musi go zapewnić warstwa aplikacji.
Warstwa aplikacji obsługuje funkcje związane z określoną aplikacją korzystającą z sieci. Istnieje wiele aplikacji TCP/IP, które dostępne są w prawie każdej implementacji:
Telnet pozwalający na zdalne zalogowanie się do systemu,
FTP (File Transfer Protocol) protokół transmisji plików,
SMTP (Simple Mail Transfer Protocol) protokół obsługujący pocztę elektroniczną,
SNMP (Simple Network Management Protocol) protokół zarządzania siecią.
2.2. Skład TCP/IP
W zestawie protokołów TCP/IP jest wiele innych protokołów poza tymi, które występują w nazwie. Na rysunku 2.2. przedstawiono kilka innych protokołów wchodzących w skład TCP/IP [1].
TCP (Transmission Control Protocol) i UDP (User Datagram Protocol) są dwoma dominującymi protokołami warstwy transportowej. Obydwa używają IP jako protokołu warstwy sieci. TCP zapewnia niezawodne usługi warstwy transportowej, chociaż posługuje się IP, który nie gwarantuje niezawodności. UDP wysyła i odbiera datagramy przekazywane z aplikacji. Datagram jest jednostką informacji (tzn. określoną przez wysyłającego liczbą bajtów informacji), która przesyłana jest od nadawcy do odbiorcy. Jednakże w przeciwieństwie do TCP, UDP nie jest usługą niezawodną. Nie ma żadnej gwarancji, że wysłany datagram kiedykolwiek dotrze do celu.
Rysunek 2.2. Różne protokoły wchodzące w skład TCP/IP z podziałem na warstwy, w których pracują
IP jest podstawowym protokołem warstwy sieci. Używany jest on zarówno przez TCP, jak i przez UDP. Każdy segment danych TCP i UDP, który przysyłany jest przez sieć, musi przejść przez warstwę IP zarówno w systemach końcowych, jak i w ruterach pośrednich. Na rysunku 2.2. pokazana jest również aplikacja mająca bezpośredni dostęp do IP. Jest to rozwiązanie możliwe do zrealizowania, choć rzadko stosowane.
ICMP jest protokołem dodatkowym dla IP. Używany jest przez warstwę IP do wymiany komunikatów o błędach i innych ważnych informacji z warstwą IP na innym hoście lub ruterze. Choć ICMP używany jest głównie przez IP, to możliwe jest posługiwanie się nim z poziomu aplikacji (programy diagnostyczne Ping i Traceroute).
Protokół IGMP (Internet Group Management Protocol) jest używany przy multicastingu: wysyłaniu datagramów UDP do wielu hostów równocześnie.
ARP (Address Resolution Protocol) i RARP (Reverse Address Resolution Protocol) są specjalizowanymi protokołami, używanymi tylko z niektórymi rodzajami interfejsów sieciowych (takimi jak Ethernet i token ring), zapewniającymi konwersję pomiędzy adresami warstwy IP a adresami interfejsu sieciowego.
2.3. Protokół IP (Internet Protocol)
IP jest podstawowym protokołem w zestawie TCP/IP. Wszystkie dane z TCP, UDP, ICMP i IGMP przesyłane są przez datagramy IP rysunek 2.3. IP świadczy zawodne, bezpołączeniowe usługi dostarczania pakietów.
Poprzez słowo zawodne (unreliable) rozumiemy to, że nie ma żadnej gwarancji na pomyślne dostarczenie datagramu IP do punktu przeznaczenia. IP stara się jedynie dobrze przesłać datagramy. Kiedy jednak coś się nie uda, na przykład wystąpi przepełnienie buforów rutera, IP uruchamia bardzo prosty algorytm obsługi błędów: usuwa datagram i próbuje wysłać do źródła wiadomość ICMP. Wszelkie wymagane mechanizmy niezawodności transmisji muszą być zapewnia ne przez wyższe warstwy (np. TCP).
Określenie bezpołączeniowy oznacza, że IP nie zachowuje żadnej informacji o datagramach, które zostały przesłane pomyślnie. Każdy datagram obsługiwany jest niezależnie od pozostałych. Oznacza to również, że datagramy IP mogą docierać do punktu przeznaczenia w innej kolejności niż zostały wysłane. Jeśli nadawca wysyła dwa kolejne datagramy (najpierw A, potem B) do tego samego punktu przeznaczenia, każdy z nich rutowany jest niezależnie i może być przesłany inną trasą, w wyniku czego B może dotrzeć przed A.
2.3.1. Nagłówek IPv4
Obecnie używaną wersją protokołu jest wersja 4, dlatego czasem IP nazywany jest IPv4. Oficjalną specyfikacją IP jest dokument [4]. Na rysunku 2.3. pokazano format datagramu IP. Typowym rozmiarem nagłówka IP jest 20 bajtów, chyba, że umieszczone są w nim dodatkowe opcje.
Rysunek 2.3. Datagram IPv4 z uwzględnieniem pól tworzących nagłówek IP
Przedstawienie cech, możliwości i sposobu działania protokołu IP najłatwiej przedstawić omawiając kolejno znaczenie i zastosowanie poszczególnych elementów struktury danych, jaką stanowi nagłówek protokołu.
Adres źródłowy i docelowy
Wszystkie urządzenia pracujące wewnątrz sieci IP identyfikowane są poprzez unikatowy 32 bitowy adres IP. Wysyłając datagram nadawca umieszcza we właściwych polach adresy IP: swój i odbiorcy oraz dysponując wiedzą z tabeli rutingu wysyła datagram do rutera najwłaściwszego z punktu widzenia lokalizacji adresu odbiorcy. W przypadku sieci lokalnej typu ethernet datagram o adresie docelowym IP „lokalnym” dla danej sieci jest wysyłany bezpośrednio do żądanego komputera, zaś datagramy o innych adresach docelowych są kierowane do rutera - bramki. Zawartość obu pól adresowych nie jest zmieniana w trakcie przesyłania informacji. Sprawia to, że kolejny router wie, kto jest nadawcą informacji oraz gdzie powinna ona dotrzeć, lecz nieznana jest mu dotychczasowa trasa pakietu w sieci (adresy ruterów, które przesyłały datagram). W ten sposób informacja o sposobie dobierania trasy jest silnie rozproszona. Pole adres źródłowy nie odgrywa w procesie dostarczania datagramu istotnej roli, wykorzystywane jest dopiero przez odbiorcę do identyfikowania nadawcy wiadomości.
Czas życia datagramu (TTL)
Ponieważ jak opisano powyżej proces wybierania trasy datagramu zależy w dużej mierze od sprawności działania wszystkich węzłów pośredniczących, możliwe jest, że w sytuacjach awaryjnych pakiet będzie krążył pomiędzy ruterami bardzo długo, lub wręcz trasa jego przesyłania zostanie zapętlona. Pole TTL (Time-To-Live) zapobiega takiej sytuacji - jego zawartość jest wstępnie inicjowana przez nadawcę i dekrementowana przez każdy z węzłów, który przesyła datagram. Gdy jego wartość wyniesie 0, datagram zostaje usunięty, a do nadawcy wysyłany jest komunikat ICMP o błędzie.
Protokół przesyłający dane
Immanentną cechą enkapsulacji danych przez protokoły warstwowe jest fakt, iż najważniejszym zadaniem protokołu warstwy niższej jest dostarczanie danych dla warstwy wyższej. Choć powszechnie używa się akronimu TCP/IP, protokół sieciowy IP, oprócz danych warstwy TCP przenosi również dane protokołu transportowego UDP oraz dane sygnalizacyjne protokołów ICMP i IGMP (które uznane są za element protokołu IP choć stanowią de facto warstwę wyższą). Aby rozróżnić rodzaj przesyłanych w datagramie informacji nadawca umieszcza w tym polu nagłówka liczbę reprezentującą zestandaryzowane oznaczenie protokołu przesyłanych informacji. Pole to może zostać również użyte przez rutery do traktowania z wyższym priorytetem wiadomości sygnalizacyjnych ICMP.
Suma kontrolna nagłówka
Pole to zabezpiecza integralność informacji przesyłanych tylko w nagłówku datagramu. Z reguły jednak warstwy łącza danych (np. MAC w ethernecie, PPP w połączeniu modemowym) sprawdzają poprawność całej przesyłanej informacji, dodatkowo zaś dane mogą być jeszcze zabezpieczane przed przekłamaniem przez warstwy wyższe.
Identyfikacja
Pole to jest unikalnym numerem, który identyfikuje w sposób jednoznaczny datagram wysyłany z danego hosta. Szesnastobitowa wartość tego pola (65 536 możliwości) w połączeniu z mechanizmem TTL gwarantują, że w danej chwili w sieci nie będą nigdy istniały dwa identyczne pakiety.
Wersja protokołu
Pole to oznacza wprost numer używanego protokołu IP obecnie używana wersja to 4, w przyszłości zastąpi ją IPv6.
Długość nagłówka
Liczba 32-bitowych słów umieszczonych w nagłówku wraz z opcjami tworzy długość nagłówka. Typowa (minimalna) długość nagłówka wynosi 5. Liczba ta informuje komputer odbierający, kiedy ma zakończyć czytanie nagłówka i rozpocząć czytanie danych.
Całkowita długość pakietu
Wielkość ta, pomniejszona o rozmiar nagłówka wyznacza rozmiar pola danych enkanpsulowanych przez datagram. Jego teoretyczny rozmiar sięga, co prawda wartości 64kB, jednak w praktyce ze względu na ograniczenia interfejsów fizycznych długość datagramu nigdy nie przekracza wartości tzw. MTU (Maximum Transmission Unit), zaś w wielu przypadkach ze względu na różnice w wielkości największego dopuszczalnego pakietu konieczna jest segmentacja datagramu (podział na kilka pakietów).
Typ usługi TOS
W założeniach, protokół IP posiadać miał pewne elementy mechanizmów sterowania przepływem, których celem jest zapewnienie gradacji poziomu jakości usługi sieciowej (QoS). W tym celu pole TOS zawiera 3 bitowy wskaźnik priorytetu przesyłania pakietu oraz trzy flagi zalecanego doboru trasy, które mogą być używane do określania parametrów pierwszeństwa, opóźnienia, przepustowości i niezawodności tego pakietu. Niestety, obecne implementacje nie używają żadnego z tych pól (tzn. pola te są z reguły ustawiane, lecz elementy komutacyjne sieci - rutery ignorują je). Ponieważ transmitowanie informacji przez sieć odbywa się na poziomie sieciowym, utracono w ten sposób możliwość efektywnego i zestandardyzowanego sterowania przepływem na poziomie IP. Istniejące rozwiązania posługują się na ogół informacjami zasięgniętymi z nagłówka TCP w celu rozpoznania rodzaju przesyłanej usługi.
Znaczniki
Pole zawiera 3 bity. Pierwszy jest zawsze zerem. Drugi bit określa czy można (wartość 1), czy też nie można (wartość 0) fragmentować datagram. Natomiast ostatni bit służy do identyfikacji ostatniego fragmentu składającego się na pierwotny datagram. Wartość 0 określa ostatni, a wartość 1 oznacza kolejny fragment.
Przesunięcie fragmentacji
Pole to zawiera 13 bitów, wskazuje, którą częścią całości pierwotnego datagramu jest dany fragment. Poszczególne fragmenty mają pola danych o długości będącej wielokrotnością 8 bitów. Wyjątkiem jest ostatni fragment, którego długość wynika z długości pierwotnego datagramu. W polu tym podaje się o ile zawartość fragmentu jest przesunięta w stosunku do początku pola danych pierwotnego datagramu.
Opcje
To pole nagłówka o zmiennej długości w zamierzeniach autorów umożliwiało uzyskanie między innymi następujących funkcji:
ograniczenia dotyczące bezpieczeństwa;
zapisu trasy podróży przez sieć;
zapisu czasu wyjścia datagramu z danego węzła sieci (router);
ustalenie swobodnej trasy rutowania - lista węzłów przez które datagram musi przejść (pomiędzy nimi droga może być wybierana dowolnie);
ustalenie dokładnej trasy rutowania - datagram nie może przejść inną drogą niż wskazaną na liście.
Możliwości pola opcje otwierają pewną drogę do wsparcia zastosowań wymagających utrzymywania w miarę stałych i powtarzalnych parametrów opóźnień i przepustowości sieci. W praktyce jednak ze względu na powszechne ignorowanie tej opcji przez rutery oraz zbyt małą dopuszczalną długość tego pola w stosunku do ilości punktów przeskoku na typowej trasie połączenia internetowego, nie można wpływać na sposób przesyłania informacji.
2.3.2. Nagłówek IPv6
Proponowany protokół IPv6 zachowuje wiele cech, które przyczyniły się do sukcesu IPv4. W rzeczywistości konstruktorzy scharakteryzowali IPv6 jako IPv4 z kilkoma modyfikacjami.
Jak widać na rysunku 2.4. datagram IP ma nagłówek podstawowy o ustalonym rozmiarze, po którym następuje zero lub więcej nagłówków dodatkowych poprzedzających dane [38].
Rysunek 2.4. Ogólna postać datagramu IPv6 z wieloma nagłówkami
Format nagłówka podstawowego
Pomimo tego, że nagłówek podstawowy IPv6 musi obsługiwać większe adresy, to zawiera on mniej informacji niż nagłówek datagramu IPv4. Opcje i niektóre z ustalonych pól, które pojawiają się w nagłówku datagramu IPv4, zostały w IPv6 przeniesione do nagłówków dodatkowych. W ogólności zmiany w nagłówku datagramu odpowiadają zmianom w samym protokole [38]:
wyrównywanie do 32-bitów zostało zmienione na wyrównywanie do 64-bitów,
pole długości nagłówka zostało wyeliminowane, a pole długości datagramu zastąpiono polem długość zawartości,
rozmiar pól adresów nadawcy i odbiorcy został zwiększony do 16 oktetów,
informacje o fragmentacji zostały przeniesione z pól stałych w nagłówku podstawowym do nagłówka dodatkowego,
pole czas życia zostało zastąpione polem liczba etapów,
pole typ obsługi zastąpiono polem etykiety potoku,
pole protokół zostało zastąpione polem, które określa typ następnego nagłówka.
Na rysunku 2.5. są pokazane zawartość i format nagłówka podstawowego IPv6. Kilka pól tego nagłówka odpowiada bezpośrednio polom w nagłówku IPv4. Tak jak w IPv4, początkowe 4-bitowe pole wersja służy do określenia wersji protokołu w datagramie IPv6, zawiera ono zawsze 6. Podobnie jak w IPv4 pola adres nadawcy i adres odbiorcy zawierają adresy wysyłającego i odbierającego. Jednak w IPv6 na każdy z tych adresów zużywa się 16 oktetów. Pole liczba etapów odpowiada polu czas życia w IPv4. Inaczej niż IPv4, które traktuje czas życia jak kombinację liczby etapów oraz maksymalnego czasu podróży, IPv6 interpretuje tę wartość jako ścisłe ograniczenie maksymalnej liczby etapów, jaką może datagram wykonać zanim zostanie usunięty.
Rysunek 2.5. Format 40-oktetowego nagłówka podstawowego IPv6. Każdy datagram IPv6 rozpoczyna się od takiego nagłówka
IPv6 używa nowego sposobu specyfikacji długości datagramu. Po pierwsze, ponieważ rozmiar nagłówka podstawowego wynosi 40 oktetów, nie zawiera on pola odpowiedzialnego za długość nagłówka. Po drugie w IPv6 pole długości datagramu jest zastąpione 16-bitowym polem długość zawartości, które służy do określenia liczby oktetów przenoszonych w datagramie, nie licząc oktetów nagłówka. Dzięki temu datagram może zawierać 64 kilo-otetów danych.
IPv6 oferuje nowy mechanizm, który umożliwia rezerwację zasobów i pozwala ruterowi na wiązanie każdego datagramu z podaną rezerwacją zasobów. Wykorzystywane jest do tego pojęcie potoku oznaczające ścieżkę poprzez intersieć, na której pośrednie rutery gwarantują określoną jakość obsługi. Przykładowo dwa programy, które chcą przesyłać obrazy mogą ustanowić potok, w ramach, którego są gwarantowane określona przepustowość i opóźnienie. Alternatywnie usługodawca sieciowy może wymagać od swojego klienta, aby ten określił potrzebną mu jakość usługi, a następnie używać potoków do ograniczania ruchu generowanego przez dany komputer czy program użytkowy.
Pole etykieta potoku w nagłówku podstawowym zawiera informacje, których rutery używają do wiązania datagramu z odpowiednim potokiem informacji oraz priorytetem. Pole to jest podzielone na dwa podpola, które widać na rysunku 2.6.
Rysunek 2.6. Dwa podpola pola ”etykieta potoku”. Każdy datagram IPv6 zawiera etykietę potoku, która może być używana do wiązania datagramu z określonym rodzajem obsługi
W etykiecie potoku 4-bitowe pole klasa ruchu służy do określenia, jaką klasą ma podróżować datagram. Wartości od 0 do 7 są używane do określania wrażliwości na czasy dla ruchu kontrolowanego potokami, a wartości od 8 do 15 określają priorytet ruchu poza nimi. Pozostałe 24 bity zawierają identyfikator potoku.
Podsumowując, datagram IPv6 zaczyna się od 40-oktetowego nagłówka podstawowego, który zawiera pola adresów nadawcy i odbiorcy, maksymalnej liczby etapów, etykiety potoku oraz typu następnego nagłówka. Wobec tego datagram IPv6 oprócz danych musi zawierać, co najmniej 40 oktetów.
2.4. Protokół TCP (Transmission Control Protocol)
TCP jest protokołem działającym w warstwie transportowej, wykorzystując warstwę sieci IP dostarcza usług aplikacjom. Obecna wersja TCP jest oficjalnie zdefiniowana w RFC 793 [3], od tego czasu dodano wiele rozszerzeń, które udokumentowano w odpowiednich dokumentach RFC.
TCP zapewnia zorientowaną połączeniowo, niezawodną obsługę ciągów przesyłanych bajtów. Połączeniowość oznacza, że dwie aplikacje używające tego protokołu muszą przed rozpoczęciem wymiany danych nawiązać ze sobą połączenie [1].
Protokół TCP zapewnia niezawodność poprzez:
Dane przekazywane przez aplikację są dzielone na fragmenty, które według TCP mają najlepszy do przesłania rozmiar. Jest to podejście całkowicie inne niż w UDP, w którym datagram generowany był na podstawie przekazanego przez aplikację komunikatu. Jednostka informacji przekazywana przez TCP do IP nazywana jest segmentem.
Kiedy TCP wysyła segment, to jednocześnie uruchamia zegar, który rozpoczyna oczekiwanie na potwierdzenie odebrania segmentu przez drugą stronę. Jeśli potwierdzenie nie nadejdzie w określonym czasie, segment wysyłany jest powtórnie.
Kiedy TCP odbiera dane nadesłane przez drugą stronę połączenia, wysyła wtedy potwierdzenie odbioru. Potwierdzenie to nie jest wysyłane natychmiast, tylko po odczekaniu zwykle kilku sekund.
TCP posługuje się sumami kontrolnymi nagłówka datagramu i danych. Jest to suma typu end-to-end, której zadaniem jest wykrycie każdej modyfikacji danych w czasie ich przesyłania. Jeśli segment zostanie nadesłany z niepoprawną sumą kontrolną, TCP odrzuca go i nie potwierdza odbioru. (Spodziewa się, że wysyłający prześle go po raz kolejny, po odczekaniu założonego czasu).
Ponieważ segmenty TCP są przesyłane jako datagramy IP, które mogą być nadsyłane w dowolnej kolejności, to segmenty TCP również mogą nadchodzić w innej kolejności niż zostały wysłane. Strona odbierająca segmenty TCP porządkuje je, jeśli zachodzi taka konieczność, i przekazuje do aplikacji.
Ponieważ datagramy IP mogą być powielane, odbiorca TCP musi umieć odrzucić zdublowane dane.
Ponadto TCP zapewnia kontrolę przepływu. Każdy z końców połączenia TCP ma przestrzeń buforową o skończonej wielkości. Strona odbierająca TCP pozwala stronie nadającej na wysłanie tylko takiej ilości danych, która może być umieszczona w buforze odbiorcy. Taki mechanizm zapobiega przeładowaniu bufora w hoście wolnym przez datagramy wysyłane z hosta szybszego.
2.4.1. Nagłówek TCP
Dane TCP umieszczane są w datagramach IP w sposób pokazany na rysunku 2.7.
Rysunek 2.7. Enkapsulacja danych TCP w datagramie IP
Rysunek 2.8. Format nagłówka TCP
Znaczenie poszczególnych pól jest następujące[3]:
Numer portu źródłowego, docelowego
Pola te identyfikują aplikacje wysyłającą i odbierającą dane. Te dwie wielkości wraz adresami IP źródła i przeznaczenia umieszczonymi w nagłówku IP, jednoznacznie identyfikują każde połączenie. Kombinacja IP i numeru portu jest czasem nazywana gniazdem.
Numer sekwencyjny
Pole to zwiera numer sekwencyjny pierwszego bajtu danych w segmencie. Ta wartość określa pozycję segmentu w strumieniu bajtów. Podczas ustanawiania połączenia, jeśli bit SYN w polu znaczniki jest ustawiony na 1, w tym polu zawarty jest inicjujący numer sekwencyjny INS, od którego rozpoczyna numerację bajtów w połączeniu. Zatem pierwszy wysyłany bajt ma numer INS+1.
Numer potwierdzenia
Zawiera numer sekwencyjny następnego oczekiwanego bajtu po stronie odbiorczej. Jednocześnie jest to potwierdzenie poprawnego odbioru bajtów o numerach sekwencyjnych mniejszych od zawartego w tym polu. Potwierdzenia mówią nadawcy, ile bajtów danych zostało już poprawnie odebranych.
Długość nagłówka
Określa liczbę 32 bitowych słów w nagłówku segmentu TCP. Tym samym określone zostaje miejsce, w którym rozpoczynają się dane. Pole to ma określone znaczenie tylko wtedy, gdy bit ACK=1.
Bity znaczników
Pole to zawiera 6 flag 1 - bitowych :
URG - wskaźnik ważności pola wskaźnika przynaglającego;
ACK - wskaźnik ważności pola numer potwierdzenia;
PSH - odbiorca powinien jak najszybciej przesłać dane do aplikacji;
RST - restart połączenia;
SYN - synchronizacja numerów sekwencyjnych w celu inicjalizacji połączenia;
FIN - zakończenie wysyłania danych.
Rozmiar okna
Określa liczbę bajtów, jaką może jeszcze zaakceptować odbiorczy moduł TCP.
Suma kontrolna
Pole to jest 16 bitowym jedynkowym uzupełnieniem jedynkowo uzupełnionej sumy wszystkich 16 bitowych słów w segmencie. Ta suma kontrolna obejmuje zarówno nagłówek jak i dane.
Wskaźnik ważności
Brany pod uwagę przy ustawieniu bitu URG. Pole to zawiera numer sekwencyjny bajtu następującego po pilnych danych.
Opcje
Pole to ma długość zmienną będącą wielokrotnością 8 bitów. Dla protokołu TCP zdefiniowano trzy opcje: 0 - koniec listy opcji, 1 - brak działania, 2 - maksymalna długość segmentu.
3. Definicje i podział parametrów jakości
Obecna generacja sieci Internet bazuje na protokole IPv.4 i realizuje przekaz pakietów na zasadzie best-effort (najlepszego osiągnięcia) bez gwarancji jakości usługi. Sieć ta nie realizuje żadnej polityki przyjmowania / odrzucania nowych połączeń, zaś sterowanie liczbą pakietów napływających do sieci jest przeniesione do użytkownika. De facto, mechanizmy zaimplementowane w protokole TCP (takie jak mechanizm wolnego startu oraz unikania przeciążenia) mają na celu jedynie dostosowanie szybkości wysyłania pakietów do sieci do aktualnie obserwowanych warunków ruchowych.
Rozszerzenie sieci IP na sieć wielousługową gwarantującą odpowiednią jakość przekazu pakietów, tzw. sieć QoS IP (Quality of Service Internet Protocol), wymaga zdefiniowania nowych usług sieciowych, w pewnym sensie wzorowanych na usługach oferowanych w sieciach ATM. Ogólnie, usługi te powinny różnić się pomiędzy sobą możliwością zapewnienia różnych poziomów strat pakietów czy też dopuszczalnymi oferowanymi wartościami opóźnienia przekazu danych.
Zapewnienie odpowiedniej jakości przekazu przez sieć IP wymaga, podobnie jak to uczyniono w sieci ATM, zdefiniowania odpowiednich funkcji realizujących QoS. Postępując w tym duchu należy:
Zdefiniować klasy usług sieciowych wraz z mechanizmami zapewniającymi sterowanie ruchem; ogólnie mechanizmy takie mogą być zaimplementowane w każdym węźle (w tym przypadku w ruterze IP);
Określić zasoby sieci przynależne danej usłudze sieciowej; w przypadku sieci pakietowej należy dla danej usługi sieciowej przydzielić odpowiednią przepustowość na każdym łączu wyjściowym wraz z buforem dla gromadzenia pakietów powodujących chwilowe przeciążenia;
W ruterze IP powinny być również zaimplementowane mechanizmy pozwalające rozróżniać pakiety według ich przynależności do danej usługi sieciowej;
Zdefiniować dla każdej z usług sieciowych tzw. parametry QoS, określającą jakość obsługi odbieraną na poziomie wywołania i na poziomie pakietów;
Zdefiniować funkcję realizującą przyjmowanie / odrzucanie nowych wywołań;
Zdefiniować parametry połączenia, zgłaszane w fazie zestawiania połączenia i dotyczące charakterystyki oferowanego ruchu; zwykle są one podawane w formie parametrów tzw. Token-Bucket'u;
Nie dopuszczać do sieci ruchu, który nie jest zgodny z kontraktem ruchowym.
W sieci QoS IP powyższe mechanizmy muszą być zdefiniowane. Należy nadmienić, iż implementacja efektywnych mechanizmów QoS w sieci IP jest szczególnie trudna, co wynika z faktu, iż sieć ta nie realizuje połączeń wirtualnych (jak to ma miejsce w sieci ATM) oraz długość przesyłanych pakietów jest zmienna.
Rozdział ten omawia obecny stan zaawansowania prac w kierunku stworzenia nowej generacji sieci Internet, tj. sieci z zaimplementowanymi mechanizmami QoS.
3.1. Terminologia
Najczęściej używane terminy związane z jakością usług to:
QoS (Ouality of Service) - jakość usługi;
CoS (Class of Service) - klasa usług;
GoS (Grade of Service) - kategoria usług;
SLA (Service Level Agreement) - kontrakt pomiędzy użytkownikiem a operatorem;
SLS (Service Level Specificafion) - uzgodniony pomiędzy operatorem a klientem zbiór parametrów sieciowych i ich wartości związany ze świadczoną usługą;
TCA (Traffic Conditioning Agreement) - porozumienie określające reguły klasyfikowania pakietów oraz profile ruchu;
TCS (Traffic Conditioning Specification) - określony zbiór parametrów technicznych i ich wartości związanych z TCA.
Niestety pojęcia te są często mylone i używane niewłaściwie. Konieczne, więc wydaje się ich uporządkowanie.
Najwięcej nieporozumień wiąże się z pojęciem jakości usług (QoS). Termin ten jest używany w różnym znaczeniu, w zależności od kontekstu. Często zapewnienie jakości usługi jest nie słusznie utożsamiane przez użytkownika jedynie z uzyskaniem zadowalającej jakości obrazu, dźwięku czy krótkiego czasu przesyłania danych, co jest dużym uproszczeniem. Jednak takimi kryteriami posługuje się zwykle odbiorca usługi. Z drugiej strony dla jej dostawcy istotne jest uzyskanie wysokiej oceny użytkownika. W tym celu dostawca musi zapewnić kanał transmisyjny spełniający określone wymagania, które bezpośrednio przekładają się na zbiór parametrów sieciowych. W każdym z tych dwóch podejść jest trochę racji. Konieczne jest jednak ustalenie spójnej terminologii obejmującej oba podejścia. W książce [5] poświęconej jakości usług wyróżniono trzy podstawowe pojęcia:
zadana jakość usług (intrinsic QoS),
postrzegana jakość usług (perceived QoS),
oceniana jakość usług (assessed QoS).
Przez zadaną jakość usługi rozumie się jej cechy ściśle związane z aspektami technicznymi, począwszy od zastosowanego łącza fizycznego, skończywszy na protokołach transmisyjnych i zastosowanych mechanizmach zapewniających określoną jakość. W tym kontekście jakość usługi (QoS) oznacza zbiór wymagań związanych z daną usługą. Powinny one być spełnione podczas przesyłania przez sieć strumienia danych w ramach tej usługi [6]. W praktyce jest to zbiór parametrów sieciowych, wymaganych do przesyłania strumienia danych. Przez zapewnienie jakości usługi (zapewnienie QoS) należy rozumieć przesłanie strumienia danych z zapewnieniem określonych wartości tych parametrów w relacji od końca do końca (od dostawcy do odbiorcy usługi). W zależności od rodzaju usługi dostawca definiuje wartości tych parametrów.
Z postrzeganą jakością usługi mamy do czynienia wtedy, gdy użytkownik korzysta z tej usługi. Na wrażenia, jakie on odnosi, mają wpływ jego oczekiwania, doświadczenia z podobną usługą świadczoną przez innego operatora, opinie innych użytkowników czy też środowisko, w którym się znajduje. W związku z tym zapewnienie wysokiej wrodzonej jakości usługi nie daje jeszcze gwarancji, że będzie on usatysfakcjonowany. Samo zapewnienie parametrów sieciowych może być niewystarczające. Jeżeli bowiem korzystanie z usługi będzie niewygodne z powodu innych czynników, użytkownik odczuje niezadowolenie.
Z ocenianą jakością usługi mamy do czynienia w chwili, gdy użytkownik podejmuje decyzję, czy chce z niej korzystać, czy zrezygnować. Wpływ na to może mieć między innymi sposób, w jaki dostawca usługi reaguje na problemy i reklamacje użytkownika.
Podsumowując można stwierdzić, że zadana jakość usługi jest tym, co czyni ją atrakcyjną dla potencjalnego użytkownika. Postrzegana jakość usługi determinuje, czy użytkownik uzna ją za satysfakcjonującą, zaś oceniana jej jakość decyduje o ewentualnej kontynuacji bądź rezygnacji z korzystania z tej usługi. Łatwo zauważyć, że bezpośredni związek z projektowaniem sieci ma zadana jakość usług. Pozostałe dwa pojęcia są raczej związane z polityką marketingową operatora, a zapewnienie wysokiej jakości usług na tych poziomach należy do zadań marketingu, projektantów usług czy obsługi technicznej.
Pojęcie jakości usługi QoS jest często mylone z klasą usług (CoS). Klasa usług jest terminem bardziej ogólnym, opisującym zbiór cech charakterystycznych i właściwości określonej usługi lub zbioru usług [7]. Usługi należące do określonej klasy charakteryzują się gwarancją wybranych parametrów QoS. Zwykle określa się tylko, jakie parametry są gwarantowane w ramach danej klasy, bez określania ich konkretnych wartości. Przykładem mogą być, omówione dalszej części pracy, klasy usług w modelach IntServ i DiffServ. W literaturze spotyka się również termin poziom usług LoS (Level of Service). Jest on zwykle utożsamiany z klasą usług. Terminy te są stosowane zamiennie.
Kategoria usług GoS (Grade of Service) jest pojęciem szerszym niż QoS. Podział usług na kategorie - oprócz parametrów transmisyjnych - może uwzględniać wiele wymagań wysokiego poziomu, takich jak bezpieczeństwo, protekcja czy prawdopodobieństwo mechanicznego uszkodzenia łącza [8], [9]. Przykładowo, w dokumencie [10] zdefiniowano cztery kategorie usług: standardową, średniego poziomu bezpieczeństwa, wysokiego poziomu bezpieczeństwa oraz najwyższego poziomu bezpieczeństwa. Rozróżnienie uwzględnia możliwość stałego utrzymywania rozłącznej ścieżki zapasowej oraz poprowadzenie ścieżki podstawowej przez obszary o małym prawdopodobieństwie mechanicznego uszkodzenia łącza (np. obszary, na których nie występują trzęsienia ziemi). Omawiane kategorie usług zestawiono w tabeli 3.1.
Tabela 3.1. Przykładowe kategorie usług
Poziom bezpieczeństwa |
Utrzymanie stałej ścieżki zapasowej |
Ścieżka podstawowa poprowadzona przez łącza o małym prawdopodobieństwie uszkodzenia fizycznego |
Standardowy |
- |
- |
Średni |
- |
+ |
Wysoki |
+ |
- |
Najwyższy |
+ |
+ |
Service Level Agreement (SLA) jest to porozumienie pomiędzy klientem a dostawcą usługi. SLA musi określać w sposób zrozumiały dla klienta, czego może on oczekiwać w ramach danej usługi. Kontrakt taki powinien zawierać jasno określone sposoby oceny jakości otrzymywanej usługi, a więc zgodności dostarczonej usługi z zawartym kontraktem. Z drugiej strony konieczne jest kontrolowanie klienta, czy dotrzymuje warunków umowy oraz ustalenie zakresu odpowiedzialności za jej złamanie przez każdą ze stron. Ponadto SLA powinno definiować:
klasę dostarczanej usługi (CoS) lub wartości gwarantowanych parametrów jakościowych usługi (QoS),
dostępność usługi,
zakres gwarantowanej obsługi technicznej,
zasady naliczania i pobierania opłat.
Porozumienie SLA może również obejmować zbiór reguł wymuszania charakterystyk ruchu klienta w ramach świadczonej usługi (TCA). Na SLA składają się, więc zarówno parametry techniczne (sieciowe) danej usługi, jak również aspekty prawne, kwestie naliczania opłat, obsługa techniczna itp.
Service Level Specification (SLS) jest to zbiór parametrów technicznych o określonych wartościach, z jakimi będzie przesyłany przez sieć strumień pakietów związanych z daną usługą [11]. SLS obejmuje również zbiór reguł niezbędnych do zdefiniowania różnorodnych usług opartego na różnych parametrach i ich wartości. SLS jest techniczną częścią kontraktu SLA pomiędzy klientem a dostawcą usługi. Specyfikuje wartości parametrów sieciowych dostarczanej usługi. SLS wraz z aspektami prawnymi, ustaleniami dotyczącymi naliczania opłat czy obsługi technicznej składa się na SLA. Pojęcie SLS zostało wprowadzone w celu wyodrębnienia z SLA, będącego pojęciem szerokim, informacji ściśle technicznych.
W ramach IETF są prowadzone prace mające na celu precyzyjne zdefiniowanie SLS. Dyskutowane są dwie koncepcje. Jedna zakłada możliwość dynamicznego negocjowania parametrów SLS pomiędzy klientem i operatorem [12], druga zaś przewiduje opracowanie predefiniowanych typów SLS i zasad posługiwania się nimi, obowiązujących wszystkich operatorów [13]. Takie podejście ma na celu ułatwienie świadczenia usług za pośrednictwem kilku operatorów, uproszczenie procedur zarządzania i ułatwienie realizacji mechanizmów agregacji strumieni.
Traffic Conditioning Agreement (TCA) jest to porozumienie określające reguły klasyfikowania pakietów oraz profile ruchu odpowiednie dla różnych strumieni ruchu. TCA definiuje zasady oznaczania pakietów (marking), odrzucania pakietów (dropping), kształtowania ruchu (shaping) oraz wykonywania pomiarów ruchu (metering). Zbiór reguł formowania ruchu zdefiniowany w ramach TCA może stanowić część SLA [14]. Porozumienie TCA nakłada na klienta obowiązek dostosowania generowanego ruchu do uzgodnionego profilu ruchu. Określa również, w jaki sposób będą traktowane pakiety klienta zarówno w przypadku zgodności z profilem ruchu, jak i w przypadku naruszenia warunków umowy.
Traffic Conditioning Specification (TCS) jest to zbiór parametrów o określonych wartościach, który jednoznacznie określa profil ruchu oraz reguły klasyfikowania pakietów [11]. TCS jest pojęciem ściśle technicznym, podczas gdy TCA jest pojęciem szerszym, obejmującym oprócz TCS definicje poszczególnych usług i uzgodnienia z klientem. TCS jest integralną częścią SLS.
3.2. Wielkości opisujące QoS w IP
W środowisku IP jakość QoS może być scharakteryzowana między innymi przez następujący zbiór parametrów [15]:
Pojemność transmisyjna
Parametr ten opisuje, ile czasu potrzebuje sieć na przesłanie zadanej porcji informacji,
z pominięciem zagadnienia opóźnień. Tak zdefiniowany wskaźnik opisuje medium transmisyjne, z którego korzysta IP. Ponieważ sieć IP może być zbudowana z wykorzystaniem różnych technologii w warstwie łącza danych i różnych fizycznych łączy, pojemność transmisyjna jest różna w każdym kierunku. Dla każdych dwu sąsiadujących ze sobą węzłów w sieci oczkowej, jaką jest sieć IP, pojemność transmisyjna oferowana przez sieć pomiędzy tymi punktami jest równa szerokości pasma w łączu pomiędzy tymi węzłami. Oczywiste jest, że łącze 2 Mbit/s, zbudowane w oparciu o łączność satelitarną, kanał cyfrowy (SDH, PDH, itp.) czy linie miedziane wyposażone w modemy (HDSL), ma jednakową pojemność transmisyjną. Jednakże dla ścieżki łączącej dwa niesąsiadujące ze sobą węzły sieci określenie pojemności transmisyjnej jest znacznie bardziej złożone ze względu na współdzielenie łączy przez różne ścieżki. Ponieważ współdzielenie jest oparte na multipleksacji statystycznej, pojemność transmisyjna ścieżki nie jest wartością stałą. Jeżeli przyjąć założenie, że żadne łącze, z którego korzysta ścieżka, nie jest współdzielone, można powiedzieć, że pojemność transmisyjna jest równa najmniejszej pojemności transmisyjnej łącza składowego. Niektóre nowoczesne technologie wykorzystywane do budowy rozległych sieci IP, takie jak Frame Relay czy ATM, charakteryzują się pojemnością transmisyjną zmienną w czasie. Wynika to z zastosowania multipleksacji statystycznej w sieciach FR czy ATM. Łącze w którejś z tych technologii pomiędzy dwoma sąsiednimi węzłami sieci IP jest tak naprawdę ścieżką, wykorzystującą wiele łączy fizycznych pomiędzy węzłami sieci FR czy ATM. W bardzo wczesnej fazie istnienia sieci IP pojemność transmisyjna była podstawowym parametrem. Systemy podłączone do sieci pracowały w trybie wsadowym, a więc ważne było jedynie wydajne przesyłanie zadań i rozwiązań - nie istniał problem interakcji z systemem zdalnym. Pojemność transmisyjna nie jest zależna od urządzeń w węzłach sieci IP - ruterów.
Wraz z pojawieniem się możliwości zdalnego interaktywnego dostępu powstał następny parametr:
Opóźnienie
Jest to czas, potrzebny na dostarczenie pakietu z jednego węzła w sieci IP do drugiego.
Parametr ten jest złożony z kilku składowych i nie jest równy dla różnych kierunków w sieci.
Nie jest on również stały w czasie, choć niektóre jego składowe są stałe. Na opóźnienie składają się następujące czynniki:
Czas serializacji pakietu przy opuszczaniu każdego węzła sieci. Parametr ten jest stały w czasie. Opisuje go poniższy wzór:
; (3.1.)
gdzie:
T - czas serializacji,
L - długość pakietu w bitach,
AR - Access Rate, czyli szybkość interfejsu w bitach na sekundę.
AR jest oczywistym i jednoznacznym parametrem dla kanałów cyfrowych w strukturze łączy analogowych. Dla FR i ATM szybkość przyłączenia AR oznacza szybkość interfejsu przyłączającego do sieci, a nie parametr kanału wirtualnego i jest ograniczeniem fizycznym każdej implementacji.
Czas Propagacji w każdym z łączy na ścieżce. Jest on stały i niezmienny w czasie dla danego łącza, ale zależny od technologii, ośrodka i długości łącza. Dla łącza satelitarnego czas propagacji jest większy niż naziemnego kanału cyfrowego czy łącza modemowego. Czas propagacji dla łącza światłowodowego jest jeszcze krótszy. Oba powyższe efekty maja charakter ograniczeń fizycznych i nie mogą być poprawione poprzez technologię związaną z IP. Chcąc ograniczyć te czynniki opóźnienia, należy budować sieć IP w oparciu o szerokopasmowe łącza z małym czasem propagacji sygnału w medium transmisyjnym.
Czas obróbki pakietu w każdym węźle pośrednim. Ten czas zależy od sprzętu i oprogramowania węzła i może być różny dla różnych węzłów, a nawet dla różnych pakietów w tym samym węźle. Czas obróbki zmienia się, ze względu na zmiany obciążenia CPU. Ograniczenie wartości tego czynnika jest możliwe przez stosowanie lepszych algorytmów przełączania i wydajniejszego sprzętu.
Jako przykłady można tu przytoczyć mechanizmy:
route-cache - ostatnio używane pozycje tablicy rutingu są przechowywane w szybkiej pamięci podręcznej CPU,
MPLS,
distributed switching - inteligentne karty liniowe ruterów.
Opóźnienia w buforach wyjściowych w węzłach pośrednich. Ten czynnik jest zmienny w czasie, ze względu na następujące zjawiska:
w czasie dt wpływa dP informacji do tej samej sieci.
ruter musi je wysyłać łączem o pojemności transmisyjnej PT podanej poniższym wzorem:
; (3.2.)
gdzie:
PT - pojemność transmisyjna łącza,
dL - ilość informacji,
dt - czas.
Ponieważ dl < dP, a ponadto dP może się składać z wielu pakietów, które należy wysłać sekwencyjnie, jedyne, co można zrobić, to założyć, że w następnej chwili czasowej dt wartość dl < dP i zbuforować dane wejściowe, a następnie wysłać z szybkością łącza PT. Taka technika wprowadza jednak opóźnienie. Ograniczenie tych zjawisk jest możliwe poprzez strategie obsługi kolejek bardziej wyrafinowane niż FIFO.
Ponieważ szybkość łącza jest stała, nie jest możliwe wysyłanie wszystkich danych z bufora szybciej, można jednak pakiety danych określonego typu wysłać częściej niż inne lub przed innymi. Prowadzi to do minimalizacji opóźnienia danych danego typu, kosztem wzrostu opóźnienia danych innego typu.
Jitter
Zmienność opóźnień w czasie jest znana pod angielską nazwą jitter i dla klasycznych usług transmisji danych wartość tego parametru nie ma większego znaczenia. Opóźnienia rzędu dziesiątków milisekund nie są zauważalne dla użytkowników usługi Telnet czy RSH. Nowe usługi szerokopasmowe z rodziny multimediów są jednak wrażliwe na ten parametr. Minimalizację efektu zmiennego opóźnienia można uzyskać poprzez inteligentne algorytmy mechanizmów kolejkowania.
Straty
Straty we współczesnych sieciach IP mogą mieć dwie przyczyny:
Przepełnienie buforów wyjściowych w routerach IP, czyli zjawisko przeciążenia (congestion). Aby zminimalizować prawdopodobieństwo wystąpienia przeciążenia należy doprowadzić do spowolnienia pracy nadajnika. Protokół IP nie przewiduje takich mechanizmów, możliwe jest jedynie pośrednie wpłynięcie na tempo nadawania danych w sesji TCP, poprzez odrzucenie pakietów tej sesji;
Przekroczenie kontraktu, zawartego z operatorem FR lub ATM, pod warunkiem,że technologie te zostały użyte do przenoszenia IP. Optymalizację pracy na takim łączu można uzyskać stosując odpowiednie mechanizmy sterowania przepływem poprzez ograniczenie prędkości nadajnika w zależności od możliwości transmisyjnych kanału wirtualnego FR lub ATM.
4. Metody zapewnienia QoS
Sieci, działające w oparciu o protokół IP, oferują jedynie usługę typu best-effort. Oznacza to, iż pakiety IP transmitowane są z maksymalną szybkością, jednak użytkownik nie posiada żadnej gwarancji, że zostaną dostarczone do punktu przeznaczenia w ustalonym czasie oraz, że w ogóle zostaną dostarczone. Gwałtowny rozwój Internetu sprawił, iż konieczne stało się wprowadzenie mechanizmów, umożliwiających zapewnienie odpowiedniego poziom jakości obsługi informacji przesyłanych w pakietach IP. W tym celu organizacja IETF (Internet Engineering Task Force) opracowała kilka sposobów gwarantowania i różnicowania obsługi w sieciach z protokołem IP. Zaproponowano, między innymi:
model usług zintegrowanych (Integrated Services - IntServ) [16] zdefiniowany w ścisłym powiązaniu z protokołem rezerwacji zasobów w sieciach IP, czyli RSVP (Resorce ReServation Protocol);
model usług zróżnicowanych (Differentiaded Services - DiffServ) [14];
wieloprotokołową komutację etykietkową MPLS (Multi Protocol Label Switching).
W niniejszym rozdziale przedstawiono wszystkie wymienione rozwiązania, opierając się głównie na dokumentach RFC opracowanych przez organizację IETF.
4.1. Architektura usług zintegrowanych IntServ
Model usług zintegrowanych został opracowany przez IETF [16]. Jest to pierwsze rozwiązanie systemowo wspierające zapewnianie jakości usług w sieci Internet.
Architektura usług zintegrowanych zapewnia pełne rozróżnienie pakietów pochodzących z różnych sesji. Pozwala to na odrębne traktowanie poszczególnych strumieni i zarazem zapewnienie jakości usługi w relacji od końca do końca (end-to-end). Dla każdego strumienia można zdefiniować odmienne wartości parametrów QoS. Ponadto strumienie danych są niezależne i nie zakłócają się wzajemnie.
W modelu IntServ zdefiniowano trzy klasy usług:
usługę gwarantowaną GS (Guaranteed Service) [17];
usługę kontrolowanego obciążenia CL (Controlled Load Service) [18];
usługę nie sklasyfikowaną (best effort).
Klasa usług GS zapewnia gwarantowaną szerokość pasma transmisyjnego, brak strat pakietów wynikających z kolejkowania w buforach urządzeń sieciowych oraz nieprzekraczalną wartość opóźnienia przesyłanych pakietów w relacji od końca do końca. Brak jest natomiast gwarancji na równomierność opóźnienia. Klasa GS znajduje zastosowanie dla aplikacji bardzo wrażliwych na opóźnienia i wymagających transmisji w czasie rzeczywistym (np. przesyłanie obrazu wideo).
Klasa usług CL nie zapewnia ścisłych gwarancji ilościowych parametrów QoS. Gwarantuje jedynie takie warunki ruchowe, jakie występowałyby w sieci nieobciążonej ruchem. Oznacza to, że w warunkach rosnącego obciążenia sieci jakość transmisji nie powinna się pogarszać. Klasa usług CL jest przeznaczona między innymi do aplikacji czasu rzeczywistego, ale tolerujących pewien poziom opóźnień i strat pakietów.
Usługa niesklasyfikowana jest zorientowana na klasyczną transmisję danych, bez żadnych gwarancji QoS. Wraz ze wzrostem obciążenia sieci poziom jakości transmisji znacznie się obniża. Klasa ta jest przeznaczona do aplikacji tolerujących duże opóźnienia oraz duże zmiany wartości opóźnienia.
Każdy węzeł sieci zgodny z modelem IntServ powinien mieć zaimplementowane wymienione poniżej następujące mechanizmy sterowania ruchem.
Sterowanie przyjmowaniem zgłoszeń (admission cortrol) - mechanizm polegający na sprawdzaniu, czy dostępne zasoby są wystarczające do zapewnienia żądanych parametrów transmisyjnych. W praktyce polega to na sprawdzeniu, czy mechanizmy szeregowania pakietów w danym węźle (packet scheduler) są w stanie obsłużyć nowy strumień danych z gwarantowaną jakością bez wpływu na strumienie już obsługiwane.
Klasyfikacja ruchu (traffic classification) - rozróżnianie pakietów należących do różnych strumieni. Funkcja ta jest realizowana przez klasyfikatory ruchu.
Sprawdzanie zgodności charakterystyki ruchowej strumienia danych z kontraktem ruchowym (traffic policing). Jeżeli generowany ruch nie odpowiada zarezerwowanym parametrom, pakiety mogą być oznaczane jako niepodlegające rezerwacji (best effort) lub odrzucone (packet dropping).
Szeregowanie pakietów (scheduling), polegające na zmianie kolejności pakietów w kolejce wyjściowej, mające na celu zapewnienie strumieniom danych gwarantowanej jakości obsługi.
Dla potrzeb realizacji modelu IntServ opracowany został protokół sygnalizacyjny RSVP (Resource reSerVation Protocol). Pojęcia te są jednak często mylone. Model IntServ może korzystać z różnych protokołów sygnalizacyjnych. RSVP jest przykładem (praktycznie jedynym) takiego protokołu.
Rysunek 4.1. Implementacja modelu zintegrowanych usług w stacjach roboczych i ruterach [19]
Do opisu charakterystyki ruchowej przesyłanego strumienia danych oraz sprawdzania zgodności generowanego ruchu z deklarowanym, model IntServ wykorzystuje mechanizm „wiadra tokenowego” (token bucket), którego zasadę działania ilustruje rysunek 4.2. [20].
Rysunek 4.2. Mechanizm wiadra tokenowego (token bucket) [20]
Wiadro tokenowe jest definiowane przy pomocy dwu parametrów, mianowicie szybkości napełniania r [B/s] oraz pojemności b [B]. Parametr r może przyjmować wartości z zakresu od l [B/s] do 40 [TB/s] (teoretyczną granicę wyznacza przepustowość włókna światłowodu), z kolei pojemność wiadra może maksymalnie wynosić 250 [GB]. Odebrany pakiet IP jest wysyłany dalej tylko wtedy, gdy w wiadrze znajduje się odpowiednia ilość tokenów (token=kredyt na x bajtów). Jeżeli wiadro jest puste lub niedostatecznie wypełnione, wtedy pakiet może poczekać na tokeny, ale jedynie w sytuacji, gdy jest wolne miejsce w buforze wejściowym.
Gdy bufor jest pełny, wtedy wszystkie nadchodzące pakiety są odrzucane. Zastosowanie bufora wejściowego pozwala dopasować przesyłany strumień danych do charakterystyki ruchowej zadeklarowanej przez użytkownika (reshaping). Jeżeli założymy, że w chwili początkowej wiadro jest całkowicie wypełnione tokenami wtedy maksymalna porcja danych wysłana w dowolnym czasie T wynosi b+rT bajtów. Na tej podstawie możemy wyznaczyć maksymalną szerokość pasma wymaganą dla przesyłanego strumienia danych.
Protokół RSVP (Resorce reSerVation Protocol) odpowiada za sygnalizację, służącą do rezerwowania zasobów i zestawiania logicznych dróg połączeniowych, którymi następnie przesyła się pakiety [21]. Jest to protokół warstwy transportowej, którego idea sprowadza się do powiadomienia stacji odbiorczej o tym, iż stacja nadawcza chce przesłać dane, wymagające określonego poziomu obsługi. Po odebraniu informacji od nadawcy, stacja odbiorcza wysyła do ruterów i hostów znajdujących się na drodze pomiędzy odbiorcą i nadawcą żądanie zarezerwowania odpowiedniej szerokości pasma oraz pojemności buforów. Jeżeli wymagane zasoby są dostępne, rezerwacja dochodzi do skutku i nadawca może rozpocząć wysyłanie danych. Istotną cechą działania protokołu RSVP jest konieczność okresowego odnawiania rezerwacji. Eliminuje to konieczność rozłączenia połączenia logicznego i zwiększa odporność całego systemu na ewentualne awarie [21]. Szczegóły dotyczące roli protokołu RSVP w modelu zintegrowanych usług zostaną omówione w dalszej części.
4.1.1. Usługa gwarantowana (Guaranteed Service)
Usługa GS jest przeznaczona dla aplikacji czasu rzeczywistego (transmisja audio, wideo), wymagających stałej szerokości pasma oraz wartości opóźnienia, zmieniającego się w ściśle określonych granicach czasowych. W celu zrealizowania usługi GS wyznacza się maksymalną wartość opóźnienia, z jakim dostarczane są pakiety. Całkowite opóźnienie pakietu end-to-end składa się z opóźnienia stałego (wnoszonego przez medium transmisyjne) oraz opóźnienia kolejkowania pakietu w buforach urządzeń sieciowych biorących udział w transmisji. Usługa gwarantowana GS kontroluje jedynie opóźnienie spowodowane kolejkowaniem, które w pierwszym rzędzie zależy od deklarowanych parametrów token bucket, a w szczególności od pojemności wiadra b oraz szybkości, z jaką generowany jest strumień danych R.
Maksymalne opóźnienie pakietu kontrolowane w usłudze GS wyznacza się z następującego wzoru [17]:
gdzie:
r [B/s] i b [B] - parametry token bucket;
p [B/s] - maksymalna szybkość generowanego ruchu (peak rate), (p≥ r);
R [B/s] - szybkość strumienia danych aplikacji; im R jest większe tym opóźnienie jest mniejsze (R ≥ r);
M [B] - maksymalny rozmiar pakietu.
Usługa gwarantowana nie kontroluje minimalnego i średniego opóźnienia pakietu, a jedynie maksymalne opóźnienie wywołane kolejkowaniem. Aby wyznaczyć całkowite opóźnienie pakietu, należy dodatkowo określić opóźnienie występujące wzdłuż ustalonej trasy (path latency) i zsumować je z wyznaczonym opóźnieniem kolejkowania. W przedstawionym wzorze osobnego wyjaśnienia wymagają parametry Ctot oraz Dtot. Otóż każdy element sieci mający zaimplementowaną usługę GS może być opisany przy pomocy dwu parametrów C [B] i D [μs], które informują o tym, w jakim stopniu własności danego elementu odbiegają od modelu przepływowego (fluid model) stworzonego dla usługi GS. Parametr C określa błąd zależny od szybkości obsługiwanego strumienia i reprezentuje opóźnienie doznawane przez pakiet w efekcie zmiany parametrów ruchowych strumienia. Z kolei parametr D jest niezależny od szybkości strumienia danych i reprezentuje maksymalny czas przejścia (transit time variation) pakietu przez dany element sieci. Jego wartość jest ustalana w czasie inicjowania systemu lub w trakcie konfiguracji. Parametry Ctot i Dtot we wzorze na opóźnienie stanowią sumę parametrów C i D wszystkich elementów sieciowych, na trasie pakietu. Aby całkowite opóźnienie pakietu było mniejsze od granicznego, należy sprawić by opóźnienie kolejkowania pakietu w pojedynczym elemencie sieciowym było mniejsze od wartości wyrażenia b/R + C/R + D [28]. Jeżeli opóźnienie dostarczanych pakietów jest większe od spodziewanego, wtedy aplikacja odbiorcy może zmodyfikować parametry token bucket (b) oraz szybkość wysyłania danych (R) tak, aby osiągnąć wymagany poziom opóźnienia.
Obok ograniczeń nakładanych na wartość opóźnienia przesyłanych pakietów, usługa GS żąda również zarezerwowania pasma o odpowiedniej szerokości (R). Ruch generowany przez aplikację w dowolnym czasie T nie może przekroczyć M + min[pT, rT+b-M] bajtów. Jeżeli nie jest znana maksymalna szybkość p generowanego ruchu, wtedy domyślnie przyjmuje się p równe nieskończoności, co sprawia, iż wyrażenie określające maksymalną porcję danych wysyłaną w czasie T redukuje się do postaci rT+b.
Aplikacja żądająca usługi GS, musi powiadomić wszystkie elementy sieciowe znajdujące się na trasie pomiędzy nadawcą i odbiorcą, jaki ruch będzie generowany oraz jakie zasoby należy zarezerwować. W tym celu wykorzystuje się dwie grupy parametrów: TSpec (Traffic Specification) oraz RSpec (Reservation Specification), które przesyłane są w wiadomościach sygnalizacyjnych RSVP Path oraz Resv do wszystkich węzłów zlokalizowanych na trasie między nadawcą i odbiorcą. Obiekt TSpec charakteryzuje ruch generowany przez nadawcę, natomiast RSpec określa wymagany poziom obsługi. TSpec zawiera parametry token bucket (b i r) oraz wielkości opisujące przesyłany strumień danych takie jak:
p [B/s] - maksymalna szybkość generowanego ruchu;
m [B] - najmniejszy rozmiar pakietu (parametr ten jest konieczny do oszacowania pasma jakie, należy zarezerwować dla przesłania nagłówka warstwy łącza danych oraz bitów wypełnienia, dla AAL5 pasmo to określone jest wyrażeniem ((r/48)*5)+((r/m)*(8+52)) [B/s]);
M [B] - największy rozmiar obsługiwanego pakietu.
Z kolei Rspec zawiera następujące dwa parametry:
R [B/s] - szybkość strumienia danych aplikacji (wymagana szerokość pasma);
S [μs] - różnica pomiędzy wymaganym dopuszczalnym opóźnieniem akceptowanym przez aplikację, a opóźnieniem wynikającym z poziomu rezerwacji dla przepływności R, (S>0).
W przypadku zarezerwowania zbyt dużych zasobów, informacja znajdująca się w parametrze S może być wykorzystana przez dany element sieciowy do zredukowania wykonanej rezerwacji. Przykładowo, gdy założymy, że dopuszczalne opóźnienie end-to-end (Dreq) jest większe od maksymalnego, wtedy dla R = r opóźnienie kolejkowania end-to-end wyraża się następującym wzorem [17]:
Opóźnienie kolejkowania end-to-end =
. (4.2.)
Parametr S (slack term), zgodnie z definicją, jest obliczany na podstawie wzoru [28]:
. (4.3.)
Przyjmując s ≤ S możemy zwiększyć lokalne opóźnienie pakietu d (delay) do wartości d+s. Większa wartość opóźnienia pozwala nam zredukować zarezerwowane pasmo R. Dzięki temu ruter może obsługiwać ruch innych strumieni, który normalnie byłby odrzucony. Wzrost wartości opóźnienia transmisji w elemencie realizującym usługę GS prowadzi do wykorzystania większej pojemności buforów. Należy zauważyć, iż w grupie parametrów Rspec nie specyfikuje się wymaganej przestrzeni bufora dla przesyłanego strumienia danych. Zakłada się, bowiem, iż na podstawie przekazanych parametrów Tspec oraz Rspec, każdy element sieciowy będzie w stanie sam wyznaczyć wymaganą pojemność bufora, aby uniknąć straty pakietów w wyniku kolejkowania.
Dopasowanie wielkości przesyłanego strumienia do charakterystyki ruchowej zadeklarowanej przez nadawcę (reshaping) wymaga zastosowania bufora wejściowego o pojemności [17]:
; (4.4.)
gdzie Csum oraz Dsum są to sumy cząstkowe parametrów C i D wszystkich elementów sieciowych zlokalizowanych na trasie pomiędzy ostatnim punktem dostosowującym przesyłany ruch do przyjętego profilu i aktualnym węzłem sieci. Jeżeli kolejkowany ruch przekroczy rozmiar bufora wtedy nadchodzące pakiety mogą zostać usunięte lub przesyłane dalej jako ruch best effort.
Kiedy uwzględnimy maksymalną szybkość p z jaką źródło wysyła dane, wtedy wyrażenie określające pojemność bufora przyjmie następującą postać [17]:
; (4.5.)
gdzie
(4.6.)
Opóźnienie spowodowane dostosowaniem ruchu do zadeklarowanego profilu, zazwyczaj nie wpływa znacząco na całkowite opóźnienie dostarczania pakietów.
4.1.2. Usługa kontrolowanego obciążenia (Controlled Load Service)
Głównym założeniem usługi CLS jest realizowanie obsługi przesyłanego strumienia danych na poziomie zbliżonym do tego, jaki ma miejsce w warunkach braku przeciążenia sieci i stosowania usługi typu best effort [18]. Klasa CLS jest przewidziana dla aplikacji wrażliwych na duże obciążenie sieci, które zostały zaprojektowane z myślą o zastosowaniu w tradycyjnym Internecie, obsługującym pakiety według zasady best effort. Ważnym przykładem aplikacji korzystających z usługi CLS są tzw. aplikacje adaptacyjne czasu rzeczywistego (adaptive real-time applications), które prawidłowo funkcjonują w warunkach obsługi best effort przy niskim obciążeniu sieci, natomiast w sytuacji pojawienia się dużego obciążenia ich efektywność gwałtownie maleje. Aplikacje wykorzystujące usługę CLS mogą być pewne, iż bardzo wysoki procent pakietów będzie poprawnie dostarczony do odbiorcy, a opóźnienie większości pakietów nie przekroczy wartości wynikającej z szybkości medium i średniego czasu obsługi w ruterach. Dla transmisji danych oznacza to, iż w długoterminowej skali czasu wystąpi bardzo małe opóźnienie kolejkowania pakietu w buforach oraz, że niewielki lub nawet zerowy procent pakietów zostanie utracony wskutek wystąpienia natłoku. W przypadku usługi CLS bardzo ważne jest to, iż nie precyzuje ona wymagań odnośnie stopy traconych pakietów oraz wartości opóźnienia, które towarzyszy transmisji. Wymaganą jakość obsługi realizuje się na drodze rezerwacji odpowiednich zasobów sieciowych. Aplikacja żądająca usługi CLS musi wcześniej zadeklarować, jaki ruch będzie generowany. Podobnie jak usługa GS wykorzystuje ona w tym celu grupę parametrów Tspec (Traffic Specification), które są przekazywane wszystkim hostom i ruterom, znajdującym się na trasie pomiędzy obiektem źródłowym i docelowym. Zawartość Tspec dla usługi CLS jest taka sama jak w przypadku usługi gwarantowanej (b, r, p, M, m).
Każdy host i ruter, realizujący usługę CLS, musi zarezerwować pasmo o odpowiedniej szerokości oraz bufory zdolne obsłużyć ruch określony w Tspec. W odróżnieniu od usługi gwarantowanej, usługa CLS zapewnia jedynie odpowiednią szerokość pasma, nie kontroluje natomiast wartości opóźnienia, z jakim dostarczane są pakiety. Wymagany poziom obsługi jest zapewniony tylko dla ruchu zgodnego z parametrami Tspec. W dowolnym czasie T generowany ruch nie może przekroczyć wartości b+rT bajtów, wynikającej z zastosowania mechanizmu token bucket. Wszystkie pakiety naruszające to ograniczenie muszą być uznane za niezgodne z profilem ruchowym zadeklarowanym przez nadawcę. Również pakiety o rozmiarze większym od jednostki MTU są traktowane jako niezgodne z Tspec, jakkolwiek sytuacja taka bardzo rzadko ma miejsce. Ruch wykraczający poza granice określone w Tspec powinien być przesyłany dalej na zasadzie best effort, oczywiście tylko wtedy, gdy istnieją wystarczające zasoby do zrealizowania transmisji.
4.1.3. Rola RSVP w modelu IntServ
Protokół sygnalizacyjny RSVP opracowano dla modelu usług zintegrowanych IntServ, jednakże możliwe są również inne jego zastosowania. Protokół RSVP odpowiada za rezerwację zasobów sieciowych potrzebnych do przesłania strumienia pakietów w relacji od końca do końca oraz za zestawianie dróg połączeniowych. Protokół ten nie jest jednak odpowiedzialny za dobór trasy. Zestawianie połączenia oraz rezerwacja zasobów odbywa się na trasie wybranej przez protokoły rutingu [22]. RSVP wspiera zarówno połączenia typu punkt-punkt (unicast), jak punkt-wielopunkt (multicast). Rezerwacja zasobów jest dokonywana dla jednego kierunku transmisji. Dla każdej ścieżki zarezerwowanej można wyróżnić nadawcę i odbiorcę danych oraz węzły pośrednie.
4.1.3.1. Definicja sesji, style rezerwacji
W protokole RSVP wprowadzono pojęcie sesji jako strumienia pakietów przesyłanego za pośrednictwem określonego protokołu warstwy transportowej do węzła o ściśle określonym adresie przeznaczenia. Adres sesji jest jednoznacznie określony przez trzy parametry: adres i numer portu odbiorcy oraz identyfikator protokołu warstwy transportowej (TCP lub UDP). W każdym węźle są zaimplementowane mechanizmy pozwalające rozróżnić pakiety należące do poszczególnych sesji. Adres sesji może być typu punkt-punkt lub punkt-wielopunkt [23].
Protokół RSVP umożliwia dodatkowe rozróżnienie pakietów na podstawie adresu i numeru portu nadawcy. Dzięki temu można określić listę nadawców i aplikacji, których pakiety wysłane na adres sesji będą podlegać rezerwacji. Zdefiniowano dwa rodzaje rezerwacji (współdzieloną i indywidualną) oraz dwa sposoby wyboru nadawców uprawnionych do korzystania z danej rezerwacji (ze ścisłą selekcją i bez selekcji). W przypadku sesji z rezerwacją współdzieloną (shared reservations) akceptuje się pakiety pochodzące od wielu nadawców. Rezerwacja indywidualna (distinct reservations) jest wykonywana dla dokładnie jednego nadawcy. Dla sesji ze ścisłą selekcją nadawców (explicit sender selection) określa się listę nadawców uprawnionych do wysyłania pakietów na jej adres. Pakiety pochodzące od nadawców nieuprawnionych nie podlegają rezerwacji. W przypadku sesji z brakiem selekcji (wildcard sender selection) wszystkie pakiety wysyłane na adres sesji podlegają rezerwacji.
Korzystając z wymienionych rodzajów rezerwacji i sposobów wyboru nadawców zdefiniowano trzy style rezerwacji WF (Wildcard-Filter Style), SE (Shared-Explicit Style) oraz FF (Fixed-Filter Style) (tabela 4.1.) [19]. Rezerwacja WF nie określa nadawcy. Rezerwacji podlegają wszystkie pakiety wysyłane na adres sesji, a wielkość zarezerwowanych zasobów nie zależy od liczby nadawców. W stylu SE określa się ściśle listę nadawców uprawnionych do korzystania z rezerwacji. Style WF i SE stosuje się przede wszystkim w przypadku aplikacji, w których nie wszyscy nadawcy wysyłają dane w tym samym czasie (np. telefonia IP) lub do emulacji łącza dzierżawionego. Jednakże w przypadku, gdy wszyscy nadawcy wysyłają dane jednocześnie, może dojść do przekroczenia zarezerwowanych parametrów, zwłaszcza na odcinku trasy najbliżej odbiorcy. Z drugiej strony zasoby na odcinkach trasy w pobliżu nadawców mogą być wykorzystywane nieefektywnie. W przypadku rezerwacji FF pakiety pochodzące tylko od jednego nadawcy podlegają rezerwacji. Styl ten jest stosowany przez aplikacje wymagające niezależnej gwarancji jakości usługi. Całkowita ilość zarezerwowanych zasobów jest sumą wszystkich pojedynczych rezerwacji. Wynikają z tego problemy ze skalowalnością protokołu RSVP. Styl rezerwacji jest wybierany przez odbiorcę. Nadawca nie ma wpływu na styl rezerwacji.
Tabela 4.1. Style rezerwacji zdefiniowane w protokole RSVP
|
Rodzaj rezerwacji |
||
|
Współdzielony |
Indywidualny |
|
Selekcja nadawców |
Ścisła |
SE (Shared-Explicit Style) Ściśle określona lista nadawców, których pakiety podlegają rezerwacji |
FF (Fixed-Filoter Style) Paliety tylko jednego nadawcy podlegają rezerwacji. |
|
Brak |
WF (Wildcard-Filter Style) Nie ma określonych nadawców. Wszystkie pakiety wysyłane na adres sesji podlegają rezerwacji |
- |
Protokół RSVP, oprócz omówionych parametrów sesji, przenosi informacje o charakterystyce ruchu - parametry TSpec (Traffic Specification) oraz zbiór wymaganych parametrów jakościowych - parametry RSpec (Resource Specification). Paramery TSpec i RSpec zawierają ponadto informację o żądanej klasie usługi (gwarantowanej lub kontrolowanego obciążenia).
Wszystkie informacje są przenoszone wewnątrz komunikatów w formie obiektów. RFC 2205 definiuje 15 obiektów o różnym przeznaczeniu [19]. Format wszystkich obiektów jest wspólny.
Pykładowe obiekty to:
SESSION - zawiera adres i numer portu przeznaczenia oraz identyfikator protokołu,
SENDER_TEMPLATE - zawiera adres i port nadawcy,
SENDER_TSPEC - wstępne parametry rezerwacji TSpec,
FLOWSPEC - przenosi żądane parametry rezerwacji RSpec,
STYLE - określa żądany styl rezerwacji,
RSVP_HOP - zawiera adres IP poprzedniego węzła, który wystał komunikat.
Definicję poszczególnych obiektów można znaleźć w dokumencie RFC 2205 [19]. Ich szczegółowa znajomość nie jest niezbędna do zrozumienia zasady działania protokołu RSVP.
4.1.3.2. Rezerwacja ścieżki
Rezerwacja ścieżki jest zawsze inicjowana przez nadawcę danych. Wysyła on do odbiorcy komunikat PATH, zawierający wstępne parametry rezerwacji TSpec odzwierciedlające charakterystykę ruchu, który będzie przesyłany. Po odebraniu komunikatu PATH odbiorca wysyła do nadawcy komunikat zwrotny RESV, zawierający żądane parametry rezerwacji RSpec. Parametry RSpec mogą mieć takie same wartości jak proponowane parametry TSpec lub mniejsze. Dzięki temu odbiorca może zdecydować, czy chce otrzymywać daną usługę z jakością oferowaną przez nadawcę, czy niższą. Komunikat RESV może ponadto zawierać listę nadawców uprawnionych do korzystania z tej rezerwacji (w zależności od stosowanego stylu rezerwacji) [23].
Na rysunku 4.3. przedstawiono proces rezerwacji ścieżki. Komunikat PATH jest przesyłany od nadawcy do odbiorcy wzdłuż drogi wybranej przez protokoły rutingu. Komunikat RESV musi zostać przesłany w przeciwnym kierunku dokładnie tą samą drogą. Jednakże droga od odbiorcy do nadawcy wybrana przez protokoły rutingu może być inna. Dlatego też należy zapamiętać drogę, którą jest przesyłany komunikat PATH. W tym celu każdy ruter zapamiętuje adres poprzedniego węzła, z którego przyszedł komunikat PATH. Informacja o adresie węzła poprzedniego jest przenoszona w obiekcie RSVP_HOP.
Rezerwacji zasobów dokonuje się na etapie przesyłania komunikatu RESV. Proces ten jest wykonywany osobno dla każdego odcinka ścieżki, począwszy od ostatniego (najbliżej odbiorcy), przez kolejne węzły pośrednie aż do nadawcy. W każdym ruterze po otrzymaniu komunikatu RESV są wykonywane następujące operacje:
sprawdzanie, czy dostępne zasoby sieciowe są wystarczające do zarezerwowania ścieżki o żądanych parametrach,
sprawdzanie, czy węzeł żądający rezerwacji jest uprawniony do korzystania z zasobów w danym węźle pośrednim.
Rysunek 4.3. Proces rezerwacji ścieżki przez protokół sygnalizacyjny RSVP
Jeżeli oba powyższe warunki są spełnione, jest dokonywana rezerwacja w tym węźle, a żądanie rezerwacji jest przesyłane do kolejnego węzła pośredniego. W przeciwnym razie proces zestawiania ścieżki zostaje przerwany, a do odbiorcy wysyła się komunikat o błędzie.
Od chwili zarezerwowania ścieżki węzły do niej należące rozpoznają pakiety podlegające rezerwacji. W każdym węźle wszystkie przychodzące pakiety są klasyfikowane. Mechanizm ten stosuje się w celu wyróżnienia pakietów należących do różnych sesji (zarezerwowanych ścieżek) oraz pakietów niepodlegających rezerwacji. Następnie, oddzielnie dla każdej sesji, elementy pomiarowe sprawdzają zgodność charakterystyki ruchowej strumienia z profilem ruchu odpowiadającym zarezerwowanym parametrom [22]. Pakiety, które są zgodne z odpowiednim profilem ruchu, podlegają rezerwacji. W przeciwnym razie są traktowane jako ruch typu niesklasyfikowanego. Aby zapewnić wymaganą jakość obsługi pakietów należących do poszczególnych sesji stosuje się zaawansowane metody kolejkowania pakietów, jak na przykład cykliczne przetwarzanie porcjami (round-robin) czy WFQ (Weighted Fair Queueing).
4.1.3.3. Połączenia w trybie punkt-wielopunkt
W celu zapewnienia realizacji połączeń w trybie punkt-wielopunkt, opracowano mechanizmy łączenia rezerwacji. Rezerwacje pochodzące od różnych odbiorców należących do tej samej sesji typu punkt-wielopunkt są obsługiwane niezależnie. Jednakże rezerwacja zasobów jest dokonywana tylko raz, zgodnie z parametrami o najwyższych wymaganiach [23]. Proces rezerwacji ścieżek w trybie punkt-wielopunkt przedstawiono w uproszczeniu na rysunku 4.4. Komunikat PATH, zawierający charakterystykę źródła, wysyłany przez nadawcę, jest następnie powielany w odpowiednich węzłach. Każdy odbiorca otrzymuje taki sam zbiór parametrów TSpec. Następnie odbiorcy mogą żądać różnej jakości usługi. Każdy z nich wysyła komunikat RESV z żądanymi parametrami RSpec. Węzeł, w którym łączy się rezerwacje, wysyła dalej komunikat RESV z takimi parametrami RSpec, jakich żądał najbardziej wymagający odbiorca.
Rysunek 4.4. Proces rezerwacji ścieżki w trybie punkt-wielopunkt
4.1.3.4. Tymczasowe stany rezerwacji
Istotną cechą protokołu RSVP są tymczasowe stany rezerwacji (soft state). Podtrzymanie rezerwacji wymaga okresowego odświeżania, które polega na wysyłaniu komunikatów PATH i RESV. Jeżeli w zadanym czasie rezerwacja nie zostanie odświeżona, będzie zerwana. Rozwiązanie takie ma zarówno szereg zalet jak i wad. Pozwala między innymi na zmianę parametrów istniejącej rezerwacji. Nadawca może w trakcie trwania połączenia zmienić profil ruchu i zażądać zmiany parametrów rezerwacji, wysyłając komunikat PATH z nowymi wartościami parametrów TSpec. Podobnie odbiorca może zażądać innej jakości usługi, wysyłając komunikat RESV z nowymi parametrami RSpec. W sposób dynamiczny można również zmieniać listę nadawców uprawnionych do korzystania z danej rezerwacji. Nie ma obowiązku rozłączania rezerwacji, gdyż zostanie ona automatycznie rozłączona przy braku odświeżania. Niewątpliwą zaletą tymczasowych stanów rezerwacji jest ponadto niezależność od zmian rutingu. Jeżeli protokoły rutingu zmienią trasę od nadawcy do odbiorcy, rezerwacja zostanie automatycznie zestawiona na nowej trasie, zaś stara ścieżka po pewnym czasie będzie rozłączona (brak komunikatów odświeżających). Niestety, nie ma żadnej gwarancji, że na nowej trasie będzie możliwość zarezerwowania ścieżki o tych samych parametrach. Istnieje, więc niebezpieczeństwo rozłączenia rezerwacji w wyniku zmian rutingu. Drugą wadą tymczasowych stanów rezerwacji jest konieczność przesyłania dużego ruchu sygnalizacyjnego, który rośnie proporcjonalnie do liczby zestawionych ścieżek zarezerwowanych. Duża liczba przesyłanych komunikatów, które muszą być przetwarzane w węzłach, wpływa też na ich dodatkowe obciążenie. Jest to jeden z czynników powodujących problemy ze skalowalnością protokołu RSVP. Ponadto w każdym węźle należy przechowywać dużą ilość informacji związaną ze stanami poszczególnych zarezerwowanych ścieżek [23].
4.1.3.5. Redukcja odświeżania stanów tymczasowych
Konieczność odświeżania tymczasowych stanów rezerwacji jest jednym z czynników wpływających negatywnie na skalowalność protokołu RSVP. Proporcjonalnie do liczby zestawionych ścieżek zarezerwowanych rośnie liczba przesyłanych komunikatów, powodując zwiększenie wielkości ruchu sygnalizacyjnego w sieci, jak również wzrost obciążenia ruterów związanego z ich przetwarzaniem. Najprostszym rozwiązaniem wydawałoby się zwiększenie odstępu czasu pomiędzy wysyłaniem kolejnych komunikatów odświeżających. Wydłuża to jednak w sposób niepożądany czas potrzebny do synchronizacji stanów tymczasowych w całej ścieżce. Ponadto w protokole RSVP brak jest niezawodnych mechanizmów dostarczania komunikatów. Węzeł wysyłający komunikat nie otrzymuje potwierdzenia o jego dostarczeniu. W przypadku utraty lub uszkodzenia pakietu nie jest on wysyłany ponownie. Ma to szczególnie duże znaczenie przy zestawiania nowej rezerwacji lub modyfikacji parametrów już istniejącej. W takiej sytuacji jedynym mechanizmem, zapewniającym poprawne działanie protokołu, jest przesyłanie komunikatów odświeżających. Im częściej są wysyłane, tym szybciej likwiduje się skutki awarii. Z tego powodu zmniejszenie częstotliwości odświeżania jest niepożądane.
Opracowane w ramach IETF rozszerzenie protokołu RSVP [24] jest oparte na założeniu, że komunikaty PATH i RESV wysyłane w czasie tworzenia i trwania sesji RSVP można podzielić na trzy rodzaje: tworzące, modyfikujące i odświeżające. Komunikaty tworzące są przesyłane w trakcie zestawiania nowej ścieżki zarezerwowanej. Komunikaty modyfikujące są przesyłane w przypadku żądania zmiany parametrów istniejącej rezerwacji. Komunikaty odświeżające służą do podtrzymywania stanów tymczasowych i są identyczne z ostatnio przesłanymi komunikatami tworzącymi lub modyfikującymi. W standardowym protokole RSVP zawsze analizuje się cały komunikat i na tej podstawie tworzy się nową sesję lub podtrzymuje istniejącą rezerwację lub zmienia się jej parametry. Jak łatwo zauważyć, konieczność analizowania i przesyłania całego komunikatu występuje tylko w przypadku komunikatów tworzących i modyfikujących. Aby możliwe było rozróżnienie poszczególnych rodzajów komunikatów, zdefiniowano nowy obiekt MESSAGE_ID. Jest on przesyłany wewnątrz komunikatów PATH i RESV. Obiekt ten zawiera identyfikator komunikatu, który jest ustawiany osobno dla każdego odcinka drogi przez kolejne węzły wysyłające komunikat. Identyfikator, wraz z przenoszonym w obiekcie RSVP_HOP adresem IP węzła, który go ustawił, jednoznacznie identyfikuje komunikat. Wszystkie komunikaty odświeżające otrzymują identyfikator o tej samej wartości. W przypadku komunikatów modyfikujących wartość identyfikatora jest zawsze większa od tej, która obowiązywała dla poprzedniego stanu rezerwacji. W węźle wystarczy, więc sprawdzić wartość identyfikatora, aby określić rodzaj komunikatu. Jeżeli zostanie on zidentyfikowany jako nowy lub modyfikujący, wówczas jest analizowana reszta komunikatu. Komunikat odświeżający nie jest przetwarzany. Przedstawione rozwiązanie przede wszystkim zmniejsza obciążenie ruterów związane z przetwarzaniem komunikatów.
Omawiane rozszerzenie protokołu RSVP wprowadza również mechanizm potwierdzeń. W obiekcie MESSAGE_ID znajduje się flaga żądania potwierdzenia. Węzeł wysyłający komunikat może ją ustawić. Wówczas węzeł, który odbierze komunikat, musi do jego nadawcy wysłać komunikat zawierający obiekt MESSAGE_ID_ACK. Jeżeli potwierdzenie nie nadchodzi w zadanym czasie, wysłanie komunikatu jest ponawiane. Mechanizm ten poprawia niezawodność przesyłania komunikatów RSVP.
Redukcję wielkości ruchu sygnalizacyjnego można uzyskać dzięki mechanizmowi potwierdzeń sumarycznych (summary refresh). Podstawowym założeniem tego mechanizmu jest możliwość odróżniania komunikatów odświeżających na podstawie identyfikatora. Zważywszy, że w przypadku komunikatów odświeżających nie ma potrzeby analizowania całego komunikatu PATH lub RESV, wystarczy przesyłać sam identyfikator. W tym celu zdefiniowano nowy typ komunikatu SREFRESH. Został on tak zaprojektowany, aby mógł przenosić zbiór identyfikatorów. W ten sposób zamiast wysyłać komunikaty odświeżające osobno dla każdej sesji, można wysłać jeden komunikat odświeżający SREFRESH. Węzeł, który odbierze taki komunikat, wydobywa z niego wszystkie identyfikatory i odświeża tymczasowe stany rezerwacji odpowiednich sesji [23].
4.1.3.6. Przesyłanie parametrów usługi GS oraz CLS
RSVP umożliwia przekazywanie parametrów niezbędnych do zrealizowania wymaganej usługi (GS lub CLS) wszystkim węzłom, które zlokalizowane są na trasie łączącej nadawcę z odbiorcą. Sesja RSVP jest inicjowana przez nadawcę, który wysyła do odbiorców wiadomość RSVP_Path zawierającą obiekt SENDER_TSPEC. Opisuje on ruch generowany przez nadawcę i stanowi odwzorowanie parametrów usługi GS oraz CLS zawartych w TSpec i RSpec. Obiekt ten nie może być modyfikowany w elementach sieciowych pośredniczących w transmisji.
Rysunek 4.5. Obiekt SENDER_TSPEC dla usługi CLS [25]
Rysunek 4.6. Obiekt SENDER_TSPEC dla usługi GS [25]
Obok SENDER_TSPEC, wiadomość RSVP_ Path zawiera również obiekt ADSPEC, który przenosi informacje generowane w źródle oraz węzłach na trasie pomiędzy nadawcą i odbiorcą, pozwalające m.in. oszacować wartość opóźnienia wzdłuż ustalonej trasy i sprawdzić, czy dana usługa może być w ogóle zrealizowana. W każdym elemencie sieci ADSPEC trafia do modułu kontroli ruchu, gdzie modyfikowane są odpowiednie parametry. Jeśli dany element nie ma zaimplementowanej żądanej usługi QoS, wtedy ustawiane są odpowiednie bity, które o tym informują (tzw. break bits). Każdy rodzaj usługi posiada swój bit w odpowiednim nagłówku dedykowanym dla tej usługi, który znajduje się w obiekcie ADSPEC. Jeśli break bit danej usługi jest ustawiony, oznacza to, że informacje dotyczące tej usługi nie są w pełni wiarygodne, ponieważ któryś z elementów sieci nie obsługuje żądanej usługi. W węźle tym przesyłany strumień będzie obsługiwany na zasadzie best effort. Dane znajdujące się w obiekcie ADSPEC są podzielone na fragmenty skojarzone z określonym rodzajem usługi. W efekcie mogą być przesyłane parametry kilku usług równocześnie. Jeżeli fragment dotyczący danej usługi nie znajduje się w obiekcie ADSPEC, wtedy usługa ta nie może być wymagana przez odbiorcę.
Rysunek 4.7. Format obiektu ADSPEC [25]
Po otrzymaniu wiadomości RSVP_Path aplikacja odbiorcy analizuje informacje zawarte w obiektach ADSPEC i SENDER_TSPEC w celu wyznaczenia odpowiednich wartości parametrów rezerwacyjnych. Następnie odbiorca wysyła do nadawcy wiadomość RSVP_Resv z żądaniem rezerwacji wymaganych zasobów w węzłach znajdujących się na trasie pomiędzy nadawcą i odbiorcą. Wiadomość ta zawiera obiekt FLOWSPEC, będący odwzorowaniem parametrów TSpec oraz RSpec wyznaczonych przez odbiorcę (Receiver TSpec and RSpec). Każdy węzeł po otrzymaniu tej informacji sprawdza, czy jest w stanie przeprowadzić rezerwację. Jeżeli posiada wymagane zasoby, wtedy modyfikuje swoje parametry zgodnie z życzeniem odbiorcy zawartym w pakiecie RSVP_Resv. Następnie pakiet ten jest przesłany do sąsiedniego węzła, który został zapamiętany w trakcie przesyłania RSVP_Path. Proces rezerwowania zasobów zostaje zakończony, gdy wiadomość Resv dotrze do nadawcy. Wtedy aplikacja w stacji nadawczej może rozpocząć transmisję.
Obiekt FLOWSPEC może być wielokrotnie modyfikowany zanim dotrze do nadawcy, ponieważ bardzo często w trakcie transmisji następuje sumowanie rezerwacji pochodzących od różnych odbiorców. Po dotarciu do nadawcy, FLOWSPEC zawiera sumaryczną informację o wielkości ruchu, dla którego wykonano rezerwacje.
Rysunek 4.8. Obiekt FLOWSPEC dla usługi CLS [25]
Rysunek 4.9. Obiekt FLOWSPEC dla usługi GS [25]
4.1.4. Wady i zalety modelu IntServ
Intencją modelu lntServ było całościowe (end-to-end) rozwiązanie kwestii zapewnienia jakości usług w sieciach IP. Niestety zamierzenie to okazało się niewykonalne ze względu na wysokie wymagania stawiane ruterom oraz konieczność przystosowania aplikacji do współpracy z protokołem RSVP. Każdy ruter, mający zaimplementowany protokół RSVP wykonuje oddzielne rezerwacje dla każdego z przesyłanych strumieni, co przy dużej liczbie aktywnych nadawców prowadzi do braku skalowalności przyjętego rozwiązania. Innymi słowy, ruter RSVP pracujący w sieci szkieletowej nie jest w stanie utrzymać informacji dotyczącej wszystkich przepływających przez niego strumieni ruchu. Jest to główna wada modelu IntServ przesądzająca o jego nieprzydatności w sieciach szkieletowych operatorów dostarczających usługi internetowe (Internet Service Provider).
Poza brakiem skalowalności, do wad modelu IntServ należy konieczność implementacji protokołu RSVP wraz z mechanizmami kontroli przyjmowania zgłoszeń, klasyfikacją oraz planowaniem wysyłania pakietów we wszystkich hostach i ruterach danej sieci, co w przypadku znacznie rozbudowanych sieci IP jest bardzo trudne, jeżeli wręcz niemożliwe do zrealizowania. W sytuacji, gdy któryś z ruterów biorących udział w transmisji nie posiada zaimplementowanego modelu IntServ, realizowana usługa przestaje być wiarygodna, mimo, iż jej wymagania mogą zostać w danej chwili spełnione. Odbiorca nie posiada, bowiem żadnej gwarancji, że jakość obsługi zostanie utrzymana przez cały okres trwania transmisji.
Obok niezaprzeczalnych wad, IntServ posiada również pewne zalety, przede wszystkim jest zorientowany na odbiorcę usługi, który określa wymagany poziom QoS dla przesyłanego strumienia danych. Uzyskuje on decydujący wpływ na wybór odpowiednich wartości parametrów QoS, które w danym momencie spełniają jego oczekiwania. Podejście to sprzyja również realizowaniu transmisji multicastowej w sytuacji, gdy uczestniczą w niej odbiorcy o różnych wymaganiach w zakresie jakości usług.
Protokół RSVP realizuje dynamiczną jakość obsługi, co oznacza, że zmiana poziomu QoS w trakcie transmisji nie powoduje konieczności przeprowadzania wszystkich rezerwacji od nowa. Każdy ruter biorący udział w transmisji alokuje wtedy dodatkowe zasoby, aby spełnić bieżące oczekiwania odbiorcy w zakresie QoS. Zaletą RSVP jest elastyczne reagowanie na zmiany wyznaczonej trasy połączenia. Ruter, który w określonym czasie nie otrzymał specjalnej wiadomości odświeżającej stan wyznaczonej trasy (path state) jest zobowiązany wskazać nowy węzeł w oparciu o informacje przechowywane w tablicy rutingu. Również stany rezerwacji utrzymywane w ruterach muszą być okresowo odświeżane, w przeciwnym razie zerwana zostanie logiczna droga połączeniowa. Takie podejście zwalnia z obowiązku rozłączania połączenia logicznego i zwiększa odporność systemu na ewentualne awarie [21].
Jakkolwiek model zintegrowanych usług ma istotne wady, mimo to z powodzeniem może być stosowany w sieciach korporacyjnych działających w oparciu o protokół IP. Aby przezwyciężyć ograniczenia związane ze skalowalnością RSVP organizacja IETF opracowała uproszczoną wersję protokołu, co pozwoliło na wykorzystanie go w sieciach szkieletowych, jednak nie pod kontrolą aplikacji, ale systemu zarządzania siecią. Uproszczona wersja RSVP umożliwia miedzy innymi zestawianie ścieżek połączeniowych spełniających wymagania QoS dla zagregowanych strumieni ruchu (explicit route setup). Należy się spodziewać, iż wyznaczanie tras gwarantujących określony poziom QoS w oparciu o możliwości, jakie daje protokół RSVP zostanie wykorzystane w sieciach z wieloprotokołową komutacją etykietową MPLS.
4.2. Architektura usług zróżnicowanych DiffServ
Opracowany przez IETF model usług zróżnicowanych DiffServ [14] jest oparty na koncepcji przyporządkowania pakietów do stosunkowo niewielkiej liczby klas. Tym samym zrezygnowano z podstawowego dla modelu IntServ pełnego rozróżnienia pakietów pochodzących z różnych sesji. Osiągnięto dzięki temu niezależność wielkości zasobów wymaganych do zagwarantowania jakości usług od liczby niezależnych strumieni obsługiwanych w sieci.
Założenia te zostały spełnione przez następujące rozwiązania:
podział sieci implementującej model DiffServ na część brzegową i rdzeniową, z maksymalnym uproszczeniem funkcjonalności węzłów rdzeniowych,
ograniczenie liczby usług różniących się parametrami, maksymalnie do 64.
Zgodnie ze specyfikacją zawartą w dokumencie [14] architektura Differentiated Services jest oparta na prostym modelu, w którym ruch wchodzący do sieci jest klasyfikowany i obsługiwany według kontraktu ruchowego oraz oznaczany jako należący do agregatu zachowań BA (Behaviour Aggregate) tylko na brzegu sieci.
Agregat zachowań BA tworzą wszystkie pakiety mające ten sam punkt kodowy DSCP (DS Code Point) i przesyłane w łączu w określonym kierunku. Oznacza to, że gwarancja jakości dotyczy jednego kierunku transmisji, podobnie jak w modelu IntServ. Węzły rdzeniowe przekazują pakiety tylko na podstawie pola DSCP. Punkt kodowy DSCP jest sześciobitowym polem w nagłówku protokołu IP służącym do określenia przynależności pakietu do klasy usługi. W protokole IPv4 są to bity w polu TOS (Type of Service), w IPv6 DSCP jest reprezentowane przez informacje w polu Service Class [26].
4.2.1. Klasy usług DiffServ
W modelu Differentiated Services niezależne strumienie obsługiwane w tej samej klasie są agregowane i doświadczają tego samego poziomu jakości obsługi QoS. Dla każdego agregatu BA w ruterze definiuje się zestaw reguł przekazywania pakietów PHB (Per Hop Behaviour). Reguły PHB są podstawowymi blokami, z których można tworzyć usługi. Dotychczas zdefiniowano dwa rodzaje PHB:
EF PHB (Expedited Forwarding PHB) [27], zwana także Premium Service [30],
AF PHB (Assured Forwarding PHB Group) [28], zwana także Olimpic Service [30].
EF PHB (Expedited Forwarding PHB)
Klasa EF PHB zapewnia małe opóźnienia pakietów oraz małą zmienność opóźnienia. Pakiety należące do tej klasy mają też zagwarantowane pewne pasmo. Usługa ta (nazywana Premium) może służyć do tworzenia dedykowanych łączy punkt-punkt o określonych parametrach. Zarezerwowany jest dla niej jeden punkt kodowy DSCP.
Utrata pakietów, ich opóźnienie i wartość jittera zależą głównie od przebiegu kolejkowania pakietów w trakcie transmisji przez sieć. Kolejki tworzą się, jeżeli w krótkim czasie ruch nadchodzący jest większy niż przepustowość danego węzła. Stworzenie usługi, dla której zapewniona jest transmisja bez kolejkowania jest równoznaczne z ustaleniem maksymalnego ruchu wejściowego poniżej minimalnej przepustowości dla danego węzła. Utworzenie takiej usługi warunkują dwa podstawowe czynniki [29]:
konfiguracja węzłów tak, aby poszczególne kategorie posiadały statycznie zdefiniowaną minimalną przepustowość (czyli niezależnie od stanu węzła, a w szczególności od jego chwilowego obciążenia),
warunkowanie obsługi danej kategorii (poprzez zarządzanie i kształtowanie) tak, aby ruch nadchodzący był mniejszy niż minimalna przepustowość.
Implementacja EF PHB zapewnia wypełnienie pierwszego z wymienionych warunków natomiast za warunkowanie obsługi ruchu odpowiadają dedykowane funkcje, będące standardowymi komponentami architektury zróżnicowanych usług.
AF PHB (Assured Forwarding PHB Group)
W przypadku klas usług z grupy AF PHB nie ma gwarancji dotyczącej wielkości opóźnienia pakietów. Określa się jedynie, że ruch zgodny z ustalonym profilem będzie dostarczony z prawdopodobieństwem nie niższym niż ustalony próg. Zdefiniowano cztery klasy usług AF. W ramach każdej z nich określono trzy poziomy prawdopodobieństwa odrzucenia pakietu (drop precedence). Pakiety przyporządkowane do danej klasy AF są umieszczane we wspólnej kolejce, a ich kolejność nie może być zmieniana. Poziomy prawdopodobieństwa odrzucenia pakietu służą priorytetyzacji pakietów w kolejce. W sytuacji przeciążenia sieci w pierwszej kolejności z kolejki usuwa się pakiety o największej wartości prawdopodobieństwa odrzucenia. W celu odróżnienia poszczególnych klas tej grupy, w standardzie przyjęto oznaczenie AFij, gdzie 1 ≤ i ≤ 4 oznacza numer klasy, zaś 1 ≤ i ≤ 3 oznacza poziom prawdopodobieństwa odrzucenia pakietu. Przyjęto, że j = 1 oznacza małe, j = 2 średnie, zaś j = 3 duże prawdopodobieństwo odrzucenia pakietu. Jakość usług w ramach danej klasy AF zależy głównie od wielkości przydzielonych dla niej zasobów sieciowych.
Węzły zgodne z DiffServ powinny spełniać następujące warunki:
pełna obsługa czterech globalnych klas,
pakiety każdej z klas globalnych muszą być nadawane niezależnie od pakietów innych klas, nie może zaistnieć łączenie pakietów różnych klas,
dla każdej klasy globalnej muszą być zarezerwowane wystarczające dla poprawnej obsługi zasoby (bufor i pasmo),
obsługa każdej klasy powinna być prowadzona na poziomie współczynników obsługi, biorąc pod uwagę zarówno szerokie jak i wąskie spektrum czasowe,
jeżeli dla konkretnej klasy, dla dwóch kryteriów usuwania k, n przy czym k > n, n musi oznaczać większe prawdopodobieństwo dostarczenia,
w obrębie każdej klasy AF węzeł musi obsługiwać wszystkie trzy kryteria usuwania,
składowe reguły PHB różnią się prawdopodobieństwem odrzucenia pakietu - dla AFxl musi oznaczać mniejsze prawdopodobieństwo utraty pakietu niż AFx2 oraz AFx3,
węzeł DiffServ nie może zmieniać kolejności pakietów AF pochodzących z tego samego strumienia w przypadku gdy należą do tej samej grupy AF niezależnie od kryterium usuwania.
Rekomendowane wartości DSCP mają następującą postać (tabela 4.2.):
Tabela 4.2. Wartości DSCP dla PSC (PHB Scheduling Class)
AFxx |
DSCP |
AF11 |
001010 |
AF12 |
001100 |
AF13 |
001110 |
AF21 |
010010 |
AF22 |
010100 |
AF23 |
010110 |
AF31 |
011010 |
AF32 |
011100 |
AF33 |
011110 |
AF41 |
100010 |
AF42 |
100100 |
AF43 |
100110 |
4.2.2. Klasyfikacja i oznaczanie pakietów
Przynależność pakietu do danej klasy usług w sieci DiffServ jest jednoznacznie określona przez wartość punktu kodowego DSCP (Differentiated Services Code Point), którego definicja została określona w RFC 2474 [26]. Punkt kodowy ma długość sześciu bitów i jest częścią jednobajtowego pola DS (Differentiated Services Field). Pole DS jest przenoszone w nagłówku pakietu IP. W wersji 4 protokołu IP wykorzystuje się w tym celu bajt TOS (Type of Service), zaś w protokole IPv6 bajt Traffic CIass.
Rysunek 4.10. Struktura pola DS
Strukturę pola DS przedstawiono na rysunku 4.10. Bity 6 i 7 nie są aktualnie używane. Przestrzeń kodów DSCP podzielono na trzy obszary (tabela 4.2.). Obszary 2 i 3, obejmujące łącznie 32 wartości, zostały zarezerwowane do celów eksperymentalnych. Pozostałe kody (obszar 1) mogą być używane do oznaczania klas usług. Zgodnie ze standardem, wartości z obszaru 3 mocą być dodatkowo użyte do oznaczania klas usług w przypadku, gdy kody z obszaru 1 zostaną wyczerpane.
Tabela 4.3. Podział przestrzeni kodów DSCP
Obszar |
Przestrzeń kodowa |
Wykorzystanie |
1 |
xxxxx0 |
Oznaczenie klas usług |
2 |
xxxx11 |
Do celów eksperymentalnych |
3 |
xxxx01 |
Do celów eksperymentalnych |
x - oznacza 0 lub 1 |
||
Odpowiednie dokumenty IETF definiują przyporządkowanie konkretnych wartości punktu kodowego do poszczególnych klas usług. Usłudze niesklasyfikowanej przypisano wartość 000000, zaś usłudze EF - 101110. W tabeli 4.2. zestawiono przyporządkowanie kodów DSCP dla klas AF. Wartość selektora klasy w ramach jednej klasy AF jest stała. Bity 3 i 4 przechowują informację o prawdopodobieństwie odrzucenia pakietu. Niskiemu prawdopodobieństwu odpowiada wartość 01, średniemu 10, zaś wysokiemu 11. Notacja ta jest wspólna dla wszystkich czterech klas AF.
Przedstawione przyporządkowanie jest zalecane przez IETF. Zakłada się jednak, że administrator domeny może stosować dowolne powiązania, a także definiować inne klasy usług.
Tabela 4.4. Zestawienie wartości punktów kodowych dla klas AF
Prawdopodobieństwo odrzucenia pakietu |
Klasa 1 |
Klasa 2 |
Klasa 3 |
Klasa 4 |
Niskie |
001010 |
010010 |
011010 |
100010 |
Średnie |
001100 |
010100 |
011100 |
100100 |
Wysokie |
001110 |
010110 |
011110 |
100110 |
Przydzielenie pakietu do klasy usług odbywa się w wejściowym ruterze brzegowym w chwili wejścia pakietu do domeny DiffServ. Po przypisaniu pakietu do klasy usług nadawana jest mu odpowiednia wartość punktu kodowego. Wszystkie pakiety, mające taki sam punkt kodowy, tworzą zespół zachowań BA (Behaviour Aggregate). Pakiety te są jednakowo traktowane w ramach domeny. Sposób przesyłania pakietów określają reguły przesyłania pakietów PHB (Per Hop Behaviour). Powinny one być zdefiniowane w każdym węźle, dla wszystkich obsługiwanych klas usług (zestawów zachowań). Reguły PHB, odpowiadające danej klasie usług mogą jednak różnić się w poszczególnych węzłach. Administrator domeny musi tak skonfigurować rutery, aby zapewnić odpowiedni poziom jakości usług.
Standard określa, że w danym węźle jednej wartości punktu kodowego powinna odpowiadać jedna reguła PHB. Ponieważ każdej z czterech klas usług zagwarantowanych AF odpowiadają trzy wartości punktu kodowego, wprowadzono pojęcie zbioru uporządkowanego reguł przesyłania pakietów - PSC (PHB Scheduling Class) [11]. PSC jest to zbiór reguł PHB powiązanych dodatkowym warunkiem, że pakiety podlegające tym regułom muszą być umieszczane w jednej kolejce, a ich kolejność nie może być zmieniana. Składowe reguły PHB różnią się prawdopodobieństwem odrzucenia pakietu. Przykładowo zbiór PSC AF1x składa się z trzech reguł PHB: AF11 PHB, AF12 PHB oraz AF13 PHB. Z klasą usług zagwarantowanych AF jest też związane pojęcie uporządkowanego zestawu zachowań OA (Ordered Aggregate) [11]. Tworzą go wszystkie pakiety należące do jednej klasy AF, a więc trzech zestawów zachowań BA. Ich wspólną cechą jest to, że są obsługiwane przez tę samą kolejkę.
Kody DSCP mogą być nadawane pakietom również przez aplikacje. Jeżeli dana aplikacja będzie uznawana przez domenę za zaufaną, dokonywane przez nią przydzielenie pakietu do określonej klasy usług będzie w domenie respektowane. W przeciwnym razie pakiety będą klasyfikowane przez węzły wejściowe ponownie.
4.2.3. Architektura sieci DiffServ
W sieci IP może istnieć wiele domen DiffServ, będących ściśle określonym zbiorem węzłów. Domeny są niezależne, ale mogą ze sobą współpracować. Obszar sieci, składający się z wielu ściśle ze sobą współpracujących domen, tworzy region. W każdej domenie DiffServ wyróżnia się węzły brzegowe i rdzeniowe. Wśród węzłów brzegowych można wyróżnić węzły wejściowe (przez które ruch wpływa do domeny) i wyjściowe (przez które ruch opuszcza domenę). Są one odpowiedzialne za wymuszenie odpowiednich charakterystyk ruchu wejściowego i wyjściowego zgodnie z porozumieniem TCA (Traffic Conditioning Agreement). W węzłach tych podejmuje się również decyzję o przypisaniu pakietów do odpowiedniej klasy usług. Węzły rdzeniowe stanowią szkielet domeny DiffServ i nie mają bezpośredniego połączenia z węzłami spoza domeny. Węzły te mogą również wykonywać pewne funkcje zapewniające zachowanie charakterystyk ruchu. W każdym węźle znajduje się zbiór reguł przesyłania pakietów PHB (Per Hop Behaviour). Reguły te są zdefiniowane dla każdej klasy usług obsługiwanej w domenie. Obowiązują one w relacji do sąsiedniego rutera. W dokumentach IETF reguły PHB nie są zdefiniowane ilościowo, ale jedynie jakościowo i mogą różnić się w zależności od domeny. Decyzja o nadaniu konkretnych parametrów ilościowych należy do administratora domeny (systemu zarządzającego) [23].
Na architekturę DiffServ składają się liczne elementy funkcjonalne implementowane w węzłach sieci. Są to następujące komponenty [27]:
zestawy opcji skoku (PHB),
funkcje klasyfikacji pakietów,
funkcje warunkujące obsługę ruchu,
funkcje mierzące właściwości ruchu (metering),
funkcje oznaczające,
funkcje kształtujące ruch,
mechanizmy wykonawcze(policing).
Architektura DiffServ jest skalowana dzięki implementacji kompleksowej funkcjonalności, dokonującej klasyfikacji i warunkowania obsługi jedynie w węzłach granicznych sieci DiffServ. Dla pozostałych węzłów (wewnętrznych) funkcjonalność DiffServ jest znacznie uproszczona.
Model architektury DiffServ
Architektura DiffServ jest oparta na prostym modelu: ruch w węzłach granicznych jest klasyfikowany, dokonywane jest warunkowanie obsługi (traffic conditioning) oraz następuje przypisanie do konkretnej grupy opcji skoku (behavior aggregates). Każda kategoria jest identyfikowana przez pojedynczą wartość pola DSCP. Pakiety są nadawane poprzez sieć DiffServ zgodnie z opcjami przypisanymi do konkretnej kategorii.
Składniki modelu architektury DiffServ:
Domena DiffServ jest to domena składająca się z zestawu węzłów zgodnych z DiffServ, które pracują ze standardowym mechanizmem zapewniania usług i obsługi zestawu PHB posiadanym przez węzły domeny. Domena DiffServ posiada ściśle określone granice, składające się z węzłów granicznych dokonujących klasyfikacji i ewentualnego formowania ruchu wejściowego, tak, aby cały ruch wchodzący był przypisany do odpowiednich opcji skoku (PHB) obsługiwanych przez węzły danej domeny. Mapowanie wartości DSCP na opcje skoków może być domyślne lub skonfigurowane lokalnie. Włączenie w obręb domeny węzła nieobsługującego całego zestawu opcji skoków danej domeny może spowodować niewłaściwą obsługę poszczególnych kategorii ruchu przechodzącego przez ten węzeł. Wypadkowa efektywność DiffServ zależy do prawidłowej obsługi kategorii ruchowych we wszystkich węzłach pośrednich. Już jeden węzeł niezgodny z DiffServ (w obrębie domeny) powoduje spadek efektywności całego mechanizmu. Analogicznie jak dla łańcucha decyduje najsłabsze ogniwo. Standardowo, domena DiffServ składa się z jednej lub kilku sieci pod wspólną administracją. Administracja domeny odpowiedzialna jest za zapewnienie wystarczających zasobów sieciowych dla obsługi na odpowiednim poziomie konkretnego natężenia ruchu dla poszczególnych kategorii ruchowych, wyspecyfikowanych w zawartych umowach o poziomie obsługi SLA (Service Level Agreement).
Węzły graniczne i wewnętrzne są to węzły, które graniczne łączą domenę DiffServ ze światem zewnętrznym. Może to być inna domena, zgodna z DiffServ lub niezgodna, podczas gdy węzły wewnętrzne są połączone tylko z innymi węzłami w obrębie domeny. Węzły graniczne mają rozszerzoną funkcjonalność w stosunku do węzłów wewnętrznych a mianowicie posiadają dodatkowo funkcje warunkowania obsługi ruchu implementowane zgodnie z definicją w TCA (Traffic Conditioning Agreement). Oba rodzaje węzłów muszą poprawnie stosować opcje skoków, bazując na odpowiednich wartościach DSCP. Węzły wewnętrzne mogą także stosować funkcje warunkujące obsługę ruchu, takie jak np. ponowne oznaczanie, czyli modyfikacje wartości DSCP.
Region DiffServ jest to zbiór składający się z domen DiffServ. W regionie DiffServ na każdej trasie biegnącej wewnątrz regionu występują tylko węzły wspierające DiffServ. Domeny w obrębie pojedynczego regionu mogą posiadać inne wewnętrzne PHB i schematy mapowania DSCP => PHB. Jednak w celu jednoznacznego określenia obsługi przez daną domenę ruchu pochodzącego z innej domeny, muszą istnieć umowy o poziomie obsługi SLA pomiędzy tymi domenami.
Rysunek 4.11. Region i domeny DiffServ
4.2.4. Budowa węzła sieci DiffServ i jego funkcje
Uproszczony schemat węzła sieci DiffServ przedstawiono na rysunku 4.12. Składa się on z dwóch podstawowych bloków: klasyfikatora pakietów (classifier) oraz urządzenia sprawdzającego i kształtującego charakterystykę ruchu (traffic conditioner). Zadaniem klasyfikatora jest przyporządkowanie pakietów wchodzących do rutera do poszczególnych klas usług. Klasyfikacja pakietów może odbywać się na podstawie:
wartości jednego lub wielu pól nagłówka pakietu IP (np. adresu i numeru portu nadawcy czy identyfikatora protokołu transportowego) - klasyfikator typu MF (Multi-Field classifier),
wartości punktu kodowego (pakiet może pochodzić od zaufanego klienta domeny DiffServ lub z innej domeny, gdzie nadano mu wcześniej punkt kodowy) - klasyfikator typu BA (Behaviour Aggregate classifier).
Kryteria klasyfikacji muszą być zgodne z zawartymi z klientami umowami (SLA).
Rysunek 4.12. Schemat podstawowych elementów węzła sieci DiffServ [14]
Urządzenie sprawdzające i kształtujące charakterystykę ruchu składa się z kilku elementów:
Jednostka pomiarowa (meter) ma za zadanie sprawdzać zgodność chwilowych właściwości strumienia pakietów, należącego do danej klasy usług, z zadeklarowanym profilem ruchu określonym przez porozumienie TCA. Uzyskana w ten sposób informacja o zgodności pakietu z profilem ruchu jest przekazywana do pozostałych jednostek. Najprawdopodobniej, dla gromadzenia statystyki wykorzystana zostanie baza protokołu SMTP (Simple Mail Transfer Protocol) MIB (Management Information Base). DiffServ MIB nie jest jeszcze zdefiniowana. Istnieją bowiem wątpliwości związane ze stopniem precyzji (granularity) który miała by zapewnić (np. czy używać metryki dla każdego PHB).
W jednostce oznaczającej pakiety (marker) każdy pakiet otrzymuje punkt kodowy. Jeżeli pakiet jest zgodny z zadeklarowanym profilem ruchu, nadawana wartość punktu kodowego odpowiada klasie usług, do której został przydzielony przez klasyfikator. W przeciwnym razie pakiet może być przeniesiony do niższej klasy usług i oznaczony innym punktem kodowym. A zatem jednostka ta używana jest w celu:
ustalenia wartości DSCP jeżeli pole to jeszcze nie jest używane (węzeł wejściowy sieci DiffServ),
ustalenia wartości DSCP na podstawie mapowania, np. parametrów RSVP,
mapowanie TOS lub odwrotnie,
zmiany wartości DSCP, jak dyktuje lokalny mechanizm zarządzania (local policy).
Jednostka kształtująca ruch oraz jednostka odrzucająca pakiety mają za zadanie dopasować właściwości strumienia pakietów do zadeklarowanego profilu ruchu przez opóźnianie pakietów w buforach lub ich odrzucanie. Wykonywane mogą być następujące czynności:
wybór kolejki,
wybór sposobu „traktowania" pakietów,
funkcje nadzorowania: kształtowanie pasma (shaping) poprzez opóźnianie lub usuwanie części pakietów w celu zapewnienia zgodności ze zdefiniowanym w SLA (Service Level Agrement) profilem,
może być także dokonywana weryfikacja autentyczności pakietów dla potrzeb funkcji kontroli dostępu.
4.2.5. Architektura funkcjonalna DiffServ
Klasyfikacja i warunkowanie obsługi ruchu
Zasięg działania DiffServ jest przedłużany poza granice własnej domeny, poprzez istnienie umów o poziomie obsługi (SLA) pomiędzy domeną zgodną z DiffServ i konkretną podsiecią zewnętrzną. SLA określa zasady klasyfikacji pakietów oraz oznaczania pakietów z wewnątrz jak i spoza zdefiniowanego profilu. Umowa o warunkowaniu ruchu (TCA - Traffic
Conditioning Agreement) bardziej szczegółowo precyzuje zasady obsługi pakietów a wywodzi się (bezpośrednio lub pośrednio) z SLA.
Mechanizm warunkowania obsługi pakietów w celu zapewnienia zgodności charakterystyk ruchu wchodzącego do domeny DiffServ z zasadami określonymi w TCA, wykonuje następujące czynności: pomiary, kształtowanie ruchu, zarządzanie ruchem, oznaczanie. Wszystko to odbywa się pod kontrolą funkcji zarządzających dla całej domeny DiffServ. Wymagany zakres warunkowania obsługi ruchu jest zależny od specyfiki oferowanych usług i może zawierać się w zakresie, od prostego oznaczania do kompleksowej obsługi wraz z operacjami kształtowania ruchu.
Klasyfikatory
Klasyfikatory pakietów dokonują selekcji, bazując na analizie informacji zapisanych w wybranych polach nagłówka pakietu. Wyróżniamy dwa typy klasyfikatorów:
klasyfikator typu BA (Behaviour Aggregate classifier), podejmujący działanie jedynie na podstawie wartości pola DSCP,
klasyfikator typu MF (Multi-Field classifier), wykorzystujący wartości jednego lub wielu pól nagłówka pakietu IP (np. adresu i numeru portu nadawcy czy identyfikatora protokołu transportowego).
Klasyfikatory są używane do kierowania pakietów spełniających określone kryteria do elementu funkcjonalnego, aby dane pakiety obsłużyć. Klasyfikatory muszą zostać skonfigurowane przez procedurę zarządzającą zgodnie z odpowiednią specyfikacją TCA. Klasyfikatory powinny dokonywać autoryzacji informacji, która jest używana do klasyfikacji pakietu.
Profile ruchowe
Profil ruchowy specyfikuje właściwości strumienia ruchu wybranego przez klasyfikator. Profil zapewnia zasady określania czy dany pakiet jest z wewnątrz, czy spoza profilu. Na przykład, profil bazujący na wiadrze tokenów może mieć postać: DSCP=X, wiadro tokenów o parametrach: r, b. Taki zdefiniowany profil wskazuje, że wszystkie pakiety, dla których wartość DSCP wynosi X, powinny być mierzone zgodnie z miarami określonymi dla wiadra tokenów o zadanych parametrach. W tym przykładzie pakiety te będziemy traktować jako spoza profilu, dla których w chwili ich nadejścia nie dysponujemy wystarczającą liczbą tokenów w wiadrze. Kategoryzacja pakietów może zostać rozszerzona w stosunku do tradycyjnego podziału na te z wewnątrz i z zewnątrz profilu, spowoduje to wyróżnienie jeszcze kilku kategorii pośrednich. Pakiety mieszczące się w zdefiniowanym profilu mogą np. przekraczać granicę domeny DiffServ bez wykonywania w odniesieniu do nich czynności warunkowania obsługi, lub np. wartości DSCP mogą być dla nich modyfikowane. To drugie podejście oznacza zmianę wartości DSCP na wartość inną niż domyślną. Pakiety spoza profilu mogą być traktowane w zależności od konfiguracji: mogą być kolejkowane (opóźniane) tak, aby mieściły się w profilu, usuwane, oznaczane nową wartością DSCP, nadawane normalnie przy jednoczesnej taryfikacji dodatkowego pasma. Profil jest opcjonalnym komponentem TCA a jego zastosowanie jest zależne od oferowanych usług i konfiguracji mechanizmów zarządzania dostarczanymi usługami.
Mechanizmy warunkowania obsługi ruchu
Mechanizmy warunkowania obsługi ruchu składają się z następujących komponentów:
klasyfikator,
jednostka pomiarowa,
jednostka oznaczająca pakiety,
jednostka kształtująca ruch, odrzucająca pakiety.
Strumień jest wyróżniany przez klasyfikator, który kieruje tak wyróżnione pakiety do logicznego mechanizmu kształtującego charakterystykę ruchu. Jednostka pomiarowa ma za zadnie stwierdzanie zgodności charakterystyk danego strumienia pakietów ze zdefiniowanym profilem. Wynik weryfikacji (w odniesieniu do konkretnych pakietów) decyduje, czy dokonane zostanie np. ponowne oznaczenie, czy kształtowanie. Po przejściu przez mechanizmy warunkowania obsługi ruchu w węzłach granicznych, wartość DSCP dla każdego pakietu musi mieć wartość ustaloną dla obsługi w całej domenie DiffServ.
Alokacja zasobów sieciowych
Efektywny rozdział zasobów sieciowych realizowany jest poprzez implementację, konfigurację i wreszcie działanie grup opcji skoków. Zarządzane są zarówno zasoby łączące domenę ze światem zewnętrznym jak i łącza wewnątrz domeny, tak, aby wszystkie kategorie ruchowe zostały właściwie obsłużone. Realizacja usług może się opierać o statyczne mechanizmy mapowania (mapowanie DSCP=>PHB w węzłach granicznych => funkcje obsługi w hostach wewnętrznych), lub o stosowanie mechanizmów dynamicznej zmiany DSCP (zmiana PHB), kształtowania i kompleksowego zarządzania ruchem. Funkcje te znacznie zwiększają możliwy do obsłużenia ruch przy identycznych zasobach. Celowe jest, więc implementowanie dynamicznych funkcji zarządzających zasobami, zwiększają one, bowiem efektywność wykorzystania posiadanych zasobów. Konfiguracja współpracy pomiędzy mechanizmami formowania ruchu i wewnętrznymi węzłami domeny powinna być zarządzana na poziomie domeny i może wymagać implementacji dedykowanych mechanizmów i kontroli poprzez protokoły. Skalowalność wymaga, aby mechanizmy zarządzania nie operowały na poziomie pojedynczego strumienia.
4.2.6. Zarządzanie zasobami w domenie DiffServ
W sieciach DiffServ w zasadzie nie jest wymagana sygnalizacja. Stanowi to jedną z istotniejszych cech różniących modele IntServ i DiffServ. W przypadku protokołu RSVP informacja o zadanych parametrach jakości obsługi pakietów jest ściśle związana z pojedynczym strumieniem. Dzięki sygnalizacji poszczególne węzły są niejako konfigurowane dynamicznie dla potrzeb konkretnej sesji. W modelu DiffServ wszystkie węzły muszą być skonfigurowane statycznie, odgórnie przez system zarządzający (top-down provisioning). Z jednej strony eliminuje to konieczność przesyłania i obsługi dużego ruchu sygnalizacyjnego. Z drugiej zaś strony rodzi to szereg problemów. Wszystkie węzły w domenie muszą mieć spójne reguły klasyfikowania pakietów oraz reguły obsługi pakietów należących do poszczególnych klas usług. Administrator domeny musi tak skonfigurować rutery wejściowe, aby mogły jednoznacznie rozpoznawać pakiety pochodzące od konkretnych użytkowników czy aplikacji. Obowiązujące w sieci reguły przesyłania pakietów i parametry poszczególnych klas usług powinny zapewnić im jakość obsługi zgodną z zawartym porozumieniem SLA. Utrudnione jest zapewnienie jakości obsługi ruchu generowanego przez aplikacje korzystające z tymczasowych numerów portów czy też ruchu o parametrach nieodpowiadających zdefiniowanym w domenie klasom usług [23].
W celu wprowadzenia możliwości dynamicznego konfigurowania węzłów sieci, opracowano koncepcję zarządcy zasobów (bandwidth broker) [30]. W sieci może pojawić się potrzeba obsługi strumienia o takich parametrach, że w ramach obowiązujących w domenie klas usług nie da się mu zagwarantować wymaganej jakości. Pojawia się wówczas konieczność dynamicznego zdefiniowania nowej klasy usług i skonfigurowania odpowiednich reguł przesyłania pakietów. W tym celu w każdej domenie powinien być wyróżniony jeden ruter, zwany zarządcą zasobów, do którego przesyła się żądanie utworzenia nowej usługi. Jeżeli jest to możliwe, zarządca zasobów rozsyła informacje konfiguracyjne do poszczególnych ruterów w domenie. Koncepcja ta wymaga zastosowania protokołu sygnalizacyjnego, którym może być np. RSVP.
Rysunek 4.13. Zastosowanie zarządcy zasobów (bandwidth broker) w celu dynamicznego konfigurowania węzłów sieci
Host A zwraca się z żądaniem obsługi do lokalnego BB, czyli N1-BB wysyłając wiadomość PATH RSVP. Jeśli N1-BB odrzuci żądanie przesyła wiadomość do hosta A i kończy proces sygnalizacji. Host może wysłać dane jako „best-effort”, lub zgłosić żądanie transmisji w ramach usługi niższej klasy. Jeśli N1-BB zaakceptuje żądanie przesyła wiadomość PATH do N2-BB. Ten żądanie odrzuca i przesyła informację do CN1-BB, lub też akceptuje i przesyła wiadomość PATH do N2-BB. Jeśli N2-BB zaakceptuje żądanie konfiguruje router ER2 odpowednimi regułami klasyfikacji i policingu, a następnie odsyła wiadomość RESV do routera N2-BB. Ten po skonfigurowaniu routerów BR1 i BR2 odsyła RESV do N1-BB, który konfiguruje router ER1, oraz router LR1, do którego dołączony jest host i który musi przeprowadzić klasyfikację MF (Multi-Field) i ewentualnie ukształtować ruch na zgodny z wynegocjowanym SLA. Następnie informuje o tym host A, który rozpoczyna transmisję przebiegającą według mechanizmów DiffServ.
4.3. Współpraca modeli IntServ i DiffServ
Model usług zintegrowanych IntServ oraz model usług zróżnicowanych DiffServ są technikami wzajemnie się uzupełniającymi. Można je stosować w różnych obszarach sieci. Protokół sygnalizacyjny RSVP, opracowany dla modelu IntServ, pozwala zapewniać żądaną jakość obsługi pojedynczym strumieniom danych w relacji od końca do końca. Nie może on być jednak stosowany w dużych sieciach ze względu na omówione wcześniej problemy skalowalności. Model DiffServ, dzięki ograniczeniu liczby klas usług oraz rezygnacji z protokołu sygnalizacyjnego, nie ma problemów ze skalowalnością i dobrze nadaje się do stosowania w dużych sieciach. Nie zapewnia jednak pełnego rozróżnienia pakietów pochodzących z różnych aplikacji, uniemożliwia to pełne ilościowe zagwarantowanie parametrów transmisji dla poszczególnych strumieni ruchu. Korzystając z najważniejszych zalet modeli IntServ i DiffServ opracowano podstawowe zasady ich współpracy [31]. Zakłada się, że model IntServ będzie stosowany w obszarze sieci dostępowej, obsługującej stosunkowo niewielką liczbę użytkowników, a zatem umiarkowaną liczbę pojedynczych strumieni danych wymagających rezerwacji zasobów sieciowych. Z kolei model DiffServ, obsługujący ruch zagregowany, będzie stosowany w sieciach szkieletowych jako element pośredniczący w zapewnieniu jakości usług w relacji od końca do końca.
4.3.1. Architektura sieci
Architekturę sieci IP z gwarancją jakości usług zrealizowaną z użyciem modeli IntServ i DiffServ, zaproponowaną przez IETF, przedstawiono na rysunku 4.13. Można wyróżnić obszary sieci dostępowej, nie wspierające architektury usług zróżnicowanych, do której są przyłączeni użytkownicy końcowi oraz sieć szkieletową, którą stanowi region DiffServ.
Rysunek 4.14. Przykładowa architektura sieci IP z zastosowaniem Modeli IntServ i DiffServ
Rezerwacja zasobów jest realizowana przez sygnalizację RSVP w relacji od końca do końca, między nadawcą i odbiorcą. Z punktu widzenia sygnalizacji region DiffServ jest pojedynczym elementem sieci. Na granicy regionu DiffServ znajdują się rutery brzegowe BR1 i BR2. Ich funkcjonalność zależy od praktycznej realizacji sieci. Jeżeli obsługują pro tokół RSVP, wówczas region DiffServ jest określany jako zgodny z RSVP. W przeciwnym przypadku region jest niezgodny z RSVP. Rutery wewnątrz regionu DiffServ również mogą, lecz nie muszą, przetwarzać komunikaty RSVP. Sieć poza regionem DiffServ składa się z siatki ruterów, z których przynajmniej część obsługuje protokół RSVP. Na granicy obszarów sieci nie wspierających architektury usług zróżnicowanych znajdują się rutery brzegowe ER1 i ER2. Są one bezpośrednio połączone z ruterami brzegowymi regionu DiffServ.
W najprostszym przypadku region DiffServ jest skonfigurowany statycznie, oferując niezmienny zbiór klas usług. Komunikaty RSVP są wówczas przenoszone w sposób przezroczysty pomiędzy ruterami brzegowymi. Jeżeli przynajmniej niektóre rutery w regionie DiffServ obsługują sygnalizację RSVP, wówczas zarządzanie zasobami może odbywać się w sposób dynamiczny. Nie dokonuje się jednak rezerwacji zasobów dla pojedynczych strumieni. Są one przydzielane strumieniom zagregowanym na podstawie wartości punktu kodowego. W praktyce konieczne było rozszerzenie protokołu RSVP o nowy obiekt DCLASS służący do przenoszenia wartości DSCP wewnątrz komunikatów [32]. Omówiony mechanizm zarządzania zasobami pozwala skorzystać z zalet sygnalizacji RSVP przy jednoczesnym zachowaniu skalowalności modelu DiffServ.
Zestawienie połączenia end-to-end
Rysunek 4.15. Sekwencja zestawiania połączenia end-to-end z wykorzystaniem protokołu RSVP
Host A inicjujący połączenie generuje komunikat RSVP PATH message opisujący strumień, jaki ma zamiar wygenerować.
Ten komunikat jest przenoszony do hosta przeznaczenia B. W domenie hosta komunikat żąda od odpowiednich węzłów dostępu do zasobów przy użyciu RSVP/IntServ.
W routerze brzegowym ER1 komunikat jest poddawany zamianie na standardowy RSVP, a stan PATH wprowadzany do routera ER1. Sam komunikat wędruje dalej w głąb DiffServ.
Wewnętrzne routery DiffServ ignorują komunikat, aż do kolejnego routera brzegowego ER2, który analizuje wiadomość RSVP.
Kiedy PATH message dotrze do hosta przeznaczenia B, ten generuje komunikat RESV message, informując w ten sposób o chęci nawiązania połączenia z hostem A.
Ta wiadomość jest kierowana przez domenę DiffServ z powrotem do hosta A. Zgodnie ze standardem RSVP/IntServ każdy upoważniony węzeł domeny hosta B może odmówić zestawienia połączenia z powodu braku wolnych zasobów.
W routerze ER2 następuje zamiana RSVP. Strumień oczywiście może być odrzucony, jeśli domena nie może zagwarantować obsługi tego strumienia. Jeśli strumień nie został odrzucony jest przenoszony transparentnie przez obszar DiffServ.
W routerze ER1 następuje kontrola dostępu do zasobów DiffServ na odpowiednim poziomie, wynikłym z uprzedniego mapowaia poziomu QoS z InServ.
Jeśli ER1 przyjmie strumień, komunikat RESV message jest dopuszczony do domeny Intserv i podąża dalej w kierunku hosta A, w przeciwnym przypadku wysyłany jest komunikat o błędzie. Jeśli strumień został dopuszczony router ER1 zaznacza w swojej bazie danych zmniejszenie przepustowości.
Komunikat RSVP przemierzając domenę IntServ do hosta A może być odrzucony przez każdy napotkany węzeł.
PATH message w hoście A oznacza przyjęcie przez sieć ruchu na żądanym poziomie QoS.
Host B może ustawiać pole DSCP nagłówka pakietów przyjętego strumienia w sposób domyślny (default) transformujący poziom QoS z Intserv na poziom DiffServ, lub zgodnie z informacją otrzymaną w PATH message.
4.3.2. Odwzorowanie mechanizmów sterowania ruchem oraz klas usług
W celu zapewnienia wysokiej jakości usług w relacji od końca do końca konieczne jest określenie zasad współpracy mechanizmów sterowania ruchem stosowanych w sieciach IntServ i DiffServ [33].
Odpowiednikiem mechanizmu szeregowania pakietów modelu IntServ są w sieci DiffServ reguły przesyłania pakietów PHB. Reguły te powinny być tak skonfigurowane, aby widziany z zewnątrz region DiffServ działał, z punktu widzenia każdego pojedynczego strumienia, jak jeden ruter RSVP zapewniający żądaną jakość obsługi.
Zgodnie z założeniami modelu DiffServ każdy pakiet wchodzący do domeny musi zostać przydzielony do jednej z klas usług w niej obowiązujących oraz oznaczony odpowiednią wartością punktu kodowego. Klasyfikacja ruchu i oznaczanie pakietów może odbywać się w ruterze brzegowym regionu DiffServ (BR1) lub w ruterze brzegowym obszaru niewspierającego architektury usług zróżnicowanych (ER1), który musi być traktowany przez region DiffServ jako zaufany. W obu przypadkach węzeł musi mieć zaimplementowany klasyfikator typu MP oraz jednostkę oznaczającą pakiety. W celu zapewnienia współpracy mechanizmów sterowania przyjmowaniem zgłoszeń konieczne jest określenie sposobu sprawdzania dostępności zasobów w sieci DiffServ oraz sposobu wymiany uzyskanej informacji pomiędzy węzłami IntServ i DiffServ. Jeżeli region DiffServ jest skonfigurowany statycznie, funkcje te może pełnić dowolny węzeł. Jeżeli zasoby regionu są zarządzane dynamicznie, wówczas funkcje sterowania przyjmowaniem zgłoszeń może pełnić zarządca zasobów lub protokół sygnalizacyjny zastosowany do dynamicznego konfigurowania ruterów. Mechanizmy sterowania przyjmowaniem zgłoszeń stosowane w regionie DiffServ i poza nim są niezależne.
Jak wspomniano wcześniej, przed wejściem pakietów do regionu DiffServ musi zostać dokonane sprawdzanie zgodności charakterystyki ruchowej strumienia danych z kontraktem ruchowym oraz jej kształtowanie. Operacje te mogą być wykonywane w ruterze brzegowym regionu DiffServ, po klasyfikacji pakietów (na ruchu zagregowanym). Zakłada się też możliwość przeniesienia tej funkcjonalności do ruterów brzegowych obszaru niewspierającego architektury usług zróżnicowanych. Pociąga to za sobą konieczność wykonywania tych operacji na każdym pojedynczym strumieniu danych.
Zdefiniowanie zasad współpracy mechanizmów sterowania ruchem jest podstawą do określenia reguł odwzorowania usług modelu IntServ na usługi modelu DiffServ. Dotychczas zaproponowano realizację usługi gwarantowanej GS z użyciem usługi premiowanej EF oraz sposoby wykorzystania usług EF i AF do realizacji usługi kontrolowanego obciążenia CL [33].
4.4. MPLS - Wieloprotokołowa Komutacja Etykiet
Budowa sieci konwergentnych jest procesem ewolucyjnym łączącym w sobie aspekty zastosowania ruterów i przełączników. Należy go rozpatrywać z punktu widzenia zarówno rozwoju sprzętu sieciowego, jak i z punktu widzenia procesów standaryzacyjnych. Każda z tych dwóch podstawowych technik: przełączania ATM i rutowania IP ma swoje zalety i wady. Krótkie porównanie obu tych technik umożliwia tabela 4.5.
Tabela 4.5. Zalety i wady technik przełączania i rutowania
Technika |
Zalety |
Wady |
Przełączanie ATM |
Możliwość zarządzania ruchem |
Duża liczba ścieżek |
|
Kontrola błędów i alarmów |
Duża nadmiarowość w stosunku do informacji użytecznej |
|
Zarządzanie siecią
|
|
Ruting IP |
Zdolność do zarządzania jakością |
|
|
Dynamiczny wybór drogi |
Trudności w zarządzaniu ruchem |
|
Możliwość połączeń każdy z każdym |
Zmienna wydajność |
|
Łatwość realizacji nowych usług |
|
Obecnie rutowanie pakietów w Internecie jest realizowane z wykorzystaniem standardowych protokołów rutingu. Protokoły IGP (Interior Gateway Protocols), takie jak OSPF (Open Shortest Path First) i RIP (Routing Information Protocol) są używane w obrębie systemów autonomicznych, natomiast protokoły EGP (Exterior Gateway Protocols), takie jak BGP4 (Border Gatewey Prorocol) są używane w celu łączenia między sobą systemów autonomicznych.
Klasyczne protokoły IGP i EGP umożliwiają w niewielkim stopniu przekazywanie informacji potrzebnych do zarządzania ruchem lub nie potrafią realizować tego wcale. Do dobrego zarządzania ruchem są niezbędne uaktualnione opisy dostępnych zasobów, ich cech, stopnia wykorzystania, aktualnego stanu itp. Ponadto w przypadku stosowania algorytmów rutingu, takich jak wybór najkrótszej ścieżki (shortest path first) lub wektor odległości (distance vector), pojawia się tendencja wybierania drogi przesyłania pakietów przez te same drogi i interfejsy. Powoduje to przeciążenia w sieci i nienajlepsze wykorzystanie dostępnych w niej zasobów.
Brak efektywnych możliwości zarządzania ruchem w systemach z dynamicznym rutingiem powoduje w dużych sieciach problemy związane ze sterowaniem przepływami ruchu oraz kontrolą wydajności sieci.
Obecnie stosowane w sieciach klasyczne rutery bezpołączeniowe standardowo nie zapewniają możliwości łatwego rozdziału ruchu pomiędzy interfejsami (portami sieci), dynamicznego przełączania na ścieżki zapasowe oraz reoptymalizacji ruchu w celu poprawy wykorzystania dostępnych zasobów transmisyjnych i wydajności. To utrudnia prowadzenie przez administratorów sieci efektywnej polityki w zakresie jej wydajności i wykorzystania. Konsekwencją niezbyt dobrego zarządzania ruchem są ograniczone możliwości wdrożenia jakości QoS i nieefektywność działania sieci. Wraz ze wzrostem popytu na usługi internetowe prawdziwym wyzwaniem staje się rozwój sieci wraz z ulepszeniem jej działania w aspekcie wydajności oraz kosztów utrzymania i kosztów operacyjnych.
Jeśli weźmiemy pod uwagę topologię sieci ATM o budowie „każdy z każdym", w której każdy ruter powinien mieć bezpośrednie połączenie z innym ruterem, to liczba połączeń w sieci wzrasta bardzo szybko wraz z każdym dodanym do sieci ruterem. Wpływa to na skalowalność i stabilność protokołów rutingowych. Bardzo szybko wzrasta w ruterach zapotrzebowanie na zasoby pamięci potrzebnej do przechowywania informacji rutingowych, a także ilość informacji, które należy przesyłać pomiędzy urządzeniami sieciowymi w celu uaktualnienia tablic kierowania ruchu.
Wzrastające wymagania dotyczące odpowiednio dużej przepływności w sieci można spełnić wieloma sposobami, włączając w to zastosowanie przełączników ATM o dużej pojemności i gigabitowych lub terabitowych ruterów IP.
Szybki postęp w dziedzinie technologii układów scalonych umożliwił zmniejszenie kolejnych ograniczeń w zakresie przetwarzania informacji w ruterach. Wyspecjalizowane układy scalone typu ASIC (Application-Specific Integrated Circuits), specjalnie projektowane w celu maksymalnie szybkiego przeglądania nagłówków pakietów IP, umożliwiają analizę milionów pakietów na sekundę i budowę terabitowych ruterów z interfejsami o przepływnościach aż do OC-192. W rezultacie wydajność ruterów przekracza wydajność przełączników ATM i coraz częściej w sieciach szkieletowych przełączniki te są zastępowane terabitowymi ruterami IP. Wielkie rutery ułatwiają skalowanie sieci dużej pojemności i wydajności. Jednak należy pamiętać, że technika ruterów IP ma swoje korzenie w sieciach korporacyjnych i niezależnie od tego, jak duże będą rutery, nie można rozwiązać problemów zarządzania międzywarstwowego (według modelu OSI). Również nie ma możliwości zaspokojenia w sposób zadowalający potrzeb, wynikających z zarządzania siecią przy korzystaniu z podstawowych protokołów rutingu.
Duża popularność oraz elastyczność protokołów IP umożliwia szybkie wdrażanie nowych usług, bez konieczności wprowadzania istotnych zmian w sieciach. Może z jednym wyjątkiem w obecnym stanie sieci IP nie są gotowe do świadczenia usług czasu rzeczywistego z kontrolą jakości przekazywanych informacji, czyli transmisji głosu i obrazu.
Niestety, w klasycznych ruterach przepływ pakietów jest realizowany na podstawie decyzji wynikających z algorytmów rutingu opartych na kryterium najkrótszej ścieżki. Powoduje to efekty występowania blokady (botleneck) i niewykorzystania dostępnych zasobów w sieci. W celu zminimalizowania ograniczeń rutingu według reguł algorytmu najkrótszej drogi, zaproponowano wieloprotokołowe przełączanie na podstawie etykiet MPLS (MultiProtocol Label Switching). W technice MPLS wirtualne połączenia są zestawiane pomiędzy dwoma punktami w sieci ściśle pakietowej. Taka hybrydowa architektura sieci umożliwia emulowanie usług zorientowanych połączeniowo w środowisku wykorzystującym standardowe mechanizmy transferu datagramów. W technice MPLS stosuje się trzy fazy budowy połączenia:
wyznaczenie przebiegu ścieżki,
zestawianie ścieżki,
przekierowywanie pakietów.
4.4.1. Właściwości protokołu MPLS
Zaproponowana przez IETF technika MPLS to zupełnie nowe podejście do komutacji pakietów. Cały proces komutacji podzielono na dwa główne podprocesy:
wybór drogi (routing);
przekierowanie - komutację (forwarding).
Wybór drogi to grupa podprocesów, w skład, których wchodzą: dystrybucja oraz wytwarzanie informacji potrzebnych do realizacji przekierowywania (komutacji). W tym celu są wykorzystywane klasyczne protokoły rutingowe wraz z odpowiednimi rozszerzeniami.
Natomiast podproces przekierowania - komutacji zajmuje się bezpośrednio kierowaniem pakietów na właściwą ścieżkę wyjściową, wykorzystując w tym celu bazę informacji zawartą w odpowiedniej tablicy przekierowań lub przełączania. Proces ten może być realizowany w dowolnej technice - rutingu w warstwie 3, przełączania w warstwie 2 (np. ATM) albo przełączania w warstwie 1 (np. CrossConnect optyczny).
Istotą techniki MPLS jest dołączanie do każdego pakietu w urządzeniu (ruterze) brzegowym domeny MPLS krótkiej etykiety wywodzącej się z koncepcji ekwiwalentnych klas przekierowań FEC (Forwarding Equivalence CIasses). Wewnątrz domeny MPLS dołączone do pakietów etykiety służą do podjęcia decyzji, gdzie kierować pakiet. Etykiety te są używane przez rutery (przełączniki) MPLS wewnątrz domeny zamiast oryginalnego adresu zawartego w nagłówku pakietu. Informacje na temat kierowania pakietów w sieci MPLS są zapisywane w lokalnych bazach danych przez protokoły rutingowe. Każde urządzenie MPLS używa etykiet lokalnie - w każdym przychodzącym pakiecie jest anali zowana jego etykieta. Następnie pakiet jest kierowany do portu wyjściowego, natomiast odebrana etykieta zostaje zastąpiona przez nową etykietę lub usunięta, jeżeli urządzenie znajduje się na brzegu domeny MPLS. Na rysunku 4.16. pokazany jest przykład domeny MPLS.
Rysunek 4.16. Przykład realizacji sieci z wykorzystaniem protokołu MPLS
W celu lepszego zrozumienia protokołu MPLS poniżej zostaną przytoczone definicje używanych dalej pojęć [34].
FEC (Forwarding Equivalence Class) jest podzbiorem pakietów, które będą traktowane tak samo i będą kierowane tą samą drogą. Oznacza to wykorzystanie tej samej ścieżki LSP (Label Switched Path), ustawienia w tej samej kolejce, takiego samego prawdopodobieństwa odrzucenia pakietu (discard) itp.
LSR (Label Switch Router) - to każdy ruter lub przełącznik wykorzystujący w swoim działaniu protokół MPLS - dołącza do każdego pakietu, należącego do tej samej klasy FEC, identycz ną etykietę.
Ruter wejściowy (ingress) LSR (Label Switch Router) to ruter brzegowy domeny MPLS, w którym pakiet przychodzący z zewnątrz jest klasyfikowany, opatrywany etykietą i wysyłany do innego rutera LSR.
Ruter wyjściowy (egress) LSR to ruter brzegowy domeny MPLS, w którym pakiet opuszcza domenę - ruter ten usuwa etykiety związane z domeną.
Klasyfikacja pakietów i przydzielanie ich do określonej klasy FEC - proces następujący w momencie przekazania pakietu do sieci w urządzeniu brzegowym - mogą współistnieć różne klasy FEC tworzone na podstawie różnych kryteriów i mogą mieć różną ziarnistość (stopień agregacji).
Najmniejsza rozdzielczość: FEC zawiera wszystkie docelowe adresy IP współdzielone we wspólnym ruterze wyjściowym LSR.
Największa rozdzielczość: FEC zawiera pakiety należące do określonej aplikacji działającej pomiędzy parą hostów IP (adresy źródłowy i docelowy IP oraz numer portu warstwy transportowej) - jest stosowana wyłącznie w środowiskach kampusu lub sieci korporacyjnej. Przyjęta i stosowana ziarnistość rozdzielczości będzie wpływać na skalowalność przyjętego rozwiązania.
Ścieżki LSP to ścieżki podobne do wirtualnych łączy w ATM i FR (ATM VC, FR DLC) jednokierunkowe, a nie dwukierunkowe, wymagane są dwie ścieżki LSP w celu obsługi ruchu dwukierunkowego.
Generyczne LSP - jest zestawione tak długo, jak długo dana klasa FEC jest rozsyłana w planie rutingu, zwykle w przypadku usługi „best effort".
Etykieta to krótki, o stałej długości, dodatek do pakietu. Nie zawiera ona i nie koduje żadnego adresu sieciowego. Zawiera wszystkie niezbędne informacje do przekierowania pakietu. Wartości użyte w etykiecie mają znaczenie lokalne i mogą być zmieniane na każdym odcinku ścieżki LSP podobnie jak w ATM/FR VC. Etykiety mogą być dodawane do stosu etykiet (wiele etykiet może być dodanych do pakietu).
Do dystrybucji informacji sterującej przepływem pakietów (ich komutacją) są stosowane protokoły rutingowe. W wyniku działania tej techniki, a przede wszystkim wykorzystania etykiety, otrzymuje się etykietowane wirtualne ścieżki nazywane LSP (Label Switched Path). Natomiast informacje niezbędne do komutacji mogą być wytwarzane lokalnie na podstawie działania klasycznych protokołów rutingu (najczęściej rozszerzonych o dodatkowe możliwości związane z techniką MPLS) lub na podstawie informacji przekazywanych przez LDP (Label Distribution Protocol) - protokół dystrybucji etykiet.
Inną bardzo ważną cechą protokołu MPLS jest to, że ścieżki LSP mogą być definiowane i mogą pracować poprawnie w sieci integrującej różne typy łączy takich jak Ethernet, Frame Relay czy ATM.
4.4.2. Zasada działania
Proces rutingu dla MPLS jest maksymalnie uproszczony, co wynika z faktu stosowania krótkiej etykiety, o prostej strukturze. Rutery, które posiadają zaimplementowany MPLS, nazywane są „ruterami przełączającymi etykiety" (Label Switching Routers - LSR).
Po otrzymaniu pakietu ruter brzegowy LER (Label Edge Router) domeny MPLS, podejmuje decyzję, który węzeł sieci ma być następny. W tym celu odczytuje adres docelowy IP oraz inne informacje zawarte w nagłówku, zgodnie z odpowiednimi specyfikacjami. Na tej podstawie ustalana jest wartość etykiety, która identyfikuje klasę, równoważności przesyłania FEC (Forwarding Equivalence Class) dla danego pakietu. Po dodaniu etykiety pakiet jest nadawany do następnego węzła.
W następnym ruterze, odczytana wartość etykiety używana jest jako indeks do tablicy przełączania, która określa następny węzeł na trasie pakietu oraz nową wartość etykiety. Po zamianie etykiety, pakiet nadawany jest do kolejnego węzła. Po dotarciu do rutera wyjściowego domeny MPLS usuwa się etykietę i pakiet nadawany jest zgodnie z klasycznymi regułami rutingu IP.
Rysunek 4.17. Zasada działania MPLS
Wyznaczaną przez MPLS ścieżkę, którą pokonuje pakiet, nazywamy ścieżką przełączaną etykietowo LSP (Label Switched Path). Zastosowanie etykiet do wyznaczania następnego węzła w sieci powoduje, że węzły rutujące działają bardziej jak proste przełączniki niż klasyczne rutery, co powoduje ich odciążenie, a co za tym idzie wzrost wydajności. Jest to szczególnie ważne, jeśli weźmiemy pod uwagę sieci szkieletowe. Dzięki ustalaniu wartości etykiety przez lokalny system zarządzający, proces administrowania zasobami staje się łatwiejszy. Dzieje się tak także dzięki prostocie mechanizmu wyznaczania następnego węzła. Pozwala to inżynierom ruchu na prowadzenie bardziej precyzyjnego zarządzania siecią.
Rysunek 4.18. Przykład przesyłania pakietów w MPLS
4.4.3. Architektura MPLS
Na architekturę MPLS składają się liczne elementy funkcjonalne implementowane w ruterach sieci, obsługujących funkcje przesyłania MPLS i dystrybucję informacji koniecznych dla zestawiania i utrzymania ścieżek przełączanych etykietowo [35].
Stos etykietowy (Label Stack)
Pojedynczy pakiet posiada przypisany zestaw etykiet, które zorganizowane są w formie stosu (kolejki last in first out), przy czym sam proces obsługi pakietu odbywa się tylko na podstawie etykiety znajdującej się na szczycie stosu, bez względu na wartości etykiet znajdujących się poniżej w strukturze stosu. Pakiet nieopatrzony etykietą jest traktowany jako posiadający przypisany stos etykiet o głębokości zero, czyli pusty.
Jeżeli pakiet ma przypisany stos etykietowy o głębokości n, wtedy etykieta nr l znajduje się na szczycie stosu, na dnie stosu znajduje się natomiast etykieta nr n.
Rysunek 4.19. Stos etykietowy
NHLFE (Next Hop Label Forwarding Entry)
NHLFE (pozycja przesyłania następnego skoku etykiety) jest rekordem zawierającym informacje wykorzystywane przy nadawaniu pakietu oznaczonego etykietą do następnego przęsła. Zawiera następujące informacje:
kolejny etap przesyłania pakietu,
identyfikator operacji jaka ma zostać wykonana na stosie etykietowym, może to być jedna z następujących operacji:
zastąpienie etykiety na szczycie stosu nową etykietą,
pobranie etykiety ze szczytu stosu,
wysłanie na stos jednej lub kilku nowych etykiet.
Opcjonalnie, NHLFE może zawierać następujące dodatkowe informacje:
typ enkapsulacji łącza danych, która ma zostać użyta przy transmisji pakietu,
informację o sposobie kodowania stosu przy transmisji etykiety,
inną informację istotną dla procesu transmisji pakietu.
ILM (Incoming Label Map)
Mapa nadchodzących etykiet ILM przechowywana w ruterze jest wykorzystywana dla przypisywania każdej nadchodzącej etykiety do odpowiedniego NHLFE. Mapowanie takie jest wykonywane w LSR przy nadejściu pakietu opatrzonego etykietą. Jeżeli w wyniku mapowania otrzymamy więcej niż jeden rekord NHLFE, wtedy przed nadaniem pakietu do następnego węzła następuje wybór jednego NHLFE. Przypisywanie więcej niż jednego NHLFE do pojedynczej etykiety służyć może np. równoważeniu obciążenia łącz o identycznym koszcie.
FTN (FEC-to-NHLFE)
Każda klasa równoważności FEC jest mapowana na zestaw NHLFE. Powiązania te służą dodaniu poprawnej etykiety do pakietów, które wchodzą w obszar sieci MPLS i nie są opatrzone etykietami.
Podmiana etykiet (Label Swapping)
W celu nadania pakietu, LSR wykonuje następujące czynności:
weryfikuje etykietę znajdującą na szczycie stosu etykiet,
przy pomocy ILM mapuje etykietę na NHLFE,
wykonuje czynności na stosie, wynikające z odpowiedniej pozycji NHLFE,
odpowiednio koduje i zapisuje na stosie nową wartość etykiety.
Po wykonaniu wymienionych czynności, węzeł nadaje pakiet opatrzony nową wartością etykiety. W celu nadania pakietu bez etykiety, LSR:
analizuje nagłówek warstwy sieciowej w celu przypisania pakietu do konkretnej klasy FEC,
na podstawie mapowania FTN (FEC-na-NHLFE) przypisuje pakietowi NHLFE,
dokonuje analizy danych NHLFE i na tej podstawie ustala następny węzeł na trasie pakietu,
wykonuje wynikające z NHLFE operacje na stosie etykiet (w tym przypadku oczywiście nie jest dokonywany zapis etykiety na stosie),
etykieta jest dodawana do pakietu.
Teraz węzeł graniczny nadaje pakiet do następnego węzła na trasie. Jeżeli podmiana etykiet jest aktywna, następny etap jest ustalany zawsze na podstawie informacji zawartych w NHLFE.
Budowa etykiety
Rysunek 4.20. Etykieta MPLS [36]
Jednobitowe pole S jest znacznikiem końca stosu etykiet (Bottom of Stack).
Pole Exp (Experimental Use) o długości 3 bitów zostało zarezerwowane dla zastosowań eksperymentalnych.
Pole wartości etykiety (Label Value) o długości 20 bitów jest używane przez rutery przełączające etykiety (LSR) do podjęcia decyzji, czy przesłać pakiet do następnego węzła MPLS, czy też zastosować enkapsulację zdefiniowaną dla przypadku, gdy pakiet opuszcza domenę obsługującą MPLS.
Pole TTL (Time to Live) o długości 8 bitów spełnia funkcję analogiczną do pola TTL z nagłówka pakietu IPv6. Każdy ruter, przez który przechodzi dany pakiet, dekrementuje wartość pola o l, do momentu aż wartość pola osiągnie wartość 0 lub pakiet osiągnie host docelowy. Różnica jest jedynie w przypadku, kiedy wartość pola osiągnie wartość 0, wtedy w przypadku IP, decyzja, co dalej z pakietem podejmowana jest w zależności od wartości określonego pola, dla MPLS decyzja ta zależy tylko od odpowiednich parametrów konfiguracyjnych.
Typy rutingu (Route Selection)
Dla wieloprotokołowej komutacji etykietowej stosowane są dwa tryby wybory trasy [37]:
hop by hop ruting
Każdy węzeł pośredni na trasie samodzielnie decyduje o następnym węźle, do którego wysyła pakiet. Dokonywane jest to poprzez skierowanie do odpowiedniej ścieżki przełączania etykiet. Zasada działania tego typu rutingu jest zbliżona do rutingu w tradycyjnych sieciach IP.
explicit ruting
Wejściowy ruter przełączający etykiety ustala kompletną ścieżkę LSP dla każdej klasy FEC. Wyznacza tym samym wszystkie węzły pośrednie na trasie pakietu wewnątrz całej sieci MPLS. Istotną cechą tego modelu rutingu jest możliwość dokonania statycznej konfiguracji ścieżek przełączania etykiet wewnątrz całej sieci MPLS. Ścieżki przełączania etykiet mogą być także zestawiane dynamicznie na podstawie informacji o bieżącym stanie łącz (link state topology information). Funkcje zarządzania ruchem wykorzystują tę metodę rutingu dla zoptymalizowania wykorzystania zasobów sieciowych.
4.4.4. Dystrybucja informacji w MPLS
Pozycja w tablicy przełączania dla pojedynczej etykiety zawiera niezbędne informacje dla funkcji przesyłania, może także zawierać informacje dodatkowe. Każda etykieta podlegająca dystrybucji, posiada przypisaną pozycję w tablicy nadawczej. Powiązanie to może być dokonywane lokalnie przez LSR lub odbierane od innego LSR. W przypadku lokalnego modelu tworzenia powiązań, LSR samodzielnie decyduje o utworzeniu i dystrybucji danego powiązania. Jeżeli stosowana jest zewnętrzna kontrola LSR czeka na otrzymanie powiązania od swojego sąsiada „w dół” (downstream neighbour) po czym tworzy, pozycję w tablicy i dystrybuuje powiązanie do swojego sąsiada „w górę”.
Dystrybucja etykiet w MPLS realizowana może być na trzy sposoby [37]:
poprzez rozszerzenie funkcjonalności istniejących protokołów rutingu, np. BGP (Border Gateway Protocol), w celu dystrybucji etykiet,
poprzez użycie mechanizmów sygnalizacyjnych RSVP (Resource reSerVation Protocol), w celu dystrybucji etykiet mapowanych ze strumieni definiowanych przez RSVP,
używając dedykowanego protokołu dystrybucji etykiet LDP (Label Distribution Protocol), który obecnie znajduje się w fazie standaryzacji przez IETF.
Dystrybucja etykiet przy pomocy BGP
Para LSR, która równorzędnie obsługuje trasy przy pomocy protokołu BGP, musi także wymieniać informacje dotyczące mapowania etykiet dla tychże tras. Wymiana jest realizowana poprzez załączanie danych mapowania dla trasy w tej samej wiadomości aktualizacyjnej, która jest używana dla utrzymania tras w sieci.
Dystrybucja etykiet przy pomocy RSVP
RSVP definiuje sesję jako strumień danych z określonym przeznaczeniem i typem protokołu warstwy transportowej. Jeżeli implementowane są mechanizmy współpracy RSVP i MPLS, wtedy strumień lub sesja mogą być definiowane bardziej elastycznie. Wejściowy węzeł ścieżki przełączania etykiet może na różne sposoby dokonywać przypisania etykiet nadchodzącym pakietom. Jeśli dana etykieta została już przypisana do grupy pakietów, definiuje ona tym samym strumień poprzez LSP. Tak ustalana ścieżka LSP określana jest mianem tunelu LSP, ponieważ trasa każdego pakietu jest z góry ustalona i nie jest zależna od decyzji węzłów pośrednich. Żądanie informacji dla etykiet powiązanych z danym strumieniem ruchu RSVP jest przenoszone w wiadomościach RSVP Path. Informacje dotyczące mapowania etykiet danego strumienia są przenoszone w wiadomościach Resv RSVP.
LDP (Label Distribution Protocol) - Protokół Dystrybucji Etykiet
Protokół dystrybucji etykiet LDP jest zbiorem procedur i wiadomości, dzięki którym rutery przełączające etykiety ustanawiają ścieżki przełączania etykiet poprzez sieć. Dokonywane jest to poprzez mapowanie informacji rutingu warstwy trzeciej na ścieżki przełączania w warstwie drugiej.
LDP wiąże FEC z każdą tworzoną ścieżką przełączania etykiet. Klasa równoważności nadawczej FEC powiązana z LSP, określa, które pakiety są mapowane na tę ścieżkę. Wiadomości wymieniane przez rutery przełączające etykiety, dzieli się na następujące kategorie:
wiadomości rozpoznawania (discovery messages) - są używane do ogłaszania danych,
wiadomości sesji - są używane w celu ustanawiania, obsługi i zakańczania sesji LDP,
wiadomości ogłoszeniowe - są używane w celu tworzenia, modyfikacji i usuwania mapowań etykiet na FEC.
Łączenie etykiet
Przypuśćmy, że LSR klasyfikuje wiele nadchodzących etykiet do jednej klasy FEC. Przy nadawaniu pakietu tej klasy FEC, można by przypisać identyczną etykietę do wszystkich takich pakietów. Możliwość nadawania etykiet w ten sposób, nazywamy łączeniem etykiet.
Przypuśćmy, że LSR otrzymuje dwa pakiety, które nadeszły z różnych interfejsów, lub/i z różnymi etykietami wyśle je poprzez ten sam interfejs wyjściowy z identycznymi wartościami etykiet. Gdyby się tak stało, utracilibyśmy informację o wejściowych interfejsach i wartościach etykiet dla tych pakietów.
LSR nieobsługujący funkcji łączenia etykiet w przypadku etykiet pochodzących z różnych interfejsów lub/i z różnymi wartościami etykiet, muszą być nadane poprzez różne interfejsy lub/i z różnymi wartościami etykiet.
4.4.5. Przełączniki ATM jako rutery przełączające etykiety
Zasada działania przełączania etykiet jest zbliżona do funkcji komutacji komórek w sieci ATM. Przełączniki ATM używają numerów portów wejściowych i wartości identyfikatorów VPI/VCI jako indeksów do tablicy przełączania, z której uzyskują informacje o wyjściowym numerze portu i wartości VPI/VCI. Dlatego, że, etykieta może zostać zapisana w polach, do których dostęp jest realizowany poprzez nagłówek komórki, przełączniki ATM są w stanie pracować jako rutery przełączające etykiety. Konieczne są w tym celu modyfikacje oprogramowania sterującego pracą przełączników. Przełączniki takie określa się mianem ATM LSR.
Istnieją trzy sposoby zapisania etykiety w nagłówku komórki ATM (zakładając użycie AAL5) [37]:
Kodowanie SVC (Switched Virtual Circuit)
W tej metodzie używa się pola VPI/VCI w celu zapisu wartości etykiety znajdującej się na szczycie stosu etykiet. Technika ta może zostać zastosowana w każdej sieci. Przy tej technice zapisu etykiety, każda ścieżka przełączania etykiet jest realizowana jako SVC i protokół dystrybucji etykiet działa jak protokół sygnalizacji ATM. Przy tej technice zapisu nie ma możliwości pobierania i zapisu etykiet ze stosu etykiet przez LSR.
Kodowanie SVP (Switched Virtual Path)
W tej technice zastosowano pola VPI (Virtual Path Identifier) w celu zakodowania wartości etykiety znajdującej się na szczycie stosu etykiet i VCI (Virtual Circuit Identifier) dla zapisu etykiety drugiej warstwy stosu. Technika ta umożliwia zastosowanie przełączania ścieżek wirtualnych (VP Switching). Ścieżki przełączania etykiet realizowane są jako ścieżki wirtualne, a protokół dystrybucji etykiet (LDP) działa jak protokół sygnalizacyjny ATM. Opisywana technika nie może być używana w każdej sytuacji. Jeżeli w danej sieci posiadamy zaimplementowane ścieżki wirtualne sieci ATM, a nie MPLS, wtedy pole VPI nie musi być dostępne dla użycia przez MPLS. W tej technice, ATM LSR w wyjściowych punktach ścieżki wirtualnej dokonują odczytu etykiet ze stosu.
Wielopunktowe kodowanie SVP
W tej technice żyyto pola VPI dla zakodowania etykiety, która znajduje się na szczycie stosu etykiet i części pola VCI dla drugiej z kolei etykiety, a pozostałe bity pola VCI używane są w celu identyfikacji początkowego węzła LSP. W przypadku stosowania tej techniki tradycyjne funkcje przełączania ATM mogą być stosowane w celu tworzenia ścieżek wirtualnych punkt-wielopunkt.
Wykorzystanie tej techniki zależy od możliwości obsługi 16 bitowych wartości VCI przez każdy przełącznik ATM tak, że żadna wartość VCI nie jest przypisana do dwóch różnych przełączników. Jeżeli możliwe byłoby przypisanie odpowiedniej wartości do każdego przełącznika, wtedy wartość VCI mogłaby pełnić rolę etykiety drugiej warstwy w stosie etykietowym.
Współpraca technik kodowania etykiet
Architektura MPLS dopuszcza stosowanie różnych sposobów kodowania etykiet dla poszczególnych węzłów ścieżki przełączania etykiet.
Łączenie etykiet
ATM-LSR używające kodowania SVC lub SVP nie mogą obsługiwać łączenia etykiet. Jeżeli dany LSR używa funkcji łączenia etykiet, liczba wyjściowych etykiet dla klasy FEC wynosi zawsze l, bez obsługi tej funkcji liczba wyjściowych etykiet mogłaby być tak duża, jak liczba węzłów w sieci.
Funkcje łączenia w sieci ATM
Istnieje szereg metod, które mogą wyeliminować problem łączenia komórek w sieci ATM, tym samym pozwalając na łączenie strumieni [37]:
Łączenie VP, używając wielopunktowego kodowania SVP
Jeżeli łączenie ścieżek wirtualnych jest stosowane, wiele pojedynczych VP jest łączonych w jedną ścieżkę wirtualną. Pakiety z różnych źródeł są rozróżniane przy użyciu różnych VCI w obrębie ścieżki wirtualnej.
Łączenie VC
Stosując łączenie VC, przełączniki są zobowiązane do buforowania ramek pakietu, aż cały pakiet jest otrzymany. Może to zostać zrealizowane poprzez wyszukiwanie wskaźnika końca ramki AAL5.
Łączenie VP jest zgodne z większą liczbą istniejących implementacji przełączników ATM. Ponadto, podejście to nie wnosi dodatkowych opóźnień, ani nie wymaga buforów dla kolejkowania pakietów. Wymaga jednak koordynacji identyfikatorów VC w obrębie ścieżki wirtualnej. Ze względu na konieczność zachowania kompatybilności z już istniejącym sprzętem, dopuszczono do użycia obie metody.
Rysunek 4.21. Możliwości umiejscowienia etykiety w nagłówku ATM
5. System utrzymania i pomiaru parametrów QoS
Ta część naszej pracy zawiera różne spojrzenia na sposoby pomiaru parametrów i usług, które muszą być monitorowane w celu utrzymania sieci IP na odpowiednim poziomie jakości QoS. W rozdziale 5.2. zaprezentowano koncepcje systemu pomiaru i utrzymania sieci.
Rozdział 5.3. zawiera opis różnych scenariuszy pomiarowych. W rozdziale 5.4. zawarty jest opis punktów pomiarowych, natomiast rozdział 5.5. prezentuje pomiar metryk QoS dla wybranych scenariuszy pomiarów. Rozdział 5.6. zawiera opis metodologii pomiarowej wraz z praktycznymi sposobami realizacji. Rozdział 5.7. jest rozważaniem na temat sposobów prezentacji wyników przeprowadzonych pomiarów z punktu widzenia Dostawcy usług (Service Provider), Dostawcy Sieciowego (Network Provider) oraz Klienta (Service Customer).
5.1. Koncepcja pomiaru i utrzymania sieci
Opracowano koncepcję systemu pomiaru i utrzymania sieci w oparciu o bierną metodę pomiarową. Główną cechą tej metody jest to, że nie jest generowany dodatkowy ruch w sieci, co jest niewątpliwie jej zaletą. Punkty pomiarowe rozlokowane na krańcach ścieżki end-to-end zbierają istotne informacje pomiarowe dotyczące podstawowych metryk opisujących poziom QoS usługi transportowej. Olbrzymie znaczenie w pracy systemu ma synchronizacja czasowa pomiędzy punktami pomiarowymi. Aby zapewnić synchronizację czasową na odpowiednim poziomie dokładności zastosowano synchronizację GPS (Global Positioning System). Dane pomiarowe z punktów pomiarowych przesyłane są do Jednostki Centralnej gdzie po wstępnej obróbce obliczane są wartości wybranych metryk QoS. Na rysunku 5.1. przedstawiono schemat omawianego systemu pomiarowego. W dalszej części pracy zostaną omówione kolejne jego składniki.
Rysunek 5.1. Schemat koncepcji systemu pomiaru i utrzymania sieci
Sondy pomiarowe umieszczone w strategicznych obszarach sieci są źródłem informacji pomiarowych będących wprost wartościami metryk QoS lub wstępnych danych pomiarowych na podstawie, których po przesłaniu do Jednostki Centralnej obliczane są wartości wybranych metryk. Pomiary przeprowadzone są dla ruchu wchodzącego i wychodzącego z rozróżnieniem kierunku transmisji, co decyduje o nadaniu punktom pomiarowym funkcji Monitora Nadawcy i Monitora Odbiorcy, które mogą być dynamicznie zmieniane (rysunek 5.2.).
Rysunek 5.2. Układ pomiaru parametrów QoS w relacji od końca do końca dla transmisji w jednym kierunku
Podstawowymi składnikami przedstawionego systemu pomiarowego są:
Punkty Pomiarowe,
Jednostka Centralna (Post-Procesing).
Jeżeli system pomiarowy posiada urządzenia zbierające (Punkty Pomiarowe) i urządzenia centralne (Jednostka Centralna), które analizują zebrane dane oraz jednostkę post-procesingu lub składowania danych pomiarowych, występują różne sposoby komunikacji pomiędzy tymi urządzeniami. Urządzenia centralne mogą pracować jako nadrzędne (master), które co jakiś czas sprawdzają urządzenia zbierające, które pracują jako podrzędne (slave).
5.1.1. Punkty Pomiarowe
Źródłem informacji pomiarowych są punkty pomiarowe rozmieszczone na krańcach ścieżki tak, aby mierzone parametry QoS odnosiły się do usługi QoS end-to-end. Punkty pomiarowe podzielono na dwa typy:
Punkt Pomiarowy od strony Nadawcy - Monitor Nadawcy
Punkt Pomiarowy od strony Odbiorcy - Monitor Odbiorcy
Powyższy podział dotyczy funkcji punktów pomiarowych podczas pomiarów dla ruchu transmitowanego od Nadawcy do Odbiorcy w przeciwnym razie funkcje punktów należy zamienić. Oznacza to, że realizacja sprzętowo-programowa jest identyczna i może to być komputer klasy PC z systemem Linux. Cały proces pomiarowy może być realizowany jako kilka oddzielnych procesów uruchomionych w systemie.
5.1.1.1. Monitor Nadawcy
Zadaniem Monitora Nadawcy jest:
Oznaczanie wybranego pakietu (wysyłanego przez Nadawcę), który będzie analizowany w celu wyliczenia opóźnień przejścia pakietu przez sieć (wykorzystane pole TOS)
Zapis dokładnego czasu przejścia mierzonego pakietu przez Punkt Pomiarowy
Odczytanie i zapis „pola identyfikacji” pakietu IP w celu późniejszej identyfikacji pakietu
Odczytanie i zapis pól adresu źródłowego i docelowego pakietu IP
Zliczanie ilości pakietów IP wysłanych do Odbiorcy
Tworzenie Tablicy Pomiarowej
Wysyłanie serii próbek danych pomiarowych do Jednostki Centralnej
Oznaczenie pakietu
W celu oznaczenia pakietu wykorzystane zostało pole Typu usługi TOS pakietu IP.
Rysunek 5.3. Datagram IP z uwzględnieniem pól tworzących nagłówek IP
W założeniach, protokół IP posiadać miał pewne elementy mechanizmów sterowania przepływem, których celem jest zapewnienie gradacji poziomu jakości usługi sieciowej (QoS). W tym celu pole TOS zawiera 3 bitowy wskaźnik priorytetu przesyłania pakietu oraz trzy flagi zalecanego doboru trasy, które mogą być używane do określania parametrów pierwszeństwa, opóźnienia, przepustowości i niezawodności tego pakietu. Większość implementacji nie używa żadnego z tych pól (tzn. pola te są z reguły ustawiane, lecz elementy komutacyjne sieci - rutery ignorują je). Jednakże, architektura DiffServ wykorzystuje 6 pierwszych bitów tego pola do nadawania odpowiednich priorytetów pakietom IP. Przynależność pakietu do danej klasy usług w sieci DiffServ jest jednoznacznie określona przez wartość punktu kodowego DSCP (Differentiated Services Code Point).
Rysunek 5.4. Struktura pola TOS
Oznacza to, iż niezależnie od architektury wspierającej QoS w sieci IP dwa ostatnie bity pola TOS są wolne i mogą być wykorzystane do oznaczenia pakietu przechodzącego przez oba punkty pomiarowe.
Zapis czasu przejścia pakietu
W tablicy pomiarowej z adresem odbiorcy i nadawcy jak i wartością „pola identyfikacji” wybranego pakietu IP należy skojarzyć dokładny czas przejścia pakietu przez punkt pomiarowy. Dokładność zegarów w Monitorze Nadawcy i Odbiorcy powinna być znacznie wyższa niż wartość średnich opóźnień pakietów IP (rzędu milisekund).
Odczytanie i zapis zawartości pola adresowego i identyfikacji
Pole identyfikacji zawiera numer, który identyfikuje w sposób jednoznaczny datagram wysyłany z danego hosta. Szesnastobitowa wartość tego pola (65 536 możliwości) w połączeniu z mechanizmem TTL gwarantują, że w danej chwili w sieci nie będą nigdy istniały dwa identyczne pakiety. Wartość tego pola skojarzoną z adresem IP nadawcy i odbiorcy należy zapisać w Tablicy Pomiarowej w celu identyfikacji strumienia pakietów IP przesyłanego od Nadawcy do Odbiorcy.
Zliczanie ilości wysłanych pakietów
W celu sporządzenia metryki strat pakietów (loss) należy zliczać ilość pakietów IP wysyłanych od Nadawcy do Odbiorcy. Należy także pamiętać o zapisie czasu rozpoczęcia i zakończenia zliczania. Proces zliczania pakietów może być uruchomiony na Monitorze Nadawcy jako kolejny wątek i pracować równolegle wraz z innymi zadaniami.
Tworzenie i wysyłanie Tablicy Pomiarowej
Monitor Nadawcy po oznaczeniu analizowanego pakietu tworzy Tablice Pomiarową zawierającą odpowiednio skojarzone ze sobą dane pomiarowe. Następujące po sobie z ustaloną częstotliwością pomiary są źródłem wyników, które są składowane na stosie w Tablicy Pomiarowej. Poszczególne rekordy w Tablicy Pomiarowej zawierają następujące informacje:
Wartość pola identyfikacji pakietu IP;
Adres nadawcy;
Adres odbiorcy;
Czas przejścia pakietu przez punkt pomiarowy.
Tabela 5.1. Przykładowy rekord w Tablicy Pomiarowej Monitora Nadawcy
Wartość Pola Identyfikacji |
Adres IP Nadawcy |
Adres IP Odbiorcy |
Czas |
. . . 24784 . . . |
. . . 156.17.230.78 . . . |
. . . 212.77.100.101 . . . |
. . . 05:32:03:56:02 . . . |
Dane z Tablicy Pomiarowej Monitora Nadawcy są przesyłane do Jednostki Centralnej, gdzie na podstawie tychże danych jak i danych pochodzących z Tablicy Pomiarowej Monitora Odbiorcy obliczane są wartości metryk QoS.
5.1.1.2. Monitor Odbiorcy
Zadaniem Monitora Odbiorcy jest:
sprawdzanie pola TOS pakietu IP w celu wykrycia pakietu oznaczonego w Punkcie Pomiarowym po stronie Nadawcy;
zapis dokładnego czasu przejścia oznaczonego pakietu IP;
odczytanie i zapis „pola identyfikacji” oznaczonego pakietu IP w celu późniejszej identyfikacji pakietu;
odczytanie i zapis pól adresu źródłowego i docelowego oznaczonego pakietu IP;
zliczanie pakietów pochodzących od Nadawcy;
tworzenie Tablicy Pomiarowej;
wysyłanie serii próbek danych pomiarowych do Jednostki Centralnej.
Zadania należące do Monitora Odbiorcy są niemal identyczne jak w przypadku zadań stawianych przed Monitorem Nadawcy i w przypadku sporządzania metryk takich jak jednokierunkowe opóźnienie, strata czy zmienność opóźnienia (jitter) są wystarczające. Jednak w przypadku metryk związanych z przepustowością należy rozszerzyć możliwości tego punktu pomiarowego. W tym celu należy uzupełnić Tablice Pomiarową o dwa dodatkowe wpisy dotyczące długości nagłówka oraz całkowitej długości pakietu. Jednostka Centralna (Post-procesing) na podstawie tychże informacji jak i czasu, w którym pakiety przechodzą przez Punkt Pomiarowy jest w stanie wyliczyć przepustowość oznaczonego strumienia IP (transmitowanego od Nadawcy do Odbiorcy). Zatem kolejnymi zadaniami, które musi wykonać Monitor Odbiorcy, związanymi z metrykami zorientowanymi na przepustowość są:
odczytanie i zapis wartości pola „długość nagłówka” pakietu IP;
odczytanie i zapis wartości pola „całkowita długość pakietu”.
Należy wspomnieć, że wartość metryki przepustowości może być wyliczona w samym punkcie pomiarowym, a wyliczona wartość przesłana do Jednostki Centralnej. Ograniczy to ilość przesyłanych danych pomiarowych. W przypadku, kiedy wartość tej metryki zostanie wyliczona w punkcie pomiarowym, przed przesyłaniem do Jednostki Centralnej danych pomiarowych zawartych w Tablicy Pomiarowej, należy usunąć rekordy dotyczące długości nagłówka i całkowitej długości pakietu.
Tabela 5.2. Przykładowy rekord w Tablicy Pomiarowej Monitora Odbiorcy
Wartość Pola Identyfikacji |
Adres IP Nadawcy |
Adres IP Odbiorcy |
Czas |
Długość Nagłówka [Bajty] |
Całkowita długość pakietu [Bajty] |
. . . 24784 . . . |
. . . 156.17.230.78 . . . |
. . . 212.77.100.101 . . . |
. . . 05:32:03:56:02 . . . |
. . . 16 . . . |
. . . 2375 . . . |
Odczytanie i zapis pola „długość nagłówka ” i „całkowita długość pakietu”
Długość nagłówka jest liczbą 32-bitowych słów umieszczonych w nagłówku wraz z opcjami tworzy długość nagłówka. Typowa (minimalna) długość nagłówka wynosi 5. Zapis tej wartości w Tablicy Pomiarowej daje możliwość obliczenia rozmiaru danych przenoszonych przez pakiet.
Wartość pola całkowitej długości pakietu, pomniejszona o rozmiar nagłówka wyznacza rozmiar pola danych enkapsulowanych przez datagram. Jego teoretyczny rozmiar sięga, co prawda wartości 64kB, jednak w praktyce ze względu na ograniczenia interfejsów fizycznych długość datagramu nigdy nie przekracza wartości tzw. MTU (Maximum Transmission Unit).
5.1.1.3. Synchronizacja czasowa
Pomiary metryk takich jak jednokierunkowe opóźnienie i zmienność opóźnienia wymagają zapisu czasu nadania i przybycia pakietów w punkcie źródłowym i docelowym. Oznacza to, że zegary użyte w punkcie źródłowym i docelowym powinny być zsynchronizowane (przy użyciu zegara odniesienia). Dokładność zegara lokalnego i odniesienia musi być jeden lub dwa rzędy wyższa od typowych wartości opóźnień mogących wystąpić podczas nadawania pakietów.
Jednym z przykładów zegara odniesienia użytego do synchronizacji pomiarów jest zegar w systemie GPS (Global Positioning System) o rozdzielczości 10 µs. Sygnał GPS nadawany jest w widmie rozproszonym o częstotliwości zbliżonej do 1,5 GHz. Emisja sygnału odbywa się w 2-ch wiązkach, z których pierwsza jest zastrzeżona dla zastosowań wojskowych, a druga może być wykorzystywana przez aplikacje cywilne. Emisja w widmie rozproszonym pozwala skutecznie przeciwdziałać zakłóceniom. Stosowane metody kompresji i korekcji błędów pozwalają skutecznie odczytać informację o czasie nawet przy złych warunkach pogodowych czy silnych zakłóceniach elektromagnetycznych występujących w pobliżu odbiornika. Sygnał GPS jest nadawany z 24 satelitów tworzących specjalną tzw. "siatkę" na orbicie okołoziemskiej. Do prawidłowego odbioru informacji o czasie niezbędna jest komunikacja, z co najmniej dwoma satelitami, co z reguły nie przysparza specjalnych trudności.. Sygnał GPS przekazuje informacje o czasie pochodzące z zegara atomowego jakkolwiek czas jest w tym przypadku podawany jako GMT [39].
5.1.2. Jednostka Centralna (Post-procesing)
Jednostka Centralna nadzoruje pracą systemu pomiarowego. Procedura pomiarowa składa się z kilku etapów:
inicjalizacja,
zbieranie danych w punktów pomiarowych,
zapis danych pomiarowych,
post-procesing,
przygotowanie informacji wyjściowych.
Rysunek 5.5. Schemat blokowy przedstawiający procedurę pomiarową
5.1.2.1. Inicjalizacja
Wartości różnych parametrów systemu muszą być ustawione przed przeprowadzeniem pomiarów. Przed przeprowadzeniem pomiarów należy wyzerować (reset) liczniki zliczające przesyłane pakiety w obu Punktach Pomiarowych. Jednostka Centralna wysyła do Punktów Pomiarowych sygnał inicjujący pomiary. W przypadku Monitora Nadawcy sygnał inicjujący rozpocznie proces pomiarowy polegający na oznaczaniu pakietów transmitowanych przez Nadawcę, tworzeniu Tablicy Pomiarowej i wysyłania otrzymanych wyników. W przypadku Monitora Odbiorcy będzie to rozpoczęcie pomiarów polegających na analizie jedynie oznaczonych pakietów, tworzenie Tablicy Pomiarowej i wysyłanie jej do Jednostki Centralnej. Należy również pamiętać, że Jednostka Centralna nadaje Punktom Pomiarowym funkcje Monitora Nadawcy i Monitora Odbiorcy, a zależy to od kierunku transmisji pakietów IP, które mają być mierzone.
5.1.2.2. Zbieranie danych z punktów pomiarowych
Podczas procesu pomiarowego, urządzenia pomiarowe mierzą określone właściwości badanego ruchu. Dane pomiarowe nie są bezpośrednio metrykami, lecz pewnego rodzaju informacjami wstępnymi, które mogą być użyte do obliczenia metryki docelowej. Punkty Pomiarowe zapisują dane pomiarowe w Tablicach Pomiarowych, które mogą być przechowywane w plikach baz danych. Dane są wysyłane do Jednostki Centralnej, która analizuje zebrane dane. Występują różne sposoby komunikacji pomiędzy tymi urządzeniami. Jednostka Centralna może pracować jako urządzenie nadrzędne (master), które co jakiś czas sprawdza Punkty Pomiarowe, które pracują jako podrzędne (slave).
Tryb zbierania master/slave umożliwia dynamiczną kontrolę wartości danych pomiarowych. Urządzenia podrzędne (slave) mogą pozbywać się starych danych pomiarowych, które nie są zebrane przez urządzenia nadrzędne (master). Jednakże ten tryb nie jest odpowiedni do monitorowania zdarzeń asynchronicznych takich jak błędy czy przekroczenia ustalonej wartości granicznej. Tryb wsadowy jest bardziej właściwy do monitorowania błędów, ponieważ urządzenia zbierające transmitują swoje dane pomiarowe automatycznie, kiedy jest spełniony odpowiedni warunek (np. bufor pomiarowy jest pełny lub wystąpi błąd). Przedstawiony system pomiarowy wymaga synchronizacji czasowej.
5.1.2.3. Zapis danych pomiarowych
W większości przypadków nie jest możliwe przetworzenie danych pomiarowych w czasie rzeczywistym, dlatego też dane muszą być zapisywane. Kolejnym powodem stosowania zapisu danych pomiarowych jest możliwość późniejszego sprawdzenia wyników pomiarów. Formą zapisu danych przez Jednostkę Centralną może być prosty zapis w plikach „log file” jak i złożone struktury obiektowe.
5.1.2.4. Post-procesing
Dane pomiarowe zebrane z punktów pomiarowych nie są stosowane jako rezultaty końcowe pomiarów, dlatego też dane muszą być odpowiednio przetworzone. Na podstawie danych zawartych w Tablicach Pomiarowych Monitora Nadawcy i Odbiorcy należy wyliczyć następujące metryki ruchowe:
opóźnienie jednokierunkowe,
opóźnienie dwukierunkowe,
zmienność opóźnienia jednokierunkowego,
strata pakietów,
przepustowość.
Poniżej zostaną podane sposoby obliczania wymienionych metryk na podstawie informacji zawartych w Tablicach Pomiarowych.
Opóźnienie jednokierunkowe
Dzięki informacjom zebranym z Monitora Nadawcy i Odbiorcy zawartych w Tablicach Pomiarowych można skojarzyć rekordy odpowiadające określonym pakietom, a następnie wyliczyć metrykę opóźnienia jednokierunkowego. Do tego celu należy wykorzystać wartość następujących pozycji z Tablic Pomiarowych:
Wartość pola identyfikacji pakietu, adres IP Nadawcy i Odbiorcy w celu identyfikacji i skojarzenia rekordów Tablicy Pomiarowej pochodzącej z Monitora Nadawcy i Odbiorcy.
Czas przejścia pakietów przez punkty pomiarowe, dla skojarzonych rekordów odpowiadających temu samemu pakietowi.
Wartość metryki opóźnienia jednokierunkowego należy wyliczyć według następującego wzoru:
Ojk = tO - tN; (5.1.)
gdzie:
Ojk - opóźnienie jednokierunkowe,
tN - czas przejścia pakietu przez Monitor Nadawcy,
tO - czas przejścia pakietu przez Monitor Odbiorcy.
Rysunek 5.6. Zasada pomiaru opóźnienia jednokierunkowego
Opóźnienie dwukierunkowe
W celu wyliczenia tej metryki można użyć programu ping. Jest to narzędzie do testowania i pomiaru transmisji w sieci. Ping wysyła pakiety testowe pod wskazany adres i zwraca informację dla każdego z pakietów testowych. Ping dostarcza informacji o poszczególnych czasach odpowiedzi w milisekundach oraz krótkie podsumowanie zawierające najkrótszy, średni i najdłuższy czas odpowiedzi dla całego badania. Jednostka Pomiarowa inicjując proces pomiarowy może wysłać do jednego z punktów pomiarowych informacje o przeprowadzeniu pomiaru opóźnienia dwukierunkowego. Wybrany punkt pomiarowy używając programu ping bada opóźnienie wysyłając pakiety testowe pod wskazany adres. Pomiar opóźnienia dwukierunkowego przy pomocy pakietów testowych Ping należy do aktywnej metody pomiarowej, ponieważ generowany jest do sieci dodatkowy ruch testowy. Po otrzymaniu wyników informacje o opóźnieniach wysyłane są do Jednostki Centralnej.
Zmienność opóźnienia jednokierunkowego (Jitter)
Metryka zmienności opóźnienia jednokierunkowego jest wyliczana jako różnica między opóźnieniami jednokierunkowymi dwóch pakietów należących do strumienia pakietów przesyłanych od Nadawcy do Odbiorcy. Metryka ta jest metryką pośrednią, ponieważ jest wyliczana na podstawie metryki opóźnienia jednokierunkowego.
Wartość metryki opóźnienia jednokierunkowego należy wyliczyć według następującego wzoru:
Jitter = | OJK1 - OJK2 |; (5.2.)
gdzie:
Jitter - zmienność opóźnienia jednokierunkowego,
OJK1 - opóźnienie jednokierunkowe pierwszego wybranego pakietu IP,
OJK2 - opóźnienie jednokierunkowe drugiego wybranego pakietu IP.
Strata pakietów (loss)
Wyliczenie wartości tej metryki polega na porównaniu ilości wysłanych i odebranych pakietów. Metryka ta jest sporządzana dla danego przedziału czasowego. Po przesłaniu z punktów pomiarowych danych dotyczących ilości wysłanych i odebranych pakietów należy wykonać następujące wyliczenie:
Loss = IW - IO; (5.3.)
gdzie:
Loss - jednokierunkowa strata pakietów IP,
IW - ilość pakietów wysłana przez Nadawcę,
IO - ilość pakietów odebrana przez Odbiorcę.
Wartość metryki może być przedstawiona jako ilość straconych pakietów w danym przedziale czasu. Jednakże wartość tejże metryki może być przedstawiona również jako stosunek straty pakietów oznaczający ilość utraconych pakietów podzielonej przez ilość wytransmitowanych pakietów. Stosunek straty pakietów należy wyliczyć według następującej zależności:
; (5.4.)
gdzie:
SSP - stosunek jednokierunkowej straty pakietów,
Loss - jednokierunkowa strata pakietów,
IW - ilość pakietów wysłana przez Nadawcę.
Wartość stosunku straty pakietów może być wyrażana procentowo i może być podawana dla danego przedziału czasu (np. 0,01 % w ciągu doby).
Przepustowość
Wartość tej metryki jest wskaźnikiem tego ile danych zostało przesłane w ciągu sekundy w jednym kierunku. Istnieje wiele różnych definicji tej metryki. Niektóre z nich biorą pod uwagę całe pakiety, inne tylko ładunek użyteczny (payload) jako niezbędne do ich specyfikacji. W tej pracy sugeruje się obliczenie metryki przepustowości jako stosunek ilości przesłanych danych do czasu, w którym zostały one nadane. Wartość ładunku użytecznego przenoszonego przez pakiet IP jest obliczana na podstawie informacji zawartych w Tablicy Pomiarowej. W omawianym systemie pomiarowym algorytm wyliczenia wartości metryki przepustowości ma następującą postać:
; (5.5.)
gdzie:
P - przepustowość jednokierunkowa,
CDPi - całkowita długość kolejnego pakietu,
DNi - długość kolejnego nagłówka,
t1 - czas przybycia pierwszego z pakietów wykorzystanych do obliczenia metryki przepustowości,
tn - czas przybycia ostatniego z pakietów wykorzystanych do obliczenia tej metryki.
Informacje niezbędne do wyliczenia wartości tej metryki znajdują się w jednym z punktów pomiarowych. Nie występuje, więc konieczność przesyłania próbek pomiarowych w celu wyliczenia tej metryki. Ogranicza to ilość przesyłanych danych pomiarowych, ponieważ zostają usunięte z Tablicy Pomiarowej rekordy dotyczące długości nagłówka i całkowitej długości pakietu.
Obróbka statystyczna danych
Zbierając pojedynczą próbkę metryki zazwyczaj nie daje to wystarczających informacji, aby wyciągnąć istotne wnioski dotyczące pomiarów. Dlatego też dane pomiarowe dotyczące metryk są przechowywane i ich próbki są statystycznie analizowane. Arytmetyczna lub geometryczna średnia, mediana, maksimum, minimum, wyrażona procentowo lub ilościowo funkcja gęstości prawdopodobieństwa lub wariancja są typowymi statystykami bezpośrednimi (direct statistics), które mogą być bezpośrednio wyliczone z serii próbek danej metryki. Statystyki pośrednie (indirect statistics) mogą być otrzymywane przez estymację.
Przedstawione poniżej typowe statystyki mogą być obliczane w sekcji post-procesingu z serii próbek metryk bezpośrednich:
średnia,
mediana,
maksimum, minimum.
5.1.2.5. Przygotowanie informacji wyjściowych
Wyjściowymi danymi pomiarowymi mogą być zarówno dokładne wartości metryk, różnego rodzaju statystyki jak i abstrakcyjne decyzje. W zależności od typu wymaganych danych wyjściowych, post-procesing danych pomiarowych powinien odpowiednio formatować dane. Status procesu decyzyjnego zależy od wyniku prostego porównania, w którym porównuje się serię danych pomiarowych z ustalonym progiem.
5.2. Scenariusze pomiarów IP QoS [40]
5.2.1. Podejście sieciowe i komercyjne
Współpraca między Sprzedawcą (Seller), a Nabywcą Usług (Buyer) może być rozważana z różnych punktów widzenia. Jednym z nich jest podejście komercyjne (Business) inicjujące pomiary, natomiast drugie podejście to sieciowe (Network), które polega na przeprowadzeniu i wizualizacji mierzonych parametrów.
Usługa end-to-end (End-to-End Service)
Górna część rysunku 5.7. przedstawia trzy połączone ze sobą domeny IP, które zapewniają utrzymanie IP QoS pomiędzy Klientem, a Dostawcą Usługi. Część sieci, która zapewnia usługi end-to-end i jest zarządzana przez Dostawce Usług (Service Provider) oznaczono na kolor szary. Ten obszar sieci dostarcza usług pomiędzy punktem wejściowym #1, a punktem wyjściowym #6 poprzez kilka połączonych domen IP. Natomiast dolna część tego rysunku ilustruje połączenia sieciowe zapewniające utrzymanie usługi end-to-end, oznacza to, że Sprzedawca jest odpowiedzialny za całościowe zapewnienie usługi od punktu wejściowego #1 do punktu wyjściowego #6. Z drugiej strony Klient (Service Customer) jest zobowiązany do dostosowania do pewnego profilu ruchowego generowanego przez niego ruchu, wprowadzonego do wejściowego punktu #1.
Rysunek 5.7. Wymiana informacji kontraktowych pomiędzy Dostawcą Usługi (Service Provider) (górna część), a Klientem (Service Customer), oraz przesyłanie metryk mierzonych parametrów (dolna część) dla usług end-to-end [40]
Usługa tranzytowa (Transit Service)
Rysunek 5.8. Wymiana informacji kontraktowych pomiędzy połączonymi domenami IP (górna część), oraz przesyłanie metryk mierzonych parametrów dla usługi transportowej [40]
Rysunek 5.8. pokazuje podobny scenariusz jak w przypadku usługi end-to-end z tym, że prezentuje usługę tranzytową oferowaną przez Sprzedawcę Usługi IPND T dla Nabywcy Usługi IPND A. W tym przypadku termin „Dostawca Usług” oznacza dostawce, który udostępnia usługę pomiędzy punktem wejściowym #3, a punktem wyjściowym #4. Dolna część rysunku ilustruje połączenia sieciowe wykorzystywane przez Sprzedawcę, który jest odpowiedzialny za dostarczenie usługi pomiędzy punktami #3 i #4, a także przez Nabywcę, który jest zobowiązany do dostosowania do pewnego profilu ruchowego generowanego przez niego ruchu w punkcie wejściowym #3.
Jaki jest cel pomiarów?
Komercyjna i techniczna relacja pomiędzy Nabywcą i Sprzedawcą usługi jest regulowana przez różne umowy i porozumienia. W dalszej części pracy wzięto pod uwagę jedynie wymianę informacji technicznych zawartych w tychże porozumieniach takich jak: opis usługi (Service Description (SD)), specyfikacja stanu ruchu (Traffic Conditioning Specification (TCS)) i prognoza ruchu (Traffic Forecast (TF)). Obie strony mogą przeprowadzić pomiary parametrów usługi w celu sprawdzenia poprawności z zawartym wcześniej kontraktem. Tabela 5.3. przedstawia kilka scenariuszy pomiarowych mających na celu sprawdzenie własnych jak i wzajemnych zobowiązań zawartych w kontrakcie.
Tabela 5.3. Scenariusze oparte na różnych celach pomiarów, wykonywane przez różnych inicjatorów [40]
Scenariusz |
Inicjator |
Cel |
1 |
Nabywca IPND (Buyer IPND)
|
|
2 |
Sprzedawca IPND (Seller IPND)
|
|
3 |
Klient - Nabywca (Service Customer - Buyer) |
|
4 |
Dostawca Usługi - Sprzedawca (Service Provider - Seller) |
|
5 |
Sprzedawca (Seller) |
sygnalizacja alarmowa pozwalająca uniknąć problemów związanych z parametrami QoS |
6 |
Sprzedawca (Seller) |
specyfikacja możliwości przyszłych usług |
7 |
Sprzedawca (Seller) |
optymalizacja zasobów we własnej sieci |
Nabywca (Buyer) inicjuje scenariusz pomiarowy
Nabywca może przeprowadzić pomiary w celu sprawdzenia czy otrzymane parametry usługi są zgodne z parametrami zawartymi w TCS, a które są zapewnione przez Sprzedawcę (scenariusz 1a). W szczególności Nabywca może sprawdzić różne osiągi parametrów usługi (Service Performance Parameters), zakres (scope) otrzymanej usługi (np. numer osiągalnych punktów wyjściowych (egress points)/przejście do kolejnej domeny (next-hop network domains)), okres ważności (validity period) usługi, charakterystyki ruchowe dla wchodzącego i wychodzącego ruchu itp. W interesie Nabywcy jest także samokontrola zobowiązań zawartych w TCS i TF (scenariusz 1b). Nabywca powinien także weryfikować parametry wprowadzanego do sieci strumienia tak, aby nie przekroczyć zobowiązań opisanych w profilu ruchowym, który jest zawarty w TCS. Natężenie generowanego ruchu powinno odpowiadać regulacjom zawartym w TF najdokładniej jak to jest możliwe.
Sprzedawca (Seller) inicjuje scenariusz pomiarowy
Sprzedawca również powinien sprawdzać czy Nabywca dotrzymuje umowy zawartej w kontrakcie. Pomiary przeprowadzone przez Sprzedawcę mogą być porównane z samokontrolą zobowiązań Nabywcy w krytycznym przypadku. W umowie SLA zawarte są pewne progi dokładności kontroli TF (np. +20% ; -50%).
Podobnie jak Nabywca, Sprzedawca może przeprowadzić samokontrolę parametrów QoS wpływających na ruch strumieniowy wewnątrz domeny IPND zarządzanej przez Dostawcę (Supplier) (scenariusz 2b). Ten rodzaj pomiarów pozwala zoptymalizować wewnętrzną sieć (Internal Network) i w miarę możliwości wprowadzić nowe usługi.
Klient (Service Customer) inicjuje scenariusz pomiarowy
Klient nabywa usługę end-to-end od Dostawcy Usług (Service Provider), który może dzielić usługę end-to-end na segmenty usług transportowych, utrzymywanych przez różne domeny IP (IPND). Pomiary zainicjowane przez Klienta różnią się zakresem usług i poziomem szczegółowości od tych przeprowadzonych przez Nabywcę i Sprzedawcę. Dlatego Klient będzie sprawdzał inne metryki niż Nabywca IPND w scenariuszu 1a. Ponadto sprawdzane przez Klienta metryki są bardziej wyabstrahowane, a także rozdzielczość charakterystyk ruchu jest większa. Samokontrola polega na monitorowaniu jak duży ruch jest transmitowany do IPND A.
Dostawca usług (Service Provider) inicjuje scenariusz pomiarowy
Ten scenariusz odpowiada inicjacji scenariusza pomiarowego przez Sprzedawcę z tym wyjątkiem, że Dostawca Usług powinien sprawdzać parametry całości usług. W przypadku weryfikacji przesyłanego strumienia, samokontrola może wymagać zaangażowania jednej lub wielu IPND w celu przeprowadzenia pomiarów między dwoma punktami sieci np. w celu wyznaczenia jednokierunkowego opóźnienia (one-way delay).
5.3. Źródło informacji pomiarowych [40]
5.3.1. Punkty pomiarowe
Ten rozdział zawiera klasyfikacje typowych punktów obserwacji i pomiarów (Points of Observation and Measurement (POM)) pracujących w wybranych miedzy-domenowych scenariuszach pomiarowych. Rozróżniamy trzy ortogonalne kierunki, w których może być rozważana klasyfikacja punktów pomiarowych (POM):
horyzontalny (horizontally) wzdłuż ścieżki strumienia pakietów,
wertykalny (vertically) od warstwy fizycznej przez warstwę IP do warstwy aplikacji,
wertykalno-horyzontalny (plane-wise) zorientowane na użytkownika (user) kontrolowanie i zarządzanie warstwami.
5.3.1.1. Kierunek horyzontalny
Typowe punkty pomiarowe rozmieszczone wzdłuż ścieżki strumienia pakietów IP przenoszącego usługi pokazano na rysunku 5.9. Ponieważ zasadniczo te same punkty POM mogą pracować jako punkty z lokalnym lub zdalnym dostępem, między różnymi domenami IPND, na rysunku przedstawiono tylko część ścieżki end-to-end.
Rysunek 5.9. Punkty obserwacji i pomiaru rozmieszczone w kierunku horyzontalnym [40]
Przedstawione na powyższym rysunku punkty POM mogą być zaklasyfikowane do czterech różnych typów. Punkty MP2 i MP3 należą do pierwszego typu reprezentującego dostęp ruchu generowanego przez Klienta do lokalnej sieci dostępowej. Te punkty mają specjalne znaczenie, ponieważ usługa IP jest definiowana pomiędzy tymi dwoma punktami. Punkt MP1 jest umiejscowiony w hoście klienta. Pomiar end-to-end powinien obejmować swoim zasięgiem ten punkt, ale w rzeczywistości jest to trudne do zrealizowania.
Drugi typ punktów POM, zawierający MP4, MP5, MP6, MP7 reprezentuje rutery i switche pomiędzy lokalną siecią dostępową, a rdzeniem sieci IP. Gdzieś pomiędzy dwoma z tych punktów Dostawca Usług przekazuje odpowiedzialność za jakość usług do operatora IPND A, a także współpracujących z nim kooperatorów. W większości przypadków Dostawca Usług oddziela kontrakty z dostawcą usług sieci dostępowej (Access Network Provider) i IPND A. Punkty MP9 to punkty umiejscowione pomiędzy dwiema sąsiadującymi IPND, biorące udział we współpracy sprzedawca/nabywca. Rozróżniamy dwa typy punktów granicznych: wyjściowy ruter graniczny nabywcy i wejściowy ruter graniczny sprzedawcy.
Poza przedstawionymi interfejsowymi punktami sieciowymi, ruch może przechodzić przez specjalne urządzenia, które są w stanie obserwować i/lub mierzyć niektóre z parametrów QoS. Takie punkty mogą być wykorzystane do formowania ruchu, sygnalizacji QoS. Ponadto występują specjalne urządzenia, które nie uczestniczą w przesyłaniu pakietów IP, ale przesyłają informacje o ruchu np. przez kontrolę przesyłanych pakietów spokrewnionych z danym strumieniem (sygnalizacja). Przykłady takich węzłów to Policy Decision Points, Bandwidth Broker, Session Initiation Protocol (SIP) server, styk H.323, itp. Ten typ punktów jest reprezentowany przez MP10, co przedstawia rysunek 5.8.
5.3.1.2. Kierunek wertykalny
Zależnie od liczby warstw zaimplementowanych w sprzęcie sieciowym, pomiary mogą być przeprowadzone na kilku warstwach. Mimo tego, że ta praca skupia się na warstwie IP, warto wspomnieć także o ważnych informacjach pochodzących z warstw niższych (takich jak alarmy i statystyki ruchu z warstwy łącza) i wyższych (np. liczba retransmisji, suma kontrolna błędów i inne informacje z 4 warstwy), które mogą być wykorzystane do pomiaru warstwy IP. Należy pamiętać, że ważną sprawą jest odpowiednia interpretacja tychże informacji. Na przykład przepustowość mierzona w ATM-ie jest większa niż przepustowość strumienia pakietów IP, ponieważ występuje enkapsulacja. Tak, więc zwiększona przepustowość wprowadzona przez enkapsulację powinna być odjęta. Rysunek 5.10. ilustruje punkt POM dla brzegowego rutera IP z uwzględnieniem warstwy IP (MPa), warstwy ATM (MPb) i warstwy SDH (MPc). Podobne punkty mogą znajdować się w urządzeniach sieciowych występujących w punktach MP2, MP3, MP4, MP5, MP7, MP8 i MP9 (rysunek 5.8.). W przedstawionej strukturze, Sprzedawca jest odpowiedzialny za nadzór jego urządzeń wejściowych i monitorowanie doprowadzonych do nich połączeń.
Rysunek 5.10. Dodatkowe punkty pomiarowe rozmieszczone w kierunku wertykalnym [40]
5.3.1.3. Kierunek wertykalno-horyzontalny (Plane-wise)
Pakiety danych w strumieniu IP przede wszystkim przenoszą dane skojarzone z różnymi usługami, ale także, duża ilość informacji może być przekazywana i zbierana w celu kontroli i zarządzania obszarów spokrewnionych z danym strumieniem. Ważne parametry danej usługi mogą być otrzymane z protokołów sygnalizacyjnych warstwy 3 i warstwy 4 takich, jak: RSVP, TCP-ACK, RTCP, Q.2931. Ponadto, węzły pośredniczące w przenoszeniu ruchu stale obliczają różne parametry metryk (performance metrics) związanych z QoS, a uzyskane informacje przenoszone są w różny sposób (np. statystyki OSPF OMP). W celu zarządzania obszarem, jednym z rozwiązań jest zrobienie pułapek SNMP lub uruchomienie klientów COPS na ruterach/switchach w celu zbierania informacji pomiarowych.
5.3.2. Punkty pomiarowe dla między-domenowego zarządzania QoS
Usługa IP end-to-end udostępniona przez kilka połączonych domen IP może być utrzymana stosując model kaskadowy, gwiazdy lub model koncentratora (hub). W modelu kaskadowym oddzielna umowa SLA jest sporządzana pomiędzy parą sąsiadujących domen IPND. W modelu gwiazdy Dostawca Usług, posiadający lub nieposiadający domeny IPND na własność, sporządza oddzielną umowę SLA z każdą domeną IPND pośredniczącą w utrzymaniu usługi end-to-end. W obu przypadkach, komercyjne (business) relacje pomiędzy każdą parą połączonych IPND mogą być przedstawione jako relacje Nabywca-Sprzedawca. Nabywca transmituje ruch IP do Sprzedawcy IPND, który jest odpowiedzialny za przenoszenie ruchu przez domeny do wyjściowego portu jednego z należących do niego ruterów brzegowych lub do portu wejściowego sąsiadującej z nim domeny IPND.
Oba modele kaskadowy i gwiazdy wymagają, aby:
ruch opuszczający domenę IPND Nabywcy był zgodny w umową SLA pomiędzy domenami IPND Nabywcy i Sprzedawcy lub pomiędzy domeną IPND Nabywcy i Dostawcą Usług,
usługi oferowane przez Sprzedawcę IPND mają być zgodne z warunkami wyszczególnionymi w umowie SLA pomiędzy domenami IPND Nabywcy i Sprzedawcy lub pomiędzy domeną IPND Sprzedawcy i Dostawcą Usług.
W celu weryfikacji zgodności w obu przypadkach, jest konieczne przeprowadzenie pomiarów różnych typów metryk ruchu zarówno wchodzącego, jak i wychodzącego z domeny Sprzedawcy. Powyższe zagadnienia będą przedyskutowane na przykładzie trzech połączonych domen IPND i jednego Dostawcy Usług połączonych razem według modelu hub, co ilustruje rysunek 5.11.
Rysunek 5.11. Domeny IP połączone według modelu hub [40]
W przedstawionym przypadku założono, że ruch przepływa w jednym kierunku z A-end do Z-end. IPND-A jest tu nabywcą (Buyer), a IPND-T jest sprzedawcą (Seller) dla ruchu przechodzącego z IPND-A do IPND-T.
Rysunek 5.12. wywodzi się z poprzedniego rysunku z tym, że usunięto niektóre szczegóły, a dodano informacje związane z przeprowadzeniem pomiarów sieci.
Rysunek 5.12. Rozmieszczenie punktów pomiarowych [40]
Powyższy rysunek ilustruje trzy punkty pomiarowe, jeden dokonujący pomiaru ruchu w wyjściowym porcie rutera brzegowego domeny IPND-A, drugi w wejściowym porcie rutera brzegowego domeny IPND-T i trzeci w wyjściowym porcie kolejnego rutera brzegowego domeny IPND-T.
Sprawdzenie czy Nabywca (Buyer) dostosowuje się do kontraktu
Dwa punkty pomiarowe IPND-A MP-out i IPND-T MP-in są użyte do sprawdzenia parametrów ruchu Nabywcy to znaczy, ruchu opuszczającego domenę IPND-A, a wchodzącego do domeny IPND-T. Punkt IPND-A MP-out jest punktem związanym z ruchem opuszczającym domenę IPND-A, który jest mierzony przez IPND-A. Podobnie IPND-T MP-in jest punktem związanym z ruchem przechodzącym przez IPND-T, a pochodzącym z IPND-A, który jest mierzony przez IPND-T. Pomiary w obu przypadkach powinny być przeprowadzone identycznie lub różnice między nimi powinny być zgodne z akceptowalnym przedziałem wartości, a także powinny być zgodne z umową SLA zawartą pomiędzy obiema domenami IPND i Dostawcą Usług 1.
Sprawdzenie czy Sprzedawca (Seller) dostosowuje się do kontraktu
Dwa punkty pomiarowe IPND-T MP-in i IPND-T MP-out są użyte do sprawdzenia osiągów domeny IPND-T. IPND-T MP-in może być użyty jako punkt wprowadzający ruch testowy dla domeny IPND-T, a punkt IPND-T MP-out jako punkt, w którym po analizie ruchu testowego otrzymuje się wyniki pomiarów.
Sprawdzenie osiągów end-to-end
Na rysunku 5.12. można zaobserwować, że usługi oferowane przez Dostawce Usług 1 rozciągały się na trzy domeny IPND. W celu zapewnienia odpowiednich parametrów usługi end-to-end zawartych w umowie SLA ustanowionej pomiędzy Dostawcą Usług 1 i jego klientami wymagane jest przeprowadzenie pomiarów pomiędzy punktami, gdzie ruch klientów wchodzi i wychodzi z sieci Dostawcy Usług. Te punkty nazwano Service Termination Points (STP) i przedstawiono je na rysunku 5.13.
Pomiary metryk usługi end-to-end np. opóźnienie jednokierunkowe (one-way-delay), opóźnienie dwukierunkowe (round-trip-delay), itp. może być mierzone pomiędzy dwoma punktami STP i sprawdzane z wymogami umowy SLA w celu wykrycia naruszenia tejże umowy. Pomiary end-to-end mogą być także porównane z sumą indywidualnych pomiarów przeprowadzonych przez każdą z domen IPND. Jakakolwiek rozbieżność może wskazywać, że pomiary otrzymane od jednej lub więcej domen IPND są niepoprawne.
Nie jest proste przeprowadzenie pomiarów end-to-end przez Dostawce Usług pomiędzy punktami MP przedstawionymi na rysunku 5.13., dlatego wymagana jest współpraca z klientami.
Rysunek 5.13. Przeprowadzenie pomiarów usługi end-to-end [40]
5.3.3. Punkty pomiarowe dla pomiarów wewnątrz-domenowych
Ten rozdział opisuje punkty pomiarowe wykorzystane do pomiarów metryk QoS wewnątrz domen IPND. Rysunek 5.14. pokazuje różne punkty pomiarowe które, mogą wystąpić wewnątrz domeny IPND w celu pomiaru różnych typów metryk QoS.
Rysunek 5.14. Punkty pomiarowe dla pomiarów metryk QoS wewnątrz domen IPND [40]
MP-Node: Ten typ punktu pomiarowego jest przewidziany do pomiarów poziomu metryk QoS w węzłach domeny. Może on występować zarówno w ruterach wejściowych/wyjściowych (edge/border) jak i w ruterach rdzeniowych (core). Metryki QoS, które powinny być mierzone przy użyciu MP-Node zawierają „metryki osiągów rutera” (router performance metrics) i „metryki stanu i klasyfikacji ruchu” (traffic classification and conditioning metrics).
MP-Link: Ten typ punktu pomiarowego może być użyty do pomiaru metryk związanych z łączem pomiędzy dwoma węzłami. Punkty te w celu np. pomiaru przepustowości mogą analizować niektóre wartości pól w nagłówkach pakietów np. adres źródłowy i docelowy, DSCP, itp. Opisywane punkty pomiarowe mogą występować zarówno w portach wejścia/wyjścia danego węzła lub na fizycznym łączu pomiędzy połączonymi ze sobą węzłami.
MP-Network: Ten typ punktów pomiarowych jest zazwyczaj używany w parach (node-to-node) w celu pomiaru poziomu metryk sieci. Punkty te mogą być użyte do pomiaru Metryk Osiągów Usługi (Service Performance) dla całej domeny IPND, jeśli zostanie wybrana para punktów znajdująca się w węźle wejściowym i wyjściowym. Metryki, które mogą być mierzone zawierają: opóźnienie jednokierunkowe (one-way-delay), opóźnienie dwukierunkowe (roundtrip-delay), IPDV i straty (loss). Metryki te mogą być także mierzone dla różnych klas usług lub zagregowanych strumieni ruchu, jeśli docelowa siec potrzebuje rozróżnienia miedzy nimi.
MP-Control: Ten typ punktów pomiarowych powinien być użyty do pomiarów w obszarze kontroli sygnalizacja/ruch (information/traffic). Dla przykładu w domenach IPND wykorzystujących rezerwacje zasobów przez sygnalizację, mogą być mierzone zarówno ilość jak i wynik rezerwacji. Typowym miejscem dla tychże punktów pomiarowych są: Policy Decision Points, Bandwidth Broker, Session Initiation Protocol (SIP) server, styk H.323, rutery zdolne wyznaczyć statystyki TE (Traffic Engineering), takie jak OSPF-OMP.
5.4. Metryki QoS [40]
Metryka QoS jest to ilościowy opis wartości parametrów QoS. Zarówno Klient jak i Dostawca Usługi (podobnie jak Sprzedawca i Nabywca Usługi domen IPND) muszą wykonywać pomiary metryk QoS (ilościowo określić wartość metryki), aby móc zawierać porozumienia między sobą zawierające zobowiązania jakościowe, a także kontrolować się na wzajem.
Wykonując pomiary parametrów QoS należy wziąć pod uwagę następujące kryteria:
metryka musi mieć istotne znaczenie dla opisu oferowanej usługi w rozważanym przypadku,
wykonując rzeczywisty pomiar w konkretnym środowisku między-domenowym metryka musi być realizowalna fizycznie,
musi istnieć możliwość ilościowego opisu danej metryki,
dostępne narzędzia i technologie powinny być stanie zmierzyć wartość metryki.
5.4.1. Klasyfikacja metryk QoS
Metryki profilu ruchu i metryki osiągów usługi
Wyróżniamy dwa typy metryk zorientowane na usługi IP QoS:
Metryki Profilu Ruchu (Traffic Profile Metrics)
Metryki Osiągów Usługi (Service Performance Metrics)
Metryka pierwszego typu charakteryzuje strumień pakietów IP w zadanym punkcie na ścieżce end-to-end. Dla przykładu, ruch generowany przez Klienta może być opisany poprzez pomiar szczytowej szybkości transmisji (peak bit rate) w brzegowym, wejściowym ruterze domeny IPND A (rysunek 5.13.). Typowymi punktami pomiarowymi dla tych metryk są: MP2, MP4 i MP7 na rysunku 5.9. lub IPND-T MP-in na rysunku 5.12.
Metryki drugiego typu charakteryzują wpływ domeny IPND na strumień pakietów IP lub na całkowity wpływ połączonych ze sobą domen IPND na strumień na drodze end-to-end. Wpływ ten może być wyznaczony przez porównanie profili ruchowych w punktach wejściowych i wyjściowych domeny IPND i wyliczenie różnic. Rysunek 5.15. przedstawia obszar zastosowań wspomnianych dwóch typów metryk i podaje przykłady dla obu z nich. Dla przykładu, Klient może mierzyć odpowiedz czasową ze swojego rutera, znajdującego się po „drugiej stronie sieci”. Typowymi punktami dla Metryk Osiągów Usługi są rutery brzegowe miedzy domenami IPND (MP7 i MP9 na rysunku 5.9. lub IPND-T MP-in i IPND-T MP-out na rysunku 5.12.).
Rysunek 5.15. Metryki Osiągów Usługi i Profilu Ruchu [40]
Metryki bezpośrednie i pośrednie
Kolejnym sposobem klasyfikacji metryk jest sprawdzenie czy dana wielkość opisywana przez metrykę może być otrzymana bezpośrednio z procesu pomiarowego, czy może być wyliczona dopiero wtedy, gdy przeprowadzimy pomiary innych metryk i wykorzystamy otrzymane dane do obliczeń. Pierwszy typ wspomnianych metryk nazywamy metrykami bezpośrednimi (primary metrics). Prosty post-processing danej metryki (np. obliczanie statystyk pierwszego lub drugiego rzędu) jest uważany jako integralna część procedury pomiarowej, a zatem metryki takie jak średnie opóźnienie (average delay) lub maksymalna przepustowość (maximum throughput), należą do tej kategorii. Metryki pośrednie są otrzymywane z kilku metryk bezpośrednich, z których każda dostarcza informacji różnego typu (np. opóźnienie i strata pakietów) lub pobierana jest z różnych punktów sieci.
Metryki krótko i długo-terminowe
Metryki ruchowe mogą być klasyfikowane według krótko-terminowych lub długo-terminowych odcinków czasu, w którym są sporządzane (np. przedział czasu krótszy niż godzina lub dłuższy niż godzina).
Statystyki długo-terminowe są bardzo użyteczne dla inżynierii ruchu do wyznaczenia okresowego obciążenia sieci (w zależności od godziny czy dnia) jak również do wyznaczenia tendencji ruchu, nierównomierności w obciążeniu łączy spowodowanym nieprawidłową pracą ruterów lub innych czynników.
Statystyki krótko-terminowe powinny dostarczać wiarygodnych i pewnych informacji o bieżącym stanie sieci. Niektóre krótko-terminowe statystyki ruchu mogą odzwierciedlać stan obciążenia i zatoru łączy. Przykładami zastosowania tychże statystyk są wskazania dotyczące nadmiernego opóźnienia pakietów, utrata pakietów oraz wysokie obciążenie zasobów sieci.
Dodatkowe informacje dla procesu sporządzania metryk QoS
Metryki profilu ruchu lub osiągów usługi nie mogą być rozważane jako niezależne od innych czynników. Istnieją czynniki, które powinny być wzięte pod uwagę podczas sporządzania metryki, są to: identyfikator usługi (identification of the service), stan ruchu (status of traffic), całkowity czas (time) zbierania informacji oraz stan sieci (network status).
Olbrzymie znaczenie podczas pomiarów ma składowanie (record) uzyskanych informacji, które mogą być użyte do identyfikacji usługi QoS end-to-end (E2EIDQoS) lub strumienia pakietów IP. Istnieje kilka poziomów rozdzielczości identyfikacji usługi, zależnie od definicji samej usługi (hose, funnel, pipe) i możliwości sprzętu pomiarowego jak również systemu post-processingu metryk (np. pojemność pamięci, szybkość, częstotliwość próbkowania). Tabela 5.4. przedstawia różne poziomy rozdzielczości dla wyspecyfikowania ze strumienia pakietów IP usługi E2EIDQoS.
Tabela 5.4. Klasyfikacja usług E2EIDQoS wyspecyfikowana ze strumienia pakietów w zależności od różnych poziomów rozdzielczości [40]
Rozdzielczość |
Informacja klasyfikacyjna |
Sieć przeznaczenia |
Ustawienie prefiksu przeznaczenia |
Host przeznaczenia |
Adres IP przeznaczenia |
Klasa |
Pole ToS (lub DSCP) |
Strumień |
Nagłówek IP + numery portu |
Aplikacja |
Nagłówek IP + nagłówek aplikacji |
Całość |
Pole ToS (lub DSCP)/ nagłówek IP + numery portu i pełna ścieżka |
Aby być w stanie poprawnie ocenić daną metrykę należy wziąć pod uwagę rodzaj mierzonego ruchu. Mówiąc bardziej szczegółowo TCS (Traffic Conditioning Specification) w różny sposób traktuje profile ruchowe dla ruchu wchodzącego i wychodzącego. A zatem przy sporządzaniu metryk profilu ruchowego i osiągów usługi należy wziąć pod uwagę ruch wchodzący i wychodzący. Jest to zazwyczaj oznaczane przez pole kodowe DSCP.
Zarówno sporządzone umowy jak i fizyczne parametry sieci są zależne od czasu.
A zatem czas powinien być zapisywany z odpowiednią dokładnością nawet w przypadku metryk niezwiązanych z opóźnieniami lub z nimi związanych. Dla pomiarów długo-terminowych podanie daty może być zadowalające, ale w przypadku monitorowania opóźnień w czasie rzeczywistym wymagana jest najwyższa możliwa precyzja. Zapis informacji czasowych może być potrzebny także do utrzymania dynamicznych umów SLA.
Poza stanem ruchu podczas testu, stan sieci może być także istotnym czynnikiem, który może wspierać złożone decyzje operacyjne, takie jak aktywacja lub dezaktywacja alternatywnych ścieżek lub równomierne rozłożenie ruchu w sieci (rebalancing).
5.4.2. Metryki bezpośrednie (Primary Metrics)
5.4.2.1. Bezpośrednie Metryki Profili Ruchu (Primary Traffic Profile Metrics)
Odnośnie między-domenowych usług IP, rozróżnia się dwa sposoby sporządzania Metryk Profili Ruchu. Pierwszy, kiedy pomiar strumienia ruchu danej usługi IP odbywa się w wybranym punkcie i jest użyty do sprawdzenia czy ruch generowany przez Nabywcę IPND lub Klienta do domeny Sprzedawcy IPND spełnia wymagania zawarte w umowie SLA. Drugi, gdy metryki mogą być otrzymane przez sporządzenie i porównanie metryk profili ruchu w dwóch kolejnych punktach ścieżki end-to-end.
Najważniejszymi metrykami profili ruchu zorientowanymi na użytkownika są:
Szybkość transmisji (Information Rate)
Charakteryzuje natężenie ruchu, to znaczy ilość informacji, jaka przepływa przez punkt pomiarowy w określonym czasie. Może być wyrażony na przykład jako szczytowa szybkość transmisji (Peak Rate) [bity na sekundę] lub średnia szybkość transmisji (Mean Rate) [bity na sekundę lub pakiety na sekundę].
Rozmiar bursta (Burst Size)
Opisuje rozmiar jednostki transportowej połączonych ze sobą, następujących po sobie (back-to-back) pakietów. Używane są określenia maksymalnego i normalnego rozmiaru bursta.
Numery pakietów i ich rozmiary (number of packets and their sizes)
Zdefiniowane w [RFC 2011] [41].
Numery pakietów z błędnymi nagłówkami (number of packets with erroneous headers)
Zdefiniowane w [RFC 2011] [41].
Parametry wiadra tokenowego (Token Bucket Parameters)
Specyfikujące szybkość napełniania wiadra tokenowego (Token Bucket Rate) [bity na sekunde] i głębokość wiadra tokenowego (Token Bucket Depth) [bajty] dla algorytmów wykorzystujących metodę wiadra tokenowego [RFC 2210] [25].
Każda z tych metryk może być określona dla interfejsów, klas ruchu, klienta lub strumienia. Ale poza ruchem w obszarze użytkownika, obszar kontroli i zarządzania ruchu powinien być także kontrolowany, ponieważ informacje sygnalizacyjne (messages) (np. ICMP, RSVP, BGP, SNMP) mają duży wpływ na pracę ruterów w domenie IPND. Dlatego należy wprowadzić kolejne metryki profili ruchu zorientowane na kontrole i zarządzanie:
Intensywność sygnalizacji (Intensity of signalling)
Daje informacje o ilości wiadomości sygnalizacyjnych (messages) przychodzących do wybranego portu wejściowego danego rutera w ciągu sekundy. Jest wyrażana w liczbie wiadomości na sekundę.
Burst sygnalizacyjny (Signalling burst)
Opisuje ilość wiadomości sygnalizacyjnych, które przychodzą do wejściowego portu rutera obsługującego daną sygnalizację. Może być wyrażona przez podanie ilości informacji sygnalizacyjnej w burście.
5.4.2.2. Bezpośrednie Metryki Osiągów Usługi (Primary Service Performance Metrics) - SPM
Podczas gdy Metryki Profili Ruchu doskonale nadają się do scharakteryzowania ruchu generowanego przez Nabywcę, tak Metryki Osiągów Usługi mogą być użyte do sprawdzenia czy Sprzedawca jest w stanie dotrzymać zobowiązań swojej części TCS (Traffic Conditioning Specification). Metryki Osiągów Usługi mogą być sklasyfikowane do następujących czterech grup zorientowanych na:
połączenia (connectivity related);
pasmo (bandwidth related) (np. sprawność (goodput), przepustowość (throughput));
opóźnienia (latency related) (np. czas reakcji (response time), opóźnienie pakietu (packet delay), zmienność opóźnienia (jitter));
straty i błędy (loss or error related).
Metryki osiągów usługi mogą odnosić się zarówno do pojedynczych węzłów jak i całej domeny IPND czy nawet do ścieżki end-to-end. SPM odnoszące się do węzła (Per-Node) charakteryzują osiągi rutera IP, do sieci tranzytowej (Transit Network) opisują stan jednej z domen IPND, a odnoszące się do ścieżki end-to-end charakteryzują osiągi usługi w całości, utrzymywanej przez połączone, współpracujące ze sobą domeny IPND. SPM dla sieci tranzytowej są używane w 1 i 2 scenariuszu pomiarowym, dla ścieżki end-to-end w 3 i 4, natomiast dla pojedynczego węzła w scenariuszu 5 (patrz tabela 5.3.).
Parametry Osiągów Usługi związane z połączeniami (Connectivity Related Service Performance Parameters):
Chwilowe opóźnienie nawiązania połączenia jednokierunkowego (Instantaneous One-way Connectivity)
Definicja [RFC 2678] [42]: Źródło (adres IP hosta źródłowego) nawiąże połączenie (Type-P-Instantaneous-Unidirectional-Connectivity) z Celem (adres IP hosta adresata) w czasie T, jeżeli pakiet type-P nadany ze Źródła do Celu dotrze do niego w czasie T.
Definicja nie mówi jasno, KIEDY pakiet dotrze do Celu.
Chwilowe opóźnienie nawiązania połączenia dwukierunkowego (Instantaneous Two-way Connectivity)
Definicja [RFC 2678] [42]: Adresaci A1 i A2 nawiążą połączenie (Type-P-Instantaneous-Bidirectional-Connectivity) w czasie T, jeżeli adresat A1 nawiąże połączenie (Type-P-Instantaneous-Unidirectional-Connectivity) z adresatem A2 i adresat A2 nawiąże połączenie (Type-P-Instantaneous-Unidirectional-Connectivity) z adresatem A1.
Połączenie jednokierunkowe (One-way Connectivity)
Definicja [RFC 2678] [42]: Adresat Źródłowy nawiąże połączenie (Type-P-Interval-Unidirectional-Connectivity) z adresatem Docelowym w przedziale czasu [T, T+dT], jeżeli są takie T' z przedziału [T, T+dT] w którym nawiąże połączenie z Celem.
Połączenie dwukierunkowe (Two-way Connectivity)
Definicja [RFC 2678] [42]: Adresaci A1 i A2 nawiążą połączenie (Type-P-Interval-Bidirectional-Connectivity) między sobą w przedziale czasu [T, T+dT], jeżeli adresat A1 nawiąże połączenie (Type-P-Interval-Unidirectional-Connectivity) z adresatem A2 w podanym przedziale czasu i adresat A2 nawiąże połączenie (Type-P-Interval-Unidirectional-Connectivity) z adresatem A1 w podanym przedziale czasu.
Parametry Osiągów Usługi związane z pasmem przenoszenia danych (Bandwidth Related Service Performance Parameters):
Sprawność (Goodput) [RFC 2647] [43]
Istnieje wiele różnych definicji tej metryki. Niektóre z nich zawierają aspekty czasowe, niektóre biorą pod uwagę całe pakiety, inne tylko „ładunek użyteczny” (payload), jako niezbędne do ich specyfikacji. W tej pracy postanowiono użyć definicji przedstawionej poniżej:
Sprawność (Goodput) jest definiowana jako stosunek poprawnie przesłanego ruchu Warstwy Aplikacji (Application Layer) podzielonego przez pasmo użyte do tego celu i jest wyrażany procentowo.
Wymagane pasmo użyte w powyższej charakterystyce omawianej metryki zawiera także uszkodzone, utracone i retransmitowane pakiety i różni się od definicji przepustowości podanej w ITU-T I.380 [51]. Ważnym zastosowaniem metryki Sprawności jest użycie jej w wyższych warstwach aplikacyjnych IP (np. TCP lub HTTP).
Parametry Osiągów Usługi związane z opóźnieniami (Latency Related Service Performance Parameters):
Opóźnienie transferu pakietów IP (IP packet transfer delay (IPTD))
Ponieważ definicje IETF są częściej implementowane przez koncerny produkujące sprzęt sieciowy niż standardy ITU, te właśnie definicje zostały wybrane.
Definicje metryki jednokierunkowego opóźnienia (one-way-delay) [RFC 2679] [44]: Dla rzeczywistego dT, „jednokierunkowe opóźnienie pakietu nadanego w czasie T ze Źródła do Celu wynosi dT” oznacza to, że Źródło nadaje pierwszy bit pakietu Type-P do Celu w czasie nadania T, po czym Cel odbiera ostatni bit tego pakietu w czasie T+dT.
Dwukierunkowy czas przejścia (Round-Trip Time)
W niektórych przypadkach dwukierunkowy czas przejścia jest bardziej istotny niż jednokierunkowe opóźnienie. Dlatego też zdefiniowano odpowiednią metrykę w [RFC 2681] [45]: Dla rzeczywistego dT, „dwukierunkowy czas przejścia pakietu nadanego w czasie T ze Źródła do Celu wynosi dT” oznacza to, że Źródło nadaje pierwszy bit pakietu Type-P do Celu w czasie nadania T, po czym Cel otrzymuje ten pakiet i natychmiast wysyła pakiet Type-P z powrotem do Źródła, które odbiera ostatni bit tego pakietu w czasie T+dT.
Występują dwie różne metryki związane z opóźnieniem transferu pakietów IP (IP packet transfer delay (IPTD)): „średnie opóźnienie transferu pakietów IP”, które jest arytmetyczną średnią IPTD i „zmienność opóźnienia pakietów IP”, które jest ważne, na przykład w retransmisji pakietów.
Zmienność opóźnienia (Delay Variation)
Definicja opisująca zmienność opóźnienia jest dana w dokumencie IETF [IppmIpdv] [52]. Ponadto można wyszczególnić wśród definicji chwilowej zmienności opóźnienia (Instantaneous Packet Delay Variation (ipdv)) definicje dla pary pakietów lub dla pakietów wewnątrz strumienia.
Dla pary pakietów:
„ipvd dla pary pakietów, które przechodzą z punktu pomiarowego MP1 do punktu pomiarowego MP2, jest różnicą pomiędzy pomiarem jednokierunkowego opóźnienia pakietu drugiego, a pomiarem jednokierunkowego opóźnienia pakietu pierwszego, będących pakietami należącymi do tejże pary pakietów”.
Dla strumienia pakietów:
„ipvd pakietu IP, wewnątrz strumienia pakietów, przechodzących z punktu pomiarowego MP1 do punktu pomiarowego MP2, jest różnicą jednokierunkowego opóźnienia tego pakietu i jednokierunkowego opóźnienia poprzedniego pakietu w strumieniu.
Parametry Osiągów Usługi związane ze stratami i błędami (Loss / Error Related Service Performance Parameters):
Stopa błędnych pakietów IP (IP packet error ratio (IPER))
Definicja [I.380] [51]: „Stosunek uszkodzonych pakietów IP oznacza stosunek ilości uszkodzonych pakietów IP podzielonej przez ilość wszystkich poprawnie transmitowanych pakietów IP łącznie z uszkodzonymi pakietami”.
Strata pakietów IP (IP packet loss ratio (IPLR))
Definicja [I.380] [51]: „Strata pakietów IP oznacza stosunek ilości utraconych pakietów IP podzielonej przez ilość transmitowanych pakietów IP”.
Kolejna definicja metryki jednokierunkowej straty (one-way-loss) pakietu jest dana w [RFC 2680] [46]: „Jednokierunkowa strata pakietu nadanego w czasie T ze Źródła do celu wynosi 0”, oznacza to, że Źródło nadaje pierwszy bit pakietu Type-P do Celu w czasie nadania T, po czym Cel odbiera ten pakiet. „Jednokierunkowa strata pakietu nadanego w czasie T ze Źródła do Celu wynosi 1”, oznacza to, że Źródło nadaje pierwszy bit pakietu Type-P do Celu w czasie nadania T, po czym Cel nie odbiera tego pakietu.
5.4.3. Sporządzanie pośrednich metryk dla jednej domeny IP
W tym rozdziale zaprezentowano listę pośrednich metryk wywodzących się z bezpośrednich Metryk Osiągów Usługi i bezpośrednich Metryk Profili Ruchu. Wspomniane pośrednie metryki zaklasyfikowano do trzech kategorii:
Pośrednie metryki wykorzystane do dostarczenia dodatkowych informacji związanych z metrykami profilu ruchowego, które Nabywca (Nabywca IPND lub Klient) powinien wykonywać w celu utrzymania zobowiązań zawartych w umowie SLA (ściślej w TCS i TF).
Pośrednie metryki osiągów usługi, które Sprzedawca (Sprzedawca IPND lub Dostawca Usługi) może użyć w celu otrzymania bardziej dokładnego opisu spełniania zobowiązań zawartych w SLA/TCS.
Metryki „dostępności” (Availability) usługi end-to-end QoS IP.
Poniższy rysunek ilustruje proste zależności pomiędzy pośrednimi metrykami i bezpośrednimi metrykami osiągów usługi i profili ruchu.
Rysunek 5.16. Zależności pomiędzy bezpośrednimi i pośrednimi metrykami [40]
5.4.3.1. Pośrednie metryki profili ruchu
Liczba pakietów lub bajtów w profilu
Bazując na metrykach pomiarowych stanu ruchu [I.380] [51] w wejściowych węzłach sieci, Sprzedawca domeny IPND może obliczyć liczbę pakietów lub bajtów otrzymanych od Nabywcy i liczbę pakietów, która odpowiada profilowi ruchu zawartego w SLA. Dla przykładu, jeżeli profil ruchowy określono jako maksymalna przepustowość i maksymalny rozmiar bursta dla ruchu Nabywcy, to Sprzedawca może określić liczbę pakietów Nabywcy, która spełnia podany limit. Głównym problemem dla Sprzedawcy będzie zdolność wyróżnienia strumienia z pośród klas usługi (Class of Service (CoS)) zagregowanego ruchu.
Liczba pakietów lub bajtów poza profilem
Bazując na metrykach pomiarowych stanu ruchu w wejściowych węzłach sieci, Sprzedawca IPND może obliczyć liczbę pakietów lub bajtów otrzymanych od Nabywcy, która nie odpowiada profilowi ruchu zawartego w SLA. Te pakiety są odrzucane lub oznaczane jako pakiety o niższym poziomie QoS.
Liczba odrzuconych pakietów lub bajtów
Ta metryka opisuje liczbę pakietów lub bajtów otrzymanych od Nabywcy, które są poza profilem i są odrzucone.
5.4.3.2. Pośrednie metryki osiągów usługi
Sumowanie przepustowości (Aggregated Throughput)
Umowa SLA pomiędzy Nabywcą a Sprzedawcą może obejmować znaczną liczbę pojedynczych przepływów (np. Nabywca może wynegocjować pojedyncza umowę SLA obejmującą wszystkie dane video-konferencyjne wysyłanych do danego adresu przeznaczenia). Każdy z pojedynczych przepływów może być transmitowany przez sieć z różną przepustowością (throughput). Wtedy przepustowość opisana w SLA będzie obejmowała sumą przepustowości pojedynczych strumieni.
Jako przykład, rozważmy przypadek, w którym Sprzedawca IPND dostarcza usługę QoS dla dwóch przepływów (flow 1 i flow 2) pochodzących od tego samego Nabywcy (rysunek 5.17.). QoS jest utrzymane dla przepływów w sieci przez zdefiniowanie pojedynczej umowy SLA pomiędzy Sprzedawcą i Nabywcą. Stosując pomiary pasywne (passive measurements) w wyjściowych ruterach ER1 i ER2, Sprzedawca może obliczyć przepustowość każdego z przepływów (np. 300 kps i 400 kps). Ta metoda wymaga klasyfikacji Multi-Field (MF) dla ruchu wychodzącego we wszystkich ruterów brzegowych sieci. Istotne dla pomiarów pasywnych jest wykonanie pomiarów dla pojedynczych przepływów a nie dla zagregowanego ruchu. Następnie Sprzedawca może dodać wartość przepustowości obu przepływów, aby odnieść je do przepustowości zdefiniowanej w danej umowie SLA. Kolejną ważną kwestią jest potrzeba posiadania narzędzi zarządzających pomiarami, w których byłyby zbierane informacje pochodzące z pośrednich metryk.
Rysunek 5.17. Obliczanie metryk przepustowości będącej sumą przepustowości dwóch przepływów [40]
Straty tranzytowe (Aggregated loss rate)
Sprzedawca powinien mierzyć przepustowość całego ruchu Nabywcy, objętego przez umowę SLA. Ruch ten wchodzi do sieci przez pojedynczy węzeł wejściowy. Wtedy strata tranzytowa SLA (loss rate) jest definiowana jako różnica pomiędzy przepustowością ruchu Nabywcy w węźle wejściowym i przepustowości opisanej w SLA. Ta definicja straty tranzytowej SLA ma znaczenie tylko wtedy, kiedy usługa zakontraktowana przez Nabywcę w SLA jest usługą tranzytową (transit service) (tzn. cały nadchodzący ruch Nabywcy opuszcza domenę Sprzedawcy przez wyjściowe węzły).
Efektywność CoS (CoS Utilisation)
Sprzedawca IPND wie, ile wynosi na każdym węźle w sieci, wartość pasma przydzielonego dla poszczególnej klasy CoS (np. 19 % pasma przydzielone dla klasy EF, w przypadku, kiedy mamy do czynienia z siecią DiffServ). Dodatkowo Sprzedawca może uzyskać z węzła MIB (np. DiffServ MIB) współczynnik efektywności (utilisation rate) CoS (np. 75 % przydzielonego pasma jest użyte). Jest to szczególnie przydatne do monitorowania obciążenia sieci.
5.4.3.3. Metryka Dostępności Usługi QoS (The QoS Service Availability Metric)
Ta pośrednia metryka osiągów usługi łączy różne typy metryk bezpośrednich w celu charakterystyki całości usługi tranzytowej lub usługi end-to-end. Główną kwestią jest wybranie odpowiednich metryk osiągów usługi, które będą użyte do sporządzenia metryki dostępności. W tym podrozdziale zamieszczono opis wspomnianych zagadnień jak i metody obliczeniowe użyte do wyliczenia metryk dostępności.
Wstęp
Termin „dostępność” może mieć wiele różnych konotacji (znaczeń), dlatego ważne jest podanie jasnej, zrozumiałej definicji metryki dostępności dla usług QoS IP. W tej pracy, dostępność jest definiowana jako procentowa metryka opisująca procent czasu (średnia), w którym usługa jest dostępna w ciągu danego okresu czasu. Dla przykładu, usługa może być opisana jako posiadająca 99,99% dostępność end-to-end w ciągu roku.
Tradycyjnie, obliczenia metryki dostępności bazowały jedynie na metrykach zorientowanych na połączenia. W Internecie opartym na best-effort, usługa jest uważana jako dostępna w określonym czasie, jeżeli połączenie pomiędzy punktami końcowymi (end-points) jest utrzymane, niezależnie do tego czy Klient doświadcza usługi QoS na zadawalającym poziomie. Dlatego, kiedy oferowana usługa jest traktowana jako usługa QoS, opisująca ją metryka dostępności musi być uzupełniona o dodatkowe kryteria związane z QoS. Takie metryki dostępności są nazywane Metrykami Dostępności Usługi QoS (QoS Service Availability).
Metryka Dostępności Usługi QoS może być zdefiniowana jako procent czasu (średnia), w którym wartości metryki osiągów usługi, podanej w SLA, nie jest przekroczona. Należy, zatem wyliczyć czy usługa QoS jest dostępna w danym czasie. Dlatego opis usługi QoS musi bazować na wartościach progowych (tzn. maksimum lub minimum) Metryk Osiągów Usługi (np. maksymalne dwukierunkowe opóźnienie = 50 ms), które mogą być stale monitorowane. Średnie wartości dla metryk osiągów usługi mogą być podane w SLA, ale nie mogą być użyte do obliczeń dostępności usługi QoS.
Bazując na powyższych opisach dostępności usługi QoS można zaproponować metodę wyliczenia tej metryki. Klient (Customer) i Dostawca (Provider) powinni ustalić wartości progowe dla metryk osiągów usługi, opisujących usługę QoS w celu wyliczenia dostępności usługi QoS. Dla przykładu:
Maksymalne jednokierunkowe opóźnienie = 50 ms (One-way Delay)
Maksymalny stosunek jednokierunkowej straty = 0,01 % (One-way Loss Ratio)
Minimalna jednokierunkowa przepustowość = 2Mbps (One-way Throughput)
Następnie, biorąc pod uwagę zobowiązania zawarte w SLA pomiędzy klientem a dostawcą można sprawdzić czy w jakimś punkcie czasu wartości pomiarowe jednej z metryk osiągów usługi znajdują się poza zakontraktowaną wartością, wtedy usługa QoS jest uważana jako niedostępna w tym punkcie czasu. Użycie jednokierunkowych jak i dwukierunkowych metryk jest poprawne.
Jednokierunkowa Dostępność Usługi QoS (One-way QoS Service Availability)
Parametry metryki:
ΔT - krótki okres czasu (np. 5 minut), podczas, którego określana jest dostępność usługi QoS.
<T0; Tf> - przedział czasu, dla którego usługa QoS musi być dostępna.
Gdzie Tf = T0 + f ×TΔ, dla f dodatnich, całkowitych.
Tn - czas który jest opisany zależnością Tn+1 = Tn + ΔT, dla całkowitych n z przedziału od 0 do f-1.
QA (procent) - dostępność usługi QoS w czasie należącym do przedziału <T0 ; Tf>.
QAn (Boolean) - chwilowa dostępność usługi QoS w czasie należącym do przedziału
<Tn ; Tn + ΔT>. QAn = 1 jeżeli usługa QoS jest dostępna i 0 w przeciwnym wypadku.
Dn (time) - średnie jednokierunkowe opóźnienie w czasie należącym do przedziału
<Tn ; Tn + ΔT>.
Ln (procent) - stosunek jednokierunkowej straty w czasie należącym do przedziału
<Tn; Tn + ΔT>.
TPn - przepustowość w czasie należącym do przedziału <Tn; Tn + ΔT>.
Cd - maksymalna wartość progowa dla Dn, ∀n
Cl - maksymalna wartość progowa dla Ln, ∀n
Ct - minimalna wartość progowa dla TPn, ∀n
<T0 ; Tf >, ΔT, Cd, Cl i Ct muszą być zakontraktowane w umowie SLA pomiędzy Klientem i Dostawcą.
Wówczas, QAn jest definiowane jako:
∀n, jeżeli wyrażenie ((Dn≤Cd)∩(Ln≤Cl)∩(TPn≥Ct)) jest prawdą to QAn = 1, w przeciwnym razie QAn = 0
Następnie QA, Dostępność Usługi QoS dla usługi QoS jest definiowana jako:
. (5.6.)
Zaletą Metryki Dostępności Usługi QoS jest jej nieskomplikowana interpretacja, co ma istotne znaczenie we współpracy Klienta z Dostawcą, który może regularnie przeprowadzać testy „solidności” oferowanych przez niego usług w kontekście QoS. Dodatkowo Dostawca może zagwarantować określony procent dostępności usługi QoS zakontraktowanej w SLA.
Dostępność SLA (SLA availability)
Opierająca się na definicji Dostępności Usługi QoS, dostępność SLA można zdefiniować jako procentową metrykę opisującą procent czasu (średnia), w którym warunki umowy SLA są utrzymane przez Sprzedawcę. Dla przykładu, Nabywca i Sprzedawca uzgadniają w SLA graniczne wartości dla przepustowości SLA i współczynnika strat SLA:
Maksymalny współczynnik strat SLA = 0,01%.
Minimalna przepustowość SLA = 2 Mbps.
SLA może zawierać specyfikacje dotyczącą niedotrzymania umowy SLA, to znaczy, jeżeli w jakimś punkcie czasu mierzone wartości dla jednej z metryk SLA znajdują się poza zakontraktowanym przedziałem, wtedy SLA jest uważana jako naruszona w tym punkcie czasu. Natomiast dostępność SLA jest obliczana jako całkowity czas, w którym SLA nie została naruszona w okresie czasu objętym przez daną umowę SLA.
5.4.4. Pośrednie Metryki Osiągów Usługi End-to-End
Ten podrozdział pracy opisuje sposób wyliczenia metryk QoS end-to-end dla usługi połączeniowej sieci IP, używając informacji pomiarowych pochodzących z pojedynczych domen IPND i łączy pomiędzy nimi, które to razem są odpowiedzialne za utrzymanie usługi end-to-end.
Usługa połączeniowa sieci IP może rozciągać się na kilka połączonych ze sobą domen IPND. Usługa zazwyczaj zawiera dwa (lub więcej) punkty brzegowe (termination points), przez które ruch wchodzi i wychodzi z sieci. Sieć zazwyczaj składa się z części dostępowej (jedna lub więcej domen IPND), części rdzeniowej (jedna lub więcej domen IPND) i połączeń pomiędzy domenami IPND. Rysunek 5.17. przedstawia wspomniane obszary sieci, a także utrzymywaną przez nie usługę end-to-end.
Rysunek 5.18. Sporządzanie metryk osiągów usługi end-to-end [40]
Rezultaty pomiarów mogą być agregowane (sumowanie) w celu ustalenia wartości metryki osiągów usługi end-to-end. Zagregowane wartości pomiarowe sygnalizują jakość usług doświadczaną przez Klienta Usługi. Te wartości powinny być opisane w SLS. Ponadto, Dostawca Usługi potrzebuje tych wartości do oceny QoS oferowanej przez niego usługi oraz wykrycia związanych z tym problemów.
Obliczenia różnych metryk osiągów usługi end-to-end bazujących na metrykach otrzymanych z pojedynczych domen IPND i między-domenowych połączeń, mogą być przedstawione w następujący sposób:
Jednokierunkowe opóźnienie end-to-end (End-to-end one-way-delay): Należy obliczać jednokierunkowe opóźnienie pakietów transmitowanych pomiędzy punktami końcowymi usługi (Service Termination Points) (STP-A i STP-Z na rysunku 5.16.). Pakiety wchodzą do sieci w punkcie STP-A i wychodzą w STP-Z. Jednokierunkowym opóźnieniem end-to-end będzie wtedy suma jednokierunkowych opóźnień wprowadzonych przez pojedyncze domeny IPND i łącza między nimi [RFC 2680] [46]. Indywidualne pomiary przeprowadzone na pojedynczych domenach i łączach powinny być wykonane w tym samym czasie i przy użyciu tego samego typu pakietów.
Dwukierunkowe opóźnienie end-to-end (End-to-end round-trip-delay): Należy obliczać dwukierunkowe opóźnienie end-to-end pomiędzy punktami STP-A i STP-Z. Ten pomiar opóźnienia dotyczy pakietów wysłanych i odebranych przez ten sam punkt STP, np. STP-A. Pakiety wchodzą do sieci w punkcie STP-A, docierają do punktu STP-Z, a następnie wracają do STP-A. Dwukierunkowe opóźnienie end-to-end może być obliczone przez zsumowanie dwukierunkowych opóźnień wprowadzonych przez pojedyncze domeny IPND i łącza między nimi. Indywidualne pomiary przeprowadzone na pojedynczych domenach i łączach powinny być wykonane w tym samym czasie i przy użyciu tego samego typu pakietów.
Chwilowa zmienność opóźnienia pakietu (End-to-end instantaneous-packet-delay-variation (IPDV)): Powinna być mierzona jako różnica pomiędzy jednokierunkowym opóźnieniem end-to-end dla dwóch pakietów transmitowanych z jednego punktu STP do drugiego, np. z STP-A do STP-Z. Wyliczenie jednokierunkowego opóźnienia end-to-end zostało opisane powyżej. IPDV odnosi się tylko do pojedynczej pary pakietów (do jakichkolwiek dwóch wybranych pakietów lub do pary pakietów w strumieniu). Dlatego statystyki IPDV (takie jak max IPDV, średnia IPDV, itd.) są bardziej praktyczne niż jej pojedyncza wartość.
Prawdopodobieństwo straty pakietu end-to-end (End-to-end packet loss probability): Powinno wskazywać prawdopodobieństwo straty pakietów transmitowanych z jednego punktu STP do drugiego, np. z STP-A do STP-Z. Załóżmy, że n jest całkowitą liczbą domen IPND i między-domenowych łączy pomiędzy punktami STP-A i STP-Z. Prawdopodobieństwo straty pakietu dla indywidualnej domeny IPND i łączy pomiędzy mini może być reprezentowane przez PL1, PL2,..., PLn. Natomiast prawdopodobieństwo nie-straty pakietu dla każdej z tych domen IPND i łączy wynosi (1-PL1), (1-PL2),... i (1-PLn). Prawdopodobieństwo nie-straty pakietu end-to-end pomiędzy dwoma punktami STP jest opisana przez:
(1-PL1) · (1-PL2) · ... · (1-PLn); (5.7.)
dlatego prawdopodobieństwo straty pakietu end-to-end wynosi:
1-((1-PL1) · (1-PL2) · ... · (1-PLn)). (5.8.)
Indywidualne pomiary przeprowadzone na pojedynczych domenach i łączach powinny być wykonane w tym samym czasie i przy użyciu tego samego typu pakietów.
Przepustowość end-to-end (End-to-end throughput): Powinna określać przepustowość end-to-end pomiędzy dwoma punktami STP, np. STP-A i STP-Z. Pewnym przybliżeniem przepustowości end-to-end może być minimalna wartość przepustowości wprowadzona przez jedną z domen IPND i łączy między nimi, to jest:
Min(T1, T2, ...,Tn); (5.9.)
gdzie T1, T2, ...,Tn są kolejnymi wartościami przepustowości.
5.4.5. Metryki Osiągów wewnątrz domeny IP
Ten podrozdział pracy opisuje metryki zorientowane na osiągi, które mogą być mierzone wewnątrz domeny IP. Metryki te mogą być używane w celu zewnętrznego zarządzania (internal management) lub użyte do sprawdzenia czy domena przenosząca ruch miedzy domenami utrzymuje usługę transportową na odpowiednim poziomie.
Metryki węzłów i przestrzeni kontrolnej (Node Level & Control Plane Metrics)
Metryki rezerwacji zasobów: Dynamiczna rezerwacja zasobów przez sygnalizację nie jest jeszcze szeroko stosowana w sieciach IP. Jednakże, kiedy te mechanizmy staną się bardziej powszechne przedstawione metryki mogą być przydatne:
liczba rezerwacji (np. rezerwacja RSVP) zakończonych sukcesem odniesiona do podmiotu inicjującego rezerwację (np. użytkownik/aplikacja/adres źródłowy/itd.);
liczba rezerwacji odrzuconych, odniesiona do podmiotu inicjującego rezerwację (np. nieuprawniony inicjator rezerwacji, wyczerpanie budżetu inicjatora);
zasoby przydzielone dla podmiotu inicjującego rezerwację jako procent odniesiony do całości dostępnych zasobów.
Metryki węzłów i przestrzeni użytkownika (Node Level & User Plane Metrics)
Metryki osiągów rutera: Ta metryka otrzymywana z rutera może być przydatna do sprawdzania jego stanu i intensywności ruchu (traffic load). Metryki te dotyczą:
statystyk takich jak obciążenie CPU i pamięci (średnie lub maksymalne) podczas okresu monitorowania;
liczba przniesionych pakietów (i oktetów);
statystyki opisujące interfejsy:
dostępność (to znaczy, okres lub procent czasu, w którym interfejs jest gotowy do użycia i oferuje minimalny poziom jakości dla usługi),
rozmiar kolejki: bieżąca, średnia i maksymalna długość kolejki w okresie monitorowania,
liczba odrzuconych pakietów w wyniku przepełnienia buforów.
Metryki klasyfikacji i stanu ruchu: Odnoszą się do metryk związanych z klasyfikacją i stanem (np. policing, kształtowanie ruchu, oznaczanie pakietów) dla każdego z interfejsów ruterów brzegowych dla ruchu wchodzącego i wychodzącego. Metryki te są bardziej użyteczne, jeżeli są sporządzane dla każdej z klas danej usługi (sprawdzając zawartość ToS w IPv4) lub ruchu zagregowanego (bazującego na polu kodowym DSCP). Metryki te dotyczą:
liczby (lub procent) pakietów i oktetów (dla klasy usługi, lub zagregowanego ruchu) ze zmienionym priorytetem lub odrzuconym w wyniku akcji policingu;
liczby (lub procent) pakietów i oktetów (dla klasy usługi, lub zagregowanego ruchu) opóźnionych w wyniku akcji formowania ruchu.
Metryki sieciowe i obszaru zarządzania (Network Level & Management Plane Metrics)
Metryki poziomu aplikacja/usługa: Metryki te mogą być użyte do monitorowania osiągów pewnych aplikacji/usług, które używają IP jako warstwy transportowej:
czas (średni, maksymalny), w którym użytkownik połączy się z usługą;
czas (średni, maksymalny), w którym użytkownik otrzymuje odpowiedz pochodzącą od usługi.
Przykłady powyższych metryk to:
dwukierunkowy czas przejścia (round-trip-time) użyty do sprawdzenia nazwy domenowej DNS;
dwukierunkowy czas przejścia (round-trip-time) użyty do nawiązania połączenia TCP między maszyną klienta a serwerem;
dwukierunkowy czas przejścia (round-trip-time) użyty do wysłania prośby (request) i otrzymania potwierdzenia (response) z serwera HTTP.
Metryki sieciowe i obszaru użytkownika (Network Level & User Plane Metrics)
Metryki ruchu węzeł-węzeł (Node-to-node traffic metrics): Są one zorientowane na pomiary wykonywane pomiędzy dwoma punktami w sieci. Zawierają one:
procent średniego i maksymalnego obciążenia łącza (w obu kierunkach) węzeł-węzeł (node-to-node), w odniesieniu do całkowitej wydajności łącza;
szczegółowe statystyki ruchu takie jak przepustowość i czas trwania (duration) dla każdej z klas CoS lub zagregowanego ruchu.
Metryki QoS węzeł-węzeł (Node-to-node QoS metrics): Jeżeli wspomniane metryki są wykonane pomiędzy ruterami brzegowymi domeny sieci tranzytowej, mogą być wykorzystane do sprawdzenia czy domena dotrzymuje zobowiązań zawartych SLA. Te metryki są szczególnie przydatne w celu utrzymania usług IP takich jak VoIP lub innych usług wymagających odpowiednich parametrów QoS.
Opóźnienie (Delay): czas, w którym pakiet przechodzi od rutera do rutera.
Strata (Loss): Liczba pakietów (lub procent z całkowitej liczby pakietów) straconych podczas transmisji z rutera do rutera.
Przepustowość (Throughput): Ilość (amount) poprawnie przetransmitowanego ruchu między ruterami.
Zmienność opóźnienia (Jitter): Różnica między opóźnieniami sąsiadujących pakietów, przesyłanych miedzy ruterami
Dostępność (Availability): Metryka ta dotyczy pomiaru czasu, podczas którego ścieżka pomiędzy dwoma punktami w sieci jest dostępna dla transmisji ruchu z wymaganym poziomem QoS (przepustowość, opóźnienie, straty i zmienność opóźnienia). Metryka ta może być wyrażona jako procent czasu, w którym ścieżka była dostępna.
Metryki niższej warstwy (Lower layer metrics): Kiedy ruch IP jest przenoszony przez techniki transportowe niższych warstw, takie jak ATM, istotne metryki dla tych warstw (np. strata komórek ATM (ATM cell loss), opóźnienie i zmienność opóźnienia) mogą być użyteczne w celu wykonania statystyk osiągów warstwy IP lub wykrycia problemów związanych z tą warstwą.
5.5. Metodologia pomiarowa [40]
Po opisie, kto przeprowadza pomiary i jakie metryki powinny być sporządzane, ten rozdział prezentuje sposób przeprowadzania pomiarów.
5.5.1. Klasyfikacja technik pomiarowych
Z wielu aspektów, które mogą być rozważane do klasyfikacji sposobów pomiarowych, ten podrozdział omawia projekt systemu pomiarowego, częstotliwość zbierania próbek i przezroczystość procesu pomiarowego.
5.5.1.1. System pomiarowy
System pomiarowy może być zarówno systemem skupionym (standalone) jak i rozproszonym (distributed). System skupiony zawiera scentralizowane urządzenie pomiarowe połączone z jednym lub wieloma punktami pomiarowymi. Zaletą tego systemu jest to, że dla transmisji danych pomiarowych synchronizacja czasowa nie jest wymagana, ale osiągi systemu są ograniczone wydajnością pojedynczego urządzenia pomiarowego, a także może wystąpić problem zasięgu związany ze zbieraniem danych pomiarowych z odległych punktów. System rozproszony zawiera kilka urządzeń pomiarowych, które mogą wykonywać podobne lub różne zadania (np. zbieranie i przesyłanie danych pomiarowych, obróbka i przechowywanie danych). Osiągi i dokładność danego systemu pomiarowego są kwestią najważniejszą, ale synchronizacja i komunikacja pomiędzy zdalnymi jednostkami również może przysporzyć wiele trudności.
Jeżeli rozproszony system pomiarowy posiada urządzenia zbierające (capture devices) i urządzenia centralne (central devices), które analizują zebrane dane, oraz jednostkę post-procesingu lub składowania danych pomiarowych, występują różne sposoby komunikacji pomiędzy tymi urządzeniami. Urządzenia centralne mogą pracować jako nadrzędne (master), które co jakiś czas sprawdzają urządzenia zbierające, które pracują jako podrzędne (slave). Tryb zbierania master/slave umożliwia dynamiczną kontrolę wartości danych pomiarowych. Urządzenia podrzędne (slave) mogą pozbywać się starych danych pomiarowych, które nie są zebrane przez urządzenia nadrzędne (master). Jednakże ten tryb nie jest odpowiedni do monitorowania zdarzeń asynchronicznych takich jak błędy czy przekroczenia ustalonej wartości granicznej. Tryb pushing jest bardziej właściwy do monitorowania błędów, ponieważ urządzenia zbierające transmitują swoje dane pomiarowe automatycznie, kiedy jest spełniony odpowiedni warunek (np. bufor pomiarowy jest pełny lub wystąpi błąd). Rozproszone systemy pomiarowe wymagają synchronizacji czasowej. Możliwe są dowolne kombinacje połączeń między tymi systemami.
5.5.1.2. Częstotliwość pomiarowa
Częstotliwość zbierania próbek zależy od wielu czynników takich jak dokładność, cel przeprowadzanych pomiarów, wydajność systemu pomiarowego. Większa liczba próbek daje wyższą dokładność, ale powinna być ona dobierana w zależności rozpatrywanego przypadku. Jeżeli celem pomiarów jest podjęcie natychmiastowej akcji związanej z detekcją błędów, w czasie rzeczywistym, bez składowania próbek, wymagana częstotliwość pomiarowa nie musi być wysoka. Z drugiej jednak strony zbieranie próbek off-line wykorzystywane jest w większości przypadków pomiarów ruchu. Rdzeniowe łącza sieciowe zazwyczaj wymagają wyższej częstotliwości pobierania próbek pomiarowych niż wąsko pasmowe łącza dostępowe. Wyznaczanie długo-terminowych statystyk nie wymaga znacznych częstotliwości pomiarowych, np. dobowe pomiary obciążenia łącza. Pojemność składowania lub częstotliwość zegara CPU urządzeń zbierających lub pasmo zajmowane przez pakiety danych pomiarowych transmitowanych pomiędzy komponentami systemu także wpływa na wartość częstotliwości pomiarowej.
5.5.1.3. Przezroczystość (Transparency)
Pomiary mogą być przeprowadzone przezroczyście, bez ingerencji w usługę ruchu lub węzły sieci pośredniczące w transmisji a także bez generowania dodatkowego ruchu w sieci. Pomiary tego typu popularnie nazywa się pomiarami biernymi (passive measurement), które mogą monitorować całą lub dużą część ruchu przechodzącego przez dany punkt np. wyjściowy port rutera wewnątrz sieci. Urządzenia sieciowe dostarczają statystyk do biernego monitorowania (zazwyczaj przechowywane w Management Information Bases) lub może być użyte także przechwytywanie ruchu (np. splitery optyczne, huby Ethernetowe, tcpdump). Przeprowadzanie biernych pomiarów nie wymaga generowania dodatkowego ruchu. Bierne pomiary mogą dostarczyć informacji o stanie węzłów przenoszących ruch w sieci w różnych okresach lub punktach czasu.
Podstawową wadą tych narzędzi jest to, że są one tylko w stanie przeprowadzać pomiary wewnątrz pojedynczo zarządzanej domeny. Operatorzy sieci nie powinni zezwalać zewnętrznym Dostawcom Usług (Service Provider) na przechowywanie danych w ich bazach MIB (Management Information Bases). W tym wypadku Dostawca Usług musi polegać na pomiarach przeprowadzonych przez domeny IPND. Jeżeli usługa jest utrzymywana przez sieć złożoną z kilku domen, pomiary otrzymywane z indywidualnych domen powinny być ze sobą powiązane w odniesieniu do usługi end-to-end. Jakkolwiek niektóre metryki takie jak zmienność opóźnienia nie mogą być powiązane w przypadku, kiedy dostawca usługi użyje metod alternatywnych (np. pomiary aktywne). Metryki opóźnienia end-to-end i strat są proste do wyznaczenia, więc mogą być traktowane jako dodatkowe. Przepustowość end-to-end jest także łatwa do wyznaczenia, ponieważ jest powiązana z najniższą przepustowością oferowaną przez domeny IPND.
Pomiary aktywne (active measurements) wykonywane są dzięki wprowadzeniu do sieci pakietów testowych w pewnym miejscu sieci, a następnie zarejestrowanie i usunięcie pakietu z sieci w innym punkcie. Przykładem tego typu pomiarów może być pomiar dwukierunkowego opóźnienia pakietu IP o danym rozmiarze i trasie transmisji w danym czasie. Pomiary aktywne wykorzystuje się do oszacowania opóźnienia, zmienności opóźnienia, dostępności usługi i czasu reakcji (response time) dla sieci lub użytkownika usługi. Jednakże wymagane jest, aby badany ruch pochodził z tej samej ścieżki w sieci, która przenosi monitorowaną usługę sieciową, po to, aby pomiary reprezentowały odpowiedni poziom QoS doświadczany przez Nabywcę (Buyer). Korzyść wynikająca ze stosowania pomiarów aktywnych przez Dostawcę Usług (Service Provider) polega na tym, że jakość przeprowadzonych pomiarów nie zależy od właściwości systemów monitorujących domen IPND. Pomiary mogą być przeprowadzone zewnętrznie przez Dostawcę Usług (Service Provider) dla pakietów przechodzących przez różne domeny. Podstawową wadą tego typu pomiarów jest potrzeba stosowania aplikacji uruchamianych w punkcie źródłowym i docelowym. Zakres przeprowadzonych pomiarów end-to-end przez Dostawcę Usług (Service Provider) jest ograniczony przez punkty PoP (Point of Presence) Dostawcy Usług.
5.5.2. Proces pomiarowy
Procedura pomiarowa składa się z kilku etapów:
inicjalizacja,
zbieranie (capturing) danych pomiarowych,
zapis (recording) danych pomiarowych,
przechowywanie (collection) i transmisja danych pomiarowych,
post-procesing danych pomiarowych,
przygotowanie (preparing) informacji wyjściowych.
Przeznaczenie tych etapów zależy od systemów pomiarowych. Poza tym niektóre z tych etapów są opcjonalne i mogą być pominięte.
Inicjalizacja
Wartości różnych parametrów systemu muszą być ustawione przed przeprowadzeniem pomiarów. Proces inicjalizacji może zawierać różne akcje, takie jak:
ustawienie zegara odniesienia,
wyzerowanie (reset) liczników, zegarów w narzędziach pomiarowych,
rozpoczęcie generowania ruchu testowego obciążającego sieć (tylko w przypadku testów laboratoryjnych),
rozpoczęcie generowania dodatkowego ruchu pomiarowego (w przypadku pomiarów aktywnych).
Zbieranie danych pomiarowych
Podczas procesu pomiarowego, urządzenia pomiarowe mierzą określone właściwości badanego ruchu lub usługi. Dane pomiarowe mogą być bezpośrednio metrykami lub pewnego rodzaju informacjami wstępnymi, które mogą być użyte do obliczenia metryki docelowej. Urządzenia zbierające (capture device) mogą zapisywać zebrane dane pomiarowe w plikach „log file” lub w pamięci a następnie transmitować je do innych części systemu pomiarowego.
Zapis
W większości przypadków nie jest możliwe przetworzenie danych pomiarowych w czasie rzeczywistym, dlatego też dane muszą być zapisywane. Kolejnym powodem stosowania zapisu danych pomiarowych jest możliwość późniejszego sprawdzenia wyników pomiarów. Zapis może odbywać się w urządzeniach zbierających lub w innych częściach systemu pomiarowego (np. po post-procesingu). Formą zapisu danych może być prosty zapis w plikach „log file” jak i złożone struktury obiektowe. Ważnym aspektem jest także zapis ważnych informacji (takich jak, czas i miejsce zbierania danych, typy pakietów oraz identyfikacja usługi (service ID)) dotyczących danych pomiarowych.
Przechowywanie i transmisja
Dane pomiarowe muszą być transmitowane pomiędzy jednostkami należącymi do systemu. Wybór sposobu przechowywania danych został przedstawiony powyżej.
Post-Procesing
W większości przypadków, wartości reprezentowane przez dane pomiarowe nie są stosowane jako końcowe rezultaty pomiarów, dlatego też dane muszą być odpowiednio przetworzone. Typowymi etapami post-procesingu są:
obliczanie metryk drugorzędnych,
obliczenie statystyk, takich jak, średnia, maksimum, minimum itp.,
odfiltrowanie nie użytecznych informacji w celu redukcji ilości danych,
sporządzanie statystyk według określonego modelu (np. regresja liniowa),
analiza trendu (trend analysis).
Przygotowanie informacji wyjściowych
Wyjściowymi danymi pomiarowymi mogą być zarówno dokładne wartości metryk, różnego rodzaju statystyki jak i abstrakcyjne decyzje. W zależności od typu wymaganych danych wyjściowych, post-procesing danych pomiarowych powinien odpowiednio formatować dane. Pojedyncze wartości metryk mogą być przenoszone w odpowiednim obiekcie wiadomości sygnalizacyjnej. Status procesu decyzyjnego zależy od wyniku prostego porównania, w którym porównuje się serię danych pomiarowych z ustalonym progiem.
5.5.3. Praktyczne rozwiązania dotyczące przechowywania danych
Ten podrozdział przedstawia kilka praktycznych aspektów, które muszą być wzięte pod uwagę podczas przechowywania i interpretowania danych pomiarowych.
5.5.3.1. Wpływ re-rutingu i zmian obciążenia ruchu
Napotykane problemy
Indywidualne pakiety należące do pojedynczego przepływu przenoszone przez domeny IPND mogą przechodzić przez różne rutery należące do tejże domeny, o ile droga połączeń jest ustalana przy użyciu technologii takich jak MPLS. Powodem zmiany drogi, przez którą przechodzą pakiety może być unikanie zawodnych ruterów lub łączy, w celu optymalnego rozłożenia obciążenia w sieci. Ponieważ droga przejścia pakietów przez sieć może ulec zmianie, pomiary niektórych metryk takich jak, opóźnienie jednokierunkowe, opóźnienie dwukierunkowe i IPDV mogą zwracać różne wyniki, ponieważ badane pakiety transmitowane są różną drogą przez domenę IPND. Nawet, jeżeli pakiety poprawnie przejdą tą samą drogą, zmiany w obciążeniu ruchu mogą być powodem zmian czasu przetwarzania w ruterach przenoszących ruch, a w rezultacie zmian wartości metryk end-to-end.
Rozwiązania
Podczas wielokrotnego sporządzania każdej z metryk należy wziąć pod uwagę ustaloną drogę i zmiany ruchu w domenie IPND. Wyniki powinny być średnią z otrzymanej średniej wartości reprezentującej daną metrykę. Ponadto należy ustalić czy zmiany wartości mierzonych metryk są spowodowane problemem związanym z wyborem ruterów i ścieżek, i jeśli to możliwe dokonać zapisu identyfikacji rutera pośredniczącego w transmisji dla każdego pakietu testowego. Analiza tych informacji może ułatwić rozpoznanie przyczyny zmian wartości mierzonych metryk.
5.5.3.2. Synchronizacja czasowa
Napotykane problemy
Pomiary metryk takich jak jednokierunkowe opóźnienie i IPDV wymagają zapisu czasu nadania i przybycia pakietów w punkcie źródłowym i docelowym. Oznacza to, że zegary użyte w punkcie źródłowym i docelowym powinny być zsynchronizowane (przy użyciu zegara odniesienia). Dokładność zegara lokalnego i odniesienia musi być jeden lub dwa rzędy wyższa od typowych wartości opóźnień mogących wystąpić podczas nadawania pakietów.
W przypadku obliczania jednokierunkowego opóźnienia end-to-end i IPDV użyte do tego celu pomiary pochodzą z indywidualnych domen IPND i łączy miedzy nimi, oznacza to, że zegary w punktach źródłowych i docelowych jak również zegary odniesienia dla wszystkich domen powinny być zsynchronizowane. Podobnie w przypadku obliczeń dwukierunkowego opóźnienia end-to-end wskazania zegarów użytych podczas pomiarów powinny być identyczne.
Rozwiązania
Jednym z przykładów zegara odniesienia użytego do synchronizacji pomiarów jest zegar w systemie GPS (Global Positioning System) o rozdzielczości 10 µs.
Obok lub zamiast zegara odniesienia z systemu GPS można wykorzystać protokół zwany NTP (Network Time Protocol) [RFC 1305] [47], który może być użyty do ustawiania i synchronizacji zegarów w węzłach mierzonej sieci. Protokół NTP może być użyty do synchronizacji czasowej między serwerami i klientami, przy czym dokładność synchronizacji zapewniona dzięki temu protokołowi jest wystarczająca, biorąc pod uwagę charakterystyczne wartości opóźnień, jaki i zmienności opóźnień w sieci. Mechanizmy tego protokołu zapewniają, jeśli to konieczne dokładności na poziomie nanosekund. Protokół ten jest wykorzystywany także do synchronizacji czasowej (drogą radiową lub przewodową) serwerów autonomicznych podsieci połączonych ze sobą (hierarchia master/slave), a wykorzystujących narodowe standardy ustawienia czasu. Serwery także mogą rozprowadzać czas odniesienia wykorzystując lokalny ruting i demony czasowe.
Stworzono także uproszczoną wersję NTP nazwaną SNTP (Simple Network Time Protocol) [RFC 2030] [48]. Stosowanie uproszczonej wersji NTP do synchronizacji zegarów komputerów w Internecie jest uzasadnione wtedy, gdy nie jest potrzebna pełna implementacja NTP. SNTP powinno być stosowane tylko do synchronizacji skrajnych podsieci. Klienci SNTP powinni pracować tylko w skrajnych gałęziach podsieci i w konfiguracjach gdzie klienci NTP lub SNTP nie zależą synchronizacji pochodzącej od kolejnych klientów SNTP. Serwery SNTP powinny pracować tylko w rdzeniu podsieci i tylko w konfiguracjach gdzie nie występują inne źródła synchronizacji.
Tabela 5.5. Dokładności zegarów/czasów oferowanych przez GPS, NTP i SNTP [40]
Protokół zegar/czas |
Dokładność |
Zegar GPS |
Do 10 µs |
NTP |
Precyzja rzędu milisekund |
SNTP |
Precyzja rzędu milisekund |
5.5.3.3. Częstotliwość pomiarów
Napotykane problemy
Częstotliwość pomiarów różnych metryk powinna być starannie dobrana biorąc pod uwagę kilka czynników. Czynniki te zawierają wymaganą dokładność, typy metryk, cel pomiarów, miejsce i czas pomiarów, jak również parametry systemu pomiarowego.
Rozwiązania
Dokładność
Długie odstępy czasowe pomiędzy pomiarami mogą być przyczyną niewykrycia chwilowych błędów. Z drugiej strony zbyt duża częstość pomiarów nadmiernie wykorzystuje zasoby sieci, które mogłyby być użyte do przenoszenia ruchu. Ponadto, może być to przyczyną generacji dużej ilości danych, które muszą być analizowane i składowane. Ale częstotliwość pomiarów musi być wystarczająco duża, aby zapewnić wymagania podane w SLA.
Cel
Jeżeli celem pomiarów jest wykrycie poważnych błędów, wymagających natychmiastowej akcji, a nie jest wymagane składowanie próbek, wymagane są pomiary w czasie rzeczywistym z dużą częstotliwością. Z drugiej strony, składowanie próbek off-line stosowane jest w większości scenariuszy pomiarowych ruchu.
Typ metryk
Pomiary niektórych metryk zorientowanych na specyfikacje sieci dotyczące łączy, ruterów, portów ruterów, wymagają wyższych częstotliwości pomiarowych, ponieważ mają decydujący wpływ na utrzymanie sieci na odpowiednim poziomie jakości. Należy wziąć pod uwagę także szybkość łączy rdzeniowych, które wymagają wyższych częstotliwości zbierania próbek danych niż wąsko pasmowe łącza dostępowe.
Skala czasowa pomiarów
Wyznaczanie długoterminowych statystyk nie wymaga znacznych częstotliwości pomiarów. Dla przykładu, dobowe pomiary obciążenia łącza, w celu wyznaczenia obciążenia łącza w ciągu doby i podjęcie ewentualnej decyzji o zmianie pojemności łącza.
Wydajność systemu pomiarowego
Wydajność składowania danych lub wydajności CPU w narzędziach zbierających dane, a także pasmo zajmowane przez transmitowane dane pomiarowe pomiędzy komponentami systemu są czynnikami, które mogą ograniczać częstotliwość pomiarów.
5.5.3.4. Wybór pakietów testowych dla pomiarów aktywnych
Typy pakietów - napotykane problemy
Rodzaj pakietów użytych w aktywnych pomiarach osiągów usługi (takich jak pomiar opóźnienia i strat) może mieć wpływ na rezultat pomiarów. Rodzaj pakietu jest określony przez następujące atrybuty: rozmiar pakietu, protokół (UDP, TCP, ICMP), numer portu, wartość bitów pierwszeństwa (precedence bits) lub bitów DSCP. Wartość któregoś z tych atrybutów może mieć wpływ na drogę przejścia pakietu przez sieć. Należy pamiętać także, że pakiety kontrolne (takie jak sygnalizacja czy wiadomości ICMP), nie są traktowane tak samo jak zwykłe pakiety danych (inny priorytet odrzucenia pakietu). Dla przykładu, pakiety ICMP przesyłane są 20 % szybciej przez rutery Linux'owe niż pakiety UDP. To także powinno być wzięte pod uwagę podczas wyboru pakietów testowych.
Typy pakietów - rozwiązania
Typ pakietów użyty do przeprowadzenia indywidualnych pomiarów domeny IPND i łączy powinny być przedstawione inicjatorowi pomiarów (np. Dostawcy Usług lub Sprzedawcy IPND), który decyduje o tym czy zastosowano te same typy pakietów a co za tym idzie czy pomiary mają sensowną wartość.
Wybór rozmiaru pakietu - napotykane problemy
Rozmiary pakietów IPv4 sięgają od 20 bajtów (tylko nagłówek, bez pola ładunku i opcji) do 65535 bajtów. Rozmiar pakietu ma wpływ na czas przejścia pakietu przez ruter. Dla przykładu tabela 5.6. pokazuje czasy przejścia pakietów o różnych rozmiarach przez różne rutery.
Tabela 5.6. Czasy przejścia pakietów o różnych rozmiarach przez rutery [40]
Rozmiar pakietu (w bajtach) |
Ruter Cisco 7200 (opóźnienie w µs) |
Ruter Linux'owy (opóźnienie w µs) |
50 |
57 |
74 |
100 |
60 |
82 |
500 |
113 |
146 |
1000 |
162 |
226 |
1500 |
224 |
306 |
Czas przejścia pakietu przez poszczególne rutery (i łącza) może mieć wpływ na takie metryki jak jednokierunkowe opóźnienie, dwukierunkowe opóźnienie i IPDV pomiędzy wejściowymi i wyjściowymi punktami indywidualnych domen IPND jak również dla usług end-to-end utrzymywanych dzięki kilku domenom IPND.
Wybór rozmiaru pakietu - rozwiązania
W celu wyboru rozmiaru pakietów pomiarowych można wprowadzić pojęcia małego, średniego i dużego rozmiaru pakietów. Dokładny rozmiar pakietów w każdej kategorii może bazować na typowych rozmiarach pakietów. Na przykład, mały rozmiar pakietów wynoszący 56 bajtów może odpowiadać rozmiarowi pakietów Ping; średni rozmiar pakietów wynoszący 576 bajtów odpowiadający największemu rozmiarowi pakietu przechodzącego przez ruter bez fragmentacji [RFC 1812]. Największy rozmiar pakietu może być równy rozmiarowi jednostki MTU (Maximum Transmission Unit) związanej z warstwą 2 (layer 2). Na przykład, w przypadku interfejsu ethernetowego, MTU wynosi 1500 [50].
Wybór rozmiaru pakietów użytych do pomiaru metryk w każdej z domen IPND i łączy między nimi, powinien zależeć od Dostawcy Usług (Service Provider), który powinien wybrać identyczne lub prawie identyczne rozmiary pakietów testowych dla każdej z domen. Tylko w tym przypadku, zagregowane dane pomiarowe pochodzące z domen IPND i łączy, będą odpowiadać rzeczywistym wartością metryk end-to-end.
5.5.3.5. Progowa strata pakietów (Loss Threshold)
Napotykane problemy
Pakiet jest uważany za stracony, kiedy w całości nie osiągnie punktu docelowego lub kiedy czas dotarcia do punktu docelowego jest poza progowym czasem oczekiwania. Wartość progowa powinna być ustalana biorąc pod uwagę średnią wartość opóźnienia pakietów przechodzących od źródła do celu. Każda z domen IPND może ustalić różne progi graniczne w celu wykrycia czy pakiet jest uznany za stracony, ponieważ zależy to od takich czynników jak fizyczny dystans pomiędzy punktem wejściowym i wyjściowym, szybkości urządzeń rutujących w danej domenie, technologii warstwy 2, średniego obciążenia ruchu itp. Ta rozbieżność może być przyczyną nierównomierności w rozłożeniu rezultatów pochodzących z indywidualnych pomiarów.
Rozwiązania
Obliczając straty end-to-end pakietów przy wykorzystaniu pomiarów z indywidualnych domen IPND i łączy miedzy nimi, progi graniczne i metodologia użyta w każdej z domen i łączach między nimi powinna być identyczna [RFC 2680] [46]. Wartość indywidualnych poziomów granicznych powinna być przedstawiona Dostawcy Usług, który decyduje czy wyznaczenie straty pakietów end-to-end jest poprawne.
5.5.3.6. Agregacja Metryk Osiągów Usługi Tranzytowej
Wartość minimalna i maksymalna - napotykane problemy
Oprócz podawania średnich wartości Metryk Osiągów Usługi end-to-end jest możliwe także podanie wartości minimalnych i maksymalnych. W tym przypadku, maksymalne/minimalne wartości end-to-end nie mogą być obliczone przez proste zsumowanie wartości min/max otrzymanych z indywidualnych domen IPND i łączy między nimi. Czas, w którym wartości min/max zostały wyznaczone indywidualnie powinien być wzięty pod uwagę. Jest tak, dlatego, że wartości min/max nie są wyznaczane w tym samym czasie w domenach i łączach. Jednym z czynników mających na to wpływ jest usytuowanie domen w różnych strefach czasowych.
Poza częstością wykonywania indywidualnych pomiarów w domenach IPND należy wziąć pod uwagę także czas, w którym pomiary zostały wykonane. Na przykład, w domenie IPND-A maksymalną wartość jednokierunkowego opóźnienia wyznaczono o godz. 08:00, w domenie IPND-T o godzinie 09:00 i w IPND-Z o 07:30. Proste zsumowanie maksymalnych opóźnień nie da maksymalnego opóźnienia end-to-end! Ten sam problem występuje w przypadku obliczeń minimalnej wartości metryk end-to-end.
Wartość minimalna i maksymalna - rozwiązania
Minimalne/maksymalne wartości Metryk Osiągów Usługi powinny być otrzymywane z pomiarów wykonanych w tym samym czasie w każdej z domen IPND.
Wartość średnia - napotykane problemy
Jest możliwe, że metryki osiągów usługi w każdej domenie IPND i w łączach między nimi są mierzone z różną częstością. Na przykład, w domenie IPND-A pomiary mogą być przeprowadzane, co 10 minut, w domenie IPND-T, co 20 minut i w IPND-Z co 30 minut. Oznacza to, że średnie wartości metryki osiągów usługi (np. jednokierunkowe opóźnienie) wyznaczone indywidualnie mają różną dokładność. Dlatego zsumowanie tych średnich wartości nie daje precyzyjnej średniej wartości end-to-end.
Wartość średnia - rozwiązania
Jeśli to możliwe pomiary powinny być przeprowadzane z tą samą częstością w każdej domenie i łączach pomiędzy nimi, jak również powinna być użyta ta sama metoda obliczania wartości średniej metryk. Częstotliwość pomiarów i techniki użyte do obliczenia średniej powinny być przedstawione Dostawcy Usług, który decyduje czy zastosowano odpowiednie metody wyznaczania wartości średniej.
5.5.4. Post-Procesing danych pomiarowych
Zbierając pojedynczą próbkę metryki zazwyczaj nie daje to wystarczających informacji, aby wyciągnąć istotne wnioski dotyczące pomiarów. Dlatego też dane pomiarowe dotyczące metryk są przechowywane i ich próbki są statystycznie analizowane. Arytmetyczna lub geometryczna średnia, mediana, maksimum, minimum, wyrażona procentowo lub ilościowo funkcja gęstości prawdopodobieństwa lub wariancja są typowymi statystykami bezpośrednimi (direct statistics), które mogą być bezpośrednio wyliczone z serii próbek danej metryki. Statystyki pośrednie (indirect statistics) mogą być otrzymywane przez estymację. Przedstawione poniżej typowe statystyki mogą być obliczane w sekcji post-procesingu z serii próbek metryk bezpośrednich:
średnia,
mediana,
maksimum, minimum.
Ocena wyników może być dość skomplikowana w odniesieniu do praktycznej sieci. Do uproszczenia analiz można użyć kilku technik np. rozkład (decomposition), aproksymacja. Dla przykładu, uproszczone pojęcia takie jak efektywne pasmo (effective bandwidth (EBW)) i efektywne buforowanie (effective buffer) może być użyte do aproksymacji zachowania węzłów na poziomie pakietów i uproszczenie analiz na poziomie łączy.
5.5.5. Raport pomiarowy
Pomiary powinny być odpowiednio przedstawione w celu odpowiedniej ich interpretacji. Ważne biznesowe i techniczne decyzje są podejmowane na podstawie pomiarów sieci i usług. Dobra prezentacja i właściwy poziom abstrakcji raportu pomiarowego może pomóc w podejmowaniu tychże decyzji.
5.5.5.1. Typy raportów pomiarowych
Raporty pomiarowe można podzielić na następujące dwa typy:
Raporty wewnętrzne (Internal reports)
Są używane przez Dostawcę Usług do monitorowania jego własnych osiągów. Format tych raportów jest definiowany przez Dostawcę Usług i wykorzystywany do wewnętrznych metod i procedur.
Raporty zewnętrzne (External reports)
Są używane przez Dostawcę Usług w celu informowania Klienta Usługi o aktualnych osiągach usługi. Zarówno format jak i okresowość tych raportów powinna być uzgodniona przez obie strony.
Raporty zewnętrzne są używane do sprawdzania przez Klienta Usługi i Dostawcę Usługi zgodności z umową SLA. W kontekście zarządzania SLA, możliwe są dwa typy raportów:
Raporty wykorzystania usługi (Reports of service usage). Te raporty zawierają aktualnie monitorowane ważne pomiary dotyczące danej usługi. Dzięki tym pomiarom Klient Usługi może sprawdzić czy zakontraktowana usługa wykorzystuje za dużo lub za mało zasobów niż jest to konieczne. Dostawca Usługi może ocenić przystosowanie jego zasobów do wymagań usługi.
Raporty zgodności SLA. Jakiekolwiek odchylenie parametrów usługi od wartości zakontraktowanej w SLA jest przedstawione w tych raportach. Są one wynikiem porównania aktualnych pomiarów wykorzystania usługi z wartościami w umowie SLA. Różnice pochodzące z porównania wywołują odpowiednie akcje wyspecyfikowane w SLA z powodu jej naruszenia.
Dostawca Usługi i Klient Usługi powinni ustalić format i okresowość tych raportów (powinno być to ustalone w SLA).
5.5.5.2. Zawartość raportów pomiarowych
Raporty pomiarowe zawierają wartości metryk zorientowanych na Klienta Usługi, usługę lub sieć dla danego okresu czasu. Rodzaj raportowanych metryk zależy od odbiorcy i typu raportów:
Raporty zewnętrzne, zorientowane na Klienta Usługi, zawierają wartości metryk QoS objętych przez SLA dla konkretnego klienta usługi.
Wewnętrzne raporty, zorientowane na usługę i sieć dostawcy usług skupiają się na krótko i długo-terminowych statystykach dla klas i usług zamiast na kliencie usługi.
Raporty mogą być przedstawione jako tabele i wykresy pokazujące zmiany różnych metryk dla raportowanego okresu czasu. Mogą być także wprowadzone dodatkowe wartości takie jak minimum, maksimum lub średnia metryk.
W przypadku raportów zgodności SLA, graficzne przedstawienie aktualnych oraz zakontraktowanych wartości metryk osiągów usługi na jednym wykresie może być bardzo przydatne. Jako przykład podano rysunek 5.19. przedstawiający wykres wartości Metryki Osiągów Usługi (Service Performance Metric) w funkcji czasu trwania SLA.
Rysunek 5.19. Przykład graficznego raportu zgodności SLA [40]
5.5.5.3. Raportowanie On-line
Klient Usługi powinien mieć dostęp on-line do raportów w czasie rzeczywistym dotyczących wykorzystania usługi i jej zgodności z SLA. To jest szczególnie ważne w przypadku naruszenia umowy SLA, kiedy to jest potrzebna natychmiastowa akcja korekcyjna.
Jako udogodnienie raportowania on-line może być zaoferowana klientowi usługi możliwość ustalenia progu granicznego dla kilku parametrów usługi. Kiedy wartość jednego z tych parametrów przekroczy próg graniczny ustalony przez klienta usługi, może być generowany alarm ostrzegający klienta usługi o tym, że może dojść do naruszenia umowy SLA.
5.5.5.4. Alarmy
W przypadku pomiarów aktywnych i pasywnych, znaczne obniżenie wydajności (np. liczba pakietów odrzucona na danym porcie rutera) może być raportowane przez generowanie alarmów. Prostym rozwiązaniem jest zdefiniowanie progów granicznych dla metryk mających znaczący wpływ na kondycje sieci lub usług. Alarmy powinny być generowane w chwili przekroczenia ustalonych progów granicznych. Te alarmy mogą wywoływać procedury i akcje zapobiegające wystąpieniom błędów. Takie zapobiegawcze akcje redukują ryzyko naruszenia umowy SLA.
Decyzja o tym, jakie metryki powinny być monitorowane w celu generowania alarmów oraz jaką wartość powinien mieć próg graniczny dla każdej z nich należy do wewnętrznej polityki każdej z domen IP. Kilka następujących czynników może mieć wpływ na tą decyzję:
Całościowa polityka zarządzania siecią. Na przykład, czy sieć powinna być zarządzana w ten sposób, że zasoby sieciowe są używane blisko granicy maksymalnej wydajności w celu osiągnięcia odpowiednich osiągów, lecz z dużym ryzykiem wystąpienia błędów lub zarządzana z dużym marginesem bezpieczeństwa, lecz z nieefektywnym wykorzystaniem zasobów.
Finansowe i kary umowne nakładane na operatora sieci, jeżeli zakontraktowane w SLA wartości parametrów nie są utrzymane na odpowiednim poziomie.
Wywołanie alarmów
Alarm jest wywoływany, kiedy wartość danego parametru przekroczy ustalona wartość progową. Może się zdarzyć, że monitorowana wartość oscyluje wokół wartości progowej, wywołując dużą liczbę alarmów. Aby uniknąć tego problemu stosuje się mechanizm histerezy.
Istotą mechanizmu histerezy jest użycie dwóch wartości progowych zamiast jednej:
Jeden z progów, próg aktywujący (set threshold), uaktywnia alarm, kiedy przekroczona jest wartość progowa w jednym kierunku (rosnącym). Jeżeli wartość progowa zostanie przekroczona w przeciwnym kierunku (malejącym) nic się nie stanie i alarm jest wciąż aktywny.
Drugi próg, próg dezaktywujący (unset threshold), kasuje alarm, kiedy zostanie przekroczona wartość progowa w przeciwnym kierunku do progu aktywującego.
Doskonałą ilustracją dyskutowanego problemu jest rysunek 5.20., który przedstawia wykres wartości Metryki Osiągów Usługi w funkcji czasu trwania umowy SLA.
Rysunek 5.20. Mechanizm histerezy do wyzwalania alarmów [40]
Na powyższym rysunku, próg aktywujący musi być przekroczony wartością rosnącą, aby alarm został wywołany. A zatem przekroczenie progu dezaktywującego wartością malejącą wyłącza alarm. Jeśli alarm powinien być wywołany, kiedy wartość monitorowanego parametru jest zbyt mała kierunki przekroczenia (aktywujące/dezaktywujące) wartości powinny być zamienione.
Istotne progi przekroczone na powyższym rysunku to:
Wartość przechodząca ponad próg dezaktywujący. To zdarzenie jest zawsze ignorowane bez względu na stan alarmu i kierunku przekroczenia progu.
Wartość przechodzi poniżej progu dezaktywującego. Mimo tego, że kierunek przekroczenia jest poprawny zdarzenie to jest ignorowane.
Wartość przechodzi ponad próg aktywujący. Alarm jest wywoływany w chwili przekroczenia progu wartością rosnącą.
Wartość przechodzi poniżej progu aktywującego. Podobnie jak w przypadku 1 to zdarzenie jest zawsze ignorowane. Alarm pozostaje aktywny.
Wartość po raz kolejny przechodzi ponad próg aktywujący. Jeśli alarm jest wciąż aktywny, nie są wywoływane nowe alarmy.
Wartość przechodzi poniżej progu dezaktywującego. Alarm jest kasowany.
Zazwyczaj w celu aktywacji alarmu jest ustalana pojedyncza wartość progowa. Różnica pomiędzy progiem aktywującym i dezaktywującym może być wyrażona jako procent wartości progowej.
5.6. Prezentacja wyników pomiarowych [40]
Utrzymanie sieci na odpowiednim poziomie sprawności zależy w dużej mierze od pomiarów. Pomiary są niezbędne do określenia jakości usług sieciowych, a także oceny efektywności polityki inżynierii ruchu. Istotnym zadaniem procesu pomiarowego jest analiza całości danych pomiarowych w celu sporządzenia wymaganych raportów pomiarowych. Sposób prezentacji danych pomiarowych należy podzielić na kilka poziomów abstrakcji: z punktu widzenia klienta, usługi i sieci (rysunek 5.21.). Te trzy spojrzenia nawiązują do trzech zależności komercyjnych pomiędzy Klientem (Customer), Dostawcą Usług (Service Provider) i operatorami domen IPND, odnośnie między-domenowych usług IP.
Rysunek 5.21. Prezentacja wyników pomiarowych z punktu widzenia Sieci,Usługi i Klienta [40]
5.6.1. Prezentacja wyników z punktu widzenia Klienta
Typowego Klienta nie interesuje jak dana usługa jest zapewniana (od technicznej strony), ale interesuje go jedynie rezultat jakości usługi end-to-end. Dlatego z punktu widzenia użytkownika, jakość usług jest lepiej wyrażana dzięki parametrom, które:
nie zależą od architektury wewnętrznej sieci,
biorą pod uwagą wszystkie ważne aspekty usługi z punktu widzenia użytkownika,
mogą być zapewnione klientowi przez dostawce usług,
opisane są powszechnymi terminami sieciowymi zrozumiałymi zarówno dla dostawcy usług jak i użytkownika.
Poniżej przedstawiono opis kilku parametrów „przyjaznych użytkownikowi” (user friendly).
Kiedy Klient zawiera kontrakt z Dostawcą Usługi, wymagany lub preferowany poziom QoS powinien być wyspecyfikowany jako część umowy SLA (Service Level Agreement) pomiędzy nimi. Na przykład Internetowy Dostawca Usług (Internet Service Provider (ISP)) oferuje usługę połączeniową do Internetu swoim klientom. Klient może żądać dostępu do sieci ISP poprzez lokalną sieć telefoniczną. W części umowy SLA, Klient może określić liczbę prób połączenia się do sieci (np. 100 prób) w przypadku wystąpienia trudności z dostępem. Klient może także ustalić, która próba połączenia z siecią ISP jest uważana za nieudaną i może to być jakakolwiek próba połączenia trwająca dłużej niż ustalona wartość np. 15 sekund. Internetowy Dostawca Usług powinien dokonać translacji tych wymagań na parametry sieciowe i ustalić wartości parametrów tych elementów sieci, które są odpowiedzialne za zapewnienie wymagań klienta.
Zalecenie ITU-T X.140 [53] wprowadza definicje parametrów QoS zorientowanych na użytkownika dotyczących ustalenia połączenia i transferu danych.
Kilka przykładów parametrów zorientowanych na transfer danych przedstawiono poniżej:
Transfer danych - szybkość: Szybkość, z jaką są transmitowane dane z domeny IPND do klienta i wice wersa.
Transfer danych - dokładność: Stopień podobieństwa wysłanych danych, a następnie odebranych w czasie połączenia. Parametry takie jak opóźnienia pakietów, współczynnik strat pakietów mogą być użyte do opisu dokładności.
Transfer danych - dostępność: Prawdopodobieństwo tego, że połączenie zostanie utrzymane w zaplanowanym czasie.
Transfer danych - bezpieczeństwo: Stopień poufności informacji wysłanych i odebranych przez klienta. Ta informacja nie powinna być dostępna dla „trzeciej strony” podczas procesu transferu informacji. Kodowanie powinno odbywać się w CPE (Customer Premises Equipment).
5.6.2. Prezentacja wyników z punktu widzenia Dostawcy Usług
Z punktu widzenia Dostawcy Usług dane dotyczące osiągów sieci mają zasadnicze znaczenie w ocenie poziomu jakości usługi oferowanej Klientowi z perspektywy biznesowo-komercyjnej. Usługa zarządzania siecią, biling klientów czy planowanie pojemności sieci bazują na tych informacjach. Dostawca Usług musi wiedzieć czy dostarcza swoim klientom usługi optymalnie wykorzystując swoje zasoby, ponieważ nieefektywnie obciążone łącza dostępowe mogą być przyczyną strat. Musi on wiedzieć także czy nowo wprowadzona usługa nie spowoduje zbytniego obniżenia wydajności sieci, co może naruszyć warunki zakontraktowane w SLA. Obniżenie jakości usług oferowanych przez Dostawce Usług może mieć zły wpływ na jego reputacje na rynku. Dlatego też Dostawca Usług powinien mieć dokładny obraz wydajności sieci jak i informacji dotyczących usług dostarczanych Klientowi, ponieważ te informacje pozwolą efektywniej wykorzystać zasoby sieci jak również podnieść satysfakcje klienta.
Usługa QoS oferowana przez Dostawcę Usług powinna byś opisana, terminami zrozumiałymi dla Klienta. Dla przykładu, Dostawca Usług może ustalić dostępność swojej sieci jako prawdopodobieństwo 99,9 % wystąpienia nie dłuższej niż 15 minutowej przerwy w ciągu roku.
Niektóre przykłady parametrów osiągów usługi oferowanej przez Dostawcę usług to:
Awaria usługi może być usunięta w przeciągu „x” godzin w 90 % przypadków.
Dostępność usługi wynosi 99,9 %.
Usługa jest dostępna w „n” krajach.
Metryki osiągów usługi są mapowane na sieciowe i nie sieciowe parametry. Parametry zorientowane sieciowo są mapowane na parametry wydajności sieci. Wymagana wydajność QoS end-to-end wywodzi się z pomiarów tych parametrów i kombinacji parametrów nie zorientowanych sieciowo.
Parametry zorientowane na wydajność sieci
Większość parametrów wydajności sieci dotyczą następujących aspektów:
Dostępność usługi, zawierająca następujące metryki:
system up-time - liczba minut, w których system jest dostępny i osiągalny dla klienta;
połączeniowość sieci (Network Connectivity) - procent czasu, w którym jeden punkt wymiany w sieci jest osiągalny z drugiego punktu wymiany;
przerwa w działaniu sieci (Network Outage) - czas, w którym sieć nie pracuje (np. z powodu awarii sprzętu);
współczynnik błędów (Error rate) - liczba odrzuconych lub uszkodzonych pakietów w przeciągu ustalonego czasu.
Dwukierunkowy czas odpowiedzi lub jednokierunkowe opóźnienie pomiędzy punktami w sieci.
Użycie pasma - procent wejściowych i wyjściowych pakietów transmitowanych w zakontraktowanym paśmie.
Parametry nie zorientowane na wydajność sieci
Parametry nie zorientowane na sieć zazwyczaj dotyczą:
sposobu raportowania problemów,
czasu reakcji i rozwiązania powstałego problemu,
procesu monitoringu i raportowania poziomu usługi oraz jakie statystyki i jak często powinny być zbierane w tym celu,
kar i konsekwencji za błędy związane z dostarczaniem zakontraktowanej usługi,
prawnych klauzur zabezpieczających Dostawce Usług np. w przypadku uszkodzenia sprzętu przez powódź lub pożar.
W celu ilustracji procesu mapowania QoS na parametry sieciowe, przedstawiono poniższy przykład:
wymagania QoS dla VoIP: nie więcej niż ustalony procent (x %) połączeń, w których mogą wystąpić problemy związane z jakością transmitowanego dźwięku,
dwa ważne parametry sieciowe powinny być utrzymane na odpowiednio wysokim poziomie tak, aby zapewnić użytkownikowi odpowiednią jakość głosu, są to: opóźnienie i zmienność opóźnienia dla pakietów VoIP, a także współczynnik strat pakietów.
5.6.3. Prezentacja wyników z punktu widzenia Dostawcy Sieciowego
Dostawca Sieciowy ponosi najwyższą odpowiedzialność za skuteczność i sprawność sieci. Dlatego z punktu widzenia dostawcy sieciowego wydajność sieci jest najlepiej opisana i wyrażona biorąc pod uwagę następujące zagadnienia:
strategia rozwojowa;
regionalne i międzynarodowe planowanie sieci;
obsługa i utrzymanie sieci.
Te parametry mają duże znaczenie zarówno dla Dostawcy Sieciowego jak i Dostawcy Usług, i są używane do celów projektowania systemu, konfiguracji, obsługi i utrzymania. Są definiowane niezależnie od wydajności terminali końcowych klientów.
Ocena wydajności sieci może być przeprowadzona na wiele różnych sposobów. Technikami godnymi uwagi są te zawierające metody analityczne, symulacje, i empiryczne metody bazujące na pomiarach. Kiedy używane są metody analityczne lub symulacje, sieciowe węzły i łącza są tak modelowane aby były w stanie przechwytywać niektóre cechy sieci i ruchu takie jak topologia, pasmo, rozmiar buforów, polityka zarządzania węzłem (priorytetyzacja pakietów, zarządzanie buforami itp.).
5.6.4. Zależności pomiędzy Klientem, Dostawcą Usług i Dostawcą Sieciowym
Rysunek 5.22. pokazuje model prezentujący zależności pomiędzy punktami widzenia klienta, dostawcy usług i dostawcy sieciowego.
Rysunek 5.22. Zależności pomiędzy Klientem, Dostawcą Usług i Dostawcą Sieciowym [40]
Poniższe punkty wyjaśniają przepływ informacji związanych z QoS pomiędzy klientem i dostawcami.
Punktem startowym są zdefiniowane przez użytkownika wymagania QoS, które są mapowane na parametry usług oferowanych przez Dostawcę Usług.
Dostawca Usług ustala Strategię Biznesową, w której wymagania QoS Klienta są analizowane i przydzielane do odpowiedniego poziomu jakościowego, jak również oblicza się koszty i ustala strategie współpracy.
Po analizie i ustaleniu strategii tworzona jest indywidualna umowa SLA. Indywidualna umowa SLA powinna zawierać opis typu zakontraktowanej usługi (np. usługi połączeniowe, usługi internetowe, poczta elektroniczna, dostęp do baz danych, itp.) jak i wymaganego poziomu QoS.
Parametry QoS są dzielone na zorientowane sieciowo i nie zorientowane sieciowo. Parametry zorientowane sieciowo są mapowane na parametry związane z wydajnością sieci. Na rysunku pokazano kilku dostawców sieciowych, ponieważ parametry QoS mogą zależeć od wielu operatorów sieciowych w przypadku między-domenowych usług QoS IP.
Następnie przydzielane są tym parametrom odpowiednie wartości (Network Performance Objectives) w celu utrzymania ustalonej wydajności end-to-end. W niektórych przypadkach istnieje konieczność rozbicia osiągów end-to-end sieci na elementarne części.
Network Performance Objectives są mapowane na parametry osiągów sieci, które są mierzone. Odpowiednio zaprojektowany system monitoringu sieci pozwoli osiągnąć maksymalne korzyści przy małej liczbie pomiarów.
Pomiary wybranych parametrów przez Dostawcę Sieciowego w połączeniu z parametrami QoS nie zorientowanymi na sieć powinny dawać możliwość wyznaczenia aktualnego poziomu QoS oraz sprawdzenia zgodności z SLA.
Klient ocenia postrzegany przez niego poziom QoS.
6. Zakończenie
Nowoczesne sieci teleinformatyczne w coraz większym stopniu dążą do konwergencji, a rozwój części globalnej sieci IP zaczyna ewaluować w kierunku utworzenia niezawodnego medium dla aplikacji związanych z przemysłem, rynkami finansowymi, mediami i nowoczesnymi środkami przekazu. Obecnie pojawiła się również tendencja rozszerzenia możliwości sieci IP o usługi multimedialne, w tym technologie przekazu głosu (VoIP) i obrazu. W celu realizacji tych usług niezbędna wydaje się być ewolucja sieci w kierunku gwarantowanej jakości usług. Całość procesów związanych z wyżej wymienionym zagadnieniem określa się terminem Quality of Service. Quality of Service można określić mianem zbioru technologii, który umożliwia użytkownikom korzystanie z usług sieciowych z przewidywalnym poziomem jakości w kontekście przepustowości (bandwith), opóźnienia (delay) i zmienności opóźnienia (jitter). Mechanizmy QoS można potraktować jako zbiór komponentów umożliwiających różnicowanie i priorytetowanie ruchu w sieci. Poprzez odpowiednią konfigurację możliwa jest m.in. rezerwacja zasobów dla ruchów krytycznych, priorytet dostępu dla uprawnionych użytkowników, zróżnicowany podział dostępnego pasma dla przesyłanych danych w zależności od ich typu.
Wydaje sie, model usług zintegrowanych IntServ oraz model usług zróżnicowanych DiffServ odegrają ogromną rolę w zapewnieniu jakości usług w sieciach IP w relacji od końca do końca. Obecnie proces standaryzacji nie został jednak zakończony. Dzięki stale prowadzonym pracom pojawiają się kolejne modyfikacje i rozszerzenia opracowanych standardów. Jednocześnie są one wprowadzane i testowane w praktyce, co pozwala na lepsze poznanie ich zalet i wad. Opracowane modele i protokoły nadal są niedoskonałe, a ich praktyczne zastosowanie napotyka na szereg trudności.
Na podstawie przeprowadzonej analizy stwierdzono, że model IntServ będzie stosowany w obszarze sieci dostępowej, obsługującej stosunkowo niewielką liczbę użytkowników, a zatem umiarkowaną liczbę pojedynczych strumieni danych wymagających rezerwacji zasobów sieciowych. Z kolei model DiffServ, obsługujący ruch zagregowany, będzie stosowany w sieciach szkieletowych jako element pośredniczący w zapewnieniu jakości usług w relacji od końca do końca
Kolejnym krokiem na drodze rozwoju sieci wielousługowych jest standard wieloprotokołowej komutacji etykietowej MPLS. Wiąże się z nim duże nadzieje, w szczególności w zakresie inżynierii ruchu oraz uproszczenia mechanizmów kierowania pakietów. Technologia MPLS jest rezultatem połączenia korzyści wynikających z technologii przełączania w warstwie 2 (data link layer) z technologią routingu w warstwie 3 (network layer). Technika MPLS we współpracy z modelami architektur sieciowych IntServ i DiffServ stwarza duże możliwości w zakresie zapewnienia jakości usług w sieci Internet. Sama komutacja MPLS zapewnia przede wszystkim uproszczenie sterowania przepływem, przyspieszenie realizacji procesów komutacyjnych w ruterach, a w szczególności pozwala na efektywniejsze gospodarowanie zasobami sieciowymi. Komutacja MPLS umożliwia tworzenie ścieżek z uwzględnieniem aktualnego stanu sieci. Dzięki mechanizmom współpracy z modelami IntServ i DiffServ, w ścieżkach tych można gwarantować jakość usług. Należy jednak zwrócić uwagę, że proces standaryzacji komutacji MPLS nie został jeszcze zakończony. Mimo przygotowania silnych podstaw standardu, brakuje szczegółowych procedur zarządzania i przydziału zasobów do ścieżek. Prowadzone są prace nad rozwojem mechanizmów współpracy MPLS z modelami IntServ i DiffServ, z czego wynika, że rola techniki MPLS będzie nadal rosła.
Funkcje gwarantujące jakość obsługi ze swej natury są skomplikowane, co powoduje trudności w procesie implementacji. Również MPLS mimo prostej zasady działania posiada złożony mechanizm dystrybucji etykiet. Nie jest, więc możliwe stworzenie mechanizmu, który nie zawierałby złożonych procedur realizowanych przez urządzenia sieciowe.
Obecnie toczy się dyskusja na temat celowości wprowadzenia mechanizmów QoS w sieciach IP. Istnieje pogląd, że światłowody i technika multipleksacji z podziałem długości fali (Wavelenght Division Multiplexing) uczyni pasmo tak łatwo dostępnym i tanim, iż QoS będzie zapewniony automatycznie. Z drugiej jednak strony panuje opinia, iż nie jest istotne jak duże pasmo dostarczy sieć, ponieważ nowe aplikacje zdołają je wykorzystać w całości.
W związku z tym mechanizmy zapewnienia QoS będą niezbędne dla zapewnienia odpowiedniej jakości obsługi.
Utrzymanie sieci na odpowiednim poziomie sprawności zależy w dużej mierze od pomiarów, które są niezbędne do określenia jakości usług QoS, a także oceny efektywności polityki inżynierii ruchu. Zarówno Klient jak i Dostawca Usług muszą wykonywać pomiary wybranych metryk QoS, aby móc podpisywać umowy pomiędzy sobą zawierające zobowiązania jakościowe, a także kontrolować się na wzajem.
Istotnym zadaniem procesu pomiarowego jest analiza całości danych pomiarowych w celu sporządzenia wymaganych raportów pomiarowych. Ważne biznesowe i techniczne decyzje są podejmowane na podstawie pomiarów sieci i usług. Dobra prezentacja i właściwy poziom abstrakcji raportu pomiarowego może pomóc w podejmowaniu tychże decyzji. Zaprezentowana przez nas koncepcja systemu pomiaru sieci IP pozwala na monitorowanie i pomiar parametrów QoS, doświadczanych przez użytkowników końcowych. Praca systemu polega na sporządzaniu metryk QoS takich jak: opóźnienie jednokierunkowe, opóźnienie dwukierunkowe, zmienność opóźnienia, strata pakietów, przepustowość. Metryki QoS mierzone są dla ruchu wchodzącego i wychodzącego na krańcach ścieżki end-to-end. Zaproponowana przez nas metoda pomiarowa polega na analizie ruchu generowanego przez użytkowników sieci. Jest to, więc bierna metoda pomiarowa i w odróżnieniu od powszechnie stosowanej aktywnej metody pomiarowej polegającej na generowaniu dodatkowego ruchu testowego nie obciąża zasobów mierzonej sieci.
Kolejnym krokiem na drodze rozwoju przedstawionego systemu pomiaru i utrzymania sieci IP będzie realizacja sprzętowo-programowa. W pracy omówiono szereg problemów mogących powstać podczas praktycznej realizacji systemu pomiarowego.
7. Słownik terminów
AF |
Assured Forwarding |
klasa obsługi DiffServ gwarantująca dostarczenie pakietu |
ARP |
Address Resolution Protocol |
protokół umożliwiający odnalezienie adresu MAC na podstawie adresu IP danego urządzenia sieciowego |
ASIC |
Application-Specific Integrated Circuits |
układy scalone projektowane dla określonego, specyficznego zastosowania |
ATM |
Asynchronous Transfer Mode |
asynchroniczny tryb przesyłania |
BA |
Behaviour Aggregate |
zespół zachowań |
BGP4 |
Border Gatewey Prorocol |
protokół bram granicznych |
BR |
Border Router |
ruter graniczny |
CL |
Controlled Load Service |
usługa kontrolowanego obciążenia |
CoS |
Class of Service |
klasa usługi |
CPE |
Customer Premises Equipment |
ogólny termin określający końcowe urządzenia abonenckie użytkownika sieci |
CR |
Core Router |
ruter rdzeniowy |
DiffServ |
Differentiated Services |
model usług zróżnicowanych opracowany dla sieci IP |
DNS |
Domain Name System |
system nazw domen |
DS |
Differentiated Services field |
jednobajtowe pole wykorzystywane przez DiffServ |
DSCP |
Differentiated Services Code Point |
punkt kodowy (6 bitów) określający przynależność do danej klasy w DiffServ |
E2EIPQoS |
End-to-End Inter-Domain IP QoS |
międzydomenowa jakość usług QoS IP od końca do końca |
EF |
Expedited Forwarding |
klasa obsługi DiffServ dla aplikacji czasu rzeczywistego |
EGP |
Exterior Gateway Protocol |
protokół bram zewnętrznych |
ER |
Egress Router |
ruter wyjściowy-graniczny |
FEC |
Forwarding Equivalence Class |
klasa równoważności etapu przesyłania |
FR |
Frame Relay |
pakietowa sieć transmisyjna z przełączaniem ramek (pakietów) |
FTN |
FEC-to-NHLFE |
mapowanie klasa równoważności FEC na zestaw NHLFE |
FTP |
File Transfer Protocol |
protokół przesyłania plików |
GoS |
Grade of Service |
kategoria usług |
GPS |
Global Positioning System |
Globalny System Pozycjonowania |
GS |
Guaranteed Service |
usługa modelu IntServ dla aplikacji czasu rzeczywistego |
HDSL |
High bit-rate Digital Subscriber Line |
symetryczne łącze abonenckie o wysokiej przepływności realizowane na zwykłej miedzianej skrętce telefonicznej |
HTTP |
Hypertext Transport Protocol |
protokół przesyłania hipertekstu |
ICMP |
Internet Control Message Protocol |
międzysieciowy protokół komunikatów sterujących |
IETF |
Internet Engineering Task Force |
Zespół Zadaniowy Inżynierii Internetowej |
IGMP |
Internet Group Management Protocol |
międzysieciowy protokół zarządzania grupami |
IGP |
Interior Gateway Protocol |
protokół bram wewnętrznych |
ILM |
Incoming Label Map |
funkcja mapująca wartości etykiet MPLS na pozycje NHLFE |
IntServ |
Integrated Services |
model usług zintegrowanych opracowany dla sieci IP |
IP |
Internet Protocol |
protokół internetowy |
IPER |
IP Packet Error Ratio |
stosunek uszkodzonych pakietów IP |
IPLR |
IP packet loss ratio |
stosunek straty pakietów IP |
IPND |
IP Network Domain |
domena sieci IP |
IR |
Ingress Router |
ruter wejściowy-graniczny |
ISP |
Internet Service Provider |
Internetowy Dostawca Usług |
ITU-T |
International Telecommunication Union - Telecommunication Standardisation Sector |
organizacja ustanawiająca europejskie standardy telekomunikacyjne |
LDP |
Label Distribution Protocol |
protokół dystrybucji etykiet dla protokołu MPLS |
LER |
Label Edge Router |
brzegowy ruter przełączania etykiet MPLS |
LoS |
Level of Service |
poziom usług |
LSP |
Label Switched Path |
ścieżka przełączania etykiet MPLS |
LSR |
Label Switch Router |
ruter przełączający etykiety |
MAC |
Media Access Control |
kontrola dostępu do nośnika |
MF |
Multi-Field classifier |
klasyfikator biorący pod uwagę wartości jednego lub wielu pól nagłówka pakietu IP |
MIB |
Management Information Base |
baza informacyjna zarządzania |
MP |
Measurement Point |
punkt pomiarowy |
MPLS |
Multi Protocol Label Switching |
wieloprotokołowa komutacja etykietowa MPLS |
MTU |
Maximum Transmission Unit |
największa jednostka przesyłania |
NHLFE |
Next Hop Label Forwarding Entry |
pozycja w tablicy przesyłania definiowanej przez MPLS |
NTP |
Network Time Protocol |
protokół czasu sieciowego stosowany w sieciach TCP/IP |
OA |
Ordered Aggregate |
uporządkowany zespół zachowań |
OSI |
Open System Interconnect |
współdziałanie systemów otwartych |
OSPF |
Open Shortest Path First |
portokół wybierania najkrutszej ścieżki |
PDH |
Plesiochronous Digital Hierarchy |
hierarchiczny, plezjochroniczny system zwielokrotnienia i transportu sygnałów cyfrowych, oparty na modulacji kodowo-impulsowej PCM |
PHB |
Per Hop Behaviour |
reguły przesyłania pakietów w DiffServ |
POM |
Point of Observation and Measurement |
punkt obserwacji i pomiarów |
PPP |
Point-to-Point Protocol |
protokół połączenia dwupunktowego |
PSC |
PHB Scheduling Class |
planowanie klas PHB |
QoS |
Quality of Service |
jakość obsługi w sieciach telekomunikacyjnych |
RARP |
Reverse Address Resolution Protocol |
protokół odwrotnej zamiany (odwzorowania) adresów |
RFC |
Request For Comment |
prośba o komentarz |
RIP |
Routing Information Protocol |
protokół informacyjny wyboru marszruty |
RSVP |
Resorce Reservation Protocol |
protokół rezerwacyjny warstwy transportowej |
SD |
Service Description |
opis usługi |
SDH |
Synchronous Digital Hierarchy |
synchroniczny system transmisyjny |
SIP |
Session Initiation Protocol |
protokół inicjalizacji sesji |
SLA |
Service Level Agreement |
kontrakt pomiędzy użytkownikiem a operatorem |
SLS |
Service Level Specificafion |
uzgodniony pomiędzy operatorem a klientem zbiór parametrów sieciowych i ich wartości związany ze świadczoną usługą |
SMTP |
Simple Mail Transfer Protocol |
prosty protokół przesyłania poczty |
SNMP |
Simple Network Management Protocol |
prosty protokół zarządzania siecią |
SNTP |
Simple Network Time Protocol |
prosty protokół czasu sieciowego stosowany w sieciach TCP/IP |
STP |
Service Termination Point |
punkty końcowe usługi |
SVC |
Switched Virtual Circuit |
komutowane połączenie wirtualne |
SVP |
Switched Virtual Path |
komutowana ścieżka wirtualna |
TCA |
Traffic Conditioning Agreement |
porozumienie określające reguły klasyfikowania pakietów oraz profile ruchu |
TCP |
Transmission Control Protocol |
protokół sterowania transmisją |
TCS |
Traffic Conditioning Specification |
określony zbiór parametrów technicznych i ich wartości związanych z TCA |
TF |
Traffic Forecast |
prognoza ruchu |
TOS |
Type of Service |
pole w nagłówku pakietu IPv4 określające typ obsługi |
TTL |
Time-To-Live |
czas życia pakietu |
UDP |
User Datagram Protocol |
protokół datagramów użytkownika |
VCI |
Virtual Circuit Identifier |
identyfikator kanału wirtualnego |
VoIP |
Voice over Internet Protocol |
technologia służąca do przesyłania głosu poprzez sieci IP |
VPI |
Virtual Path Identifier |
identyfikator ścieżki wirtualnej |
WAN |
Wide Area Network |
sieć rozległa |
WDM |
Wavelenght Division Multiplexing |
multipleksacja z podziałem długości fali |
8. Literatura
W. Richard Stevens, Biblia TCP/IP tom 1, RM Warszawa 1998.
Andrzej Kasprzak, Rozległe sieci komputerowe z komutacja pakietów, OWPW Wrocław 1997.
Admiralty Way, Transmission Control Protocol, RFC 793, September 1981.
Admiralty Way, Internet Protocol, RFC 791, September 1981.
Hardy W. C.: “QoS” Measurement and Evaluation of Telecomunications Quality of Service, John Willey & Sons Ltd, 2001 England.
Crawley E., Nair R., Rajagopalan B., Sandick H.: A Framework for QoS-based Routing in the Internet, RFC 2386, August 1998.
IP QoS-A Bold New Network, White Paper, Nortel, September 1998.
Colle D., Demeester P., Manzalini A., Jaeger M., Lehr G., Rraptis L., Lason A. et al.: Envisaging Next_Generation Data-Centric Optical Networks, Third International Workshop on Design of Reliable Communication Networks (DRCN2001), 7-10 October 2001, Budapest, Hungary.
LION Project Milestone WP1M3: Preliminary results on optimised network architectures, IST-1999-11387 LION, September 2001.
Newsome G.: Carrier Needs Regarding Survivability and Maintenance for Switched Optical Networks, OIF2000.231, November 15-16, 2000.
Grossman D.: New Terminology for DiffServ, ITEF draft-left-diffserv-new-terms-05.txt, August 2001.
Goderis D. et al.: Service Level Specification Semantic, Parameters and negotiation requirements, IETF Draft, draft-tequila-sls-01.txt, June 2001.
Salsano S. et al.: Definition and usage of SLSs in Aquila consortium, IETF Draft, draft-salsano-aquila-sls-00.txt, November 2000.
Blake S., Black D., Carlson M., Daves E., Wang Z., Weiss W.: An Architecture for Differentiated Services, IETF RFC 2475, December 1998.
Rafał Szarecki, QoS - jakość transmisji w Internecie, Tele Net Forum, Kwiecień 2001.
Braden R., Clark D., Shenker S.: Integrated Services in the Internet Architecture: an Overview, RFC 1633, June 1994.
Shenker S., Partridge C., Guerin R.: Specification of Guaranteed Quality of Service, RFC 2212, September 1997.
Wroclawski J.: Specification of Controlled Load Quality of Service, RFC 2211, September 1997.
Braden R., Zhangh L., Berson S., Herzog S., Jamin S.: Resource reSerVation Protocol (RSVP) - Version 1 Functional Specification, RFC 2205, September 1997.
ATM Forum, Traffic Management Specification Version 4.1, March 1999.
Jajszczyk A.: Dalekosiężne sieci telekomunikacyjne bez ATM i SDH ?, Przegląd Telekomunikacyjny 1/2000.
Gozdecki J., Pacyna P., Papir Z.: Konwergencja sieci Internet i ATM z perspektywy jakości usług, Przegląd Telekomunikacyjny i Wiadomości Telekomunikacyjne 5-6/2001.
Stankiewicz R., Jajszczyk A.: Sposoby zapewnienia gwarantowanej jakości usług w sieci IP, Przegląd Telekomunikacyjny i Wiadomości Telekomunikacyjne 2/2002.
Berger L., Gan D., Swallow G., Pan P., Tommasi F., Molendini S.: RSVP Refresh Overhead Reduction Extensions, RFC 2961, April 2001.
Wroclawski J.: The use of RSVP with IETF Integrated Services, RFC 2210, September 1997.
Nicholas K., Blake S., Baker F., Black D.: Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, December 1998.
Jacobson V., Nicholas K., Poduri K.: An Expedited Forwarding PHB, IETF RFC 2598, June 1999.
Heinanen J., Baker F., Weiss W., Wroclawski J.: Assured Forwarding PHB Group, IETF RFC 2597, June 1999.
Rosen E. C., Viswanathan A., Callon R.: Multiprotocol Label Switching Architecture, ITEF Draft, February 2000.
Nichols K., Jacobson V., Zhang L.: A Two-bit Differentiated Services Architecture for the Internet, RFC 2638, July 1999.
Bernet Y., Ford P.: A Framework for Integrated Services Operation over Diffserv Networks, IETF RFC 2998, November 2000.
Bernet Y.: Format of RSVP DCLASS Object, IETF RFC 2996, November 2000.
Wroclawski J., Charny A.: Integrated Service Mappings for Differentiated Services Networks, IETF Draft, draft-left-issll-ds-map-01.txt, February 2001.
Floryan K., Oniszczuk P., Skobejko J.: Protokół MPLS i zarządzanie ruchem w sieciach IP, Przegląd Telekomunikacyjny i Wiadomości Telekomunikacyjne 7/2001.
Dave B., Lawrence J.: MPLS using LDP and ATM VC Switching, IETF Draft , April 1999
Rosen E., Tappan D., Fedorkow G.: MPLS Label Stack Encoding, RFC 3032, January 2001
Rosen E., Viswanathan A., Callon R.: Multiprotocol Label Switching Architecture, RFC 3031, January 2001
Douglas E. Comer, Sieci komputerowe TCP/IP - Zasady, protokoły i architektóra, WNT Warszawa 1997
EURESCOM P1008 Part 2 of Deliverable 3, Inter-operator interfaces for ensuring end to end IP QoS - Measurement of Performance Metrics and Service Events, May 2001
McCloghrie K.: SNMPv2 Management Information Base for the Internet Protocol using SMIv2, RFC 2011, November 1996.
Mahdavi J., Paxson V.: IPPM Metrics for Measuring Connectivity, RFC 2678, September 1999.
Newman D.: Benchmarking Terminology for Firewall Performance, RFC 2647, August 1999.
Almes G., Kalidindi S., Zekauskas M.: A One-way Delay Metric for IPPM, RFC 2679, September 1999.
Almes G., Kalidindi S., Zekauskas M.: A Round-trip Delay Metric for IPPM, RFC 2681, September 1999.
Almes G., Kalidindi S., Zekauskas M.: A One-way Packet Loss Metric for IPPM, RFC 2680, September 1999.
Mills David L.: Network Time Protocol (Version 3), Specification, Implementation and Analysis, RFC 1305, March 1992.
Mills David L.: Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI, RFC 2030, October 1996.
Baker F.: Requirements for IP Version 4 Routers, RFC 1812, June 1995.
Hornig C.: Standard for the transmission of IP datagrams over Ethernet networks, RFC 894, April 1984.
ITU-T Recommendation I.380, Internet protocol data communication service - IP packet transfer and availability performance parameters, 1999.
Demichelis C., Chimento P.: Instantaneous Packet Delay Variation Metric for IPPM, Internet-Draft, July 2000.
ITU-T Recommendation X.140, General Quality of Service Parameters For Communication Via Public Data Networks, September 1992.
3
Jakość usług w sieciach z protokołem IP
20 bajtów
Region DiffServ
mapowanie DSCP=>PHB
mapowanie DSCP=>PHB
mapowanie DSCP=>PHB
Domena A
Domena B
Domena C
SLA (A, C)
SLA (A, B)
BITY:
SLA (B, C)
0 1 2 3 4 5 6 7
DSCP
NIE UŻYWANE
SELEKTOR KLASY
20 bajtów
segment TCP
warstwa
aplikacji
warstwa
transportowa
warstwa
sieciowa
warstwa
łącza
media
RARP
Interfejs
sprzętowy
ARP
IGMP
IP
ICMP
UDP
TCP
Proces użytkownika
Proces użytkownika
Proces użytkownika
Proces użytkownika
IP, ICMP, IGMP
TCP, UDP
Program obsługi urządzeń i karta interfejsu
Telnet, FTP, e-mail, itd.
Warstwa łącza
Warstwa sieci
Warstwa transportowa
Warstwa aplikacji
6 Flag 1-bitowych
Zarezerwowane
Długość nagłówka
Dane
Suma kontrolna
Znacznik pilności
Rozmiar okna
Port źródłowy
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
Port docelowy
Numer sekwencji
Numer potwierdzenia
Opcje
FIN
SYN
RST
PSH
ACK
URG
dane
Przyjmowanie
zgłoszeń
Planowanie
Wysyłania
pakietów
Klasyfikacja
pakietów
Policy
Control
Proces
RSVP
Proces
rutingu
Planowanie
Wysyłania
pakietów
Przyjmowanie
zgłoszeń
Klasyfikacja
pakietów
Aplikacja
Policy
Control
Proces
RSVP
dla r ≤ p ≤ R
dla p > R ≥ r
Opóźnienie kolejkowania = end-to-end
datagram IP
nagłówek
TCP
dane TCP
nagłówek
IP
Maksymalna pojemność wiadra wynosi b bajtów
Tokeny napełniaja wiadro z szybkością r [B/s]
Pakiety IP
Ruter
Stacja robocza (host)
RSVP
dane
dane
RSVP
Bufor wejściowy
Tx
Odbiorca
Nadawca
Odbiorca 3
Odbiorca 2
Odbiorca 1
Nadawca
0
Maximum Packet Size [M]
Zarezerwowane
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
Długość obiektu
Zarezerwowane
Wersja
Długość pola danych CLS
ID usługi CLS
Długość pola z parametrami TSpec
Flagi parametrów TSpec
ID parametrów TSpec
Token Bucket Rate [r]
Token Bucket Size [b]
Peak Data Rate [p]
Minimum Policed Unit [m]
Slack Term [S]
Rate [R]
Długość pola z parametrami RSpec
Flagi parametrów RSpec
ID parametrów RSpec
0
Maximum Packet Size [M]
Zarezerwowane
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
Długość obiektu
Nieużywane
Wersja
Długość pola danych GS
ID usługi GS
Długość pola z parametrami TSpec
Flagi parametrów TSpec
ID parametrów TSpec
Token Bucket Rate [r]
Token Bucket Size [b]
Peak Data Rate [p]
Minimum Policed Unit [m]
0
Maximum Packet Size [M]
Zarezerwowane
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
Długość obiektu
Zarezerwowane
Wersja
4 bity
4 bity
4 bity
4 bity
4 bity
Parametry globalne usługi QoS (m.in. MTU, path latency, APB) - pole zawsze obecne
Parametry usługi GS (break bit, Ctot, Dtot.Csum, Dsum) - pole obecne tylko wtedy, gdy jest stosowana usługa GS
Parametry usługi CLS (m.in. break bit) - pole obecne tylko wtedy, gdy jest stosowana usługa CLS
4 bity
4 bity
4 bity
Długość obiektu
Zarezerwowane
Wersja
Długość pola danych CLS
ID usługi CLS
Długość pola z parametrami TSpec
Flagi parametrów TSpec
ID parametrów TSpec
Token Bucket Rate [r]
Token Bucket Size [b]
Peak Data Rate [p]
Minimum Policed Unit [m]
Slack Term [S]
Rate [R]
Długość pola z parametrami RSpec
Flagi parametrów RSpec
ID parametrów RSpec
0
Maximum Packet Size [M]
Zarezerwowane
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
Długość obiektu
Nieużywane
Wersja
Długość pola danych GS
ID usługi GS
Długość pola z parametrami TSpec
Flagi parametrów TSpec
ID parametrów TSpec
Token Bucket Rate [r]
Token Bucket Size [b]
Peak Data Rate [p]
Minimum Policed Unit [m]
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
Całkowita długość pakietu
Typ usługi TOS
Długość
Wersja
Przesunięcie fragmentacji
Znacz-niki
Identyfikacja
Suma kontrolna nagłówka
Protokół przesyłający dane
Czas życia (TTL)
Adres źródłowy datagramu - 32 bity
Adres docelowy datagramu - 32 bity
Opcje nagłówka (Mogą nie występować)
Transportowane dane (TCP, UDP …)
KLASYFIKATOR
JEDNOSTKA OZNACZAJĄCA PAKIETY
JEDNOSTKA KSZTAŁTUJĄCA RUCH LUB JEDNOSTKA ODRZUCAJĄCA PAKIETY
JEDNOSTKA POMIAROWA
URZĄDZENIE SPRAWDZAJĄCE I KSZTAUTUJĄCE CHARAKTERYSTYKĘ RUCHU
PAKIETY
Region DiffServ
Obszar sieci nie wspierający architektury DiffServ
IntServ
Obszar sieci nie wspierający architektury DiffServ
ER2
BR2
BR1
ER1
Nadawca
Odbiorca
ER1
BR1
Host A
N1
Bandwidth Broker N1-BB
Dane
Sygnalizacja
N2
N3
Host B
ER2
BR2
LR1
CR
Bandwidth Broker N2-BB
Bandwidth Broker N1-BB
DiffServ
IntServ
Host A
Host B
BR1
ER1
BR2
ER2
PATH message
RESV message
RESV/ERR
Pakiety z DSCP
DiffServ
DiffServ
PHB
LSR
LSR
Brzegowy
LSR
Brzegowy
LSR
PAKIET
PAKIET
ETYKIETA
PAKIET
ETYKIETA
PAKIET
Domena IGP
z protokołem dystrybucji etykiet (LDP)
LSR
LER
LER
4. Wyjściowy LER usuwa etykietę i wysyła pakiet do odbiorcy
LSR
LSR
LSR
1. Wejściowy LER dodaje etykietę na podstawie analizy nagłówka IP
2, 3. LSR przełączają na podstawie etykiet
Ścieżka przełączania etykiet (LSP)
LER - Ruter brzegowy
LSR - Ruter przełączający etykiety
In
Label
Out
Label
Out
I'face
Address
Prefix
-
-
...
...
156.17
1
1
4
5
171.69
Out
I'face
In
Label
...
...
7
1
5
9
156.17
171.69
Out
Label
Address
Prefix
0
4
Address
Prefix
Out
Label
156.17
Out
I'face
In
Label
...
...
-
0
9
1
1
0
0
171.69
156.17
156.17.230.78
Data
Data
156.17.230.78
Data
156.17.230.78
Data
156.17.230.78
4
9
LER
LSR
LER
...
Etykieta 1
Etykieta n
Orginalny pakiet
Wierzchołek
stosu
Dno stosu
DANE
HEC
TTL
S
Exp.
Wartość etykiety
CLP
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
Etykieta
PTI
VPI
VCI
GFC
GFC
CLP
VPI
VCI
HEC
DANE
Etykieta 1
PTI
Etykieta 2
Dane
1-szy nagłówek dodatkowy
Nagłówek podstawowy
opcjonalne
...
n-ty nagłówek dodatkowy
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
tO
4 bity
Etykieta potoku
Wersja
Liczba etapów
Następny nagłówek
Długość zawartości
Klasa ruchu
24 bity
Adres nadawcy
tN
Identyfikator potoku
Adres odbiorcy
Strumień pakietów IP
Dane
Nagłówek
Dane
Nagłówek
Dane
Nagłówek
Odbiorca
Dane
Nagłówek
Dane
Nagłówek
Dane
Nagłówek
Dane
Nagłówek
Nadawca
Dane
Nagłówek
Przygotowanie Informacji Wyjściowych
Post-procesing
Zapis
Zbieranie Danych Pomiarowych
Inicjalizacja
Raport pomiarowy
Statystyczna obróbka danych:
średnia
maksimum, minimum
mediana
Wyliczenie wartości metryk:
opóźnienia jednokierunkowego
zmienności opóźnienia jednokierunkowego
straty (loss)
Sortowanie danych
Zapis danych pomiarowych
Pobranie danych:
z Tablicy Pomiarowej
wartości wyliczonych metryk:
opóźnienia dwukierunkowego (ping)
przepustowości
z liczników zliczających pakiety w celu wyliczenia metryki straty (loss)
Wysłanie sygnału inicjującego pomiary wybranych metryk
Zerowanie liczników
Nadanie Punktom Pomiarowym funkcji Monitora Nadawcy lub Monitora Odbiorcy
BITY:
0 1 2 3 4 5 6 7
DSCP
NIE UŻYWANE
SELEKTOR KLASY
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
4 bity
Całkowita długość pakietu
Typ usługi TOS
Długość
Wersja
Przesunięcie fragmentacji
Znacz-niki
Identyfikacja
Suma kontrolna nagłówka
Protokół przesyłający dane
Czas życia (TTL)
Adres źródłowy datagramu - 32 bity
Adres docelowy datagramu - 32 bity
Opcje nagłówka (Mogą nie występować)
Transportowane dane (TCP, UDP …)
Sonda
Pomiarowa
Sonda
Pomiarowa
Kierunek
transferu
Kierunek
transferu
Nadawca
Jednostka Centralna
(Post-procesing)
Monitor Odbiorcy
Monitor Nadawcy
(4.1.)
Host A
SP
SP - Sonda Pomiarowa
SP
Jednostka
Centralna
SP
SP
SP
SP
SP
Host C
Sieć LAN
Region IP
SLA (B, C)
SLA (A, B)
SLA (A, C)
Domena C
Domena B
Domena A
Host A
Odbiorca
Synchronizacja GPS
Synchronizacja GPS
Sieć IP
Wyszukiwarka
Podobne podstrony:
WYKORZYSTYWANIE MODELU LUK JAKOŚCI W ZARZĄDZENIU JAKOŚCIĄ USŁUG MEDYCZNYCH
BADANIE STOPNIA ZADOWOLENIA KLIENTÓW Z JAKOŚCI USŁUG
Adresowanie w protokole IP id 5 Nieznany (2)
Protokół IP, Politechnika Lubelska
jakosc uslug jako narzedzie roz Nieznany
0 Kryteria oceny JAKOŚCI USŁUG
jakosc uslug medycznych - konspekt wykładu, Logistyka, zarządzanie jakością
Kompetencje pracownicze jakość usług
Jakość Usług Turystycznych
ECTS Jakosc uslug hotelarsko-gastronomicznych Mysiak 01 2011, notatki, WSTiH, 301lzh
Jakość energii w sieciach promieniowych niskiego napięcia
referat jakość usług bankowych(1), Bankowość i Finanse
Sieci, Adresowanie w protokole IP, Adresowanie w protokole IP
Protokuł IP
Jakość usług gastronomicznych, percepcja konsumenta (ang.)
Jakosc uslug klient student
Kategoryzacja gospodarstw a jakość usług agroturystycznych
więcej podobnych podstron