Ponadto SLA powinno definiować następujące parametry:

Transkrypt

1 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ć w ramach danej usługi. Kontrakt taki powinien również zawierać jednoznacznie określone sposoby oceny jakości otrzymywanej usługi, czyli zgodności dostarczonej usługi z zawartym kontraktem SLA. Dodatkowo konieczne jest kontrolowanie klienta, czy dotrzymuje warunków umowy. Ważne elementem jest również ustalenie zakresu odpowiedzialności za złamanie kontraktu przez każdą ze stron. Ponadto SLA powinno definiować następujące parametry: klasę dostarczanej usługi (CoS) lub wartości gwarantowanych parametrów QoS; dostępność usługi; zakres gwarantowanej obsługi technicznej; zasady naliczania i pobierania opłat za dostarczane usługi.

2 SERVICE LEVEL AGREEMENT (SLA) CZ. II Service Level Specification (SLS) jest to zbiór parametrów technicznych o określonych wartościach, z jakimi będzie przesyłany przez sieć strumień pakietów związanych z daną usługą. SLS stanowi techniczną część kontraktu SLA pomiędzy klientem a dostawcą usługi. W ramach IETF są prowadzone prace mające na celu szczegółowe zdefiniowanie SLS. Dyskutowane są dwie koncepcje. Jedna z nich zakłada możliwość dynamicznego negocjowania parametrów SLS pomiędzy klientem i operatorem, druga zaś przewiduje opracowanie predefiniowanych typów SLS i zasad posługiwania się nimi, obowiązujących wszystkich operatorów. Traffic Conditioning Specification (TCS) jest to zbiór parametrów o określonych wartościach, który jednoznacznie określa profil ruchu oraz reguły klasyfikowania pakietów. TCS jest pojęciem ściśle technicznym, podczas gdy TCA jest pojęciem szerszym, obejmującym oprócz TCS definicje poszczególnych usług i uzgodnienia z klientem. TCS jest integralną częścią SLS.

3 SERVICE LEVEL AGREEMENT (SLA) CZ. III Traffic Conditioning Agreement (TCA) jest to porozumienie określające reguły klasyfikowania pakietów oraz profile ruchu odpowiednie dla różnych strumieni ruchu. TCA definiuje zasady oznaczania pakietów (nadawanie wartości punktu kodowego DSCP, ang. marking), odrzucania pakietów, kształtowania ruchu (proces opóźniania pakietów mający na celu dostosowanie strumienia ruchu do określonego profilu ruchu ang. shaping) oraz wykonywania pomiarów ruchu (ang. Metering). Zbiór reguł formowania ruchu zdefiniowany w TCA stanowi część SLA. Porozumienie TCA nakłada na klienta obowiązek do stosowania generowanego ruchu do uzgodnionego profilu ruchu z operatorem. Określa ono również, w jaki sposób będą traktowane pakiety klienta zarówno w przypadku zgodności z profilem ruchu, jak i w przypadku naruszenia warunków umowy.

4 JAKOŚĆ USŁUG W SIECIACH PAKIETOWYCH Pojęcie jakości usług w sieciach pakietowych to zbiór technologii, które pozwalają użytkownikom otrzymywać od sieci przewidywalny poziom usług w kontekście przepustowości (ang. bandwith), opóźnienia (ang. delay) i zmienności opóźnienia (ang. jitter). Aby węzeł danych otrzymał wymaganą jakość usług, każdy węzeł sieci musi być powiadomiony o tych wymaganiach. Wyróżnia się dwie metody powiadamiania o wymaganiach związanych z jakością usług. Etykietowanie pakietów powiadamianie poprzez oznaczanie pakietów. Sygnalizacja powiadamianie poprzez specjalny protokół. Obecnie dominują dwa modele QoS w sieciach pakietowych: Model oparty na rezerwacji zasobów. Model oparty na rozróżnianiu klas ruchu.

5 MODEL OPARTY NA REZERWACJI ZASOBÓW Aplikacje przy pomocy protokołu sygnalizacyjnego zgłaszają sieci swoje wymagania z zakresu przepustowości i opóźnienia. Węzły sieci przeprowadzają kontrolę dostępności zasobów potrzebnych do zapewnienia żądanego poziomu usługi. W przypadku dostępności odpowiednich zasobów następuje ich rezerwacja tak, aby dany węzeł sieci mógł świadczyć żądaną jakość usługi. Rezerwacja gwarantuje aplikacji żądaną jakość usługi, o ile generowany przez nią ruch nie przekracza zgłoszonych parametrów. Węzeł sieciowy sprawdza i ewentualnie ogranicza ruch do zgłoszonych parametrów. Przykładowe rozwiązanie opierające się o model z rezerwacją zasobów to model IEFT IntServ z użyciem protokołu RSVP.

6 MODEL OPARTY NA ROZRÓŻNIANIU KLAS RUCHU W modelu tym nie ma jawnego zgłaszania przez aplikację wymagań co do jakości usługi, natomiast strumień danych generowany przez aplikację zaliczany jest do jednej z kilku klas ruchu. Każda klasa ruchu oznaczana jest odpowiednią etykietą zawartą w pakietach danych, na podstawie której węzły sieci dostarczają odpowiedniej jakości usług. Węzły sieci nie dostarczają bezwzględnej jakości usług, lecz względną, rozróżniając ruch na podstawie przynależności do danej klasy. Model ten jest bardzo łatwo skalowalny z tego względu, że nie ma konieczności rozpoznawania pojedynczych strumieni danych. Przykładowe rozwiązanie opierające się o rozróżnianie klas ruchu model IETF DiffServ.

7 PODSTAWY KLASYFIKACJI PAKIETÓW Celem jest odpowiednie zidentyfikowanie pakietów, tak aby prawidłowo rozpoznać ich wymagania co do jakości usług. Pakiety zostaną zakwalifikowane do odpowiedniej klasy usług na podstawie następujących kryteriów: źródłowy / docelowy adres IP interfejs Numery portów TCP /UDP Adres MAC Możliwa jest również klasyfikacja pakietów na podstawie warstwy aplikacji (NBAR)

8 KLASYFIKACJA PAKIETÓW NBAR NBAR Network-Based Application Recognition Klasyfikacja pakietów na podstawie: Protokołów warstwy 5-7 modelu OSI Dynamicznie uzgadnianych portów TCP/UDP HTTP URL W tej chwili przez NBAR obsługiwane są np. następujące protokoły: HTTP / URL SAP RealAudio MSExchange PeopleSoft MS Netshow SUN RPC r-commands SQL-Net TIBCO H.323 VDOLive NBAR zakłada możliwość zdefiniowania obsługi nowych protokołów poprzez skrypty w języku PDL (ang. Packet Description Language)

9 ETYKIETOWANIE PAKIETÓW Pakiet po zakwalifikowaniu do odpowiedniej klasy usług oznaczany jest etykietą identyfikującą daną klasę usług. Etykieta pozwala innym węzłom sieci na szybkie rozpoznawanie klasy usług Do technik etykietowania pakietów można zaliczyć: Warstwa 3 modelu OSI IPv4 IP Precedence Field IPv4 DiffServ Differentiated Services Field IPv6 DiffServ Differentiated Services Field Warstwa 2 modelu OSI IEEE 82.1d (82.1p+q) User Priority Field MPLS Exp / CoS Field

10 ETYKIETOWANIE W WARSTWIE 2 MODELU OSI Pierwsze dwa bajty Q Tag Type, który jest ustawiany na x81 zastępuje pole Length/Type Field Następne dwa bajty: User Priority Field (3 bity) wskazuje na poziom priorytetu ramki Canonical Format Indicator (1 bit) wskazuje na tzw. Routing Information Field VLAN Identifier (12 bitów) - VID jednoznacznie wskazuje na VLAN, do którego dana ramka przynależy

11 ETYKIETOWANIE W WARSTWIE 3 MODELU OSI

12 USTAWIENIA POLA TOS W IPv4 Usługa Minimize delay Maximize throughput Maximize reliability Minimize monetary cost Wart. hex Telnet/Rlogin 1 x1 FTP control data 1 1 x1 x8 any bulk data 1 x8 TFTP 1 x1 SMTP command phase data phase 1 1 x1 x8 DNS UDP query TCP query zone transfer 1 1 x1 x x8 ICMP error query x x any IGP 1 x4 SNMP 1 x4 BOOTP x NNTP 1 x2

13 ALTERNATYWNE ETYKIETY W IPv4 Pole DS Differientiated Services Field opisany w RFC 2747.

14 ARCHITEKTURA USŁUG ZINTEGROWANYCH Usługi zintegrowane rezerwacja zasobów w sieciach klasyfikatory kolejki mechanizmy rezerwacji statyczne dynamiczne (protokół RSVP) Elementy architektury IntServ Rozszerzenia tradycyjnych mechanizmów Internetu Związanie każdego pakietu IP z przepływem (strumieniem pakietów wymagających tego samego QoS) Kontrola dopuszczania do zasobów sieci nowego przepływu Algorytmy rutowania Założenia IntServ Dyscyplina kolejkowania Polityka odrzucania pakietów

15 REZERWACJA ZASOBÓW

16 PRZETWARZANIE PAKIETÓW W INTSERV

17 USŁUGI W ARCHITEKTURZE INTSERV CZ. I Usługi Controlled Load Cechy: Brak górnej granicy czasu opóźnienia pakietów Bardzo wysoki procent pakietów jest dostarczany pomyślnie Aproksymacja do usługi best-effort w warunkach sieci nieobciążonej Zastosowania dla aplikacji: Adaptacyjnych czasu rzeczywistego Wrażliwych na szybkie zmiany obciążenia sieci

18 USŁUGI W ARCHITEKTURZE INTSERV CZ. II Usługi Guaranted Service Cechy: Stały poziom przepustowości danych Górna granica czasu opóźnienia pakietów Brak strat pakietów Najbardziej wymagająca usługa w architekturze Integrated Services Zastosowania dla aplikacji: Wrażliwych na stratę pojedynczych pakietów Wymagających obsługi w czasie rzeczywistym

19 WADY USŁUG ZINTEGROWANYCH Wysokie wymagania sprzętowe 1. Protokół sygnalizacyjny RSVP (Resource Reservation Protocol) 2. Admission control 3. Packet classification 4. Packet scheduling Nadmiar informacji Pomimo dużej ilości informacji sterującej wymaganej do zastosowania w sieci architektury IntServ, pakiety danych nie zawierają tak kluczowych dla obserwatora informacji, jak status bieżącego QoS. Skomplikowany routing, opóźnienia Zmiana routingu pociąga za sobą konieczność zmiany rezerwacji, co komplikuje zarządzanie siecią oraz powoduje opóźnienia w ruchu pakietów.