Wykład 12: Architektura DiffServ Sieci Wielousługowe: lato 2007/2008 Wykład 12: Architektura DiffServ Prof. dr hab. inż. Wojciech Burakowski Instytut Telekomuniacji PW Zespół Technik Sieciowych Pokój 335 tnt.tele,pw,.edu.pl

Plan wykładu 1 2 3 4 Mechanizmy QoS dla sieci IP Zasadnicze cechy architektury IntServ 3 Zasadnicze cechy architektury DiffServ 4 Architektura AQUILA

Plan wykładu 1 2 3 4 Architektura AQUILA Mechanizmy QoS dla sieci IP Zasadnicze cechy architektury IntServ 3 Zasadnicze cechy architektury DiffServ 4 Architektura AQUILA

Rozwój sieci IP IP – best effort Protokół RSVP (ReSerVation Protocol) Architektury IntServ (Integrated Services) DiffServ (Differentiated Services) Technika MPLS (Multiprotocol Label Switching)

Technika IP Poziomy przekazu ruchu w sieci TCP/IP

Mechanizmy QoS dla sieci IP (1) Rozróżniamy dwa poziomy, tj.:  poziom wywołań, poziom pakietów IP. Poziom wywołań: wymagania takie jak w przypadku sieci z komutacją kanałów; wyrażają się poprzez podanie wartości prawdopodobieństwa odrzucenia zgłoszenia, zwykle przyjmowanego na poziomie 0.01. Inne są jednakże warunki, przy których to wymaganie powinno być spełnione. W sieci telefonicznej operuje się pojęciem GNR (Godzina Największego Ruchu), natomiast w sieciach pakietowych (zwłaszcza w sieci Internet) obciążenie sieci jest mniej zróżnicowane w ciągu doby.   Poziom pakietów: dotyczy jakości przekazu pakietów i odnosi się do takich parametrów jak opóźnienie przekazu pakietu przez sieć, zmienność tego opóźnienia, prawdopodobieństwo utraty pakietu wynikłe z chwilowego przeciążenia sieci itd.

Mechanizmy QoS dla sieci IP (2) Zapewnienie odpowiedniej jakości przekazu przez sieć IP wymaga, podobnie jak to uczyniono w sieci ATM, zdefiniowania odpowiednich funkcji realizujących QoS: zdefiniować klasy usług sieciowych wraz z mechanizmami zapewniającymi sterowanie ruchem; ogólnie mechanizmy takie mogą być zaimplementowane w każdym węźle (w tym przypadku w ruterze IP); przykładem usługi sieciowej jest usługa gwarantująca przekazanie pakietów przez sieć z możliwie małym opóźnieniem i z zapewnieniem minimalnych strat (usługa Premium), określić zasoby sieci przynależne danej usłudze sieciowej; w przypadku sieci pakietowej należy dla danej usługi sieciowej przydzielić odpowiednią przepustowość pasma na każdym łączu wyjściowym wraz z buforem dla gromadzenia pakietów powodujących chwilowe przeciążenia;

Mechanizmy QoS dla sieci IP (3) w ruterze IP powinny być zaimplementowane mechanizmy pozwalające rozróżniać pakiety wg ich przynależności do danej usługi sieciowej; należy zdefiniować dla każdej z usług sieciowych tzw. parametry QoS, określające jakość obsługi odbieraną na poziomie wywołania i na poziomie pakietów; należy zdefiniować funkcję realizującą przyjmowanie/odrzucanie nowych wywołań; należy zdefiniować parametry połączenia, zgłaszane w fazie zestawiania połączenia i dotyczące charakterystyki oferowanego ruchu; zwykle są one podawane w formie parametrów tzw. token-bucketu; należy nie dopuszczać do sieci ruchu, który nie jest zgodny z kontraktem ruchowym.

Proponowane architektury dla sieci QoS IP Sieć TCP/IP zakłada jedynie model usługi sieciowej best effort i zarządzanie ruchem jedynie na końcu systemu (end_system only traffic management). Dla zapewnienia QoS (Quality of Service), w ramach IETF (Internet Engineering Task Force) zaproponowano dwie alternatywne architektury dla sieci IP, a więc:   Architektura Integrated Services (z rezerwacją zasobów), oznaczaną w dalszej części jako architekturę IntServ; w architekturze tej zasoby sieci są przydzielane dla danej aplikacji na żądanie,  Architektura Differentiated Services (z ‘priorytetyzowaniem’ strumieni ruchu), oznaczaną w dalszej części jako architekturę DiffServ; w architekturze tej przesyłane przez sieć strumienie ruchu są klasyfikowane zgodnie z uprzednio wprowadzonymi usługami sieciowymi i przesyłane w sieci z różnymi priorytetami

Plan wykładu 1 2 3 4 Architektura AQUILA Mechanizmy QoS dla sieci IP Zasadnicze cechy architektury IntServ 3 Zasadnicze cechy architektury DiffServ 4 Architektura AQUILA

Architektura Intserv (1) W architekturze IntServ [RFC1633] zakłada się, że zasoby w sieci są rezerwowane dla poszczególnych lub zagregowanych strumieni danych. W tym celu został zdefiniowany specjalny protokół sygnalizacyjny znany pod nazwą protokołu RSVP (Reservation Protocol) [RFC2205, RFC2210], który umożliwia realizację żądania przez daną aplikację rezerwacji zasobów w sieci. Implementacja tego protokołu jest wymagana w każdym ruterze IP. W konsekwencji, ruter IP będzie przyjmował i realizował żądania rezerwacji, co wiąże się z przechowywaniem informacji o każdej poczynionej rezerwacji wraz z informacją o skojarzonym strumieniu danych. W architekturze IntServ zdefiniowano, oprócz standardowej usługi typu Best Effort , dwie dodatkowe usługi: Guaranteed Service [RFC2212] – przeznaczoną dla aplikacji wymagających gwarancji odnośnie parametrów jakości przekazu danych związanych z opóźnieniami, Controlled-load Service [RFC2211] – przeznaczoną dla aplikacji wymagających bezstratnego przekazu danych i charakteryzującą się jakością przekazu określaną jako lepszą niż Best Effort.

Architektura Intserv (2)

Architektura Intserv (3) protokół RSVP cechuje się następującymi własnościami: jest to protokół sygnalizacyjny (a nie realizujący sterowanie przekazem danych), rezerwacja jest typu “soft”, tj. musi być ona odnawiana okresowo, żądanie rezerwacji jest generowane przez odbiorcę, użycie protokołu przez daną aplikację wymaga opracowania specjalnego interfejsu API (Application Programming Interface), wymaga przechowywania informacji w ruterach o pojedynczych strumieniach danych, co w konsekwencji prowadzi do problemów ze skalowalnością sieci.

Plan wykładu 1 2 3 4 Technika IP Architektura AQUILA Zasadnicze cechy architektury IntServ 3 Zasadnicze cechy architektury DiffServ 4 Architektura AQUILA

Architektura DiffServ (1) Architektura DiffServ została zaproponowana jako rozwiązanie, które omija problem skalowalności, występujący w architekturze IntServ. W sieci definiujemy a priori odpowiedni zestaw usług sieciowych jedynie na podstawie mechanizmów priorytetyzowania strumieni w ruterach. Markowanie przynależności do usługi sieciowej za pomocą kodu DSCP – 6 bitów Format oktetu IPv4 TOS i pola DS (Differentiated Services).

Propozycje klas usług z kodami DSCP(IETF)

Architektura DiffServ (2) Sposób obsługi pakietu zależy od przynależności do strumienia zbiorczego (usługi sieciowej) Rutery brzegowe rozpoznają pojedyncze strumienie Rutery szkieletowe rozpoznają tylko strumienie zbiorcze (DSCP)

Architektura DiffServ (3) Rozwiązanie dla jednej domeny Dotyczy zapewnienia QoS pomiędzy ruterami końcowymi Bandwidth Broker dla przydzielenia przepływności

Granice klas usług dla pojedynczej domeny w strukturze wielo-domenowej AS – Autonomus System (domena)

Architektura DiffServ (4) Dotychczas w opracowaniach IETF zdefiniowano dwie podstawowe zasady przekazu pakietów (PHB), które w najprostszym przypadku mogą reprezentować dwa poziomy obsługi pakietów: Expedited Forwarding (EF) – określony przez pojedynczą wartość pola DSCP (Differentiated Services Codepoint), wykorzystywane do zapewnienia jakości obsługi związanej z parametrami opóźnień. Ruch ten jest monitorowany na wejściu do sieci; pakiety nie spełniające warunków zawartych w profilu ruchowym danego strumienia lub grupy strumieni są usuwane z sieci [RFC2598]; Assured Forwarding (AF) – określa cztery klasy i trzy poziomy odrzucania pakietów wewnątrz każdej z klas (w sumie 12 wartości pola DSCP). Ruch nie spełniający warunków zawartych w profilu ruchowym danego strumienia lub grupy strumieni dla danej klasy może być przesyłany jako ruch należący do niższej klasy lub może być po prostu odrzucony [RFC2597].

Architektura DiffServ (5)

Architektura DiffServ (6) Wyróżniamy następujące elementy funkcjonalne: Klasyfikator (Classifier) – typu BA (Behaviour Aggregate) lub MF (Multi-Field), klasyfikuje pakiety IP w przypadku BA na podstawie tylko pola DSCP, natomiast w przypadku MF, dodatkowo uwzględnia się inne informacje zawarte w nagłówku pakietu IP jak np. adres źródłowy, numer portu itd. Urządzenie monitorujące (Meter) – mierzy zgodność strumienia danych z parametrami zawartymi w kontrakcie SLA (najczęściej stosuje się algorytm typu Token Bucket) oraz umożliwia zbieranie statystyk ruchowych, Marker – znakuje lub usuwa pakiety niezgodne z parametrami zawartymi w kontrakcie ruchowym, Multiplekser – multipleksuje strumienie danych, Urządzenie usuwające pakiety – wyłącznie usuwa pakiety niezgodne z kontraktem ruchowym (np. algorytm RED – Random Early Detection), Kolejka – dla przechowywania pakietów w buforze (najczęściej stosuje się dyscyplinę obsługi typu FIFO), Urządzenie szeregujące pakiety – realizuje algorytm szeregujący pakiety do obsługi z poszczególnych kolejek, najczęściej spotykane rozwiązania oparte są na priorytetach lub algorytmie WFQ (Weithed Fair Queuing).

Architektura DiffServ (7) Oprócz wyżej wymienionych mechanizmów niezbędnym elementem funkcjonalnym w sieciach DS jest tzw. broker pasma (Bandwidth Broker), realizujący funkcje zarządzania zasobami i decydujący o przyjmowaniu nowych strumieni danych do obsługi. Broker w ramach jednej domeny realizuje zasady dostępu do wspólnych zasobów pomiędzy poszczególnych użytkowników. Pomiędzy operatorem sieci DS a grupą użytkowników jest zawierany kontrakt, tzw. Service Level Agreement (SLA). SLA zawiera specyfikację klas usług wraz z parametrami opisującymi dopuszczalny ruch jaki użytkownicy mogą generować w ramach każdej z klas. Ponadto, zawiera on informacje dotyczące adresów źródłowych i docelowych, numery portów, identyfikatory protokołu, aplikacji itd. Kontrakt ten może być zawarty w sposób statyczny (na dłuższy okres czasu) lub dynamiczny (w tym przypadku, konieczne jest użycie protokołu sygnalizacyjnego, np. RSVP).

Plan wykładu 1 2 3 4 Technika IP Zasadnicze cechy architektury IntServ Zasadnicze cechy architektury DiffServ 4 Architektura AQUILA

(Projekt IST-1999-10077) Adaptive Resource Control for QoS Using an IP-based Layered Architecture First let me introduce the AQUILA IST project. AQUILA is an abbreviation of Adaptive Resource Control for QoS Using an IP- based Layered Architecture. http://www-st.inf.tu-dresden.de/aquila/

Agent Sterowania Zasobami AQUILA: architektura Warstwa Sterowania Zasobami Obsługa Wywołań Sterowanie Zasobami Aplikacja Użytkownika Agent Obsługi Wywołań Agent Sterowania Zasobami zasoby zasoby Wywołanie QoS Wywołanie QoS Ustawienia Ustawienia wywołanie QoS Ruter Szkieletowy Sieć Dostępowa Ruter Brzegowy On this figure you can see the AQUILA architecture. We can distinguish two layers. First is network layer based on DiffServ architecture and second Resource Control Layer created by AQUILA. The Resource Control Layer components are: the End-User Application Toolkit, located at the end- user site, the Admission Control Agent, located at the edge router, and the Resource Control Agent, which logically a centralized entity within the network itself. User sends QoS Request to end-user application toolkit, next this request is sent to Admission Control Agent. Network resources are redistributed by Resource Control Agent. In first phase of the AQUILA project, the focus is on QoS in a single domain.

Klasy usług sieciowych Usługa sieciowa Zdolność sieci dla przekazu strumieni ruchu przy zapewnieniu gwarancji odnośnie QoS Gwarancje QoS: Gwarancje relatywne – dla jednej klasy ruchu zapewniamy „lepszy” przekaz pakietów niż dla innych klas Gwarancje absolutne – dla każdej klasy ruchu zapewniamy gwarancje przekazu pakietów, które są wyrażone poprzez takie parametry jak poziom strat pakietów, opóźnienie pakietów i zmienności opóźnienia pakietów

Propozycje klas usług z kodami DSCP(IETF)

AQUILA: usługi sieciowe Typy ruchu w sieci IP Strumieniowy Elastyczny Stała szybkość bitowa Długotrwałe połączenia TCP Zmienna szybkość bitowa Krótkotrwałe połączenia TCP Usługi Sieciowe To explain the AQUILA architecture and concepts I would like to present the following picture. On the top we have types of traffic, which we can distinguish in IP networks. Generally, we can distinguish between two types of traffic: Streaming and Elastic. Streaming traffic can consists of both Constant Bit Rate as well as Variable Bit Rate traffic and is generated by real time applications served by UDP protocol. On the contrary Elastic traffic can be produced by long live TCP greedy sources or short live TCP non-greedy sources. In AQUILA project for each type of traffic there have been created network services, which can be offered by providers. Since now, we have considered 4 network services Premium CBR, Premium VBR, Premium Multimedia and Premium Mission Critical. These services can offer QoS for traffic in IP network. Premium CBR Premium VBR Premium Multimedia Premium Mission Critical

AQUILA: koncepcja i architektura (2) Usługi Sieciowe: Premium CBR dla aplikacji typu telefonia IP, voice trunking bardzo małe opóźnienia oraz pomijalny poziom strat pakietów, gwarancja pasma Premium VBR dla obsługi wideo oraz telekonferencji bardzo małe opóźnienia pakietów, pomijalny poziom strat pakietów, gwarancja pasma Premium Multimedia dla aplikacji adaptujących się do warunków panujących w sieci (TCP), np. ftp gwarancja pasma, umiarkowane opóźnienia pakietów Premium Mission Critical gry interaktywne, operacje bankowe bardzo małe straty pakietów, źródła „nie zachłanne” wysyłające krótkie pakiety Standard obsługa na zasadzie „best effort” Each network service supports a class of applications with similar requirements and traffic characteristics. Premium CBR is mainly dedicated for IP Telephony an Voice Trunking. It should guarantee very low packet delay and jitter, very low losses and hard bandwidth guarantees. Premium VBR is for Video Streaming and Teleconferencing. It should guarantee also low packet delay and jitter, low losses and bandwidth guarantee. Premium Multimedia is dedicated for adaptive applications (for instance ftp), with bandwidth guarantee and moderate delay. Premium Mission Critical has been created for interactive games, online banking. It guarantees very low packet delay and packet losses. The last one is Standard service and it is classical best effort service.

Co chcemy zapewnić dla usług sieciowych ? Rozróżnienie QoS Każdy strumień pakietów obsługiwany w ramach danej usługi sieciowej powinien doświadczyć podobnego poziomu QoS Oddzielenie usług sieciowych(ruch z jednej klasy nie powinien wpływać na ruch z innej klasy) Każda klasa powinna oferować inny poziom QoS Algorytmy AC powinny być efektywne aby zagwarantować założony poziom QoS Prawidłowość mapowania wartości deskryptorów ruchu z parametrów opisujących aplikację

Obsługa usług sieciowych w ruterach Napływ pakietów PMM VBR PMC CBR Klasyfikatorr Standard C1 C2 C3 C4 C5 PQ Napływ pakietó PMM VBR PMC CBR Klasyfikatorr C WFQ Standard High priority Low priority Model obsługi dla wyznaczenia AC Obsługa w ruterze WFQ – Weighted Fair Queueing PQ – Priority Queueing C1+C2+C3+C4+C5=C

Mechanizmy dla obsługi strumieni ruchu Alokacja i redystrybucja zasobów (Provisioning) Parametry wejściowe: Topologia sieci Ruting Macierze zainteresowania dla poszczególnych klas ruchu Parametry wyjściowe: Maksymalne przepustowość łącza dedykowana dla każdej klasy (określana jako provisioned rate) Limit pasma dedykowanego dla danej klasy ruchu na węzłach brzegowych (ED) Wartości parametrów dla mechanizmu zarządzania zasobami (Resource Pools) Traffic classes let us introduce QoS differentiation at the service and the traffic level. To deliver QoS guarantees AQUILA considers three mechanisms at aggregate level. The Provisioning phase is one of them and it is run off-line before the network operation, and gives the required input to the Resource Control Layer elements as well as configuration values for setting the router parameters. The Initial Provisioning Phase takes as an inut: - network topology, - routing (costs of links), - the expected traffic distribution between Edge Routers for each Traffic Class, and any further constraints on the link bandwidth sharing between TCLs. As an output it produces: -expected amount of traffic for each Traffic Class on each link, called provisioned rate. This is used for the router configuration, i.e. to choose the appropriate setting for the scheduling / queuing parameters (WFQ weights, WRED thresholds) at each router interface; -the Admission Control Limits for each Traffic Class at each Edge Router. This is used by AC algorithms during the operation phase; -Definition of the Resource Pools sets

Modelowanie usług sieciowych w ruterach Założenie: każda usługa ma oddzielne zasoby Model obsługi dla każdej klasy: - oddzielny system - przydzielone zasoby dla każdej z klas: - pojemność C - bufor B Algorytmy AC – przyjmowania nowych wywołań Napływ pakietów danej klasy Bufor B Pojemność C Wynik analizy: Poziom QoS Modelowanie strumienia ruchu Analiza systemu

Laboratoria projektu w Warszawie

Example of AQUILA network topology Real network topology Lab testbed topology 8 routers connected in the chain topology Test traffic Artificial flows submitted between PC1 and PC3 Background traffic submitted on an ingress link to the network

Instalacja pilotowa dla projektu AQUILA The presented concepts there were implemented in three AQUILA testbedS. On this slide you can see the testbed configuration in Warsaw. 8 ruterów CISCO połączonych w topologii kaskadowej

NetMeeting - PVBR service HP BSTS BGT: 2.1 Mbps, STD service Reservation parameters PVBR service : (PR=270kbps,BSP=2000B, SR=270kbps,BSS=15000B)

Real Player - PMM service HP BSTS BGT: 2.1 Mbps, STD service Reservation parameters -PC4-PC2 PMM service : (SR=250kbps,BSP=15000B) PC4-PC7 STD service

Demonstracja aplikacji RealPlayer Z gwarancją jakości obsługi Bez gwarancji jakości obsługi

Projekt AQULA pokazał, że jest możliwa implementacja QoS w sieci IP Podsumowanie Projekt AQULA pokazał, że jest możliwa implementacja QoS w sieci IP Wyniki projektu są podstawą dla realizacji obecnie działających projektów EuQoS - End-to-end QoS over Heterogenous Networks Daidalos - Designing Advanced Interfaces for the Delivery and Administration of Location Independent Optimised personal Services.