W czasie implementacji nie napotkano krytycznych problemów. Wszystkie węzły spełniają załoŝone wymagania oraz realizują załoŝoną funkcjonalność.
|
|
- Bożena Sawicka
- 9 lat temu
- Przeglądów:
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/WUT/D.2 Tytuł raportu: Implementacja warstwy zarządzania zasobami - część II Przewidywany termin dostarczenia raportu: 31/12/2009 Rzeczywisty termin dostarczenia raportu: 15/01/2010 Kierownik zadania: Wykonawcy: Wojciech Burakowski Sylwester Kaczmarek, Marcin Narloch, Piotr Pyda, Tomasz Dalecki, Jarosław Śliwiński, Witold Góralski, Andrzej Bęben, Halina Tarasiuk, Piotr Krawiec Abstrakt: Raport przedstawia stan implementacji systemu IP QoS na koniec etapu D projektu i dotyczy warstwy zarządzania zasobami. W raporcie opisano aktualny stopień realizacji poszczególnych węzłów i serwerów, w tym definicje interfejsów w języku SLICE, implementację oraz wymagania związane z wdroŝeniem wytworzonego oprogramowania. Ponadto w raporcie znajdują się równieŝ opisy konfiguracji i uruchamiania poszczególnych elementów oprogramowania. Słowa kluczowe: DiffServ, NGN, RACF, zarządzanie zasobami, wymiarowanie sieci
2 Streszczenie Raport przedstawia stan implementacji IP QoS na zakończenie etapu D projektu i dotyczy warstwy zarządzania zasobami. Opis implementacji dotyczy ostatecznego stanu całego oprogramowania (w tym oprogramowania, które powstało w etapie C) i zawiera: definicję interfejsów w języku SLICE, stan implementacji na koniec etapu D, wymagania związane z zastosowanymi narzędziami programistycznymi, sposób konfiguracji poszczególnych węzłów lub serwerów, sposób uruchamiania poszczególnych węzłów lub serwerów. PowyŜszy opis dotyczy: węzła RMS (Resource Management Subsystem), węzła ROMAN (Routing Management), węzła PD-PE (Policy Decision Physical Entity), węzła TRC-PE (Transport Resource Control Physical Entity), węzła PE-PE (Policy Enforcement Physical Entity) serwera konfiguracyjnego systemu. W czasie implementacji nie napotkano krytycznych problemów. Wszystkie węzły spełniają załoŝone wymagania oraz realizują załoŝoną funkcjonalność. SPIS TREŚCISTRESZCZENIE... 2 SPIS TREŚCI ARCHITEKTURA SYSTEMU ZAŁOśENIA SYSTEMU PODZIAŁ FUNKCJONALNY SYSTEMU PROCESY WARSTWY ZARZĄDZANIA ZASOBAMI STAN IMPLEMENTACJI WĘZŁÓW SYSTEMU WĘZEŁ RMS (RESOURCE MANAGEMENT SUBSYSTEM) WĘZEŁ ROMAN (ROUTING MANAGER)
3 2.3 WĘZEŁ PD-PE (POLICY DECISION PHYSICAL ENTITY) WĘZEŁ TRC-PE (TRANSPORT RESOURCE CONTROL PHYSICAL ENTITY) WEZEL PE-PE (POLICY ENFORCEMENT PHYSICAL ENTITY) SERWER KONFIGURACYJNY SYSTEMU KOLEJNOŚĆ URUCHAMIANIA WĘZŁÓW SYSTEMU PODSUMOWANIE LITERATURA LISTA SKRÓTÓW ZAŁĄCZNIK A: DEFINICJA INTERFEJSÓW W JĘZYKU SLICE
4 1 Architektura systemu 1.1 ZałoŜenia systemu Rysunek 1-1 przedstawia podstawowy scenariusz działania systemu. WyróŜniamy w nim uŝytkowników, którzy są dołączeni do ruterów brzegowych. UŜytkownik uzyskuje dostęp do zasobów sieci za pomocą aplikacji, która komunikuje się z serwerami aplikacji (oferowanymi przez dostawcę usługi). Serwery aplikacji wysyłają Ŝądanie przygotowania zasobów sieciowych zgodnie z wymaganiami, które są zawarte w Ŝądaniu wysyłanym przez aplikację. Serwery zarządzania zasobami (nale- Ŝą do operatora) odpowiadają za zarządzanie zasobami sieci, tak, aby dla wybranych klas usług wprowadzić ścisłe gwarancje jakości przekazu w sieci od końca do końca. Ponadto zgodnie z zało- Ŝeniami architektury DiffServ [RFC2475], sieć składa się z ruterów brzegowych oraz ruterów szkieletowych (rutery szkieletowe nie zostały przedstawione na rysunku). Serwer aplikacji (dostawca usług) Serwery zarządzania zasobami (operatora) UŜytkownik A Aplikacja UŜytkownik B Aplikacja A Ruter brzegowy B Ruter brzegowy Rysunek 1-1: Podstawowy scenariusz działania systemu Ze względu na skalę czasu, wyróŝnia się dwie grupy procesów realizowanych w systemie: Procesy związane z obsługą wywołań skala sekund lub minut, Procesy związane z zarządzaniem zasobami skala godzin lub dni. W raporcie tym opisuje się implementację węzłów i interfejsów dla procesów drugiego rodzaju, czyli procesów związanych z zarządzaniem zasobami. 1.2 Podział funkcjonalny systemu Rysunek 1-2 przedstawia podział funkcjonalności systemu, zgodnie ze specyfikacją przedstawioną w [B1], na poszczególne węzły funkcjonalne wraz z interfejsami występujące pomiędzy poszczególnymi węzłami. Skierowanie strzałek oznacza jedynie kierunek, w którym wywołanie jest inicjalizowane. Wywołania te mogą otrzymywać wynik opisujący rezultat działania, tak więc wymiana wiadomości sygnalizacyjnych jest obustronna. Definicja w języku SLICE dla interfejsów rozwaŝanych w tym raporcie znajduje się w Załączniku A. 4
5 RomanToRms RmsToRoman RmsToPd PdToRms RomanToPd PdToSce SceToPd PdToTrc TrcToPd PdToPe Rysunek 1-2: Elementy funkcjonalne systemu wraz z interfejsami Raport ten dotyczy wyłącznie procesów związanych z obsługą wywołań. Z tego względu nie zostały opisane w nim węzeł funkcjonalny SCE oraz strona aplikacji, które biorą udział wyłącznie w procesach związanych z obsługą wywołań (procesy te zostały opisane w raporcie D.1). Dodatkowym elementem systemu, który został wprowadzony w celu usprawnienia procesu konfiguracji oprogramowania, jest serwer konfiguracyjny. Serwer ten umoŝliwia automatyczną konfigurację węzłów (wraz z lokalizacją) i przez to upraszcza część oprogramowania związaną z uruchomieniem wstępnym kaŝdego węzła. 1.3 Procesy warstwy zarządzania zasobami Warstwa zarządzania zasobami realizuje następujące procesy: Proces ustalenia rutingu w domenie jest wykonywany w module ROMAN. W procesie ustalona jest ścieŝka MPLS między kaŝdym wejściowym i wyjściowym ruterem brzegowym. W opisywanym rozwiązaniu cały ruch naleŝący do róŝnych klas usług przesyłany jest tą samą ścieŝką (MPLS) między ruterami brzegowymi. Przydzielanie zasobów dla róŝnych klas usług realizowane jest w module RMS. Moduł ten przydziela odpowiednie pasmo wszystkim klasom usług w danej ścieŝce (MPLS). Dodatkowo przydziela odpowiednie pasmo dla ścieŝek MPLS przechodzących przez dane łącze. Rozmiary buforów ustawiane są odpowiednio dla poszczególnych klas kaŝdego portu wyjściowego rutera (port przez który przebiega co najmniej jedna ścieŝka). Wyniki uzyskane z algorytmu przydzielania zasobów wykorzystywane są do konfigurowania interfejsów wyjściowych ruterów naleŝących do domeny (wyliczenie rozmiarów buforów). Dodatkowo wyliczone wartości wykorzystywane są w algorytmie przyjmowania nowych wywołań w odrębnym module. 5
6 Do opisu algorytmu zastosowano następujące oznaczenia: l=1..l, numer łączy (L liczba łączy), s=1..s, numer ścieŝki (S liczba ścieŝek), k=1..k, numer klasy usług (K liczba klas usług), C l przepustowość łączy l, δ ls = 1 kiedy ścieŝka s zawiera łączę l, inaczej δ ls =0, M[k,s] macierz zapotrzebowań, opisująca zapotrzebowanie ruchu klasy k dla ścieŝki s. W szczególności, algorytm przydzielenia zasobów dla klas usług polega na przeliczeniu macierzy zapotrzebowań od wejściowej macierzy relatywnej (zapotrzebowania wyraŝone w procentach) do absolutnej macierzy zainteresowań opisującej dokładną przepustowość dla kaŝdej ścieŝki i klasy usług. Na wejściowej macierzy zapotrzebowań dane są zapotrzebowania procentowe dla róŝnych klas dla danej ścieŝki. W ogólnym przypadku dla wszystkich klas i ścieŝek zapotrzebowania są takie same (elementy wejściowej macierzy równą się 1). Po uruchomieniu algorytmu, wyjściowa macierz zapotrzebowań zawiera wartości przepustowości dla kaŝdej ścieŝki i kaŝdej klasy ruchu. Wtedy, moŝna obliczyć wartości przepustowości C kl do skonfigurowania na wyjściowym interfejsie rutera łącza l dla ruchu klasy k przez następującą formułę: C kl = M[ k, s] s δ ls Dane wejściowe związane z topologią sieci i rutingiem (rozmieszczenie ścieŝek) przekazywane są z modułu ROMAN do modułu RMS. Konfiguracja wymogów QoS przechowywana jest w pliku qos.txt, natomiast wartości zapotrzebowań zapisane są w pliku demands.txt. Rysunek 1-3 pokazuje algorytm przedzielenia pasma dla poszczególnych ścieŝek i klas ruchu. 6
7 Start fac=? l_=1 M*[l_]=0 k_=1 l_=1 C[l_,k_]=0 s_=1 s_=1 δ l_s_ =1? TAK k_=1 NIE s_++ δ l_s_ =1? NIE TAK C[l_,k_]= C[l_,k_]+M[k_,s_] s_++ M*[l_]= M*[l_]+M[k_,s_] s_=s? NIE s_++ k_=k? s_=s? l_=l? TAK TAK C l_/m*[l_]<fac _? TAK fac= C l_/m*[l_] NIE NIE NIE k_++ s_++ NIE l_++ l_=l? TAK TAK k_=k? l_=1 TAK Σ CoS C[l_,k_]>C l_? TAK s_=1 NIE NIE l_++ k_++ l_++ NIE l_=l? TAK KONIEC NIE TAK M[k_,s_]= M[k_,s_] fac δ l_s_ =1? NIE s_++ TAK k_=1 M[k_,s_]=M[k_,s_] C l_/ Σ CoSC[l_,k_] k_=k? TAK NIE k_++ Rysunek 1-3: Algorytm przedzielenia pasma. L liczba łączy, S liczba ścieŝek, K liczba klas, C l przepustowość łączy l, M[k,s] macierz zapotrzebowań, pozostałe zmienne losowe pomocnicze Po obliczeniu wartości pasma dla poszczególnych klas usług rozpatrujemy rozmiar buforów dla danych klas. Następnie przedstawiono potrzebne rozmiary buforów dla kaŝdej klasy usług. Długość bufora przydzielona dla kaŝdej klasy zaleŝy od moŝliwości szeregowania w ruterach. Na przykład, do niedawna rutery CISCO pozwalały pracować z maksymalnym całkowitym rozmiarem kolejki o 7
8 długości 64 pakietów (dla wszystkich klas). Podsumowując przedstawione w dalszej części rozmiary buforów są tylko wartościami względnymi uwzględniającymi maksymalny rozmiar kolejki (moŝliwości szeregowania ruterów). Klasa Signalling: Wymiarowanie zasobów dla ruchu sygnalizacyjnego jest dość skomplikowane. Najnowsze badania [Mong09] pokazały, iŝ pojedyncza procedura zestawienia połączenia w przykładowej architekturze sieci Następnej Generacji potrzebuję przynajmniej 30 [kbps]. Jeśli mamy zarezerwowane pasmo C SIG dla ruchu sygnalizacyjnego, wtedy moŝemy dopuścić do systemu maksymalnie C SIG /30 procedur zestawienia połączenia. Jedna procedura zestawienia połączenia wysyła jednocześnie do sieci N wiadomości, gdzie N jest liczba Physical Entities w systemie według referencji [B1] rozdział 3.1. Zestawienie połączenia. Dlatego rozmiar bufora dla klasy Signalling moŝemy liczyć według następującego wzoru: B CSIG [ kbps] = 30 [ kbps] SIG N [ packets] Klasa RT Interactive: Obliczanie rozmiaru bufora dla tej klasy musi uwzględniać maksymalną wartość zmiany opóźnienia (IPDV) według następującego wzoru: IPDV RT B [ s] = RT d RT [ Bytes / packet] 8 hop C RT [ kbps] gdzie: d RT - największa długość pakietów wszystkich strumień RT, hop - liczbą skoków dla najdłuŝszej ścieŝki, B RT - długość bufora dla tej klasy, C RT - podzielonym pasmem dla klasy RT. Klasy usług MM Streaming oraz HTD wymagają małych strat pakietów [B2]. Dlatego rozmiar bufora powinien być wystarczająco duŝy, aby zminimalizować liczbę odrzuconych pakietów naleŝących do tych klas usług. Z drugiej strony, wymaganie na opóźnienie (IPTD) jest 0.5 [s] dla opóźnienia od końca do końca [B2] podczas, gdy nie ma wymagań dla zmienności opóźnienia. Dla klas usług MM Streaming i HTD wymiarowanie bufora na podstawie wartości opóźnienia nie jest realizowane. Dlatego opóźnienie zaleŝy od obciąŝenia (ρ) podobnie jak poziom strat pakietów. Jedynie, moŝna obliczyć rozmiar bufora dla maksymalnego opóźnienia. Przypadek ten będzie miał miejsce, gdy bufor jest zawsze pełny (ρ 1). Wtedy bufor moŝna obliczyć według następującego wzoru: gdzie: IPTD MMS / HTD ( B [ s] = MMS / HTD + 1) d C MMS / HTD MMS / HTD [ Bytes / packet] 8 hop [ kbps] 8
9 d MMS/HTD - największa długość pakietów wszystkich strumień MMS lub HTD, hop - liczbą skoków dla najdłuŝszej ścieŝki, B MMS/HTD - długość bufora dla klasy MMS lub HTD, C MMS/HTD - podzielonym pasmem dla klasy MMS lub HTD. Dla powyŝszych wartości długości bufora na podstawie IPTD jest przewymiarowana (normalnie ρ<1). Jeśli wyliczony rozmiar bufora okazuje się zbyt mały (to będzie znaczyło zbyt duŝe przewymiarowanie), wtedy wybieramy większy rozmiar bufora w naszej implementacji, około 100 pakietów jako wartość minimalna. PoniŜsza tabela krótko podsumowuje wzory wykorzystane w implementacji do obliczania rozmiarów buforów dla poszczególnych klas usług. Dane potrzebne do wyliczenia rozmiarów buforów znajdują się w pliku qos.txt jako część modułu RMS. Tabela 1-1: Zdefiniowane klasy usług - stan implementacji systemu (etap D) dla modułu zarządzania zasobami(moduł RMS) Klasa usług Formuła Wartości Signalling CSIG [ kbps] BSIG = N [ packets] 50 [ kbps] C SIG przepustowość (plik) N liczba Physical Entities w systemie (wartość ustalona) RT Interactive B RT = IPDVRT [ s] CRT [ kbps] IPDV Tel wartość zmiany opóźnienia d RT [ Bytes / packet] 8 hop (plik) C Tel przepustowość (plik) d RT długość pakietu (plik) hop hopów na najdłuższej ścieżce IPTDMMS CMMS IPTD MM Streaming BMMS = max 1, 100 packets} MMS wartość opóźnienia (plik) dmms 8 hop C MMS przepustowość (plik) D MMS długość pakietu (plik) hop hopów na najdłuższej ścieżce IPTDHTD CHTD IPTD HTD BHTD = max 1, 100packets} HTD wartość opóźnienia (plik) d HTD 8 hop C HTD przepustowość (plik) D HTD długość pakietu (plik) hop hopów na najdłuższej ścieżce 9
10 2 Stan implementacji węzłów systemu 2.1 Węzeł RMS (Resource Management Subsystem) Węzeł RMS odpowiada za realizację algorytmu wymiarowania zasobów dla łączy w zaleŝności od dostępnych zasobów i rozpływu ruchu w domenie (rutingu) oraz algorytmu odpowiadającego za realokację zasobów. Realizacja tych zadań wymaga komunikacji z węzłem ROMAN oraz z węzłem PD-PE. W pierwszym etapie realizowana jest wersja uproszczona, która dokonuje statycznej alokacji zasobów. Podstawowym zadaniem węzła RMS jest określenie dla ruterów brzegowych (ER) przydzielonej pojemności dla kaŝdej klasy usług sieciowych w domenie. Pojemność ta jest wykorzystywana przez funkcję AC realizowaną w ruterach brzegowych. Ponad to węzeł RMS oblicza dla kaŝdego portu pojemności buforów dla poszczególnych klas usług zgodnie z raportem [B.2-6] Opis działania interfejsów oferowanych przez węzeł Podczas działania modułu RMS za pomocą metody topologyhaschanged() odbierane są zdarzenia od modułu ROMAN informujące o zmianie topologii sieciowej. Sama metoda nie przenosi struktur danych, jedynie ma na celu zasygnalizowanie koniczności pobrania aktualnych danych od węzła ROMAN. Za pomocą metody requesttopology() węzeł RMS pobiera od węzła ROMAN aktualną topologię sieci. Dodatkowo węzeł RMS podczas działania moŝe być powiadamiany przez węzeł ROMAN o zmianie ścieŝek w sieci za pomocą metody routingpathshavechanged(). Podobnie jak poprzednia metoda, tak i w tym przypadku nie przekazuje dodatkowych danych. Z tego powodu węzeł RMS za pomocą metody requestpath() pobiera aktualną strukturę danych zawierającą aktualne ścieŝki w sieci. W interfejsie RomanToRms zdefiniowano metody: topologyhaschanged() oraz routingpaths- HaveChanged() umoŝliwiające przesłanie informacji od węzeł ROMAN do węzła RMS odpowiednio o zmianie topologii sieciowej lub zmianie ścieŝek. Natomiast w interfejsie RmsToRoman zdefiniowano metody: requesttopology() oraz requestpath() umoŝliwiające pobranie przez moduł RMS aktualnych struktur danych opisujących aktualną topologię sieci lub aktualne ścieŝki. Rysunek 2-1 przedstawia sekwencję wiadomości przesyłaną między węzłami ROMAN, RMS oraz PD-PE podczas aktualizacji ścieŝek i topologii sieciowej. 10
11 ROMAN RMS PD-PE topologyhaschanged() [] requesttopology() [LinkList] routingpathshavechanged() [] requestpath() [RoutingPathList] configureresources(cacconflist) [bool] configureports(rouconflist) [] Rysunek 2-1: Sekwencja wiadomości aktualizacja topologii sieciowej i ścieŝek Po otrzymaniu nowych danych węzeł RMS uruchamia algorytm obliczający nowe wartości parametrów CAC i konfiguracji portów wyjściowych ruterów. Następnie nowe dane przesyłane są do węzła PD-PE w strukturach danych za pomocą metod: configureresources(cacconflist) oraz configure- Ports(RouConfList). Metoda configureresources(cacconflist) przekazuje jako parametr strukturę CacConfList zawierającą konfigurację ruterów brzegowych dla funkcji CAC (obliczanej na podstawie wyliczonej pojemności). Natomiast metoda configureports(rouconflist) przekazuje jako parametr strukturę RouConfList zawierającą konfigurację wykorzystywanych portów wyjściowych ruterów. W interfejsie RmsToPd zdefiniowano metody: configureresources(cacconflist) oraz configure- Ports(RouConfList) umoŝliwiające przesłanie konfiguracji od węzła RMS do węzła PD-PE odpowiednio o parametrach CAC i konfiguracji portów wyjściowych. Listingi specyfikacji interfejsów RomanToRms i PdToRms wraz ze specyfikacją struktur danych są zamieszczone w Załączniku A Interfejsy wykorzystywane przez węzeł Węzeł RMS wykorzystuje metody requesttopology() i requestpath() z interfejsu RmsToRoman oferowanego przez węzeł ROMAN oraz metody configureresources(), configureports(), requestresourcestate(), configurerequestresourcestate() z interfejsu PdToRms oferowanego przez węzeł PD-PE. Opis działania tych interfejsów i udostępnianych metod znajduje się odpowiednio w punktach 2.2 i Wymagania dla instalacji węzła Węzeł RMS zrealizowano z wykorzystaniem języka C++ i wymaga następujących składników: 11
12 Kompilator języka C++ (np. gcc w wersji 4.0 lub nowszy), Standardowa biblioteka C++, Bibliotekę ICE w wersji dla języka C++, Kompilator slice2cpp. W celu przygotowania węzła do działania naleŝy uruchomić następujące polecenie: $ cd /opt/pbz/rms && make Sposób konfiguracji węzła Węzeł RMS moŝna konfigurować za pomocą odpowiednich wpisów do następujących plików konfiguracyjnych: rms.cfg demands.txt qos.txt Dla działania węzła RMS jest wymagany plik konfiguracyjny rms.cfg, w którym są zawarte parametry konieczne dla właściwej pracy w środowisku ICE. Ten plik naleŝy konfigurować zgodne z dokumentacją dostarczaną razem ze środowiskiem ICE. W pliku kaŝdy wiersz odpowiada jednej grupie zapotrzebowań dla 5 klas, których ścieŝki rozpoczynają się w danym węźle rbx. Format wiersza: <rbx> <z1> <z2> <z3> <z4> <z5> gdzie: <rbx> - pierwszy ruter występujący na ścieŝkach (wartość domyślna default jest przeznaczona dla wszystkich niezdefiniowanych zapotrzebowań, które będą wykorzystać te parametry) <z1> - zapotrzebowanie dla klasy Signalling <z2> - zapotrzebowanie dla klasy Real Time <z3> - zapotrzebowanie dla klasy MM Streaming <z4> - zapotrzebowanie dla klasy High Throughput Data (HTD) <z5> - zapotrzebowanie dla klasy Standard Zapotrzebowania od <z1> do <z5> wyraŝone są wagami, a przydzielona pojemność będzie wprost proporcjonalna do podanych wag. W niektórych przypadkach plik z zapotrzebowaniami musi posiadać dodatkową pustą linie (w sieci testowej znak nowej linii na końcu pliku konfiguracyjnego jest niezbędny). W pliku qos.txt zapisane są wymagania na jakość przekazu pakietów dla poszczególnych klas (Tabela 2-1). W pliku dla odpowiednich klas określa się następujące metryki: poziom strat pakie- 12
13 tów IPLR (ang. IP Packet Loss Ratio), średnie opóźnienie przekazu pakietów IPTD (ang. IP Packet Transfer Delay), zmienność opóźnienia przekazu pakietów IPDV (ang. IP Packet Delay Variation), oraz rozmiar pakietu - d. Tabela 2-1 Wymagania na jakość przekazu pakietów dla poszczególnych klas Lp. Klasa IPLR IPTD IPDV d 1 Signalling X X X 2 RealTime X X X X 3 MMStreaming X X 4 HighThroughputData X X 5 Standard Format zawartości pliku qos.txt został przedstawiony poniŝej w ramce. Nazwy metryk pomiarowych podanych w nawiasach trójkątnych naleŝy zastąpić ich odpowiednimi wartościami. Signalling <IPLR> <IPTD> <IPDV> RealTime <IPLR> <IPTD> <IPDV> <d> MMStreaming <IPLR> <IPTD> HighThroughputData <IPLR> <IPTD> Standard gdzie: d - rozmiar pakietu [byte] IPLR - poziom strat pakietów (ang. IP Packet Loss Ratio) [sek.] IPTD - opóźnienie pakietów (ang. IP Packet Transfer Delay) [sek.] IPDV - wariancja opóźnienia pakietów (ang. IP Packet Delay Variation) [sek.] Sposób uruchomienia węzła Uruchomienie węzła RMS musi być poprzedzone uruchomieniem rejestru nazw icegridregistry (katalog /opt/pbz/registry) oraz serwera konfiguracyjnego systemu (katalog /opt/pbz/config). Aby uruchomić węzeł RMS naleŝy wykonać następujące polecenia: $ cd /opt/pbz/rms $./start_rms 2.2 Węzeł ROMAN (Routing Manager) Opis działania interfejsów oferowanych przez węzeł W poniŝszej tabeli zawarto operacje, na interfejsach programowych pomiędzy współpracującymi modułami, które są udostępniane przez węzeł ROMAN. 13
14 Interfejs Operacja Opis RMS - ROMAN requesttopology() Pobranie topologii przez RMS od ROMANA. requestpaths() Pobranie ścieŝek rutingowych przez RMS od ROMANA. PD-PE - ROMAN requestaccessnetworks() Pobranie informacji o przynaleŝności podsieci (uŝytkowników) do poszczególnych ruterów brzegowymi przez PD-PE od ROMANA. Dane o sieciach lokalnych i topologii są wczytywane z pliku konfiguracyjnego conf.xml bądź są pobierane z bazy danych OSPF od jednego z ruterów w sieci. ŚcieŜki rutingowe są obliczane z wykorzystaniem jednego z dostępnych algorytmów rutingowych. Zaimplementowano algorytmy: Dijkstra, Kruskal oraz SAMCRA. Dodatkowo zaimplementowano cztery róŝne warianty modyfikacji wag przy obliczeniach ścieŝek rutingowych. Przy obliczaniu ścieŝek rutingowych uŝyto następującego oszacowania na przepustowość pomiędzy parą ruterów brzegowych: przepustowość najmniejszego łącza dostępowego C QoS = liczba ruterów brzegowych - 1 PowyŜszy wzór wynika z wymiarowania zasobów przyjętego w raporcie [B3] oraz realizacji funkcji AC jedynie w ruterach dostępowych. Wartość przepustowości łącza dla klasy QoS jest ograniczona i nie moŝe być większa niŝ C QoS. Kod implementujący interfejsy RMS-ROMAN oraz PDPE-ROMAN znajduje się w pliku roman.cs, gdzie umieszczono klasy: PdToRomanI oraz RmsToRomanI zawierające metody implementujące operacje, które oferuje węzeł. Są to odpowiednio: requestaccessnetworks(), requesttopology() oraz requestpaths(). Dane o topologii sieci oraz sieciach dostępowych są przechowywane w instancji klasy Repository, która uŝywa struktur Hashtable do przechowywania danych o sieci. Udostępnione są następujące metody publiczne: Metoda addaccessnetwork Opis Dodanie sieci dostępowej do repozytorium. 14
15 addtopologylink addpath getaccessnetworks gettopology getpaths Fill Dodanie łącza do repozytorium. Dodanie ścieŝki do repozytorium. Pobranie sieci dostępowych z repozytorium. Pobranie topologii sieci z repozytorium. Pobranie ścieŝek z repozytorium. Wczytanie łączy, ścieŝek i sieci dostępowych z pliku conf.xml do repozytorium. W przypadku uŝycia opcji pobierania informacji o topologii sieci z bazy danych OSPF ruterów wykorzystywana jest klasa OspfDiscovery, której implementacja znajduje się w pliku ospfdiscovery.cs. W uproszczeniu operacja polega na zdalnym zalogowaniu się do wybranego rutera (wskazanego w pliku konfiguracyjnym conf.xml) i wykonaniu szeregu komend wyświetlających informacje z bazy danych OSPF, tablicy rutingu oraz listy interfejsów rutera. Następnie naleŝy przeanalizować otrzymane od rutera odpowiedzi i wpisać otrzymane rezultaty do struktur danych repozytorium. Realizowane jest to poprzez następujące metody klasy OspfDiscovery: Metoda Start LoginToRouter GetInterfacesData Opis Główna metoda klasy, wywołująca pozostałe metody, które realizują zadania cząstkowe. Zdalne logowanie do rutera zdefiniowanego w pliku conf.xml w sekcji: ospfdataprovidingrouter. Pobieranie danych o interfejsach rutera, takich jak: nazwa interfejsu, adres IP oraz szybkośc bitową. Wykorzystywana jest komenda: show interfaces include Internet address BW Ethernet[0-9]". ExtractInterfacesData Analizowanie otrzymanej odpowiedzi z metody GetInterfacesData() i wstawia dane interfejsów do repozytorium. GetTopology ExtractTopology Pobieranie danych (topologia)z bazy danych OSPF. Wykorzystywana jest komenda: "show ip ospf database network include State Attached". Analizowanie otrzymanej odpowiedzi z metody GetTopology() i wstawianie danych do repozytorium. ExtractNodesFromLinks Przeglądanie tablicy łączy i tworzenie tablicy węzłów. 15
16 W celu automatycznej pracy na zdalnym ruterze zaimplementowano klasę Robot znajdującą się w pliku robot.cs. Jej funkcjonalność umoŝliwia połączenie się ze zdalnym ruterem, wysyłanie komend oraz oczekiwanie na odpowiedź, która moŝe być zadana w formie wyraŝenia regularnego (czyli specjalnego filtru sprawdzającego dopasowanie dla ciągu znaków). Algorytmy rutingowe zaimplementowano w pliku routingalgo.cs odpowiednio w klasach Samcra, Dijkstra oraz Kruskal. Wszystkie te klasy implementują interfejs IRoutingAlgo, który zawiera tylko dwie metody: Metoda SetLinks CalculateRouting Opis Ustawienie danych wejściowych dla algorytmu rutingu czyli danych o topologii sieci: łącza i przepływność łączy. Obliczenie rutingu i zwrócenie wyniku w postaci tablicy ścieŝek Interfejsy wykorzystywane przez węzeł Interfejs Operacja Opis ROMAN - RMS topologyhaschanged() Wiadomość informująca RMS, Ŝe ROMAN wykrył zmianę topologii sieci. RMS powinien w odpowiedzi wywołać requesttopology() w celu uaktualnienia topologii. routingpathshavechanged() Wiadomość informująca RMS o zmianie obliczonych ścieŝek przez ROMANA. RMS powinien w odpowiedzi wywołać requestpaths() w celu uaktualnienia ścieŝek rutingowych. PD-PE - ROMAN configureaccessnetworks() Wysłanie sieci dostępowych znajdujących się za ruterami brzegowymi przez ROMANA do PD-PE. W przypadku zmiany konfiguracji sieci węzeł ROMAN uaktualnia listę prefiksów sieci lokalnych w interfejsie RomanToPd za pomocą metody configureaccessnetworks(). W interfejsie RomanToRms wykorzystywane są metody topologyhaschanged() oraz routingpaths- HaveChanged(), które informują odpowiednio o zdarzeniach zmiany topologii sieci oraz obliczeniu nowych ścieŝek rutingowych. Przyjęto, Ŝe zawsze zmiana topologii pociąga za sobą rekonfigurację 16
17 ścieŝek i dlatego ROMAN zawsze przy wykryciu zmiany topologii oraz przy starcie wywołuje obie te metody Konfiguracja ruterów Konfiguracja rutingu w sieci sprowadza się do ustawienia ścieŝek tuneli MPLS. Korzystamy ze wstępnie skonfigurowanych ruterów, które mają ustanowione interfejsy tunelowe pomiędzy kaŝdą parą ruterów brzegowych. ROMAN ustawia dla tych tuneli dokładną ścieŝkę za pomocą komendy: ip explicit-path z podaniem kolejnych węzłów pośrednich. Implementacja konfiguracji ruterów jest zawarta w klasie PathConfigurator znajdującej się w pliku pathconfigurator.cs. Wykorzystywana jest opisana wcześniej klasa Robot Wymagania dla instalacji węzła Węzeł ROMAN wymaga instalacji następujących komponentów: maszyny wirtualnej MONO w wersji 1.9.1, kompilatora języka C# dla platformy.net gmcs, generatora klas dla schematu XML xsd, znajdującego się w narzędziach platformy MO- NO, biblioteki ICE w wersji dla platformy.net, kompilatora slice2cs znajdującego się w narzędziach biblioteki ICE. W celu przygotowania węzła do działania naleŝy uruchomić następujące polecenie: $ cd /opt/pbz/roman && make W ten sposób węzeł ROMAN jest gotowy do uruchomienia Sposób konfiguracji węzła Konfiguracja węzła ROMAN zawarta jest w dwóch plikach. Pierwszym z nich jest plik konfiguracyjny /opt/pbz/roman/ice.cfg, który definiuje parametry konfiguracji biblioteki ICE. Określono tylko jeden parametr - Ice.Default.Locator, który identyfikuje lokalizację rejestru nazw ICE. Drugim plikiem konfiguracyjnym jest conf.xml. Jest to poprawny dokument w formacie XML 1.0, który jest zgodny ze schematem XML zdefiniowanym w pliku conf.xsd. W pliku określono pięć sekcji głównych: Main opisuje główne parametry konfiguracyjne węzła ROMAN. Obecnie zdefiniowano trzy pola: o topologysource określa źródło informacji o topologii sieci. Dopuszczalne wartości: 17
18 file plik konfiguracyjnego conf.xml (sekcja Topology i AccessNetworkList), ospf baza danych OSPF pobierana z wyznaczonego rutera z sieci, o ospfdataprovidingrouter wyznaczony ruter w sieci, z którego jest pobierana baza danych OSPF przy ustawionej opcji topologysource na wartość ospf, o routingalgo określa algorytm uŝywany do obliczania ścieŝek rutingowych. Dopuszczalne wartości: file ruting wczytywany z pliku konfiguracyjnego conf.xml (sekcja Routing), Dijkstra algorytm Dijkstry, Kruskal algorytm Kruskala, SAMCRA algorytm SAMCRA; BorderRouters lista ruterów brzegowych. Sekcja moŝe zawierać jedną lub kilka podsekcji <router>, które definiują ruter poprzez następujące parametry: o routerid identyfikator rutera, np.: RB1, o routerip adres IP rutera brzegowego; AccessNetworkList lista prefiksów sieci lokalnych. Sekcja jest uŝywana w przypadku ustawienia parametru <Main><topologySource> na wartość file i moŝe zawierać jedną lub więcej podsekcji <Network>, które definiują poszczególne sieci lokalne za pomocą następujących parametrów: o netprefix prefiks sieci wraz z maską, np.: /16, o routerid identyfikator rutera, np:. RB1, o routerip adres IP rutera brzegowego, za którym jest dana sieć lokalna; Topology topologia sieci. Sekcja jest uŝywana w przypadku ustawienia parametru <Main><topologySource> na wartość file i moŝe zawierać jedną lub więcej podsekcji <Link>, które definiują poszczególne łącza w sieci za pomocą następujących parametrów: o Name identyfikator/nazwa łącza, o SourceRouter ruter początkowy. Sekcja zawiera trzy parametry opisujące ruter: routerid identyfikator rutera, routerip adres IP rutera, routertype typ rutera, dopuszczalne wartości: Border (brzegowy) i Core (szkieletowy), 18
19 o SinkRouter ruter końcowy. Parametry analogiczne jak dla pierwszego rutera, o PortName nazwa fizycznego portu na ruterze, o Capacity przepływność łącza w [Mbit/s]; Routing lista ścieŝek rutingowych. Sekcja jest uŝywana w przypadku ustawienia parametru <Main><routingAlgo> na wartość file i moŝe zawierać jedną lub więcej podsekcji <Path>, które definiują poszczególne ścieŝki w sieci za pomocą następujących parametrów: o ClassOfService nazwa klasy usług sieciowych, o Capacity przepływność przeznaczona dla tej klasy w [Mbit/s], o Routers uporządkowana lista identyfikatorów ruterów na ścieŝce, zgodna z kolejnością przebiegu ścieŝki rutingowej, np.: <Routers> <Router> </Router> <Router> </Router> <Router> </Router> <Router> </Router> </Routers> Konfiguracja systemu w laboratorium Wykonane oprogramowanie projektu IP QoS będzie testowane i demonstrowane w sieci laboratoryjnej w Instytucie Łączności opisanej w [B8] i [D6]. ROMAN wymaga, aby rutery brzegowe i szkieletowe były wstępnie skonfigurowane do przesyłania ruchu MPLS. W szczególności naleŝy wykonać następujące operacje: włączenie MPLS na interfejsach fizycznych: interface GigabitEthernet0/1 mpls ip mpls traffic-eng tunnels ip rsvp bandwidth włączenie rutingu OSPF, utworzenie tuneli pomiędzy parą ruterów brzegowych: interface Tunnel1 description tunel1 tunnel destination tunnel mpls traffic-eng path-option 1 explicit name sciezka_1 tunnel mpls traffic-eng record-route no routing dynamic 19
20 KaŜdy ruter w sieci laboratoryjnej posiada adresy IP związane z interfejsami fizycznymi rutera oraz adres logiczny, który jest unikalny w całej sieci (interfejs Loopback0). ROMAN uŝywa adresów interfejsów Loopback0 przy konfigurowaniu tuneli MPLS. W ramach testów laboratoryjnych aplikacja ROMAN będzie uruchamiana w fazie wstępnej konfiguracji sieci. Po uruchomieniu będzie następowało wykrycie topologii sieci, obliczenie ścieŝek rutingowych i skonfigurowanie tuneli MPLS. Następnie funkcjonalność ROMANa ograniczy się do udostępniania danych o topologii sieci i zestawionym runtingu dla innych aplikacji systemu Sposób uruchomienia węzła Uruchomienie węzła ROMAN musi być poprzedzone uruchomieniem rejestru nazw icegridregistry (katalog /opt/pbz/registry) oraz serwera konfiguracyjnego systemu (katalog /opt/pbz/config). Aby uruchomić węzeł ROMAN naleŝy wykonać następujące polecenia: $ cd /opt/pbz/roman $ sh start_roman.sh 2.3 Węzeł PD-PE (Policy Decision Physical Entity) Opis działania interfejsów oferowanych przez węzeł Węzeł PD-PE uczestniczy w procesie ustalenia rutingu w domenie. Węzeł PD-PE otrzymuje od węzła ROMAN informację o przynaleŝności adresów klientów do poszczególnych ruterów. Funkcja ta jest realizowana za pomocą metody configureaccessnetworks() w interfejsie RomanToPd. Po otrzymaniu aktualnej listy przynaleŝności adresów klientów do ruterów, stara lista jest usuwana. Węzeł PD-PE przekazuje informację w procesie konfiguracji zasobów dla algorytmu przyjmowania nowych połączeń oraz w procesie konfiguracji zasobów dla interfejsu wyjściowego rutera. Obie funkcje znajdują się w interfejsie RmsToPd i są to odpowiednio configureresources() oraz configureports(). W przypadku procesu konfiguracji zasobów dla algorytmu przyjmowania nowych połączeń węzeł PD-PE odszukuje odpowiednie węzły TRC-PE i przekazuje do nich Ŝądania. W przypadku procesu konfiguracji zasobów dla interfejsu wyjściowego rutera węzeł PD-PE odszukuje odpowiednie węzły PE-PE i przekazuje do nich Ŝądania Interfejsy wykorzystywane przez węzeł Węzeł PD-PE po uruchomieniu komunikuje się z węzłem ROMAN aby otrzymać informację o przynaleŝności adresów klientów do poszczególnych ruterów uczestniczy. Działanie to jest związane z procesem ustalenia rutingu w domenie. W wyniku uruchomienia funkcji requestaccessnetworks() naleŝącej do interfejsu PdToRoman jest uzyskiwana lista przynaleŝności adresów klientów do ruterów. W czasie procesu monitorowania stanu wykorzystania zasobów węzeł PD-PE przekazuje raporty (tworzone przez węzły TRC-PE) poprzez metodę reportresourcestate() w interfejsie PdToRms. W 20
21 implementacji węzła PD-PE dla etapu C funkcjonalność ta nie została zaimplementowana. Przewidujemy, Ŝe zostanie ona zrealizowana w etapie D Wymagania dla instalacji węzła Węzeł PD-PE wymaga instalacji następujących komponentów: Interpreter języka programowania Python w wersji 2.6, Bibliotekę ICE w wersji dla języka Python, Kompilator slice2py znajdujący się w narzędziach biblioteki ICE, Bibliotekę języka Python: threadpool. W celu przygotowania węzła do działania naleŝy uruchomić następujące polecenie: $ cd /opt/pbz/pdpe && make Po spełnieniu powyŝszych wymagań węzeł PD-PE jest gotowy do uruchomienia Sposób konfiguracji węzła Konfiguracja węzła PD-PE znajduję się w pliku konfiguracyjnym /opt/pbz/pdpe/pdpe.cfg, który zawiera dwie sekcje [pdpe] i [ice]. W sekcji [pdpe] wyróŝniamy: name określa identyfikator węzła, który powinien być unikalny wśród wszystkich węzłów PD-PE, debug określa poziom szczegółowości wyświetlanych informacji o działaniu węzła; dozwolone wartości to true i false, W sekcji [ice] określono parametry konfiguracji biblioteki ICE: Ice.Default.Locator identyfikuje lokalizację rejestru nazw ICE, Ice.ThreadPool.Client.Size określa minimalną liczbę wątków biblioteki ICE po stronie klienta; wartość ta powinna być ustawiona na 1, Ice.ThreadPool.Client.SizeMax określa maksymalną liczbę wątków biblioteki ICE po stronie klienta; wartość ta powinna być ustawiona na 1, Ice.ThreadPool.Server.Size określa minimalną liczbę wątków biblioteki ICE po stronie serwer; sugerowana wartość to 10, Ice.ThreadPool.Server.SizeMax określa maksymalną liczbę wątków biblioteki ICE po stronie serwer; sugerowana wartość to
22 2.3.5 Sposób uruchomienia węzła Uruchomienie węzła PD-PE musi być poprzedzone uruchomieniem rejestru nazw icegridregistry (katalog /opt/pbz/registry) oraz serwera konfiguracyjnego systemu (katalog /opt/pbz/config). Aby uruchomić węzeł PD-PE naleŝy wykonać następujące polecenia: $ cd /opt/pbz/pdpe $ python pdpe.py 2.4 Węzeł TRC-PE (Transport Resource Control Physical Entity) Opis działania interfejsów oferowanych przez węzeł Węzeł TRC-PE realizuje algorytm przyjmowania nowych połączeń i jest elementem końcowym w procesie konfiguracji zasobów dla algorytmu przyjmowania nowych połączeń. W tym celu w interfejsie PdToTrc wyróŝniono metodę configureresources(), której parametrem jest opis konfiguracji zasobów z podziałem na poszczególne klasy usług. Po uruchomieniu tej metody wykonywane są następujące działania: Węzeł TRC-PE identyfikuje w bazie danych poszukiwany punkt realizacji algorytmu przyjmowania połączeń. W przypadku, gdy punkt nie zostanie odnaleziony metoda zwraca wynik negatywny. Wśród opisu konfiguracji zasobów znajduje się przepływność i rozmiar bufora przydzielony dla danej klasy usług oraz wymagany poziom strat pakietów. Na podstawie tych parametrów wyliczane jest maksymalne dopuszczalne obciąŝenie, które określane jest za pomocą algorytmu przyjmowania połączeń. Wartość ta zostaje zapisana w bazie danych. W przypadku gdy algorytm przyjmowania nowych połączeń nie wspiera danej klasy usług, metoda zwraca wynik negatywny. Po obsłuŝeniu wszystkich grup opisujących zasoby algorytm zwraca wyniki pozytywny. ZauwaŜmy, Ŝe moŝe wystąpić sytuacja, w której aktualny poziom zajętości zasobów moŝe przekraczać nowe maksymalne obciąŝenia danej klasy usług. W obecnej wersji implementacji zjawisko to jest ignorowane, jednak w docelowej wersji systemu zostanie zastosowany algorytm zwalniający zasoby wśród działających połączeń w sposób minimalizujący liczbę rozłączonych połączeń Interfejsy wykorzystywane przez węzeł Węzeł TRC-PE nie wykorzystuje zewnętrznych interfejsów w przypadku procesów zarządzania zasobami Wymagania dla instalacji węzła Węzeł TRC-PE wymaga instalacji następujących komponentów: Interpreter języka programowania Python w wersji 2.6, 22
23 Bibliotekę ICE w wersji dla języka Python, Kompilator slice2py znajdujący się w narzędziach biblioteki ICE, Biblioteki języka Python: threadpool, SQLAlchemy, psycopg2, Bazę danych PostrgreSQL w wersji 8.3. W celu przygotowania węzła do działania naleŝy uruchomić następujące polecenie: $ cd /opt/pbz/trc && make W bazie danych PostgreSQL naleŝy stworzyć bazę danych o nazwie pbz_trc dla uŝytkownika user (parametry te moŝna zmienić w pliku /opt/pbz/trc/trc.cfg w parametrze konfiguracyjnym o nazwie database_string). Następnie naleŝy przygotować strukturę bazy danych za pomocą polecenia $ cd /opt/pbz/trc/database && python db_create.py Po spełnieniu powyŝszych wymagań węzeł TRC-PE jest gotowy do uruchomienia Sposób konfiguracji węzła Konfiguracja węzła TRC-PE składa się z dwóch elementów. Pierwszym z nich jest plik konfiguracyjny /opt/pbz/trc/trc.cfg, który zawiera dwie sekcje [trc] i [ice]. W sekcji [trc] wyróŝniamy: name określa identyfikator węzła, który powinien być unikalny wśród wszystkich węzłów TRC-PE, database_string określa dostęp do bazy danych PostrgreSQL, w tym nazwę uŝytkownika oraz nazwą bazy danych, debug określa poziom szczegółowości wyświetlanych informacji o działaniu węzła; dozwolone wartości to true i false, emulation określa czy węzeł działa w trybie emulacji, w którym nie uŝywa się bazy danych, emulation_rate określa prawdopodobieństwo negatywnej odpowiedzi w przypadku działania a w trybie emulacji. W sekcji [ice] określono parametry konfiguracji biblioteki ICE: Ice.Default.Locator identyfikuje lokalizację rejestru nazw ICE, Ice.ThreadPool.Client.Size określa minimalną liczbę wątków biblioteki ICE po stronie klienta; wartość ta powinna być ustawiona na 1, Ice.ThreadPool.Client.SizeMax określa maksymalną liczbę wątków biblioteki ICE po stronie klienta; wartość ta powinna być ustawiona na 1, 23
24 Ice.ThreadPool.Server.Size określa minimalną liczbę wątków biblioteki ICE po stronie serwer; sugerowana wartość to 10, Ice.ThreadPool.Server.SizeMax określa maksymalną liczbę wątków biblioteki ICE po stronie serwer; sugerowana wartość to 50. Druga część konfiguracji węzła TRC-PE znajduje się w bazie danych. Plik /opt/pbz/trc/database/db_dummyfill.py przedstawia przykładowy sposób wypełnienia bazy danych. Jego główne elementy to klasy TrcPoint i TrcResource, które definiują punkty algorytmu przyjmowania nowych połączeń oraz wspierane klasy usług Sposób uruchomienia węzła Uruchomienie węzła TRC-PE musi być poprzedzone uruchomieniem rejestru nazw icegridregistry (katalog /opt/pbz/registry), serwera konfiguracyjnego systemu (katalog /opt/pbz/config) oraz bazy danych PostgreSQL. Aby uruchomić węzeł TRC-PE naleŝy wykonać następujące polecenia: $ cd /opt/pbz/trc $ python trc.py 2.5 Węzeł PE-PE (Policy Enforcement Physical Entity) Opis działania interfejsów oferowanych przez węzeł Węzeł PE-PE zarządza konfiguracją urządzeń i jest elementem końcowym w procesie konfiguracji zasobów dla interfejsu wyjściowego rutera. W tym celu w interfejsie PdToPe wyróŝniono metodę configureports(), której parametrem jest opis konfiguracji interfejsu rutera. Opis ten zawiera podział zasobów dla poszczególnych klas usług włączając m.in. przepływności oraz rozmiary buforów Interfejsy wykorzystywane przez węzeł Węzeł PE-PE jest skrajnym elementem łańcucha sygnalizacji i sam nie wykorzystuje interfejsów systemowych. Z drugiej strony węzeł ten kontaktuje się z urządzeniami sieciowymi, jednak ten sposób komunikacji jest specyficzny dla kaŝdego urządzenia i nie jest przedmiotem tego raportu Wymagania dla instalacji węzła Węzeł PE-PE wymaga instalacji następujących komponentów: Interpreter języka programowania Python w wersji 2.6, Bibliotekę ICE w wersji dla języka Python, Kompilator slice2py znajdujący się w narzędziach biblioteki ICE, Biblioteki języka Python: threadpool. 24
25 W celu przygotowania węzła do działania naleŝy uruchomić następujące polecenie: $ cd /opt/pbz/pepe && make Węzeł PE-PE wykorzystuje lokalną bazę danych, której zawartość trzeba przygotować przed uruchomieniem węzła. Przykładowe skrypty z zawartością znajdują się w zbiorach db_fill_dummy_core.py i db_fill_dummy_edge.py. MoŜna je wykorzystać aby stworzyć strukturę bazy danych za pomocą polecenia $ cd /opt/pbz/pepe && python db_fill_dummy_edge.py Po spełnieniu powyŝszych wymagań węzeł PE-PE jest gotowy do uruchomienia Sposób konfiguracji węzła Konfiguracja węzła PE-PE składa się z dwóch elementów. Pierwszym z nich jest plik konfiguracyjny /opt/pbz/pepe/pepe.cfg, który zawiera dwie sekcje [pepe] i [ice]. W sekcji [pepe] wyróŝniamy: name określa identyfikator węzła, który powinien być unikalny wśród wszystkich węzłów PE-PE, database_string określa dostęp do bazy danych przechowującej konfigurację węzła, debug określa poziom szczegółowości wyświetlanych informacji o działaniu węzła; dozwolone wartości to true i false, W sekcji [ice] określono parametry konfiguracji biblioteki ICE: Ice.Default.Locator identyfikuje lokalizację rejestru nazw ICE, Ice.ThreadPool.Client.Size określa minimalną liczbę wątków biblioteki ICE po stronie klienta; wartość ta powinna być ustawiona na 1, Ice.ThreadPool.Client.SizeMax określa maksymalną liczbę wątków biblioteki ICE po stronie klienta; wartość ta powinna być ustawiona na 1, Ice.ThreadPool.Server.Size określa minimalną liczbę wątków biblioteki ICE po stronie serwer; sugerowana wartość to 10, Ice.ThreadPool.Server.SizeMax określa maksymalną liczbę wątków biblioteki ICE po stronie serwer; sugerowana wartość to 50. Druga część konfiguracji węzła PE-PE znajduje się w bazie danych. Zbiory db_fill_dummy_core.py i db_fill_dummy_edge.py przedstawiają przykładowy sposób wypełnienia bazy danych, odpowiednio dla rutera szkieletowego oraz rutera brzegowego. 25
26 2.5.5 Sposób uruchomienia węzła Uruchomienie węzła PE-PE musi być poprzedzone uruchomieniem rejestru nazw icegridregistry (katalog /opt/pbz/registry) oraz serwera konfiguracyjnego systemu (katalog /opt/pbz/config). Aby uruchomić węzeł PE-PE naleŝy wykonać następujące polecenia: $ cd /opt/pbz/pepe $ python pepe.py 2.6 Serwer konfiguracyjny systemu Opis działania interfejsów oferowanych przez serwer Sewer konfiguracyjny systemu jest serwerem pomocniczym, który nie jest związany bezpośrednio z Ŝadnym procesem systemu. Pozwala on jednak w łatwy sposób automatycznie skonfigurować zaleŝności pomiędzy węzłami za pomocą usługi rejestru icegridregistry. Serwer konfiguracyjne systemu rejestruje znane nazwy w rejestrze, które wykorzystywane są przez węzły podczas ich uruchamiania. W przypadku tego raportu istotne są: configurationpd@ dostęp do interfejsu konfiguracyjnego dla węzła PD-PE, configurationtrc@ dostęp do interfejsu konfiguracyjnego dla węzła TRC-PE, configurationpe@ dostęp do interfejsu konfiguracyjnego dla węzła PE-PE, configurationroman@ dostęp do interfejsu konfiguracyjnego dla węzła ROMAN, configurationrms@ dostęp do interfejsu konfiguracyjnego dla węzła RMS Wymagania dla instalacji serwera Serwer konfiguracyjny systemu wymaga instalacji następujących komponentów: Interpreter języka programowania Python w wersji 2.6, Bibliotekę ICE w wersji dla języka Python, Kompilator slice2py znajdujący się w narzędziach biblioteki ICE, W celu przygotowania serwera do działania naleŝy uruchomić następujące polecenie: $ cd /opt/pbz/config && config Po spełnieniu powyŝszych wymagań serwer konfiguracyjny systemu jest gotowy do uruchomienia Sposób konfiguracji serwera Konfiguracja serwera konfiguracyjnego systemu znajduje się w pliku /opt/pbz/config/config.cfg, który zawiera dwie sekcje [config] i [ice]. 26
27 W sekcji [config] wyróŝniamy: debug określa poziom szczegółowości wyświetlanych informacji o działaniu serwera; dozwolone wartości to true i false. W sekcji [ice] określono parametry konfiguracji biblioteki ICE: Ice.Default.Locator identyfikuje lokalizację rejestru nazw ICE, Sposób uruchomienia serwera Uruchomienie serwera konfiguracyjnego musi być poprzedzone uruchomieniem rejestru nazw icegridregistry (katalog /opt/pbz/registry). Aby uruchomić serwer konfiguracyjny systemu naleŝy wykonać następujące polecenia: $ cd /opt/pbz/config $ python config.py 2.7 Kolejność uruchamiania węzłów systemu Rysunek 2-2 przedstawia wymaganą kolejność uruchamiania poszczególnych elementów oprogramowania systemu. Pierwszym krokiem jest uruchomienie serwera rejestru icegridregistry. Drugim krokiem jest uruchomienie serwera konfiguracyjnego. Serwery znajdujące się w kroku trzecim mogą być uruchomione w dowolnej kolejności. Ponadto jest moŝliwe ponowne uruchomienie kaŝdego serwera ( zresetowanie ) w dowolnym stabilnym momencie, tzn. gdy nie są obsługiwane wywoływania. Podobnie postępujemy w kroku czwartym. Gdy wszystkie węzły zostaną uruchomione moŝna uruchomić aplikację testową. 1 icegridregistry 2 Serwer konfiguracyjny 3 SCE PD-PE TRC-PE PE-PE 4 RMS ROMAN 5 Aplikacja testowa Rysunek 2-2: Kolejność uruchamiania oprogramowania systemu 27
28 3 Podsumowanie W etapie D zostały zaimplementowane wszystkie węzły związane z zarządzaniem zasobami sieci. System IP QoS wymiaruje zasoby sieci zgodnie z załoŝonymi algorytmami oraz wymaganiami jakości przekazu pakietów. W szczególności system zarządza stanem zasobów w punktach przyjmowania nowych połączeń oraz zarządza konfiguracją mechanizmów sterowania ruchem w ruterach. Opis stanu implementacji został podzielony ze względu na poszczególne węzły funkcjonalne systemu, czyli węzły RMS, ROMAN, PD-PE, TRC-PE i PE-PE. Ponadto opisano serwer konfiguracyjny systemu, który jest elementem pomocniczym związanym z konfiguracją i zarządzaniem oprogramowania. Tabela 3-1 podsumowuje szczegóły stanu implementacji na zakończenie etapu D. Tabela 3-1: Stan implementacji systemu dla etapu D procesy zarządzania zasobami Nazwa Definicja interfejsu w języku SLICE Stan implementacji Węzeł RMS Węzeł ROMAN Węzeł PD-PE RmsToPd: TAK RmsToRoman: TAK RomanToPd: TAK RomanToRms: TAK RmsToPd: TAK RomanToPd: TAK TrcToPd: TAK Węzeł został zaimplementowany Węzeł korzysta z serwera konfiguracyjnego Węzeł współpracuje z węzłem PD-PE Węzeł współpracuje z węzłem ROMAN Węzeł został zaimplementowany Węzeł korzysta z serwera konfiguracyjnego Węzeł współpracuje z węzłem PD-PE Węzeł współpracuje z węzłem RMS Węzeł został zaimplementowany Węzeł korzysta z serwera konfiguracyjnego Węzeł współpracuje z węzłem ROMAN Węzeł współpracuje z węzłem RMS Węzeł współpracuje z węzłem TRC-PE Węzeł TRC-PE PdToTrc: TAK Węzeł został zaimplementowany Węzeł korzysta z serwera konfiguracyjnego Węzeł automatycznie rejestruje się w węzłach PD-PE 28
29 Węzeł PE-PE PdToPe: TAK Węzeł został zaimplementowany Węzeł korzysta z serwera konfiguracyjnego Węzeł automatycznie rejestruje się w węzłach PD-PE konfigura- Serwer cyjny TAK specjalne interfejsy Serwer został zaimplementowany Serwer obsługuje węzły RMS, ROMAN, PD-PE i TRC-PE. 29
30 Literatura [A8] [B1] [B3] [B7] [B8] [D6] [Mong09] [RFC2475] W. Burakowski et. al., Opracowanie wymagań na system IP QoS, -MNiSW-02- II/2007/WUT/A.1, W. Burakowski et. al, Raport B.1: Specyfikacja architektury systemu IP QoS, -MNiSW- 02-II/2007/WUT/B.1, S. Kaczmarek et. al., Specyfikacja metod i algorytmów zarządzania zasobami w systemie IP QoS, -MNiSW-02-II/2007/PG/B.3, P. Pyda, T, Dalecki, Specyfikacja metody rutingu w sieci IP QoS, -MNiSW-02- II/2007/WIŁ/B.7, H. Gut et. al., Specyfikacja i instalacja sieci laboratoryjnej IP QoS, -MNiSW-02- II/2007/IŁ-PIB/B.8, H. Gut et. al., Integracja oprogramowania i instalacja w sieci laboratoryjnej IP QoS - część II, -MNiSW-02-II/2007/PW/D.6, J.Mongay Batalla, J. Śliwiński, H.Tarasiuk and W.Burakowski, Impact of Signaling System Performance on QoE In Next Generation Networks, Journal of Telecommunications and Information Technology, 4/2009, str S. Blake, et al., An Architecture for Differentiated Services, Internet RFC 2475, December
31 Lista skrótów CAC PD-PE PE-PE ROMAN RMS SCE TRC-PE Connection Admission Control Policy Decision Physical Entity Policy Enforcement Physical Entity Routing Management Resource Management System Service Control Entity Transport Resource Control Physical Entity 31
32 Załącznik A: Definicja interfejsów w języku SLICE Plik: router.ice #ifndef ROUTES_ICE #define ROUTES_ICE module pbz struct Router string name; string ipaddress; string type; // ingress, egress, core sequence<router> RouterList; struct AccessNetwork string prefix; Router borderrouter; sequence<accessnetwork> AccessNetworkList; struct Link bool com; string name; Router sourcerouter; Router sinkrouter; string portname; long capacity; sequence<link> LinkList; struct RoutingPath bool com; string classofservice; long capacity; RouterList pathnodes; sequence <RoutingPath> RoutingPathList; #endif Plik: rms_cac.ice #ifndef RMS_CAC_ICE #define RMS_CAC_ICE #include <router.ice> module pbz struct CacPolicy Router egressrouter; long maxcapacity; 32
Implementacja modułu do wspomagania konfiguracji. Usługi i sieci teleinformatyczne następnej generacji aspekty techniczne, aplikacyjne i rynkowe
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/WUT/D.4
Analysis of PCE-based path optimization in multi-domain SDN/MPLS/BGP-LS network
Analysis of PCE-based path optimization in multi-domain SDN/MPLS/BGP-LS network Grzegorz Rzym AGH, Department of Telecommunications 20-21.10.2016, Poznań www.agh.edu.pl Agenda Motywacja PCE SDN Środowisko
Zaawansowane metody pomiarów i diagnostyki w rozległych sieciach teleinformatycznych Pomiary w sieciach pakietowych. Tomasz Szewczyk PCSS
Zaawansowane metody pomiarów i diagnostyki w rozległych sieciach teleinformatycznych Pomiary w sieciach pakietowych Tomasz Szewczyk PCSS Plan prezentacji Rodzaje pomiarów Sprzęt pomiarowy Analiza wyników
Instrukcje dotyczące funkcji zarządzania pasmem w urządzeniach serii ZyWALL.
Instrukcje dotyczące funkcji zarządzania pasmem w urządzeniach serii ZyWALL. Niniejsza instrukcja zawiera wskazówki dotyczące konfiguracji funkcji BW MGMT dostępnej w urządzeniach serii ZyWALL. Dość często
Wymagania i zalecenia dla usługi głosowej w Sieci FreePhone. MASH.PL Wymagania i zalecenia dla usługi głosowej w Sieci FreePhone Strona 1
Wymagania i zalecenia dla usługi głosowej w Sieci FreePhone MASH.PL Wymagania i zalecenia dla usługi głosowej w Sieci FreePhone Strona 1 SPIS TREŚCI: Wymagania ogólne stawiane połączeniom głosowym-----------------------------------------3
DR INŻ. ROBERT WÓJCIK DR INŻ. JERZY DOMŻAŁ PODSTAWY RUTINGU IP. WSTĘP DO SIECI INTERNET Kraków, dn. 7 listopada 2016 r.
DR INŻ. ROBERT WÓJCIK DR INŻ. JERZY DOMŻAŁ PODSTAWY RUTINGU IP WSTĘP DO SIECI INTERNET Kraków, dn. 7 listopada 2016 r. PLAN Ruting a przełączanie Klasyfikacja rutingu Ruting statyczny Ruting dynamiczny
Aplikacja serwerowa Platformy Prezentacyjnej Opis produktu
Aplikacja serwerowa Platformy Prezentacyjnej Opis produktu Polska Organizacja Turystyczna ul. Chałubińskiego 8 00-613 Warszawa Spis treści 1 Założenia wstępne... 1 1.1 Informacje wstępne... 1 1.2 Cel projektu...
RUTERY. Dr inŝ. Małgorzata Langer
RUTERY Dr inŝ. Małgorzata Langer Co to jest ruter (router)? Urządzenie, które jest węzłem komunikacyjnym Pracuje w trzeciej warstwie OSI Obsługuje wymianę pakietów pomiędzy róŝnymi (o róŝnych maskach)
Bramka IP 2R+L szybki start.
Bramka IP 2R+L szybki start. Instalacja i dostęp:... 2 Konfiguracja IP 2R+L do nawiązywania połączeń VoIP... 4 Konfiguracja WAN... 4 Konfiguracja serwera SIP... 5 Konfiguracja IAX... 6 IP Polska Sp. z
Integracja systemów sterowania i sterowanie rozproszone 5 R
Integracja systemów sterowania i sterowanie rozproszone 5 R ifix połącznie z serwerami OPC Laboratorium 8. Krzysztof Kołek Plan laboratorium 1. OLE FOR PROCESS CONTROL (OPC)... 2 2. TESTOWY SERWER OPC...
Instrukcja Instalacji
Generator Wniosków Płatniczych dla Programu Operacyjnego Kapitał Ludzki Instrukcja Instalacji Aplikacja współfinansowana ze środków Unii Europejskiej w ramach Europejskiego Funduszu Społecznego Spis treści
Aby pobrać program FotoSender naleŝy na stronę www.fotokoda.pl lub www.kodakwgalerii.astral.pl i kliknąć na link Program do wysyłki zdjęć Internetem.
FotoSender 1. Pobranie i instalacja programu Aby pobrać program FotoSender naleŝy na stronę www.fotokoda.pl lub www.kodakwgalerii.astral.pl i kliknąć na link Program do wysyłki zdjęć Internetem. Rozpocznie
Podstawowe protokoły transportowe stosowane w sieciach IP cz.2
Laboratorium Technologie Sieciowe Podstawowe protokoły transportowe stosowane w sieciach IP cz.2 Wprowadzenie Ćwiczenie przedstawia praktyczną stronę następujących zagadnień: połączeniowy i bezpołączeniowy
Programowanie współbieżne i rozproszone
Programowanie współbieżne i rozproszone WYKŁAD 11 dr inż. CORBA CORBA (Common Object Request Broker Architecture) standard programowania rozproszonego zaproponowany przez OMG (Object Management Group)
Protokół BGP Podstawy i najlepsze praktyki Wersja 1.0
Protokół BGP Podstawy i najlepsze praktyki Wersja 1.0 Cisco Systems Polska ul. Domaniewska 39B 02-672, Warszawa http://www.cisco.com/pl Tel: (22) 5722700 Fax: (22) 5722701 Wstęp do ćwiczeń Ćwiczenia do
Rys. 1. Wynik działania programu ping: n = 5, adres cyfrowy. Rys. 1a. Wynik działania programu ping: l = 64 Bajty, adres mnemoniczny
41 Rodzaje testów i pomiarów aktywnych ZAGADNIENIA - Jak przeprowadzać pomiary aktywne w sieci? - Jak zmierzyć jakość usług sieciowych? - Kto ustanawia standardy dotyczące jakości usług sieciowych? - Jakie
Podstawowe protokoły transportowe stosowane w sieciach IP cz.1
Laboratorium Technologie Sieciowe Podstawowe protokoły transportowe stosowane w sieciach IP cz.1 Wprowadzenie Ćwiczenie przedstawia praktyczną stronę następujących zagadnień: połączeniowy i bezpołączeniowy
Internetowy moduł prezentacji WIZYT KLIENTA PUP do wykorzystania np. na stronie WWW. Wstęp
Internetowy moduł prezentacji WIZYT KLIENTA PUP do wykorzystania np. na stronie WWW. Wstęp Prezentujemy Państwu propozycję modułu aplikacji internetowej słuŝącej do prezentacji zaplanowanych wizyt klienta
Instrukcja do panelu administracyjnego. do zarządzania kontem FTP WebAs. www.poczta.greenlemon.pl
Instrukcja do panelu administracyjnego do zarządzania kontem FTP WebAs www.poczta.greenlemon.pl Opracowanie: Agencja Mediów Interaktywnych GREEN LEMON Spis treści 1.Wstęp 2.Konfiguracja 3.Konto FTP 4.Domeny
Internetowy moduł prezentacji ofert pracy do wykorzystania na stronie WWW lub panelu elektronicznym. Wstęp
Internetowy moduł prezentacji ofert pracy do wykorzystania na stronie WWW lub panelu elektronicznym. Wstęp Prezentujemy Państwu propozycję modułu aplikacji internetowej słuŝącej do prezentacji ofert pracy
Routing - wstęp... 2 Routing statyczny... 3 Konfiguracja routingu statycznego IPv Konfiguracja routingu statycznego IPv6...
Routing - wstęp... 2 Routing statyczny... 3 Konfiguracja routingu statycznego IPv4... 3 Konfiguracja routingu statycznego IPv6... 3 Sprawdzenie połączenia... 4 Zadania... 4 Routing - wstęp O routowaniu
Konfiguracja komunikacji jednostki centralnej systemu sterowania PVS MCU LAN w sieci LAN (Local Area Network)
Konfiguracja komunikacji jednostki centralnej systemu sterowania PVS MCU LAN w sieci LAN (Local Area Network) Niniejszy rozdział opisuje czynności jakie naleŝy wykonać aby skonfigurować komunikację z jednostki
Ćwiczenie 5a Sieć komputerowa z wykorzystaniem rutera.
. Cel ćwiczenia: - Krótka charakterystyka rutera. - Połączenie rutera z komputerem w celu jego konfiguracji. - Szybka konfiguracja rutera do pracy w przewodowej sieci LAN. - Zmiana adresu rutera. - Konfiguracja
Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV
Piotr Jarosik, Kamil Jaworski, Dominik Olędzki, Anna Stępień Dokumentacja wstępna TIN Rozproszone repozytorium oparte o WebDAV 1. Wstęp Celem projektu jest zaimplementowanie rozproszonego repozytorium
Instrukcja uŝytkownika
Instrukcja uŝytkownika Instalator systemu Rejestracji Czasu Pracy 20 listopada 2008 Wersja 1.0 Spis treści 1Wstęp... 3 2Serwer FireBird... 3 3Baza danych instalacja i rejestracja... 9 3.1Instalacja...
Bezpieczne strony WWW dla edukacji, organizacji non-profit i uŝytkowników indywidualnych.
Bezpieczne strony WWW dla edukacji, organizacji non-profit i uŝytkowników indywidualnych. Jerzy Mikołajczak, Sebastian Petruczynik, Marek Zawadzki support-mic@man.poznan.pl 1 Plan prezentacji: 1. Wstęp
Konta uŝytkowników. Konta uŝytkowników dzielą się na trzy grupy: lokalne konta uŝytkowników, domenowe konta uŝytkowników, konta wbudowane
Konta uŝytkowników Konta uŝytkowników dzielą się na trzy grupy: lokalne konta uŝytkowników, domenowe konta uŝytkowników, konta wbudowane Lokalne konto uŝytkownika jest najczęściej wykorzystywane podczas
Graficzny terminal sieciowy ABA-X3. część druga. Podstawowa konfiguracja terminala
Graficzny terminal sieciowy ABA-X3 część druga Podstawowa konfiguracja terminala Opracował: Tomasz Barbaszewski Ustawianie interfejsu sieciowego: Podczas pierwszego uruchomienia terminala: Program do konfiguracji
Ćwiczenie 5b Sieć komputerowa z wykorzystaniem rutera.
. Cel ćwiczenia: - Krótka charakterystyka rutera. - Połączenie rutera z komputerem w celu jego konfiguracji. - Szybka konfiguracja rutera do pracy w przewodowej sieci LAN. - Zmiana adresu rutera. - Konfiguracja
Co w sieci siedzi. Warstwa 2 - konfiguracja sieci VLAN. Routing między sieciami VLAN.
1 (Pobrane z slow7.pl) Co w sieci siedzi. Warstwa 2 - konfiguracja sieci VLAN. Wyobraź sobie o to taką sytuację. W firmie w której pracujesz wdrożono nowe oprogramowanie bazodanowe, którego zadaniem jest
Warstwa sieciowa rutowanie
Warstwa sieciowa rutowanie Protokół IP - Internet Protocol Protokoły rutowane (routed) a rutowania (routing) Rutowanie statyczne i dynamiczne (trasowanie) Statyczne administrator programuje trasy Dynamiczne
Instrukcja dotycząca funkcji zarządzania pasmem w urządzeniach serii Prestige 660HW.
Instrukcja dotycząca funkcji zarządzania pasmem w urządzeniach serii Prestige 660HW. Niniejsza instrukcja zawiera wskazówki dotyczące konfiguracji funkcji BW MGMT dostępnej w urządzeniach serii Prestige
Współpraca z platformą Emp@tia. dokumentacja techniczna
Współpraca z platformą Emp@tia dokumentacja techniczna INFO-R Spółka Jawna - 2013 43-430 Pogórze, ul. Baziowa 29, tel. (33) 479 93 29, (33) 479 93 89 fax (33) 853 04 06 e-mail: admin@ops.strefa.pl Strona1
Routing średniozaawansowany i podstawy przełączania
Przygotował: mgr inż. Jarosław Szybiński Studium przypadku case study Semestr III Akademii Sieciowej CISCO Routing średniozaawansowany i podstawy przełączania Na podstawie dokumentu CCNA3_CS_pl.pdf pochodzącego
System operacyjny Linux
Paweł Rajba pawel.rajba@continet.pl http://kursy24.eu/ Zawartość modułu 15 DHCP Rola usługi DHCP Proces generowania dzierżawy Proces odnawienia dzierżawy Konfiguracja Agent przekazywania DHCP - 1 - Rola
76.Struktura oprogramowania rozproszonego.
76.Struktura oprogramowania rozproszonego. NajwaŜniejsze aspekty obiektowego programowania rozproszonego to: Współdziałanie (interoperability) modułów programowych na róŝnych maszynach. Wielokrotne wykorzystanie
Współpraca Integry z programami zewnętrznymi
Współpraca Integry z programami zewnętrznymi Uwaga! Do współpracy Integry z programami zewnętrznymi potrzebne są dodatkowe pliki. MoŜna je pobrać z sekcji Download -> Pozostałe po zalogowaniu do Strefy
Funkcje warstwy sieciowej. Podstawy wyznaczania tras. Dostarczenie pakietu od nadawcy od odbiorcy (RIP, IGRP, OSPF, EGP, BGP)
Wyznaczanie tras (routing) 1 Wyznaczanie tras (routing) 17 Funkcje warstwy sieciowej Podstawy wyznaczania tras Routing statyczny Wprowadzenie jednolitej adresacji niezaleŝnej od niŝszych warstw (IP) Współpraca
Wykład Nr 4. 1. Sieci bezprzewodowe 2. Monitorowanie sieci - polecenia
Sieci komputerowe Wykład Nr 4 1. Sieci bezprzewodowe 2. Monitorowanie sieci - polecenia Sieci bezprzewodowe Sieci z bezprzewodowymi punktami dostępu bazują na falach radiowych. Punkt dostępu musi mieć
ZESPÓŁ SZKÓŁ NR 9. Projekt lokalnej sieci komputerowej zapewniającej dostęp do Internetu.
ZESPÓŁ SZKÓŁ NR 9 IM. ROMUALDA TRAUGUTTA W KOSZALINIE Projekt lokalnej sieci komputerowej zapewniającej dostęp do Internetu. autorzy: mgr inŝ. Tomasz Pukiewicz mgr inŝ. Rafał Traczyk - 1 - 1. ZałoŜenia
Czym jest router?... 3 Vyatta darmowy router... 3 Vyatta podstawowe polecenia i obsługa... 3 Zarządzanie użytkownikami... 3 Uzupełnianie komend...
Czym jest router?... 3 Vyatta darmowy router... 3 Vyatta podstawowe polecenia i obsługa... 3 Zarządzanie użytkownikami... 3 Uzupełnianie komend... 4 Historia komend... 4 Wywołanie komend operacyjnych w
Budowa i oprogramowanie komputerowych systemów sterowania. Laboratorium 4. Metody wymiany danych w systemach automatyki DDE
Budowa i oprogramowanie komputerowych systemów sterowania Laboratorium 4 Metody wymiany danych w systemach automatyki DDE 1 Wprowadzenie do DDE DDE (ang. Dynamic Data Exchange) - protokół wprowadzony w
Wdrożenie modułu płatności eservice. dla systemu Zen Cart 1.3.9 1.5
Wdrożenie modułu płatności eservice dla systemu Zen Cart 1.3.9 1.5 - dokumentacja techniczna Wer. 01 Warszawa, styczeń 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie
Opis wdrożenia Platformy Technologicznej epodreczniki.pl na zasobach Poznańskiego Centrum Superkomputerowo-Sieciowego
Opis wdrożenia Platformy Technologicznej epodreczniki.pl na zasobach Poznańskiego Centrum Superkomputerowo-Sieciowego w ramach realizacji umowy pomostowej nr 427/PCSS/2016 Poznań, 21 lutego 2017 r. 1 Spis
Wdrożenie modułu płatności eservice. dla systemu oscommerce 2.3.x
Wdrożenie modułu płatności eservice dla systemu oscommerce 2.3.x - dokumentacja techniczna Wer. 01 Warszawa, styczeń 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie
Komunikacja Master-Slave w protokole PROFIBUS DP pomiędzy S7-300/S7-400
PoniŜszy dokument zawiera opis konfiguracji programu STEP7 dla sterowników S7 300/S7 400, w celu stworzenia komunikacji Master Slave z wykorzystaniem sieci PROFIBUS DP pomiędzy sterownikami S7 300 i S7
Ćwiczenie Konfiguracja statycznych oraz domyślnych tras routingu IPv4
Ćwiczenie Konfiguracja statycznych oraz domyślnych tras routingu IPv4 Topologia Tabela adresacji Urządzenie Interfejs Adres IP Maska podsieci Brama domyślna R1 G0/1 192.168.0.1 255.255.255.0 N/A S0/0/1
Konfigurowanie sieci VLAN
Konfigurowanie sieci VLAN 1 Wprowadzenie Sieć VLAN (ang. Virtual LAN) to wydzielona logicznie sieć urządzeń w ramach innej, większej sieci fizycznej. Urządzenia tworzące sieć VLAN, niezależnie od swojej
Dokonaj instalacji IIS opublikuj stronę internetową z pierwszych zajęć. Ukaże się kreator konfigurowania serwera i klikamy przycisk Dalej-->.
Dokonaj instalacji IIS opublikuj stronę internetową z pierwszych zajęć Ukaże się kreator konfigurowania serwera i klikamy przycisk Dalej-->. Następnie wybieramy Serwer aplikacji (IIS, ASP.NET) i klikamy
ZiMSK. Routing dynamiczny 1
ZiMSK dr inż. Łukasz Sturgulewski, luk@kis.p.lodz.pl, http://luk.kis.p.lodz.pl/ dr inż. Artur Sierszeń, asiersz@kis.p.lodz.pl dr inż. Andrzej Frączyk, a.fraczyk@kis.p.lodz.pl Routing dynamiczny 1 Wykład
Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania
Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 21 maja 2012 Historia dokumentu
1. Instalacja modułu w systemie Windows.
1. Instalacja modułu w systemie Windows. W urządzeniach dołączanych do sieci lokalnej LAN zastosowano moduły firmy DIGI. Sterowniki dostarczone przez producenta tworzą w systemie Windows wirtualny port
Komunikator internetowy w C#
PAŃSTWOWA WYśSZA SZKOŁA ZAWODOWA W ELBLĄGU INSTYTUT INFORMATYKI STOSOWANEJ Sprawozdanie Komunikator internetowy w C# autor: Artur Domachowski Elbląg, 2009 r. Komunikacja przy uŝyciu poczty internetowej
SIECI KOMPUTEROWE I TECHNOLOGIE INTERNETOWE
SIECI KOMPUTEROWE I TECHNOLOGIE INTERNETOWE, AiR r. I, sem. II Politechnika Gdańska Wydział Elektrotechniki i Automatyki Katedra Inżynierii Systemów Sterowania SIECI KOMPUTEROWE I TECHNOLOGIE INTERNETOWE
Tom 6 Opis oprogramowania
Część 4 Narzędzie do wyliczania wielkości oraz wartości parametrów stanu Diagnostyka stanu nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 30 maja 2012 Historia dokumentu Nazwa
Instalacja programu. Po naciśnięciu przycisku Dalej pojawi się okno, w którym naleŝy dokonać wyboru docelowej lokalizacji.
EuroSoft Apteka wer. dla Szpitali programu EuroSoft Sp z o.o. 02-220 Warszawa ul. Łopuszańska 32 tel.: (22) 44 888 44 www.eurosoft.com.pl programu Po umieszczeniu płyty CD w napędzie komputera uruchomiony
4. Podstawowa konfiguracja
4. Podstawowa konfiguracja Po pierwszym zalogowaniu się do urządzenia należy zweryfikować poprawność licencji. Można to zrobić na jednym z widżetów panelu kontrolnego. Wstępną konfigurację można podzielić
1 Powłoka programu Windows PowerShell... 1. 2 Skrypty programu Windows PowerShell... 37. 3 Zarządzanie dziennikami... 65
Spis treści Podziękowania... xi Wstęp... xiii 1 Powłoka programu Windows PowerShell... 1 Instalowanie programu Windows PowerShell... 1 Sprawdzanie instalacji za pomocą skryptu w języku VBScript... 1 WdraŜanie
router wielu sieci pakietów
Dzisiejsze sieci komputerowe wywierają ogromny wpływ na naszą codzienność, zmieniając to, jak żyjemy, pracujemy i spędzamy wolny czas. Sieci mają wiele rozmaitych zastosowań, wśród których można wymienić
Zdalna obsługa transcievera. H A M R A D I O D E L U X E R e m o t e S e r v e r C o n f i g u r a t i o n
Zdalna obsługa transcievera H A M R A D I O D E L U X E R e m o t e S e r v e r C o n f i g u r a t i o n Do poprawnej pracy zdalnego dostępu do radiostacji, niezbędne jest działające oprogramowanie Ham
Instrukcja EQU Kantech
Instrukcja EQU Kantech Pobranie konfiguracji Konfiguracje Kantecha do IFTER EQU pobieramy za pomocą opcji we właściwościach integracji Kantech wskazując lokalizacje katalogu..\data\kantech. Po wskazaniu
Lab 2 ĆWICZENIE 2 - VLAN. Rodzaje sieci VLAN
ĆWICZENIE 2 - VLAN Rodzaje sieci VLAN Sieć VLAN tworzą porty jednego lub wielu przełączników. Wyróżnia się dwie odmiany sieci VLAN: statyczne i dynamiczne. W statycznych sieciach VLAN porty te konfigurowane
LABORATORIUM SIECI KOMPUTEROWYCH (compnet.et.put.poznan.pl)
Wydział Elektroniki i Telekomunikacji POLITECHNIKA POZNAŃSKA fax: (+48 61) 665 25 72 ul. Piotrowo 3a, 60-965 Poznań tel: (+48 61) 665 22 93 LABORATORIUM SIECI KOMPUTEROWYCH (compnet.et.put.poznan.pl) Protokoły
Zakład Teleinformatyki i Telekomutacji LABORATORIUM SIECI
Zakład Teleinformatyki i Telekomutacji LABORATORIUM SIECI Instrukcja do ćwiczenia: Switching, VLAN & Trunking Przedmiot: Sieci Lokalne (LAN) Wojciech Mazurczyk Warszawa, kwiecień 2008 ZTiT. Zakład Teleinformatyki
Konfiguracja połączenia G.SHDSL punkt-punkt w trybie routing w oparciu o routery P-791R.
Konfiguracja połączenia G.SHDSL punkt-punkt w trybie routing w oparciu o routery P-791R. Topologia sieci: Lokalizacja B Lokalizacja A Niniejsza instrukcja nie obejmuje konfiguracji routera dostępowego
1. Instalacja systemu Integra 7
1. Instalacja systemu Integra 7 Wersja instalacyjna programu Integra 7 znajduje się na płycie CD-ROM. NaleŜy ją umieścić w odpowiednim napędzie, po czym nastąpi automatyczne uruchomienie programu instalacyjnego.
1.1 Ustawienie adresów IP oraz masek portów routera za pomocą konsoli
1. Obsługa routerów... 1 1.1 Ustawienie adresów IP oraz masek portów routera za pomocą konsoli... 1 1.2 Olicom ClearSight obsługa podstawowa... 2 1.3 Konfiguracja protokołu RIP... 5 Podgląd tablicy routingu...
Sieciowa instalacja Sekafi 3 SQL
Sieciowa instalacja Sekafi 3 SQL Niniejsza instrukcja opisuje instalację Sekafi 3 SQL w wersji sieciowej, z zewnętrznym serwerem bazy danych. Jeśli wymagana jest praca jednostanowiskowa, należy postępować
Tom 6 Opis oprogramowania
Część 9 Narzędzie do wyliczania wskaźników statystycznych Diagnostyka Stanu Nawierzchni - DSN Generalna Dyrekcja Dróg Krajowych i Autostrad Warszawa, 31 maja 2012 Historia dokumentu Nazwa dokumentu Nazwa
Backend Administratora
Backend Administratora mgr Tomasz Xięski, Instytut Informatyki, Uniwersytet Śląski Katowice, 2011 W tym celu korzystając z konsoli wydajemy polecenie: symfony generate:app backend Wówczas zostanie stworzona
Wykład 3 / Wykład 4. Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak
Wykład 3 / Wykład 4 Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak 1 Wprowadzenie do Modułu 3 CCNA-E Funkcje trzech wyższych warstw modelu OSI W jaki sposób ludzie wykorzystują
OBSŁUGA I KONFIGURACJA SIECI W WINDOWS
OBSŁUGA I KONFIGURACJA SIECI W WINDOWS Jak skonfigurować komputer pracujący pod kontrolą systemu operacyjnego Windows 7, tak aby uzyskać dostęp do internetu? Zakładamy, że komputer pracuje w małej domowej
KOMPUTEROWY SYSTEM WSPOMAGANIA OBSŁUGI JEDNOSTEK SŁUŻBY ZDROWIA KS-SOMED
KOMPUTEROWY SYSTEM WSPOMAGANIA OBSŁUGI JEDNOSTEK SŁUŻBY ZDROWIA KS-SOMED Podręcznik użytkownika Katowice 2010 Producent programu: KAMSOFT S.A. ul. 1 Maja 133 40-235 Katowice Telefon: (0-32) 209-07-05 Fax:
Laboratorium - Używanie programu Wireshark do obserwacji mechanizmu uzgodnienia trójetapowego TCP
Laboratorium - Używanie programu Wireshark do obserwacji mechanizmu uzgodnienia trójetapowego Topologia Cele Część 1: Przygotowanie Wireshark do przechwytywania pakietów Wybór odpowiedniego interfejsu
Generator Wniosków Płatniczych dla Programu Operacyjnego Kapitał Ludzki. Instrukcja Instalacji
Generator Wniosków Płatniczych dla Programu Operacyjnego Kapitał Ludzki Instrukcja Instalacji Aplikacja współfinansowana ze środków Unii Europejskiej w ramach Europejskiego Funduszu Społecznego Warszawa,
Laboratoria zdalne ZTiT
Zakład Teleinformatyki i Telekomutacji Laboratoria zdalne ZTiT Instrukcja Zdalny dostęp ZTiT. Zakład Teleinformatyki i Telekomutacji Instytut Telekomunikacji Wydział Elektroniki i Technik Informacyjnych
Instrukcja do laboratorium 1. Podstawowa konfiguracja środowiska MPLS (Multi-Protocol Label Switching)
Instrukcja do laboratorium 1 Podstawowa konfiguracja środowiska MPLS (Multi-Protocol Label Switching) Przed zajęciami proszę dokładnie zapoznać się z instrukcją i materiałami pomocniczymi dotyczącymi laboratorium.
Laboratorium Projektowanie i implementowanie schematu adresowania z zastosowaniem zmiennych masek podsieci
Laboratorium Projektowanie i implementowanie schematu adresowania z zastosowaniem zmiennych Topologia Cele Część 1: Określenie wymagań sieci Część 2: Projektowanie schematu adresacji z wykorzystaniem masek
Wdrożenie modułu płatności eservice. dla systemu Magento 1.4 1.9
Wdrożenie modułu płatności eservice dla systemu Magento 1.4 1.9 - dokumentacja techniczna Wer. 01 Warszawa, styczeń 2014 1 Spis treści: 1 Wstęp... 3 1.1 Przeznaczenie dokumentu... 3 1.2 Przygotowanie do
Laboratorium Ericsson HIS NAE SR-16
Laboratorium Ericsson HIS NAE SR-16 HIS WAN (HIS 2) Opis laboratorium Celem tego laboratorium jest poznanie zaawansowanej konfiguracji urządzenia DSLAM Ericsson HIS NAE SR-16. Konfiguracja ta umożliwi
Wykład 4: Protokoły TCP/UDP i usługi sieciowe. A. Kisiel,Protokoły TCP/UDP i usługi sieciowe
N, Wykład 4: Protokoły TCP/UDP i usługi sieciowe 1 Adres aplikacji: numer portu Protokoły w. łącza danych (np. Ethernet) oraz w. sieciowej (IP) pozwalają tylko na zaadresowanie komputera (interfejsu sieciowego),
SIECI KOMPUTEROWE LABORATORIUM 109
Michał Turek SIECI KOMPUTEROWE LABORATORIUM 109 Tematyka: Cisco IOS VRF Virtual Routing and Forwarding (VRF Lite). Zadanie A: Uruchomienie VRF 1. Virtual Routing and Forwarding (VRF) umoŝliwia wprowadzenie
Bramka IP 1 szybki start.
Bramka IP 1 szybki start. Instalacja i dostęp:... 2 Konfiguracja IP 1 do nawiązywania połączeń VoIP... 5 Konfiguracja serwera SIP... 5 Konfiguracja uŝytkownika User1... 6 IP Polska Sp. z o.o. 2012 www.ippolska.pl
Laboratorium - Przechwytywanie i badanie datagramów DNS w programie Wireshark
Laboratorium - Przechwytywanie i badanie datagramów DNS w programie Wireshark Topologia Cele Część 1: Zapisanie informacji dotyczących konfiguracji IP komputerów Część 2: Użycie programu Wireshark do przechwycenia
INFORMATOR TECHNICZNY WONDERWARE
Informator techniczny nr 106 18-09-2008 INFORMATOR TECHNICZNY WONDERWARE Konfiguracja sieci dla redundancji w Wonderware Application Server Funkcjonalność redundancji logiki jest wbudowana w Wonderware
Sterowniki urządzeń zewnętrznych w pracy lokalnej i sieciowej w programach firmy InsERT dla Windows
Sterowniki urządzeń zewnętrznych w pracy lokalnej i sieciowej w programach firmy InsERT dla Windows 1/5 SPIS TREŚCI 1. DEFINICJE POJĘĆ... 3 2. TRYBY PRACY... 3 2.1 TRYB LOKALNY - APLIKACJA I STEROWNIK
ANALIZA BEZPIECZEŃSTWA SIECI MPLS VPN. Łukasz Polak Opiekun: prof. Zbigniew Kotulski
ANALIZA BEZPIECZEŃSTWA SIECI MPLS VPN Łukasz Polak Opiekun: prof. Zbigniew Kotulski Plan prezentacji 2 1. Wirtualne sieci prywatne (VPN) 2. Architektura MPLS 3. Zasada działania sieci MPLS VPN 4. Bezpieczeństwo
Rys. 1. Sieć uczelniana
CCNA-2 Skills Exam Głównym celem Skills Exam jest sprawdzenie umiejętności praktycznych. Dodatkowo Skills Exam ma zachęcić i zmobilizować do powtórzenia materiału z drugiego semestru kursu CCNA, z myślą
SIECI KOMPUTEROWE Adresowanie IP
Adresowanie IP Podstawowa funkcja protokołu IP (Internet Protocol) polega na dodawaniu informacji o adresie do pakietu danych i przesyłaniu ich poprzez sieć do właściwych miejsc docelowych. Aby umożliwić
BACKUP BAZ DANYCH FIREBIRD
BACKUP BAZ DANYCH FIREBIRD SPIS TREŚCI Informacje ogólne... 2 Tworzenie projektu... 2 Krok 1: Informacje podstawowe... 2 Krok 2: Dane... 3 Backup bazy umieszczonej na serwerze... 3 Bezpośredni backup pliku
Okno logowania. Okno aplikacji. 1. Logowanie i rejestracja
1. Logowanie i rejestracja Aby wysłać zlecenie do laboratorium fotograficznego musisz mieć załoŝone konto. Jest to niezbędne do weryfikacji twojej osoby i daje pewność, Ŝe osoby nieupowaŝnione nie będą
Mechanizmy pracy równoległej. Jarosław Kuchta
Mechanizmy pracy równoległej Jarosław Kuchta Zagadnienia Algorytmy wzajemnego wykluczania algorytm Dekkera Mechanizmy niskopoziomowe przerwania mechanizmy ochrony pamięci instrukcje specjalne Mechanizmy
RPC. Zdalne wywoływanie procedur (ang. Remote Procedure Calls )
III RPC Zdalne wywoływanie procedur (ang. Remote Procedure Calls ) 1. Koncepcja Aplikacja wywołanie procedury parametry wyniki wykonanie procedury wynik komputer klienta komputer serwera Zaletą takiego
MASKI SIECIOWE W IPv4
MASKI SIECIOWE W IPv4 Maska podsieci wykorzystuje ten sam format i sposób reprezentacji jak adresy IP. Różnica polega na tym, że maska podsieci posiada bity ustawione na 1 dla części określającej adres
Projektowanie zabezpieczeń Centrów Danych oraz innych systemów informatycznych o podwyższonych wymaganiach bezpieczeństwa
Projektowanie zabezpieczeń Centrów Danych oraz innych systemów informatycznych o podwyższonych wymaganiach bezpieczeństwa dr inż. Mariusz Stawowski mariusz.stawowski@clico.pl Agenda Wprowadzenie Specyficzne
PODSTAWOWA KONFIGURACJA LINKSYS WRT300N
PODSTAWOWA KONFIGURACJA LINKSYS WRT300N 1. Topologia połączenia sieci WAN i LAN (jeśli poniższa ilustracja jest nieczytelna, to dokładny rysunek topologii znajdziesz w pliku network_konfigurowanie_linksys_wrt300n_cw.jpg)
Instrukcja konfiguracji urządzenia Comarch TNA Gateway Plus
Instrukcja konfiguracji urządzenia Comarch TNA Gateway Plus COMARCH TNA Szanowni Państwo, dziękujemy za wybór usługi Comarch TNA oraz urządzenia Comarch TNA Gateway Plus. Mamy nadzieję, że korzystanie
1. Wprowadzenie...9. 2. Środowisko multimedialnych sieci IP... 11. 3. Schemat H.323... 19
Spis treści 3 1. Wprowadzenie...9 2. Środowisko multimedialnych sieci IP... 11 2.1. Model odniesienia... 11 2.2. Ewolucja technologii sieciowych...12 2.3. Specyfika ruchowa systemów medialnych...13 2.4.
Instalacja programu Ozon.
Instalacja programu Ozon. Przykładowa topologia sieci w której moŝe pracować program Ozon: Jak widać na powyŝszym obrazku baza danych zainstalowana jest na jednym komputerze, który określany jest mianem
Instrukcja konfiguracji funkcji skanowania
Instrukcja konfiguracji funkcji skanowania WorkCentre M123/M128 WorkCentre Pro 123/128 701P42171_PL 2004. Wszystkie prawa zastrzeżone. Rozpowszechnianie bez zezwolenia przedstawionych materiałów i informacji