Raport z realizacji zadania badawczego: A.9 Tytuł raportu: Opracowanie wymagań na sieć laboratoryjną system IP QoS

Transkrypt

1 Numer Projektu Badawczego Zamawianego: -MNiSW-02-II/2007 Tytuł projektu: Numer dokumentu: Usługi i sieci teleinformatyczne następnej generacji aspekty techniczne, aplikacyjne i rynkowe -MNiSW-02-II/2007/IŁ-PIB/A.9 Tytuł raportu: Opracowanie wymagań na sieć laboratoryjną system IP QoS Przewidywany termin dostarczenia raportu: 30/06/08 Rzeczywisty termin dostarczenia raportu: 25/06/08 Kierownik zadania: Wykonawcy: Henryk Gut IŁ-PIB, PW, NASK Abstrakt: Dokument ten jest raportem z realizacji zadania badawczego A.9 pt. Opracowanie wymagań na sieć laboratoryjną systemu IP QoS. Słowa kluczowe: sieć laboratoryjna IP QoS, TestBed, Wymagania, Routery brzegowe, Routery szkieletowe, Emulator sieci IP, Generator / Analizator ruchu IP, DiffServ, MPLS.

2 Streszczenie Niniejszy dokument stanowi raport z realizacji zadania badawczego A.9, które jest etapem wstępnym szerszych działań zespołu, prowadzących do budowy i uruchomienia sieci laboratoryjnej systemu IP QoS. W dalszych działaniach projektu, sieć ta będzie wykorzystywana do integracji i badania efektywności oprogramowania do dynamicznego zarządzania ruchem w sieciach IP z gwarantowanymi parametrami QoS, opracowywanego przez pozostałe zespoły w ramach projektu pt. Zarządzanie ruchem w sieciach - sieć IP QoS. Budowa takiej sieci, zwanej także TestBedem, wymaga zastosowania zarówno odpowiedniej klasy sprzętu sieciowego (routerów) z wbudowanymi mechanizmami DiffServ i MPLS, jak i użycia właściwego zestawu pomiarowego (generatory i analizatory ruchu IP, aplikacje i serwery usług testowych). Niniejszy raport jest zbiorem wymagań dotyczących zarówno funkcjonalności testbedu jako takiego, jak i tworzących go urządzeń sieciowych i pomiarowych. 2

3 SPIS TREŚCI STRESZCZENIE...2 WPROWADZENIE ARCHITEKTURA SIECI LABORATORYJNEJ SYSTEMU IP QOS WYMAGANIA DOTYCZĄCE MOŻLIWOŚCI FUNKCJONALNYCH SIECI LABORATORYJNEJ SYSTEMU IP QOS WYMAGANIA OGÓLNE WYMAGANIA DOTYCZĄCE PLATFORMY SIECIOWEJ WYMAGANIA DOTYCZĄCE CZĘŚCI POMIAROWEJ WYMAGANIA DOTYCZĄCE URZĄDZEŃ TWORZĄCYCH PLATFORMĘ SIECIOWĄ WYMAGANIA DOTYCZĄCE ROUTERÓW BRZEGOWYCH SIECI LABORATORYJNE WYMAGANIA DOTYCZĄCE ROUTERÓW SZKIELETOWYCH SIECI LABORATORYJNE WYMAGANIA DOTYCZĄCE URZĄDZEŃ TWORZĄCYCH CZĘŚĆ POMIAROWĄ SIECI LABORATORYJNEJ WYMAGANIA DOTYCZĄCE GENERATORÓW RUCHU IP WYMAGANIA DOTYCZĄCE TESTERÓW RUCHU IP WYMAGANIA DOTYCZĄCE SYNCHRONIZACJI URZĄDZEŃ POMIAROWYCH SIECI LABORATORYJNEJ WYMAGANIA DOTYCZĄCE APLIKACJI TESTOWYCH PODSUMOWANIE...15 LISTA SKRÓTÓW...16 LISTA OZNACZEŃ

4 Wprowadzenie W architekturze sieci laboratoryjnej systemu IP QoS wyróżnia się dwie, funkcjonalnie powiązane platformy: sieciową i pomiarową. Platformę sieciową tworzy jedno-domenowa sieć IP QoS o architekturze DiffServ / MPLS. Platforma ta jest utworzona z routerów brzegowych, szkieletowych i przełączników. Platformę pomiarową stanowią zaś stacje robocze z zainstalowanymi aplikacjami klienckimi i serwerowymi usług testowych, generatory ruchu podkładowego oraz testery (analizatory) ruchu IP. W strukturze funkcjonalnej TestBedu jest ona odpowiedzialna za generowanie ruchu testowego oraz podkładowego o regulowanym natężeniu i profilu ruchu, i jako taka jest także wykorzystywana do pomiaru parametrów jakościowych dla ruchu testowego zarówno na poziomie usług transmisji danych (QoS), jak i na poziomie aplikacji (QoE), w warunkach ustawionego ruchu podkładowego. Przedmiotem niniejszego raportu są wymagania, które odnoszą się oddzielnie do każdej z wyżej wymienionych platform TestBedu. W ramach każdej z tych platform formułowane są ogólne wymagania funkcjonalne stawiane platformie jako takiej, a następnie są specyfikowane wymagania szczegółowe dotyczące urządzeń / aplikacji wchodzących w skład danej platformy. Przyjmuje się, że sieć laboratoryjna, zaprojektowana zgodnie z wyspecyfikowanym w ten sposób zbiorem wymagań, w trakcie realizacji projektu będzie służyć: integracji i walidacji oprogramowania tworzonego przez poszczególne grupy robocze projektu oraz badaniu skuteczności projektowanego systemu pod kątem zapewniania ścisłych gwarancji jakości przekazu pakietów dla wybranych aplikacji krytycznych (takich jak: wideo na żądanie, gry sieciowe, wideokonferencja, VoIP, itd.), w warunkach kontrolowanego obciążenia zasobów sieci przez tzw. ruch podkładowy, o regulowanym natężeniu i profilu ruchu. Zakłada się, że po zakończeniu projektu sieć laboratoryjna systemu IP QoS, o rozszerzonej konfiguracji, będzie wykorzystywana do prezentacji osiągnięć projektu małym i dużym operatorom telekomunikacyjnym, pragnącym świadczyć usługi w swoich sieciach IP z absolutną gwarancją jakości świadczenia usług, zarówno na poziomie usług transmisji danych (QoS), jak i na poziomie aplikacji (QoE). 4

5 1 Architektura sieci laboratoryjnej systemu IP QoS Sieć laboratoryjna systemu IP QoS, tworzona w ramach projektu, jest zestawem odpowiednio połączonych urządzeń sieciowych i pomiarowych, umożliwiającym integrację i walidację oprogramowania tworzonego przez poszczególne grupy robocze projektu, a także przeprowadzanie badań skuteczności tego oprogramowania pod kątem zapewniania ścisłych gwarancji jakości przekazu pakietów dla wybranych aplikacji krytycznych (takich jak: wideo na żądanie, gry sieciowe, wideokonferencja, VoIP, itd.), w warunkach kontrolowanego obciążenia zasobów sieci przez tzw. ruch podkładowy pakietów, o regulowanym natężeniu i profilu ruchu. W tak rozumianej sieci laboratoryjnej, zwanej także testbedem, wyróżnia się dwie warstwy. Jedną jest tzw. platforma sieciowa testbedu, zaś drugą część pomiarowa. Platforma sieciowa reprezentuje sobą jedno-domenową sieć IP QoS o architekturze DiffServ/ MPLS, zdolną do obsługi zagregowanych strumieni danych o regulowanych parametrach ruchu, zapewniającą zarówno ścisłe gwarancje jakości przekazu pakietów QoS dla wybranych strumieni ruchu, jak i różnicowanie jakości przekazu pakietów między strumieniami ruchu należącymi do różnych klas ruchu. Utworzona jest ona z odpowiednio skonfigurowanych routerów brzegowych i szkieletowych oraz przełączników umożliwiających dołączenie do niej części pomiarowej testbedu. Część pomiarowa testbedu jest odpowiedzialna za generowanie ruchu testowego oraz podkładowego o regulowanym natężeniu i profilu ruchu, jak również służy do wykonywania pomiarów jakościowych dla ruchu testowego zarówno na poziomie usług transmisji danych (QoS), jak i na poziomie aplikacji (QoE), w warunkach ustalonego ruchu podkładowego. Tworzą ją stacje robocze z zainstalowanymi aplikacjami klienckimi i serwerowymi usług testowych, generator ruchu podkładowego oraz testery (analizatory) ruchu IP. Integracja i walidacja oprogramowania sterującego wywołaniami z gwarantowanym QoS, tworzonego przez poszczególne grupy robocze projektu, będzie dokonywana w wariancie minimalnej konfiguracji testbedu. W konfiguracji tej (rys. 1.1), platforma sieciowa składać się będzie z co najmniej 2 routerów, o architekturze DiffServ. W konfiguracji rozszerzonej (rys. 1.2), stanowiącej funkcjonalny odpowiednik sieci operatorskiej i umożliwiającej przeprowadzanie badań skuteczności utworzonego (w ramach projektu) oprogramowania zapewniającego ścisłe gwarancje jakości przekazu pakietów dla wybranych aplikacji krytycznych, część sieciowa będzie zawierać co najmniej 3-routery w części dostępowej oraz 3-routery w części szkieletowej z architekturą DiffServ. Rozważana jest również w trakcie trwania projektu realizacja badań w modelowej sieci operatorskiej z zaimplementowaną architekturą MPLS. W takim przypadku zarówno routery w części dostępowej jak i szkieletowej powinny wspierać architekturę MPLS. 5

6 Sterowanie dostępem Zarządzanie elementami sieci Proxy Klient aplikacji testowej Serwer aplikacji testowej Analizator ruchu Generator ruchu tłowego Rysunek 1-1. Konfiguracja minimalna testbedu Sterowanie dostępem Zarządzanie elementami sieci Proxy Klient aplikacji testowej SIEĆ SZKIELETOWA SIEĆ DOSTĘPOWA Serwer aplikacji testowej Analizator ruchu Generator ruchu Rysunek 1-2. Konfiguracja rozszerzona testbedu 6

7 2 Wymagania dotyczące możliwości funkcjonalnych sieci laboratoryjnej systemu IP QoS 2.1 Wymagania ogólne Wymaganie Sieć laboratoryjna powinna umożliwiać integrację oraz, przeprowadzanie badań zgodności implementacji oprogramowania tworzonego przez poszczególne grupy robocze projektu. Wymaganie Sieć laboratoryjna powinna umożliwiać przeprowadzanie badań efektywności projektowanego systemu IP QoS pod kątem zapewniania ścisłych gwarancji jakości przekazu pakietów przenoszonych w ramach projektowanych klas usług (takich jak: wideo na żądanie, gry sieciowe, wideokonferencja, VoIP, itd.), w warunkach kontrolowanego obciążenia sieci Wymagania dotyczące platformy sieciowej Pod pojęciem platformy sieciowej sieci laboratoryjnej rozumie się tu zespół odpowiednio połączonych routerów brzegowych i szkieletowych, przełączników oraz terminali i serwerów sterujących, który to zespół odzwierciedla (pod względem funkcjonalnym) jedno-domenową sieć IP QoS o architekturze DiffServ / MPLS. W odniesieniu do tak rozumianej platformy sieciowej testbedu wymaga się w szczególności, co następuje: Wymaganie Platforma sieciowa powinna umożliwiać zainstalowanie i przeprowadzenie badań projektowanego systemu IP QoS Wymaganie Platforma sieciowa powinna umożliwiać zastosowanie mechanizmów profilowania ruchu i szeregowania pakietów wymaganych przez projektowany system IP QoS oraz ich zdalną konfigurację Wymaganie Platforma sieciowa powinna umożliwiać zarówno implementację wypracowanych w ramach projektu mechanizmów przyjmowania / odrzucania nowych wywołań, Wymaganie Platforma sieciowa powinna umożliwiać przeprowadzenie badań usług sieciowych oferowanych przez projektowany system IP QoS Wymaganie Platforma sieciowa powinna umożliwiać implementacje wypracowanych w ramach projektu protokołów rutingu. Wymaganie Platforma sieciowa powinna umożliwiać implementację wypracowanych w ramach projektu mechanizmów zarządzania zasobami sieci, jak i zdalnego sterowania tymi mechanizmami. Wymaganie Platforma sieciowa powinna umożliwiać zainstalowanie i przebadanie systemu sygnalizacji zastosowanego w projektowanym systemie. Wymaganie Platforma sieciowa powinna umożliwiać zainstalowanie i przebadanie aplikacji zastosowanych w projektowanym systemie. 7

8 2.3 Wymagania dotyczące części pomiarowej Pod pojęciem części pomiarowej sieci laboratoryjnej rozumie się tu zespół urządzeń, takich jak: stacje robocze z zainstalowanymi aplikacjami klienckimi i serwerowymi usług krytycznych (wideo na żądanie, gry sieciowe, wideokonferencja, VoIP, itd.), a także generatory i analizatory ruchu IP. Urządzenia te odpowiednio dołączone do routerów brzegowych platformy sieciowej testbedu powinny umożliwiać kontrolowane obciążanie zasobów tej platformy, a także pomiar parametrów QoS metodami obiektywnymi i/lub subiektywnymi dla wymienionych aplikacji krytycznych. W odniesieniu do tak rozumianej części pomiarowej tesbedu wymaga się w szczególności, co następuje: Wymaganie Część pomiarowa sieci powinna umożliwiać generowanie i analizowanie ruchu testowego odpowiadającego ruchowi generowanemu przez aplikacje zastosowane w systemie IP QoS, takich jak: wideo na żądanie, gry sieciowe, wideokonferencja, VoIP. Wymaganie Część pomiarowa testbedu powinna umożliwiać generowanie ruchu podkładowego o profilach odpowiadających pojedynczym jak i zagregowanym strumieniom ruchu przenoszonym w ramach projektowanych klas usług Wymaganie Część pomiarowa sieci powinna umożliwiać obiektywny pomiar parametrów jakościowych QoS związanych z poszczególnymi klasami usług, takich jak: poziom start pakietów IPLR (IP Packet Loss Rate), opóźnienie przekazu pakietów - IPTD (IP Packet Transfer Delay), zmienność opóźnienia przekazu pakietów - IPDV (IP Packet Delay Variation) oraz przepływność bitowa osiągana przez pojedyncze połączenie TCP - BTC (Bulk Transfer Capacity). Wymaganie Opcjonalnie część pomiarowa sieci powinna umożliwiać pomiar metryk związanych z wydajnością systemu sygnalizacji. Wymaganie Opcjonalnie część pomiarowa sieci powinna umożliwiać pomiar metryk związanych z rekonfiguracją ścieżek oraz zasobów w pojedynczym węźle jak i w całej sieci. Wymaganie Część pomiarowa sieci powinna umożliwiać zdalny odczyt konfiguracji urządzeń. Wymaganie W przypadku pomiaru charakterystyk opóźnienia, część pomiarowa sieci powinna zapewniać odpowiednią synchronizację czasu urządzeń pomiarowych. Wymaganie Część pomiarowa sieci powinna umożliwiać zarówno zdalną konfigurację urządzeń pomiarowych, jak i zdalny odczyt wyników pomiarów. 8

9 3 Wymagania dotyczące urządzeń tworzących platformę sieciową 3.1 Wymagania dotyczące routerów brzegowych sieci laboratoryjne Routery brzegowe umieszczone są w końcowych węzłach sieci szkieletowej. Routery te połączone są z jednym bądź kilkoma routerami w sieci szkieletowej, generatorem ruchu podkładowego i testowego oraz urządzeniami pomiarowymi IP i serwerami sterowania. Z uwagi na fakt, iż koncepcja systemu uwzględnia konieczność dynamicznej konfiguracji parametrów QoS routerów brzegowych konieczne jest, aby wspierały one mechanizmy architektury DiffServ obejmujące: klasyfikację i oznaczanie pakietów, kształtowanie profilu i nadzorowanie kontraktu oraz kolejkowanie pakietów, a także opcjonalnie mechanizmy zapobiegania przeciążeniom,. W odniesieniu do routerów tworzących tę część sieci laboratoryjnej wymaga się w szczególności, co następuje: Wymaganie Routery brzegowe powinny być wyposażone w interfejsy typu Ethernet o minimalnej przepływności 100Mbit/s. Wymaganie Routery brzegowe powinny posiadać co najmniej 2 interfejsy typu Ethernet. Wymaganie Routery brzegowe powinny zapewniać klasyfikację typu MF na podstawie: adresów źródłowych i docelowych, protokołów, portów TCP/UDP oraz interfejsów wejściowych. Wymaganie Routery brzegowe powinny umożliwiać klasyfikację typu BA na podstawie następujących pól: IP Precedence Field, dscp_ipv4, dscp_ipv6,mpls-exp, ieee-802.1p. Wymaganie Routery brzegowe powinny zapewniać funkcjonalność oznaczania pakietów za pomocą przypisania kodów dscp, IP Precedence Field oraz MPLS Exp Wymaganie Routery brzegowe powinny umożliwiać kolejkowanie pakietów w oparciu o różnicowanie klas z użyciem mechanizmów typu CBWFQ oraz LLQ. Wymaganie Routery brzegowe powinny mieć możliwość utworzenia co najmniej 4 kolejek. Wymaganie Routery brzegowe powinny umożliwiać implementację algorytmu RED lub WRED, z możliwością konfiguracji minimalnej i maksymalnej zajętość kolejki oraz prawdopodobieństwo usunięcia pakietu z kolejki. Wymaganie Routery brzegowe powinny umożliwiać wspieranie funkcjonalności kształtowania ruchu wychodzącego IP (Traffic Shaping) oraz nadzorowanie kontraktu ruchowego (Traffic Policing) zarówno dla ruchu wejściowego, jak i wyjściowego. Wymaganie Routery brzegowe powinny umożliwiać obsługę następujących protokołów routingu : BGP, OSPF, RIP. Wymaganie Jeśli wymagana jest obsługa MPLS, routery brzegowe powinny posiadać funkcjonalność MPLS-TE z możliwościami: tworzenia ścieżek MPLS (przypisywanie etykiet, zmiana etykiet, zdejmowanie etykiet, protokoły LDP i RSVP-TE), wspierania mechanizmu Diffserv (moż- 9

10 liwość konwersji kodów dscp na mpls-exp), przypisywania klasy ruchu dla każdej ścieżki MPLS (L-LSP). Wymaganie Routery brzegowe powinny umożliwiać zdalną konfiguracje z wykorzystaniem dowolnego z następujących protokołów komunikacyjnych: SNMP (wraz z bazami MIB obejmującymi parametry odpowiedzialne za QoS), Telnet, SSH. 3.2 Wymagania dotyczące routerów szkieletowych sieci laboratoryjne W architekturze projektowanej sieci laboratoryjnej routery szkieletowe tworzą sieć WAN, i jako takie są połączone z: routerem brzegowym, innymi routerami sieci szkieletowej, a także z komputerem realizującymi system sterowania zasobami. Z uwagi na konieczność odzwierciedlenia operatorskiej sieci szkieletowej konieczne jest zatem zastosowanie routerów szkieletowych posiadających możliwość konfiguracji parametrów QoS (mechanizmów klasyfikacji oraz kolejkowania pakietów), a także wspierających funkcjonalność MPLS. W szczególności powinny one spełniać następujące wymagania: Wymaganie Routery szkieletowe powinny być wyposażone w interfejsy typu Ethernet o minimalnej przepływności 100Mbit/s. Wymaganie Routery szkieletowe powinny posiadać co najmniej 5 interfejsów typu Ethernet. Wymaganie Routery szkieletowe powinny umożliwiać klasyfikację typu BA na podstawie następujących pól: IP Precedence Field, dscp_ipv4, dscp_ipv6,mpls-exp, ieee-802.1p. Wymaganie Routery szkieletowe powinny umożliwiać kolejkowanie pakietów w oparciu o różnicowanie klas, z użyciem mechanizmu typu MDRR. Wymaganie Routery brzegowe powinny mieć możliwość utworzenia co najmniej 4 kolejek obsługiwanych przez mechanizmy MDRR. Wymaganie Routery szkieletowe powinny umożliwiać implementację algorytmu RED lub WRED, z możliwością konfiguracji minimalnej i maksymalnej zajętość kolejki oraz prawdopodobieństwa usunięcia pakietu z kolejki. Wymaganie Opcjonalnie routery szkieletowe powinny umożliwiać wspieranie funkcjonalności kształtowania ruchu wychodzącego IP (Traffic Shaping) oraz nadzorowanie kontraktu ruchowego (Traffic Policing) zarówno dla ruchu wejściowego, jak i wyjściowego. Wymaganie Routery szkieletowe powinny umożliwiać obsługę następujących protokołów routingu dynamicznego: BGP, OSPF, RIP. Wymaganie Jeśli wymagana jest obsługa MPLS, routery szkieletowe powinny posiadać funkcjonalność MPLS-TE z możliwościami: tworzenia ścieżek MPLS (przypisywanie etykiet, zmiana etykiet, zdejmowanie etykiet, protokoły LDP i RSVP-TE), wspierania mechanizmu Diffserv (możliwość konwersacji kodów dscp na mpls-exp), przypisywania klasy ruchu dla każdej ścieżki MPLS (L-LSP) oraz protokołów konfiguracji ścieżek typu RSVP-TE, LDP 10

11 Wymaganie Routery szkieletowe powinny umożliwiać zdalną komunikację z systemem sterowania z wykorzystaniem dowolnego z następujących protokołów komunikacyjnych: SNMP (wraz z bazami MIB obejmującymi parametry odpowiedzialne za QoS), Telnet, SSH. 11

12 4 Wymagania dotyczące urządzeń tworzących część pomiarową sieci laboratoryjnej 4.1 Wymagania dotyczące generatorów ruchu IP Ogólnie rzecz biorąc, generator ruchu IP jest urządzeniem umożliwiającym generowanie strumieni ruchu IP o zadanym profilu. W architekturze sieci laboratoryjnej, generatory te będą odpowiedzialne za wysyłanie ruchu podkładowego, emulującego ruch rzeczywisty wytwarzany przez aplikacje użytkowe. W odniesieniu do tak rozumianych urządzeń wymaga się w szczególności, co następuje: Wymaganie Generatory ruchu IP powinny być wyposażone przynajmniej w jeden interfejs sieciowy typu Ethernet, umożliwiający ich proste dołączanie do sieci testowanej. Wymaganie Generatory ruchu IP powinny umożliwiać generowanie ruchu o minimalnej łącznej przepływności 4 Mb/s, dla minimum 256-niezależnych strumieni danych. Wymaganie Generatory ruchu IP powinny umożliwiać obsługę, co najmniej następującej grupy protokołów: TCP, UDP, IPv4, IPv6. Wymaganie Generatory ruchu powinny umożliwiać co najmniej generowanie: ruchu o stałej szybkości CBR (od ang. Constant Bit Rate), definiowany przez odstęp między pakietami i długość pakietu; ruch o zmiennej szybkości VBR (od ang. Variable Bit Rate), określany przez przedział czasu, w jakim będzie zawierać się losowe opóźnienie pomiędzy kolejnymi pakietami oraz przedział określający rozmiar generowanego pakietu. Ruch o zmienne Wymaganie Generatory ruchu IP powinny umożliwiać generowanie błędów w polu CRC wytwarzanych pakietów. Wymaganie Generatory ruchu IP powinny umożliwiać indywidualnego definiowanie adresów MAC/IP (źródłowego i docelowego) dla wybranych pakietów. 4.2 Wymagania dotyczące testerów ruchu IP Tester ruchu IP jest urządzeniem umożliwiającym monitorowanie i przechwytywanie ruchu sieci IP, a także analizę stanu połączenia w zakresie pomiaru zarówno przepływności binarnej łącza, jak i wyznaczania parametrów jakościowych QoS, takich jak: opóźnienie pakietów, zmienność opóźnienia pakietów, stopień pakietów utraconych. W architekturze sieci laboratoryjne, testery te będą wykorzystywane do pomiaru parametrów QoS dla aplikacji testowych, i jako takie powinny spełniać następujący zbiór wymagań: Wymaganie Testery /analizatory ruchu IP powinny być wyposażone przynajmniej w jeden interfejs sieciowy typu Ethernet, umożliwiający ich proste dołączanie do sieci testowanej. 12

13 Wymaganie Testery ruchu IP powinny umożliwiać przechwytywanie całościowego ruchu z wybranych interfejsów fizycznych oraz umożliwiać przechwytywanie wybranych pakietów, definiowanych przez użytkownika za pomocą: typu nagłówka, adresu MAC/IP, długości nagłówka, długości pakietu. Wymaganie Testery ruchu IP powinny umożliwiać obsługę, co najmniej następującej grupy protokołów: IPv4, IPv6, MPLS. Wymaganie Testery ruchu IP powinny umożliwiać zliczanie przechwyconych pakietów (całościowe lub wybranych według zdefiniowanego filtru). Wymaganie Testery ruchu IP powinny umożliwiać zliczanie utraconych pakietów. Wymaganie Testery ruchu IP powinny umożliwiać pomiar opóźnienia przekazu pakietów Wymaganie Testery ruchu IP powinny umożliwiać detekcję błędów: CRC, spójności pakietu, błędów nagłówka IP oraz rozmiaru pakietu (Undersize, Oversize). 4.3 Wymagania dotyczące synchronizacji urządzeń pomiarowych sieci laboratoryjnej Synchronizacja urządzeń pomiarowych sieci laboratoryjne ma na celu umożliwienie pomiaru opóźnienia pakietów w połączeniu typu punkt-punkt. Z uwagi na to, generatory i testery ruchu IP powinny dodatkowo spełniać następujące wymagania: Wymaganie Generatory i testery ruchu IP powinny być wyposażone w interfejsy i mechanizmy umożliwiające doprowadzenie do nich zewnętrznego sygnału synchronizującego. Wymaganie Generatory i testery ruchu IP powinny być przystosowane do synchronizacji zewnętrznym sygnałem zegarowym z odbiornika GPS 1 PPS (ang. Pulse Per Second). 4.4 Wymagania dotyczące aplikacji testowych Przewiduje się aplikacje testowe do testowania usług: telefonia internetowa (VoIP), wideostreaming, gra interaktywna. Wymaganie Do testowania usługi telefonii internetowej (VoIP) powinna służyć aplikacja typu telefon software owy (softphone) działająca w środowisku MS Windows XP/Vista, spełniająca następujące warunki: możliwość wyboru kodeka audio spośród najpopularniejszych kodeków pracujących w systemach VoIP (ilbc, Speex, GSM-FR, G.711, G.723.1, G.728, G.729 itp.); wspieranie protokołu SIP 2.0; 13

14 możliwość wyłączenia algorytmów regeneracji pakietów (algorytmy PLC packet loss concealment) i układu usuwania echa (EC echo cancellation); możliwość pracy w trybie punkt-punkt; ewent. możliwość sterowania długością bufora kompensującego jitter. Wymaganie Stacje robocze, na których będą zainstalowane telefony software owe, powinny mieć zainstalowane oprogramowanie, umożliwiające przesyłanie przez system VoIP wybranych plików dźwiękowych, a także rejestrowanie (bez kompresji) do pliku odebranego sygnału mowy (o ile takiej funkcji nie posiada sam softphone). Wymaganie Testowanie usługi transmisji strumieniowej wideo powinno się odbywać z wykorzystaniem architektury klient-serwer. W skład środowiska testowego powinien wchodzić serwer wideo oraz terminale klienckie, zainstalowane na stacjach roboczych. Wymagana obsługa kodeków wideo: H.261, H.263, MPEG-1, MPEG-2 (DVD), MPEG-4-2, MPEG-4-10 (czyli H.264 AVC) Wymaganie Stacje robocze, na których będą zainstalowane terminale klienckie wideo, powinny mieć zainstalowane oprogramowanie, umożliwiające rejestrowanie do pliku odebranego sygnału wideo wraz z dźwiękiem, np. w formacie.avi. Wymaganie Testowanie usługi gra interaktywna powinno się odbywać w trybie punktpunkt. Środowisko testowe powinno zawierać 2 stacje robocze z uruchomionymi aplikacjami gier. Oba komputery muszą mieć możliwość rejestracji sesji gry w formie pliku wideo wraz z dokładną informacją czasową, do celów późniejszej analizy. 14

15 5 Podsumowanie W dokumencie przedstawiono zbiór wymagań dotyczących sieci laboratoryjnej systemu IP QoS, która będzie wykorzystywana zarówno do integracji oprogramowania opracowywanego w ramach projektu oraz do testowania efektywności systemu. Wymagania te odnoszą się zarówno do funkcjonalności testbedu jako takiego, jak i do tworzących go urządzeń sieciowych i pomiarowych. W szczególności zdefiniowano tu wymagania na podstawowe parametry techniczne routerów brzegowych i szkieletowych tej sieci, a także wymagania na urządzenia pomiarowe i aplikacje testowe, tworzące platformę pomiarową testbedu. Tak zdefiniowany pakiet wymagań będzie podstawą do opracowania dokumentów, niezbędnych do organizacji przetargu na zakup tych urządzeń, w drugim etapie realizacji projektu 15

16 Lista skrótów BA BGP CBR CBWFQ DSCP EXP GPS IP LSP MAC MDRR MIB MF MPLS OSPF PPS RED RIP QoS SNMP SSH TCP UDP VBR Behaviour Aggregate Border Gateway Protocol Constant Bit Rate Class Based Weighted Fair Queuing Differentiated Services Code Point Experimental Bit Global Positioning System Internet Protocol Label Switched Path Media Access Control Modified Deficit Round Robin Management Information Base Multi Field Multiprotocol Label Switching Open Shortest Path First Pulse Per Second Random Early Detection Routing Information Protocol Quality of Service Simple Network Management Protocol Secure Shell Transmission Control Protocol User Datagram Protocol Variable Bit Rate 16

17 VoIP WAN WRED Voice over IP Wide Area Network Weighted Random Early Detection 17

18 Lista oznaczeń DiffServ Differentiated Services 18