Hybrydowe podejście

W większych środowiskach praktyczniejszym rozwiązaniem, ale pozwalającym nadal zachować dość szczegółowy poziom kontroli, jest podejście hybrydowe. Zakłada się w nim pośrednie rozwiązanie, w którym wykorzystuje się zarówno centralny punkt kontrolny, jak i lokalną płaszczyznę kontrolną w przełącznikach.

Lokalna, rozproszona płaszczyzna kontrolna odpowiada za wirtualizację sieci, mechanizmy odporności na błędy (failover) czy obsługę reguł przydzielania zasobów (provisioning) dla nowych przepływów. Jednakże niektóre przepływy poddawane dokładniejszej analizie centralny punkt i na jej podstawie rekonfigurowane. Rezultaty są następnie zwracane do przełączników i na ich podstawie wprowadzane są modyfikacje przepływów.

Innym rozwiązaniem pośrednim jest stosowanie zamiast jednego kontrolera SDN, większej ich liczby w zależności od wielkości sieci. W ten sposób kontrolery można umieścić bliżej urządzeń, które są przez nie zarządzane. To prowadzi do skrócenia opóźnień i pozwala na wydajniejsze sterowanie pracą przełączników przy jednoczesnym przeniesieniu większej liczby zadań do centralnej płaszczyzny kontrolnej.

Protokół OpenFlow

Dużym wyzwaniem pozostaje standaryzacja pomiędzy rozwiązaniami różnych producentów, co opóźnia popularyzację SDN. Przykładowo, brakuje jednego API stosowanego przez wszystkich dostawców. Ten kluczowy problem można rozwiązać, korzystając z nowych rozwiązań, jak OpenFlow. Trzeba jednak pamiętać, że ten projekt jest jeszcze we wczesnej fazie rozwoju i jego stosowanie w środowiskach produkcyjnych może budzić obawy o niezawodność działania. Z drugiej strony OpenFlow jest już implementowany przez producentów w komercyjnych przełącznikach, routerach czy punktach dostępowych Wi-Fi, co jest dobrym krokiem w kierunku standaryzacji.

W klasycznych routerach czy przełącznikach płaszczyzna danych (matryca przełączająca) oraz płaszczyzna kontrolna są realizowane w jednym urządzeniu. W przełączniku OpenFlow te dwie funkcje są odseparowane. Funkcja przełączania pakietów nadal jest realizowana w przełączniku, natomiast płaszczyzna kontrolna zostaje przeniesiona na zewnątrz do kontrolera SDN. Przełącznik i kontroler komunikują się między sobą, używając protokołu OpenFlow, który definiuje takie komunikaty, jak: packet-received, send-packet-out, modify-forwarding-table czy get-stats.

Przełącznik z obsługą OpenFlow przechowuje klasyczną tablicę przepływów zawierającą wpisy z parametrami przepływów oraz sposobem obsłużenia pakietów (wyślij przez port, odrzuć, prześlij do kontrolera), które cechują się danymi parametrami. Jeśli przełącznik otrzyma pakiet, który nie pasuje do żadnego wpisu w tablicy, prześle jego parametry do kontrolera SDN. Kontroler podejmie decyzję, jak obsłużyć taki pakiet i zwróci ją do przełącznika. Tablice przepływów w przełącznikach poszczególnych producentów różnią się od siebie, ale zespół pracujący nad OpenFlow wyodrębnił zestaw poleceń występujący w większości urządzeń. Działanie protokołu opiera się właśnie na tym zestawie polecenie. To z kolei pozwala programować i kontrolować z centralnego punktu tablicę przepływów w różnych przełącznikach i routerach. Ponieważ OpenFlow definiuje standardowy interfejs, pozwala uniknąć konieczności programowania każdego urządzenia z osobna.

Przełącznik zgodny ze specyfikacją OpenFlow musi obsługiwać trzy wspomniane wcześniej polecenia dotyczące przepływów. Dwa pierwsze – prześlij przez port (forward) oraz odrzuć – są oczywiste. Warto jedynie dodać, że pakiety mogą być odrzucane ze względu bezpieczeństwa, aby zapobiec atakom DoS lub aby ograniczyć fałszywe transmisje rozgłoszeniowe. Interesujące jest natomiast polecenie prześlij do kontrolera. Powoduje ono przesłanie pakietu do kontrolera poprzez bezpieczny kanał komunikacji. Typowo ma to miejsce w przypadku nowych pakietów i pozwala podjąć decyzję co do dalszych losów danego pakietu przez kontroler SDN. Jednakże w eksperymentalnym środowisku może posłużyć również do przesyłania wszystkich pakietów do kontrolera.

OpenFlow pozwala, m.in. na konfigurowanie ścieżek dla przesyłanych pakietów przez oprogramowanie działające w oddzielnej warstwie kontrolnej, z reguły chodzi o centralny punkt sterujący ruchem w sieci (kontroler SDN). Separacja płaszczyzny kontrolnej od płaszczyzny danych pozwala potencjalnie na bardziej zaawansowane podejmowanie decyzji odnośnie ruchu w sieci, niż listy kontroli dostępu (ACL) oraz protokoły routing. Ponadto umożliwia wirtualizację środowiska sieciowego. Te protokół pozwala także na łatwe wdrażanie nowych protokołów routingu i przełączania. Można go wykorzystać do realizacji takich rozwiązań, jak mobilność maszyn wirtualnych, wysokie bezpieczeństwo sieci czy budowanie sieci IP dla urządzeń mobilnych.

Alternatywne interfejsy oraz API

Sieć SDN można wdrożyć także, wykorzystujące powszechnie stosowane protokoły i interfejsy, jak CLI (Command Line Interface), SNMP, RADIUS, NETCONF, XML, XMPP, itd. Poniżej przedstawiamy omówienie poszczególnych protokołów i API stosowanych we wdrożeniach SDN, wskazując ich zalety oraz wady.

CLI (Command Line Interface) – każdy producent ma swoją własną implementację linii poleceń; mało tego, większość ma w swojej ofercie wiele różnych interfejsów CLI w wyniku przejęć i fuzji między firmami. Wprawdzie są na rynku narzędzia, który tworzą warstwę abstrakcji dla interfejsów CLI różnych producentów, ale są bardzo kosztowne i znajdują zastosowanie tylko w dużych sieciach dostawców usług.

SNMP (Simple Network Management Protocol) – w tym przypadku mamy do czynienia z podobnymi wyzwaniami co przy linii poleceń. W praktyce większość producentów stosuje SNMP tylko do monitorowania urządzeń sieciowych, a nie do konfigurowania i przydzielania zasobów.

RADIUS (Remote Authentification Dial in User Service) – jest częścią standardu regulującego metody kontroli dostępu do sieci (RFC 3580). Ten protokół może być wykorzystywany do dynamicznego wdrażania reguł w środowisku, w którym pracują urządzenia różnych producentów. Protokół znalazł już zastosowanie w wielu dużych heterogenicznych wdrożeniach.

NETCONF (Network Configuration Protocol) – ten protokół (RFC 6241) jest stosowany w rozwiązaniach do obsługi routerów. Mimo że można rozszerzać jego możliwości, nadaje się do dużych sieci operatorskich czy dla dostawców usług.

XMPP (Extensible Messaging and Presence Protocol) – to rozwiązanie zostało opracowane, aby umożliwić wymianę niemal w czasie rzeczywistym ustrukturyzowanych danych pomiędzy dwoma lub więcej urządzeniami sieciowymi. Stworzone z myślą głównie o zarządzaniu dostępnością, znajduje zastosowanie również w innych rozwiązaniach.

XML (Extensible Markup Language) – NETcoNf i XMPP, jak również SOAP (Simple Object Access Protocol), wykorzystują ten protokół do przenoszenia własnych komunikatów. SOAP jest prostym protokołem do wymiany informacji w zdecentralizowanym, rozproszonym środowisku. Ponieważ potrafi obsługiwać dane definiowane przez aplikacje, można wykorzystać tę właściwość w celu przesyłania do urządzeń poleceń czy nowych reguł.

IF-MAP (Interface for Metadata Access Point) – niezależna organizacja Trusted Computing Group opracowała otwartą architekturę i zestaw protokołów umożliwiających zachowanie wysokiego poziomu interoperacyjności urządzeń podłączonych do sieci, jak również ich bezpieczeństwa i integralności. Architektura ta jest określana mianem Trusted Network Connect (TNC). Spośród jej protokołów warty wspomnienia jestIF-MAP, tworzący bezpieczne, otwarte i elastyczne podstawy do komunikacji i wymiany danych pomiędzy aplikacjami, systemami operacyjnymi oraz urządzeniami.

OpenStack – celem inicjatywy jest stworzenie uniwersalnej, chmurowej platformy open source do tworzenia chmur publicznych i prywatnych. Korporacje, dostawcy usług, instytucje badawcze czy duże centra danych szukają rozwiązań do budowy dużych środowisk chmurowych i mogą być zainteresowane tym produktem.

Automatyzacja i wirtualizacja

Istotną wartością SDN w środowiskach korporacyjnych jest wirtualizacja sieci oraz automatyzacja procesów konfiguracyjnych. To pozwala na szybkie wdrażanie nowych usług, przy jednoczesnym zminimalizowaniu kosztów operacyjnych. Będące jeszcze w opracowaniu protokoły, jak OpenFlow, koncentrują się właśnie na tych aspektach. Jednak podobne rezultaty można osiągnąć, wykorzystując istniejące lub będące blisko standaryzacji protokoły, jak SPB (Shortest Path Bridging), VLAN, VRF/MPLS. W połączeniu z architekturą SDN pozwalają na dynamiczne przydzielanie zasobów sieciowych urządzeniom i aplikacjom pracującym na brzegu sieci.

Brak przejrzystości ruchu

SDN wykorzystuje tunele UDP (User Datagram Protocol), które są bardzo podobne do tuneli GRE (Generic Routing Encapsulation), z tą różnicą, że mogą być one dynamicznie włączane i wyłączane. Efektem stosowania tunelowania jest brak przejrzystości ruchu sieciowego, co pociąga za sobą istotne konsekwencje – poważne trudności przy diagnozowaniu problemów. Jako przykład weźmy użytkownika skarżącego się na bardzo wolny dostęp do bazy danych. W tradycyjnej sieci administrator sieci może szybko ustalić, co jest przyczyną, przykładowo że są to procesy tworzące w tym samym czasie kopie zapasowe. Rozwiązaniem jest przeniesienie tych zadań na inną godzinę.