Openflow – omówienie protokołu

Protokół Openflow jest jednym z najpopularniejszych protokołów SDN (Software Defined Networking). Umożliwia zdalne sterowanie warstwą danych switchy Openflow oraz zarządzanie mechanizmami QoS.  W pierwszej części artykułu w ramach wprowadzenia krótko przedstawię warstwowy model sieci oraz model referencyjny sieci SDN. Następnie przedstawię protokół Openflow wykorzystywany do komunikacji pomiędzy sterownikiem SDN a switchem OF (OpenFlow). Na koniec omówię budowę logiczną switcha Openflow.

Warstwowy model sieci

Warstwowy model sieci został przedstawiony na rysunku 1. Składa się 3 warstw:

• warstwy sterowania,
• warstwy zarządzania,
• warstwy danych.

W warstwie danych realizowane jest przetwarzanie pakietów i przekazywanie ich pomiędzy urządzeniami sieciowymi. Warstwa sterowania odpowiedzialna jest za wyznaczenie reguł przekazywania ruchu wykorzystywanych w warstwie danych. W warstwie zarządzania realizowane są funkcjonalności konfiguracji, wykrywanie i naprawa awarii, monitorowania stanu i obciążenia zasobów oraz kontrolowanie dostępu do elementów sieciowych. Warto zauważyć, że zarządzaniu podlegają komponenty realizujące zarówno funkcjonalności warstw danych i sterowania.

Model referencyjny sieci SDN

Model referencyjny sieci SDN został przedstawiony w rekomendacji ITU Y.3300 i wyróżnia 3 warstwy sieci SDN:

1. Warstwa Aplikacji SDN,
2. Warstwa Sterownika SDN,
3. Warstwa Zasobów Sieciowych.

Powyższe warstwy są zarządzane przez wielowarstwową funkcję zarządzania. Rysunek 2. obrazuje powyższe warstwy oraz ich główne funkcje.

Warstwa aplikacji SDN jest odpowiedzialna za realizację funkcjonalności biznesowych (np. realizacji usług sieciowych takich jak L2VPN czy L3VPN). Korzysta z interfejsu programistycznego udostępnianego przez sterownik SDN, za pośrednictwem którego aplikacje SDN mogą sterować ruchem w sieci oraz zarządzać zasobami urządzeń. Interfejs ten bazuje na abstrakcyjnym modelu sieci. Warstwa sterownika SDN realizuje funkcję orkiestracji siecią SDN. Odpowiada za zarządzanie zasobami urządzeń oraz zestawianiu połączeń transportowych na żądanie aplikacji SDN. Zapewnia niezależność aplikacji SDN oraz logiki sterownika SDN poprzez wprowadzenie abstrakcyjnego modelu sieci i mechanizmów sieciowych. Model ten jest przetwarzany na wiadomości odpowiednie dla danego typu urządzenia w momencie komunikacji z danym urządzeniem. Komunikacja pomiędzy sterownikiem a urządzeniem odbywa się poprzez interfejs sterownik SDN – zasoby sprzętowe. Interfejs ten pełni funkcje sterowania i zarządzania urządzeniem sieciowym i może być zrealizowany przez dowolną liczbę protokołów komunikacyjnych. Główną funkcjonalnością realizowaną w warstwie zasobów sieciowych jest przetwarzanie i przekazywanie pakietów zgodnie z regułami sterowania (ang. flow rules) instalowanymi przez sterownik SDN.

Podsumowując główną cechą technik SDN jest przeniesienie logiki sterującej ruchem do logicznie centralnego elementu sieci nazwanego sterownikiem SDN. Sterownik posiada informacje o konfiguracji i stanie wszystkich urządzeń SDN oraz znacznie więcej zasobów obliczeniowych w porównaniu z urządzeniem sieciowym dzięki czemu może podejmować lepsze decyzję routingowe. Dodatkowo dzięki uproszczeniu funkcjonalności switche SDN są potencjalnie tańszymi urządzeniami co zwiększa atrakcyjność biznesową sieci SDN.

Protokół Openflow

Główną funkcjonalnością protokołu Openflow jest umożliwienie sterowania switchem Openflow przez sterownik SDN. Realizuje funkcjonalność warstwy sterowania oraz część funkcjonalności warstwy zarządzania warstwowego modelu sieci. Idealnie wpisuje się w model referencyjny sieci SDN przedstawiony w rekomendacji ITU Y.3300^[1] realizując interfejs sterowania zasobami sieciowymi. Na rysunku 3. przedstawiono sieć zbudowaną ze switchy Openflow wraz z zarządzającymi nimi sterownikiem SDN.

Na urządzeniach umieszczony jest agent Openflow inicjujący połączenie ze sterownikiem. Konfiguracja sterownika SDN musi zostać wprowadzona niezależnym kanałem zarządzania. Jeden agent może utrzymywać kanały Openflow z wieloma sterownikami SDN. Każdy kanał ma nadaną jedną z 3 przewidzianych ról: Slave, Master lub Equal.  Rola Slave umożliwia jedynie odczyt dostępnych danych. Kanały o rolach Master i Equal uprawnione są do odczytu i modyfikacji reguł sterowania i konfiguracji mechanizmów sieciowych. Dozwolone są dwa typy konfiguracji ról Master-Slave oraz Equal-Equal. W pierwszym tylko jeden kanał i w efekcie jeden sterownik SDN może mieć przypisaną rolę Master. Jednocześnie wszystkie pozostałe kanały muszą mieć przypisaną rolę Slave. W drugim wszystkie kanały muszą mieć przypisaną rolę Equal. W celu zabezpieczenia kanałów Openflow wykorzystywany jest standard TLS (Transport Layer Security).

Możliwości protokołu Openflow

Protokół Openflow umożliwia:

• instalacje/usuwanie/modyfikacje reguł OF,
• instalacje/usuwanie/modyfikacje grup OF,
• pobieranie statystyk dotyczących reguł OF, tablic OF oraz portów Openflow,
• konfigurację mechanizmu meter realizującego funkcję policingu strumieni ruchu sieciowego,
• pobieranie podstawowych informacji o switchu Openflow.

Model działania protokołu Openflow pokrywa się z modelem referencyjnym sieci SDN przedstawionym w poprzednim rozdziale, a sam protokół Openflow realizuje interfejs sterownik SDN – zasoby sieciowe, ponieważ umożliwia logicznie centralne sterowanie siecią switchy OF.

Zasady sterowania switchem Openflow

Sterowanie switchem Openflow odbywa się poprzez instalację reguł OF o formacie przedstawionym na rysunku 4. Reguła składa się z definicji strumienia ruchu (Match Fields) określającej kryteria jakie musi spełniać ramka aby zostać przypisana do danej reguły. Definicja strumienia ruchu to lista wpisów o strukturze {nazwa pola/metadanej, maska, wartość}. Przykładami takich wpisów są:

• {IP_DST, 255.255.255.0, 45.3.233.0},
• {MAC_DST, FF:FF:FF:00:00:00, A2:A3:A4:00:00:00},
• {TCP_SRC, 0xCC00, 0}.

Priorytet określa pierwszeństwo przyporządkowania do reguły w przypadku, gdy dana ramka pasuje do definicji wielu reguł.

Liczniki przechowują informacje o liczbie bajtów, ramek danych oraz czasu życia reguły.

Instrukcje sterują ruchem poprzez kierowanie do kolejnych elementów struktury datapath (pojęcie datapath zostanie przybliżone w kolejnym rozdziale) oraz wykonywaniem akcji modyfikujących nagłówki pakietu. W tabeli 1 zostały zestawione instrukcje wraz z opisami w kolejności ich wykonania podczas przetwarzania reguły Openflow.

Pola timeouts zawierają liczniki określające kiedy reguła zostanie usunięta. Reguła może zostać usunięta po określonym czasie nieaktywności oraz po określonym czasie od jej instalacji. Może również zostać zainstalowana permanentnie.

Wartość pola cookie pełni funkcję identyfikatora reguły, który może zostać wykorzystany podczas modyfikacji, usuwania lub pobierania statystyk reguły.

Flagi określają sposób zarządzania regułami.

Proaktywne i reaktywne sterowanie

Protokół Openflow umożliwia dwa sposoby realizacji sterowania: proaktywny i reaktywny. Sterowanie proaktywne polega na instalacji reguł Openflow przed odebraniem ramek danych do nich pasujących. Pakiety nie pasujące do żadnej z zainstalowanych reguł sterowania zostają odrzucane. Takie podejście jest wykorzystywane w sieciach IP. Protokoły routingu pełniące funkcję warstwy sterowania routerów IP na podstawie wymienianych informacji o trasach ustalają tablicę RIB (Routing Information Base) zawierającą listę dostępnych podsieci oraz przypisanych im metryk i portów wyjściowych do danej podsieci. Następnie RIB mapowany jest na tablicę przełączania pakietów FIB (Forwarding Information Base), w której znajdują się najlepsze trasy do każdej z podsieci. Odebrane pakiety IP są przekazywane zgodnie z tablicą FIB a nie pasujące do żadnego z dostępnych wpisów pakiety są odrzucane. Sterowanie reaktywne polega na wyznaczaniu interfejsu wyjściowego dla pakietu w momencie jego odbioru. W Openflow sterowanie reaktywne zrealizowane jest poprzez wykorzystanie wiadomości packetIn i pakcetOut oraz instalacji reguły Openflow wysyłającej do sterownika SDN pakiety, które nie pasują do żadnej pozostałych z zainstalowanych reguł. Na rysunku 5 zobrazowano wymianę wiadomości towarzyszącą obsłudze pakietu w przypadku zastosowania sterowania reaktywnego. Gdy switch Openflow odbierze pakiet niepasujący do żadnej z zainstalowanych reguł do sterownika SDN zostaje wysłana wiadomość packetIn zawierająca całą ramkę Ethernet lub część tej ramki i identyfikator bufora, w którym cała ramka jest przechowywana. Sterownik po podjęciu decyzji o dalszym losie ramki odsyła do switcha wiadomość packetOut zawierającą otrzymaną ramkę lub identyfikator bufora oraz opcjonalnie instaluje regułę Openflow dla kolejnych pakietów z tego samego strumienia ruchu sieciowego. Przykładem reaktywnego sterowania w sieciach tradycyjnych jest protokół Ad-hoc On-demand Distance Vector (AODV) wykorzystywany w bezprzewodowych sieciach ad-hoc. W protokole Openflow można łączyć ze sobą oba sposoby sterowania realizując część funkcjonalności w sposób proaktywny i część w sposób reaktywny.

Openflow jest protokołem binarnym co pozytywnie przekłada się na szybkość przetwarzania wiadomości przez CPU. Ważną cechą protokołu Openflow jest rozszerzalność pozwalająca na . Zostanie ona opisana w kolejnym artykule na naszym blogu.

Switch Openflow

Switch Openflow składa się z agenta protokołu Openflow, Datapath’u oraz serwera protokołu zarządzania. Wysokopoziomowa budowa switcha sprzętowego została przedstawiona na rysunku 6. Agent odpowiada za obsługę kanałów Openflow oraz sterowanie datapathem zgodnie z żądaniami sterownika SDN. Agent jest daemonem uruchomionym na systemie operacyjnych switcha OF – NOS (Network Operating System). Datapath to zbiór komponentów odpowiedzialnych za przetwarzanie i przekazywanie pakietów. Składa się on z tablic reguł OF, tablicy grup OF, mechanizmów QoS oraz portów. Może być zrealizowany sprzętowo w przypadku switchy fizycznych oraz programowo w przypadku switchy wirtualnych (np. Open vSwitch). W przypadku switchy realizowanych sprzętowo koniecznym komponentem dla integracji systemu operacyjnego z sprzętowymi komponentami realizującymi datapath jest sterownik urządzenia. Standard OF nie narzuca zastosowania protokołu zarządzania, jednak jest to zwykle konieczne, ponieważ protokół Openflow umożliwia zarządzanie jedynie częścią zasobów switcha. Protokół zarządzania może zostać dowolnie wybrany przez producenta urządzenia.

Datapath switcha Openflow został zwizualizowany na rysunku 7. Liniami przerywanymi przedstawiono najważniejsze możliwe przejścia pakietu pomiędzy komponentami przetwarzającymi ruch. Pakiet z portu wejściowego kierowany jest na tablicę 0. Następnie, z regułą OF, do której pasuje, jest przekazywany do kolejnej tablicy reguł OF lub tablicy grup. Pakiet może przechodzić przez dowolną liczbę tablic jednak tylko w kierunku rosnących indeksów tablic tzn. dozwolone jest przejście z tablicy 0 do 12, lecz przejście z 12 do 3 nie jest dozwolone. W szczególności pakiet może być przetwarzany tylko w jednej tablicy reguł OF. Z każdej tablicy Openflow pakiet może zostać przekierowany na mechanizm meter realizujący funkcję policera. Na pakietach nieodrzuconych przez policer wykonywane są kolejne instrukcje zapisane w regule Openflow. Wraz z pakietem przekazywane są pomiędzy tablicami 3 rodzaje metadanych:

1. numer portu wejściowego,
2. 64b metadanych Openflow do wykorzystania przez użytkownika,
3. zbiór akcji wykonywany na końcu potoku przetwarzania pakietów.

Matching w Openflow

Numer portu wejściowego i metadane OF mogą zostać wykorzystane do przyporządkowania pakietu do odpowiedniej reguły OF (matching). Metadane OF mogą być zmieniane podczas przetwarzania w tabeli OF za pomocą odpowiedniej instrukcji, co daje możliwość przenoszenia dodatkowych informacji pomiędzy tablicami. Zbiór akcji może być uzupełniany podczas przejścia przez każdą z tablic. Służy do tego instrukcja WRITE_ACTIONS. Zbiór akcji może zawierać po jednej akcji danego typu i kolejne dodania tej samej akcji skutkują jej nadpisaniem tzn. jeśli w tablicy 0 wpisana zostanie akcja ustawiające pole label nagłówka MPLS na wartość 100, a następnie w tablicy 10 zostanie dodana taka sama akcja ustawiająca pole na wartość 200 to ostatecznie zostanie ustawiona wartość 200. Dodatkowo istnieje możliwość natychmiastowego wykonania akcji podczas przetwarzania w tablicy reguł OF za pomocą instrukcji APPLY_ACTIONS. Zarówno z tablicy reguł OF jak i na podstawie akcji zapisanych w zbiorze akcji pakiet może zostać przekierowany do tablicy grup. Grupy Openflow oraz ich wykorzystanie zostaną omówione w jednym z kolejnych artykułów.  Blok wyjściowych mechanizmów QoS również jest blokiem opcjonalnym na ścieżce pakietu. Do przekierowania pakietu na kolejkę QoS wykorzystywana jest akcja enqueue.

Pipeline w Openflow

Wyszczególnia się dwa typy switchy Openflow – OpenFlow-only i OpenFlow-hybrid. Różnią się one obecnością tradycyjnego potoku przetwarzania pakietów (pipeline), który jest dostępny tylko w switchach hybrydowych. Potok przetwarzania pakietów (pipeline) to ścieżka złożona z bloków przetwarzania pakietów przez jaki przechodzi pakiet w ramach urządzenia sieciowego. W przypadku switcha Openflow pipelinie składa się z listy tablic Openflow. Budowa pipeline’u nie zależy jedynie od budowy switcha ale również od zainstalowanych reguł sterowania, ponieważ w regułach Openflow zawarta jest informacja o przejściach do kolejnych tablic OF. W efekcie budowa pipeline’u jest zależna od aplikacji SDN sterującej ruchem w sieci oraz typu pakietu i jego źródła.

Tradycyjny potok może w zależności od realizacji obsługiwać funkcjonalność switcha Ethernet czy routingu IP. Wybór potoku dla danego pakietu w switchu hybrydowym może odbywać się w klasyfikatorze oraz zostać przekierowany z pipeline’u Openflow do potoku tradycyjnego za pomocą specjalnych, logicznych portów wyjściowych:

• portu NORMAL przekierowującego na wejście tradycyjnego potoku lub
• portu FLOOD rozgłaszającego ramkę zgodnie z tradycyjnym potokiem np. tylko na pozostałe porty należące do tego samego VLANu.

Największą bolączką standardu Openflow jest duża liczba opcjonalnych mechanizmów. W efekcie urządzenia zgodne ze specyfikacjami publikowanymi przez ONF często nie są w pełni kompatybilne ze sobą. Luźna definicja standardu implikuje konieczność dokładnej weryfikacji możliwości urządzenia przed użyciem w sieci Openflow. Jednak jest to sytuacja naturalna, ponieważ tak jak w sieciach konwencjonalnych tak i w SDN dane urządzenie jest dedykowane pod określone typy sieci (data center, enterprise, ISP) a każdy typ sieci ma inne wymagania.

Podsumowanie

Sieci SDN oparte o protokół Openflow stanowi solidną alternatywę dla tradycyjnych sieci pakietowych. Dzięki rozszerzalności protokołu o dowolne nagłówki producenci switchy Openflow mają możliwość projektowania urządzeń pod dowolne zastosowania. Protokół posiada wszystkie zalety i wady sterowania centralnego tj. umożliwia lepsze podejmowanie decyzji i upraszczanie urządzeń sieciowych, ale posiada logicznie centralny punkt awarii (sterownik SDN). Warto przy tym pokreślić, że sterownik SDN jest logicznie scentralizowanym komponentem, który może składać się z wielu instancji systemu działających w klastrze.

[1] ,,Framework of software-defined networking”, ITU Y.3300, 2014