Dezvoltarea Unui Controller Openflow

Declarație de onestitate academică

Prin prezenta declar că lucrarea cu titlul “Dezvoltarea unui controller OpenFlow”, prezentată în cadrul Facultății de Electronică, Telecomunicații și Tehnologia Informației a Universității “Politehnica” din București ca cerință parțială pentru obținerea titlului de Inginer în domeniul Electronică și Telecomunicații programul de studii Rețele și Software de Telecomunicații este scrisă de mine și nu a mai fost prezentată niciodată la o facultate sau instituție de învățământ superior din țară sau străinătate.

Declar că toate sursele utilizate, inclusiv cele de pe Internet, sunt indicate în lucrare, ca referințe bibliografice. Fragmentele de text din alte surse, reproduse exact, chiar și în traducere proprie din altă limbă, sunt scrise între ghilimele și fac referință la sursă. Reformularea în cuvinte proprii a textelor scrise de către alți autori face referință la sursă. Înțeleg că plagiatul constituie infracțiune și se sancționează conform legilor în vigoare.

Declar că toate rezultatele simulărilor, experimentelor și măsurătorilor pe care le prezint ca fiind făcute de mine, precum și metodele prin care au fost obținute, sunt reale și provin din respectivele simulări, experimente și măsurători. Înțeleg că falsificarea datelor și rezultatelor constituie fraudă și se sancționează conform regulamentelor în vigoare.

București,

Absolvent Mădălina-Elena VRÎNCEANU

_________________________

(semnătura în original)

Lista figurilor

Figura 1.1: SDN – Arhitectura de nivel 3

Lista tabelelor

Lista acronimelor

ACL – Access Control List

QoS – Quality of Service

BYOD – Bring Your Own Device

OSI – Open Systems Interconnection

IP – Internet Protocol

TCP – Transmission Control Protocol

UDP – User Datagram Protocol

LDAP – Lightweight Directory Access Protocol

SDN – Software Defined Networking

CPU – Central Processing Unit

RAM – Random Access Memory

FPGA – Field-Programable Gate Array

ASIC – Application-Specific Integrated Circuit

RIB – Router Information Base

FIB – Forwarding Information Base

Introducere

Odată cu dezvoltarea tehnologiei, managementul rețelelor a trebuit să facă față unor noi provocări în ceea ce privește politicile rețelelor (gestionarea drepturilor, ACL), securitatea (noi amenințări), dar și managementul traficului (QoS). În același timp, rețelele tind să devină tot mai dinamice, datorită conceptului de Cloud Computing ( reprezentând un ansamblu distribuit de servicii de calcul, aplicații, acces la informații și stocare de date, fără ca utilizatorul să aibă nevoie să cunoască amplasarea și configurația fizică a sistemelor care furnizează aceste servicii) sau politicilor BYOD necesare oricărui administrator de rețea.

Toruși, rețelele tind să rămână în urmă și folosesc tehnologii stratificate vechi cu interfețe specifice furnizorilor. De aceea, este complicat si predispusă la erori gestionarea rețelei. Bazat pe ideea unei gestionări centralizate, Software Defined Networking se adresează acestei probleme prin separarea planului de control de cel de date.

Principiul SDN este simplu: un nivel de control va satisface necesitățile curente ale rețelei, așa cum este specificat de administratorul acesteia, folosind tehnologii actuale și eficiente și va transmite reguli de bază prin intermediul nivelului de date, care poate fi, de exemplu, switch-uri simple cu o interfață standard, cum ar fi protocolul OpenFlow. Aceste protocol permite nivelului de control să specific reguli (de la nivelul 2 al stivei OSI la nivelul 4: Ethernet, IP, TCP/UDP, etc.) referitoare la modul în care switch-ul va trebui să se ocupe de pachete. Astfel, planul de control va putea fi capabil să utilizeze un nivel mai mare de resurse (baze de date sau LDAP) și va fi ușor de modificat, asigurând flexibilitatea și scalabilitatea, în timp ce performanțele sunt garantate de utilizarea de hardware dedicate pentru switch-uri.

Ca o consecință, SDN abordează așteptările actuale prin furnizarea unei rețele flexibile și programabile, care poate primi informații de la switch-uri, utilizatori, administratori sau de la dispozitive de securitate și le folosește cu scopul de a actualiza politica actuală în concordanță cu reguli definite, care acum pot folosi funcții sofisticate. În prezent, SDN și OpenFlow sunt tot mai răspândite, nu numai în lucrările de cercetare, dar și în industrie. Această idee este complementară celei legată de importanța tot mai mare a virtualizării. Având în vedere că totul este virtualizat, are sens încercarea de a virtualiza dispozitivele de rețea cu scopul de a ușura gestionarea acesteia.

Lucrarea de față își propune să studieze beneficiile pe care le aduce SDN, împreună cu protocolul OpenFlow, unei rețele și implementarea unui controller OpenFlow în limbajul de programare Java.

Capitolul 1

Software Defined Networking

Introducere

Software Defined Networking (SDN) se referă la un mod de organizare a funcționalităților rețelelor de calculatoare. SDN permite rețelei să fie virtualizată, furnizând un control mai mare și suport pentru ingineria traficului, iar administratorii de rețele pot gestiona serviciile acestora printr-o abstractizare a funcționalităților de bază. Acest lucru se realizează prin decuplarea sistemului care ia decizii cu privire la destinația traficului (planul de control) de sistemul care sta la baza dirijării traficului către o destinație selectată (planul de date). Inventatorii acestor sisteme pretind că acest mechanism simplifica rețelistica. SDN necesită niște mecanisme pentru ca planul de control să comunice cu planul de date. Un astfel de mecanism, OpenFlow, este deseori confundat cu SDN.

În continuare, se vor prezenta necesitățile care au condus la dezvoltarea SDN și avantajele pe care le aduce această tehnologie.

Scurt istoric

SDN își are originile cam în aceeași perioadă în care Sun Microsystems a lansat Java, în 1995. Unul dintre primele și cele mai importante proiecte SDN a fost GeoPlex aparținând AT&T. Membrii proiectului, Michah Lerner, George Vanecek, Nino Vidovic, Dado Vrsalovic au influențat API-ul rețelei și aspectele dinamice ale limbajului Java pentru a avea o modalitate de a implementa rețele middleware, mai exact, pentru a implementa nivelurile software intermediare pe care se sprijină comunicația dintre un client și un server. AT&T dorea un “soft switch” care să poată să reconfigureze switch-urile fizice din rețea și să încarce în ele servicii provenite de la OSS. Însă, GeoPlex nu putea să pătrundă atât de adânc în dispozitivele fizice pentru a realiza reconfigurarea și astfel, sistemul de operare ce rula pe dispozitivele de rețea a devenit o barieră pentru dezvoltarea SDN.

În 1998, Mark Medovich, om de știință la Sun Microsystems și Javasoft, părăsește Sun și ajunge la WebSprocket pentru a lansa un “soft switch”. El concepe un nou system de operare pentru rețele și o structură orientată pe obiecte, ce permitea modificarea acesteia. Platforma WebSprocket a fost concepută astfel încât dispozitivele puteau instanția stive, interfețe și protocoale, folosind mai multe fire de execuție. Abia în 2003, Bob Burke și Zac Carman au finalizat dezvoltarea SDN.

“Open Networking Foundation” a fost fondată în 2011 cu scopul de a promova SDN și OpenFlow.

În 2014 la Tech Field Day, SDN a fost demostrat de Avaya folosind „Shortesh Path Bridging” și OpenStack prin extinderea automatizării de la centrele de date către dispozitivele terminale, eliminând furnizarea manuală de servicii.

Limitări ale rețelei

Serverele care conectează rețelele din prezent au suferit o transformare dramatică în ultimul deceniu. Apariția virtualizării serverelor a schimbat radical rolul acestora. Serverele sunt acum dinamice și pot fi create și mutate ușor, cu o creștere a numărului acestora în ceea ce privește utilizarea rețelei. Înainte de apariția la scară largă a virtualizării serverelor, aplicațiile erau asociate cu un singur server ce avea un loc fix în rețea. Aceste aplicații foloseau rețeaua pentru schimbul de informații cu alte aplicații care, de asemenea, erau în locații fixe.

Acest lucru s-a schimbat. Aplicațiile pot fi acum distribuite pe multiple mașini virtuale. Administratorii de rețea pot muta mașinile virtuale pentru a optimiza și echilibra sarcinile serverelor. Faptul că mașinile virtuale sunt capabile să migreze presupune noi provocări pentru anumite aspecte ale așa numitei rețele tradiționale, cum ar fi schemele de adresare. Împreună cu virtualizarea serverelor, mai multe companii au început să folosească o singură rețea pentru a livra servicii de voce, date, video. În rețelele vechi din prezent, conceptul de QoS este folosit pentru a furniza nivel diferit de servicii pentru diverse aplicații. Personalul care se ocupă de rețea trebuie să configureze separat fiecare echipament al furnizorului și să ajusteze diverși parametri, cum ar fi lărgimea de bandă sau QoS per sesiune.

Importanța virtualizării

Principiul care stă la baza virtualizării este decuplarea unui serviciu de nivelul fizic la care acel serviciu operează. În zilele de azi, totul este virtualizat: nu numai serverele, dar și aplicațiile. Avantajele sunt evidente: replicare ușoară, ușurință în gestionarea și standardizarea resurselor. Totuși, rețelele încă rămân în urmă, dar încep să existe soluții (ex: switch-uri virtuale). Acestea sunt bazate pe ideea că echipamentele de rețea ar trebui să fie capabile să înțeleagă reguli simple standardizate și să urmeze anumite ordine. Așa cum virtualizarea serverelor reproduce CPU și RAM virtuale, așa și virtualizarea rețelelor reproduce switch-uri logice, routere (nivel 2 pana la nivel 4 în stiva OSI) sau chiar firewall-uri (de la nivelul 4 până la nivelul 7) . Astfel, ele pot rula pe echipamente ieftine, deja disponibile în centre de date sau, în cazul switch-urilor virtuale, direct pe hypervisor – ce monitorizează mașinile virtuale – alături de mașinile virtuale la care vor fi conectate.

Planul de control

La un nivel înalt, planul de control stabilește setul de date la nivel local folosit la crearea intrărilor în tabela de înaintare ce, ulterior sunt utilizate de planul de date pentru a trimite traficul între porturile de intrare și ieșire ale unui dispozitiv. Setul de date pe baza căruia se construiește topologia rețelei este numit “baza informațiilor de rutare” (RIB). RIB se actualizează constant, la fiecare schimbare de informație între instanțele planului de control din cadrul rețelei. Intrările tabelei de înaintare sunt numite, în mod uzual, “baza informațiilor de înaintare” (FIB). și uneori sunt reflectate între planul de control și cel de date ale unui anumit dispozitiv. FIB este programată odată ce RIB este considerată consecventă și stanbilă. Pentru a se realiza acest lucru, programul/entitatea control trebuie să dezvolte o vedere de ansamblu a topologiei rețelei care satisface anumite constrângeri. Această vedere poate fi programată manual, învățată prin observare sau construită pe baza informațiilor obținute din discursul cu alte instanțe ale planului de control, realizate prin utilizarea unuia sau mai multor protocoale de rutare, programării manuale sau printr-o combinare a celor două variante.

În Figura 2 este reprezentată partea mecanică a planelor de control și de date și constă într-o rețea de switch-uri interconectate. În partea de sus a figurii, este prezentată o rețea de switch-uri, cu accent pe detalii legate pe planele de control și de date ale celor doua switch-uri, notate cu A și B. Se observă că pachetele sunt primite de switch-ul A și ulterior trimise către switch-ul B. În cadrul fiecarei detalieri, se observă că planul de control și cel de date sunt separate, fiecare folosindu-se de propriul procesor. Pachetele sunt primite pe porturile de intrare unde se află planul de date. Dacă, de exemplu, se primește un pachet cu adresa MAC necunoscută, este redirecționat(4) către planul de control al dispozitivului, unde este invățat, procesat și, apoi dirijat mai departe. Același procedeu se aplică și în cazul mesajelor protocoalelor de rutare. Odată ce un pachet este livrat planului de control, informația conținută este procesată și, eventual, conduce la o modificare a RIB. Când RIB se stabilizează, FIB este actualizată atât în planul de control, cât și în planul de date. Totuși, în acest caz, deoarece pachetul primit a fost unul cu o adresa MAC necunoscută, planul de control returnează pachetul(C) planului de date(2), ce îl va dirija corespunzător (2).

Istoria Internetului este strâns legată de evoluția schemelor de control pentru gestionarea accesibilității informației, de protocoale pentru distribuția accesibilității informațiilor și de generarea de căi optimale ce trebuie să facă față diverselor provocări. În acest ultim caz, este inclusă o creștere tot mai mare a informației utilizate și modul de gestionare a acesteia.

Figura 1.1: Planul de date și cel de control într-o rețea

Planul de date

Planul de date gestionează datagramele ce sosesc (pe fir, fibră optică, mediu wireless) și face anumite verificări ale acestora. O datagramă corectă este procesată de planul de date prin realizarea unor căutări în tabela FIB, programate în prealabil de planul de control. Această operațiune este deseori numită “calea rapidă” (fast path) pentru procesarea pachetelor deoarece este nu necesară nicio altă interogare, în afară de cea pentru identificarea destinației pachetelor, utilizând tabela FIB preprogramată. Singura excepție este cazul în care pachetele nu se potrivesc cu nicio regulă predefinita, ca atunci când este detectată o destinație ncunoscută și pachetele sunt trimise la procesor, unde planul de control le poate procesa utilizând RIB.

Cele mai comune acțiuni care pot rezulta din interogarea FIB sunt: “forward” (și in anumite cazuri, ca multicast, replicarea), „drop”, „re-mark”, „count” și „queue”. Unele dintre acestea pot fi combinate. În anumite cazuri, forward-ul indică faptul că traficul este destinat unui proces în curs de execuție, cum ar fi OSPF sau BGP. Aceste datagrame trec prin ceea ce se numește “punt path” și sunt dirijate spre procesor folosind un canal intern de comunicație. Această cale este concepută pentru viteze relativ mici de trafic și nu este recomandată pentru nivele mari de trafic. În plus, planul de date poate să implemeteze și niște mici servicii/caracteristici (ACL și QoS). În anumite sisteme, aceste caracteristici folosesc propriile tabele, în timp ce altele realizează o extensie a tabelelor de dirijare. În plus, diferite tipuri pot implementa diverse caracteristici și o ordine a operațiilor de dirijare (Figura ).

Figura 1.2 : Generic example of ingress feature application on a traditional outer/switch

Separarea planului de control de planul de date

Bazat pe ideea că switch-urile sunt ușor controlabile, SDN introduce ideea de separare a planelor de date și de control, așa cum este arătat în Figura 1.1. Planul de control este sistemul care ia decizii cu privire la trimiterea traficului de date, pe când planul de date este sistemul care ia decizii cu privire la redirecționarea traficului.

Rolul planului de date este simplu: fiind dat un pachet, acesta trebuie să îl trimită către următorul nod, urmând niște reguli simple. Astfel, putem asigura performanțe folosind hardware specializate ca FPGA sau ASIC.

Planul de control poate doar să aibă grijă să transmită aceste reguli, rezultate din politicile complexe de nivel înalt. Astfel, planul de control poate folosi resurse de nivel înalt cum ar fi drepturi de management ale bazelor de date sau LDAP, și să folosească resurse existente prin lucrul pe servere standard sau mașini virtuale.

Figura 1.3: SDN – Arhitectura de nivel 3

Controller-ul poate adapta aceste reguli conform nevoilor dinamice, politicilor, evenimentelor ce pot să apară în rețea sau alertelor.

Timpul de convergență

Timpul de convergență este durata de timp care trece de când un element al unei rețele introduce o schimbare în atingerea nodului destinație, din cauza unui eveniment ce poate să apară în rețea, până când această schimbare este văzută de celelalte elemente ale rețelei. Una din componentele convergenței este timpul de propagare specific unei actualizări. În mod normal, este o funcție de distanța medie de la locul în care a intervenit schimbarea, măsurată în numărul de noduri ce trebuiesc anunțate de actualizare.

Pentru a optimiza procesarea convergenței la nivel de protocol, dar și mecanismul de propagare/inundare, fiecare protocol are un ceas intern diferit, folosit pentru a genera diverse tipuri de evenimente pentru protocolul respectiv. Un astfel de eveniment poate fi transmiterea de mesaje “Hello” către vecini. Pentru a îmbunătăți actializarea FIB, diverși vendori au dezvoltat strategii de organizare a tabelei pentru componentele cheie ale FIB (ex.: next hop al BGP). Aceste optimizări reduc numărul și tipul de schimbări care au loc în FIB ca răspuns la un eveniment ce are loc în rețea și, astfel se minimizează convergența. Aceste optimizări fac posibilă realizarea oriunde a unui număr mai mare 10000 de actualizări pe secundă în anumite tipuri de hardware.

Load Balancing

Load balancing este o tehnică ce se aplică în cazul căilor cu costuri egale sau în cazul rețelelor punct-la-punct, deși nu au costuri egale pe căi din diverse motive. Eficiența unui algoritm de load balancing este legată de două aspecte: de algoritmul de calcul în sine și de potențialele dezechilibre în dimensiunile fluxurilor. Astfel, pot rezulta probleme de eficiență care ar conduce la limitarea costului egal al căilor.

Avantaje

Rețele programabile

Cu SDN este mult mai simplu și fără predispunere la erori să se schimbe politicile rețelei având în vedere că trebuiesc schimbate doar politicile, nu și regulile multiple în diverse rețele de echipamente.

Mai mult, răspunsul la o modificare ce poare să apară în rețea (o noua conexiune, de exemplu) sau la un eveniment în rețea (un atac sau o suspiciune de intruziune) este mult mai simplu și eficient având în vedere că putem modifica întreaga rețea când apar schimbări. În plus, acest lucru poate fi făcut cât mai aproape de sursă pentru a evita o încărcare inutilă în rețea. Înainte de SDN, regulile trebuiau modificate manual, ceea ce conducea la erori sau timpi mari de răspuns.

Această capacitate de programare a rețelei este elementul cheie a SDN.

Flexibilitatea

SDN vine cu o îmbunătățire a flexibilității în managementul rețelei. Devine mult mai ușor să se reruteze traficul, să se analizeze fluxurile particulare, să se testeze noi politici sau să se descopere fluxuri neprevăzute. SDN este un instrument bun pentru testarea unor noi algoritmi de rutare sau a unui protocol și pentru a simplifica securitatea rețelei.

Figura 1.4: Ingineria traficului B4 a Google

După definirea unui grup de fluxuri care constau într-un grup de aplicații (pentru scalabilitate), descris de un tuplu (sursă, destinație, QoS), fluxurile sunt rutate conform cererilor de lărgime de bandă a grupului de fluxuri și a priorității acestora. Imaginea aparține B4: Experiența cu o rețeaWAN SDN dezvoltată global.

Politici unificate

Având propriul controller, SDN garantează o politică vastă și actuală la nivel de rețea: având în vedere faptul ca controllerul este cel care adaugă regulile în switch-uri, nu există riscul ca un operator de rețea să instaleze reguli greșite în rețea. Într-adevăr, operatorul doar va specifica regula nou adăugată, iar controllerul va adapta configurația și va trimite reguli coerente către fiecare dispozitiv specificat. În plus, dacă un dispozitiv este mutat, vechea regulă poate fi ștearsă, iar cele noi pot fi adăugate dinamic. Astfel, devine mult mai simplu să se dezvolte o politică unificată, dar și să se adauge o automatizare inteligentă în rețea.

Rutarea

SDN poate fi folosit pentru a gestiona informațiile legate de rutare într-un mod centralizat prin utilizarea unei interfețe a controllerului. Gestionarea rutării prin intermediul SDN poate avea ca scop gestionarea utilizării legaturilor și astfel, dezvoltând performanța prin creșterea utilizării medii a fiecărei legături, fără a exploata la maxim fiecare legătură, ceea ce ar fi neproductiv. Google, prin dezvoltarea B4 a putut să obțină o îmbunătățire a utilizării legăturilor de până la 3 ori mai bună decât în cazul tehnicilor standard prin analiza necesităților aplicațiilor și adaptarea rutării de pachete.

Cloud management

SDN permite un management mai ușor a platformei de cloud. Într-adevăr, într-un astfel de mediu, separarea planului de control, prin care clienții și sistemele interacționeaza prin intermendiul API, de planul de date este necesară, iar dinamicitatea adusă de SDN adduce probleme specific, cum ar fi: scalabilitatea, adaptarea, mutarea mașinilor virtual și izolare.

De exemplu, OpenStack Neutron (înainte Quantum) deja furnizează “networking as a service” și este plănuit să fie integrat cu un controller SDN, OpenDaylight – Neutron va folosi interfața OpenDaylight pentru a gestiona rețeaua – cu scopul de a funcționa într-un mediu SDN. Un alt proiect, FlowN furnizează un framework pentru a izola clienții cât timp le este furnizat fiecăruia accesul la programarea rețelei: fiecare client va putea rula controller-ul propriu – permițând utilizatorului să îl personalizeze dacă este necesar sau să îl folosească pe cel implicit, ceea ce va furniza o conectivitate totală – și își va putea gestiona propria rețea. Pentru a fi posibil acest lucru, FlowN interceptează fiecare cerere și o distribuie către controller-ul potrivit, bazat pe numărul portului de intrare din pachet.

Simplificare din punct de vedere hardware

SDN tinde să folosească tehnologii standard și de bază pentru a controla echipamentele de rețea, în timp de puterea de calcul este necesară doar pentru controller. Totuși, elementele de rețea folosite în prezent, switchurile și routerele, nu au nevoie să furnizeze prea multe caracteristici; ele trebuie doar să aplice comezile date de controller.

Având în vedere faptul că toate switch-urile au același scop, ele se vor distince din ce în ce mai puțin din punct de vedere hardware deoarece acestea vor oferi mai puține caracteristici (care vor ajunge în controller). Aceste echipamente de rețea vor deveni produse ieftine ce oferă interfețe standard. Astfel, devine mult mai simplu să se adauge noi dispositive, să se conecteze la rețea, iar controllerul să le gestioneze conform politicilor definite. Totuși, rețeaua va deveni scalabilă ușor atunci când și controller va fi scalabil.

Implementare hibridă

SDN este, în prezent, o tehnologie “matură”, folosită în rețele reale, având un mare succes și performanțe importante. Întrucât SDN presupune o implementare deplină a switch-urilor SDN, acesta nu poate fi implementat ușor în toate rețelele din întreprinderi – care încă pot avea switch-uri clasice și nu își pot schimba toate echipamentele odată – dar totuși este posibilă o dezvoltare tradițională pentru a profita de toate posibilitățile SDN.

Spre deosebire de tiparele clasice de implementare – rețeaua SDN este plasată alături de rețeaua deja existentă sau rețeaua poate fi separată în părți ce vor fi partajate între rețeaua de bază și noile rețele SDN – , Panopticon propune un mod de a implementa SDN în rețea prin “conviețuirea” a două tehnologii : va instala switch-uri SDN pe calea de date și chiar dacă un pachet nu va putea folosi doar switch-uri SDN, va fi cel puțin transmis de unul. Asemănarea constă în faptul că este dificil să se filtreze un pachet dupa sursa lui; nu putem aplica politici globale.

SDN și securitatea rețelelor

În această secțiune vor fi menționate efectele SDN asupra securității rețelelor, de asemenea și riscul folosirii unui controller într-o rețea centralizată, dar și folosirea unui protocol standard pentru gestionarea rețelei. Ulterior, vor fi prezentate și îmbunătățirile aduse de SDN, în comparație cu rețelele tradiționale.

1.7.1 Probleme inerente ale SDN

Așa cum a fost specificat în secțiunea 1.6, SDN rezolvă multe dintre probleme în ceea ce privește managementul rețelelor, dar adăugarea unei gestionări centralizate aduce cu sine noi probleme.

Se va presupune că controller-ul funcționează cu OpenFlow și are diverse acțiuni la pachetele necunoscute. Totuși, ramân valabile multe considerente dacă controller-ul configurează automat rețeaua și toate pachetele sunt potrivite proactive cu regulile de pe switch-uri.

1.7.1.1 O rețea mai puțin robustă

SDN, prin toate specificațiile sale, poate duce la diverse potențiale probleme. Într-adevăr, managementul este concentrat într-un singur punct, diversele nivele din care este compusă rețeaua sunt îmbinate într-un singur nivel mai mare, iar diversitatea protocoalelor scade.

Având în vedere faptul ca SDN adduce cu sine un management centralizat prin intermediul controller-ului, acesta este mai predispus la atacuri. Aceste atacuri nu numai că vor fi mai numeroase, dar și mult mai orientate. Mai mult, atacurile indirecte pot fi puse la punct daca stația utilizatorului este compromisă și are ca scop atacarea controller-ului sau prin adăugarea unor reguli în numele utilizatorului.

Un alt aspect crucial în ceea ce privește schimbările aduse de SDN este reducerea izolării dintre nivelele stivei OSI. Principul de bază al SDN este să centralizeze managementul pentru a-l face mai simplu și mai coherent, dar, istoric vorbind, securitatea rețelelor a fost îmbunătățită prin numărul de nivele întrucât arhitectura stratificată poate îmbunătăți robustețea prin limitarea interacțiunilor dintre nivele.

În plus față de aceste schimbări, a fost și o standardizare a protocoalelor. Astfel, cum OpenFlow devine un nou standard, un defect la un protocol sau într-o implementare poate fi dramatic deoarece ar afecta cele mai multe echipamente din rețea. Înainte aceste risc putea fi atenuat prin folosirea diverselor echipamente de la vendori, fiecare cu specificațiile sale, facând ca exploatarea simultană a diferitelor defecte în dispozitive să fie foarte dificilă. În plus, toate echipamentele de rețea trebuie să certifice că este absolut imposibil ca un utilizator să modifice direct regulile de pe echipament. OpenFlow rezolvă această problemă prin utilizarea canalului SSL/TLS dar, de exemplu, nu specifică faptul că certificatele trebuiesc verificate atât pe switch, cât și pe controller: controller-ul trebuie să asigure faptul că switch-ul nu e un echipament care ar putea pune în pericol rețeaua și chiar dacă comunicația dintre switch și controller ar fi complet izolată, switch-ul trebuie să asigure identitatea controller-ului.

1.7.1.2 Controller-ul: un punct de decizie critic

Având un management centralizat, orice care are acces la controller poate controla întreaga rețea, această vulnerabilitate având consecințe dramatice și trebuie evitată. Astfel, procesarea pachetelor, utilizarea interfeței “northbound”(interfața prin care un echipament de rețea comunică cu un alt echipament de nivel superior) și determinarea regulilor trebuiesc să fie complet sigure și robuste.

Verificarea datelor ce vin prin interfețele “southbound” (interfața prin care un echipament de rețea comunică cu un alt echipament de nivel inferior) este decisivă. Într-adevăr, informația raportată de aceste interfețe corespunde cu starea rețelei, statisticile și pachetele necunoscute. Acestea pot fi create – prin falsificarea unor pachete sau prin generarea de trafic – de un utilizator cu scopul de a exploata vulnerabilitățile prin analiza pachetului, dar și pentru a furniza controller-ului informații false sau să îl inunde cu informații inutile. În plus, controller-ul trebuie să fie atent la identificarea swith-urilor pentru a preveni ca un dispozitiv care ar pune în pericol rețeaua să fie considerat un switch în rețea.

De asemenea, interfața “northbound” trebuie săfie sigură și bine protejată. Putem considera două cazuri: doar câțiva administratori o pot accesa și pot adăuga noi reguli sau oricine să o poată accesa, să se autentifice și să adauge reguli noi, de exemplu să declare un flux nou pentru aplicația sa care va fi acceptat dacă el/ea are autorizație. Northbound API trebuie, de asemenea, să fie bine structurată și să verifice cu grijă modificările ce apar pe fluxuri pentru a garanta faptul că regulile de nivel înalt rămân consecvente.

În final, controller-ul are mai multă responsabilitate când gestionează regulile. Într-adevăr, trebuie doar să adauge reguli bine definite pe switch-uri deoarece devine responsabil de izolarea rețelei(ex: VLANuri) și de securitate. Trebuie să ne asigurăm că o regulă nu poate conduce la o posibilă exploatare, în special prin pachetele falsificate.

1.7.1.3 Controller-ul: un singur punct de eșec

Pe lângă toate aceste nevoi importante(multiple verificări efectuate asupra pachetelor, regulilor), riscuri și prin urmare, și o cerință mare de randament pentru un volum mare de lucru, controller-ul ramâne singurul punct de eșec. Într-adevăr, dacă pică sau începe să funcționeze necorespunzător, buna funcționare a rețelei va fi afectată direct. Astfel, este necesar să se folosească un siystem distribuit pentru a gestiona controller-ul.

Primele versiuni ale protocolului OpenFlow specificau numai un singur controller pentru switch-uri. Acum, versiunile mai recente permit specificarea mai multor controllere și rolul lor (Master, Slave), astfel simplificând managementul unui controller distribuit având în vedere că switch-ul poate trimite direct cererile către alt controller.

Totuși, volumul mare de lucru este necesar pentru reproducerea informației și asigurarea consistenței și performanțelor în acest sistem distribuit. Controller-ul va trebui să adreseze probleme comune în sisteme, cum ar fi partiționarea rețelei sau defectarea componentelor, iar în acest timp să asigure scalabilitate, consistență și disponibilitate.

Când pachetele necunoscute sunt trimise către controller pentru a le analiza și apoi adăugarea unor reguli pe switch, apare o întârziere pe durata transmiterii primului pachet datorită drumuluidus-întors către controller și timpul de procesarea necesar controller-ului. Presupunând că această întârziere este mică, nu se compară cu timpul necesar stabilirii unei sesiuni TCP, dar poate fi supărător pentru pachetele de tip UDP sau ICMP, cel puțin pentru primele pachete, până când switch-ul primește o regulă specifică fluxului. O soluție ar fi să se seteze proactive fluxurile pentru dispozitivele care necesită să gestioneze mai multe pachete fără nicio întârziere.

1.7.2 SDN pentru îmbunătățirea securității rețelei

Cu SDN este posibil să se dezvolte mai multe politici de rețea. Administratorul rețelei va define reguli simple și de baza și drepturi de utilizator. Utilizatorii se pot conecta la controller și pot cere autorizarea unul flux cât timp acestea au un scop definit de administrator. Astfel, putem îmbunătăți securitatea rețelei prin limitarea numărului de rute implicite și încă să rămână proactivă deoarece utilizatorul poate declara singur nevoile sale controller-ului, ceea ce va presupune o actualizare imediată, dacă este necesar. Utilizatorul nu trebuie să aștepte ca schimbările să fie procesate de echipementele relevante din rețea – deoarece controller-ul va înainta schimbările – în timp ce administratorii de rețea pot avea control asupra acestor reguli.

Ierarhizarea sistemului de reguli – care va fi transformat de controller în reguli de bază pentru echipamentele de rețea – poate fi folosit și pentru a șterge rapid permisiuni cu scopul de a acționa la un atac fără a pune în pericol servicii critice ce pot utiliza reguri cu prioritate mai mare.

Având în vedere că avem de-a face cu o rețea programabilă, mai multe oportunități ce înainte nu erau posibile sau foarte complicate, devin acum disponibile. Înainte, regulile trebuiau inserate în switch, iar verificările necesare făcute înainte. Acum, regulile sunt specificate într-un controller programabil, scalabil și cu o mai mare putere de calcul.

Când este utilizată o politica multinivel, gestionarea drepturilor poate fi simplificată foarte mult, prin utilizarea sistemelor criptografice. Pe lângă aspecte legate de autentificare – o autentificare puternică este recomandată, având în vedere importanța controller-ului – putem considera sisteme în care regulile vor fi semnate pentru a demostra faptul că sunt valide. Acest lucru ne asigură ca regulile nu au fost alterate și provin de la o sursă certificată.

Capitolul 2

OpenFlow

2.1 Introducere

Protocolul OpenFlow structutează comuncația dintre plnul de control și planul de date suportate de dispozitivele de rețea. OpenFlow a fost conceput ca să furnizeze o aplicație externă cu acces la planul de dirijare a switch-ului. Accesul la această parte a unui switch sau router poate fi dobândit, ceea ce permite ca programul de control să nu fie în același loc cu switch-ul de rețea.

Protocoalele de rețea tradiționale au avut tendința să fie definite izolate, fiecare rezolvând o anumită problemă specifică și fără a avea beneficiul unei abstractizări fundamentale. Rezultatul acestei izolări a fost crearea unei limitări primare a rețelelor de astăzi: complexitatea. Ca un exemplu al acestei complexități, pentru a muta un dispozitiv dintr-o locație a rețelei intr-o altă locație, specialiștii în rețele trebuie să atingă puncte ca switch-uri, routere, firewall, autentificare web, ș.a.m.d și să actualizeze listele de acces (ACL), VLAN-urile, QoS și alte mecanisme bazate pe protocoale folosind unelte de gestionare a rețelei care operează la nivelul dispozitivelor și legăturilor.

În plus, când aceste tipuri de schimbări sunt făcute, topologia rețelei, modelul de switch al vendorului și versiunea de software trebuiesc luate în considerare. Rezultatul final al complexității rețelei este acela că odată ce o rețea este construită, de multe ori ramâne așa cum este, fără ca nimic să se defecteze.

Protocolul OpenFlow a fost creat cu scopul de a rezolva problemele create de protocoalele de rețea vechi. În prima arhitectură SDN, OpenFlow este definit ca fiind prima interfață de comuncație între nivelul de control și cel de dirijare. OpenFlow permite accesul direct și manupularea planului de dirijare a dispozitivelor de rețea, cum ar fi switch-ui, routere, ambele fizice sau virtuale. În prezent, niciun alt protocol standard nu face ceea ce OpenFlow este capabil să facă și s-a determinat că un protocol ca OpenFlow este necesar să mute partea de control a rețelei în afara switch-urilor pentru a avea un control centralizat.

Când protocolul OpenFlow este implementat, acest lucru este făcut pe albele părți ale interfeței dintre infrastrucuta dispozitivelor de rețea și software-ul SDN de control. Pentru a identifica traficul în rețea, OpenFlow folosește conceptul de flux bazat pe reguli predefinite care pot fi statice sau dinamic programate de software-ul SDN.

OpenFlow permite specialiștilor în rețele să specifice cum traficul ar trebui să parcurgă dispozitivele din rețea, bazându-se pe anumiți parametri, cum ar fi: moduri de utilizare, aplicații sau resurse cloud. OpenFlow permite ca rețeaua să fie programată pe baza unui flux. Aceasta înseamnă că o arhitectură SDN bazată pe OpenFlow poate furniza un control profund, făcând ca SDN să răspundă în timp real la schimbările aplicației, utilizatorilor, sesiunilor. În rețelele de astăzi, rutarea bazată pe Internet Protocol (IP) nu asigură acest nivel de control deoarece toate fluxurile dintre două puncte terminale ale rețelei trebuie să parcurgă aceeași cale prin rețea, indiferent de cerințele lor diferite.

OpenFlow a fost creat pentru a da acces la SDN și, în prezent, este singurul protocol ce permite manipularea directă a planului de dirijare a dispozitivelor de rețea. Acest protocol a fost inițial aplicat rețelelor bazate pe Ethernet. Toltuși, comunarea OpenFlow se poate exinde la o scară mai largă de cazuri de utilizare. SDN bazat pe OpenFlow poate fi implementat în rețelele existente, fie fizice sau virtuale. Anumite dispozitive de rețea pot suporta simultan dirijarea bazată pe OpenFlow și cea tradițională. Acest lucru înseamnă că este ușor pentru întreprinderi să introducă progresiv tehnologia SDN.

2.2 Prezentare generală a switch-ului OpenFlow

ONF este organizația care gestionează standardul OpenFlow. Versiunea 1.1 a protocolului a fost lansată pe 28 februarie 2011. Următoarea versiune a standardului, 1.2, a fost publizată în februarie 2012, iar versiunea curentă este 1.4.

OpenFlow definit de ONF identifică necesitățile unui switch OpenFlow, așa cum apare în figura ____. Un switch OpenFlow este compus din trei mai componente: un canal OpenFlow, o tabelă de grup și una sau mai multe tabele de fluxuri. Tabela de fuxuri și tabela de grup sunt responsabile de căutările pachetelor și de dirijarea acestora. Canalul OpenFlow este utilizat la comunicarea cu un controller extern. Acest controller extern utilizează protocolul OpenFlow pentru a gestiona unul sau mai multe switch-uri.

Figura 2.1: Principalele componente ale Switch-ului OpenFlow

Folosind protocolul OpenFlow, controller-ul poate să adauge, să actualizeze și să șteargă fluxuri din tabela de fuxuri, reactiv sau proactiv. Fiecare tabelă de fluxuri de pe switch-uri conține un set de fluxuri de intrare, iar fiecare intrare în această tabelă este compusă din: câmpuri de potrivire, contori și un set de instrucțiuni ce trebuie aplicat pachetelor potrivite.

Potrivirea începe la prima tabelă de fluxuri și poate continua la alte tabele adiționale. Intrările de flux, adică instrucțiunile care specifică switch-ului ce trebuie să facă cu pachetele primite, corespund pachetelor în ordine prioritară, cu prima intrare potrivită uilizată. Dacă este găsită o intrare care să se potrivească, se execută intrucțiunile asociate cu intrarea de flux corespunzătoare. Dacă nu se găsește nicio potrivire în tabela de fluxuri, rezultatul depinde de configurarea intrării specifică lipsei de reguli: un pachet poate fi dirijat la controller prin canalul OpenFlow, poate fi aruncat sau poate continua cu următoarea tabelă de fluxuri.

Instrucțiunile asociate fiecărei intrări de flux fie conțin acțiuni, fie modifică procesarea pipeline. Acțiunile incluse în instrucțiuni descriu dirijarea pachetelor, modificarea acestora și procesarea tabelei de grup. Instrucțiunile procesate prin pipeline permit pachetelor să fie trimise unor tabele ulterioare pentru a le procesa mai departe și permit informației, sub formă de metadata, să comunice între tabele. Procesarea pipeline se oprește atunci când setul de instrucțiuni asociate unei intrări de flux nu specifică o următoare tabelă. În acest punct, pachetul este, de obicei, modificat și înaintat.

Intrările de flux pot dirija spre un port. Acesta este, de obicei, un port fizic, dar poate fi și un port logic, definit de switch sau un port rezervat, definit de specificațiile sale. Porturile rezervate pot specifica acțiuni generale de dirijare, cum ar fi trimiterea la controller, inundarea sau dirijarea folosind metode nonOpenFlow, cum ar fi procesarea ”normală” pe switch, în timp ce porturile logice pot specifica grupuri de legături agregate, tunele sau interfețe de loopback.

Acțiunile asociate cu intrările de flux pot, de asemenea, direcționa pachete către un grup, ceea ce presupune o procesare adițională. Grupurile reprezintă seturi de instrucțiuni pentru inundare, precum și o semantică a dirijării mai complexă. Grupurile permit și ca multiple intrări de flux să dirijeze spre un singur identificator (ex. Dirijarea IP către un next hop comun). Această abstracție permite ca acțiunile comune rezultate aplicate intrărilor de flux să fie schimbate eficient. Tabela de grup conține intrări de grup; fiecare intrare de grup conține o listă de seturi de acțiuni (action bucket) cu semantică specifică dependentă de tipul grupului. Acțiunile din unul sau mai multe seturi de acțiuni sunt aplicate pachetelor trimise către grup.

2.3 Porturile OpenFlow

Porturile sunt o componentă critică a protocolului OpenFlow, deoarce ele specifică de unde provine un pachet și unde va merge. Conectarea a două switch-uri OpenFlow se face prin intermediul porturilor.

Porturile OpenFlow sunt interfețele de rețea pentru trecerea pachetelor între procesarea OpenFlow și restul rețelei. Setul de porturi OpenFlow poate să nu fie identic cu setul de interfețe furnizate de switch-ul hardware, unele interfețe pot fi invalide pentru OpenFlow, iar switch-ul PenFlow poate defini porturi OpenFlow adiționale.

Pachetele OpenFlow sunt primite pe un port de intrare de pipeline-ul OpenFlow care le poate dirija către un port de ieșire. Portul de intrare al pachetelor OpenFlow este o proprietate a pachetelor pe care o au pe parcursul parcurgerii pipeline-ului și reprezintă portul pe care pachetele au fost primite de switch. Portul de intrare poate fi utilizat la realizarea corespondenței pachetelor. Pipeline OpenFlow poate decide să trimitp pachetul spre un port de ieșire folosind o acțiune ce definește modul în care pachetul ajunge înapoi în rețea.

Un switch OpenFlow trebuie să suporte trei tipuri de porturi: porturi fizice, porturi logice și porturi rezervate.

Porturile standard OpenFlow sunt definite ca fiind porturi fizice, logice și poturi locale rezervate, dacă sunt suportate, excluzând alte porturi rezervate. Porturile standard pot fi folosite ca porturi de intrare sau de ieșire, pot fi folosite în grupuri și au contori.

2.3.1 Porturile fizice

Porturile fizice OpenFlow sunt porturi care corespund în mod direct unei interfețe hardware a switch-ului. De exemplu, pe un switch Ethernet, porturile fizice se mapeaza unul-la-unu cu interfețele Ethernet.

În anumite implementări, switch-ul OpenFlow poate fi virtualizat peste switch-ul hardware. În aceste cazuri, un port fizic poate reprezenta o parte virtuală a interfeței hardware corespunzătoare a switch-ului.

2.3.2 Porturile logice

Porturile logice OpenFlow sunt porturi care nu corespund în mod direct unei interfețe hardware a unui switch. Porturile logice reprezintă un nivel înalt de abstractizare și pot fi definite în switch folosind metode nonOpenFlow, cum ar fi: tuneluri, interfețe de loopback, grupuri de link-uri agregate.

Porturile logice pot include încapsularea pachetelor sau pot mapa diferite porturi fizice. Procesarea facută de porturile logice trebuie să fie transparentă procesării OpenFlow, iar aceste porturi trebuie să interacționeze cu procesarea OpenFlow ca și cum ar fi porturi fizice.

Singura diferență dintre porturile logice și cele fizice este aceea că un pachet asociat unui port logic poate avea un câmp în plus, numit Tunnel-ID, asociat acestuia, iar când un pachet primit pe un port logic este trimis către controller, ambele porturi, cel logic și cel fizic de bază sunt raportate controllerului.

2.3.3 Porturile rezervate

Porturile rezervate specifică acțiuni de dirijare cum ar fi trimiterea pachetelor către controller, inundarea sau dirijarea folosind metode nonOpenFlow. Un switch nu trebuie să suporte toate tipurile de porturi rezervate, doar cele marcare cu “Obligatoriu” mai jos:

Obligatoriu: ALL: reprezintă toate porturile pe care un switch le poate folosi pentru a dirija un pachet specific. Acesta poate fi folosit doar ca port de ieșire, iar în acest caz, o copie a pachetelor e trimisă către porturile standard, în afară de cele de intrare și cele configurate ca atare.

Obligatoriu: CONTROLLER: reprezintă canalul de control către controllerul OpenFlow. Poate fi folosit și ca port de intrare și ca port de ieșire. Când este utilizat ca port de ieșire, încapsulează pachetul într-un mesaj ”packet-in” și îl trimite folosind protocolul OpenFlow. Când este folosit ca port de ieșire, acesta identifică un pachet provenit de la controller.

Obligatoriu: TABLE: reprezintă începutul pipeline OpenFlow. Acest port este valid numai într-o acțiune de ieșire într-o listă de acces a unui mesaj de tipul ”packet-out” și prezintă pachetul primei tabele de fluxuri pentru ca acesta să poată fi procesat prin pipeline.

Obligatoriu: IN_PORT: reprezintă portul de intrare al pachetului. Poate fi folosit doar ca port de ieșire, trimițănd pachetul prin portul său de intrare.

Obligatoriu: ANY: reprezintă o valoare specială folosită în anumite comenzi când nu este specificat clar un port. Nu poate fi folosit nici ca port de intrare, nici ca port de ieșire.

Opțional: LOCAL: reprenzintă stiva locală de rețea a switch-ului și stiva de management. Poate fi folosit fie ca port de intrare, fie ca port de ieșire. Portul local pemrite entităților distante să interacționeze cu switch-ul și serviciile sale de rețea prin rețeaua OpenFlow. Cu un set corespunzător de intrări de fluxuri, poate fi folosit pentru implementarea unei conexiuni in-band.

Opțional: NORMAL: reprezintă rețeaua pipeline nonOpenFlow tradițională a switch-ului. Poate fi folosit ca port de ieșire și procesează pachetul folosind pipeline normal. Dacă switch-ul nu poate dirija pachete de la pipeline-ul OpenFlow, trebuie indicat că nu poate suporta această acțiune.

Opțional: FLOOD: reprezintă inundarea folosind pipeline normal al switch-ului. Poate fi folosit doar ca port de ieșire și, în general, trimite pachetul către toate porturile standard, dar nu și către porturile de intrare. Switch-ul poate folosi și VLAN ID al pachetului pentru a selecta ce porturi să inunde.

Switch-urile care suportă numai OpenFlow nu suportă porturile NORMAL și FLOOD, în timp ce cele hibride le pot suporta. Dirijarea pachetelor către portul FLOOD depinde de implementarea și configurarea switch-ului.

2.4 Tabelele OpenFlow

Această secțiune descrie componentele tabelelor de fluxuri și tabelelor de grup, împreună cu mecanismul de potrivire și gestionare a acțiunilor.

Pachetele sunt comparate cu multiple tabele din pipeline

Procesarea pachetului pe tabelă

Găsirea intrării de flux ce se potrivește și are cea mai mare prioritate.

Aplicarea instrucțiunilor:

Modificarea pachetelor și actualizarea câmpurilor potrivite

Actualizarea setului de acțiuni

Actualizarea metadata

Trimiterea datelor și setului de acțiuni următoarei tabele.

Figura 2.2: Fluxul de pachete prin procesarea pipeline

2.4.1 Procesarea pipeline

Switch-urile OpenFlow sunt de doua tipuri: ”OpenFlow-only” și ”OpenFlow-hybrid”. Switch-urile OpenFlow-only suportă doar operațiuni OpenFlow; în aceste switch-uri toate pachetele sunt procesate de pipeline OpenFlow și nu pot fi procesate altfel.

Switch-urile OpenFlow-hybrid suportă ambele moduri de operare: OpenFlow și comutare Ethernet clasică (procesarea comutării Ethernet la L2, rutării L3, ACL și QoS). Aceste switch-uri trebuie să furnizeze un mecanism de clasificare în afară de OpenFlow care să ruteze traficul fie către pipeline OpenfFlow, fie către pipeline normal. De exemplu, un switch poate folosi eticheta VLAN sau portul de intrare a pachetului pentru a decide ce pipeline să îl proceseze sau direcționeze toate pachetele către pipeline OpenFlow. Un switch OpenFlow-hybrid poate permite unui pachet să treacă de la pipeline OpenFlow la pipeline normal prin porturile rezervate NORMAL și FLOOD.

Pipeline-ul OpenFlow al fiecărui switch OpenFlow conține multiple tabele de fluxuri, fiecare dintre acestea conținând multiple intrări de flux. Procesarea pipeline de tip OpenFlow definește cum pachetele interacționează cu aceste tabele de fluxuri. Un switch OpenFlow trebuie să aibă cel puțin o tabelă de fluxuri și opțional mai multe. Un switch OpenFlow cu o singură tabelă de fluxuri este valid, în acest caz procesarea pipeline fiind foarte mult simplificată.

Tabelele de fluxuri ale unui switch OpenFlow sunt numerotate secvențial, începând cu 0. Procesarea pipeline începe întotdeauna la prima tabelă de fluxuri: pachetul este, la început, potrivit cu intrările de fluxuri ale tabelei de fluxuri 0. Pot fi folosite și alte tabele de fluxuri, acest lucru depinzând de rezultatul potrivirii în prima tabelă.

Pachetul, când este procesat de o tabela de fluxuri, este potrivit cu intrările de fluxuri ale tabelei de fluxuri pentru a selecta o intrare. Dacă este găsită o intrare, setul de instrucțiuni inclus în acea intrare de flux este executat. Aceste instrucțiuni pot direcționa pachetul direct către o altă tabelă, unde același proces este repetat. O intrare de flux poate direcționa pachetul numai către o tabelă cu un număr mai mare decât al său; cu alte cuvinte, procesarea pipeline poate doar să meargă într-un singur sens. Evident, intrările ultimei tabele nu pot include instrucțiuni care să direcționeze pachetele către o altă tabelă. Dacă potrivirea intrărilor de flux nu direcționează direct către o altă tabelă de fluxuri, procesarea pipeline se oprește la tabela respectivă. Când acest proces se oprește, pachetul este procesat cu setul de acțiuni asociat și, de obicei, este dirijat.

În cazul în care un pachet nu se potrivește niciunei intrări de flux într-o tabelă de fluxuri, numim acest lucru lipsă de tabelă (table miss). Comportamentul în cazul unei lipse de tabelă depinde de configurația tabelei. O intrare de flux într-o tabelă lipsă în tabela de fluxuri poate spefica cum trebuiesc procesate pachetele nepotrivite: aruncarea lor, înaintarea lor spre o altă tabelă sau trimiterea lor către controller prin canalul de control prin mesaje de tip packet-in.

2.4.2 Tabela de fluxuri

O tabelă de fluxuri este compusă din intrări de fluxuri.

Tabelul 2.1: Principalele componente ale unei intrări de flux într-o tabelă de fluxuri

Fiecare intrare în tabela de fluxuri conține:

Match fields: pentru potrivirea pachetelor. Acestea conțin portul de intrate și antetul pachetelor și, opțional, metadata specificată de o tabelă anterioară.

Priority: pentru potrivirea prioritară a intrărilor de fluxuri.

Counters: actualizate când pachetele sunt potrivite.

Instructions: pentru a modifica setul de acțiuni sau procesarea pipeline.

Timeouts: timpul maxim sau timpul de inactivitate până fluxul expiră.

Cookie: valori de date opace alese de controller. Pot fi folosite de controller pentru a filtra statistici pe fluxuri, modificarea fluxurilor și ștergerea lor. Nu sunt folosite când sunt procesate pachete.

Este posibil ca mai multe intrări în tabela de fluxuri să se potrivească aceluiași pachet în același timp. Daca acest lucru se întâmplă, atunci prioritatea fluxului este folosită pentru a determina ce potrivire va fi folosită pentru a furniza setul de intrucțiuni ce va fi executat asupra pachetului. Figura ___ arată pașii pe care un switch OpenFlow îi parcurge când primește un pachet.

Dacă există, când o intrare de flux dintr-o tabelă lipsă se potrivește unui pachet, toate câmpurile sunt omise din comparație și intrarea din tabela lipsă are prioritatea 0, cea mai mică.

2.4.3 Procesul de potrivire

La primirea unui pachet, un switch OpenFlow realizează funcțiile descrise în figura de mai jos. Switch-ul începe să efectueze o căutare de tabelă în prima tabelă de fluxuri și, bazat pe procesarea pipeline, poate efectua căutări și în alte tabele.

Figura 2.3: Procesul de potrivire a pachetelor OpenFlow

Câmpurile din pachet care trebuie să se potrivească sunt extrase din pachet. Aceste câmpuri folosite pentru căutarea tabelelor depind de tipul pachetului și, de obicei, includ diverse câmpuri din antetul pachetului, cum ar fi adresa sursă sau destinația Ipv4. În plus față de antetul pachetelor, potrivirile se pot face și după portul de intrare sau câmpurile de metadate. Metadatele pot fi folosite pentru a pasa informația între tabelele unui switch. Câmpurile potrivite ale unui switch reprezintă starea curentă a switch-ului, iar dacă acțiunile aplicate într-o tabelă anterioară, folosind instrucțiunea ”Apply-Actions” au schimbat antetul pachetului, aceste schimbări se reflectă și asupra câmpurilor ce trebuiesc potrivite.

Un pachet se potrivește unei intrări într-o tabelă de fluxuri dacă valorile câmpurilor potrivite din pachet folosite pentru efectuarea căutărilor se potrivesc cu cele definite de intrările în tabela de fluxuri. Dacă un câmp dintr-o intrare în tabela de fluxuri are valoarea ANY, se potrivește tuturor valorilor posibile din antet. Dacă switch-ul suportă mască de biți arbitrară în anumite câmpuri potrivite, aceste măști pot defini mai precis potrivirea.

Pachetul este potrivit conform tabelei și numai fluxul cu cea mai mare prioritatea care se potrivește pachetului trebuie selectat. Contorii asociați cu fluxul selectat trebuiesc actualizați și setul de instrucțiuni inclus în fluxul respectiv trebuie aplicat. Dacă este cazul mai multor potriviri cu aceeași prioritate maximă, intrarea de flux selectată este nedefinită explicit.

2.4.4 Table-miss

O potrivire între un pachet primit și o intrare în tabela de fluxuri va avea loc numai dacă intrarea în tabelă conține valori care se găsesc și în antetul pachetelor. Dacă niciuna dintre intrările în tabelă nu conține valori care să se regăsească în pachetul primit, se va genera un eveniment de tupul ”table-miss”.

Protocolul OpenFlow afirmă că fiecare tabelă de fluxuri trebuie să aibă o intrare de tipul ”table miss”. Totuși, această intrare nu există în mod implicit. Acest lucru înseamnă că responsabil pentru crearea acestei intrări în tabelă este controllerul extern. Această intrare se va potrivi fiecărui pachet și va avea prioritatea 0. Când potrivirea cu intrarea ”table-miss” este singura potrivire făcută, instrucțiunile specifice acestei intrări vor fi cele aplicate pachetului. Acțiunile specifice ”table-miss” pot includ aruncarea pachetului, trimiterea lui către controller sau dirijarea lui către o altă tabelă. Sunt două acțiuni pe care fiecare intrare de tipul ”table-miss” trebuie să le suporte: trimiterea pachetului către controller folosind portul rezervat CONTROLLER și aruncarea pachetului.

2.4.5 Ștergerea fluxului

SDN este dinamic, iar legăturile pot fi up sau down tot timpul. Acest lucru înseamnă că tabela de fluxuri ale unui switch OpenFlow trebuie să fie actualizată constant de către controller-ul extern. Una dintre acțiunile pe care controller-ul le ia este ștergerea unui flux care poate avea loc atunci când acest lucru este cerut de către controller – mecanismul de expirare al fluxurilor poate cauza ștergerea acestuia -, sau printr-un mecanism opțional de ștergere a fluxurilor.

Mecanismul de expirare a intrărilor în tabela de fluxuri funcționează în două moduri diferite, depinzând de configurația switch-ului. Un contor hard_timeout diferit de zero poate fi asociat cu un flux care, după expirarea contorului, va fi șters. Alternativ, un al doilea contor idle_timeout poate fi asociat unui flux. Dacă acest contor are valoarea în secunde diferită de zero atunci, dacă fluxul nu se potrivește niciunui pachet care a fost primit de switch până contorul să ajungă la zero, fluxul va fi șters.

Fluxurile pot fi șterse și de controller-ul extern. Controller-ul realizează ștergerea prin trimiterea unui mesaj swith-ului prin care îi cere să șteargă fluxul. Când un flux este șters, fie de către controller, fie de către mecanismul de expirare al fluxurilor, switch-ul trebuie să verifice un flag care, dacă este setat, acesta trebuie să trimită un mesaj controller-ului prin care să specifice faptul că fluxul a fost șters.

2.4.6 Tabela de grup

O tabelă de grup constă din intrări de grup. Abilitatea unei intrări de flux de a indica către un grup permite OpenFlow să reprezinte metode adiționale de dirijare.

Tabelul 2.2 : Principalele componente ale unei intrări în tabela de grup

Fiecare intrare de grup este identificată prin identificatorul de grup propriu și conține:

un identificator de grup (un număr de 32 de biți ce identifică în mod unic grupul)

tipul grupului (pentru a determina semantica grupului)

contori (actualizați când pachetele sunt procesate de un grup)

acțiuni.

2.4.7 Tabela de metrici

O tabelă de metrici constă din intrări de metrici, definind metrici per flow. Aceste metrici permit OpenFlow să implementeze diverse operații QoS simple și pot fi combinate cu cozile pe porturi pentru a implementa framework-uri QoS mai complexe, cum ar fi DiffServ.

O metrică măsoară rata de pachete și permite controlul ratei pachetelor respective. Metricile sunt atașate direct intrărilor de fluxuri (diferit față de cozi care sunt atașate porturilor). Orice intrare de flux poate specifica o metrică în setul său de instrucțiuni. Multiple metrici pot fi folosite în aceeași tabelă, dar într-un mod exclusiv (seturi disjuncte de intrări de flux) și în același set de pachete prin utilizarea lor în tabele de flux succesive.

Tabel 2.3 : Principalele componente ale unei intrări de metrici în tabela de metrici

Fiecare intrare de metrică este definită de identificatorul de metrică propriu și conține: un identificator de metrică (un număr de 32 de biți care identțifică în mod unic metrica), banda metricii (o listă neordonată de benzi de metrici, unde fiecare bandă de metrică specifică rata de bandă și modul de procesare al pachetelor), contori(actualizați când pachetele sunt procesate de metrică).

2.4.8 Intstrucțiuni

Pentru ca un pachet in SDN să ajungă de la sursă la destinație, trebuie să aibă antetul modificat de switch-urile OpenFlow pe care le parcurge. Modul prin care un switch OpenFlow determină modul în care modifică un pachet este bazat pe instrucțiunile pe care le execută asupra pachetului. Colecția de instrucțiuni care se execută va fi bazată pe potrivirea câmpului din antetul pachetului cu ininstrucțiunile care sunt conținute în tabela de intrare de fluxuri.

Dacă, dintr-un oarecare motiv un switch OpenFlow nu reușește să execute înstrucțiunile asociate cu o intrare de flux, switch-ul rebuie să respingă intrarea de flux. Dacă acest lucru se intâmplă, switch-ul trebuie să returneze un mesaj de eroare de tipul flux nesuportat. Este posibil ca tabelele de fluxuri de pe switch-urile OpenFlow să nu sporte fiecare instrucțiune, acțiune sau potrivire.

2.4.9 Contorii

Controrii sunt menținuți pentru fiecare tabelă de fluxuri, intrare de flux, port, coadă, grup, metrică. Aceștia pot fi implementați software și menținuți prin ”votul” contorilor hardware cu intervale mai limitate. Tabelul 2.4 conține setul de contori definiți de specificațiie OpenFlow. Un switch nu trebuie să suporte toți contorii, doar cei marcați cu ”Required”. ”Duration” se referă la cât timp intrarea de flux, portul, grupul, coada sau metrica au fost instalate pe switch și trebuie definit cu precizie de secundă. Câmpul ”Received Errors” este totalul tuturor coliziunilor primite definite în tabel și nu numai.

Contorii sunt fără semn, iar dacă valoarea numerică a unui contor nu este disponibilă pe switch, valoarea acestuia trebuie setată la valoarea maximă a câmpului (echivalentul fără semn al lui -1).

Tabel 2.4: Lista de contori

2.4.10 Setul de acțiuni. Lista de acțiuni. Acțiuni

Fiecărui pachet îi este asociat un set de acțiuni care, implicit, este vid. O intrare de flux poate modifica setul de acțiuni folosind instrucțiuni(ex.: Write-Action, Clear-Action) asociate cu o anumită potrivire. Setul de acțiuni este purtat între tabelele de fluxuri. Când setul de instrucțiuni nu conține instrucțiunea Goto-Table, procesarea pipeline se oprește și sunt executate acțiunile din set. Un set de acțiuni conține cel mult o acțiune din fiecare tip. Acțiunile set-field sunt identificate de tipul lor de câmpuri, deci setul de acțiuni conține un maxim de cel mult o acțiune de tipul set-field pentru fiecare câmp de acest tip. Când sunt necesare mai multe acțiuni de același tip se folosește acțiunea Apply-Actions. Acțiunile dintr-un set de aplică într-o anumită ordine, indiferent de ordinea în care au fost adăugate în set.

Instrucțiunea Apply-Actions și mesajul de tip Packet-out includ o lista de acțiuni. Acestea se execută în ordinea în care au fost introduse în listă și sunt aplicate imediat pachetului. Execuția unei liste de acțiuni începe de la prima acțiune și fiecare acțiune este executată pachetului în ordine. Efectul acestora este cumulativ. Dacă lista de acțiuni conține o acțiune de ieșire, o copie a pachetelor este dirijată către portul dorit. După execuția unei liste de acțiuni, execuția pipeline continuă de la ultimul pachet modificat. Setul de acțiuni al pachetului este neschimbat de execuția listei.

2.5 Canalul OpenFlow

Canalul OpenFlow este interfața care conectează fiecare switch OpenFlow la controller. Prin această interfață, controller-ul configurează și gestionează switch-ul, primește evenimente de la switch și trimite pachete acestuia. Între calea datelor și canalul OpenFlow, interfața este specifică implementării, iar toate mesajele care circulă prin canal trebuiesc formatate în conformitate cu protocolul OpenFlow. Canalul este, de obicei, criptat folosind TLS, dar poate rula și direct prin TCP.

Protocolul OpenFlow suportă trei tipuri de mesaje: controller-to-switch, asincrone și simetrice, fiecare având multiple subtipuri. Mesajele de tipul controller-to-switch sunt inițiate de controller și folosite pentru a gestiona sau inspecta direct starea switch-ului. Cele asincrone sunt inițiate de switch și sunt utilizate la actualizarea controller-ului în urma eveimentelor și schimbărilor de rețea asupra stării switch-ului. Mesajele simetrice sunt inițiate fie de switch, fie de controller și se trimit fără solicitare.

2.5.1 Controller-to-switch

Aceste mesaje sunt inițiate de către controller și pot sau nu să necesite un răspuns de la switch.

Features: controller-ul poate cere capabilitățile switch-ului prin trimiterea unei cereriș switch-ul trebuie să răspundă, specificând capabilitățile sale. Acest proces este efectuat, de obicei, la stabilirea canalului OpenFlow.

Configuration: controller-ul poate seta și interoga paramentri ai switch-ului, iar switch-ul răspunde numai unei interogări.

Modify-State: sunt trimise de către controller pentru a gestiona starea switch-urilor. Principalul lor scop este de a adăuga, șterge sau modifica fluxuri în tabele OpenFlow și de a seta proprietăți ale porturilor switch-ului.

Read-State: sunt folosite pentru de controller pentru a colecta diverse informații de la switch, cum ar fi configurația curentă, statistici, etc.

Packet-out: sunt folosite de controller pentru a trimite pachete pe un port speficat al switch-ului și să dirijeze pachetele primite prin mesaje de tipul Packet-in. Mesajele Packet-out trebuie să conțină un pachet întreg sau un ID care să refere pachetul stocat în switch. Mesajul trebuie să conțină și o listă de acțiuni care să fie aplicate în ordinea specificată. O acțiune vidă presupune aruncarea pachetului.

Barrier: mesajele de tip Barrier cerere/răspuns sunt folosite de controller pentru a primi notificări pentru anumite operații finalizate.

Role-Request: folosite de controller pentru a seta rolul canalului său OpenFlow. Este cel mai mult folosit atunci când switch-ul se conectează la mai multe controllere.

Asynchronous-Configuration: folosite de controller pentru a seta un filtru adițional al mesjelor asincrone pe care vrea să le primească pe canal. Sunt necesare atunci când switch-ul se conectează la mai multe controllere.

2.5.2 Mesajele asincrone

Mesajele asincrone sunt trimise fără să fie solicitate de controller switch-ului. Switch-urile trimit mesajele asincrone controller-elor pentru a confirma sosirea unui pachet, schimbarea stării switch-ului sau o eroare. Există patru mesaje asincrone principale, descrise mai jos.

Packet-in – trasferă controlul unui pachet controller-ului. Petru toate pachetele dirijate către portul rezervat CONTROLLER, un eveniment de tipul packet-in este intotdeauna trimis către controller. Acest tip de evenimente pot fi configurate pentru a avea și funcția de buffere de pachete. În acest caz, dacă switch-ul are suficientă memorie pentru a stoca pachetele, packet-in vor conține numai o fracțiune din antetul pachetelor și un buffer de id-uri ce va fi folosit de controller pentru a dirija pachetul când switch-ul este pregătit. Pachetele din buffer vor fi procesate prin intermediul mesajelor Packet-out de la controller, sau vor expira după un anumit timp.

Flow-Removed – informează controller-ul despre ștergerea unui flux din tabela de fluxuri. Aceste mesaje sunt trimise pentru intrările de flux cu un flag setat. Ele sunt generate ca un rezultat al ștergerii unui flux de către controller sau la expirarea unui contror al unui flux.

Port-status – informează controller-ul de schimbari apărute pe un port. Aceste evenimente includ schimbări în configurarea porturilor, de exemplu, dacă un port a fost adus în starea de inactivitate direct de către un utilizator, și evenimente legate de schimbarea stării unui port, de exemplu, dacă o legătură este căzută.

Error – switch-ul anunță controller-ele în privința diverselor probleme folosind mesajele de eroare.

2.5.3 Mesajele simetrice

Mesajele simetrice sunt trimise fără solicitări, în ambele direcții. Acestea sunt:

Hello – aceste mesaje sunt schimbate între switch și controller la stabilirea conexiunii.

Echo – mesajee Echo request/reply pot fi trimise fie de switch către controller, fie invers și trebuie să returneze un Echo reply. Sunt folosite pentru a verifica starea conexiunii și pentru măsurarea benzii și latenței.

Experimenter – aceste mesaje furnizează un mod standard pentru ca switch-urile OpenFlow să ofere funcționalități adiționale în mesajele OpenFlow. Acesta este un început pentru revizuirile viitoare ale protocolului.

2.6 Tratarea mesajelor

Protocolul OpenFlow nu furnizează un mecanism sigur de livrare și procesare a mesajelor. În plus, protocolul nu furnizează în mod automat confirmări pentru a asigura procesarea în ordine a mesajelor.

Când un switch primește un mesaj de la controller, trebuie să îl proceseze și, în funcție de tipul mesajului , switch-ul poate genera un răspuns. Un mesaj de eroare va fi trimis controller-ului dacă switch-ul nu poate procesa complet un mesaj primit de la controller. Este foarte important ca viziunea controller-ului asupra switch-ului sa fie potrivită cu starea switch-ului OpenFlow. Pe scurt, tratarea mesajelor este următoarea:

Livrarea mesajelor: mesajelor le este garantată livrarea, în afară de cazul când canalul OpenFlow pică, caz în care controller-ul nu ar trebui să presupună nimic despre starea switch-ului.

Procesarea mesajelor: switch-urile trebuie să proceseze fiecare mesaj primit de la controller și, eventual să genereze un răspuns. Dacă un switch nu poate procesa un mesaj, el trebuie să trimită un mesaj de eroare. În plus, switch-urile trebuie să trimită către controller toate mesajele asincrone generate de schimbările de stare ale OpenFlow, cum ar fi: ștergerea de fluxuri, starea porturilor, etc., pentru ca vederea de ansamblu a controller-ului asupra switch-ului sa fie actuală. Controller-ele pot ignora mesajele pe care le primesc, dar trebuie să raspundă celor de tip Echp pentru a menține conexiunea.

Ordonarea mesajelor: ordonarea poate fi asigurată prin utilizarea mesajelor de tip Barrier. În lipsa acestora, switch-urile ordonează arbitrar mesajele astfel încât să maximizeze performanțele, deci controller-ele nu ar trebui să depindă de o anumită ordine de procesare. În special, intrările de flux pot fi inserate în tabele într-o ordine diferită de cea a primirii mesajelor pe switch.

2.7 Conexiunea canalului OpenFlow

Un switch OpenFlow și un controller OpenFlow schimbă mesaje folosind un canal OpenFlow. În general, un singur controller va comunica cu mai multe switch-uri OpenFlow folosind mai multe canale. Astfel, un singur switch va avea fie o singură conexiune către un controller printr-un canal, fie multiple conexiuni OpenFlow cu multiple controllere pentru scalabilitate și siguranță. Un controller OpenFlow este localizate departe și folosește mai multe rețele pentru a se conecta la un switch dat. Singura cerință în acest caz ar fi ca switch-ul și controller-ul să suporte TCP/IP. Rețeaua care se presupune că va suporta comunicația controller-switch poate fi o rețea dedicată, partajată sau o rețea de tipul in-band (reșeaua gestionată de switch-ul OpenFlow).

Canalul OpenFlow dintre switch și controller este, în general, o singură conexiune de rețea care folosește TLS (Transport-Layer Security) sau TCP. Este posibilă crearea unei conexiuni compusă din mai multe conexiuni de rețea pentru a exploata paralelismul. Switch-ul OpenFlow este cel responsabil pentru stabilirea conexiunii cu controller-ul. În anumite cazuri, switch-ul poate permite controller-ului să stabilească o conexiune cu el. Totuși, în acest caz, switch-ul ar trebui să își restricționeze accesul la utilizarea numai conexiunilor sigure (TLS) pentru a preveni accesul neautorizat la acesta.

Portul utilizat pentru stabilirea conexiunii între switch și controller trebuie să fie o adresă IP configurabilă de utilizator, dar de altfel fixă. Această conexiune poate fi stabilită folosind fie un port de transport specificat de utilizator, fie portul implicit de transport. Presupunând că switch-ul a fost preconfigurat cu adresa IP a controller-ului pentru a se putea conecta, switch-un va iniția o conexiune standard TLS sau TCP către controller. Traficul de la și spre canal nu trece prin procesarea pipeline. Acest lucru înseamnă că switch-ul va trebui să identifice traficul care sosește ca fiind local înainte să îl verifice cu tabelele de fluxuri.

Un switch poate detecta că a pierdut contactul cu controller-ele externe la care a fost conectat atunci când detectează expirarea echo request, a sesiunii TLS sau alte deconectări. Când acest lucru se întâmplă, switch-ul trebuie să se declare imediat fie în modul ”fail secure mode”, fie în ”fail stand-alone mode”, în funcție de implementarea și configurarea switch-ului. Diferența dintre cele două moduri este aceea că în ”fail secure mode”, singura schimbare în comportamentul switch-ului este aceea ca pachetele și mesajele destinate controller-ului, sunt aruncate.

Un mod prin care switch-ul și controller-ul comunică este prin intermediul conexiunii TLS. Switch-ul stabilește o sesiune TLS către controller-ul extern când pornește. Conexiunea se realizează pe portul implicit 6633. Pentru a autentifica și switch-ul și controller-ul, sunt schimbate certificate semnate de o cheie privată specifică. Se cere ca fiecare switch să fie configurabil de către utilizator, cu un certificat de autentificare a controller-ului și un certificat pentru autentificarea switch-ului.

Comunicația dintre switch și controller folosind TCP este permisă; switch-ul va iniția o conexiune TCP când pornește, conexiune realizată pe portul implicit 6633. Se recomandă ca atunci când se folosește o conexiune TCP să se ia măsuri de securitate pentru a preveni interceptarea sau alte tipuri de atac asupra canalului OpenFlow.

2.8 Modurile de operare ale controllerului

Protocolul OpenFlow suportă trei moduri diferite pentru controller-ele conectate la un switch. Acestea sunt: equal, master și slave.

Figura de mai jos arată patru scenarii posibile pentru conexiunea unuia sau mai multor controllere la un switch OpenFlow. În primul scenariu, un singur controller este conectat la switch-ul OpenFlow și funcționează în modul equal. Când un controller funcționează în acest mod, acesta are acces deprin la switch. Acțiunea implicită asociată acestui mod este de a primi toate mesajele asincrone. Acest mod permite controller-ului să trimită către switch comenzi de tipul controller-to-switch pentru a modifica starea acestuia.

Cel de-al doilea scenariu, două controllere care funcționează în modul equal, sunt conectate la același switch. Switch-urile OpenFlow pot stabili conexiuni cu un singur controller sau cu mai multe. Dacă un switch este conectat la mai multe controllere în același timp, acestea vor fi considerate ca fiind mai sigure și pot continua să funcționeze în modul OpenFlow dacă unul dintre ele sau conexiunea se defectează. Când este necesar un transfer de controllere, acest lucru va fi suportat chiar de acestea, fără a fi necesară implicarea switch-ului. Acest aspect prezintă două avantaje: primul este acela că permite revenirea rapidă în urma unor defecțiuni și al doilea că permite controller-ului load balancing.

În cel de-al treilea scenariu, un switch OpenFlow este conectat la trei controllere: două în modul equal și unul în modul slave. Un controller are posibilitatea de a cere ca rolul lui să fie schimbat. Acest lucru poate fi realizat prin cererea ca rolul acestuia să fie schimbat în slave. Acest mod permite controller-ului să aibă doar acces de tipul read-only la switch. Comportamentul implicit al acestui mod este ca mesajele asincrone să nu fie primite de switch, în afară de cele legate de starea porturilor. Controller-ului nu îi este permis să execute toate comenzile controller-to-switch care trimit pachete sau modifică starea switch-ului.

Scenariul 4 prezintă un switch OpenFlow legat la trei controllere: unul în modul equal, unul în modul slave și unul master. Când un controller este master, acel controller are acces deplin la switch. Diferența dintre rolul de master și cel equal este acela că, în rolul de master, switch-ul se va asigura că acest controller este singurul în acel moment în acel rol. Switch-ului îi este interzis să schimbe starea unui controller singur.

Figura 2.4 : Modurile controllerelor OpenFlow

2.9 Prezentarea unul controllere OpenFlow

Diverse controllere au fost dezvoltate și oferă diverse posibilități. Acestea pot fi clasificate în două categorii: controllere care oferă o înterfață OpenFlow și câteva nivele de abstractizare și controllere care vor presupune soluții mai complexe.

2.9.1 NOX

Inițial dezvoltat de Nicira, NOX este primul controller OpenFlow. Este open source și scris, în principal, în C++ și a fost folosit în diverse cercetări, iar majoritatea lucrărilor publicate despre SDN și OpenFlow se bazează pe NOX. Acest controller furnizează un mediu favorabil dezvoltatorului în care este ușor să se modifice module sau să se implementeze unele noi. În prezent este în declin, nemaiavând schimbări majore din 2012.

2.9.2 POX

POX este fratele mai mic al lui NOX. Este un controller open source scris în Python și, la fel ca și NOX, furnizează un framework pentru dezvoltarea și testarea unui controller OpenFlow. Datorită utilității Python, este ușor să se implementeze și să se lanseze noi caracteristici, dar performanțele sale sunt relativ slabe, în comparație cu ale altor controllere.

2.9.3 Beacon

Beacon este un controller scris în Java, cunoscut pentru stabilitatea pe care o oferă. A fost creat în 2010 și încă este menținut și folosit în diverse proiecte de cercetare. Un alt avantaj pe care îl are constă în utilizarea OSGi pentru gestionarea independentă și repornirea diverselor pachete. Datorită performanțelor sale, Beacon este o soluție viabilă pentru a fi utilizat în condiții reale. Acest controller a fost utilizat și în proiecte precum Floodlight sau OpenDaylight, descrise mai jos.

2.9.4 Floodlight

Floodlight este un controller open source bazat pe Java, ce derivă din Beacon și suportat de BigSwitch Networks. Este ușor de setat și are performanțe grozave. În prezent, este cel mai matur controller OpenFlow. Cu toate caracteristicile sale, Floodlight este mai mult o soluție complexă decât un simplu controller.

2.9.5 OpenDaylight

OpenDaylight este un proiect suportat de Linux Foundation. Este un framework open source care facilitează accesul la SDN și NFV. Ca și FloodLight, și acest tip de controller poate fi considerat o soluție complexă. Prima versiune, Hydrogen, a fost lansată în decembrie 2013. Deși inițial a fost suportat de renumite companii, cele mai recente îndepărtează acest proiect: BigSwitch continuă să dezvolte FloodLight, iar Juniper introduce propriul controller Contrail.