Metody gwarantowania QoS płaszczyzny sterowania w systemach specjalnych

Transkrypt

1 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 R ) 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 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 R ) 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,

2 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 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.

3 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 AC Układ decyzyjny CAC Porównanie (ruch/zasoby) Estymator ruchu Estymator zasobów Strumień danych Wywołanie (opis wywołania) Strumień danych(pakiety) Strumienie w systemie/łączu Zasoby systemu/łącza 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

4 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 Aplikacja RT AC/term AC/rout Ruter 1 sygnalizacja Routing QoS (15) (2) (5) (4) (14) (3) (6) (1) (7) (13). AC/rout Ruter n Routing QoS (8) (9) (10) (12) sygnalizacja (11) AC/term Aplikacja RT dane (16) 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 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): (1) r α N k + i =1 r i ρ C k gdzie: r α - przepływność szczytowa strumienia zgłaszanego r i - przepływność średnia strumienia zgłaszanego N k - 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) C k- przepustowość łącza przeznaczona dla danej klasy usług k (2) Sumaryczna wartość przepływności składowych strumieni r i może być zastąpiona wartością średniej zagregowanej wartości obciążenia łącza otrzymaną w wyniku pomiarów. Zakładając, że

5 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 2B k 2Bk ln(pr ) k (3) gdzie: ρ k maksymalne natężenie ruchu na łączu/ (części łącza) dla k-tej klasy ruchu. B k wielkość bufora dla k-tej klasy ruchu Pr k prawdopodobieństwo utraty pakietu Przy założeniu, że maksymalna wartość Pr k dla usług RT wynosi 10-3, wyliczona wielkość natężenia ruchu na łączu ρ k wynosi ok 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. ) 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.

6 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 A Decyzja o wyborze trasy Ruch wychodzący z rutera Wiedza o połączeniach Wiedza o adresie docelowym Tablica rutingu Ruch napływający do rutera B Decyzja o wyborze trasy Wiedza o połączeniach i zasobach sieci Ruch wychodzący z rutera Baza informacji o topologii sieci i parametrach łączy Wiedza o adresie docelowym Tablica rutingu Ruch napływający do rutera Decyzja o wyborze trasy Baza informacji o topologii sieci i parametrach łączy Wiedza o wymaganiach QoS C Ruch wychodzący z rutera Wiedza o połączeniach i zasobach sieci 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

7 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. Oba protokoły muszą ściśle ze sobą

8 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 ) informacje o jakości obsługi żądania. Na podstawie tych danych protokół (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. SIP/ SIP/ 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/ 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 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ół 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:

9 gdzie: TC rate delay jitter packet loss q=<tc> <r rate> <d delay> <j jitter> <p 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. 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 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_), b. d delay ( q= ) Max_Path_Latency <1,8> (PATH_), 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_, 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_, 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 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.

10 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 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, 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 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 R ) 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, ITU-T Recommendation Y.1291, An architectural framework for support of Quality of Service in packet networks, 05/ 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, RFC 5340, OSPF for IPv6, IETF, RFC 3261, SIP: Session Initiation Protocol, IETF, RFC 3312, Integration of resource Management and Session Initiation Protocol (SIP), IETF, RFC 2212, Specification of Guaranteed Quality of Service, IETF, Zespół pracowników WIŁ, Specyfikacja mechanizmów rezerwacji zasobów w taktycznych sieciach IP, WIŁ 613/2009/PBR, Jacek Pszczółkowski, Specyfikacja mechanizmów przyjmowania zgłoszeń w taktycznym

11 systemie łączności wykorzystującym technikę IPv6, WIŁ 50/2010/PBR, Mirosław Ruszkowski, Specyfikacja mechanizmów QoS rutingu w taktycznym systemie łączności wykorzystującym technikę IPv6, WIŁ 51/2010/PBR, Rafał Bryś, Specyfikacja mechanizmów sygnalizacji w taktycznym systemie łączności wykorzystującym technikę IPv6, WIŁ 52/2010/PBR, 2010.