Metody gwarantowania QoS płaszczyzny sterowania w systemach

Rafał Bryś, Jacek Pszczółkowski, Mirosław Ruszkowski
Zakład Systemów Łączności
Wojskowy Instytut Łączności
Metody gwarantowania QoS płaszczyzny
sterowania w systemach specjalnych
W referacie zaprezentowana została metoda QoS bazująca na mechanizmach płaszczyzny sterowania
opracowana w ramach Projektu Badawczo-Rozwojowego MNiSW (PBR nr 0 R00 0024 06) pt.: „Metoda
gwarantowania jakości usług w taktycznym systemie łączności wykorzystującym technikę sieciową IPv6 i
integracji systemów bazujących na IPv4”. We wstępie przedstawiona została usystematyzowana przez
międzynarodową organizację standaryzacyjną ITU-T architektura QoS, na bazie której sprecyzowany został
obszar oraz funkcjonujące w nim mechanizmy stanowiące przedmiot niniejszego referatu. W dalszej części
dokonano szczegółowej specyfikacji mechanizmów płaszczyzny sterowania proponowanych do
zastosowania w routerze sieci IPv6 taktycznego systemu łączności STORCZYK 2010, będącego obiektem
implementacji proponowanych rozwiązań. W celu lepszego zrozumienia kompleksowego funkcjonowania
mechanizmów płaszczyzny sterowania, jako pierwsza przedstawiona została funkcja nadzorowania
przyjmowania zgłoszeń (AC), następnie routing QoS, a na końcu mechanizmy sygnalizacyjne bazujące na
wypracowanych przez nie decyzjach. Specyfikacja poszczególnych mechanizmów zawiera elementy
standardowe oraz propozycje rozszerzeń koniecznych do spełnienia wymagań specjalnych systemów
łączności w zakresie realizacji usług połączeniowych z zadaną jakością.
1. Wprowadzenie
Obiektem implementacji przedstawionych w referacie mechanizmów QoS jest system
STORCZYK 2010. Jest to system łączności wprowadzany do polskich Sił Zbrojnych jako kolejna
generacja systemu eksploatowanego i rozwijanego od kilkunastu lat. W pierwszej wersji, system
wyposażony był w urządzenia pracujące w trybie komutacji kanałów, a transmisja danych
realizowana była w trybie modemowym. Prowadzone w kolejnych latach prace rozwojowe systemu
pozwoliły na zwiększenie jego funkcjonalności oraz wyposażenie w urządzenia komutacji
pakietów. Obecnie system STORCZYK przystosowany jest do pracy z protokołem IPv4 w trybie
„best effort”. W wersji STORCZYK 2010 zaproponowano zastosowanie routerów (zbudowanych w
oparciu o rozwiązania firmowe producenta systemu) wykorzystujących protokół sieciowy IPv6.
Zgodnie z zaleceniami NATO dla systemów bazujących na protokole IPv6, muszą one posiadać
zdolność do realizacji usług telekomunikacyjnych z uwzględnieniem ich jakości. Dlatego konieczne
było zaproponowanie mechanizmów wspierających QoS oraz ich implementacja w urządzeniach
systemu odpowiedzialnych za realizację komutacji pakietów IP.
Standardowe mechanizmy QoS dla sieci pakietowych IP zostały zdefiniowane w zaleceniu
ITU-T Y.1291 [2], w którym zgodnie z przedstawioną tam architekturą zostały pogrupowane i
umiejscowione na trzech płaszczyznach architektury logicznej (sterowania, danych oraz
zarządzania)[2]. Docelowym rozwiązaniem wsparcia jakości usług w sieciach specjalnych powinno
być zastosowanie wszystkich mechanizmów architektury QoS związanych zarówno ze schematem
DiffServ płaszczyzny danych, jak i schematem IntServ płaszczyzny sterowania. Rozwiązanie takie
pozwoli na zapewnienie pełnej gwarancji jakości usług, tzw. twardy QoS. Na potrzeby realizacji
Projektu Badawczo-Rozwojowego (PBR nr 0 R00 0024 06) pt.: „Metoda gwarantowania jakości
usług w taktycznym systemie łączności wykorzystującym technikę sieciową IPv6 i integracji
systemów bazujących na IPv4” wyspecyfikowano cztery podstawowe klasy usług sieciowych:
• RT – przeznaczona dla transmisji stumieniowych, np. głos, wideo,
• NRT-TC – przeznaczona dla krótkotrwałych transmisji połączeniowych TCP, np.
informacje sterujące, sygnalizacja,
•
•
NRT – przeznaczona do długotrwałych transmisji połączeniowych TCP, np. HTTP, FTP
BE – przeznaczona dla pozostałych transmisji nie wygmagających gwarancji jakości.
oraz przyjęto założenie, że pełna gwarancja jakości zgodnie ze schematem IntServ realizowana
będzie tylko dla strumieniowych usług czasu rzeczywistego RT.
W związku z powyższym, mechanizmami będącymi obiektem niniejszego referatu są
mechanizmy modelu IntServ umiejscowione w płaszczyźnie sterowania. Zwane są
„wysokopoziomowymi” i działają na poziomie wywołań (na poziomie strumieni, przepływów i
sesji). Należą do nich:
• funkcja nadzorowania przyjmowaniem zgłoszeń,
• routing QoS.
• rezerwacja zasobów,
• sygnalizacja.
Mechanizmy nadzorowania przyjmowaniem zgłoszeń AC (ang. Admission Control) podejmują
decyzję związaną z odrzuceniem lub przyjęciem określonego strumienia danych do sieci jeżeli
posiada ona zasoby wystarczające do obsługi tego strumienia z żądanymi parametrami QoS.
Prawidłowe działanie mechanizmu AC gwarantuje, że przyjęcie nowego zgłoszenia nie pogorszy
jakości już obsługiwanych połączeń. Pozwala tym samym kontrolować obciążenie w sieci i unikać
przeciążeń (zatorów). Mechanizmy routingu QoS są odpowiedzialne za wyznaczenie trasy (ścieżki)
transmisji danych, na której znajdą się wyłącznie elementy sieciowe będące w stanie zrealizować
daną usługę z parametrami jakościowymi QoS określonymi w żądaniu połączenia. Mechanizmy
routingu QoS ściśle współdziałają z mechanizmami rezerwacji zasobów.
Rezerwacja zasobów, zgodnie z założeniami modelu IntServ realizowana jest dla pojedynczych
lub zagregowanych strumieni danych. Umożliwia aplikacji inicjującej zgłoszenie węzłom sieci
(routerom) wymagań dotyczących parametrów QoS i na ich podstawie dokonuje rezerwacji
zasobów w węzłach wzdłuż trasy przesyłu danych wyznaczonej przez routing QoS. Każdy router
przyjmujący i realizujący żądania przechowuje informacje o dokonanych rezerwacjach wraz z
informacją o skojarzonym strumieniu danych. W przypadku usług połączeniowych wymagających
wymiany informacji inicjujących właściwą transmisję danych pomiędzy terminalami końcowymi,
stosowane są protokoły sygnalizacyjne odpowiedzialne za ustanowienie sesji (połączenia).
Powinny one wspierać realizację usług z wymaganą jakością (QoS) przekazując współpracującym
elementom sieci (routerom brzegowym) żądane parametry jakościowe, na podstawie których,
mechanizmy rezerwacji ustalą i przydzielą niezbędne zasoby sieciowe na trasie wyznaczonej do
przesyłania pakietów IP należących do określonego strumienia danych.
W dalszej części referatu przedstawiono szczegółową specyfikację mechanizmów wsparcia
QoS płaszczyzny sterowania proponowanych do implementacji w urządzeniach systemu
STORCZYK 2010.
2. Mechanizm nadzorowania przyjmowaniem zgłoszeń (AC)
Podstawowym zadaniem mechanizmów AC jest przyjęcie nowych zgłoszeń tylko wtedy, gdy
ich realizacja nie spowoduje pogorszenia jakości już świadczonych usług. Sterowanie
przyjmowaniem nowych zgłoszeń ogranicza nadmierny ruch od użytkowników i zapewnia
poprawną realizację usług zgodnie z uzgodnieniami SLA (Service Level Agreement) ustalonymi
między użytkownikiem, a dostawcą usług.
Realizacja procesu decyzyjnego AC związana jest z dwoma zasadniczymi zagadnieniami:
a. Sposobem opisu i wartościami opisu wywołania, na podstawie których określane są
wymagania użytkownika oraz rezerwowane zasoby;
b. Sposobem monitorowania i pomiaru zasobów udostępnianych na potrzeby obsługi
wywołań strumieniowych RT.
Widać stąd, że każde żądanie realizacji usługi klasy RT, musi być opisane parametrami
zrozumiałymi przez estymator ruchu mechanizmu AC. Na ich podstawie określane są wymagania
ruchowe oraz jakościowe i porównywane z oszacowanymi przez estymator ruchu, wolnymi
zasobami sieci lub elementu sieciowego (routera). Przyjęcie zgłoszenia nastąpi wówczas, gdy
spełnione zostaną dwa warunki:
a. ilość wolnych zasobów jest większa lub równa wymaganym w żądaniu,
b. polityka mechanizmu AC dopuszcza przyjęcie danego wywołania.
Graficzna reprezentacja procesu decyzyjnego zaawansowanych mechanizmów nadzorowania
przyjmowaniem zgłoszeń (AC) przedstawiona została na rysunku 1.
AC (płaszczyzna sterowania)
Polityka
Układ decyzyjny CAC
AC
Porównanie (ruch/zasoby)
Estymator ruchu
Estymator zasobów
Strumień danych
Wywołanie (opis wywołania)
Zasoby systemu/łącza
Strumień danych(pakiety)
Strumienie w systemie/łączu
Strumienie
wyjściowe
Rys.1. Opis funkcjonalny mechanizmów przyjmowania zgłoszeń (AC)
W specyfikacji mechanizmów AC dla systemów łączności o specjalnym przeznaczeniu
przyjęto założenie, że każde z urządzeń sieciowych powinno podejmować samodzielnie decyzję
dotyczącą obsługi strumienia, bazując na:
a. informacjach zawartych w specyfikacji ruchowej opisującej nowy strumień danych;
b. informacji o aktualnych obciążeniach na bezpośrednio podłączonych łączach;
c. informacjach o aktualnej topologii sieci (węzłach i łączach) uzyskanej z podsystemu
zarządzania.
Powyższe uwarunkowania pozwalają przyjąć, że estymacja zasobów powinna opierać się na
algorytmach pomiarowych MBAC (Measurement-Based Admission Control), przy czym pomiary
powinny być wykonywane w każdym węźle pośrednim, PH MBAC (Per-Hop Measurement-Based
Admission Control). W związku z tym, w systemie powinien funkcjonować mechanizm warstwy
zarządzania odpowiedzialny za monitorowanie i pomiary w sieci, którego wyniki pracy pozwolą
oszacować zajętości zasobów w poszczególnych węzłach sieci, a także do nadzorować jakość
aktualnie realizowanych usług.
Na rysunku 2, przedstawiony został schemat procesu zestawiania połączenia z rezerwacją
zasobów, na podstawie którego wyjaśniona zostanie ogólna idea działania mechanizmów
nadzorowania przyjmowaniem zgłoszeń. Jak widać na rysunku, że mechanizmy AC powinny być
zaimplementowane zarówno w routerach (AC/rout) oraz terminalach (AC/term), w których
funkcjonalność AC może być uproszczona. Parametry wywołania przekazywane są w żądaniu
zestawienia połączenia za pomocą mechanizmów sygnalizacji i mogą być negocjowane pomiędzy
terminalami wywołującym i docelowym. Po zakończeniu procesu negocjacji, ustalone parametry
wywołania, w stacji roboczej A przekazywane są do modułu rezerwacji, który przy współpracy z
mechanizmami AC w terminalu wyjściowym (AC/term) określa możliwość przekazania wywołania
do routera brzegowego skojarzonego z tą stacją roboczą. Akceptacja wywołania powoduje dalsze
przesyłanie wiadomości rezerwacyjnych, przez wszystkie węzły sieci, aż do osiągnięcia docelowej
stacji roboczej B.
Stacja robocza A
Stacja robocza B
Ruter 1
sygnalizacja
(15)
Aplikacja
RT
Routing
QoS
(2)
(4)
RSVP
(3)
Ruter n
(1)
(14)
sygnalizacja
Routing
QoS
(5)
(7)
RSVP
(8)
RSVP
(13)
(6)
(9)
(10)
RSVP
(12)
Aplikacja
RT
(11)
….
AC/term
AC/rout
AC/rout
(16)
dane
AC/term
dane
Rys.2. Proces zestawiania połączenia z rezerwacją zasobów
Mechanizm AC w terminalach powinien realizować wstępną procedurę decyzyjną o przyjęciu
zgłoszenia do obsługi. Z uwagi na konieczność uproszczenia procesu AC, proponuje się
wykorzystanie algorytmu prostego sumowania dla interfejsu wyjściowego. Wywołanie jest
akceptowane, jeżeli spełnione są warunki zdefiniowane wzorem (1):
v + rα ≤ C
gdzie: rα - przepływność strumienia zgłaszanego (deklarowana)
v - suma wszystkich rezerwacji na łączu
(1)
C - przepustowość łącza przeznaczona dla danej klasy usług
Przyjęcie wywołania w terminalu pozwala na inicjację rezerwacji dla tego wywołania na
interfejsie wyjściowym terminala i rozpoczęcie rezerwacji w routerze brzegowym sieci
znajdującym się na ścieżce rezerwowanej. Moduł rezerwacji w takim routerze, na podstawie
informacji z terminala musi komunikować się z procesem routingu QoS. Na podstawie informacji
zwrotnej z modułu routingu QoS, określany jest interfejs wyjściowy dla wywołania i wysyłane
zapytanie o możliwość realizacji żądanego wywołania do modułu AC/rout. Mechanizmy AC w
routerze (AC/rout) powinny zapewnić lepsze wykorzystanie zasobów, niż AC w terminalach przy
wykorzystaniu algorytmu prostego sumowania. Zamiast tego można wykorzystać metodę pomiaru
sumy średnich przepływności, według której nowe połączenie jest przyjmowane jeżeli spełnione są
warunki określone wzorem (2):
Nk
rα +
∑r
i
≤ ρkCk
i =1
(2)
gdzie: rα - przepływność szczytowa strumienia zgłaszanego
ri - przepływność średnia strumienia zgłaszanego
Nk - oznacza liczbę połączeń aktualnie w obsłudze
ρk - maksymalne natężenie ruchu na łączu/ (części łącza) dla k-tej klasy ruchu. ρ∈(0,1)
Ck- przepustowość łącza przeznaczona dla danej klasy usług
Sumaryczna wartość przepływności składowych strumieni ri może być zastąpiona wartością
średniej zagregowanej wartości obciążenia łącza otrzymaną w wyniku pomiarów. Zakładając, że
wywołania będą obsłużone według modelu M/D/1/B* można wyznaczyć wielkość współczynnika
ρk według wzoru (3):
ρk =
2 Bk
2 Bk − ln(Prk )
(3)
gdzie: ρk – maksymalne natężenie ruchu na łączu/ (części łącza) dla k-tej klasy ruchu.
Bk – wielkość bufora dla k-tej klasy ruchu
Prk – prawdopodobieństwo utraty pakietu
Przy założeniu, że maksymalna wartość Prk dla usług RT wynosi 10-3, wyliczona wielkość
natężenia ruchu na łączu ρk wynosi ok. 0.85. Dodatkowo, ustalając określoną wielkość bufora dla
k-tej klasy ruchu można parametryzować próg decyzyjny zastosowanego mechanizmu AC.
Spełnienie warunku określonego wzorem (2) przez strumień nowego wywołania rα pozwala
modułowi rezerwacji zasobów na wstępną rezerwację w routerze i wysłania żądania do następnego
routera na trasie określonej przez routing QoS. Działania AC/rout w routerach pośrednich na
ścieżce rezerwowanej oraz interakcje z mechanizmami rezerwacji oraz routingu QoS powinny być
identyczne jak opisane powyżej dla routera brzegowego.
Negatywna decyzja mechanizmu AC o przyjęciu nowego wywołania w dowolnym elemencie
na ścieżce połączenia (terminalu lub routerze) będzie skutkować wstrzymaniem procesu rezerwacji.
W efekcie stacja robocza inicjująca takie wywołanie może ponowić wywołanie z niższymi
wymaganymi parametrami QoS, zestawić połączenie bez wymagania gwarancji lub zaniechać
realizacji usługi.
Mechanizmy AC współdziałają z modułami rezerwacji (np. RSVP) tylko w kierunku od stacji
inicjującej połączenie zgodnie z kierunkiem wysyłania komunikatów wstępnej rezerwacji PATH.
Nie partycypują jednak w obsłudze komunikatów zwrotnych RESV, potwierdzających rezerwację,
ponieważ w przypadku braku akceptacji wywołania w którymkolwiek z węzłów pośrednich proces
zestawiania ścieżki zostaje przerwany, a do odbiorcy wysyłany zostaje komunikat o odrzuceniu
żądania rezerwacji (komunikat o błędzie).
Jak wcześniej wspomniano, mechanizmy AC ściśle współpracują z mechanizmami rezerwacji,
które z kolei dokonują rezerwacji zasobów na ścieżkach ustalonych przez routing QOS dla
wybranej klasy usług. W następnym rozdziale opisana została specyfikacja routingu QoS
proponowana do zastosowania w specjalnych systemach łączności.
3. Routing QoS
W celu lepszego zrozumienia idei routingu QoS warto przywołać definicję opracowaną przez
międzynarodową organizację standaryzacyjną IETF, która routing QoS definiuje następująco [5]:
„Routing QoS to taki mechanizm wyszukiwania tras, który określa ścieżki dla przepływów w
oparciu o pewną wiedzę o dostępnych zasobach sieci jak również w oparciu o wymagania QoS dla
tych przepływów.”
Aby wymagania QoS mogły być uwzględnione przez mechanizm routingowy, należy
zastosować odpowiednie miary parametrów sieci – metryki. Wyrażają one jeden, bądź kombinację
kilku parametrów QoS i odnoszą się do konkretnego interfejsu wyjściowego urządzenia routującego
lub przypadku routingu międzydomenowego, fragmentów sieci. Metryką może być przepustowość
łącza, opóźnienie na łączu, wartość jitter’a, straty pakietów.
*
M/D/1/B - system kolejkowy opisany wg notacji Kendalla (TMO - teoria masowej obsługi) M - markowski (zgodnie z
rozkładem Poissona) czas przybycia danych do kolejki, D - deterministyczny czas obsługi, 1 - jedno stanowisko
obsługi, B - wielkość bufora kolejki.
Na rysunku 2 przedstawiono ideę przejścia od klasycznego rutingu, nieuwzględniającego
wymagań ruchu co do jakości przekazu, do rutingu wspomagającego mechanizmy QoS. Routing
taki uwzględnia wymagania jakości zgłaszane przez ruch napływający do interfejsu wejściowego
routera, kierując go do sieci docelowej ścieżką o zadanych parametrach.
Wiedza o adresie
docelowym
Tablica rutingu
Ruch napływający
do rutera
Decyzja o wyborze trasy
W iedza
o połączeniach
A
Ruch wychodzący
z rutera
W iedza o adresie
docelowym
Tablica rutingu
Ruch napływający
do rutera
Baza informacji
o topologii sieci
i parametrach łączy
Decyzja o wyborze trasy
Wiedza
o połączeniach
i zasobach sieci
B
Ruch wychodzący
z rutera
Wiedza o adresie
docelowym
Tablica rutingu
Ruch napływający
do rutera
Wiedza
o połączeniach
i zasobach sieci
W iedza o
wymaganiach QoS
C
Baza informacji o
topologii sieci i
parametrach łączy
Decyzja o wyborze trasy
Ruch wychodzący
z rutera
Rys. 3. Trzy tryby obsługi ruchu przez router [12]
Na rysunku 3 przedstawiono kolejno:
a. Tradycyjny routing na podstawie adresu docelowego i tablicy rutingu;
b. Routing na podstawie adresu docelowego i tablicy rutingu zbudowanej w oparciu o
pewną wiedzę o właściwościach łączy (realizowany np. przez protokół OSPF wg
[6]);
c. Routing QoS na podstawie adresu docelowego i tablicy rutingu zbudowanej w
oparciu o pewną wiedzę o właściwościach łączy oraz wymaganiach zgłaszanych
przez ruch napływający do routera (realizowany przez protokół OSPF z
rozszerzeniami QoS).
Routing realizowany jak w punkcie c jest zgodny z definicją rutingu QoS zamieszczoną w
zaleceniu IETF [5]. Protokołem rutingu dynamicznego najlepiej odpowiadającym potrzebom
specjalnych systemów łączności jest OSPFv3. Zaproponowano modyfikację jego funkcjonowania
w celu spełnienia wymagań IETF na architekturę rutingu QoS zawartą w zaleceniu [5].
Na wstępie przyjęto założenie, że w sieci łączności o specjalnym przeznaczeniu metryką jest
opóźnienie transmisji pakietów poprzez interfejs wyjściowy routera, oraz że funkcjonuje w niej
mechanizm pomiarowy (w płaszczyźnie zarządzania architektury QoS) gromadzący informacje
dotyczące opóźnień na poszczególnych łączach.
Poniżej, w punktach, został przedstawiony zaproponowany w projekcie badawczorozwojowym algorytm realizacji funkcji protokołu routingu QoS w wersji dla IPv6 i towarzyszące
temu funkcje i procedury dodatkowe.
I. Po uruchomieniu urządzeń systemu:
1. Na każdym routerze w systemie uruchamiają się cztery instancje protokołu OSPFv3, każda
wyróżniona numerem 1 – 4 w polu nagłówka „Instance ID” (jego umiejscowienie w
nagłówku pakietu wskazuje zaznaczenie na rysunku 4). Od tej chwili w całym systemie
funkcjonują równolegle cztery instancje protokołu działające niezależnie.
Rys. 4. Nagłówek pakietu OSPFv3
2. Procedury pomiarowe ustalają wartości opóźnienia na wszystkich łączach i przekazują je do
bazy danych (na przykład na komputerze administratora sieci).
3. Routery, przy pomocy standardowych procedur (wymiana komunikatów Hello, LSA),
uzyskują wiedzę o topologii sieci.
4. Utworzony specjalnie skrypt przypisuje poszczególnym łączom (na każdym routerze) koszt
na postawie wartości pomiarowej metryki uzyskanej z bazy danych. Nie zachodzi przy tym
potrzeba modyfikowania drzewa połączeń wyznaczonych przez algorytm Dijkstry,
ponieważ metryka reprezentująca opóźnienie jest:
a. addytywna, tak samo jak koszt wyznaczony na podstawie domyślnej metryki opartej
na przepustowości,
b. ma tę samą wagę – im mniejsza wartość tym lepsze właściwości łącza.
5. W trzech z czterech utworzonych przez standardowe procedury tablicach rutingu, należy
wyeliminować ścieżki o parametrach opóźnieniowych przekraczających dopuszczalne
wartości:
a. IPTD>100ms dla tabeli routingowej nr 1,
b. IPTD>400ms dla tabeli routingowej nr 2,
c. IPTD>1000ms dla tabeli routingowej nr 3,
d. czwarta tabela przeznaczona jest do obsługi ruchu klasy BestEffort.
6. Poszczególne instancje protokołu OSPFv3 (1÷4), przy pomocy odpowiadających im tablic
routingowych (1÷4) przeznaczone będą do obsługi strumieni ruchu następujących typów:
a. RT – tabela routingowa nr1, instancja OSPF nr1;
b. NRT-TC – tabela routingowa nr2, instancja OSPF nr2;
c. NRT – tabela routingowa nr3, instancja OSPF nr3;
d. BE – tabela routingowa nr4, instancja OSPF nr4;
Klasa usług sieciowych, do której należy dany strumień będzie określana na podstawie pola TC
w nagłówku IPv6 lub na podstawie informacji przekazanych w nagłówkach protokołu rezerwacji
zasobów oraz sygnalizacji, których specyfikację przedstawiono w następnym rozdziale.
4. Sygnalizacja i rezerwacja zasobów
Wybranym do zastosowania protokołem sygnalizacji jest protokół SIP dedykowany do sieci IP
wykorzystujących technologię VoIP (ang. Voice over IP). Wybór podyktowany został łatwością
implementacji oraz propozycjami zastosowania protokołu SIP w innych projektach mających na
celu osiągnięcie zdolności sieciocentrycznej przez systemy narodowe państw NATO. Ponadto
przyjęto, że protokół sygnalizacji będzie współpracował z mechanizmami rezerwacji zasobów,
których funkcje będą realizowane za pomocą protokołu RSVP. Oba protokoły muszą ściśle ze sobą
współpracować w celu prawidłowego zestawienia ścieżki dla transmisji danych z określonymi
parametrami jakości usług. Proces zestawiania połączenia pomiędzy terminalami powinien być
nadzorowany przez protokół SIP, za pomocą którego terminale jednocześnie będą przekazywały
elementom sieciowym (routerowym modułom RSVP) informacje o jakości obsługi żądania. Na
podstawie tych danych protokół RSVP (na ścieżce ustalonej przez routing QoS) dokona rezerwacji
zasobów do transmisji pakietów z zadaną jakością. Na rysunku 5 przedstawiona została architektura
systemu wraz z umiejscowieniem implementacji poszczególnych protokołów.
RSVP
RSVP
RSVP
RSVP
RSVP
SIP/RSVP
SIP/RSVP
SIP
SIP
WAS – sieć szkieletowa (Wide Area Subsystem)
LAS – sieć lokalna (Local Area Subsystem)
MANET – mobilna sieć radiowa (Mobile Adhoc NETwork)
Rys. 5. Umiejscowienie implementacji protokołów sygnalizacji w architekturze systemu.
Jak widać na powyższym rysunku, implementacja protokołów sygnalizacyjnych SIP/RSVP
została zaproponowana w routerach sieci szkieletowej oraz odpowiedzialnych za komutację
pakietów przychodzących i wychodzących z/do sieci szkieletowej (routery brzegowe). Wynika to z
przyjętych założeń dotyczących rozdziału funkcjonalności protokołów SIP i RSVP pomiędzy
poszczególne podsystemy. Proponuje się, aby protokół SIP, wspierał realizację usług z wymaganą
jakością (QoS) w sieciach lokalnych oraz w dostępie do sieci szkieletowej przekazując
odpowiednim elementom systemu (routerom brzegowym) informacje o wymaganych parametrach
połączenia. Protokół RSVP bazując na informacjach przekazanych przez SIP będzie dokonywał
rezerwacji zasobów w sieci szkieletowej, tj. ustalał niezbędne zasoby na ścieżce wyznaczonej do
przesyłania pakietów IP z określonymi parametrami ruchowymi i jakościowymi.
W związku z powyższym, konieczne jest określenie sposobu przenoszenia parametrów QoS
oraz zasad współpracy obu mechanizmów sygnalizacyjnych, tj. mapowania wiadomości
sygnalizacyjnych, stanów sygnalizacji oraz innych charakterystycznych dla danego protokołu
funkcjonalności.
W celu zapewnienia wsparcia dla realizacji usług z zadaną jakością przez protokół sygnalizacji
proponuje się dodanie dodatkowego klucza (pola informacyjnego) w sekcji SDP (pole wiadomości)
komunikatu SIP. Pole to oznaczone będzie jako „q=” i będzie zawierało informacje o klasie usługi
oraz parametrach jakościowych:
q=<TC> <r rate> <d delay> <j jitter> <p packet loss>
gdzie:
TC
rate
delay
jitter
packet loss
- klasa usługi,
- wymagana szybkość transmisji danych,
- maksymalne dopuszczalne opóźnienie transmisji pakietów,
- maksymalna dopuszczalna zmienność opóźnienia,
- maksymalna dopuszczalna stopa straty pakietów.
Standardowy proces zestawiania połączenia za pośrednictwem protokołu SIP nie uwzględnia
procedury rezerwacji zasobów sieci. Stąd pojawia się niedogodność polegająca na tym, że protokół
SIP może zestawić połączenie zanim zasoby sieci zostaną przydzielone dla konkretnego połączenia
lub zasoby zostaną zarezerwowane, a połączenie nie zostanie zestawione. Rozwiązaniem
powyższego problemu jest implementacja mechanizmów opisanych w zaleceniu [8]. Zalecenie to
wprowadza modyfikacje w komunikatach protokołu SIP w podobny sposób, jak opisano to
powyżej. Modyfikacje komunikatów SIP polegają na dodaniu dodatkowych kluczy „a=” do
protokołu SDP opisujące warunki wstępne oraz stany realizacji rezerwacji.
Parametry QoS przenoszone w wiadomości SIP (klucz „q=” protokołu SDP), w routerze
brzegowym inicjującym procedurę rezerwacji w sieci, powinny być odpowiednio przepisane do
wiadomości protokołu RSVP. U źródła, tj. w routerze brzegowym występującym po stronie
terminala inicjującego, parametry zawarte w kluczu „q=” powinny być przepisane do elementu
AdSpec wiadomości PATH protokołu RSVP rozpoczynającej procedurę rezerwacji, tzw. wstępna
rezerwacja. Bezpośrednio przepisane mogą być jedynie parametry:
a. r rate („q=”) → Min_Path_Bandwidth <1,6> (PATH_RSVP),
b. d delay („q=”) → Max_Path_Latency <1,8> (PATH_RSVP),
W zależności od żądanej klasy usługi, wielkość przepływności (szybkości transmisji danych)
może być opisywana (w elemencie AdSpec) parametrem minimalnej wymaganej przepływności
(Min_Path_Bandwidth <1,6>) lub dostępnej (Available_Path_Bandwidth <1,5>).
Pozostałych parametrów klucza „q=” protokołu SIP/SDP nie można bezpośrednio przepisać do
pola AdSpec wiadomości PATH_RSVP, dlatego powinny one być odpowiednio [9] przeliczone na
parametry elementu Sender_Tspec zawierającego parametry ruchowe, wykorzystywane do
konfiguracji buforów typu Token Bucket (b – wielkość „wiadra”, r – szybkość napływania
żetonów).
Właściwa rezerwacja odbywa się poprzez przesłanie w kierunku przeciwnym (do kierunku
transmisji wiadomości PATH) wiadomości RESV_RSVP, która zawiera element FlowSepc.
Element ten składa się z pola danych zawierającego parametry ruchowe Receiver_Tspec oraz Rspec
przenoszący właściwe parametry jakościowe. Są nimi:
a. parametr R – opisujący przepływność/szybkość transmisji,
b. parametr S – opisujący różnicę opóźnienia pakietów end-to-end pomiędzy żądanym,
a uzyskanym w wyniku rezerwacji ścieżki o przepustowości R (opóźnienie to
liczone jest w następujący sposób b/R).
Wartości powyższych parametrów strona odbiorcza przesyła kopiując z wiadomości
PATH_RESV w przypadku akceptacji propozycji (AdSpec) strony inicjującej lub ustalając je na
podstawie możliwości własnych aplikacji warstw wyższych.
Reasumując, w specjalnych systemach łączności w zakresie sygnalizacji zaleca się
implementację protokołu SIP z rozszerzeniem jego funkcjonalności o klucze „q=” protokołu opisu
sesji SDP, którego wartości poszczególnych parametrów odczytywane byłyby przez moduły RSVP
we wszystkich elementach sieciowych na ścieżce połączenia wyznaczonej przez protokół routingu
QoS. W przypadku żądania o wyższych parametrach niż aktualna zdolność elementu sieciowego,
decyzję o przyjęciu zgłoszenia podejmowałaby funkcja AC.
5. Zakończenie
W niniejszym referacie przedstawione zostały specyfikacje mechanizmów płaszczyzny
sterowania architektury QoS, tj. nadzorowania przyjmowaniem zgłoszeń, routingu QoS,
sygnalizacji i rezerwacji zasobów wraz z ich rozszerzeniami. Zgodnie z informacją zawartą we
wstępie, proponowane rozwiązania planowane są do implementacji w taktycznym systemie
łączności STORCZYK 2010.
W celu zapewnienia pełnego wsparcia dla realizacji usług z zadaną jakością mechanizmy te
powinny ściśle ze sobą współpracować na zasadach opisanych w treści odpowiednich rozdziałów.
Zaproponowana funkcja nadzorowania przyjmowania zgłoszeń bazuje na pomiarach aktualnej
przepustowości łączy i jest ona mechanizmem prostym do implementacji. Jest ona implementowana
razem z mechanizmem rezerwacji zasobów, protokołem RSVP, który dokonuje rezerwacji w
kolejnych elementach sieciowych (routerach) znajdujących się na ścieżce połączenia (trasie) dla
danej klasy usługi wyznaczonej przez dedykowaną dla niej instancję protokołu OSPFv3. Protokół
ten buduje tablice routingu w oparciu o metryki odwzorowujące opóźnienie transmisji pakietów
danej klasy poprzez poszczególne łącza. W przypadku usług typu połączeniowego, np. głos, wideo,
niezbędny do ustanowienia połączenia (sesji multimedialnej) jest protokół sygnalizacyjny. Dla
specjalnych systemów łączności zaproponowany został protokół SIP (rekomendowany również
przez organizacje NATO), którego funkcjonalność proponuje się rozszerzyć o możliwości
przekazywania żądań realizacji połączenia z wymaganymi parametrami jakości. Ponieważ usługi
połączeniowe są z reguły usługami czasu rzeczywistego, w związku z tym dla pełnej gwarancji ich
jakości zgodnej z wymaganiami przekazanymi w żądaniu, dokonuje się rezerwacji części zasobów
sieciowych na wyłączność strumienia danych tej usługi. Dlatego zaistniała konieczność współpracy
protokołu sygnalizacji SIP z protokołem rezerwacji RSVP polegająca na takiej jego modyfikacji,
aby w procesie zestawiania połączenia z określonymi parametrami QoS uwzględniony został czas
oraz inne czynniki procedury rezerwacji.
Przedstawione w niniejszym referacie specyfikacje mechanizmów płaszczyzny sterowania
architektury QoS (model IntServ) dokładniej opisane są w dokumentach sprawozdawczych
Projektu Badawczo-Rozwojowego (PBR nr 0 R00 0024 06) pt.: „Metoda gwarantowania jakości
usług w taktycznym systemie łączności wykorzystującym technikę sieciową IPv6 i integracji
systemów bazujących na IPv4”.
Literatura
1.
Krzysztof Strzelczyk, Koncepcja gwarantowania jakości usług w taktycznych sieciach IP,
WIŁ 597/2009/PBR, 2009.
2. ITU-T Recommendation Y.1291, An architectural framework for support of Quality of Service
in packet networks, 05/2004.
3. A. Grzech, Sterowanie ruchem w sieciach teleinformatycznych, Oficyna Wydawnicza
Politechniki Wrocławskiej, Wrocław, 2002 r.
4. S. Kaczmarek, Piotr Żmudziński, Metody Admission Control oparte na pomiarach, PWT,
Poznań, 2004 r.
5. RFC 2386, A Framework for QoS-based Routing in the Internet, IETF, 1998.
6. RFC 5340, OSPF for IPv6, IETF, 2008.
7. RFC 3261, SIP: Session Initiation Protocol, IETF, 2002.
8. RFC 3312, Integration of resource Management and Session Initiation Protocol (SIP), IETF,
2002.
9. RFC 2212, Specification of Guaranteed Quality of Service, IETF, 1997.
10. Zespół pracowników WIŁ, Specyfikacja mechanizmów rezerwacji zasobów w taktycznych
sieciach IP, WIŁ 613/2009/PBR, 2009.
11. Jacek Pszczółkowski, Specyfikacja mechanizmów przyjmowania zgłoszeń w taktycznym
systemie łączności wykorzystującym technikę IPv6, WIŁ 50/2010/PBR, 2010.
12. Mirosław Ruszkowski, Specyfikacja mechanizmów QoS rutingu w taktycznym systemie
łączności wykorzystującym technikę IPv6, WIŁ 51/2010/PBR, 2010.
13. Rafał Bryś, Specyfikacja mechanizmów sygnalizacji w taktycznym systemie łączności
wykorzystującym technikę IPv6, WIŁ 52/2010/PBR, 2010.