W artykule Jakość to będzie… – policing w sieci SDN została podjęta tematyka zapewnienia szeroko rozumianej jakości transmisji danych w sieciach SDN. Omówiłem w nim traffic policing, czyli przycinanie ruchu do wartości określonych przez użytkownika. Niniejszy artykuł jest kontynuacją wspomnianego tekstu i ma na celu zaznajomienie czytelnika z innym sposobem zapewnienia QoS, poprzez tzw. traffic shaping.
Idea kolejkowania ruchu
Traffic shaping to inaczej kształtowanie ruchu. Charakteryzuje się wykorzystaniem mechanizmów QoS do przesłania określonej porcji danych w możliwie efektywny sposób, tj. bez znaczących strat pakietów. Innymi słowy, ruch zamiast być przycinany do określonego poziomu, może zostać wstrzymany przez urządzenie sieciowe, a przez to jego charakterystyka może ulec wygładzeniu (patrzy: rysunek 1.).
Rysunek 1. Wynik kształtowania ruchu mechanizmami policingu i shapingu | źródło: cisco.com
Gdy natężenie ruchu w sieci nie przekracza zadeklarowanych wartości, jest on bez przeszkód transmitowany przez sieć. Gdy zbliża się do limitów zostaje przytrzymany. Swoiste przytrzymanie ruchu sieciowego nazywamy buforowaniem. Buforowanie polega na zapisaniu pakietów w dedykowanym miejscu w pamięci urządzenia. Użytkownik może zadeklarować wielkość takiego bufora. Jeśli bufor zostanie przepełniony, kolejne pakiety są odrzucane (patrz rysunek 2.).
Rysunek 2. Kolejkowanie - buforowanie nadmiarowych pakietów
Buforowanie ma również swoje zastosowanie w codziennym odtwarzaniu filmów na internetowych platformach video takich jak YouTube. Do prawidłowego odtworzenia filmu potrzeba określonej porcji danych z sieci. Jeśli dane dotrą do odbiorcy, film jest odtwarzany. Jeśli nie, dane są zbierane w buforze by następnie przekazać widzowi pełną klatkę, a w konsekwencji ruchomy obraz. W tym przypadku buforowanie służy do gromadzenia danych. W sieciach ma na celu przytrzymanie nadmiarowego ruchu, co nazywamy kolejkowaniem.
Kolejkowanie w sieciach
Najprostsze kolejkowanie w sieciach mogłoby składać się z jednego bufora. W istocie pojedyncza kolejka o zadanych parametrach pozwala utrzymać ruch na określonym poziomie np. 100 Mb/s. Jednakże, prawdziwa wartość mechanizmu kolejkowania pakietów ujawnia się przy tzw. schedulingu, czyli szeregowaniu pakietów z użyciem wielu kolejek.
W sieci możemy wyróżnić różne typy ruchu i związane z nim zapotrzebowania. Mogą to być strumienie audio/video do rozmów real-time, mogą to być zwykłe dane, które muszą zostać przesłane end-to-end. Ruch typu real-time musi zostać obsłużony w możliwie najszybszym czasie, bez opóźnień i wahań czasu dotarcia kolejnych pakietów. Z kolei jedynym wymaganiem na transmisję danych jest pewność dotarcia do odbiorcy. Widać zatem, że oba typy ruchu mają różne priorytety. Jeśli dwa takie strumienie spotkają się w sieci, warto je rozróżnić, oznaczyć i przyporządkować do odpowiedniej kolejki, gdzie kolejka dla ruchu real-time powinna mieć wyższy priorytet niż kolejka dla zwykłych danych. Na koniec określony mechanizm urządzenia powinien dokonać wyboru czy przekazać na wyjście urządzenia sieciowego pakiet z kolejki z wyższym priorytetem czy z niższym, a jeśli z wyższym, to na ile pakietów kolejki wyższej powinien zostać pobrany pakiet z kolejki niższej. Za to odpowiada właśnie scheduler, czyli algorytm szeregujący pakiety z poszczególnych kolejek. Jednym z popularniejszych algorytmów tego typu jest WFQ (z ang. Weighted Fair Queueing).
Kształtowanie ruchu (traffic shapingu) jest zatem dość złożonym procesem, w którym można wyróżnić następujące fazy (patrz rysunek 3.):
- klasyfikację – rozróżnienie ruchu na podstawie określonych pól w pakietach np. 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żna wyróżnić do 8 klas ruchu.
- kolejkowanie – zaklasyfikowane pakiety zostają przyporządkowane do kolejek na switch-u przeznaczonych dla różnych typów ruchu bądź o różnym priorytecie.
- szeregowania – algorytm szereguje pakiety i decyduje, który pakiet z której kolejki pobrać i przekazać na bufor wyjściowy.
Rysunek 3. Proces traffic shapingu
Realizacja kolejkowania w sieci SDN
By ruch sieciowy mógł zostać poddany procesowi traffic shapingu, należy skonfigurować urządzenia sieciowe. Zaletą sieci SDN jest automatyzacja tego procesu. Kontroler sieci SDN jako centralna jednostka przetrzymuje informacje o całej topologii sieci. Dzięki temu jest w stanie wyróżnić porty końcowe sieci operatora (patrz rysunek 4.) tzw. porty klienckie UNI (z ang. User Network Interface), jak również porty między kolejnymi urządzeniami wewnątrz sieci operatora I-NNI (z ang. Internal Network-to-Network Interface). Co więcej, kontroler ma możliwość równoczesnej konfiguracji wszystkich urządzeń sieciowych, które widzi w sieci. Dokonuje wyboru portów do konfiguracji spośród danych urządzeń i podejmuje na nich działanie.
W przypadku traffic shapingu konieczne jest wskazanie portów INNI, instalacja na nich klasyfikatorów, kolejek oraz aktywacja stosownego algorytmu szeregowania pakietów.
W przypadku sieci SDN opartej na protokole OpenFlow i przy wykorzystaniu urządzeń sieciowych Open vSwitch proces ten można zrealizować w następujących etapach:
- konfiguracja kolejek na switchu
- konfiguracja przepływów przez dany switch.
Rysunek 4. Przykładowa sieć z oznaczeniem typów portów: UNI i INNI
Instalacja kolejek
W celu instalacji kolejek na porcie switch-a należy utworzyć kolejkę, dodać ją do profilu QoS, zaś profil powiązać ze stosownym portem INNI.
W poniższym przykładzie zostały utworzone dwie kolejki ograniczające ruch do 10Mb/s i 50Mb/s, po czym powiązano je z portem TE1 switch-a (port INNI mający link do kolejnego switcha)
# ovs-vsctl create queue other-config:max-rate=10000000 c80b2a19-90e8-4eed-a1d4-5db061a6f864 # ovs-vsctl create queue other-config:max-rate=50000000 94965335-6dd5-4064-91f2-9b5c09f8e7ce # ovs-vsctl create qos type=linux-htb d56353d2-8b42-4074-a64f-2aeac0ff776e # ovs-vsctl set qos d56353d2-8b42-4074-a64f-2aeac0ff776e queues:1=c80b2a19-90e8-4eed-a1d4-5db061a6f864 # ovs-vsctl set qos d56353d2-8b42-4074-a64f-2aeac0ff776e queues:2=94965335-6dd5-4064-91f2-9b5c09f8e7ce # ovs-vsctl set port TE1 qos=d56353d2-8b42-4074-a64f-2aeac0ff776e
W wyniku konfiguracji został utworzony profil QoS z dwiema kolejkami (id 1 i 2). Do kształtowania ruchu została wykorzystana linux-owa implementacja algorytmu HTB (Hierarchical Token Bucket).
# ovs-vsctl list qos
_uuid : d56353d2-8b42-4074-a64f-2aeac0ff776e
external_ids : {}
other_config : {}
queues : {1=c80b2a19-90e8-4eed-a1d4-5db061a6f864, 2=94965335-6dd5-4064-91f2-9b5c09f8e7ce}
type : linux-htb
Instalacja przepływów
Po utworzeniu kolejek należy je skonfigurować do przyjmowania określonych pakietów. W tym celu protokół OpenFlow zdefiniował przepływy, tzw. flow-y, czyli krótkie porcje konfiguracji złożone z pól match i action. Pole match pozwala wykryć i zaklasyfikować pakiety o określonych parametrach, zaś pole action opisuje jakie działanie na pakiecie ma zostać podjęte.
W poniższym przykładzie przyjmijmy, że pakiety wchodzące portem TE2 będą kierowane do kolejki o id 1, zaś pakiety wchodzące portem TE3 zostaną skierowane do kolejki o id 2, a dalej na port wyjściowy TE1.
# ovs-ofctl add-flow ETH1 in_port=2,actions=set_queue:1,output=1 # ovs-ofctl add-flow ETH1 in_port=3,actions=set_queue:2,output=1
W wyniku tych działań do puli flow-ów urządzenia zostaną dodane reguły OpenFlow kształtujące ruch do zadanych przez kolejki poziomów zależnie od portu wejściowego, na którym pojawia się pakiet.
# ovs-ofctl dump-flows ETH1 cookie=0x0, duration=9.397s, table=0, n_packets=0, n_bytes=0, in_port=TE3 actions=set_queue:2,output:TE1 cookie=0x0, duration=2.841s, table=0, n_packets=0, n_bytes=0, in_port=TE2 actions=set_queue:1,output:TE1
Potencjał QoS w sieci SDN
Powyższe rozważania zamykają tematykę traffic policingu i traffic shapingu pokazując przy tym jak znaczącym i złożonym mechanizmem są techniki zapewnienia jakości w sieci. Mechanizmy QoS pozwalają w elastyczny sposób manipulować ruchem sieciowym oraz różnicować jego poziom i priorytet względem innych źródeł ruchu. W kontekście sieci SDN, QoS zyskuje dodatkową elastyczność względem tradycyjnych rozwiązań. W połączeniu z programowalną warstwą aplikacji umożliwiającą implementację i wdrożenie wielu funkcji sieciowych, możliwe jest zaaplikowanie dodatkowej funkcjonalności biznesowej. Przykładowo, w połączeniu z otwartym API możliwe jest dynamiczne zarządzanie poziomem QoS. Użytkownik końcowy za dodatkową opłatą może sam decydować o szybkości ruchu. Takie podejście do zarządzania usługami i ruchem sieciowym redukuje koszty oraz otwiera nowy model biznesowy, w którym funkcja sieciowa jest bliżej użytkownika niż kiedykolwiek wcześniej.
