W czasie implementacji nie napotkano krytycznych problemów. Wszystkie węzły spełniają załoŝone wymagania oraz realizują załoŝoną funkcjonalność.

Wielkość: px
Rozpocząć pokaz od strony:

Download "W czasie implementacji nie napotkano krytycznych problemów. Wszystkie węzły spełniają załoŝone wymagania oraz realizują załoŝoną funkcjonalność."

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ą: dostęp do interfejsu konfiguracyjnego dla węzła PD-PE, dostęp do interfejsu konfiguracyjnego dla węzła TRC-PE, dostęp do interfejsu konfiguracyjnego dla węzła PE-PE, dostęp do interfejsu konfiguracyjnego dla węzła ROMAN, 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

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

Bardziej szczegółowo

Instrukcje dotyczące funkcji zarządzania pasmem w urządzeniach serii ZyWALL.

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

Bardziej szczegółowo

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

Bardziej szczegółowo

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

Bardziej szczegółowo

Integracja systemów sterowania i sterowanie rozproszone 5 R

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

Bardziej szczegółowo

RUTERY. Dr inŝ. Małgorzata Langer

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)

Bardziej szczegółowo

Protokół BGP Podstawy i najlepsze praktyki Wersja 1.0

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

Bardziej szczegółowo

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

Bardziej szczegółowo

Podstawowe protokoły transportowe stosowane w sieciach IP cz.2

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

Bardziej szczegółowo

Rys. 1. Wynik działania programu ping: n = 5, adres cyfrowy. Rys. 1a. Wynik działania programu ping: l = 64 Bajty, adres mnemoniczny

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

Bardziej szczegółowo

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV

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

Bardziej szczegółowo

Instrukcja Instalacji

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

Bardziej szczegółowo

Bramka IP 2R+L szybki start.

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

Bardziej szczegółowo

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

Bardziej szczegółowo

Podstawowe protokoły transportowe stosowane w sieciach IP cz.1

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

Bardziej szczegółowo

System operacyjny Linux

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

Bardziej szczegółowo

Routing średniozaawansowany i podstawy przełączania

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

Bardziej szczegółowo

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

Bardziej szczegółowo

Komunikator internetowy w C#

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

Bardziej szczegółowo

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 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ą

Bardziej szczegółowo

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

Bardziej szczegółowo

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

Bardziej szczegółowo

Instrukcja uŝytkownika

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

Bardziej szczegółowo

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania

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

Bardziej szczegółowo

LABORATORIUM SIECI KOMPUTEROWYCH (compnet.et.put.poznan.pl)

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

Bardziej szczegółowo

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

Bardziej szczegółowo

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

Bardziej szczegółowo

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.

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

Bardziej szczegółowo

Wykład Nr 4. 1. Sieci bezprzewodowe 2. Monitorowanie sieci - polecenia

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ć

Bardziej szczegółowo

Współpraca z platformą Emp@tia. dokumentacja techniczna

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

Bardziej szczegółowo

1. Instalacja modułu w systemie Windows.

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

Bardziej szczegółowo

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

Bardziej szczegółowo

Graficzny terminal sieciowy ABA-X3. część druga. Podstawowa konfiguracja terminala

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

Bardziej szczegółowo

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

Bardziej szczegółowo

Komunikacja Master-Slave w protokole PROFIBUS DP pomiędzy S7-300/S7-400

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

Bardziej szczegółowo

Tom 6 Opis oprogramowania

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

Bardziej szczegółowo

Teoretyczne wprowadzenie do programu pocztowego Microsoft Outlook 2007

Teoretyczne wprowadzenie do programu pocztowego Microsoft Outlook 2007 Teoretyczne wprowadzenie do programu pocztowego Microsoft Outlook 2007 Zawartość 1 WSTĘP 2 2 BUDOWA OKNA PROGRAMU MICROSOFT OUTLOOK 2007 3 3 USTAWIENIA WIDOKU EKRANU 3 4 KORZYSTANIE Z PROGRAMU MICROSOFT

Bardziej szczegółowo

Instrukcja do laboratorium 1. Podstawowa konfiguracja środowiska MPLS (Multi-Protocol Label Switching)

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.

Bardziej szczegółowo

Konfigurowanie sieci VLAN

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

Bardziej szczegółowo

ZESPÓŁ SZKÓŁ NR 9. Projekt lokalnej sieci komputerowej zapewniającej dostęp do Internetu.

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

Bardziej szczegółowo

Generator Wniosków Płatniczych dla Programu Operacyjnego Kapitał Ludzki. Instrukcja Instalacji

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,

Bardziej szczegółowo

SPECYFIKACJA TECHNICZNA. LP. Parametry wymagane Parametry oferowane (pełny opis

SPECYFIKACJA TECHNICZNA. LP. Parametry wymagane Parametry oferowane (pełny opis Załącznik nr 3A do SIWZ DZP-0431-1620/2008 SPECYFIKACJA TECHNICZNA Właściwości systemu zabezpieczeń sieciowych UTM (Unified Threat Management) 1. 2. 3. 4. 5. 6. 7. LP. Parametry wymagane Parametry oferowane

Bardziej szczegółowo

Rys. 1. Sieć uczelniana

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ą

Bardziej szczegółowo

SIECI KOMPUTEROWE I TECHNOLOGIE INTERNETOWE

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

Bardziej szczegółowo

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

Bardziej szczegółowo

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

Bardziej szczegółowo

Tom 6 Opis oprogramowania

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

Bardziej szczegółowo

Współpraca Integry z programami zewnętrznymi

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

Bardziej szczegółowo

Narzędzia i aplikacje Java EE. Usługi sieciowe Paweł Czarnul pczarnul@eti.pg.gda.pl

Narzędzia i aplikacje Java EE. Usługi sieciowe Paweł Czarnul pczarnul@eti.pg.gda.pl Narzędzia i aplikacje Java EE Usługi sieciowe Paweł Czarnul pczarnul@eti.pg.gda.pl Niniejsze opracowanie wprowadza w technologię usług sieciowych i implementację usługi na platformie Java EE (JAX-WS) z

Bardziej szczegółowo

1 Powłoka programu Windows PowerShell... 1. 2 Skrypty programu Windows PowerShell... 37. 3 Zarządzanie dziennikami... 65

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

Bardziej szczegółowo

Wykład 4: Protokoły TCP/UDP i usługi sieciowe. A. Kisiel,Protokoły TCP/UDP i usługi sieciowe

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

Bardziej szczegółowo

PODSTAWOWA KONFIGURACJA LINKSYS WRT300N

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)

Bardziej szczegółowo

(Pluggable Authentication Modules). Wyjaśnienie technologii.

(Pluggable Authentication Modules). Wyjaśnienie technologii. Bezpieczeństwo systemów komputerowych. Temat seminarium: Moduły PAM (Pluggable Authentication Modules). Wyjaśnienie technologii Autor: Bartosz Hetmański Moduły PAM (Pluggable Authentication Modules). Wyjaśnienie

Bardziej szczegółowo

Laboratoria zdalne ZTiT

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

Bardziej szczegółowo

4. Podstawowa konfiguracja

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ć

Bardziej szczegółowo

8. Sieci lokalne. Konfiguracja połączenia lokalnego

8. Sieci lokalne. Konfiguracja połączenia lokalnego 8. Sieci lokalne Ćwiczenia zawarte w tym rozdziale pozwolą na podłączenie komputera z zainstalowanym systemem Windows XP do lokalnej sieci komputerowej. Podstawowym protokołem sieciowym dla systemu Windows

Bardziej szczegółowo

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

Bardziej szczegółowo

Zakład Teleinformatyki i Telekomutacji LABORATORIUM SIECI

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

Bardziej szczegółowo

1. Wprowadzenie...9. 2. Środowisko multimedialnych sieci IP... 11. 3. Schemat H.323... 19

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.

Bardziej szczegółowo

Instrukcja administratora Agenta Administracji i Aktualizacji Aplikacji oraz baz danych Polskiego FADN oraz pobierania danych słownikowych

Instrukcja administratora Agenta Administracji i Aktualizacji Aplikacji oraz baz danych Polskiego FADN oraz pobierania danych słownikowych Instrukcja administratora Agenta Administracji i Aktualizacji Aplikacji oraz baz danych Polskiego FADN oraz pobierania danych słownikowych Opracowali: ElŜbieta JUCHNOWSKA, Darek OSUCH Wersja i podstawowe

Bardziej szczegółowo

Zarządzanie systemem komendy

Zarządzanie systemem komendy Zarządzanie systemem komendy Nazwa hosta set system host name nazwa_hosta show system host name delete system host name Nazwa domeny set system domain name nazwa_domeny show system domain name delete system

Bardziej szczegółowo

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

Bardziej szczegółowo

Komunikacja i wymiana danych

Komunikacja i wymiana danych Budowa i oprogramowanie komputerowych systemów sterowania Wykład 10 Komunikacja i wymiana danych Metody wymiany danych Lokalne Pliki txt, csv, xls, xml Biblioteki LIB / DLL DDE, FastDDE OLE, COM, ActiveX

Bardziej szczegółowo

Podstawowa konfiguracja routerów. Interfejsy sieciowe routerów. Sprawdzanie komunikacji w sieci. Podstawy routingu statycznego

Podstawowa konfiguracja routerów. Interfejsy sieciowe routerów. Sprawdzanie komunikacji w sieci. Podstawy routingu statycznego Podstawowa konfiguracja routerów Interfejsy sieciowe routerów Sprawdzanie komunikacji w sieci Podstawy routingu statycznego Podstawy routingu dynamicznego 2 Plan prezentacji Tryby pracy routera Polecenia

Bardziej szczegółowo

Routing dynamiczny... 2 Czym jest metryka i odległość administracyjna?... 3 RIPv1... 4 RIPv2... 4 Interfejs pasywny... 5 Podzielony horyzont...

Routing dynamiczny... 2 Czym jest metryka i odległość administracyjna?... 3 RIPv1... 4 RIPv2... 4 Interfejs pasywny... 5 Podzielony horyzont... Routing dynamiczny... 2 Czym jest metryka i odległość administracyjna?... 3 RIPv1... 4 RIPv2... 4 Interfejs pasywny... 5 Podzielony horyzont... 5 Podzielony horyzont z zatruciem wstecz... 5 Vyatta i RIP...

Bardziej szczegółowo

Przypadki testowe. Spis treści. Plan testów. From Sęp. Wstęp. 2 Plan testów

Przypadki testowe. Spis treści. Plan testów. From Sęp. Wstęp. 2 Plan testów Przypadki testowe From Sęp Spis treści 1 Wstęp 2 Plan testów 3 Testy bazy danych 4 Testy serwera 5 Testy aplikacji klienckiej 6 Testy interfejsu webowego 7 Testy integracyjne 8 Testy wydajności 8.1 Baza

Bardziej szczegółowo

Veronica. Wizyjny system monitorowania obiektów budowlanych. Instrukcja oprogramowania

Veronica. Wizyjny system monitorowania obiektów budowlanych. Instrukcja oprogramowania Veronica Wizyjny system monitorowania obiektów budowlanych Instrukcja oprogramowania 1 Spis treści 1. Aplikacja do konfiguracji i nadzoru systemu Veronica...3 1.1. Okno główne aplikacji...3 1.2. Edycja

Bardziej szczegółowo

MASKI SIECIOWE W IPv4

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

Bardziej szczegółowo

Akceleracja symulacji HES-AHDL. 1. Rozpoczęcie pracy aplikacja VNC viewer

Akceleracja symulacji HES-AHDL. 1. Rozpoczęcie pracy aplikacja VNC viewer Akceleracja symulacji HES-AHDL 1. Rozpoczęcie pracy aplikacja VNC viewer Rys. 1 Ultra VNCViewer Karta HES jest umieszczona w komputerze PC w pokoju 502 C-3 na serwerze VNC o adresie IP 149.156.121.112.

Bardziej szczegółowo

BACKUP BAZ DANYCH FIREBIRD

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

Bardziej szczegółowo

Instrukcja konfiguracji funkcji skanowania

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

Bardziej szczegółowo

Instalacja programu. Po naciśnięciu przycisku Dalej pojawi się okno, w którym naleŝy dokonać wyboru docelowej lokalizacji.

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

Bardziej szczegółowo

Instrukcja integratora - obsługa dużych plików w epuap2

Instrukcja integratora - obsługa dużych plików w epuap2 Instrukcja integratora - obsługa dużych plików w epuap2 Wersja: 1.1 Strona 1 z 18 Spis treści SPIS TREŚCI... 2 WPROWADZENIE ORAZ INFORMACJE OGÓLNE... 3 1.1 WSTĘP... 3 1.2 WARUNKI KONIECZNE DO SPEŁNIENIA

Bardziej szczegółowo

Podstawy MPLS. pijablon@cisco.com. PLNOG4, 4 Marzec 2010, Warszawa 1

Podstawy MPLS. pijablon@cisco.com. PLNOG4, 4 Marzec 2010, Warszawa 1 Podstawy MPLS Piotr Jabłoński pijablon@cisco.com 1 Plan prezentacji Co to jest MPLS i jak on działa? Czy moja sieć potrzebuje MPLS? 2 Co to jest MPLS? Jak on działa? 3 Co to jest MPLS? Multi Protocol Label

Bardziej szczegółowo

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

Bardziej szczegółowo

Wprowadzenie do projektu QualitySpy

Wprowadzenie do projektu QualitySpy Wprowadzenie do projektu QualitySpy Na podstawie instrukcji implementacji prostej funkcjonalności. 1. Wstęp Celem tego poradnika jest wprowadzić programistę do projektu QualitySpy. Będziemy implementować

Bardziej szczegółowo

Sieciowa instalacja Sekafi 3 SQL

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ć

Bardziej szczegółowo

ZiMSK dr inż. Łukasz Sturgulewski, luk@kis.p.lodz.pl, http://luk.kis.p.lodz.pl/ DHCP

ZiMSK dr inż. Łukasz Sturgulewski, luk@kis.p.lodz.pl, http://luk.kis.p.lodz.pl/ DHCP 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 DHCP 1 Wykład Dynamiczna konfiguracja

Bardziej szczegółowo

Instalacja programu Ozon.

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

Bardziej szczegółowo

FAQ: 00000013/PL Data: 16/11/2007 Programowanie przez Internet: Konfiguracja modułów SCALANCE S 612 V2 do komunikacji z komputerem przez VPN

FAQ: 00000013/PL Data: 16/11/2007 Programowanie przez Internet: Konfiguracja modułów SCALANCE S 612 V2 do komunikacji z komputerem przez VPN Za pomocą dwóch modułów SCALANCE S 612 V2* (numer katalogowy: 6GK5612-0BA00-2AA3) chcemy umoŝliwić dostęp do sterownika podłączonego do zabezpieczonej sieci wewnętrznej. Komputer, z którego chcemy mieć

Bardziej szczegółowo

Konfiguracja połączenia internetowego serwera w pracowni Microsoft

Konfiguracja połączenia internetowego serwera w pracowni Microsoft Konfiguracja połączenia internetowego serwera w pracowni Microsoft W przypadku problemów z zpołączniem internetowym zalecaną listą czynnosci jest: Zalogowanie się na serwerze jako administrator Uruchomienie

Bardziej szczegółowo

Routing statyczny vs. dynamiczny. Routing dynamiczny. Routing statyczny vs. dynamiczny. Wymagania stawiane protokołom routingu

Routing statyczny vs. dynamiczny. Routing dynamiczny. Routing statyczny vs. dynamiczny. Wymagania stawiane protokołom routingu Routing dynamiczny 1 Routing dynamiczny 5 Routing statyczny vs. dynamiczny Routing dynamiczny tablice routingu konfigurowane przez administratora (-ów), przewidywalny trasa po której pakiet jest przesyłany

Bardziej szczegółowo

Podziękowania... xv. Wstęp... xvii

Podziękowania... xv. Wstęp... xvii Spis treści Podziękowania... xv Wstęp... xvii Instrukcja budowy laboratorium... xvii Przygotowanie komputerów Windows Server 2008... xviii Korzystanie z dołączonego CD... xviii Instalowanie testów ćwiczeniowych...

Bardziej szczegółowo

Tworzenie aplikacji GIS w technologii Flex. Tomasz Turowski Esri Polska

Tworzenie aplikacji GIS w technologii Flex. Tomasz Turowski Esri Polska Tworzenie aplikacji GIS w technologii Flex Tomasz Turowski Esri Polska Rodzina produktów bazujących na Fleksie ArcGIS API for Flex zbiór klas wprowadzających funkcjonalności mapowe do środowiska Flex.

Bardziej szczegółowo

Bramka IP 1 szybki start.

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

Bardziej szczegółowo

FAQ: 00000012/PL Data: 19/11/2007 Programowanie przez Internet: Przekierowanie portu na SCALANCE S 612 w celu umo

FAQ: 00000012/PL Data: 19/11/2007 Programowanie przez Internet: Przekierowanie portu na SCALANCE S 612 w celu umo W tym dokumencie opisano przekierowanie portu na sprzętowym firewall u SCALANCE S 612 V2* (numer katalogowy: 6GK5612-0BA00-2AA3) w celu umoŝliwienia komunikacji STEP 7 ze sterownikiem przez sieć Ethernet/Internet.

Bardziej szczegółowo

app/ - folder zawiera pliki konfiguracyjne dla całej aplikacji src/ - folder zawiera cały kod PHP aplikacji

app/ - folder zawiera pliki konfiguracyjne dla całej aplikacji src/ - folder zawiera cały kod PHP aplikacji Baza danych i ORM Projekt zestaw usług dostępnych pod daną domeną. Aplikacja niezależnie działające programy/serwisy (w obrębie pojektu). Zwyczajowo projekt posiada dwie aplikacje: Frontend Backend Moduł

Bardziej szczegółowo

1 Implementowanie i konfigurowanie infrastruktury wdraŝania systemu Windows... 1

1 Implementowanie i konfigurowanie infrastruktury wdraŝania systemu Windows... 1 Spis treści Wstęp... xi Wymagania sprzętowe (Virtual PC)... xi Wymagania sprzętowe (fizyczne)... xii Wymagania programowe... xiii Instrukcje instalowania ćwiczeń... xiii Faza 1: Tworzenie maszyn wirtualnych...

Bardziej szczegółowo

Routing. mgr inż. Krzysztof Szałajko

Routing. mgr inż. Krzysztof Szałajko Routing mgr inż. Krzysztof Szałajko Modele odniesienia 7 Aplikacji 6 Prezentacji 5 Sesji 4 Transportowa 3 Sieciowa 2 Łącza danych 1 Fizyczna Aplikacji Transportowa Internetowa Dostępu do sieci Wersja 1.0

Bardziej szczegółowo

Wykład 3: Internet i routing globalny. A. Kisiel, Internet i routing globalny

Wykład 3: Internet i routing globalny. A. Kisiel, Internet i routing globalny Wykład 3: Internet i routing globalny 1 Internet sieć sieci Internet jest siecią rozproszoną, globalną, z komutacją pakietową Internet to sieć łącząca wiele sieci Działa na podstawie kombinacji protokołów

Bardziej szczegółowo

Wykład 2: Budowanie sieci lokalnych. A. Kisiel, Budowanie sieci lokalnych

Wykład 2: Budowanie sieci lokalnych. A. Kisiel, Budowanie sieci lokalnych Wykład 2: Budowanie sieci lokalnych 1 Budowanie sieci lokalnych Technologie istotne z punktu widzenia konfiguracji i testowania poprawnego działania sieci lokalnej: Protokół ICMP i narzędzia go wykorzystujące

Bardziej szczegółowo

Dysk CD (z Oprogramowaniem i Podręcznikiem użytkownika)

Dysk CD (z Oprogramowaniem i Podręcznikiem użytkownika) Do skonfigurowania urządzenia może posłużyć każda nowoczesna przeglądarka, np. Internet Explorer 6 lub Netscape Navigator 7.0. DP-G310 Bezprzewodowy serwer wydruków AirPlus G 2,4GHz Przed rozpoczęciem

Bardziej szczegółowo

Konfiguracja parametrów sondy cyfrowo analogowej typu CS-26/RS/U

Konfiguracja parametrów sondy cyfrowo analogowej typu CS-26/RS/U Konfiguracja parametrów sondy cyfrowo analogowej typu CS-26/RS/U Ostrów Wielkopolski, 25.02.2011 1 Sonda typu CS-26/RS/U posiada wyjście analogowe napięciowe (0...10V, lub 0...5V, lub 0...4,5V, lub 0...2,5V)

Bardziej szczegółowo

Warsztaty ewon. efive

Warsztaty ewon. efive Warsztaty ewon efive Product Update, 2014 Spis treści Wstęp... 3 1. Uruchomienie okna konfiguracji urządzenia efive... 4 2. Konfiguracja interfejsu sieciowego.... 5 3. Konfiguracja VPN.... 6 4. Konfiguracja

Bardziej szczegółowo

Instrukcja uŝytkownika narzędzia Skaner SMTP TP. Uruchamianie aplikacji

Instrukcja uŝytkownika narzędzia Skaner SMTP TP. Uruchamianie aplikacji Instrukcja uŝytkownika narzędzia Skaner SMTP TP W związku z wprowadzeniem dodatkowego profilu dla usługi "Bezpieczny Dostęp", który ogranicza komunikację i wpływa na funkcjonowanie poczty elektronicznej,

Bardziej szczegółowo

Spis treúci. Księgarnia PWN: Wayne Lewis - Akademia sieci Cisco. CCNA semestr 3

Spis treúci. Księgarnia PWN: Wayne Lewis - Akademia sieci Cisco. CCNA semestr 3 Księgarnia PWN: Wayne Lewis - Akademia sieci Cisco. CCNA semestr 3 Spis treúci Informacje o autorze...9 Informacje o redaktorach technicznych wydania oryginalnego...9 Podziękowania...10 Dedykacja...11

Bardziej szczegółowo

KOMPUTEROWY SYSTEM WSPOMAGANIA OBSŁUGI JEDNOSTEK SŁUŻBY ZDROWIA KS-SOMED

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:

Bardziej szczegółowo

INSTRUKCJA OBSŁUGI USTAWIEŃ DYNAMICZNIE PRZEDZIELANYCH ADRESÓW IP W URZĄDZENIACH SYSTEMU IP-PRO ORAZ REJESTRATORACH MY-DVR

INSTRUKCJA OBSŁUGI USTAWIEŃ DYNAMICZNIE PRZEDZIELANYCH ADRESÓW IP W URZĄDZENIACH SYSTEMU IP-PRO ORAZ REJESTRATORACH MY-DVR INSTRUKCJA OBSŁUGI USTAWIEŃ DYNAMICZNIE PRZEDZIELANYCH ADRESÓW IP W URZĄDZENIACH SYSTEMU IP-PRO ORAZ REJESTRATORACH MY-DVR UWAGA Aby zapewnić niezawodną pracę urządzenia, przed przystąpieniem do jego obsługi

Bardziej szczegółowo

Konfiguracja dostępu zdalnego z wykorzystaniem tunelu VPN pomiędzy SCALANCE S623 a SOFTNET Security Client

Konfiguracja dostępu zdalnego z wykorzystaniem tunelu VPN pomiędzy SCALANCE S623 a SOFTNET Security Client Konfiguracja dostępu zdalnego z wykorzystaniem tunelu VPN pomiędzy SCALANCE S623 a SOFTNET Security Client 1. Wstęp W tym przykładzie, funkcja tunelu VPN konfigurowana będzie z wykorzystaniem widoku standard

Bardziej szczegółowo

Konfigurowanie sterownika BX9000 firmy Beckhoff wprowadzenie. 1. Konfiguracja pakietu TwinCAT do współpracy ze sterownikiem BX9000

Konfigurowanie sterownika BX9000 firmy Beckhoff wprowadzenie. 1. Konfiguracja pakietu TwinCAT do współpracy ze sterownikiem BX9000 Konfigurowanie sterownika BX9000 firmy Beckhoff wprowadzenie 1. Konfiguracja pakietu TwinCAT do współpracy ze sterownikiem BX9000 Stanowisko laboratoryjne ze sterownikiem BX9000 Sterownik BX9000 należy

Bardziej szczegółowo