Jakość to będzie… - policing w sieci SDN

30 Czerwca 2022

Dzisiejsza telekomunikacja w znakomitej większości opiera się o sieci IP. W największym uproszczeniu jest to sieć, do której należą wszelkie urządzenia podłączone do Internetu. W sensie ścisłym sieć IP dotyczy urządzeń działających w 3 warstwie stosu TCP/IP lub ISO/OSI. Pomimo tak powszechnego wykorzystania sieci IP, jej bolączką jest brak zapewnionej jakości transmisji, tzw. QoS (Quality of Service). Objawy tego możemy dostrzec przede wszystkim przy połączeniach audio/video w czasie rzeczywistym, np. Skype, WhatApp, streaming. Rozmowa może się zawieszać lub zacinać, obraz traci na jakości lub całkowicie zanika. Taki stan może być wywołany spadkami liczby przesyłanych pakietów (packet loss), zbyt dużą zmiennością czasu dotarcia pakietu (jitter) lub zbyt dużym opóźnieniem czasu dotarcia pakietu (delay).

Jakość w sieciach IP

W celu rozwiązania problemu z jakością transmisji w sieciach IP zostały zaproponowane dwie architektury: IntServ oraz DiffServ. Pierwsza z nich zakładała rezerwację zasobów w każdym kolejnym węźle będącym na ścieżce łączącej punkty końcowe transmisji. Rozwiązanie to nie sprawdziło się ze względu na słabą skalowalność, tj. duża złożoność procesu rezerwacji zasobów w większych sieciach, jak również wysokie narzuty mocy obliczeniowej i pamięci związane z przetwarzaniem strumieni danych. Druga z architektur, tzw. DiffServ, za punkt wyjścia przyjęła przydzielanie pakietów do klas ruchu, o różnym priorytecie, uprzednio zdefiniowanych na routerach. Każdy pakiet zawiera dedykowaną informację o klasie ruchu do której jest przydzielony. Po dotarciu do kolejnego węzła sieci, informacja ta jest poddawana analizie, zaś pakiet obsługiwany jest zgodnie ze zdefiniowanymi priorytetami. Dzięki temu uniknięto złożoności wynikającej z rezerwacji zasobów, a przy tym zapewniono określoną jakość transmisji dla różnych strumieni danych.

Sieć programowalna czyli SDN

W ostatnich latach sieci SDN (z ang. Software-Defined Network) stały się gorącym tematem w świecie telekomunikacji. Z perspektywy operatora telekomunikacyjnego jest to milowy skok technologiczny od ręcznej konfiguracji urządzeń do zautomatyzowanej konfiguracji realizowanej przez kontroler znajdujący się w centrum całej sieci. Od kreowania usług na poziomie pojedynczych urządzeń do równoczesnej konfiguracji wielu. Co istotne, przy udziale programistów i inżynierów sieci mogą powstawać zupełnie nowe usługi dostosowywane do wymagań klienta. Wreszcie, nad procesem implementacji i wdrażania nowych usług czuwa operator telekomunikacyjny, który zamiast wykorzystywać gotowe rozwiązanie od zewnętrznego dostawcy, może wsłuchać się w głos klienta i w sposób spersonalizowany przygotować rozwiązanie od backend-u po frontend.

Mechanizmy zapewnienia jakości w sieci

O jakość transmisji w sieci możemy zadbać dwutorowo. Raz, poprzez nakładanie reguł ograniczających transmisję danych – traffic policing. Dwa, poprzez kształtowanie ruchu wychodzącego ze switcha – traffic shaping (patrzy: rysunek 1.).

Rysunek 1. Wynik kształtowania ruchu mechanizmami policingu i shapingu | Na podstawie: cisco.com

Traffic policing polega na ograniczeniu ruchu (patrz: rysunek 2.) w procesie:

meteringu – pomiar szybkości transmisji danych w sieci przy użyciu mechanizmu tocken bucket (wiadro z żetonami) i klasyfikacja ruchu
markowania – oznaczenie ramek kolorami zależnie od klasyfikacji ruchu: zielony (zagwarantowany), żółty (best effort), czerwony (odrzucony)
akcji – przekazanie lub odrzucenie ramki

Rysunek 2. Proces traffic policingu

Traffic shaping jest mechanizmem odpowiedzialnym za kształtowanie ruchu (patrz: rysunek 3.) na drodze:

klasyfikacji – klasyfikacja ruchu na podstawie pola MPLS_TC lub VLAN_PCP pakietów przychodzących do switch-a. Są to 3 bitowe pola składowe nagłówków MPLS/VLAN, dzięki którym możemy wyróżnić do 8 klas ruchu.
kolejkowania – zaklasyfikowane pakiety wpadają do kolejek na switch-u przeznaczonych dla różnych typów ruchu bądź o różnym priorytecie.
szeregowania – w obrębie szeregowania ruchu wykorzystywane są różne algorytmy decydujące o kolejności przekazywania pakietów do bufora wyjściowego switch-a po czym są z niego kolejno wypuszczane.

Rysunek 3. Proces traffic shapingu

Konfiguracja urządzeń przez kontroler SDN

Fakt, że sieć SDN jest programowalna, sprawia że możemy poprzez odpowiednią implementację kontrolera SDN zarządzać urządzeniami i ruchem w sieci, w tym jakością transmisji danych. Zapewnienie QoS (Quality of Service) wiąże się z konfiguracją odpowiedniego mechanizmu sieciowego w urządzeniu sieciowym, toteż jest wymagane, aby kontroler wspierał określony protokół komunikacyjny na tzw. mostku południowym, czyli w warstwie abstrakcji odpowiedzialnej za bezpośrednią komunikację z urządzeniem sieciowym (patrz: rysunek 4.)

Aby sterować QoS z poziomu kontrolera, należy wpierw uzyskać połączenie z urządzeniem. W tym celu należy zaimplementować driver do obsługi urządzenia na mostku południowym z wykorzystaniem protokołu komunikacyjnego. Dzięki temu możliwe będzie podłączenie urządzenia do kontrolera i konfiguracja w ramach dedykowanej usługi sieciowej z poziomu warstwy aplikacji.

Rysunek 4. Architektura kontrolera SDN z uwzględnieniem komunikacji z urządzeniami sieciowymi Open vSwitch

Policing w praktyce

Policing sprowadza się do konfiguracji tzw. profili przepływności (bandwidth profile). W ramach profilu przepływności definiujemy 4 wartości: CIR, EIR, CBS, EBS.

CIR (Committed Information Rate) wyrażony w b/s (bity na sekundę) pozwala na określenie zagwarantowanej szybkości transmisji danych. Ruch w zakresie określonym przez CIR markowany jest na zielono.

EIR (Excess Information Rate) wyrażony również w b/s określa zapas przepływności wykorzystywany w przypadku całkowitego wykorzystania przepływności określonej w parametrze CIR. Ruch w zakresie określonym przez EIR oznaczany jest na żółto. Dostępność pasma w ramach EIR uzależniona jest od innych usług, które mogą wykorzystać to samo pasmo. Stąd, ruch w tym zakresie określany jest jako best effort.

CBS (Committed Burst Size) wyrażony w B (bajt) określa dopuszczalną wielkość ramek z danymi, które mogą zostać jednorazowo przekazane. Jest to szczególnie istotne w kontekście wielosegmentowych ramek, np. w mechanizmie zwielokrotnienia transmisji danych w protokole TCP. Przy małym CBS mechanizm nie będzie w stanie efektywnie pracować. Równocześnie, nieduży CBS sprzyja przesyłowi niewielkich porcji danych, co może być istotne w kontekście komunikacji real-time (np. głosowej), gdzie istotna jest niska zmienność opóźnienia dostarczanych ramek.

EBS (Excess Burst Size) wyrażony w B (bajt) określa dodatkowy bufor wielkości ramek z danymi. Wykorzystywany jest w sytuacji, gdy ramki przekroczą wartość CBS.

Przykładowa konfiguracja

Zaprezentowana niżej konfiguracja (rysunek 5.) jest oparta na switch-u Open vSwitch i protokole OpenFlow, które w swojej bazowej formie są elastyczne i zgodne z wymaganiami sieci SDN.

Rysunek 5. Przykładowa topologia do weryfikacji policingu

Aby zdefiniować profile przepływności zrozumiałe dla Open vSwitch-a konieczne jest utworzenie tzw. meterów. Meter jest funkcjonalnością protokołu OpenFlow monitorującą wielkość ruchu przychodzącego lub wychodzącego. W zależności od ustawionej reguły może ruch przepuścić (pass) lub przyciąć (drop).

W sieci SDN proces tworzenia meterów jest prowadzony przez kontroler SDN. Można to zrobić również bezpośrednio na switch-u. W tym celu należy wywołać komendę:

ovs-ofctl add-meter

Przy wywołaniu należy wskazać

port bridge-a,
oznaczenie meter-a (meterId),
jednostkę przepływności (kilobity na sekundę lub pakiety na sekundę),
typ metera (pass/drop),
rate (odpowiada CIR) oraz burst size (odpowiada CBS).

Należy przy tym zauważyć, że dla OVS-a nie definiujemy czterech parametrów traffic policingu, a jedynie dwa, więc po stronie architekta pozostaje decyzja czy uwzględniać parametry EIR/EBS w ramach wspólnego rate/burst czy też nie.

Przykład konfiguracji dla CIR = 5000 kbps i CBS = 2000 kb:

ovs-ofctl add-meter br0 
meter=1,kbps,burst,band=type=drop,rate=5000,burst_size=2000

Na switchu zostanie dodany meter o zadanych parametrach:

OFPST_METER_CONFIG reply (OF1.3) (xid=0x2):

meter=1 kbps burst bands=
type=drop rate=5000 burst_size=2000

Ruch transportowany przez switch będzie przycinany do wartości CIR. Tu wysłany ruch protokołem UDP 10 Mb/s zostaje przycięty do 5 Mb/s.

Host A:

Connecting to host 172.16.0.11, port 5201

[  5] local 172.16.0.10 port 60925 connected to 172.16.0.11 port 5201
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec  1.19 MBytes  10.0 Mbits/sec  863
[  5]   1.00-2.00   sec  1.19 MBytes  10.0 Mbits/sec  863
[  5]   2.00-3.00   sec  1.19 MBytes  10.0 Mbits/sec  864
[  5]   3.00-4.00   sec  1.19 MBytes  10.0 Mbits/sec  863
[  5]   4.00-5.00   sec  1.19 MBytes  10.0 Mbits/sec  863
[  5]   5.00-6.00   sec  1.19 MBytes  10.0 Mbits/sec  863
[  5]   6.00-7.00   sec  1.19 MBytes  10.0 Mbits/sec  864
[  5]   7.00-8.00   sec  1.19 MBytes  10.0 Mbits/sec  863
[  5]   8.00-9.00   sec  1.19 MBytes  10.0 Mbits/sec  863
[  5]   9.00-10.00  sec  1.19 MBytes  10.0 Mbits/sec  863
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  11.9 MBytes  10.0 Mbits/sec  0.000 ms  0/8632 (0%)  sender
[  5]   0.00-10.00  sec  6.60 MBytes  5.54 Mbits/sec  0.187 ms  3851/8632 (45%)  receiver

Host B:

Accepted connection from 172.16.0.10, port 58486
[  5] local 172.16.0.11 port 5201 connected to 172.16.0.10 port 60925
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  1.19 MBytes  9.99 Mbits/sec  0.205 ms  0/863 (0%)
[  5]   1.00-2.00   sec   795 KBytes  6.51 Mbits/sec  0.234 ms  300/862 (35%)
[  5]   2.00-3.00   sec   594 KBytes  4.87 Mbits/sec  0.345 ms  445/865 (51%)
[  5]   3.00-4.00   sec   592 KBytes  4.85 Mbits/sec  0.173 ms  443/862 (51%)
[  5]   4.00-5.00   sec   592 KBytes  4.85 Mbits/sec  0.199 ms  443/862 (51%)
[  5]   5.00-6.00   sec   592 KBytes  4.85 Mbits/sec  0.245 ms  443/862 (51%)
[  5]   6.00-7.00   sec   594 KBytes  4.87 Mbits/sec  0.223 ms  445/865 (51%)
[  5]   7.00-8.00   sec   594 KBytes  4.87 Mbits/sec  0.219 ms  445/865 (51%)
[  5]   8.00-9.00   sec   592 KBytes  4.85 Mbits/sec  0.443 ms  442/861 (51%)
[  5]   9.00-10.00  sec   594 KBytes  4.87 Mbits/sec  0.187 ms  445/865 (51%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  6.60 MBytes  5.54 Mbits/sec  0.187 ms  3851/8632 (45%) receiver

Perspektywy QoS w sieciach SDN

Sieci telekomunikacyjne ewoluują wraz ze zmieniającymi się potrzebami i możliwościami rynku. Jeszcze kilka lat temu jako użytkownicy cieszyliśmy się z prędkości rzędu 10 Mb/s po kablu miedzianym. Dzisiaj standardem stają się połączenia światłowodowe. EXATEL jako właściciel dużej sieci światłowodowej ma ambicje by sieć SDN stała się standardem w telekomunikacji. Przy rosnącym zapotrzebowaniu na pasmo, konieczne będzie zapewnienie jakości transmisji w sieci dostosowanej do preferencji klientów korzystających z naszych usług. Sieć SDN ze względu na wysoką programowalność w połączeniu z zapewnieniem QoS pozwoli wdrażać nowe usługi szybciej, na większą skalę i o większym poziomie zróżnicowania.