Usługi i sieci teleinformatyczne następnej generacji aspekty techniczne, aplikacyjne i rynkowe
|
|
- Dagmara Niewiadomska
- 7 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/A.1 Tytuł raportu: Analiza architektur proponowanych dla realizacji sieci IP QoS Przewidywany termin dostarczenia raportu: 30/06/08 Rzeczywisty termin dostarczenia raportu: 25/06/08 Kierownik zadania: Wojciech Burakowski Wykonawcy: Halina Tarasiuk, Wojciech Burakowski, Andrzej Bęben, Piotr Krawiec, Jarosław Śliwiński Abstrakt: Raport przedstawia analizę architektur proponowanych dla sieci IP z gwarancją jakości obsługi (IntServ i DiffServ) oraz stan standaryzacji dotyczącej architektury sieci następnej generacji NGN. Prezentuje również możliwości zastosowania techniki MPLS w sieciach QoS IP. Ostatni rozdział raportu zawiera wnioski i sugestie dotyczące architektury systemu tworzonego w ramach projektu, które wynikają z realizacji zadania A.1. Słowa kluczowe: IntServ, DiffServ, IMS, NGN, TISPAN, RACF, MPLS
2 Streszczenie W raporcie dokonano analizy architektur oraz stanu standaryzacji dotyczących realizacji sieci IP z gwarancją jakości obsługi QoS. W pierwszej części raportu przedstawiono dwie architektury dla sieci IP QoS zaproponowane przez IETF: IntServ oraz DiffServ. Architektura IntServ pozwala zapewnić ścisłe gwarancje QoS dzięki rezerwacji zasobów (dla pojedynczego lub zbiorczego strumienia) w każdym węźle i łączu danej ścieżki. Jednakże konieczność przeprowadzenia procesu zestawiania połączenia w sieci (wykonywanego za pomocą protokołu sygnalizacyjnego RSVP) i przechowywania informacji o połączeniu w każdym ruterze należącym do danej ścieżki pomiędzy użytkownikami końcowymi, spowodowały, iż architektura IntServ rozpatrywana jest jako rozwiązanie o ograniczonej skalowalności. W związku z tym rozwój jej został zarzucony na rzecz bardziej skalowalnej architektury DiffServ. Główna koncepcja DiffServ polega na tym, iż rutery brzegowe obsługują pojedyncze strumienie pakietów, natomiast w sieci szkieletowej obsługa odbywa się na podstawie strumieni zbiorczych (klas ruchu), zgodnie z przyjętymi modelami przekazu pakietów (tzw. PHB). Poprzez odpowiednio zdefiniowane PHB, DiffServ pozwala na różnicowanie jakości obsługi poszczególnych klas ruchu. Celem zapewnienia ścisłych gwarancji QoS dla poszczególnych strumieni pakietów konieczne jest jednak rozszerzenie architektury DiffServ o dodatkowe elementy, którymi są mechanizmy realizujące funkcje sterowania przyjmowaniem nowych wywołań AC, przydziału zasobów dla połączeń i obsługi żądań generowanych przez użytkownika. Kolejna część raportu dotyczy analizy stanu standaryzacji sieci następnej generacji NGN, której jedną z podstawowych cech jest zapewnienie jakości przekazu pakietów od końca do końca. Prace standaryzacyjne, mające na celu specyfikację sieci NGN, prowadzone są przez różne organizacje, m.in. 3GPP, ITU-T oraz ETSI. Cechą wspólną proponowanych rozwiązań jest podział funkcjonalności systemu na dwie niezależne warstwy: usługową i transportową. System IMS, opracowany przez 3GPP, odpowiedzialny jest za zarządzanie multimedialnymi usługami oferowanymi użytkownikowi, stanowi zatem przykład realizacji warstwy usługowej, bez określania aspektów warstwy transportowej. Z kolei architektura TISPAN, zaproponowana przez ETSI, definiuje zarówno płaszczyznę usługową, jak i transportową, jednakże obejmuje swym zasięgiem jedynie obszar sieci dostępowej i ruter brzegowy sieci szkieletowej. Ostatnia z prezentowanych specyfikacji, zdefiniowana przez ITU-T, jest opracowaniem kompleksowym, obejmującym wszystkie elementy architektury sieci NGN. W dalszej części rozdziału zostały przedstawione elementy funkcjonalne tej architektury realizujące funkcje związane z zarządzaniem sposobem przesyłania danych, metody obsługi żądania QoS oraz mechanizmy QoS przewidziane dla sieci ITU-T NGN. Na zakończenie, jako przykład implementacji elementów architektury NGN, zaprezentowano system opracowany w ramach projektu 6.PR EuQoS. Następny rozdział raportu prezentuje stan standaryzacji oraz możliwości wykorzystania techniki MPLS w sieci IP QoS. W ramach IETF opracowano zasady współpracy pomiędzy techniką MPLS a DiffServ. Zdefiniowano dwie metody przyporządkowania pakietów przenoszonych w ramach ścieżek MPLS do klas usług zdefiniowanych w technice DiffServ: (1) odwzorowanie każdej klasy usług na osobną ścieżkę MPLS, (2) przyporządkowanie pakietów przenoszonych w ramach danej 2
3 ścieżki MPLS do różnych klas usług poprzez ustawienie pola EXP w nagłówku MPLS. Technika MPLS w połączeniu z DiffServ umożliwia zestawianie niezależnych ścieżek MPLS dla poszczególnych klas usług oraz optymalizację zasobów sieci z uwzględnieniem wymagań oferowanych usług. Ostatni rozdział raportu zawiera, wynikające z realizacji zadania A.1, następujące wnioski i zalecenia dla projektu: Projektowany system powinien uwzględniać elementy architektury ITU-T NGN, zwłaszcza w aspektach dotyczących obsługi żądań i rezerwacji zasobów. W szczególności, następujące aspekty architektury ITU-T NGN powinny być wzięte pod uwagę: o Dekompozycja funkcjonalności systemu na płaszczyznę usług (funkcje SCF) i płaszczyznę transportową (funkcje RACF i NACF); o Realizacja połączeń na żądanie (zakładany scenariusz obsługi żądania QoS generowanego przez użytkownika/aplikację push mode); o Użyte protokoły komunikacyjne powinny być zgodne z protokołami objętymi standaryzacją i zalecanymi dla architektury NGN. Stosując powyższą zasadę, gwarantujemy możliwość potencjalnego rozwoju zaprojektowanego systemu poprzez współpracę z innym systemami zgodnymi ze specyfikacją ITU. Warstwę transportową systemu należy opracować w oparciu o skalowalną architekturę DiffServ, uzupełnioną o funkcję przyjmowania nowych wywołań, co razem umożliwi zapewnienie ścisłych gwarancji QoS. Zgodnie z architekturą DiffServ, jedynie w ruterach brzegowych rozróżniamy pojedyncze strumienie i dla tych strumieni definiujemy funkcje profilowania ruchu, zaś w ruterach szkieletowych rozróżniamy jedynie strumienie zbiorcze (zagregowane) obsługiwane w ramach danej usługi sieciowej. Odnośnie realizacji sieci DiffServ, należy rozważyć możliwość użycia techniki MPLS. 3
4 Spis treści STRESZCZENIE WSTĘP ARCHITEKTURA INTSERV PODSUMOWANIE ARCHITEKTURA DIFFSERV PODSUMOWANIE ARCHITEKTURY DLA SIECI NOWEJ GENERACJI STAN STANDARYZACJI GPP IMS IP Multimedia Subsystem ITU-T NGN ETSI TISPAN WYMAGANIA QOS ELEMENTY FUNKCJONALNE NGN Zarządzanie zasobami Sygnalizacja Mechanizmy QoS PRAKTYCZNE REALIZACJE Projekt EuQoS PODSUMOWANIE TECHNIKA MPLS STAN STANDARYZACJI Path Computation Element ZASTOSOWANIA WEWNĄTRZ-DOMENOWE ZASTOSOWANIA MIĘDZY-DOMENOWE PRAKTYCZNE REALIZACJE Projekt EuQoS PODSUMOWANIE
5 6 WNIOSKI I ZALECENIA DLA PROJEKTU...28 LITERATURA...29 LISTA SKRÓTÓW...33 LISTA OZNACZEŃ
6 1 Wstęp W celu umożliwienia prawidłowego transferu przez sieć pakietową multimedialnych strumieni generowanych przez aplikacje takie jak: VoIP, wideo-konferencja czy wideo na żądanie, konieczne jest zapewnienie ścisłych gwarancji jakości obsługi pakietów QoS (Quality of Service). Termin ścisłe gwarancje QoS oznacza, że wszystkie lub część parametrów QoS (np. opóźnienie, zmienność opóźnienia, poziom strat pakietów) jest wyspecyfikowana za pomocą odpowiednich wartości liczbowych. Pierwsze specyfikacje architektur sieci IP QoS to IntServ i DiffServ zaproponowane w ramach IETF. W chwili obecnej trwają prace związane ze standaryzacją architektury funkcjonalnej dla sieci następnej generacji NGN (Next Generation Network), opartej na protokole IP. Cechą charakterystyczną takiej sieci jest oddzielenie płaszczyzny usługowej, przeznaczonej do obsługi sygnalizacji aplikacji, od płaszczyzny transportowej, odpowiedzialnej za zarządzanie przesyłaniem danych. Jednym z wymagań dla warstwy transportowej sieci NGN jest możliwość transmisji pakietów z zapewnieniem jakości obsług QoS. Niniejszy raport dotyczy analiz obecnego stanu definicji architektur dla sieci IP QoS. W dwóch następnych rozdziałach przedstawiono analizę architektur IntServ i DiffServ. Kolejny szczegółowo opisuje architektury dla sieci następnej generacji. W rozdziale 5 zaprezentowana jest technika MPLS oraz możliwości jej zastosowania w sieciach IP QoS. Ostatni rozdział raportu zawiera wnioski i sugestie dotyczące architektury systemu tworzonego w ramach projektu. 6
7 2 Architektura IntServ Obserwując brak aplikacji wykorzystujących usługi telekomunikacyjne oferowane przez technikę ATM oraz jednoczesny gwałtowny wzrost liczby użytkowników sieci Internet, projektanci nowych architektur zorientowanych na oferowanie QoS wnioskują, iż architektury te powinny być oparte na technice IP, ze względu na jej szerokie zastosowanie [RFC1633]. Architektura IntServ [RFC1633] stanowi rozszerzenie architektury sieci Internet o model tzw. usług zintegrowanych. W szczególności, w architekturze IntServ zakłada się, iż dostęp do zasobów sieci jest sterowany za pomocą mechanizmu przyjmowania nowych wywołań (Admission Control - AC). W celu zapewnienia QoS odpowiednie zasoby sieci (bufory, pasmo) są rezerwowane w każdym węźle i łączu wzdłuż drogi połączenia. Rezerwacje mogą być realizowane dla pojedynczego strumienia pakietów lub dla strumieni zbiorczych. wiadomość PATH(1) wiadomość PATH(2) wiadomość PATH(3) IBM PS/2 IBM PS/2 IBM PS/2 IBM PS/2 Nadawca Odbiorca wiadomość RESV(6) wiadomość RESV(5) wiadomość RESV(4) Nadawca Odbiorca Ruter Ruter Rysunek 2-1: Przepływ wiadomości sygnalizacyjnych w protokole RSVP. W celu rezerwacji zasobów, w architekturze IntServ zaproponowano zastosowanie odpowiedniego protokołu sygnalizacyjnego, dla zestawienia połączenia w sieci. W konsekwencji organizacja IETF zdefiniowała protokół Resource ReSerVation Protocol (RSVP) [RFC2205, RFC2210]. Przykładowy przepływ wiadomości sygnalizacyjnych w protokole RSVP przedstawia Rysunek 2-1. Żądanie rezerwacji zasobów jest inicjowane przez stronę nadawczą, która wysyła wiadomość typu PATH. Wiadomość ta zawiera informacje o generowanym profilu ruchowym. W oparciu o te dane określane są wymagania na pasmo oraz rozmiar bufora dla zapewnienia QoS w poszczególnych węzłach sieci. Strona odbiorcza po otrzymaniu wiadomości PATH, wysyła wiadomość RESV, której zadaniem jest rezerwacja zasobów w każdym węźle wzdłuż drogi połączeniowej pomiędzy stacją odbiorczą a nadawczą. Wiadomość RESV jest przesyłana od stacji odbiorczej do stacji nadawczej tą samą drogą jak wiadomość PATH. W przypadku, kiedy sieć dysponuje zasobami, algorytm AC akceptuje przyjęcie wywołania w każdym węźle na drodze połączeniowej. Dokonana rezerwacja musi być okresowo odnawiana (soft reservation). Rezerwacja zasobów na całej drodze połączeniowej wymaga również, aby w każdym węźle była przechowywana informacja o profilach ruchowych dla obsługiwanych strumieni ruchu, co z kolei ogranicza skalowalność tego rozwiązania. Oprócz mechanizmów AC oraz sygnalizacji RSVP, mechanizmami QoS, które wspierają jakość obsługi w sieci IntServ są klasyfikatory pakietów stosowane w interfejsach wejściowych ruterów oraz mechanizmy szeregowania pakietów, ulokowane w interfejsach wyjściowych. Model odniesienia dla implementacji rutera w sieci IntServ przedstawia Rysunek 2-2. W modelu tym możemy wyróżnić 7
8 dwie warstwy logiczne. Dolna część modelu przedstawia warstwę przekazu danych z urządzeniami do klasyfikacji i szeregowania pakietów, zaś górna część stanowi warstwę rezerwacji oraz sterowania zasobami, odpowiednio z agentami rutingu, zestawiania rezerwacji oraz zarządzania. Agent rutingu Agent zestawiania rezerwacji Agent zarządzania Tablice rutingu Baza danych sterowania ruchem Dane wejściowe Interfejs wejściowy Klasyfikacja Interfejs wyjściowy Szeregowanie pakietów Dane wyjściowe Rysunek 2-2: Model ścieżki pakietów w ruterze dla sieci IntServ. W ramach architektury IntServ zaproponowano dwie usługi sieciowe oferujące QoS: Usługę, która powinna oferować ścisłe gwarancje QoS - Guaranteed Service [RFC2212]. Usługa ta została zaprojektowana dla aplikacji wymagających obsługi w reżimie czasu rzeczywistego i powinna zapewnić, aby maksymalne wartości opóźnień, których doznają pakiety przekazywane przez sieć, nie przekraczały założonych wartości granicznych. Usługę, która powinna zapewniać pewną jakość obsługi dla elastycznych aplikacji standardowych - Controlled-load Service [RFC2211]. Usługa powinna zapewniać bardzo małe średnie opóźnienia pakietów, a także bardzo małe straty pakietów, w skalach czasowych większych, niż czas obsługi paczki pakietów. Dla obu wymienionych usług, aby zagwarantować założone wymagania QoS należy zdefiniować odpowiednią metodę AC. Zastosowanie konkretnego algorytmu AC zależy od implementacji danej usługi i pozostaje w gestii operatora sieci. Dodatkowo, w ramach architektury IntServ, przewidziano trzecią usługę, którą może być np. usługa standardowa. 2.1 Podsumowanie Pomimo dużych nadziei, jakie wiązano z zastosowaniem architektury IntServ, problem skalowalności rozwiązania stanowi istotny czynnik hamujący rozwój tego podejścia. Dlatego też, dalsze prace nad architekturą sieci opartej na protokole IP, która wspierałaby gwarancje QoS, zostały ukierunkowane na takie podejścia, które rozwiązałyby problem skalowalności. Taką architekturą jest architektura DiffServ. 8
9 3 Architektura DiffServ Architektura DiffServ dzięki zastosowaniu właściwych mechanizmów QoS ma pozwolić operatorom sieci na świadczenie usług różniących się oferowaną jakością obsługi. Różnicowanie jakości obsługi może odbywać się ze względu na różnicowanie jakości obsługi w ramach różnych klas abonentów lub różnych klas ruchu [RFC2475, RFC3260, RFC3290]. Agent przydzielania pasma IBM PS/2 IBM PS/2 Nadawca IB M P S/2 IB M P S/2 Odbiorca Wejściowy ruter brzegowy Wyjściowy ruter brzegowy Ruter szkieletowy Rysunek 3-1: Ogólna architektura DiffServ. Rysunek 3-1 przedstawia ogólną architekturę DiffServ. Wyróżniamy w niej rutery brzegowe, usytuowane na wejściu i wyjściu z sieci szkieletowej oraz rutery szkieletowe. Jak już wspomniano jednym z warunków, który ma być spełniony przez architekturę DiffServ, jest skalowalność rozwiązania. Elementem wyróżniającym architekturę DiffServ, od wcześniej przedstawionej architektury IntServ, jest zastosowanie tzw. agenta przydzielania pasma (Bandwidth Broker). Agent ten odpowiada za realizację funkcji AC, zarządzanie zasobami sieci oraz za funkcje związane z konfiguracją ruterów brzegowych. Wymienione funkcje są realizowane tylko w węzłach brzegowych sieci. Zakłada się, iż sieć szkieletowa jest odpowiednio przewymiarowana, aby nie stanowić ograniczenia dla przekazu pakietów. Główna koncepcja DiffServ polega na tym, iż rutery brzegowe obsługują pojedyncze strumienie pakietów, natomiast w sieci szkieletowej obsługa odbywa się na podstawie strumieni zbiorczych. Dlatego też funkcje profilowania ruchu są realizowane jedynie w węzłach brzegowych sieci. Natomiast, obsługa ruchu zbiorczego (klas ruchu) przez sieć powinna odbywać się zgodnie z przyjętymi modelami przekazu pakietów, określanymi jako Per-Hop-Behaviour (PHB). PHB określają, w jaki sposób ruch w ramach danej klasy ruchu ma być przekazywany między poszczególnymi węzłami sieci. Pakiety, obsługiwane wg tego samego PHB są rozpoznawane w ruterach dzięki odpowiedniemu ustawieniu pola DSCP nagłówka pakietu IP. Odpowiednie definicje dla wartości pól nagłówków pakietów zarówno dla IPv4 oraz IPv6 przedstawiono w dokumencie [RFC2474] oraz [RFC4594]. 9
10 W ramach architektury DiffServ zdefiniowano dwie główne grupy PHB: Expedited Forwarding (EF) [RFC3246] i Assured Forwarding (AF) [RFC2597]. Grupa EF PHB została zdefiniowana dla przekazu pakietów wymagających obsługi w reżimie czasu rzeczywistego, natomiast grupa AF PHB odpowiada za przekaz pakietów w ramach wielu klas ruchu elastycznego oraz ruchu bez reżimu czasu rzeczywistego. W przypadku obu grup PHB, zdefiniowane mechanizmy QoS powinny zapewnić jakość przekazu pakietów zgodnie z wymaganiami QoS przyjętymi dla danej klasy ruchu oraz zapewnić różnicowanie jakości między poszczególnymi klasami ruchu. Dlatego też, w celu gwarancji QoS przy przekazie pakietów przez sieć, w każdym węźle sieci (ruterze), powinny być utworzone tzw. bloki dla regulowania ruchu (Traffic Conditioning Blocks - TCB) [RFC3290], które stanowią zestaw wybranych mechanizmów QoS dla regulowania ruchu w ramach danej usługi sieciowej. Zestaw mechanizmów QoS w ramach bloków TCB zależy od typu rutera. Bloki TCB dla ruterów brzegowych będą zawierały mechanizmy QoS dla obsługi pojedynczych strumieni ruchu, zaś bloki ruterów szkieletowych tylko mechanizmy QoS dla obsługi strumieni zbiorczych. Przykładowo, mechanizmy monitorowania ruchu dedykowane do obsługi pojedynczych strumieni ruchu są stosowane jedynie w ruterach brzegowych sieci. Również funkcje związane z sygnalizacją QoS oraz metodami AC, a w konsekwencji konfiguracją parametrów urządzeń monitorujących ruch, powinny być realizowane jedynie na wejściu do sieci szkieletowej oraz na jej wyjściu. Główne elementy funkcjonalne rutera w architekturze DiffServ przedstawia Rysunek 3-2. Zarządzanie np.: SNMP, COPS Interfejs konfiguracji oraz zarządzania DiffServ Dane wejściowe Interfejs wejściowy Klasyfikacja Licznik Monitorowanie Kolejkowanie Ruting wewnętrzny Interfejs wyjściowy Klasyfikacja Licznik Monitorowanie Kolejkowanie Dane wyjściowe Sygnalizacja QoS Agent QoS (opcjonalnie) (np.: RSVP) Rysunek 3-2: Główne elementy funkcjonalne rutera DiffServ Jak wynika z definicji architektury DiffServ, architektura ta powinna wspierać różnicowanie jakości obsługi np. różnych klas abonentów lub różnych klas ruchu. Biorąc pod uwagę obecny stan sztuki, na potrzeby projektu rozważane są jedynie aspekty różnicowania jakości obsługi z punktu widzenia różnych klas ruchu, a zwłaszcza ze względu na stawiane tym klasom wymagania QoS. Różnicowanie jakości obsługi wymaga zastosowania odpowiednich mechanizmów. Najprostszym mechanizmem dla zróżnicowania QoS jest nadanie strumieniom poszczególnych klas ruchu różnych priorytetów obsługi. Jednak zastosowanie jedynie prostego mechanizmu priorytetów w ruterach szkiele- 10
11 towych sieci bez użycia właściwych metod AC na dostępie do sieci nie wystarczy dla zapewnienia ścisłych gwarancji QoS, gdyż niekontrolowany ruch w ramach klas o wyższym priorytecie obsługi mógłby wpływać na pogorszenie lub całkowitą blokadę przekazu pakietów z klas o niższym priorytecie. W ramach architektury DiffServ można, oprócz usług oferujących ścisłe gwarancje QoS, zaprojektować również usługi, które będą oferować względne gwarancje QoS. Usługi takie nie wymagają zastosowania mechanizmów AC. W ramach IETF, w oparciu o EF PHB, zaproponowano realizację usługi Premium [RFC2638], dla aplikacji generujących ruch o stałej szybkości bitowej. Usługa Premium realizuje emulację łącza o stałej szybkości (na poziomie pakietów). Wymagania QoS dla usługi Premium są następujące: usługa powinna gwarantować bardzo małe opóźnienia przekazu pakietów, małą zmienność tych opóźnień oraz małe straty pakietów. Zakłada się, iż pakiety w ramach usługi Premium będą obsługiwane z najwyższym priorytetem z zastosowaniem odpowiedniej metody AC. W tym przypadku proponuje się zastosowanie metody AC typu REM (Rate Enveloped Multiplexing) z alokację pasma na podstawie maksymalnej szybkości bitowej (peak rate allocation scheme). Dla pełnej realizacji usługi należy uzgodnić tzw. kontrakt ruchowy między użytkownikiem a siecią. Kontrakt taki jest określany jako Service Level Agreement (SLA) i jest zawierany na podstawie parametrów mechanizmu token bucket, tj. maksymalnej szybkości bitowej oraz maksymalnego rozmiaru paczki pakietów. Dodatkowo, w ruterach brzegowych sieci DiffServ ruch, w ramach pojedynczych strumieni, podlega procesowi kształtowania, aby był zgodny z zawartym kontraktem ruchowych na wejściu do sieci szkieletowej i na jej wyjściu. Usługa Premium jest jedną z propozycji realizacji usługi w ramach architektury DiffServ, która została zaproponowana przez IETF. Dla pozostałych usług nie przygotowano dokładnych definicji, aczkolwiek ogólne wymagania zostały zawarte np. w [RFC4594]. Inne podejście do wykorzystania architektury DiffServ, nie dla oferowania ścisłych gwarancji QoS, ale dla oferowania względnych gwarancji QoS, zostało przedstawione np. w artykułach [Nyb01, Nyb03]. Względne gwarancje QoS są związane z tzw. nominalną szybkością obsługi. W artykule [Nyb01] autorzy przedstawiają modele analityczne dla usług w architekturze DiffServ z zastosowaniem mniej znanego niż EF, czy AF PHB o nazwie Dynamic RT/NRT (Dynamic Real Time/ Non- Real Time PHB) oraz mechanizmu SIMA (Simple Integrated Media Access). Zaś w artykule [Nyb03] zaproponowane modele analityczne dla usług z zaprojektowanych na bazie AF PHB oraz mechanizmu SIMA. Jednak dotychczas żadna z tych propozycji nie znalazła odbicia w ramach zaleceń IETF. 3.1 Podsumowanie Nie ma wątpliwości, iż niezależnie od proponowanej architektury sieci wielo-usługowej, obsługa ruchu z wymaganiami reżimu czasu rzeczywistego powinna różnić się od obsługi ruchu elastycznego. Stąd też, konieczność zastosowania odpowiednich metod różnicowania jakości obsługi. Metody różnicowania obsługi wymagają istnienia odpowiedniej architektury, która pozwoli na ich realizację. W konsekwencji metody różnicowania obsługi sprowadzają się do zdefiniowania odpowiedniej dla danej architektury grupy klas usług sieciowych, które będą mogły obsługiwać strumienie ruchu o podobnych charakterystykach oraz wymaganiach QoS. 11
12 Obecnie najbardziej obiecującą architekturą wspierającą ścisłe gwarancje QoS w sieciach wielousługowych jest architektura DiffServ, która może działać zarówno w oparciu o technikę IPv4, jak i IPv6. Dlatego też, znalazła ona najwięcej zwolenników dla zastosowania w przypadku sieci IP QoS, czy też szeroko rozumianych sieci następnej generacji NGN [Potts03], [ITU-Y2001]. Praktyczną realizacją sieci IP QoS jest np. instalacja pilotowej sieci europejskich projektów AQUILA [Bak03, Koch03], EuQoS [Masip07] oraz europejska sieć badawcza GEANT [Geant]. Należy podkreślić, iż architektura DiffServ pozwala jedynie na różnicowanie jakości obsługi w sieci szkieletowej, poprzez zdefiniowane PHB. Dlatego też, konieczne jest rozszerzenie tej architektury o nowe elementy, aby uzyskać ścisłe gwarancje QoS dla poszczególnych strumieni pakietów. Przykładami takich elementów są mechanizmy QoS realizujące odpowiednio metody AC [Brand02], metody przydziału pasma dla połączeń [D1301, D1302], metody obsługi żądań użytkownika [D1301], metody współpracy aplikacji użytkownika z siecią [Kem03], [Rodriguez08]. Dopiero właściwe połączenie grup PHB zdefiniowanych w ramach architektury DiffServ z wymienionymi mechanizmami pozwoli na zbudowanie właściwych usług sieciowych oferujących QoS w sieci IP. 12
13 4 Architektury dla sieci nowej generacji Jedną z podstawowych cech sieci następnej generacji NGN jest wykorzystanie tej samej sieci transportowej, opartej na protokole IP, do przekazu wszystkich danych generowanych przez użytkownika, niezależnie od użytej aplikacji (VoIP, telekonferencja, wideo na żądanie VoD, pobieranie zbiorów danych z serwera FTP itd.). Prace standaryzacyjne, związane ze specyfikacją sieci NGN, prowadzone są równocześnie przez różne organizacje standaryzacyjne, m.in. 3GPP, ITU-T oraz ETSI. 4.1 Stan standaryzacji GPP IMS IP Multimedia Subsystem IMS (IP Multimedia Subsystem) ([TS23002] [TS23228]) opracowany został przez ciało standaryzacyjne 3GPP [3gpp] w celu dostarczenia usług multimedialnych użytkownikom mobilnym. Pomimo że projektowany był do zastosowania w sieciach bezprzewodowych 3G, w chwili obecnej rozpatrywany jest jako płaszczyzna usługowa niezależna od technologii, w jakiej zostały wykonane sieci dostępowe. IMS odpowiedzialny jest za zarządzanie multimedialnymi usługami oferowanymi użytkownikowi, z punktu widzenia sterowania sesją, sterowania usługą, zarządzania bazą danych zawierającą informacje o użytkownikach sieci itp. Mb IP Multimedia Networks Mb IM - MGW Mb CS Network CS CS M n MGCF BGCF Mk Mj BGCF Mk Mg Mr Mg I-CSCF Mi Mm Mw S - CSCF Mw Mm Dx Cx Legacy mobile signalling Networks ISC Cx AS Dh SLF Sh C, D, Gc, Gr HSS Mb MRFP Mb Mp Mb MRFC P-CSCF Gm UE Ut IMS Subsystem Rysunek 4-1. IMS IP Multimedia Subsystem (źródło: [TS23228]) Rysunek 4-1 przedstawia architekturę funkcjonalną systemu IMS. Jej główne elementy to: CSCF (Call Session Control Function) główna funkcja systemu, obejmuje serwery przeznaczone do obsługi sygnalizacji SIP: 13
14 o P-CSCF (Proxy-CSCF) SIP proxy z którym komunikuje się terminal użytkownika UE (User Equipment); o S-CSCF (Serving-CSCF) serwer SIP odpowiedzialny m.in. za zarządzanie wszystkimi sesjami użytkowników, obsługę rejestracji użytkowników, wybór serwera aplikacji AS dostarczającego usługę; o I-CSCF (Interrogating-CSCF) SIP proxy zlokalizowany na brzegu domeny, przeznaczony do obsługi wiadomości SIP przychodzących z innych domen; MRFC (Media Resource Function Controller) steruje MRFP (Media Resource Function Processor), który jest odpowiedzialny za obsługę strumieni multimedialnych przesyłanych do i od użytkownika, m.in. łączenia strumieni w przypadku usługi telekonferencji, konwersję kodeków pomiędzy strumieniami użytkowników, wysłanie komunikatów przeznaczonych dla użytkownika; MGCF (Media Gateway Control Function) funkcja odpowiedzialna za konwersję pomiędzy protokołem SIP a protokołem sygnalizacyjnym ISUP wykorzystywanym w sieci PSTN; IM-MGW (IMS Media Gateway Function) dokonuje transkodowania strumieni danych przesyłanych pomiędzy siecią IP i siecią z komutacją kanałów (np. PSTN); BGCF (Breakout Gateway Control Function) serwer SIP odpowiedzialny za przesyłanie wiadomości SIP według numerów telefonicznych, wykorzystywany podczas nawiązywania połączenia pomiędzy użytkownikiem sieci IMS a użytkownikiem sieci stacjonarnej PSTN; HSS (Home Subscriber Server) główna baza danych systemu, zawierająca informacje o profilu użytkownika, jego aktualnej lokalizacji, jak również dane wymagane do uwierzytelnienia i autoryzacji użytkownika; SLF (Subscription Locator Function) moduł odpowiedzialny za lokalizację HSS zawierającego informację o danym użytkowniku w sytuacji, gdy system zawiera wiele baz HSS; AS (Application Server) serwer aplikacji, dostarczający usługi oferowane użytkownikom sieci za pomocą IMS. Podczas projektowania systemu IMS założono wykorzystanie istniejących już protokołów (opracowanych przez IETF: SIP [RFC3261] oraz Diameter [RFC3588]) wszędzie tam, gdzie to jest możliwe. IMS stosuje zatem protokół SIP (interfejsy: Gm, ISC, Mg, Mi, Mj, Mk, Mr, Mw) do sygnalizacji zgłoszenia użytkownika oraz Diameter (interfejsy: Cx, Dh, Dx) dla funkcji związanych z uwierzytelnieniem i naliczaniem opłat. Standard IMS specyfikuje platformę służącą do realizacji usług multimedialnych, z pominięciem jednakże aspektów dotyczących warstwy transportowej. Dlatego też architektura IMS jako taka nie gwarantuje jakości obsługi QoS na poziomie pakietów, niemniej jednak może być zastosowana jako warstwa usługowa w sieci NGN. 14
15 4.1.2 ITU-T NGN Architektura sieci ITU-T NGN [ITU-Y2000][ITU-Y2001] zakłada podział funkcjonalności na dwie niezależne warstwy (Rysunek 4-2). Rysunek 4-2. Architektura sieci ITU-T NGN (źródło: [ITU-Y2000]) Pierwsza z nich to warstwa usługowa (Service stratum). Obsługuje ona sygnalizację aplikacji, w tym uwierzytelnianie i naliczanie, oraz przechowuje profil użytkownika. Realizację tej warstwy pozostawiono otwartą, i tak np. system IMS może być wykorzystany do jej realizacji. Druga warstwa (Transport stratum) związana jest z zarządzaniem sposobem przesyłania danych (Resource and Admission Control Functions RACF) oraz zarządzaniem lokalizacją użytkownika (Network Attachment Control Functions NACF). Realizacja tej warstwy oparta jest na definicji interfejsów i protokołów sygnalizacyjnych. Szczegółowy opis elementów funkcjonalnych wchodzących w jej skład przedstawiony jest w rozdziale 4.3. Ponadto specyfikacja ITU-T określa następujące wymagania, które sieć NGN powinna spełniać: umożliwienie dostępu do usług dla terminali niezależnie od tego czy posiadają funkcjonalność NGN, możliwość rozproszenia elementów funkcjonalnych, w celu poprawienia skalowalności systemu, oraz współpracy z innymi systemami za pomocą otwartych protokołów, zapewnienie bezpieczeństwa w dostępie do usług, 15
16 wspieranie jakości przekazu od końca do końca, wspieranie aspektów mobilności zarówno z punktu widzenia profilu użytkownika, jak i z punktu widzenia sieci ETSI TISPAN Kolejnym ciałem standaryzacyjnym zajmującym się opracowaniem architektury NGN jest ETSI, który specyfikuje architekturę TISPAN (Telecoms and Internet converged Services and Protocols for Advanced Networks) [ETSI282001]. Dzięki współpracy z ITU, architektura TISPAN jest zbliżona do architektury NGN ITU-T. Podobnie jak w NGN ITU-T, architektura TISPAN składa się z dwóch odrębnych płaszczyzn (Rysunek 4-3): usługowej (Service Layer) oraz transportowej (Transport Layer). Jako realizację warstwy usługowej dla sieci IP, TISPAN zaadoptował system IMS. Również elementy funkcjonalne wyodrębnione w warstwie transportowej, czyli NASS (Network Attachment Subsystem) zarządzający fizycznym dostępem terminala do sieci i lokalizacją użytkownika oraz RACS (Resource and Admission Control Subsystem) odpowiedzialny za zarządzanie sposobem przesyłania danych, posiadają odwzorowanie w architekturze NGN ITU-T. Są to odpowiednio funkcje NASF oraz RACF zaprezentowane na rysunku 4-2. Rysunek 4-3. Architektura NGN TISPAN (źródło: [ETSI282001]). Jedną z różnic pomiędzy architekturą TISPAN a NGN ITU-T jest obszar do którego dana architektura się odnosi. W przypadku TISPAN, RACS zdefiniowany jest dla sieci stacjonarnych, zaś zakres jego działania obejmuje jedynie sieć dostępową oraz ruter brzegowy sieci szkieletowej, a więc obszar, gdzie nie występują zmiany rozpływu ruchu związane ze zmianą rutingu. Natomiast RACF występujący w NGN ITU-T definiowany jest celem zapewnienia jakości obsługi QoS od końca do końca, obejmuje zatem zarówno sieć dostępową (stacjonarną oraz mobilną), jak i szkieletową. Można zatem przyjąć, iż funkcjonalność RACS jest podzbiorem funkcjonalności RACF [Song07]. 16
17 Architektura NGN opracowywana w ramach ITU jest zatem rozwiązaniem bardziej ogólnym, obejmującym wszystkie aspekty sieci NGN. 4.2 Wymagania QoS W sieci NGN rozróżniono dwa modele zapewniania jakości obsługi QoS [ITU-Y2111]. Są to: ścisłe gwarancje QoS (absolute QoS), kiedy wszystkie lub część parametrów QoS (np. opóźnienie, zmienność opóźnienia, poziom strat pakietów) jest wyspecyfikowana bezpośrednio, poprzez podanie wartości numerycznych; względne gwarancje QoS (relative QoS), kiedy poszczególne klasy usług wspierane przez sieć są obsługiwane w różny sposób, przez co uzyskują inne parametry QoS, jednakże parametry te nie są wyrażone za pomocą konkretnych wartości liczbowych. 4.3 Elementy funkcjonalne NGN Architekturę NGN możemy podzielić na następujące główne elementy funkcjonalne (Rysunek 4-4): (1) terminal użytkownika CPE (Customer Premises Equipment), (2) SCF (Service Control Functions) będący realizacją warstwy usługowej, (3) RACF zarządzający sposobem przesyłania danych (Transport Functions) w warstwie transportowej oraz (4) NACF zarządzający dostępem użytkownika do sieci. Rysunek 4-4. Elementy funkcjonalne architektury NGN ITU-T (źródło: [ITU-Y2111]) Zarządzanie zasobami Rysunek 4-5 przestawia fragment architektury sieci ITU NGN z punktu widzenia funkcji zarządzania zasobami RACF [ITU-Y2111]. Wyróżniono na nim następujące elementy: PD-FE (Policy Decision Functional Entity) spełnia rolę pojedynczego punktu kontaktowego dla warstwy usługowej (SCF). PD-FE podejmuje ostateczną decyzję o przyjęciu lub odrzuceniu połączenia. Ponadto pozwala wprowadzić polityki operatora związane z charakterem dozwolonych połączeń. 17
18 TRC-FE (Transport Resource Control Functional Entity) ukrywa przed PD-FE aspekty związane z różnorodnością technik, które mogą zostać wykorzystane do budowy sieci. Dostarcza funkcję przyjmowania nowych wywołań (decyzja o przyjęciu zgłoszenia do obsługi podejmowana jest na podstawie zajętości zasobów), której wynik przekazuje do PD-FE. Ponadto element ten gromadzi informację o dostępnych zasobach i topologii sieci. TRE-FE (Transport Resource Enforcement Functional Entity) odpowiada za konfigurację sieci warstwy drugiej w celu zapewnienia zasobów dla połączeń. PE-FE (Policy Enforcement Functional Entity) odpowiada za kontrolę połączeń w sieci. Moduł ten zarządza: mechanizmami kontroli i kształtowania ruchu, firewall ami, klasyfikacją i oznaczaniem pakietów. NACF (Network Attachment Control Functions) zarządza fizycznym dostępem terminala do sieci, przydziela adresy IP i monitoruje lokalizację użytkownika. Service control function (SCF) Service Stratum Transport Stratum Network attachment control functions (NACF) Ru RACF Rt Rs PD-FE Rd Ri Other NGNs TRC-FE Rp Rn Rc Rw TRF-FE PE-FE Transport functions Rysunek 4-5. Architektura RACF Tabela 4-1 podsumowuje aktualny stan specyfikacji protokołów interfejsów sieci NGN ITU-T w oparciu o roboczą wersję rekomendacji Q.3300 [ITU-Q3300]. Wśród wykorzystywanych protokołów wyróżniamy: Diameter ([RFC3588]), COPS-PR (Common Open Policy Service Policy Provisioning; [RFC2748] i [RFC3084]), SNMP (Simple Network Management Protocol; [RFC3410] i późniejsze), RCIP (Resource Connection Initiation Protocol; ITU-T Q ). Sposób realizacji interfejsów Rd, Ri, Rn i Ru nie został jeszcze określony. Tabela 4-1. Protokoły przewidziane do realizacji interfejsów sieci NGN ITU-T. Interfejs Związane elementy Protokół Specyfikacja Rs SCF, PD-FE Diameter ITU-T Q Rp TRC-FE RCIP ITU-T Q Rw PD-FE, PE-FE ITU-T Q
19 Rc TRC-FE, Transport functions COPS-PR H.248 Diameter COPS-PR SNMP ITU-T Q ITU-T Q ITU-T Q ITU-T Q ITU-T Q Rt PD-FE, TRC-FE Diameter ITU-T Q Sygnalizacja NGN ITU-T zakłada 3 rodzaje terminali użytkownika CPE: typ 1 to terminal bez funkcji negocjacji QoS; aby korzystać z funkcji sieci NGN wymagane jest wprowadzenie do sieci elementów pośredniczących w sygnalizacji i dokonujących translacji wiadomości sygnalizacyjnych; typ 2 to terminal, który potrafi określić zapotrzebowanie QoS za pomocą sygnalizacji warstwy usługowej; typ 3 to terminal, który potrafi określić zapotrzebowanie zasobów za pomocą sygnalizacji warstwy transportowej, np. za pomocą protokołu RSVP; jednak autoryzacja użytkownika jest wykonywana za pomocą warstwy usługowej. SCF Service Stratum Transport Stratum NACF (1) (2) (3) RACF CPE PE-FE Rysunek 4-6. Scenariusz obsługi wywołania QoS push mode. Rysunek 4-6 przedstawia scenariusz obsługi zgłoszenia przewidziany dla terminali typu 2 (push mode). Składa się on z następujących kroków: Aplikacja znajdująca się w terminalu wysyła do SCF żądanie QoS (1), które zawiera opis zasobów oraz identyfikuje użytkowników zaangażowanych w połączenie. Moduł SCF autoryzuje użytkownika i przygotowuje procedurę naliczania. Moduł SCF uzupełnia żądanie QoS o brakujące dane, np. identyfikuje użytkowników po ich adresach SIP. 19
20 Moduł RACF otrzymuje żądanie (2) i przeprowadza algorytm AC przyjmowania nowych połączeń. Po stwierdzeniu przez RACF, że zasoby są dostępne, moduł PE-FE otrzymuje wiadomość (3) i konfiguruje mechanizmy per flow na wejściu do sieci. SCF Service Stratum Transport Stratum (1) (3) (2) NACF RACF (5) (6) CPE (4) PE-FE Rysunek 4-7. Scenariusz obsługi wywołania QoS pull mode. W przypadku terminala typu 3 procedura obsługi zgłoszenia jest inna (pull mode). Rysunek 4-7 przedstawia jej poszczególne kroki: Aplikacja znajdująca się w terminalu wysyła do SCF żądanie obsługi (1), które nie określa dokładnie zasobów. SCF autoryzuje użytkownika i wysyła wiadomość potwierdzającą (2) do modułu RACF. Potwierdzenie to umożliwia zapytanie o dostęp do zasobów. RACF poprzez SCF odsyła do CPE specjalny token autoryzacyjny (3) [RFC3520]. CPE wysyła do sieci żądanie rezerwacji zasobów (4) identyfikowane poprzez nadany wcześniej token autoryzacyjny. Moduł PE-FE przechwytuje żądanie rezerwacji zasobów i przekazuje je do RACF (5). RACF potwierdza dostępność zasobów (6) Mechanizmy QoS Tabela 4-2 opisuje podstawowe mechanizmy QoS przewidziane w dla sieci NGN. Tabela 4-2. Wybrane mechanizmy QoS rozważane dla sieci NGN ITU-T. Akronim Funkcja Opis FDP Final Decision Point Jest to ostateczny punkt decyzyjny uwzględniający polityki 20
21 operatora dotyczące zasobów. QMTI QoS Mapping Technology Independent Decyduje o odwzorowaniu wymagań jakości przekazu z warstwy SCF na parametry QoS sieci, np. na klasy zdefiniowane w [ITU-Y1541]. IPMC IP Packet Marking Control Decyduje o sposobie oznaczania pakietów IP w sieci. RLC Rate Limiting Control Decyduje o sposobie kontroli ruchu generowanego przez użytkownika, np. policing, shaping QMTD QoS Mapping - Technology Dependent Decyduje o odwzorowaniu wymagań jakości przekazu z uwzględnieniem ograniczeń techniki sieciowej. TDDP Technology Dependent Decision Point Podejmuje decyzję o przyjęciu połączenia w oparciu o aktualny stan zasobów sieci, NRM Network Resource Maintenance Zbiera i przechowuje aktualny stan wykorzystania zasobów w sieci. ERC Element Resource Control Zarządza stanem elementów służących do realizacji mechanizmów QoS. 4.4 Praktyczne realizacje Projekt EuQoS Przykładową architekturą dla realizacji sieci IP QoS jest architektura systemu EuQoS, opracowana w ramach projektu zintegrowanego 6PR IST EuQoS [EuQoS]. Jego celem było zaprojektowanie i zaimplementowanie systemu dla wielo-usługowej sieci telekomunikacyjnej opartej o protokół IP, która potrafi zagwarantować jakość przekazu informacji w relacji koniec-koniec pomiędzy użytkownikami wybranych rodzajów aplikacji. Architekturę systemu EuQoS przedstawia Rysunek 4-8. Możemy w niej wyróżnić następujące warstwy [Bur07]: Warstwa usługowa (Service Plane serwery ASSN i AQ-SSN) określająca sposób, w jaki użytkownik komunikuje się z systemem. Rezerwacja zasobów wykonywana jest niezależnie dla każdego zgłoszenia. W tym celu zdefiniowano trzy metody nawiązania i rozłączenia połączenia: (1) za pomocą protokołu SIP (korzystając ze specjalnego serwera proxy), (2) za pomocą protokołu EQ-SIP, będącego rozszerzeniem zwykłego protokołu SIP o informację opisującą zasoby wymagane przez połączenie, lub (3) za pomocą protokołu SOAP. Warstwa ta 21
22 spełnia również funkcje związane z autoryzacją, uwierzytelnianiem, weryfikacją uprawnień oraz naliczaniem. Legacy application signalling USER 1 USER 1 Application ASSN Service Plane ASSN Application Application Signalling EQ-SIP AQ-SSN Application QoS based e2e signaling EQ-SIP AQ-SSN Application Signalling QCM QCM Control Plane Transport Protocols RA1 Access Network 1 Network Technology Independent layer RM1 RMi RMj COPS NSIS Network Technology Dependent layer QoS Domain i NSIS QoS Domain j EQ-path NSIS RMk QoS Domain k NSIS RM2 RA1 RA1 RA1 RA1 Transport Plane Access Network 2 Transport Protocols Rysunek 4-8. Architektura systemu EuQoS (źródło: [Bur07]). Warstwa sterowania realizacją połączeń (Network Technology Independent Layer) odpowiedzialna za realizację procesu rezerwacji zasobów w sieci, której elementami są serwery RM (Resource Manager). Jej głównym zadaniem jest odnalezienie ścieżki w sieci, która będzie obsługiwać dane połączenie. Aby zrealizować rezerwację na całej ścieżce, serwery RM komunikują się pomiędzy sobą za pomocą protokołu NSIS [RFC4080] rozszerzonego o wymaganą funkcjonalność. Realizacja pojedynczej rezerwacji dla zadanego łącza na ścieżce przekazywana jest do serwerów RA (Resource Allocator) za pomocą protokołu COPS. Warstwa rezerwacji zasobów (Network Technology Dependent Layer serwery RA) wykonująca rezerwację zasobów w oparciu o model łącza lub sieci dostępowej. Proces rezerwacji ma dwie części: (1) odwzorowanie usługi sieciowej i przeprowadzenie algorytmu przyjmowania nowych połączeń CAC, oraz (2) konfiguracja mechanizmów niezbędnych w danej technice sieciowej. Dodatkowo, zgodnie z założeniami architektury DiffServ, w pierwszym elemencie sieciowym przyjmującym ruch użytkownika dokonuje się oznaczania pakietów oraz kontroli ruchu wprowadzanego do sieci. Warstwa transportu danych, która wykorzystuje mechanizmy kolejkowania w celu zapewnienia zagwarantowania jakości przekazu w sieci. Architekturę EuQoS cechuje podobieństwo do architektury NGN ITU-T. Zakłada ona wyraźne rozgraniczenie pomiędzy warstwą usługową (Service Plane) oraz warstwą zarządzającą sposobem 22
23 przesyłania danych (Control Plane). Serwery ASSN i AQ-SSN tworzące warstwę usługową odpowiadają funkcjom SCF architektury NGN. Z kolei funkcja zarządzania zasobami RACF NGN jest realizowana poprzez serwery RM (posiadają funkcjonalność elementów PD-FE) oraz RA (posiadają funkcjonalność elementów PD-FE i TRC-FE). Ponadto RA wykonują funkcje elementów TRE- FE i PE-FE warstwy transportowej architektury NGN [D122]. 4.5 Podsumowanie Architektura sieci następnej generacji, zarówno w organizacjach standaryzacyjnych jak i w przykładowych implementacjach, została podzielona na dwie warstwy. Pierwsza z nich to warstwa usługowa, której celem jest dostarczenie użytkownikowi aplikacji i usług w sposób dla niego zrozumiały, zarówno ze względu na opis usług jak i na sposób naliczania opłat. Druga część związana jest z realizacją funkcjonalności transportowych dla poszczególnych połączeń IP na żądanie pomiędzy użytkownikami. Podział taki pozwala różnym dostawcom usług wykorzystać możliwości transmisyjne operatorów na równych prawach. Jedną z istotnych cech sieci następnej generacji jest wprowadzenie jakości przekazu pakietów IP. Ta cecha warstwy transportowej musi być uwzględniona w wymaganiach wszystkich funkcjonalności systemu. Wśród przedstawionych standardów najbardziej wszechstronna jest architektura ITU NGN, którą łatwo można połączyć z architekturą usługową IMS oraz metodami rozważanymi przez fora dla specyficznych technik sieciowych, np. DSL Forum, 3GPP. Ponadto, architektura ITU NGN opiera się na dekompozycji funkcji opartej na otwartych standardach protokołów komunikacyjnych. Umożliwia to współpracę urządzeń różnych producentów, a więc obniża koszt zakupu. 23
24 5 Technika MPLS Multi-Protocol Label Switching (MPLS) jest techniką komutacji pakietów zorientowaną połączeniowo. W odróżnieniu od techniki IP, w której rutery przesyłają pakiety na podstawie adresu docelowego bez konieczności zestawiania połączeń, ruter MPLS, zwany ruterem LSR (Label Switching Router), przesyła pakiet na podstawie etykiety umieszczonej w nagłówku MPLS w oparciu o zawartość tablicy komutacji ustanowionej w fazie zestawiania ścieżki MPLS. Etykieta MPLS jest dodawana do pakietu IP w ruterze brzegowym domeny MPLS na podstawie przynależności pakietu do klasy FEC (Forwarding Equivalence Class) uzgadnianej w fazie zestawienia ścieżki MPLS. Pakiety IP są klasyfikowane do danej ścieżki MPLS w oparciu o wartości pól nagłówka pakietu IP tj. docelowy i/lub źródłowy adres IP, rodzaj protokołu, typ klasy usług, jak również wartości pól nagłówków protokołów warstwy transportowej i wyższych, np. numeru portu źródłowego lub docelowego. Nagłówek MPLS [RFC3032] ma rozmiar 32 bitów i składa się z: (1) pola Label (20 bitów) zawierającego etykietę, (2) pola Exp (3 bity), zarezerwowanego do przyszłych zastosowań, w tym przenoszenia informacji o przynależności ścieżki do danej klasy usług, (3) pola S (Bottom of Stack, 1 bit), którego wartość równa 1 wskazuje, iż dany nagłówek MPLS stanowi ostatnią etykietę MPLS w danym pakiecie, oraz (4) pola TTL (Time-To-Live, 8 bitów), którego wartość i rola jest identyczna jak w przypadku pola TTL w nagłówku pakietu IP. Szczegółowy format pakietu MPLS przedstawia Rysunek 5-1. Rysunek 5-1. Format pakietu w technice MPLS. Główną cechą techniki MPLS jest możliwość utworzenia ścieżek MPLS, które mogą być zestawiane w sposób w pełni kontrolowany przez operatora, niezależne od dróg wyznaczonych przez dynamiczne protokóły rutingu. Ponadto, technika MPLS umożliwia zestawienie wielu dróg pomiędzy daną parą źródło i ujście, a przez to istnieje możliwość zastosowania większej grupy algorytmów rutingu, obejmującej również algorytmy rutingu źródłowego oraz wielościeżkowego. W efekcie technika MPLS umożliwia operatorowi ścisłą kontrolę nad rozpływem ruchu w sieci, a przez to zastosowanie w praktyce metod inżynierii ruchu pozwalających na optymalizację wykorzystania zasobów sieci. W przypadku sieci wielo-usługowych, technika MPLS umożliwia zestawianie niezależnych ścieżek MPLS dla poszczególnych klas usług oraz optymalizację zasobów sieci z uwzględnieniem wymagań oferowanych usług. Należy jednakże zwrócić uwagę, iż MPLS jako taka, nie umożliwia zapewnienia gwarancji jakości przekazu pakietów. Z tego względu dla realizacji sieci wielo-usługowej zapewniającej gwarancję przekazu, opracowano zasady współpracy pomiędzy techniką MPLS a DiffServ [RFC3270]. Główna idea polega na przyporządkowaniu pakietów przenoszonych w ramach ścieżek MPLS do właściwych klas usług zdefiniowanych w ramach architektury DiffServ. W ten sposób pakiety MPLS podlegają tym samym mechanizmom tj. PHB, admission control, etc., jak przypadku ruchu przenoszonego w ramach klas usług. W zależności od moż- 24
25 liwości ruterów, pakiety MPLS mogą korzystać z tych samych kolejek co ruch IP lub też mogą mieć dedykowane zasoby (bufory i pojemność). Z punktu wiedzenia zastosowania techniki MPLS w praktyce, należy podkreślić, iż technika ta była przewidywana do wykorzystania głównie w sieciach szkieletowych. Z tego względu, większość wiodących producentów ruterów udostępnia funkcjonalność MPLS jedynie w urządzeniach projektowych do budowy sieci szkieletowych, natomiast brak jest tej funkcjonalności w urządzeniach dostępowych i brzegowych. 5.1 Stan standaryzacji Prace standaryzacyjne dotyczące MPLS prowadzone są przez organizację IETF w ramach grup roboczych MPLS oraz PCE (Path Computation Element). Wymagania oraz architektura MPLS zostały przedstawione w zaleceniach RFC 2702 [RFC2702] oraz RFC 3031 [RFC3031]. W dokumencie [RFC3032] zdefiniowano format nagłówka MPLS oraz metody tworzenia hierarchii ścieżek przez włączanie kolejnych etykiet do nagłówka pakietu. Dokumenty [RFC5036], [RFC3037], [RFC3215], [RFC5037], [RFC5038] odnoszą się do protokołu LDP (Label Distribution Protocol), służącego do uzgadniania etykiet pomiędzy sąsiednimi ruterami LSR celem zestawienia ścieżki MPLS. Ponieważ technika MPLS pozwala na przesyłanie pakietów niezależnie od aktualnego rutingu IP, co umożliwia realizację funkcji zarządzania ruchem w sieciach IP, w ramach IETF przeprowadzono prace przystosowujące zarówno protokół sygnalizacyjny RSVP (RSVP-TE, [RFC3209], [RFC3477], [RFC4090], [RFC4420]), jak również LDP (CR-LDP, [RFC3212], [RFC3213], [RFC3214]), do przesyłania wiadomości koniecznych do zestawienia ścieżek MPLS zgodnych z wymogami zarządzania ruchem. W lutym 2003 podjęto decyzję o wstrzymaniu prac nad protokołem CR-LDP i rozwijaniu wyłącznie protokołu RSVP-TE jako podstawowego protokołu dla zarządzania ruchem w technice MPLS ([RFC3468]). Zagadnienia współpracy pomiędzy techniką MPLS a DiffServ są przedstawione w dokumentach [RFC3260], [RFC3270]. Dokumenty te definiują dwie metody przyporządkowania pakietów przenoszonych w ramach ścieżek MPLS do klas usług zdefiniowanych w technice DiffServ. Pierwsza z nich zakłada odwzorowanie wszystkich pakietów należących do danej ścieżki MPLS do jednej klasy DiffServ. W drugiej metodzie założono, że pakiety przenoszone w ramach danej ścieżki MPLS mogą być przyporządkowane do różnych klas usług DiffServ. Przyporządkowanie to jest realizowane przez nadanie odpowiedniej wartości polu EXP w nagłówku MPLS. Ze względu na długość pola EXP istnieje możliwość przyporządkowania pakietów MPLS do maksymalnie 8 klas usług DiffServ Path Computation Element Path Computation Element (PCE) jest wydzielonym elementem domeny MPLS, którego celem jest zarządzanie ścieżkami w domenie MPLS. Ponieważ zarządzanie ścieżkami jest operacją złożoną, wymagającą znacznej mocy obliczeniowej, wiedzy o stanie domeny jak również wiedzy o domenach współpracujących, zdecydowano się zdefiniować specjalizowany element przeznaczony do obliczania ścieżek zarówno wewnątrz domeny, jak i między domenami. Obliczone ścieżki są następnie konfigurowane w ruterach LSR za pomocą protokołów LDP lub RSVP-TE. Szczegółową architekturę elementów PCE przedstawiono w dokumencie [RFC4655]. 25
26 5.2 Zastosowania wewnątrz-domenowe Głównym zastosowaniem MPLS w obszarze domeny jest zarządzanie ruchem (Traffic Engineering). Zestawianie tuneli MPLS umożliwia operatorowi sterowanie rozpływem strumieni ruchu wewnątrz domeny. Ponadto, MPLS jest również stosowany do zabezpieczenia ścieżek w przypadku awarii. Szczegółowe opis zastosowań MPLS wewnątrz domeny przedstawiono w dokumencie [RFC4105]. 5.3 Zastosowania między-domenowe Stosowane obecnie rozwiązania bazują na scentralizowanym zarządzaniu ścieżkami, co powoduje problemy ze skalowalnością w przypadku dużych sieci. Ponadto, zestawienie ścieżek pomiędzy operatorami wymaga uzgodnień dotyczących informacji udostępnianych pomiędzy operatorami. Dlatego też zastosowanie MPLS w obszarze między-domenowym wymaga ścisłej współpracy pomiędzy operatorami. Szczegóły zastosowań techniki MPLS w obszarze między-domenowym przedstawiono w dokumencie [RFC4216]. 5.4 Praktyczne realizacje Projekt EuQoS W projekcie EuQoS [EuQoS] technika MPLS została zastosowana do realizacji wirtualnych łączy między-domenowych, nazywanych EQ-link, umożliwiających połączenie domen pomiędzy którymi nie istnieją łącza fizyczne. Koncepcję zastosowania techniki MPLS w projekcie EuQoS przedstawia Rysunek 5-2. Rysunek 5-2. Koncepcja zastosowania MPLS w projekcie EuQoS (źródło: D122 Annex A [D122]). Łącza EQ-link mogą być ustanawiane pomiędzy ruterami brzegowymi domen MPLS. W projekcie EuQoS założono, że każda ścieżka MPLS przenosi ruch związany z daną klasą usług i ma dedykowane pasmo. Ścieżki MPLS są tworzone automatycznie przez elementy PCE umieszczone w po- 26
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
Bardziej szczegółowoUproszczenie mechanizmów przekazywania pakietów w ruterach
LISTA ŻYCZEŃ I ZARZUTÓW DO IP Uproszczenie mechanizmów przekazywania pakietów w ruterach Mechanizmy ułatwiające zapewnienie jakości obsługi Może być stosowany do równoważenia obciążenia sieci, sterowanie
Bardziej szczegółowoNGN/IMS-Transport (warstwa transportowa NGN/IMS)
Instytut Telekomunikacji PW NGN/IMS-Transport (warstwa transportowa NGN/IMS) IMS/Transport 1 RACF Resource and Admission COntrol FUnction Architektura odniesienia NGN funkcje transportowe ANI Profile usługowe
Bardziej szczegółowoTytuł raportu: Podsumowanie aktywności za okres styczeńczerwiec
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/A.0
Bardziej szczegółowoARCHITEKTURA USŁUG ZRÓŻNICOWANYCH
ARCHITEKTURA USŁUG ZRÓŻNICOWANYCH This architecture achieves scalability by implementing complex classification and conditioning functions only at network boundary nodes and by applying per-hop behaviors
Bardziej szczegółowoPodstawy 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ółowoQoS w sieciach IP. Parametry QoS ( Quality of Services) Niezawodność Opóźnienie Fluktuacja ( jitter) Przepustowość ( pasmo)
QoS w sieciach IP Parametry QoS ( Quality of Services) Niezawodność Opóźnienie Fluktuacja ( jitter) Przepustowość ( pasmo) Przeciążenie Overbooking, Kolejki i zrzuty obciążenia Losowe lub według oznaczeń
Bardziej szczegółowoTransmisja z gwarantowaną jakością obsługi w Internecie
Transmisja z gwarantowaną jakością obsługi w Internecie dr inż. Jerzy Domżał Akademia Górniczo-Hutnicza w Krakowie, Katedra Telekomunikacji 28 listopada 2016 r. dr inż. Jerzy Domżał (AGH) Wprowadzenie
Bardziej szczegółowoAnalysis 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
Bardziej szczegółowoIntegrated Services i Differentiated Services
Integrated Services i Differentiated Services dr inż. Jerzy Domżał Akademia Górniczo-Hutnicza w Krakowie, Katedra Telekomunikacji 15 października 2012 r. dr inż. Jerzy Domżał (AGH) Gwarantowanie jakości
Bardziej szczegółowoUsługi i sieci teleinformatyczne następnej generacji aspekty techniczne, aplikacyjne i rynkowe. Opracowanie wymagań na system IP QoS
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/A.1
Bardziej szczegółowo1. 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ółowoUsługi IMP i konferencyjne
Usługi IMP i konferencyjne Obecność jako katalizator dla innych usług Konferencja ad hoc, IM, aktywna książka adresowa Wydział Elektroniki i Technik Informacyjnych, PW 2 Obecność w IMS Terminal IMS pełni
Bardziej szczegółowoZarządzanie ruchem i jakością usług w sieciach komputerowych
Zarządzanie ruchem i jakością usług w sieciach komputerowych Część 1 wykładu SKO2 Mapa wykładu Wprowadzenie 10 trendów rozwoju sieci Komunikacja multimedialna w sieciach IP Techniki QoS ATM IEEE 802.1D
Bardziej szczegółowoMPLS. Krzysztof Wajda Katedra Telekomunikacji, 2015
MPLS (Multiprotocol Label Switching) Krzysztof Wajda Katedra Telekomunikacji, 2015 Plan wykładu Ewolucja od IP do MPLS Klasyfikacja ruchu Etykiety Elementy funkcjonalne MPLS: LSR, E-LSR Działanie LSR Dystrybucja
Bardziej szczegółowoMateriały przygotowawcze do laboratorium
Materiały przygotowawcze do laboratorium Badanie właściwości wieloprotokołowej komutacji etykietowej MPLS (Multi-Protocol Label Switching). Wznawianie pracy po wystąpieniu uszkodzenia w sieciach rozległych
Bardziej szczegółowoMODEL WARSTWOWY PROTOKOŁY TCP/IP
MODEL WARSTWOWY PROTOKOŁY TCP/IP TCP/IP (ang. Transmission Control Protocol/Internet Protocol) protokół kontroli transmisji. Pakiet najbardziej rozpowszechnionych protokołów komunikacyjnych współczesnych
Bardziej szczegółowoProtokoły sieciowe model ISO-OSI Opracował: Andrzej Nowak
Protokoły sieciowe model ISO-OSI Opracował: Andrzej Nowak OSI (ang. Open System Interconnection) lub Model OSI to standard zdefiniowany przez ISO oraz ITU-T, opisujący strukturę komunikacji sieciowej.
Bardziej szczegółowoPonadto SLA powinno definiować następujące parametry:
SERVICE LEVEL AGREEMENT (SLA) CZ. I Service Level Agreement (SLA) jest to porozumienie pomiędzy klientem a dostawcą usługi. SLA powinno określać w sposób jasny i zrozumiały dla klienta, czego może on oczekiwać
Bardziej szczegółowoSystemy i sieci GMPLS. Wprowadzenie do GMPLS. Krzysztof Wajda. Katedra Telekomunikacji AGH Czerwiec, 2018
Systemy i sieci telekomunikacyjne: GMPLS Wprowadzenie do GMPLS Krzysztof Wajda Katedra Telekomunikacji AGH Czerwiec, 2018 Plan Podstawy GMPLS Ewolucja od koncepcji MPLS do GMPLS Etykieta uogólniona Interfejsy
Bardziej szczegółowo(12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP (96) Data i numer zgłoszenia patentu europejskiego:
RZECZPOSPOLITA POLSKA (12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP 1879335 Urząd Patentowy Rzeczypospolitej Polskiej (96) Data i numer zgłoszenia patentu europejskiego: 19.04.2006 06722372.7
Bardziej szczegółowoDLACZEGO QoS ROUTING
DLACZEGO QoS ROUTING Reakcja na powstawanie usług multimedialnych: VoIP (Voice over IP) Wideo na żądanie Telekonferencja Potrzeba zapewnienia gwarancji transmisji przy zachowaniu odpowiedniego poziomu
Bardziej szczegółowoBandwidth on Demand - wyzwania i ograniczenia. Tomasz Szewczyk tomeks@man.poznan.pl
Bandwidth on Demand - wyzwania i ograniczenia Tomasz Szewczyk tomeks@man.poznan.pl 1 O PCSS Jednostka afiliowana przy Instytucie Chemii Bioorganicznej PAN Dział sieci Dział usług sieciowych Dział komputerów
Bardziej szczegółowoWarstwy i funkcje modelu ISO/OSI
Warstwy i funkcje modelu ISO/OSI Organizacja ISO opracowała Model Referencyjny Połączonych Systemów Otwartych (model OSI RM - Open System Interconection Reference Model) w celu ułatwienia realizacji otwartych
Bardziej szczegółowoStandardy w obszarze Internetu Przyszłości. Mariusz Żal
Standardy w obszarze Internetu Przyszłości Mariusz Żal 1 Agenda Wprowadzenie Organizacje standaryzacyjne Projekty mogące mieć wpływ na proces standaryzacji Przyszłe obszary standaryzacji Podsumowanie 2
Bardziej szczegółowoPrzesyłania danych przez protokół TCP/IP
Przesyłania danych przez protokół TCP/IP PAKIETY Protokół TCP/IP transmituje dane przez sieć, dzieląc je na mniejsze porcje, zwane pakietami. Pakiety są często określane różnymi terminami, w zależności
Bardziej szczegółowoProtokoły sieciowe - TCP/IP
Protokoły sieciowe Protokoły sieciowe - TCP/IP TCP/IP TCP/IP (Transmission Control Protocol / Internet Protocol) działa na sprzęcie rożnych producentów może współpracować z rożnymi protokołami warstwy
Bardziej szczegółowoZiMSK. VLAN, trunk, intervlan-routing 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 VLAN, trunk, intervlan-routing
Bardziej szczegółowoService Level Agreement (SLA) jest to porozumienie pomiędzy klientem a dostawcą usługi.
SERVICE LEVEL AGREEMENT (SLA) CZ. I Service Level Agreement (SLA) jest to porozumienie pomiędzy klientem a dostawcą usługi. SLA powinno określać w sposób jasny i zrozumiały dla klienta, czego może on oczekiwać
Bardziej szczegółowoQuality of Service (QoS)
Quality of Service (QoS) Definicja QoS jest związana z technicznym podejściem do zapewnienia parametrów transmisji danych. Użytkownik korzystający z usługi czy dostawca zapewniający tę usługę mają pewne
Bardziej szczegółowoZarządzanie ruchem i jakością usług w sieciach komputerowych
Zarządzanie ruchem i jakością usług w sieciach komputerowych Część 1 wykładu SKO2 Mapa wykładu Wprowadzenie 10 trendów rozwoju sieci Komunikacja multimedialna w sieciach IP Techniki QoS ATM IEEE 802.1D
Bardziej szczegółowoTechnologia VoIP w aspekcie dostępu do numerów alarmowych
Technologia VoIP w aspekcie dostępu do numerów alarmowych Jerzy Paczocha - gł. specjalista Waldemar Szczęsny - adiunkt Debata o przyszłych regulacjach usługi VoIP Urząd Komunikacji Elektronicznej 26 listopad
Bardziej szczegółowoZaawansowane 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ółowoPBS. Wykład Zabezpieczenie przełączników i dostępu do sieci LAN
PBS Wykład 7 1. Zabezpieczenie przełączników i dostępu do sieci LAN mgr inż. Roman Krzeszewski roman@kis.p.lodz.pl mgr inż. Artur Sierszeń asiersz@kis.p.lodz.pl mgr inż. Łukasz Sturgulewski luk@kis.p.lodz.pl
Bardziej szczegółowojest protokołem warstwy aplikacji, tworzy on sygnalizację, aby ustanowić ścieżki komunikacyjne, a następnie usuwa je po zakończeniu sesji
PROTOKÓŁ SIP INFORMACJE PODSTAWOWE SIP (Session Initiation Protocol) jest protokołem sygnalizacyjnym służącym do ustalania adresów IP oraz numerów portów wykorzystywanych przez terminale do wysyłania i
Bardziej szczegółowoMateriały przygotowawcze do laboratorium 3
Materiały przygotowawcze do laboratorium 3 Badanie właściwości wieloprotokołowej komutacji etykietowej MPLS (Multi-Protocol Label Switching). Wznawianie pracy po wystąpieniu uszkodzenia w sieciach rozległych
Bardziej szczegółowoTelefonia Internetowa VoIP
Telefonia Internetowa VoIP Terminy Telefonia IP (Internet Protocol) oraz Voice over IP (VoIP) odnoszą się do wykonywania połączeń telefonicznych za pośrednictwem sieci komputerowych, w których dane są
Bardziej szczegółowoLaboratorium - 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
Bardziej szczegółowoRaport z realizacji zadania badawczego: A.9 Tytuł raportu: Opracowanie wymagań na sieć laboratoryjną system IP QoS
Numer Projektu Badawczego Zamawianego: -MNiSW-02-II/2007 Tytuł projektu: Numer dokumentu: Usługi i sieci teleinformatyczne następnej generacji aspekty techniczne, aplikacyjne i rynkowe -MNiSW-02-II/2007/IŁ-PIB/A.9
Bardziej szczegółowoPLAN KONSPEKT. do przeprowadzenia zajęć z przedmiotu. Wprowadzenie do projektowania sieci LAN
PLAN KONSPEKT do przeprowadzenia zajęć z przedmiotu Wprowadzenie do projektowania sieci LAN TEMAT: Wprowadzenie do projektowania sieci LAN CEL: Zapoznanie uczniów z podstawami zasadami projektowania sieci
Bardziej szczegółowoWLAN bezpieczne sieci radiowe 01
WLAN bezpieczne sieci radiowe 01 ostatnim czasie ogromną popularność zdobywają sieci bezprzewodowe. Zapewniają dużą wygodę w dostępie użytkowników do zasobów W informatycznych. Jednak implementacja sieci
Bardziej szczegółowo(12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP (96) Data i numer zgłoszenia patentu europejskiego:
RZECZPOSPOLITA POLSKA (12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP 2028811 (96) Data i numer zgłoszenia patentu europejskiego: 24.07.2007 07014467.0 (13) (51) T3 Int.Cl. H04L 29/06 (2006.01)
Bardziej szczegółowoMarek Parfieniuk, Tomasz Łukaszuk, Tomasz Grześ. Symulator zawodnej sieci IP do badania aplikacji multimedialnych i peer-to-peer
Marek Parfieniuk, Tomasz Łukaszuk, Tomasz Grześ Symulator zawodnej sieci IP do badania aplikacji multimedialnych i peer-to-peer Plan prezentacji 1. Cel projektu 2. Cechy systemu 3. Budowa systemu: Agent
Bardziej szczegółowoSygnalizacja Kontrola bramy Media
PROTOKOŁY VoIP Sygnalizacja Kontrola bramy Media H.323 Audio/ Video H.225 H.245 Q.931 RAS SIP MGCP RTP RTCP RTSP TCP UDP IP PROTOKOŁY VoIP - CD PROTOKOŁY VoIP - CD PROTOKOŁY VoIP - CD PROTOKOŁY SYGNALIZACYJNE
Bardziej szczegółowoMulticasty w zaawansowanych usługach Internetu nowej generacji
PREZENTACJA PRACY MAGISTERSKIEJ Multicasty w zaawansowanych usługach Internetu nowej generacji Autor : Bogumił Żuchowski Kierujący pracą: dr inż. Maciej Stroiński PLAN PREZENTACJI Wprowadzenie Cel pracy
Bardziej szczegółowoMetody gwarantowania QoS płaszczyzny sterowania w systemach specjalnych
Rafał Bryś, Jacek Pszczółkowski, Mirosław Ruszkowski Zakład Systemów Łączności Wojskowy Instytut Łączności Metody gwarantowania QoS płaszczyzny sterowania w systemach specjalnych W referacie zaprezentowana
Bardziej szczegółowoReferencyjny model OSI. 3 listopada 2014 Mirosław Juszczak 37
Referencyjny model OSI 3 listopada 2014 Mirosław Juszczak 37 Referencyjny model OSI Międzynarodowa Organizacja Normalizacyjna ISO (International Organization for Standarization) opracowała model referencyjny
Bardziej szczegółowoIP Multimedia Subsystem
IP Multimedia Subsystem Karol Kański 16 marca 2010 1 Wprowadzenie 2 Architektura 3 Plan sygnałów 4 Serwisy 5 Uzupełnienia Czym jest IMS, motywacja IMS to ramowa architektura stworzona w celu dostarczania
Bardziej szczegółowoInstytut Telekomunikacji PW. NGN od ISUP do BICC Materiały wykładowe do użytku wewnętrznego
Instytut Telekomunikacji PW NGN od do BICC Materiały wykładowe do użytku wewnętrznego 1 Podstawowa architektura fizyczna sieci NGN Nieformalnie Call server = MGC+GK+SIPProxy/Redirect/Registrar (+API) Call
Bardziej szczegółowoGrzegorz Gliński. 1. Opis wykonanego ćwiczenia
Grupa ćwicz. IIIb Nr ćwicz./ wersja 1 Imiona i nazwiska. Grupa lab. 7 Grzegorz Gliński Rok 3 IS Temat ćwiczenia. Voice Conference Data wykonania. 22.10.09 Data odbioru Ocena i uwagi 1. Opis wykonanego
Bardziej szczegółowoWYMAGANIA TECHNOLOGICZNE W ODNIESIENIU DO SYSTEMÓW TELEKOMUNIKACYJNYCH I TELEINFORMATYCZNYCH W OBSZARZE SIŁ ZBROJNYCH
WYMAGANIA TECHNOLOGICZNE W ODNIESIENIU DO SYSTEMÓW TELEKOMUNIKACYJNYCH I TELEINFORMATYCZNYCH W OBSZARZE SIŁ ZBROJNYCH Robert Goniacz WYMAGANIA TECHNOLOGICZNE Obszar sił zbrojnych Najważniejsze problemy
Bardziej szczegółowoZałącznik nr 1 do zapytania ofertowego. Połączenie lokalizacji ŁOW NFZ wysokowydajną siecią WAN, zapewnienie dostępu do Internetu oraz
Załącznik nr 1 do zapytania ofertowego Połączenie lokalizacji ŁOW NFZ wysokowydajną siecią WAN, zapewnienie dostępu do Internetu oraz Opis przedmiotu zamówienia 1. Przedmiotem zamówienia jest: dzierżawa
Bardziej szczegółowoKonfigurowanie 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ółowoZiMSK NAT, PAT, ACL 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 NAT, PAT, ACL 1 Wykład Translacja
Bardziej szczegółowoW 10 stron dookoła QoS a
W 10 stron dookoła QoS a 25 czerwca 2009 Spis treści 1 Wstęp 1 1.1 Charakter ruchu................................ 2 2 ATM QoS 3 2.1 Parametry.................................... 3 2.2 Klasy......................................
Bardziej szczegółowoOpis 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
Bardziej szczegółowoProjektowanie 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ółowoAdresy w sieciach komputerowych
Adresy w sieciach komputerowych 1. Siedmio warstwowy model ISO-OSI (ang. Open System Interconnection Reference Model) 7. Warstwa aplikacji 6. Warstwa prezentacji 5. Warstwa sesji 4. Warstwa transportowa
Bardziej szczegółowo(12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP 1571864. (96) Data i numer zgłoszenia patentu europejskiego: 05.03.2004 04005227.
RZECZPOSPOLITA POLSKA (12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP 1571864 (96) Data i numer zgłoszenia patentu europejskiego: 05.03.2004 04005227.6 (13) (51) T3 Int.Cl. H04W 4/10 (2009.01)
Bardziej szczegółowoInfrastruktura PL-LAB2020
Infrastruktura 2020 Bartosz Belter (Poznańskie Centrum Superkomputerowo-Sieciowe) Seminarium 2020, Warszawa, 23.03.2017 Rozproszona infrastruktura 2020 Rozproszona infrastruktura 2020 (2) Sieć szkieletowa
Bardziej szczegółowoSieci Komórkowe naziemne. Tomasz Kaszuba 2013 kaszubat@pjwstk.edu.pl
Sieci Komórkowe naziemne Tomasz Kaszuba 2013 kaszubat@pjwstk.edu.pl Założenia systemu GSM Usługi: Połączenia głosowe, transmisja danych, wiadomości tekstowe I multimedialne Ponowne użycie częstotliwości
Bardziej szczegółowo1. W jakich technologiach QoS w sieciach komputerowych wykorzystywany jest miękki stan? W technologii IntServ.
1. W jakich technologiach QoS w sieciach komputerowych wykorzystywany jest miękki stan? W technologii IntServ. 2. W jakich technologiach QoS w sieciach komputerowych wykorzystywany jest zarządzanie ruchem
Bardziej szczegółowoPodstawy IMS (IP Multimedia Subsystem)
Architektura IMS Podstawy IMS (IP Multimedia Subsystem) Co to jest IMS? Podsystem multimedialny IP dla sieci mobilnej 3G Wspólna rama architektoniczna architektura funkcjonalna Nakładkowa sieć dla istniejących
Bardziej szczegółowoMarek Średniawa Instytut Telekomunikacji PW
Architektura usługowa IMS Marek Średniawa Instytut Telekomunikacji PW Plan prezentacji Wprowadzenie Architektura IMS Usługi, aplikacje i zastosowania Ewolucja NGN IMS jako wspólna arch. usługowa Podsumowanie
Bardziej szczegółowoStos protokołów TCP/IP (ang. Transmission Control Protocol/Internet Protocol)
Stos protokołów TCP/IP (ang. Transmission Control Protocol/Internet Protocol) W latach 1973-78 Agencja DARPA i Stanford University opracowały dwa wzajemnie uzupełniające się protokoły: połączeniowy TCP
Bardziej szczegółowoMarek Średniawa Instytut Telekomunikacji PW
Architektura usługowa IMS Marek Średniawa Instytut Telekomunikacji PW Plan prezentacji Wprowadzenie Architektura IMS Usługi, aplikacje i zastosowania Ewolucja NGN IMS jako wspólna arch.usługowa Podsumowanie
Bardziej szczegółowo(12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) (96) Data i numer zgłoszenia patentu europejskiego: 29.06.2007 07290821.3
RZECZPOSPOLITA POLSKA (12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP 2009875 (96) Data i numer zgłoszenia patentu europejskiego: 29.06.2007 07290821.3 (13) T3 (51) Int. Cl. H04L12/56 H04L29/08
Bardziej szczegółowoWymagania 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ółowoZdalne logowanie do serwerów
Zdalne logowanie Zdalne logowanie do serwerów Zdalne logowanie do serwerów - cd Logowanie do serwera inne podejście Sesje w sieci informatycznej Sesje w sieci informatycznej - cd Sesje w sieci informatycznej
Bardziej szczegółowoWarstwa sieciowa. Model OSI Model TCP/IP. Aplikacji. Aplikacji. Prezentacji. Sesji. Transportowa. Transportowa
Warstwa sieciowa Model OSI Model TCP/IP Aplikacji Prezentacji Aplikacji podjęcie decyzji o trasowaniu (rutingu) na podstawie znanej, lokalnej topologii sieci ; - podział danych na pakiety Sesji Transportowa
Bardziej szczegółowoWideokonferencje MGR INŻ. PAWEŁ SPALENIAK
SYSTEMY I TERMINALE MULTIMEDIALNE Wideokonferencje MGR INŻ. PAWEŁ SPALENIAK Plan wykładu 1. Wprowadzenie 2. Zalety wideokonferencji 3. Podstawowe elementy systemu wideokonferencyjnego 4. Standardy telekomunikacyjne
Bardziej szczegółowoPodstawy Transmisji Danych. Wykład IV. Protokół IPV4. Sieci WAN to połączenia pomiędzy sieciami LAN
Podstawy Transmisji Danych Wykład IV Protokół IPV4 Sieci WAN to połączenia pomiędzy sieciami LAN 1 IPv4/IPv6 TCP (Transmission Control Protocol) IP (Internet Protocol) ICMP (Internet Control Message Protocol)
Bardziej szczegółowoSieci WAN. Mgr Joanna Baran
Sieci WAN Mgr Joanna Baran Technologie komunikacji w sieciach Analogowa Cyfrowa Komutacji pakietów Połączenia analogowe Wykorzystanie analogowych linii telefonicznych do łączenia komputerów w sieci. Wady
Bardziej szczegółowoWykł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ółowoTransmisja danych multimedialnych. mgr inż. Piotr Bratoszewski
Transmisja danych multimedialnych mgr inż. Piotr Bratoszewski Wprowadzenie Czym są multimedia? Informacje przekazywane przez sieć mogą się składać z danych różnego typu: Tekst ciągi znaków sformatowane
Bardziej szczegółowoKonfiguracja 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ółowow sieciach szerokopasmowych CATV i ISP - Model OSI
Technologie VoIP wykorzystywane w sieciach szerokopasmowych CATV i ISP - Model OSI mgr inż. Zbigniew Papuga Stowarzyszenie Elektryków Polskich W celu ujednolicenia struktury oprogramowania sieci komputerowych
Bardziej szczegółowoANALIZA 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
Bardziej szczegółowoSterowanie ruchem w sieciach szkieletowych
Sterowanie ruchem w sieciach szkieletowych Transmisja wielościeżkowa Dr inż. Robert Wójcik Wydział Informatyki, Elektroniki i Telekomunikacji Katedra Telekomunikacji Kraków, dn. 6 kwietnia 2016 r. Plan
Bardziej szczegółowoNGN SIGTRAN (Signalling Transport)
Instytut Telekomunikacji PW NGN SIGTRAN (Signalling Transport) Materiały wykładowe do użytku wewnętrznego Sigtran 1 Kontekst szczególny: 3GPP G VLR Rel. 7 Sigtran 2 ... SIGTRAN (Signalling Transport) Pierwotna
Bardziej szczegółowoArchitektura IMS. Wydział Elektroniki i Technik Informacyjnych, PW
Architektura IMS Nakładkowa architektura sterowania sesją i usługami nad domeną sieci pakietowej (GPRS, UMTS, WLAN, DSL, FTTx) wykorzystująca technikę IP i protokoły internetowe IETF (np. SIP, Diameter)
Bardziej szczegółowoOr.V.271.21.2013 Wykonawcy zainteresowani uczestnictwem w postępowaniu
Strona 1 Ostrowiec Świętokrzyski, 07.06.2013 r. Or.V.271.21.2013 Wykonawcy zainteresowani uczestnictwem w postępowaniu W nawiązaniu do ogłoszenia o zamówieniu (DUUE Nr 2013/S 087-147731 z dnia 04.05.2013)
Bardziej szczegółowoIP VPN. 1.1 Opis usługi
IP VPN 1.1 Opis usługi IPVPN MPLS to usługa transmisji danych umożliwiająca zbudowanie dla Twojej Firmy sieci WAN składającej się z oddalonych od siebie korporacyjnych sieci lokalnych (LAN). Rozwiązanie
Bardziej szczegółowoWykł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ółowoKsięgarnia PWN: Mark McGregor Akademia sieci cisco. Semestr szósty
Księgarnia PWN: Mark McGregor Akademia sieci cisco. Semestr szósty Wprowadzenie 13 Rozdział 1. Zdalny dostęp 17 Wprowadzenie 17 Typy połączeń WAN 19 Transmisja asynchroniczna kontra transmisja synchroniczna
Bardziej szczegółowoWykł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ółowoModel OSI. mgr inż. Krzysztof Szałajko
Model OSI mgr inż. Krzysztof Szałajko Protokół 2 / 26 Protokół Def.: Zestaw reguł umożliwiający porozumienie 3 / 26 Komunikacja w sieci 101010010101101010101 4 / 26 Model OSI Open Systems Interconnection
Bardziej szczegółowoRywalizacja w sieci cd. Protokoły komunikacyjne. Model ISO. Protokoły komunikacyjne (cd.) Struktura komunikatu. Przesyłanie między warstwami
Struktury sieciowe Struktury sieciowe Podstawy Topologia Typy sieci Komunikacja Protokoły komunikacyjne Podstawy Topologia Typy sieci Komunikacja Protokoły komunikacyjne 15.1 15.2 System rozproszony Motywacja
Bardziej szczegółowoPodstawy Informatyki. Inżynieria Ciepła, I rok. Wykład 13 Topologie sieci i urządzenia
Podstawy Informatyki Inżynieria Ciepła, I rok Wykład 13 Topologie sieci i urządzenia Topologie sieci magistrali pierścienia gwiazdy siatki Zalety: małe użycie kabla Magistrala brak dodatkowych urządzeń
Bardziej szczegółowoUniwersalny Konwerter Protokołów
Uniwersalny Konwerter Protokołów Autor Robert Szolc Promotor dr inż. Tomasz Szczygieł Uniwersalny Konwerter Protokołów Szybki rozwój technologii jaki obserwujemy w ostatnich latach, spowodował że systemy
Bardziej szczegółowoTCP/IP. Warstwa aplikacji. mgr inż. Krzysztof Szałajko
TCP/IP Warstwa aplikacji 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
Bardziej szczegółowoWirtualizacja zasobów IPv6 w projekcie IIP
Wirtualizacja zasobów IPv6 w projekcie IIP Artur Binczewski, Bartosz Gajda, Wiktor Procyk, Robert Szuman Poznańskie Centrum Superkomputerowo Sieciowe Adam Grzech, Jan Kwiatkowski, Krzysztof Chudzik Politechnika
Bardziej szczegółowoPRZEKAZ INFORMACJI MIĘDZY SIECIĄ LOKALNĄ (LAN), A SIECIĄ SZEROKOPASMOWĄ OPARTĄ NA TECHNICE ATM. mgr inż. Zbigniew Zakrzewski, mgr inż.
PRZEKAZ INFORMACJI MIĘDZY SIECIĄ LOKALNĄ (LAN), A SIECIĄ SZEROKOPASMOWĄ OPARĄ NA ECNICE AM mgr inż. Zbigniew Zakrzewski, mgr inż. Jacek Majewski INSYU ELEKOMKACJI AR BYDGOSZCZ 85-795 Bydgoszcz ul. Prof.
Bardziej szczegółowoZałącznik nr 2. Opis sieci teleinformatycznej
Załącznik nr 2 Opis sieci teleinformatycznej 1. Założenia techniczne Sieć teleinformatyczna Stadionu Narodowego ma pełnić rolę wydajnego, zintegrowanego szkieletu komunikacyjnego dla wielu systemów projektowanych
Bardziej szczegółowo7. zainstalowane oprogramowanie. 8. 9. 10. zarządzane stacje robocze
Specyfikacja oprogramowania do Opis zarządzania przedmiotu i monitorowania zamówienia środowiska Załącznik nr informatycznego 1 do specyfikacji Lp. 1. a) 1. Oprogramowanie oprogramowania i do systemów
Bardziej szczegółowoUrządzenia sieciowe. Tutorial 1 Topologie sieci. Definicja sieci i rodzaje topologii
Tutorial 1 Topologie sieci Definicja sieci i rodzaje topologii Definicja 1 Sieć komputerowa jest zbiorem mechanizmów umożliwiających komunikowanie się komputerów bądź urządzeń komputerowych znajdujących
Bardziej szczegółowoInterfejs DXI dostępu do sieci szerokopasmowej opartej na technice ATM
Zbigniew Zakrzewski Jacek Majewski Instytut elekomunikacji AR - Bydgoszcz Interfejs dostępu do sieci szerokopasmowej opartej na technice AM W referacie przedstawiono realizację podłączenia strumienia danych
Bardziej szczegółowo5.5.5. Charakterystyka podstawowych protokołów rutingu zewnętrznego 152 Pytania kontrolne 153
Przedmowa 1. Sieci telekomunikacyjne 1 1.1. System telekomunikacyjny a sieć telekomunikacyjna 1 1.2. Rozwój sieci telekomunikacyjnych 4 1.2.1. Sieci telegraficzne 4 1.2.2. Sieć telefoniczna 5 1.2.3. Sieci
Bardziej szczegółowoSieci Komputerowe Modele warstwowe sieci
Sieci Komputerowe Modele warstwowe sieci mgr inż. Rafał Watza Katedra Telekomunikacji AGH Al. Mickiewicza 30, 30-059 Kraków, Polska tel. +48 12 6174034, fax +48 12 6342372 e-mail: watza@kt.agh.edu.pl Wprowadzenie
Bardziej szczegółowoRys. 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