Retele S.d.n. Studiu de Caz

Rețele SDN – Studiu de caz

Lista acronimelor utilizate în lucrare

Lista figurilor și tabelelor prezente în lucrare

Figura 1.1 Precursorii SDN 13

Figura 1.2 Programul „Clean Slate”[1] 16

Figura 1.3 Arhitectura SDN 17

Figura 2.1 Posibilitățile de separare ale planurilor de date și control 19

Figura 2.2 Planurile de control și date ale unei rețele tradiționale 20

Figura 2.3 Componentele principale ale SDN[2] 23

Figura 2.4 Rețea tradițională de servere 25

Figura 2.5 Migrarea aplicației în mediul SDN 26

Figura 3.1 Switch-ul OpenFlow 28

Tabelul 3.1 Tabela de flux a unui switch OpenFlow 29

Figura 3.2 Căile pachetelor corespunzătoare porturilor virtuale[3] 30

Tabelul 3.2 Tipurile de mesaje OpenFlow 1.0 33

Figura 3.3 Sesiunea OpenFlow controler-switch[4] 34

Figura 3.4 Stabilirea unei conexiuni TLS 36

Figura 3.5 Anatomia controlerului 37

Figura 3.6 Interfața nordică a controlerului 38

Figura 3.7 Modurile controlerului OpenFlow 38

Figura 3.8 Conexiuni auxiliare între controler și switch 39

Figura 3.9 Aplicațiile SDN 40

Figura 4.1 Arhitectura de virtualizare 44

Figura 4.2 Topologia rețelei simulate 45

Figura 4.3 Deschiderea rețelei 46

Figura 4.4 Informații referitoare la dispozitive 46

Figura 4.5 Configurația de rețea pentru Client 1 47

Figura 4.6 Legăturile dintre dispozitive 47

Figura 4.7 Testare conectivitate fără controler 48

Figura 4.8 Arhitectura controlerului 48

Figura 4.9 Pornirea controlerului 49

Figura 4.10 Mesaje schimbate la inițializarea controlerului 50

Figura 4.11 Testarea conexiunii 50

Figura 4.12 Schimbul de mesaje între switch și controler 51

Figura 4.13 Arhitectura planului de control 52

Figura 4.14 Testare acces stații din exterior 53

Figura 4.15 Testare acces clienți 53

Figura 4.16 Configurarea switch-urilor pentru a suporta QoS 54

Figura 4.17 Testare lățime de bandă fără modulul QoS 54

Figura 4.18 Testare lățime de bandă cu modulul QoS activat 55

Figura 4.19 Arhitectura planului de control 55

Figura 4.20 Statistici trafic generate 56

Figura 4.21 Trafic rețea pentru switch-urile S9 și S10 57

Figura 4.22 Trafic HTTP în rețea 58

Figura 4.23 Trafic FTP în rețea 59

Figura 4.24 Trafic HTTP în rețeaua modificată 60

Introducere

Prezenta lucrare își propune studiul rețelelor definite prin software (Software Defined Networking) sau SDN.

De-a lungul anilor, Internetul a condus la crearea unei societăți digitale, în care totul este conectat și accesibil de oriunde. Totuși, în ciuda adopției rapide, rețelele tradiționale IP sunt complexe și greu de administrat. Atât configurarea unei rețele în concordanță cu niște politici predefinite, cât și reconfigurarea acesteia ca răspuns la avarii, supraîncărcări și schimbări reprezintă sarcini dificile de realizat. Pentru a face lucrurile și mai complicate, rețelele actuale de calculatoare sunt integrate pe verticală: planurile de control și de date se regăsesc în același dispozitiv fizic.

Software Defined Networking este o paradigmă în curs de dezvoltare ce se angajează să schimbe starea actuală a rețelelor prin separarea logicii de control de echipamentele de comutare din planul de date și introducerea capabilității de programare a rețelei. SDN reprezintă o nouă abordare a rețelelor de calculatoare ce permite operatorilor de rețele, producătorilor de echipamente, furnizorilor de servicii să inoveze și să implementeze noi competențe într-un ritm rapid. Paradigma rețelelor definite prin software prezintă potențial pentru multe domenii de utilizare, incluzând centrele de date, furnizorii de servicii mobile sau fixe, companii sau chiar locuințe.

Scopul acestei lucrări este de a descrie cadrul ce a dat naștere conceptului SDN și de a sublinia caracteristicile definitorii ce îl diferențiază de arhitectura actuală de rețea. De asemenea, rolul prezentei lucrări este de a îndruma orice persoană ce dorește să realizeze o rețea de tip SDN, cât și diferite aplicații de tip SDN. Una din provocările întâlnite în redactarea prezentei lucrări o constituie gradul ridicat de evoluție a acestei tehnologii.

Primul capitol are rolul de a prezenta cerințele adresate unei rețele de calculatoare și limitările pe care funcționarea acesteia le impune. De asemenea, se va prezenta un scurt istoric al conceptului SDN, lucrări din care își are originea, precum și arhitectura propusă pentru acesta.

Cel de-al doilea capitol își propune să descrie modul de funcționare al rețelelor definite prin software în comparație cu rețelele actuale, separarea celor două planuri ale rețelei, precum și unele beneficii aduse de SDN.

Capitolul 3 reprezintă partea principală a lucrării în care sunt descrise componentele protocolului OpenFlow pe care se bazează funcționarea SDN, dintre care se pot enumera switch-urile, controlerul și, poate cel mai important în privința dezvoltărilor ulterioare, aplicațiile ce rulează peste acestea. Lucrarea conține un număr mare de figuri și diagrame pentru explicarea și ilustrarea conceptelor de rețea ce sunt definite și discutate.

În studiul de caz se propune o topologie care să simuleze una reală emulată cu ajutorul Mininet și are rolul de a prezenta modul de funcționare al unei rețele de tip SDN, mesajele schimbate între echipamente, precum și performanțele obținute.

Lucrarea se încheie prin prezentarea concluziilor personale realizate în urma studiului unei rețele de tip SDN.

1. Conceptul Software Defined Networking

1.1 Nevoia unei noi arhitecturi de rețea

Creșterea masivă din ultimii ani a numărului de dispozitive mobile, a virtualizării serverelor și a serviciilor sunt factorii care au condus la reexaminarea arhitecturii de rețea tradiționale. Multe din rețelele convenționale sunt ierarhice, bazate pe niveluri de echipamente organizate într-o structură de tip arbore. Topologia era utilă atunci când interacțiunea client-server era dominantă, dar această arhitectură statică este depășită de cerințele actuale ale companiilor, ale centrelor de date, precum și ai utilizatorilor finali. Câteva din aspectele care au impus un nou tip de rețea sunt:

Schimbarea modelelor de trafic: În interiorul centrelor de date, tiparul traficului s-a modificat considerabil. În contrast cu aplicațiile client-server în care comunicațiile aveau loc între un client și un server, astăzi aplicațiile accesează diferite baze de date și servere, creând un flux de trafic major între diferite mașini, înainte de a trimite datele către utilizatorul final. În același timp, utilizatorii modifică traficul în rețea prin accesarea de conținut de pe diferite dispozitive, conectându-se de oriunde și în orice moment.

Creșterea serviciilor virtuale: Companiile utilizează tot mai mult servicii de tip cloud, atât private cât și publice. Pentru a adăuga complexitate, toate aceste servicii trebuie sa aibă loc într-un mediu securizat, în conformitate cu cerințele de audit ale unei companii.

Diversitatea accesărilor: Utilizatorii folosesc dispozitive mobile personale precum telefoane inteligente, tablete și laptop-uri pentru a accesa rețeaua companiei pentru care lucrează, ceea ce înseamnă o presiune suplimentară asupra acesteia pentru a putea integra toate aceste dispozitive și pentru a proteja datele companiei.

Creșterea lățimii de bandă: Manipularea seturilor mari de date necesită o procesare paralelă pe mii de servere, toate fiind direct conectate între ele. Creșterea acestor seturi de date se traduce printr-o cerere constantă a capacității rețelei în centrele de date. Operatorii rețelelor pentru astfel de centre au sarcina dificilă de a menține activă conectivitatea între orice puncte ale acestora.

1.2 Limitările tehnologiei actuale de rețea

Rețelele de calculatoare actuale sunt rezultatul unor protocoale și a unor decizii de proiectare realizate inițial în anii 1970. Rețelele erau considerate a fi statice. O dată realizată,se presupunea că topologia rețelei nu se va schimba mult. Serverele care conectează rețelele actuale au suferit o transformare dramatică în ultimul deceniu. Apariția virtualizării serverelor au schimbat fundamental rolul acestora. Serverele sunt acum dinamice și pot fi create și mutate cu ușurință. Înainte de apariția acestei virtualizări, aplicațiile erau asociate unui singur server ce avea o locație fixă în rețea. Aceste aplicații foloseau rețeaua pentru a schimba informații între ele. Aplicațiile actuale pot fi distribuite pe mai multe mașini virtuale. Fiecare dintre acestea schimbă fluxuri de trafic cu altele. Administratorii de rețea pot muta aceste mașini virtuale pentru a optimiza și rebalansa încărcarea serverelor. Această migrarea presupune schimbarea punctului fizic terminal al unui flux existent.

Îndeplinirea cerințelor actuale ale utilizatorilor sunt aproape imposibil de realizat cu arhitecturile actuale de rețea. Având bugete limitate, departamentele IT ale companiilor încearcă să obțină cât mai mult din rețelele lor, utilizând instrumente de management al echipamentelor. Furnizorii de servicii întâmpină provocări similare ca urmare a cererii foarte mari în privința mobilității și a lățimii de bandă. Topologiile de rețea existente nu au fost proiectate pentru a suporta exigențele utilizatorilor, ale companiilor și ale furnizorilor de servicii.

Arhitecții de rețea întâmpină următoarele limitări în proiectarea și implementarea unei topologii:

Creșterea complexității: Tehnologiile de rețea din prezent constau dintr-un număr mare de protocoale proiectate să conecteze fiabil echipamente pe diferite distanțe, viteze de conexiune și topologii. Pentru a satisface nevoile tehnice din ultimele decenii, protocoalele de rețea au evoluat pentru a furniza performanțe, fiabilitate, conectivitate și securitate cât mai ridicate. Protocoalele sunt definite solitar și sunt utilizate pentru a rezolva o problemă specifică. Din aceasta rezultă o primă limitare a rețelelor actuale: complexitatea. Spre exemplu, pentru a adăuga sau elimina un echipament de rețea, inginerii trebuie să se conecteze la diferite switch-uri, rutere, echipamente de filtrare, portale de autentificare, să actualizeze diferite liste de acces, rețele locale virtuale (VLAN), nivelul calității serviciilor (QoS) și alte mecanisme bazate pe protocoale utilizând instrumente de management. Din cauza acestei complexități, rețelele actuale sunt relativ statice, întrucât o eventuală modificare în rețea crește riscul întreruperii serviciilor care utilizează rețeaua respectivă. Natura statică a acestor rețele este în puternic contrast cu natura dinamică a mediului de servere actual, în care virtualizarea acestora a crescut numărul de host-uri pentru care este necesară conectivitate la rețea și a căror percepție despre locația fizică este fundamental modificată. Înaintea virtualizării, aplicațiile se aflau într-un singur server care schimba informații numai cu clienții selectați. În prezent, aplicațiile sunt distribuite pe mai multe mașini virtuale, care schimbă informații între ele. Mașinile virtuale migrează pentru a optimiza și reechilibra încărcarea pe server, ceea ce conduce la modificarea punctelor fizice între care se stabilise conexiunea. Suplimentar adoptării tehnologiilor de virtualizare, multe companii folosesc o rețea IP convergentă pentru traficul de voce, date și video. În timp ce rețelele actuale pot asigura anumite nivele QoS pentru diferite aplicații, provizionarea acestora se face manual. Inginerii trebuie să configureze fiecare echipament al fiecărui producător separat și să modifice parametrii precum lățimea de bandă, nivelul calității serviciilor pentru fiecare sesiune, pentru fiecare aplicație. Din cauza naturii sale statice, rețeaua nu se poate adapta dinamic la schimbările de trafic, la cerințele anumitor aplicații și ale utilizatorilor.

Politici incoerente: Pentru a implementa o politică la nivel de rețea, inginerii trebuie să configureze mii de dispozitive și echipamente. Spre exemplu, de fiecare dată când o mașină virtuală este pornită, procesul de reconfigurare al listelor de acces ale întregii rețele poate dura ore sau chiar zile. Complexitatea rețelelor actuale face foarte dificilă sarcina inginerilor de a aplica un set de politici de acces, securitate, QoS întrucât rețeaua poate deveni vulnerabilă, nerespectând anumite reglementări interioare, prezentând breșe de securitate sau alte consecințe negative.

Incapacitatea de scalare: Pe măsură ce necesitățile din centrele de date au crescut rapid, rețelele trebuie de asemenea să se mărească. Totuși, acestea devin din ce în ce mai complexe prin adăugarea a sute sau chiar mii de echipamente de rețea ce trebuiesc configurate și gestionate. Spre exemplu, marii furnizori de servicii utilizează algoritmi de procesare paralelă și seturile de date asociate la nivelul întregului spațiu de calcul. Întrucât domeniul de utilizare al aplicațiilor este tot mai mare, numărul elementelor de calcul a crescut și seturile de date schimbate între acestea pot fi de ordinul petaocteților. Astfel de companii au nevoie de așa numitele rețele hiperscalate care prezintă performanțe ridicate și un cost redus în ceea ce privește conectarea a sute sau mii de servere. O astfel de scalare nu poate fi realizată configurând manual fiecare echipament.

Dependența de producătorii de echipamente: Furnizorii de servicii și companiile încearcă să implementeze noi funcții care să facă față nevoilor acestora și cerințelor utilizatorilor. Totuși, capacitatea lor de a reacționa este îngreunată de furnizorii de echipamente ale căror dispozitive pot îndeplini sarcinile impuse pentru un ciclu de aproximativ trei ani, datorat dezvoltării rapide a tehnologiei.

Aceste neconcordanțe între nevoile pieței și capabilitățile rețelei au dus industria IT într-un punct critic. Ca răspuns, aceasta a creat arhitectura rețelelor definite prin soft sau Software-Defined Networking (SDN) și standardele asociate.

1.3 Precursorii SDN

Înainte de apariția conceptului Software Defined Networking, cercetătorii au avut în vedere schimbări fundamentale în lumea actuală a dispozitivelor autonome și a inteligenței și controlului distribuit al rețelei. Există o progresie constantă a ideii legate de avansul tehnologiei de rețea spre ceea ce astăzi se numește SDN. În figura 1.1 este reprezentată această progresie în care intervalele de timp reprezintă perioada aproximativă în care tehnologiile respective au fost dezvoltate sau aplicate.

Figura 1.1 Precursorii SDN

Unele din primele încercări de programare a rețelelor au început cu switch-urile cu mod de transfer asincron (ATM), iar două dintre acestea sunt proiectele DCAN și Semnalizări deschise în care cele două planuri ale rețelei, de date și de control, sunt separate. Control rețelei îi revenea unui dispozitiv extern ce are un rol similar cu cel din SDN. Proiectul Semnalizări deschise propunea un set de interfețe deschise, programabile pentru switch-urile ATM. Comutația pe bază de etichete a fost propusă inițial de Cisco și s-a concretizat în protocolul MPLS. Acesta reprezintă o deviație de la deciziile autonome și distribuite de direcționare a traficului caracteristice ruterelor tradiționale și, în acest sens, este un mic pas către paradigma de comutare SDN.

Lucrarea „Separarea elementelor de control și direcționare a traficului” a fost realizată de IETF începând cu anul 2003. ForCES reprezintă una din propunerile ce recomandă decuplarea planurile de control și de date. Ideea generală consta în asigurarea unei direcționări folosind echipamente simple și controlarea acestora prin software. Dispozitivele din planul de date erau construite folosind tehnologia de comutație pe bază de celule sau de etichete. Elementele de direcționare a traficului era implementate în hardware și localizate în rețea, responsabilitatea lor era de filtra și comuta pachetele în concordanță cu regulile primite de la controler. Elementul de control se ocupa de coordonarea dispozitivelor din rețea și de transmiterea informațiilor de rutare.

Seminarul legat de migrarea tehnologiei de rețea către un controler central s-a concretizat în lucrarea: „A Clean Slate 4D Approach to Network Control and Management”. 4D, denumit după arhitectură bazată pe patru planuri: decizie, diseminare, descoperire și date, propune o reorganizare completă a rețelelor spre ideea de concentrare a operațiilor planului de control într-un dispozitiv separat, independent și dedicat acestui scop. Proiectul 4D delimetează câteva din provocările cu care se confruntă arhitectura centralizată, dintre care amintim latența, scalabilitatea, disponibilitatea ridicată și securitatea.

Ethane a fost introdus într-o lucrare numită „Rethinking Enterprise Network Control” în anul 2007. Ethane reprezintă o soluție bazată pe politici ce permite administratorilor de rețea să definească politici referitoare la accesul utilizatorilor în rețea. Acesta este construit pe baza a trei principii fundamentale:

Rețeaua trebuie să fi reglementată printr-un set de politici de nivel înalt;

Procesul de rutare în rețea trebuie să fie în concordanță cu aceste politici;

Rețeaua trebuie să impună legături între pachete și originea lor.

Controlul accesului în rețea este realizat pe baza unor politici stabilite de administratorul rețelei. La nivel de bază, controlul are rolul de a determina dacă un utilizator este admis sau nu în rețea. Această decizie este luată de obicei pe baza schimbării unor credențiale între utilizator și rețea. RADIUS este folosit pentru a furniza capacitatea de reconfigurare automată a rețelei. Ideea pe care se bazează constă în faptul că atributele rețelei se schimbă pe baza identității resursei de calcul care a apărut în rețea și dorește conectivitate. RADIUS a fost proiectat inițial pentru procesele de autentificare, autorizare și contabilizare (AAA) legate de acordarea accesului unui utilizator.

Alte încercări de automatizare a rețelelor au fost aplicațiile denumite orchestratoare. Acestea utilizează interfețele de programare cum ar fi interfața linei de comandă (CLI) sau protocolul de administrare a rețelei (SNMP). O soluție de orchestrare va implementa politici de nivel înalt ce vor fi executate de dispozitivele conectate.

Conceptul implementării unui manager de virtualizare a rețelei este construit pe baza noțiunii de orchestrare și încearcă să automatizeze notificările de rețea ce sunt necesesare într-un mediu virtual. Unelte specifice unui centru de date sunt configurate pentru a lua anumite decizii în cazul în care un server va migra.

1.4 Definirea conceptului SDN

Susținătorii SDN au observat că echipamentele de rețea pe care le puteau achiziționa nu îndeplineau nevoile lor, mai ales din perspectiva unor dezvoltări ulterioare. De asemenea, echipamentele de ultimă generație erau supraestimate din punctul de vedere al prețului de cost comparativ cu specificațiile lor. În același timp, costul puterii de calcul devenea din ce în ce mai mic, ajungând în punctul în care un echipament putea avea până la o mie de procesoare. A fost momentul în care au realizat că această putere de calcul poate fi exploatată pentru a lucra într-o unitate centrală logică, de control a unor dispozitive de comutare cu preț redus. Ingineri ai Universității Stanford au creat protocolul OpenFlow care poate fi implementat într-o astfel de configurație. OpenFlow a fost conceput pentru dispozitive ce conțin doar planul de date, răspunzând comenzilor trimise de un controler central care conține singurul plan de control al rețelei. Controlerul are rolul de a menține toate rutele din rețea, precum și programarea fiecărui dispozitiv pe care îl controlează. Totodată, soluția propusă nu neglijează progresele în ceea ce privește tehnologia rețelelor actuale, ci recomandă o variantă hibrid, în care unele părți ale rețelei să fie comandate de către un controler central, iar celelalte părți să lucreze pe structura tradițională, cu planul de control distribuit pe fiecare echipament.

Conceptul Software-Defined Networking își are originile în programul „Clean Slate” (figura 1.2 ) propus de un grup de cercetători ai Universității Stanford în urmă cu șapte ani. Aceștia au plecat de la ideea proiectării unui nou tip de Internet pornind de la zero, fără a acumula complexitatea sistemelor actuale de rețea, dar folosind experiența deceniilor de dezvoltare. Clean Slate se bazează pe ideea că Internet-ul actual prezintă deficiențe semnificative ce ar fi trebuit rezolvate înainte ca acesta să devină o infrastructură de comunicație globală. Acest program este caracterizat de două mari întrebări: „Cu ceea ce știm în prezent, dacă ar fi să începem de la zero, cum am proiecta infrastructura de comunicații globală? ” și „Cum ar trebui să arate Internetul în următorii 15 ani?”.

Coordinatorii programului au identificat cinci mari arii de cercetare:

Arhitectura de rețea de calculatoare;

Aplicații eterogene;

Tehnologii eterogene la nivelul fizic;

Securitatea;

Economii și politici.

Figura 1.2 Programul „Clean Slate”[1]

Sursa: http://cleanslate.stanford.edu/

Programul Clean Slate a încetat în luna ianuarie a anului 2012, după realizarea a patru mari proiecte:

Infrastructura Internet: OpenFlow și Software Defined Networking

Internetul mobil direct programabil: POMI 2020;

Rețelele mobile de socializare: MobiSocial;

Centrul de date: Laborator experimental al unui centru de date.

Software-Defined Networking este o arhitectura de rețea în curs de dezvoltare în care planul de control este decuplat de cel de date și este direct programabil. SDN este o abordare arhitecturală care optimizează și simplifică funcționarea unei rețele prin creșterea interacțiunii (provizionare, mesaje, alarme) între aplicații, servicii și echipamente, chiar dacă acestea sunt reale sau virtuale. Acest lucru se realizează utilizând un nod logic central, numit SDN controler, care mediază și facilitează comunicarea între aplicații ce doresc să interacționeze cu elementele de rețea, precum și reciproc. Controlerul transmite funcțiile și operațiunile rețelei printr-o interfață programabilă, bidirecțională.

Unul din cele mai semnificative evenimente ce au avut loc în scurta istorie a SDN a avut loc în 2012. La sumitul „Open Networking”, la care au participat peste 1000 de ingineri din industria de rețele, Google a anunțat că folosește tehnologia SDN ca parte a unei mari rețele utilizată pentru interconectarea propriilor centre de date.

În figura 1.3 este ilustrată configurația logică a arhitecturii SDN. Inteligența rețelei se regăsește în controlerul SDN care realizează o imagine globală a acesteia. Așadar, rețeaua apare, din punctul de vedere al aplicațiilor, ca un singur echipament logic. Cu ajutorul SDN, companiile și furnizorii de servicii obțin independență față de producătorii de echipamente, putând controla întreaga rețea dintr-un singur punct logic, ceea ce simplifică esențial topologia și funcționarea rețelei. De asemenea, SDN ușurează și sarcina echipamentelor de rețea din moment ce acestea nu trebuie să mai proceseze mii de protocoale, ci doar trebuie să preia instrucțiunile date de controlerul SDN.

Figura 1.3 Arhitectura SDN

Poate cel mai important lucru, operatorii de rețea și administratorii pot configura prin programare această rețea simplificată, în loc să introducă mii de linii de cod pentru fiecare dispozitiv în parte. În plus, prin intermediul controlerului SDN, inginerii pot modifica comportamentul rețelei în timp real și pot dezvolta noi aplicații și servicii de rețea într-un timp mult mai scurt, de ordinul orelor sau zilelor. Prin centralizarea stării rețelei în nivelul de control, SDN oferă operatorilor acesteia flexibilitatea de a configura, administra, securiza și optimiza resursele rețelei într-un mod dinamic, automatizat prin programe SDN. Mai mult, aceștia pot dezvolta singuri aceste programe, fără a mai fi necesară implicarea furnizorilor de echipamente în propriile rețele.

Suplimentar cu abstractizarea rețelei, arhitectura SDN suportă un set de interfețe pentru programarea de aplicații (API) care fac posibilă implementarea serviciilor de rețea generale, precum rutare, securitate, controlul accesului, managementul lățimii de bandă, ingineria traficului, calitatea serviciilor, optimizarea procesorului și a spațiului de stocare, consumul de energie și toate formele de politici de administrare pentru a îndeplini obiectivele companiei.

SDN face posibilă controlarea întregii rețele prin intermediul sistemului de provizionare. Promoterii SDN au studiat varianta introducerii unei interfețe comune pentru programarea de aplicații prin care să se poată administra echipamentele provenite de la diverși furnizori. Astfel, prin intermediul acestei interfețe între planul de control și planul de aplicații, din punctul de vedere al companiilor, aplicațiile acestora vor lucra făcând abstracție de rețea, bazându-se pe serviciile și capabilitățile acesteia fără a fi constrânse de detaliile de implementare.

2. Funcționarea SDN

2.1 Separarea planurilor de date și de control

Separarea planurilor de date și control este în mod fundamental unul din principiile SDN. Deși nu este un concept nou, modul în care era gândită această problemă prezenta câteva neclarități: cât de departe poate fi localizat planul de control față de cel de date, de câte instanțe este nevoie pentru a satisface cerințele cu privire la disponibilitate sau dacă planul de control poate fi separat în totalitate de planul de date. Figura 2.1 ilustrează spectrul de opțiune disponibil operatorilor de rețea, precum și câteva argumente pro și contra acestui concept.

Figura 2.1 Posibilitățile de separare ale planurilor de date și control

Planul de control stabilește setul de date locale utilizate pentru a crea tabelele de direcționare a traficului ce sunt folosite de către planul de date. Setul de date în care se stochează topologia rețelei poartă numele de baza informației de rutare (RIB). Această bază, se dorește a fi menținută fără bucle în timpul schimbării informațiilor între diferite instanțe ale planurilor de control dintr-o rețea. Tabela de direcționare a intrărilor este numită baza informației de direcționare (FIB) și este adesea reflectată între planurile de date și control ale unui echipament. FIB este construită după ce RIB se consideră a fi stabilă. Pentru a realiza această sarcină, programul de control al întregii rețelei trebuie să își construiască o imagine de ansamblu a acesteia. Această imagine asupra rețelei poate fi programată manual, învățată prin supraveghere sau construită din informațiile rezultate în urma interacțiunii între instanțele planurilor de control, ca urmare a utilizării unuia sau mai multor procoale de rutare, direcționare statică sau o combinație între cele două.

Mecanismul de funcționare al planurilor de control și date este prezentat în Figura 2.2, în care avem o rețea de switch-uri interconectate. În partea de sus a imaginii este ilustrată rețeaua, iar în partea de jos sunt detaliate planurile de control și date pentru două din aceste dispozitive (notate cu A și B). În figură, pachetele sunt recepționate de switch-ul A și sunt direcționate către switch-ul B. După cum se poate observa, planurile de control și date sunt separate, instrucțiunile planului de control fiind executate de procesorul propriu, iar cele ale planului de date de un altul, ambele fiind conținute de același dispozitiv. Pachetele ajung pe portul de intrare al switch-ului A, în planul de date. Dacă pachetul este recepționat de la o adresă MAC necunoscută, acesta este trimis (4) către planul de control, unde acesta este procesat, este învățată adresa și direcționat mai departe. Același mecanism este folosit și în cazul ruterelor, direcționarea pachetelor fiind făcută pe baza adresei IP. După ce un pachet este livrat de planul de control, informația de rutare este procesată și va rezulta o posibilă modificare a RIB, precum și transmiterea de mesaje adiționale ruterelor vecine, înștiințându-i de noua rută învățată. După ce RIB-ul devine stabil, FIB-ul va fi și acesta actualizat. Așadar, planul de control returnează pachetul (C) către planul de date (2) ce va redirecționa corespunzător pachetul (3). Dacă sunt necesare actualizări suplimentare ale FIB, acestea au loc la pasul (C). Același mecanism de procesare a pachetelor va avea loc și în următoarele switch-uri.

Figura 2.2 Planurile de control și date ale unei rețele tradiționale

Acțiunile fundamentale ce pot fi efectuate de planul de date sunt descrise de modul în care prelucrează traficul. Acesta poate direcționa, arunca, asimila sau replica pachetele primite. Dispozitivele determină portul de ieșire corespunzător printr-o căutare în tabela de adrese a acestuia. În cazul în care este necesară procesarea de către planul de control și management, pachetele sunt asimilate. Un caz special de redirecționare a traficului este cel multicast, în care pachetele primite trebuiesc replicate înainte de a fi trimise pe diferite porturi de iesire.

Protocoale, logica și algoritmii care sunt utilizați pentru a programa planul de date aparțin de planul de control. Multe din aceste protocoale necesită cunoașterea întregii rețele. Planul de control determină cum trebuie să fie configurate tabelele de direcționare și logica planului de date. Întrucât în rețelele tradiționale fiecare dispozitiv are propriul plan de control, principala sarcină a acestuia este să prelucreze diferite procoale de rutare și de comutare astfel încât tabelele de redirecționare ale dispozitivelor din rețea sa rămână sincronizate, adică să prevină apariția buclelor.

Deși aceste planuri sunt considerate a fi separate din punct de vedere logic, ele se regăsesc în același echipament. În SDN, planul de control este înlăturat din dispozitivul de comutare într-un controler central.

2.2 Rețea orientată spre extremități

În Software Defined Networking, majoritatea funcționalităților importante pot fi realizate la extremitatea rețelei. Aceste funcționalități includ sarcini de QoS, mobilitate, controlul accesului, migrarea și monitorizarea rețelei. Acestea modifică maniera de utilizare a nucleului rețelei. Acesta va fi folosit doar pentru expedierea pachelelor dintr-o margine în alta a rețelei. Protocoalele din rețelele actuale își indeplinesc foarte bine funcțiile în acest scop.

Împingerea funcționalităților rețelei către extremități are două urmări importante în ceea ce privește proiectarea viitoare a SDN. Complexitatea asociată cu SDN poate fi împinsă către extremitatea rețelei. Aici vor avea loc toate procesele de identificare a identității pachetelor. Efectiv, ceea ce se realizează defapt este o rețea de acoperire la nivelul nucleului rețelei.

Așadar, SDN va putea fi implementat progresiv. Rețeaua poate fi împărțită în două din punctul de vedere al dispozitivelor de comutare. Primele sunt switch-urile centrale, utilizate ca în rețelele actuale. Extremitățile rețelei vor deveni dispozitive definite software ce vor rula pe servere. Switch-ul poate rula un program ce simulează un dispozitiv de comutare de tip OpenFlow, ce are la bază un sistem de operare Linux și un hipervizor al mașinii virtuale Xen.

Aceasta înseamnă că SDN poate fi implementat fără a necesita vreo schimbare la nivelul rețelei nucleu. Switch-urile virtuale poate fi adăugate unei rețele existente și pot realiza un tunel de-a lungul echipamentelor fizice. Astfel, niciunul din dispozitivele de comutare actuale nu vor trebui să suporte interfețe de tip OpenFlow.

Un alt aspect important este acela că SDN oferă posibilitatea ca rețeaua să devină orientată către software. Părțile complicate, cum ar fi calculele în legătură cu expedierea pachetului prin rețea, pot fi realizate de software-ul ce rulează pe dispozitivele din extremități. Planul de control al rețelei este acum un program ce poate funcționa pe orice server. Aceasta este o schimbare majoră, având planul de control într-un alt dispozitiv fizic ce rulează anumite protocoale.

Procesul de creare a rețelei se va schimba de asemenea. Acestea nu vor mai fi proiectate, ci vor fi programate. Ideea principală a aceste programări constă în modularitatea și abstractizarea rețelei fizice. Accentul nu va mai fi pus pe antetele pachetelor. Adevărata valoare a acestei abordări constă în faptul că rețelele vor fi capabile să inoveze la vitezele software-ului și nu vor fi limitate să inoveze doar la nivel hardware.

Software-ul, prin natura sa, acordă un nivel ridicat de abstractizare. Aceasta înseamnă că rețelistica va deveni mult mai mult o disciplină formală. Abstractizarea și separarea planurilor în SDN vor duce la o rigurozitate crescută.

Un exemplu legat de acest aspect constă în modul cum un controler pentru a rețea extinsă va fi proiectat. Una dintre cele mai mari provocări în acest tip de rețea îl constituie avaria unor legături. Atunci când aceasta are loc, toate ruterele din rețea trebuie să aibă tabelele de rutare actualizate, adică să conveargă. Aceasta este definită ca fiind starea unui set de rutere care să dețină aceleași informații cu privire la topologia rețelei în care funcționează. Pentru a fi capabile să își declare starea de convergență, ruterele trebuie să colecteze toate informațiile necesare prin intermediul unui protocol de rutare, informații ce nu trebuie să se contrazică între ele și să reflecte în totalitate adevarata stare a rețelei. Cu alte cuvinte, toate ruterele trebuie să fie de acord topologia rețelei.

În SDN, datorită faptului că sistemul de operare al rețelei va actualiza toate tabelele de rutare, nu vor mai exista convergențe repetate pentru ruterele din rețeaua extinsă. Aceasta înseamnă că va exista o delimitare clară, procesul de actualizare va dura un anumit timp, specificat.

Buclele sunt o altă problemă semnificativă a rețelelor actuale. Acestea pot avea loc atunci când o actualizare a tabelelor de rutare se realizează. Un pachet ce a fost trimis când rețeaua se afla în starea A va afla că este direcționat printr-o rețea ce se află în starea B. Deoarece SDN actualizează imaginea globală și abstractă a rețelei în același timp, nu vor exista neconcordanțe în timpul convergenței, iar buclele vor fi evitate. Acest lucru nu poate fi spus despre marea majoritate a algoritmilor moderni de rutare.

Un alt beneficiu al abstractizării SDN îl reprezintă faptul că procesul de depanare va deveni mult mai ușor. Atunci când o operațiune ce nu ar trebui să aibă loc în rețea este detectată ( un pachet din nodul A este direcționat către un nod B), începând de la nivelul programului de control, inginerii de rețea vor verifica mai întâi dacă acest comportament este cel așteptat. Dacă raspunsul este negativ, atunci vor fi verificate intrările de flux la fiecare nivel de abstractizare. Scopul este de a identifica primul loc în care regula de direcționare a pachetului este încălcată.

Deoarece planul de control SDN este implementat software, din moment ce locația problemei a fost identificată, un program de test poate fi rulat. Printr-o simulare, poate fi identificat un nivel minim de setări ce au dus la încălcarea regulii. Aceasta înseamnă că problemele din rețea vor putea fi detectate și rezolvate urmând un algoritm.

Cel mai mare beneficiu al SDN îl constituie comportamentul global al unui centru de date. Mai mult, va deveni mai ușor cum trebuie să fie controlul rețelei. Când o rețea este construită folosind tehnologia SDN, rețeaua rezultată va fi diferită de cele actuale. Partea hardware utilizată pentru a contrui rețeaua va fi ieftină și se poate interschimba ușor. Software-ul utilizat în SDN poate fi actualizat frecvent și nu depinde de partea hardware a rețelei.

Funcționalitatea Software Defined Networking va fi condusă în principal de software. Acesta se va regăsi la extremitățile rețelei în dispozitivele de comutare definite în soft și în programul de control.

2.3 Modul de operare al SDN

La nivel conceptual, comportamentul și modul de operare al rețelelor definite prin software sunt simple, dar total diferite față de rețelele actuale. În figura 2.3 sunt reprezentate grafic componentele principale ale funcționării SDN: dispozitivele SDN, controlerul și aplicațiile.

Figura 2.3 Componentele principale ale SDN

Echipamentele SDN prezintă funcționalități de direcționare pentru a decide ce acțiune trebuie întreprinsă asupra pachetelor primite. Dispozitivele conțin și datele care conduc la luarea deciziei de direcționare. Acestea reprezintă de fapt fluxul de date definit de controler, așa cum este reprezentat în partea din stânga-sus a fiecărui dispozitiv.

Un flux este destinat unui set de pachete care este transferat dintr-un punct în altul al rețelei. Aceste puncte pot fi definite, printre altele, de adresa IP, identificatorul VLAN, tunel de nivel trei, porturile de intrare. Un set de reguli definește deciziile de comutare pe care dispozitivele trebuie să le ia pentru toate pachetele care aparțin fluxului respectiv. Un flux este unidirecțional, astfel transferul pachetelor între doua puncte, dar în direcții opuse constituie fluxuri separate.

Fiecare dispozitiv conține un tabel de direcționare în care se găsesc o serie de măsuri ce trebuiesc luate pentru fluxul de pachete primit. Când echipamentul SDN primește un pachet, acesta caută în tabel o similitudine. Aceste tabele au fost construite anterior, atunci când controlerul a descărcat aceste reguli specifice către dispozitivele SDN. Dacă echipamentul SDN găsește o potrivire, acesta va realiza acțiunea preconfigurată, care de obicei constă în direcționarea pachetului către un anumit port. În cazul în care nu există nicio similitudine, dispozitivul poate arunca pachetul sau îl poate trimite către controler.

Controlerul SDN este responsabil de abstractizarea rețelei pe care o controlează și de prezentarea resurselor acesteia către aplicațiile care funcționează peste ea. Controlerul permite aplicațiilor SDN să definească fluxuri pe echipamente și ajută aplicațiile să răspundă pachetelor care îi sunt adresate de către echipamente. În figura 2.3 putem observa în partea dreaptă a controlerului că acesta menține o imagine asupra întregii rețele pe care o controlează. Aceasta îi permite să calculeze soluțiile optime de direcționare pentru rețea într-o manieră sigură. Din moment ce un controler poate administra un număr mare de dispozitive de rețea, aceste calcule sunt efectuate în mod normal de o mașină de înaltă performanță, ale cărei capacități sunt direct proporționale cu numărul de echipamente pe care trebuie să le administreze. Spre exemplu, procesorul unui controler poate avea până la opt nuclee la frecvența de 2 GHz, în comparație cu cel al unui dispozitiv de comutare obișnuit de 1 GHz cu un singur nucleu.

Aplicațiile SDN sunt construite la un nivel superior controlerului. Interfețele dintre aplicațiile SDN și controler sunt folosite pentru a stabili fluxuri proactive pe echipamente și pentru a primi pachete care au fost direcționate către controler. Fluxurile proactive sunt stabilite de aplicații. Tipic, aplicațiile stabilesc aceste fluxuri când acestea pornesc și continuă până când apar schimbări de configurare. Acest tip de flux este cunoscut sub numele de flux static. Un alt tip ar fi acela în care controlerul decide să modifice fluxul datorită încărcării din rețea.

Suplimentar față de fluxurile definite proactiv de către aplicație, unele fluxuri sunt definite ca răspuns al unui pachet trimis către controler. La primirea unui pachet ce a fost direcționat către controler, aplicația SDN îl va instrui cum să răspundă și, dacă este necesar, va stabili un nou flux astfel încât dispozitivul va ști cum să reacționeze în momentul primirii unui pachet similar. Acest tip de flux este numit reactiv. În acest fel este posibilă scrierea de aplicații care implementează, printre altele, funcții de direcționare, rutare, controlul accesului. De asemenea, există fluxuri reactive care sunt definite sau modificate ca rezultat al unui eveniment neprevăzut ca, de exemplu, detecția unui atac asupra rețelei.

Pentru exemplificare, vom considera cazul unei rețele formată din patru dispozitive de comutare. Diferite servere sunt conectate la fiecare switch și diferite părți ale unei aplicații date operează pe aceste servere. Switch-urile au fost conectate pentru a avea conexiuni fiecare cu fiecare. În figura 2.4 este reprezentată această topologie:

Figura 2.4 Rețea tradițională de servere

În rețelele tradiționale, switch-urile schimbă automat informații și, prin folosirea algoritmului Spanning Tree, ar descoperi că această rețea prezintă riscul unor bucle infinite. Majoritatea porturilor de rețea vor fi puse în stare de blocare pentru ca apariția unor bucle infinite să fie evitată.

Totuși, într-o rețea SDN, modul de operare va fi total diferit. Astfel, controlerul SDN, amplasat în partea dreaptă a figurii 2.4, va fi responsabil de provizionarea switch-urilor cu toate datele necesare populării tabelelor de direcționare. Aplicației, fără a cunoaște detaliile de implementare și arhitectură ale rețelei, îi va fi permis să comunice cu diferitele baze de date de care are nevoie cu ajutorul controlerului SDN. Ceea ce este definit defapt în controler este fluxul de date al aplicației.

Controlerul SDN actualizează tabelele fiecărui switch din rețea cu datele fluxului necesar aplicației folosind protocolul OpenFlow. Figura 2.5 prezintă cazul migrării unei aplicații pe mai multe servere din rețea. Când aceasta are loc, controlerul SDN este informat și, la rândul lui, va actualiza tabelele fiecărui switch astfel încât baza de date și aplicația să poată comunica.

Figura 2.5 Migrarea aplicației în mediul SDN

În această configurație, aplicațiile prezintă abilitatea de a interacționa direct cu controlerul SDN. De asemenea, apar momente în care aplicația este oprită sau nu mai are nevoie de toată lățimea de bandă ce îi era rezervată. Atunci când controlerul SDN primește aceste tipuri de notificări, acesta va actualiza din nou tabelele fiecărui switch astfel încât comportamentul solicitat al rețelei să fie implementat.

3. Protocolul OpenFlow

3.1 Specificații generale

Protocolul OpenFlow structurează comunicația dintre planul de control și cel de date al dispozitivelor din rețea. OpenFlow permite unei aplicații externe să aibă acces la planul de direcționare al unui switch sau router. Protocolul definește mesajele specifice și formatul acestora, schimbate între controler ( planul de control) și echipamente ( planul de date).

Atunci când protocolul OpenFlow este implementat, acesta este activat de ambele părți ale interfeței dintre dispozitivele de rețea și controlerul SDN. Pentru a identifica și direcționa traficul în rețea, OpenFlow folosește conceptul de flux bazat pe niște reguli predefinite ce pot fi programate de către controler. Acest protocol permite inginerilor de rețea să definească modul în care traficul trebuie să traverseze rețeaua pe baza unor parametri cum ar fi tipul aplicației, resursele utilizate. OpenFlow permite rețelei să fie programată la nivel de flux. Aceasta înseamnă că arhitectura SDN bazată pe OpenFlow poate oferi un control detaliat, permițând controlerului să răspundă schimbărilor în timp real la nivel de aplicație, utilizator sau sesiune. În rețelele actuale, rutarea bazată pe procolul IP nu poate oferi acest nivel de control deoarece toate fluxurile între două puncte terminale trebuie să urmeze același traseu prin rețea, indiferent de cerințele acestora.

Protocolul OpenFlow a fost creat pentru a permite definirea rețelelor prin software și este singurul protocol SDN standardizat ce permite manipularea directă a planului de direcționare al dispozitivelor de rețea. OpenFlow a fost inițial aplicat în rețelele Ethernet, dar acesta poate fi extins unui număr mult mai mare de utilizări. Soluția SDN bazată pe OpenFlow poate fi implementată și în rețelele actuale, fizice sau virtuale. Echipamentele de rețea pot suporta simultan atât direcționarea pe baza protocolului OpenFlow, cât și cea tradițională. Aceasta înseamnă că este facil pentru companii și furnizorii de servicii să introducă progresiv tehnologiile SDN bazate pe OpenFlow.

Organizația OpenNetworkFoundation a fost concepută cu scopul de a promova adoptarea SDN. ONF administrează standardul OpenFlow. Versiunea 1.1 a protocolului a fost realizată în data de 28.02.2011. Versiunea următoare a fost publicată în luna decembrie 2011. Versiunea actuală 1.4 a fost realizată în 15.10.2013.

3.2 Switch-ul OpenFlow

Protocolul OpenFlow identifică cerințele pe care switch-ul trebuie să le îndeplinească. Un switch de tip OpenFlow conține trei componente principale: canalul OpenFlow, o tabelă de grup și una sau mai multe tabele de flux. Aceste tabele sunt responsabile pentru căutarea și direcționarea pachetelor. Canalul OpenFlow este utilizat pentru comunicația cu controlerul extern. Acest controler utilizează protocolul OpenFlow pentru a administra unul sau mai multe switch-uri.

După cum se poate vedea în figura 3.1, funcția principală a unui switch este de a prelua pachetele care ajung pe un port ( calea X pe portul 2) și de a le direcționa către un alt port ( în figură, portul N), realizând toate modificările necesare asupra pachetului. Un aspect unic al switch-ului OpenFlow se regăsește în funcția de potrivire a pachetelor. Aceasta este strâns legată de tabela de flux (tabelul 3.1) și de blocul de acțiuni. Acest bloc conține trei opțiuni de tratare a pachetului primit:

Direcționarea pachetului către un port de ieșire, modificând mai întâi un antet al acestuia;

Aruncarea pachetului;

Trimiterea pachetului către controler.

Aceste trei moduri fundamentale sunt ilustrate în figura 3.1. În cazul căii C, pachetul este trimis către controler prin canalul securizat OpenFlow. În cazul în care controlerul are un mesaj de control sau un pachet de date de trimis către switch, acesta va folosi același canal securizat, dar în sens invers. Când controlerul dorește să trimită un pachet de date către switch, acesta va folosi un mesaj OpenFlow de tip PACKET_OUT. Un pachet venit de la controler poate urma două căi diferite prin logica OpenFlow, ambele notate cu Y. În cazul cel mai avantajos, controlerul specifică direct portul de ieșire, iar pachetul este trimis către acesta.

Figura 3.1 Switch-ul OpenFlow

Într-un switch OpenFlow, pachetele Ethernet care îi sunt adresate și anteturile acestora sunt comparate cu datele care sunt stocate în tabela de flux a acestuia. Dacă este găsită o identitate între conținutul antetului și o intrare din tabelă, atunci un anumit set de instrucțiuni este executat. Orice linie din tabela de flux a unui switch conține trei informații importante: datele ce sunt folosite pentru a identifica pachetele recepționate, contori care numără realizările procesului de identitate și instrucțiunile care vor fi executate dacă identitatea este îndeplinită.

Tabelul 3.1 Tabela de flux a unui switch OpenFlow

Următoarele câmpuri asociate unui pachet pot fi folosite în procesul de identitate cu o intrare în tabela:

portul de intrare al switch-ului;

identificatorul rețelei locale virtuale (VLAN ID);

prioritatea rețelei locale virtuale;

adresa sursă Ethernet;

adresa destinație Ethernet;

tipul cadrului Ethernet;

adresa IP sursă;

adresa IP destinație;

protocolul IP;

biții pentru tipul de serviciu din antetul IP;

portul TCP/UDP sursă;

portul TCP/UDP destinație.

Intrările din tabela de flux sunt procesate în ordine, iar când o identitate este găsită, nu va mai fi făcută nicio altă încercare de găsire a identității. Din acest motiv, este posibil ca multiple intrări în tabela de flux să provoace o identitate, dar doar prima dintre acestea va fi semnificativă, următoarele nefiind găsite.

Există trei niveluri de conformitate ale celor 12 câmpuri. Primul este conformitatea totală în care identitatea trebuie să se producă pentru toate cele 12 câmpuri. Cel de-al doilea reprezintă conformitatea la nivel doi, în care doar câmpurile de nivel doi (adresă sursă/destinație Ethernet) trebuie să respecte identitatea. Al treilea este conformitatea de nivel trei, în care toate câmpurile de nivel trei (adresă sursă/destinație IP) să respecte identitatea.

Căutarea identității unui câmp din pachet se face începând cu prima tabelă de flux și se continuă până la găsirea ei sau până când un eveniment de tip „ lipsă tabelă” are loc. Ceea ce se întâmplă după ce un eveniment „ lipsă tabelă” are loc depinde de modul în care este configurat switch-ul, printre opțiuni fiind aruncarea pachetelui, trimiterea către controler pe canalul OpenFlow pentru procesări suplimentare sau încercarea găsirii unei identități în tabela de flux următoare.

Porturile sunt o parte critică a protocolului OpenFlow deoarece acestea specifică de unde vin pachetele și unde vor fi trimise. Atunci când două switch-uri se conectează, aceasta se realizează prin intermediul porturilor. Un switch OpenFlow conține trei tipuri de porturi: fizice, logice și rezervate; fiecare având un comportament diferit. Oricare din aceste porturi pot fi folosite atât ca intrare, cât și ca ieșire pentru un pachet. Porturile fizice corespund unei interfețe fizice a dispozitivului de comutare. Porturile logice sunt mapate pe cele fizice. Când un pachet este procesat de către un switch OpenFlow, atât porturile logice, cât și cele fizice sunt tratate la fel. Porturile rezervate sunt porturi speciale care sunt utilizate ca acțiune specificată să aibă loc. Această acțiune este declanșată de un pachet către un port rezervat.

Există cinci porturi virtuale speciale definit în OpenFlow ce au semnificații deosebite în privința acțiunilor ce vor fi întreprinse. Acestea sunt: LOCAL, ALL, CONTROLLER, IN_PORT și TABLE. În figura 3.2 sunt reprezentate transferurile pachetelor rezultate în urma atribuirii acestor porturi virtuale.

Figura 3.2 Căile pachetelor corespunzătoare porturilor virtuale[2]

LOCAL comandă ca pachetul să fie trimis către soft-ul de control al switch-ului. LOCAL este utilizat când mesajele OpenFlow de la controler sunt recepționate pe un port ce primește pachete comutate de planul de date. LOCAL indică faptul că pachetele trebuie să fie procesate de programul de control OpenFlow local.

ALL este utilizat pentru a trimite pachetele către toate porturile cu excepția celui de intrare. Acesta oferă capabilități rudimentare de difuzare switch-ului. CONTROLLER indică faptul că switch-ul trebuie să trimită pachetul către controler.

IN_PORT instruiește switch-ul să direcționeze pachetul înapoi pe portul pe care l-a primit. În mod normal, aceasta ar crea o buclă ce poate fi utilă în unele situații. Una din acestea ar fi în cazul unui port fără fir 802.11, unde este destul de normal să se recepționeze un pachet pe acel port de la un utilizator și să fie transmis pe același port către altul.

Portul virtual TABLE se aplică doar pachetelor trimise de controler către switch. Aceste pachete ajung ca o parte a unui mesaj PACKET_OUT, ce include și o listă de acțiuni. Aceste acțiuni conțin în general portul pe care pachetul trebuie direcționat. Controlerul poate specifica direct portul de ieșire pentru acel pachet sau, dacă dorește ca portul să fie determinat de linia de procesare OpenFlow, va stipula TABLE ca port de ieșire.

Mai există alte două tipuri de opțiuni: de punere în coadă sau de modificare a unui câmp. Acțiunea de punere în coadă selectează o coadă aparținând unui anumit port. Aceasta este folosită pentru a realiza nivelul dorit de calitate a serviciilor prin intermediul cozilor cu diferite priorități. Acțiunea de modificare informează switch-ul cum să schimbe un anumit câmp din antetul pachetului.

Atunci când există multiple acțiuni asociate unei intrări din tabelă, acestea sunt puse într-o listă de acțiuni. Switch-ul trebuie să execute acele acțiuni în ordinea în care acestea apar în listă.

Pentru mulți ani, switch-uri cu o complexitate mare au fost utilizate pentru a suporta multiple cozi pe porturile fizice. Aceste cozi sunt în general folosite de algoritmii ce permit provizionarea diferitelor niveluri de calitate a serviciilor (QoS) pentru diferite tipuri de pachete. OpenFlow adoptă acest concept și permite ca un flux să fie mapat către o coadă predefinită a unui port de ieșire.

Odată cu modificările în rețea, tabelele de flux ale switch-ului OpenFlow trebuie să fie actualizate. Această sarcină revine controlerului extern la care este conectat switch-ul. De asemenea, eliminarea unei rute poate avea loc la cererea controlerului, în momentul expirării unui contor sau la intervenția unui mecanism de înlăturare. Mecanismul de urmărire a expirării intrării din tabela de flux poate lucra în două moduri, în funcție de configurarea switch-ului. Un timer descrescător contorizează secundele asociate unui flux care, odată ajuns la zero, va elimina acea intrare. Alternativ, un al doilea tip de contor poate fi asociat unui flux. Dacă acest timer are a valoare diferită de zero și dacă procesul de potrivire nu se finalizează până când acesta ajunge la zero, fluxul va fi eliminat. Eliminarea fluxurilor de către controlerul extern se realizează prin trimiterea unui mesaj de excludere către switch. Dacă dispozitivul de comutare OpenFlow este suprasolicitat, acesta poate cere eliminarea unuia sau mai multor fluxuri. Controlerul poate configura switch-ul să îl notifice în legătură cu excluderea unei intrări din tabelă. Orice mesaj de eliminare a unei rute conține următoarele informații:

Descriere completă a intrării din tabelă;

Motivul eliminării ( expirare contor, ștergere sau evitarea congestiei );

Perioada petrecută în tabela de flux;

Statistica rutei până la momentul eliminării.

Un switch poate fi implementat atât OpenFlow-exclusiv, cât și OpenFlow-hibrid. Un switch OpenFlow direcționează pachetele în concordanță cu logica descrisă anterior, iar cel hibrid poate expedia pachetele și în modul actual, acela de switch Ethernet sau router IP. Un asemenea dispozitiv de comutare necesită un mecanism de preprocesare ce direcționează pachetele către partea de procesare OpenFlow sau către modelul tradițional. Utilizarea acestui mod hibrid de funcționare va fi frecvent folosită pe timpul migrației către implementarea OpenFlow-exclusiv.

În SDN, pentru ca un pachet să ajungă de la sursă la destinație, este necesar ca antetul său să fie modificat de către switch-urile OpenFlow prin care trece. Modul în care un dispozitiv determină cum să modifice un pachet se bazează pe instrucțiunile pe care acesta trebuie să le execute. Dacă un switch se află în imposibilitatea de a executa o instrucțiune asociată intrării în tabela de flux, atunci acesta va elimina intrarea respectivă și va returna un mesaj de eroare de tip UNSUPPORTED_FLOW.

3.3 Canalul OpenFlow

Un switch OpenFlow se conectează cu un controler extern prin intermediul unui canal OpenFlow. Acesta reprezintă interfața prin intermediul căreia controlerul configurează și administrează switch-ul, primește notificări și expediază pachete către switch. Legătura stabilită este securizată de obicei printr-o criptare asimetrică TLS, cu toate că se poate folosi și o conexiune TCP nesecurizată.

Protocolul OpenFlow suportă următoarele trei tipuri de mesaje pentru schimbul de informații ce are loc între switch și controler:

Controler către switch;

Asincron;

Simetric.

Mesajele controler către switch sunt utilizate pentru a administra sau verifica starea switch-ului și sunt inițiate de către controler. Există șapte tipuri de astfel de mesaje, iar acestea pot solicita sau nu un răspuns din partea dispozitivului de comutare. Mesajele asincrone sunt utilizate pentru a înștiința controlerul în legătură cu anumite evenimente din rețea și sunt inițiate de către switch. Mesajele simetrice sunt trimise fără o cerere în prealabil și pot fi expediate atât de switch, cât și de controler. În protocolul OpenFlow sunt definite patru tipuri de mesaje de acest fel.

Orice mesaj dintre switch și controler va începe cu antetul OpenFlow. Acesta specifică versiunea OpenFlow utilizată, tipul și lungimea mesajului, precum și identificatorul tranzacției mesajului. În tabelul 3.2 sunt prezentate tipurile de mesaje existente în protocolul OpenFlow versiunea 1:

Tabelul 3.2 Tipurile de mesaje OpenFlow 1.0

În figura 3.3 sunt prezentate cele mai importante mesaje utilizate în faza de inițializare, operare și, respectiv, monitorizare. În general, fazele de operare și monitorizare se suprapun. Mesajele de tip HELLO sunt schimbate după ce canalul securizat este stabilit pentru a determina versiunea cea mai bună de OpenFlow ce este suportată de switch. Mesajele de tip ECHO sunt utilizate de ambele părți pe perioada conexiunii pentru a determina dacă aceasta încă funcționează și pentru a măsura latența și lățimea de bandă a canalului. Mesajele VENDOR sunt valabile pentru experimentele furnizorilor de echipamente și pentru viitoare îmbunătățiri.

Când un dispozitiv de comutare recepționează un mesaj de la controler, acesta îl va procesa și, în funcție de tipul acestuia, va genera un răspuns. Un mesaj de eroare va fi trimis în cazul în care switch-ul nu poate procesa complet mesajul. Este important ca perspectiva controlerului asupra stării dispozitivelor de comutare să fie identică cu realitatea.

Mesajele de tip PACKET_IN reprezintă modul în care pachetele de date sunt trimise către controler pentru prelucrare. Traficul planului de control va fi trimis înapoi controlerului prin intermediul acestui mesaj. Switch-ul poate informa controlerul că o intrare în tabela de flux a fost ștearsă prin intermediul mesajului FLOW_REMOVED. PORT_STATUS este utilizat pentru a schimbări în ceea ce privește starea unui port, fie prin intervenția directă a unui utilizator, fie prin schimbarea mediului de comunicație. Mesajele de tip ERROR sunt necesara pentru a notifica planul de control în legătură cu unele probleme neprevăzute apărute.

Mesajele controler către switch sunt o categorie de mesaje de difuzare. După cum se poate observa și în tabelul 3.2, acestea pot fi împărțite în cinci subcategorii: configurarea switch-ului, comandă de la controler, statistici, configurarea cozilor și limitări. Mesajele de configurare a unui switch constau dintr-un mesaj unidirecțional și două perechi de mesaje de tip cerere-răspuns. Controlerul utilizează mesajul unidirecțional SET_CONFIG pentru a seta parametrii switch-ului. În figura 3.3 putem vedea mesajul SET_CONFIG transmis în faza de inițializare a legăturii dintre controler și switch. Controlerul folosește perechea de mesaje FEATURES pentru a interoga switch în legătură cu ce caracteristici suportă. Similar, perechea de mesaje GET_CONFIG este utilizată pentru a reface setările de configurație ale switch-ului.

Există trei mesaje ce sunt include în categoria comenzilor de la controler. PACKET_OUT este analogul mesajului PACKET_IN menționat anterior. Controlerul folosește PACKET_OUT pentru a trimite pachete de date către switch în vederea direcționării prin planul de date. Controlerul modifică intrările în tabela de flux printr-un mesaj de tip FLOW_MOD, în timp ce PORT_MOD este utilizat pentru a schimba starea unui port.

Figura 3.3 Sesiunea OpenFlow controler-switch[3]

Statisticile sunt obținute de la switch-uri prin intermediul perechii de mesaje STATS. Perechea BARRIER este utilizată de controler pentru a se asigura că o anumită comandă a putut fi finalizată de către switch. Acesta trebuie să termine de executat toate comenzile primite anterior BARRIER_REQUEST înainte de a efectua altele, recepționate după acesta, iar switch-ul trebuie să notifice controlerul în legătură cu finalizarea lor printr-un mesaj de tip BARRIER_REPLY.

Perechea QUEUE_GET_CONFIG_REQUEST și QUEUE_GET_CONFIG_REPLY este un mecanism prin care controlerul învață de la switch-uri cum o anumită coadă este configurată. Cu această informație, controlerul poate mapa într-un mod inteligent anumite fluxuri către anumite cozi pentru a se atinge nivelurile de calitate a serviciilor dorite.

Versiunea 1.1 a OpenFlow a fost realizată în februarie 2011 și introduce capabilități precum: multiple tabele de flux, grupuri, suport pentru etichetarea MPLS și VLAN, porturi virtuale, modul de avarie a conexiunii cu controlerul. Versiunea 1.2 a adus suport pentru IPv6, utilizarea mai multor controlere, comportament simplificat pentru cererile de tip FLOW_MOD. OpenFlow 1.3 a fost realizat în aprilie 2012 și reprezintă un salt major. Acesta introduce funcții precum: suport mult mai flexibil pentru evenimentele de tip lipsă tabelă, extensii pentru antetele IPv6, statistici pentru fiecare flux, conexiuni auxiliare cu controlerul, filtrare după conexiuni. Versiunea 1.4 aduce capabilități precum sincronizarea tabelelor de flux, proprietăți pentru porturile optice, monitorizarea fluxurilor, protocol pe fir mult mai elastic, descrieri mai amănunțite pentru mesajele de tip PACKET_IN.

În general, un singur controler va comunica cu mai multe switch-uri utilizând canale OpenFlow. Un singur switch poate avea fie o singură legătură cu un controler, fie multiple legături cu diferite controlere pentru siguranță.

Un controler OpenFlow este localizat în general la distanță și folosește una sau mai multe rețele pentru a se conecta cu un dispozitiv de comutare. Singura cerință pentru rețeaua dintre cele două dispozitive este suportarea TCP/IP. Rețeaua folosită poate fi una dedicată, partajată sau chiar cea a switch-ului respectiv.

În vederea stabilirii conexiunii dintre controler și switch, responsabilitatea revine acestuia din urmă. Portul utilizat pentru aceasta poate fi configurat de către utilizator, dar cu o adresă IP fixă. Dacă switch-ul a fost configurat cu o adresă IP, atunci acesta va iniția o conexiune TLS, așa cum se vede în figura 3.4, sau TCP cu controlerul. Traficul de pe canalul OpenFlow nu va fi niciodată introdus în coada de procesare a pachetelor. Aceasta înseamnă că dispozitivul de comutare va trebui să identifice acest trafic ca fiind local.

Un switch poate detecta pierderea legăturii cu controlerul când constată expirarea contorului „cerere ecou” ( echo request time-out ) sau a sesiunii TLS. Când aceasta are loc, switch-ul va intra imediat în modul de avarie securizat. În această funcționare, singura schimbare în comportamentul dispozitivului de comutare constă în aruncarea pachetelor destinate controlerului, iar rutele din tabela vor expira conform contorilor configurați.

Figura 3.4 Stabilirea unei conexiuni TLS

O metodă prin care controlerul și switch-ul vor comunica este prin utilizarea unei conexiuni TLS. Switch-ul inițiază această conexiune la pornire și este localizată pe portul TCP 6633. Pentru autentificare, certificate semnate cu chei private vor fi schimbate. Este necesar ca fiecare switch să fie configurat cu un certificat pentru autentificarea controlerului și un altul pentru cea a dispozitivului de comutare.

Metoda care utilizează conexiunea TCP în clar se inițiază, de asemenea, la pornirea switch-ului. Este recomandat ca, adiacent folosirii acestei conexiuni, să se utilizeze măsuri suplimentare de securitate pentru a preveni interceptarea mesajelor. Totuși, această implementare este utilă într-un mediu controlat cum ar fi un centru de date căci criptarea TLS necesită performanțe superioare și timpi de prelucrare mai mari.

3.4 Controlerul OpenFlow

Controlerul OpenFlow are sarcina de a menține în permanență o perspectivă asupra întregii rețele, implementează politici de direcționare, controlează dispozitivele de comutare și asigură o interfață de programare pentru aplicații ( API ).

În figura 3.5 este prezentată anatomia controlerului. Imaginea ilustrează modulele care oferă funcționalitățile de bază ale acestuia, atât pentru interfața nordică, cât și cea sudică, precum și câteva modele de aplicații. Interfața sudică este utilizată pentru conexiunea cu dispozitivele de comutare și este standardizată. În schimb, interfața nordică nu este încă standardizată, aceasta reprezetând o deficiență a SDN, dar care va fi soluționată. Această interfață reprezintă o oportunitate remarcabilă pentru inovație și pentru colaborarea între diferiți furnizori de echipamente.

Figura 3.5 Anatomia controlerului

Controlerul abstractizează detaliile protocolului dintre acesta și dispozitivele de comutare astfel încât aplicațiile au posibilitatea de a comunica direct cu acestea din urmă. Caracteristicele de bază ale controlerului includ:

Descoperirea dispozitivelor utilizatorilor ( calculator, laptop, imprimantă, telefon, tabletă );

Descoperirea dispozitivelor de rețea ( switch-uri, routere, puncte de acces );

Administrarea topologiei ( menținerea informațiilor referitoare la detaliile de interconectare dintre dispozitive );

Administrarea fluxurilor ( menținerea unei baze de date a fluxurilor gestionate de controler și efectuarea coordonării necesare sincronizării cu tabelele de rutare ale dispozitivelor ).

În comparație cu echipamentele de rețea actuale, planul de control OpenFlow diferă prin trei moduri esențiale. Primul constă în faptul că acesta poate programa diferite elemente ale planului de date printr-un limbaj standard. Cel de-al doilea rezidă din separarea fizică a planului de date de cel de control. Această separare este posibilă deoarece controlerul poate programa elementele planului de date de la distanță, peste Internet. Iar cel de-al treilea constă în posibilitatea programării a multiple elemente de rețea dintr-o singură instanță a planului de control.

Pentru aplicațiile SDN, o funcție importantă furnizată de controler o reprezintă interfața de aplicație pentru accesarea rețelei. În unele cazuri, interfața nordică este una de nivel scăzut, asigurând accesul la dispozitivele de rețea într-o manieră comună și consistentă. Astfel, aplicațiile sunt conștiente de echipamentele individuale dar sunt protejate de diferențele dintre ele. În alte cazuri, controlerul poate furniza o interfață la nivel înalt ce vor abstractiza întreaga rețea, așa că dezvoltatorii de aplicații nu trebuie să fie preocupați în legătură cu fiecare dispozitiv individual, ci cu rețeaua ca un întreg.

Figura 3.6 Interfața nordică a controlerului

În figura 3.6 este prezentată comunicarea dintre controler și o aplicație SDN. Acesta înștiințează aplicația cu evenimentele ce au loc în rețea. Evenimentele pot fi cauzate de un pachet ce a fost recepționat de către controler sau de schimbarea unei stări în topologia rețelei, cum este cazul întreruperii unei legături între două echipamente. Aplicațiile folosesc diferite metode pentru a influența modul de operare al rețelei. Aceste metode pot fi invocate ca răspuns la un eveniment și pot face ca un pachet recepționat să fie aruncat, modificat, direcționat către un port sau ca un flux să fie adăugat, eliminat sau modificat. Aplicațiile pot invoca metode și independent, fără stimulul unui eveniment de la controler.

Protocolul OpenFlow suportă trei moduri diferite pentru controlerele ce sunt conectate la switch-uri. Aceste roluri sunt:

EQUAL

SLAVE

MASTER

Figura 3.7 Modurile controlerului OpenFlow

Figura 3.7 prezintă patru scenarii pentru conectarea unuia sau mai multor controlere la un switch OpenFlow. În primul scenariu, un singur controler se conectează la un switch și are rolul EQUAL. Când un controler se află în acest mod, el are acces complet la dispozitivul din planul de date și recepționează toate mesajele asincrone trimise de switch. Acest rol permite controlerului să trimită comenzi de tipul controler către switch în vederea modificării stării switch-ului.

În cel de-al doilea scenariu, două controlere în starea EQUAL sunt conectate la același switch. Switch-urile OpenFlow pot stabili o conexiune cu un singur controler sau cu mai multe în același timp. Dacă un switch are conexiuni cu mai multe controlere, atunci el este considerat a fi mult mai sigur și își poate continua funcționarea în modul OpenFlow dacă un controler sau conexiunea dintre cei doi pică. Atunci când este necesar un transfer între controlere, acesta va fi tratat de către controlere, fără ca switch-ul să fie implicat. Această funcționare prezintă doua avantaje: recuperarea rapidă în cazul unei avarii, balansarea încărcării controlerului.

În al treilea scenariu, un singur switch este conectat la trei controlere: două în modul EQUAL și unul în modul SLAVE. Un controler are abilitatea de a cere ca rolul sau să fie schimbat. O modalitate de a face acest lucru este prin a solicita ca modul său să fie schimbat în SLAVE. Acest rol permite controlerului să aibă doar acces de citire asupra switch-ului. În acest mod, controlerul nu recepționează mesajele asincrone, în afară de cele legate de starea porturilor. Controlerului nu ii este permis să execute comenzile controler către switch de a trimite pachete sau de a modifica starea unui switch.

Ultimul scenariu prezintă cazul unui switch cu un controler EQUAL, altul SLAVE, iar cel de-al treilea MASTER. Atunci când se află în modul MASTER, controlerul va avea acces complet la switch-ul OpenFlow. Diferența dintre acest modul și cel EQUAL constă în faptul că switch-ul se va asigura ca acel controler să fie unicul cu rolul MASTER. Switch-ului îi este interzis să schimbe starea unui controler.

Când un controler administrează un switch, performanțele canalului dintre ele devin un punct cheie. Pentru a evita unele probleme, protocolul OpenFlow permite stabilirea a multiple conexiuni auxiliare, adițional celei principale, după cum se poate observa în figura 3.8.

Figura 3.8 Conexiuni auxiliare între controler și switch

Fiecare conexiune suplimentară va trebuie să folosească aceeași adresă IP a controlerului ca și cea principală. Totuși, diferite protocoale de transport pot fi utilizate pe fiecare conexiune în parte. Aceste protocoale pot include: TLS, TCP, DTLS, UDP. Înainte de stabilirea conexiunilor auxiliare, switch-ul trebuie să realizeze conexiunea principală. Dacă se întâmplă ceva cu conexiunea principală și aceasta devine indisponibilă, atunci toate conexiunile suplimentare ce au fost stabilite trebuie să fie șterse imediat.

3.5 Aplicațiile SDN

Aplicațiile SDN rulează deasupra controlerului, interacționând cu rețeaua prin intermediul interfeței nordice de programare. Aplicațiile sunt responsabile pentru administrarea intrărilor de flux ce sunt programate în dispozitivele de rețea folosind interfața controlerului. Prin intermediul acestor interfețe aplicațiile pot configura fluxurile pentru a direcționa pachetele pe cea mai bună cale între două puncte, pot balansa încărcarea traficului pe mai multe căi, pot reacționa la schimbările din topologia rețelei cum ar fi întreruperea unei legături sau adăugarea unui nou dispozitiv și pot redirecționa traficul în vederea unor verificări, autentificări sau segregări.

Figura 3.9 Aplicațiile SDN

După cum se poate observa în figura 3.9, dintre aplicațiile standard putem aminti interfața grafică pentru administrarea controlerului, un switch ce pot învăța adresele MAC și un comutator pe baza adresei IP. Trebuie menționat faptul că și cea mai simplă implementare a unui switch de nivel doi nu se poate obține prin simpla împerechere a unui dispozitiv SDN cu un controler. Este necesară o logică suplimentară pentru a reacționa la noi adrese MAC detectate și pentru a actualiza tabele de direcționare în echipamentele planului de date ce sunt controlate în așa manieră încât să furnizeze conectivitate noilor adrese de-a lungul rețelei evitând buclele. Unul din beneficiile aduse de arhitectura SDN este faptul că deciziile de comutare pot fi controlate de o familie de aplicații ce prezintă capabilitatea de a comanda controlerul. În acest mod, puterea arhitecturii SDN poate fi mult extinsă. Alte aplicații ce sunt foarte potrivite acestei arhitecturi sunt cele de balansare a încărcării și de filtrare a traficului. Aplicații ca acestea au menirea să demonstreze perspectivele rețelelor definite prin software: capabilitatea de a realiza funcții complexe ce anterior se regăseau separate în fiecare dispozitive de rețea sau platforme și de a permite operarea într-un mediu deschis SDN.

Responsabilitatea principală a unei aplicații SDN este de a îndeplini funcțiile pentru care ea a fost proiectată. O dată ce controlerul a realizat inițializarea legăturilor cu dispozitivele planului de date și a comunicat topologia rețelei către aplicații, acestea își vor consuma cea mai mare parte a timpului pentru a răspunde evenimetelor din rețea. Funcționalitățile de bază ale aplicațiilor variază între ele, dar comportamentul lor este dictat de evenimentele venite de la controler sau de la intrările sistemelor de monitorizare a rețelei. Aplicația influențează rețeaua răspunzând la evenimente. Aplicațiile înregistrează precum un ascultător anumite evenimente, iar controlerul le va invoca metoda ori de câte ori acestea apar. Această apelare este completată de detalii adecvate referitoare la respectivul eveniment. Câteva exemple de tratare a evenimentelor de către aplicațiile SDN sunt descoperirea dispozitivelor utilizatorilor, descoperirea dispozitivelor de rețea, pachetele primite. În primele două cazuri, evenimentele sunt trimise către aplicații ca urmare a descoperirii respectivelor dispozitive. Evenimentele de primire a pachetelor sunt recepționate de către aplicații atunci când un pachet este recepționat de la un dispozitiv SDN ca urmare a unei intrări în tabela de flux ce prevedea ca acel echipament să direcționeze pachetul către controler sau din cauza faptului că nu există nicio tabelă de flux în acel dispozitiv.

Există multe moduri în care o aplicație SDN poate răspunde evenimentelor ce au fost recepționate de la controler. Există răspunsuri simple, cum ar fi descărcarea unui set de intrări de flux implicite către dispozitivele de rețea nou descoperite. Acest flux implicit sau static este același pentru fiecare clasă de echipamente de rețea descoperite și prin urmare aplicația va necesita un nivel de procesare scăzut. Există însă răspunsuri mult mai complexe ce necesită informații de stare preluate din alte părți în afara controlerului.

Înainte de construirea unei aplicații, trebuie avut în vedere un set de întrebări. Răspunzând acestor întrebări, dezvoltatorul va ști cum să construiască aplicația, incluzând interfețele de aplicație (API) ce îi sunt necesare, ce controler este cel mai potrivit pentru aplicație și ce specificații ale switch-urilor trebuiesc luate în considerare. Câteva din aceste întrebări sunt:

Care este natura de bază a aplicației? Va petrece cel mai mult timp pentru a reacționa pachetelor primite de la dispozitivele de comutare din rețea? Sau va seta anumite fluxuri proactiv și va răspunde doar schimbărilor din rețea ce necesită anumite reconfigurări?

Care este tipul și natura rețelei cu care aplicația va interacționa? Spre exemplu, o aplicație pentru a rețea de tip campus orientată spre controlul accesului va avea o proiectare diferită în comparație cu o altă aplicație ce implementează politice de prioritizare a diferitelor tipuri de trafic.

Care este implementarea controlerului în raport cu switch-urile pe care le administrează? Un controler ce este îndepărtat fizic de dispozitivele pe care le controlează nu va fi capabil să suporte o aplicație SDN a cărei natură este una reactivă deoarece se va înregistra o latență semnificativă datorată direcționării pachetelor către controler și recepționării răspunsurilor de la acesta.

Aplicația va lucra într-un mediu pur SDN sau va avea de-a face și cu dispozitive de comutare ce nu suportă SDN? În puține situații un dezvoltator va construi o aplicație SDN pornind de la zero. Tipic, este necesar să se utilizeze echipamentele existente în soluția propusă. Este important a înțelege dacă switch-urile existente pot fi actualizate pentru a suporta OpenFlow și dacă poate rula într-un mediu hibrid, suportând atât OpenFlow cât și modul de operare actual.

Răspunsurile referitoare la aceste întrebări vor ajuta dezvoltatorul să înțeleagă natura aplicației SDN. Dezvoltatorul va trebui să se decidă între cele două tipuri de aplicații SDN: reactiv sau proactiv.

În cazul unei aplicații reactive, comunicația dintre switch și controler va fi proporțională cu numărul de fluxuri noi introduse în rețea. Switch-urile vor avea un număr relativ mic de intrări în tabela de flux, din moment ce contorii sunt setați pentru o durată scurtă. Aceasta va rezulta în recepționarea frecventă de pachete pentru care nu se găsește nicio regulă de direcționare. În cadrul modelului reactiv, aceste pachete sunt încapsulate în mesaje de tip PACKET_IN și trimise către controler și de acolo către aplicație. Aceasta examinează pachetul și determină dispoziția sa. Rezultatul constă în programarea unei noi intrări de flux în switch, așa că, data viitoare când un astfel de pachete va fi recepționat, el va fi procesat local. Aplicația va programa de obicei mai multe switch-uri în același timp astfel că fiecare din acestea, de-a lungul căii către destinație, vor avea un set consistent de intrări pentru fluxul respectiv. Pachetul original va fi returnat către switch astfel că acesta îl va direcționa conform intrării de flux nou instalate. Aplicațiile reactive sunt notificate în mod asincron în legătură cu pachetele primite ce au fost trimise către controler de switch-urile OpenFlow. Exemple de astfel de aplicații sunt cele de filtrare a traficului ce trebuie să identifice și să proceseze noile fluxuri din rețea.

Pe de altă parte, aplicațiile SDN de tip proactiv sunt caracterizate de un număr mai mic de mesaje schimbate între planul de date și cel de control. Aceste aplicații setează switch-urile din rețea cu intrări de flux ce sunt adecvate pentru a putea procesa pachetele înainte ca acestea să ajungă. Evenimentele ce declanșează schimbări în configurațiile tabelei de flux ale switch-urilor pot proveni de la mecanisme ce sunt în afara sferei canalului dintre cele două planuri. Spre exemplu, un modul extern de monitorizare a traficului va genera un eveniment ce este recepționat de aplicația SDN care va adapta fluxurile din switch-uri în mod corespunzător. Aplicațiile proactive sunt de obicei utilizate pentru a administra și controla topologia rețelei. Exemple de astfel de aplicații includ noi alternative ai algoritmilor Spanning Tree și de direcționare pe mai multe căi.

Programarea reactivă poate fi mult mai vulnerabilă la întreruperea serviciilor în cazul în care conectivitatea cu controlerul este pierdută. Pentru modul proactiv, această pierdere are un impact mai puțin negativ dacă în modul de alertă se specifică faptul că operarea rețelei trebuie să continue.

4. Implementarea unei rețele SDN. Studiu de caz

4.1 Definirea unei rețele de tip SDN de laborator

În vederea aprofundării cunoștințelor legate de conceptul SDN am realizat o serie de aplicații ce vor rula peste o rețea definită în soft.

Simularea rețelei SDN este realizată în Mininet. Acesta este un emulator de rețea pe care pot rula host-uri, switch-uri și controlere. Mininet folosește virtualizarea pentru a face ca un singur sistem să arate ca o rețea completă, utilizând același nucleu, sistem și cod. Un host emulat prezintă același comportament ca unul real și poate rula orice program aflat în sistemul de bază Linux. Programul poate trimite pachete precum o interfață Ethernet reală, cu o anumită viteză și o anumită întârziere. Aceste pachete sunt apoi procesate de un dispozitiv asemenea unui switch sau a unui router. Host-urile, switch-urile, legăturile și controlerul sunt create utilizând software, în locul hardware-ului însă comportamentul acestora este similar. Este posibilă crearea unei rețele Mininet ce înlocuiește una fizică, dar și invers, folosind același cod și aceleași aplicații.

Motivele pentru care am ales acest emulator de rețea în comparație cu altele existente ( CloudSim, FPGA Emulation, Meridian, ICanCloud, GreenCloud și GroundSim) sunt:

rapiditatea – pornirea unei rețelei durează câteva secunde ceea ce înseamnă că procesul de funcționare-editare-depanare este unul rapid;

crearea unor topologii personalizate – rețele extinse, rețele pentru centre de date, rețele nucleu pentru furnizorii de servicii;

rularea unor programe reale – orice program ce poate rula în Linux, poate fi folosit și în Mininet, de la servere web la unelte de monitorizare a rețelelor;

posibilitatea rulării pe propriul laptop, pe un server sau pe o mașină virtuală;

dezvoltarea continuă – fiind un proiect deschis, codul sursă poate fi examinat, modificat sau îmbunătățit.

Totodată, Mininet prezintă și unele limitări cum ar fi rularea pe un singur sistem, cu resurse limitate, izolarea rețelei emulate de Internet, precum și imposibilitatea rulării pe legături de mare viteză, de ordinul sutelor de Gpbs.

Un instrument utilizat în implementarea și studiul rețelei este Wireshark. Acesta este un analizor al protocoalelor de rețea ce ne permite să vizualizăm rețeaua la un nivel foarte detaliat. În practică, Wireshark este utilizat pentru a rezolva probleme în rețea, pentru a analiza traficul, cât și pentru a dezvolta noi produse sau protocoale de comunicare. Acesta este un program ce poate sesiza structura diferitelor protocoale de rețea, existând posibilitatea vizualizării și analizării antetelor acestora.

Pentru a evalua performanțele rețelei și pentru a genera trafic am utilizat Iperf, o unealtă prin care se formează fluxuri de tip TCP sau UDP în vederea măsurării ratei maxime de transfer. Acesta permite utilizatorilor să seteze diferiți parametri ce pot fi folosiți pentru testarea și optimizarea rețelei. Funcționarea sa se bazează pe una client – server, putând fi folosit atât sensul unidirecțional, cât și cel bidirecțional. Pentru a testa capacitatea UDP, Iperf permite utilizatorului să specifice dimensiunea pachetelor și furnizează rezultatele în legătură cu rata de transfer și cu pierderile de pachete. Atunci când este utilizat pentru a testa capacitatea TCP, acesta măsoară rata de transfer a sarcinii utile.

Limbajul de programare prin care s-a definit topologia rețelei, modul de funcționare al controlerului, precum și aplicațiile ce vor rula peste acesta este Python. Am ales acest limbaj deoarece codul scris poate fi rulat pe orice mașină, este relativ ușor de înțeles, există o comunitate extinsă ce contribuie la adăugarea de noi module. Python a fost proiectat punându-se accent pe posibilitatea de citire ușoară a codului, iar sintaxa sa permite programatorilor să exprime concepte în mai puține linii de cod față de alte limbaje cum ar fi C++ sau Java. Acesta suportă multiple paradigme de programare, incluzând orientarea spre obiecte, programarea imperativă sau funcțională, precum și stiluri procedurale. Caracteristicile Python includ administrarea automată a memoriei și o gamă largă de librării.

Pentru a realiza simularea rețelei SDN a fost necesară instalarea unei mașini virtuale ce va emulua Mininet. O mașină virtuală este o implementare software a unui mașini ce execută programe ca și una fizică. O mașină virtuală operează pe baza unei arhitecturi computaționale, iar funcționarea sa implică software și hardware specializat. Arhitectura pe baza căreia a fost simulată rețeaua SDN este prezentă în figura 4.1. La nivelul hardware se regăsește propriul laptop cu specificațiile sale pe care rulează un sistem de operare Windows 7. Hypervisor-ul ales este Oracle VM VirtualBox deoarece este un produs de virtualizare puternic și singura soluție profesională ce poate fi folosită liber. La nivelul mașinii virtuale se regăsește Mininet, în care rulează rețeaua, controlerul și uneltele Wireshark și Iperf.

Figura 4.1 Arhitectura de virtualizare

Rețeaua simulată în Mininet are arhitectura reprezentată în figura 4.2. Aceasta conține un număr de zece dispozitive de comutare ce sunt conectate la un controler C1. De asemenea, în topologie se regăsesc patru clienți, două servere pe care vor rula două aplicații de tip HTTP și FTP și alte două stații considerate a fi în exteriorul rețelei. După cum se poate observa, fiecare din dispozitivele de comutare sunt prevăzute cu legături de siguranță, astfel în cazul întreruperii uneia dintre acestea, serviciul să nu fie întrerupt, ci comutat pe celălalt.

Figura 4.2 Topologia rețelei simulate

Codul Python în care este descrisă topologia rețelei este prezent în Anexa A. Atât host-urile, cât și switch-urile au adrese MAC alocate astfel încât controlerul va ști cui să i se adreseze și pe baza cărui câmp să se realizeze direcționarea pachetelor. În plus, switch-urile au asignat un port unic pe care vor comunica cu controlerul, în timp ce acesta va trimite comenzi, conform specificațiilor protocolului OpenFlow, pe portul 6633:

C1 = net.addController( 'C1', controller=RemoteController, ip='127.0.0.1', port=6633 )

S1 = net.addSwitch('S1', listenPort = 6673, mac='00:00:00:00:00:01')

Pentru adăugarea unui host topologiei se folosește funcția net.addHost() ce primește ca parametri numele stației, adresa MAC și adresa IP. Pentru a stabili o legătură între două dispozitive ale rețelei se utilizează funcția net.addLink() ce are ca parametrii echipamentele între care se realizează legătura, precum și interfețele implicate:

h2 = net.addHost('h2', mac='00:00:00:00:02:02', ip='10.3.0.8/8')

net.addLink(S1, S2, 1, 1)

Rulăm codul în Python pentru a deschide topologia și a porni dispozitivele din rețea ( figura 4.3 ). Se observă că nu a putut fi deschisă o conexiune cu controlerul pe portul 6633 deoarece acesta nu a fost pornit.

Figura 4.3 Deschiderea rețelei

Mininet asignează fiecărui element al rețelei câte un proces. În figura 4.4 se regăsesc informații cu privire la identificatorul procesului corespunzător fiecărui dispozitiv, nodurile rețelei, o parte din configurația de rețea a stațiilor, precum și interfețele implicate în funcționarea acesteia. De asemenea, se poate observa că dispozitivele de comutare din planul de date sunt de tipul OVS Switch. Acesta reprezintă o implementare de tip open-source a unui switch virtual multinivel. Principalul scop al unui astfel de switch este de a furniza o stivă de comutare pentru mediul de virtualizare hardware, suportând multiple protocoale și standarde utilizate în rețelele de calculatoare.

Figura 4.4 Informații referitoare la dispozitive

Oricare host poate fi identificat printr-o adresă MAC și o adresă IP, asignate anterior prin cod Python. Configurația de rețea pentru Client 1 este prezentă în figura 4.5. Putem vizualiza informații legate de adresa IP de difuzare a mesajelor, masca rețelei din care face parte stația, numărul de pachete transmise, recepționate și eventuale erori.

Figura 4.5 Configurația de rețea pentru Client 1

Legăturile stabilite între dispozitivele din rețea, precum și interfețele implicate sunt prezentate în figura 4.6. Toate aceste informații sunt utile în situații în care rețeaua nu funcționează conform așteptărilor, fiind necesare în momentul depanării acesteia.

Figura 4.6 Legăturile dintre dispozitive

Se încearcă verificarea unei conexiuni între doi clienți ai rețelei fără a fi deschis controlerul care să asigure această legătură ( figura 4.7 ):

Figura 4.7 Testare conectivitate fără controler

Legătura nu poate fi stabilită întrucât pachetul transmis de Client 1 va ajunge la primul switch care nu va ști cum să reacționeze deoarece în tabela sa de flux nu există nicio regulă de direcționare a traficului.

Dintre tipurile de controlere existente am ales POX deoarece acesta este o platformă pentru dezvoltarea și proiectarea rapidă a soft-urilor de control al rețelei. Acest controler este definit în Python și înglobează un număr mare de componente. De asemenea, am ales acest tip de controler deoarece a fost dezvoltat de același grup de cercetători ce au realizat și protocolul OpenFlow pe care se bazează întreaga funcționare a SDN.

Se deschide controlerul a cărui funcționare se va baza pe arhitectura din figura 4.8. Modulul l2_learning va stabili o regulă de direcționare a pachetelor de nivel doi (pe baza adresei MAC), ceea ce implică un comportament de switch al dispozitivelor din planul de date. Modulul discovery este utilizat pentru a descoperi topologia rețelei prin trimiterea de mesaje LLDP către switch-uri. Întrucât rețeaua conține mai multe bucle este necesară utilizarea unui modul suplimentar, spanning_tree, ce folosește mesajele trimise de modulul discovery pentru a crea un arbore și dezactivează porturile ce nu se află în acesta. În momentul în care o legătură a rețelei este dezactivată, modulul va calcula din nou arborele necesar evitării buclelor.

Figura 4.8 Arhitectura controlerului

În figura 4.9 sunt prezentate comanda introdusă pentru pornirea controlerului cu cele trei componente, confirmarea conectării și descoperirii dispozitivelor de comutare, a legăturilor dintre acestea, precum și calculării arborelui pentru evitarea buclelor.

Figura 4.9 Pornirea controlerului

La inițializarea controlerului, după cum se poate observa și în captura Wireshark din figura 4.10, au loc diferite schimburi de mesaje între acesta și dispozitivele de comutare, dintre care: OF_HELLO, OF_FEATURES_REQUEST, OF_STATS_REQUEST, OF_STATS_REPLY, OF_SET_CONFIG, OF_FLOW_DELETE, OF_FLOW_ADD, OF_FEATURES_REPLY, OF_BARRIER_REQUEST, OF_BARRIER_REPLY. După realizarea acestor conexiuni, la intervale de 10 secunde, se vor transmite mesaje de tip OF_ECHO_REQUEST, OF_ECHO_REPLY pentru testarea permanentă a conectivității cu dispozitivele din planul de date și pentru menținerea unei perspective clare asupra rețelei.

Figura 4.10 Mesaje schimbate la inițializarea controlerului

Se încearcă din nou testarea conectivității dintre cei doi clienți. După cum se poate observa în figura 4.11 aceasta funcționează corect. De asemenea este de remarcat faptul că prima încercare de conectare prezintă un timp semnificativ mai mare față de celelalte. Această întârziere este datorată faptului că mesajul primit de switch-ul S9 este trimis către controler printr-un mesaj de tip OF_PACHET_IN deoarece în tabela de flux a acestuia nu există nicio intrare pentru sursa și destinația respectivă.

Figura 4.11 Testarea conexiunii

Așa cum rezultă și din captura din figura 4.12, controlerul, având o imagine clară asupra rețelei, va răspunde cu un mesaj de tip OF_FLOW_ADD trimis atât switch-ului care a inițiat solicitarea, cât și celorlalte de pe traseul către destinație. Astfel nu va mai fi necesară interogarea controlerului de fiecare dată când pachetul ajunge într-un nou dispozitiv de comutare.

Figura 4.12 Schimbul de mesaje între switch și controler

4.2 Implementarea unor aplicații SDN

Unul din beneficiile aduse de Software Defined Networking îl reprezintă posibilitatea rulării unor aplicații peste controler și întreg planul de date. De aceea am realizat trei aplicații ce vor funcționa peste planul de control: un filtru ce impune diferite restricții de accesare, un modul de prioritizare a traficului și unul de colectare de statistici.

Un filtru este un sistem de securitate a rețelei ce este utilizat pentru a controla fluxurile de intrare sau de ieșire dintre o rețea securizată și una mai puțin securizat. Aplicația pe care am realizat-o își propune filtrarea traficului prin rețea, astfel încât cele două servere să nu poată fi accesate de stațiile din exterior, ci doar de cei 4 clienți ai rețelei. Codul complet corespunzător acestei aplicații este prezent în Anexa B.1, iar structura și politicile de filtrare se regăsesc în Anexa B.2. Noua arhitectură emulată după care va funcționa rețeaua este reprezentată în figura 4.13. Modulul Firewall va interacționa cu controlerul prin intermediul interfeței nordice, iar acesta va trimite mai departe comenzile către planul de date.

Figura 4.13 Arhitectura planului de control

Aplicația definește o nouă clasă Filtru care la inițializare va asculta evenimentele trimise de către core.openflow, o componentă ce administrează conexiunile cu toate dispozitivele de comutare și va inițializa o listă căreia îi va adăuga elementele din fișierul de filtrare politici-filtrare.csv.

self.listenTo(core.openflow)

self.policy = []

with open(policyFile, 'rb') as f:

Aplicația va analiza adresele MAC ale stațiilor ce au inițiat un eveniment în rețea, iar dacă acestea se găsesc în lista de filtrare, către echipamentele din planul de date se va trimite un mesaj de tip OF_FLOW_MOD în care nu se va specifica nicio regulă de direcționare a pachetelor corespunzătoare stațiilor.

for (src, dst) in self.policy:

match = of.ofp_match()

match.dl_src = src

match.dl_dst = dst

msg = of.ofp_flow_mod()

msg.match = match

event.connection.send(msg)

În figura 4.14 sunt prezentate comenzile introduse pentru a instala cele două servere HTTP, precum și portul TCP pe care acestea vor fi accesate. Dacă în primul caz, în care aplicația de filtrare nu este utilizată, serverele au putut fi accesate fără nicio restricție, recepționând un răspuns 200 OK, în cel de-al doilea caz, nu se mai primește nimic. Se observă că serverul nu a putut fi accesat datorită faptului că nu există nicio regulă de rutare a pachetelor către acesta.

Figura 4.14 Testare acces stații din exterior

Totodată, în figura 4.15, se testează conectivitatea dintre clienți și servere în condițiile în care aplicația de filtrare a traficului rulează, iar aceasta se încheie cu același răspuns: 200 OK.

Figura 4.15 Testare acces clienți

Așadar, o companie ce deține un centru de date și care dorește un sistem de securitate asupra propriilor servere sau chiar asupra unei părți a rețelei, poate implementa o astfel de aplicație de filtrare a traficului ce prezintă avantajul simplității.

A doua aplicație pe care am realizat-o își propune implementarea unor politici de prioritizare a traficului în rețea pentru anumiți clienți. Astfel, cei patru clienți vor fi împărțiți în două clase în funcție de lățimea de bandă alocată. Pentru aceasta, am adus anumite modificări modulului l2_learning:

msg = of.ofp_flow_mod()

msg.match = of.ofp_match.from_packet(packet, event.port)

msg.idle_timeout = 10

msg.hard_timeout = 30

if msg.match.dl_src == EthAddr("00:00:00:00:01:02") or msg.match.dl_src == EthAddr("00:00:00:00:01:04"):

msg.actions.append(of.ofp_action_enqueue(port = port,queue_id=1))

else:

msg.actions.append(of.ofp_action_output(port = port))

msg.data = event.ofp

self.connection.send(msg)

Astfel, mesajele a căror adresă MAC sursă corespunde clienților 2 sau 4 vor fi trimise către o coadă de așteptare, în timp ce restul clienților nu vor avea nicio restricție, mesajele lor fiind trimise direct către portul de ieșire. De asemenea, este necesară configurarea celor două dispozitive de comutare la care sunt atașați clienții astfel încât să suporte cele două tipuri de prelucrări a pachetelor. Prin comenzile din figura 4.16, celor două switch-uri li se trimit instrucțiuni de realizare a politicilor de QoS de tip linux-htb, ceea ce ne permite să controlăm lățimea de bandă a legăturilor de pe interfețele eth3, respectiv eth2.

Figura 4.16 Configurarea switch-urilor pentru a suporta QoS

Dacă inițial traficul nu avea nicio limitare, acum fiecare din cele două switch-uri va avea două cozi de așteptare, una în care traficul va trece fără nicio restricție (lățimea de bandă maximă de 1Gbit/s) și una în care banda se încadrează între 4 și 10 Mbit/s.

Pentru a testa funcționarea acestui nou modul se folosește utilitarul Iperf. În figura 4.17 sunt prezentate rezultatele obținute fără a utiliza modulul de prioritizare și limitare a traficului, în care clienții au la dispoziție toată lățimea de bandă.

Figura 4.17 Testare lățime de bandă fără modulul QoS

Rezultatele obținute pentru perechile de clienți sunt apropiate, micile diferențe fiind datorate încărcării diferite de pe hardware-ul folosit în momentul simulării. Se testează din nou lățimea de bandă pentru cazul în care aplicația de prioritizare a traficului de la clienți este activată. Performanțele obținute sunt prezente în figura 4.18. După cum se poate observa, pentru clienții C1 și C3 limitarea se datorează capabilităților hardware ale dispozitivului pe care este emulată rețeaua, în timp ce pentru clienții C2 și C4 limitarea se datorează aplicației de prioritizare și de limitare a traficului, viteza de transfer fiind inferioară celor 10 Mbit/s alocați.

Figura 4.18 Testare lățime de bandă cu modulul QoS activat

Prin urmare, o astfel de aplicație poate fi utilizată de un furnizor de servicii mobile sau fixe pentru a limita viteza de acces pentru anumiți clienți, în timp ce alții vor putea folosi o lățime de bandă mai mare. De asemenea, aplicația poate fi dezvoltată ulterior pentru a prioritiza un anumit tip de trafic, cum este cel de voce, în defavoarea celui de date.

Cea de-a treia aplicație pe care am realizat-o constă în colectarea de statistici ale traficului din rețea. Prin intermediul acesteia, se vor putea urmări valorile pentru diferite tipuri de trafic ce traversează rețeaua. Codul Python corespunzător acestui modul este prezent în Anexa C, iar arhitectura planului de control după care va funcționa întreaga rețea este prezentă în figura 4.19.

Figura 4.19 Arhitectura planului de control

Pentru fiecare conexiune stabilită între controler și dispozitivele din planul de date, aplicația va cere să îi fie transmise statisticile legate de fluxuri:

for connection in core.openflow._connections.values():

connection.send(of.ofp_stats_request(body=of.ofp_flow_stats_request()))

Se definește o funcție în care se specifică modul de a reacționa în momentul în care se recepționează un eveniment de tip FlowStatsReceived. Se inițializează trei dicționare pentru cele trei tipuri de trafic pentru care se realizează statistici, iar valorile pentru cele trei chei egale cu 0:

iperf = {'traffic': 0, 'packet': 0, 'flows': 0}

web = {'traffic': 0, 'packet': 0, 'flows': 0}

ftp = {'traffic': 0, 'packet': 0, 'flows': 0}

Așadar, pentru fiecare eveniment recepționat, se vizualizează portul TCP destinație sau sursă, iar dacă acesta coincide cu unul din porturile specificate ( 5001 pentru traficul generat de utilitarul Iperf, 80 pentru traficul HTTP, respectiv 21 pentru traficul FTP ) se vor incrementa câmpurile pentru trafic, pachete și fluxuri.

for f in event.stats:

if f.match.tp_dst == 5001 or f.match.tp_src == 5001:

iperf['traffic'] += f.byte_count

iperf['packet'] += f.packet_count

iperf['flows'] += 1

Toate aceste statistici vor fi scrise în fișiere cu extensia .csv pentru fiecare dispozitiv de comutare. Structura unui astfel de fișier este cea din figura 4.18.

os.chdir('/home/mininet/mininet/share/statistici')

csvFile = open('/home/mininet/mininet/share/statistici/S%s.csv' %event.connection.dpid, 'a')

columns = [str(time.strftime("%H:%M:%S")), iperf['traffic'], iperf['packet'], iperf['flows'], web['traffic'], web['packet'], web['flows'], ftp['traffic'], ftp['packet'], ftp['flows']]

for column in columns:

csvFile.write('%s;' %column)

csvFile.write('\n')

csvFile.close()

Figura 4.20 Statistici trafic generate

După cum se poate observa și în figura 4.20, toate aceste statistici sunt colectate la fiecare 2 secunde prin apelul funcției Timer() din biblioteca pox.lib.recoco:

def launch ():

core.openflow.addListenerByName("FlowStatsReceived", _handle_flowstats_received)

Timer(2, _timer_func, recurring=True)

Cu datele obținute se vor realiza diferite diagrame pentru a urmări funcționarea rețelei și încărcarea de pe echipamentele acesteia. Pentru a testa funcționarea corectă a acestui modul a fost necesară modificarea codului corespunzător topologiei:

print "***Starting network***"

net.start()

sleep(5)

print "Starting servers"

s1.sendCmd('python -m SimpleHTTPServer 80 &')

s2.sendCmd('python -m pyftpdlib -p 21 &')

sleep(3)

print "Accessing servers"

c1.sendCmd('wget -r -l 5 http://' +s1.IP()+'; iperf -s &')

c2.sendCmd('wget -r -l 5 ftp://'+s2.IP()+'; iperf -s &')

c3.sendCmd('wget -r -l 5 http://' +s1.IP()+'; iperf -s &')

c4.sendCmd('wget -r -l 5 ftp://' +s2.IP()+'; iperf -s &')

h1.sendCmd('iperf -c '+c1.IP()+' -t 120 -i 1; iperf -c '+c3.IP()+' -t 120 -i 1 &')

h2.sendCmd('iperf -c '+c2.IP()+' -t 120 -i 1; iperf -c '+c4.IP()+' -t 120 -i 1 &')

Se inițiază dispozitivele din planul de date, precum și controlerul, după care se așteaptă un interval de 5 secunde astfel încât controlerul să își calculeze arborele pentru evitarea buclelor. Prin intermediul funcției sendCmd() se trimit comenzile primite ca parametru de aceasta direct către echipamente de comutare. Astfel, Server 1 va deveni un server HTTP ce va fi accesat de către clienții 1 și 3, iar Server 2 va deveni un server FTP ce este accesat de clienții 2 și 4. De asemenea, stațiile exterioare, H1 și H2 vor rula iperf către clienții 1 și 3, respectiv 2 și 4.

Graficul corespunzător funcționării switch-urilor S9 și S10 ce conectează cei patru clienți la rețea conform codului descris anterior este reprezentat în figura 4.21.

Figura 4.21 Trafic rețea pentru switch-urile S9 și S10

După cum se poate observa, numărul de pachete pe flux pentru traficul generat de Iperf este mult mai mic față de celelalte două tipuri deoarece rețeaua își atinge foarte repede limitele impuse de configurația hardware pe care s-a realizat simularea. De asemenea, se observă că alura graficelor pentru tipurile de trafic sunt asemătoare pentru cele două dispozitive de comutare, așadar aplicația funcționează corect. Totodată, se remarcă faptul ca traficul este cel caracteristic unei conexiuni TCP, având perioade de creștere a dimensiunii pachetelor, urmate de perioade de scădere a traficului datorate absenței confirmării primitii pachetelor.

În continuare se realizează o comparație a numărului de pachete ce traversează fiecare echipament de comutare al rețelei. Pentru traficul HTTP, diagrama este reprezentată în figura 4.22.

Figura 4.22 Trafic HTTP în rețea

Așa cum se observă, traficul HTTP generat de clienți poate parcurge două mari căi: S9 – S3 – S2 – S8 și S10 – S6 – S1 – S8, în timp ce switch-urile S4, S5 și S7 nu sunt parcurse de niciun pachet.

De asemenea, se reprezintă valorile traficului de tip FTP în figura 4.23. Din punctul de vedere al încărcării de pe dispozitive, traficul prezintă aceeași formă precum în cazul HTTP, urmând cele două căi de transport a mesajelor, dar numărul pachetelor pe flux este unul mai mic. Se remarcă faptul că există perioade de creștere masivă a numărului de pachete, în care viteza de transmisie a fișierelor se mărește progresiv, urmate de momente în care rețeaua ajunge la limită și conexiunea cu serverul FTP nu se mai realizează.

Figura 4.23 Trafic FTP în rețea

Întrucât nici de această dată switch-urile S4, S5 și S7 nu sunt traversate de niciun flux, se simulează întreruperea unor legături cu ajutorul comenzilor:

mininet>link S3 S2 down

mininet>link S1 S6 down

Astfel, legătura dintre cele două echipamente de comutare este anulată și tot traficul generat pentru a accesa cele două servere va traversa și switch-urile care înainte nu erau traversate de pachete. Graficul traficului HTTP pentru acest tip de funcționare a rețelei este reprezentat în figura 4.24. În acest caz, traficul prin switch-ul S2 va fi nul, în timp ce switch-ul S7 va prelucra toate pachetele, fiind cel mai solicitat echipament al rețelei. Se poate remarca faptul că numărul pachetelor pe flux este mai mic în această configurație decât în precedenta datorită încărcării de pe switch-ul S7.

Figura 4.24 Trafic HTTP în rețeaua modificată

Așadar, o astfel de aplicație poate fi utilizată de orice companie ce dorește să monitorizeze propriile echipamente în vederea descoperirii unor eventuale puncte foarte încărcate în rețea ce ar putea cauza probleme și a căror defectare ar putea conduce la întreruperea serviciilor pe care compania le folosește. De asemenea, în cazul furnizorilor de servicii de telecomunicații, o asemenea aplicație poate fi utilizată în combinație cu cea de prioritizare a traficului pentru a urmări respectarea obligațiilor contractuale între aceștia și clienți.

Concluzii

Această lucrare a avut ca scop prezentarea conceptului Software Defined Networking, a protocolului pe care se bazează funcționarea sa, precum și implementarea unei rețele definite în software în emulatorul Mininet peste care au rulat trei aplicații de tip SDN.

Rețelele actuale de calculatoare sunt complexe și dificil de administrat. Unul din motive îl constituie faptul că planurile de control și de date sunt integrate fizic în același dispozitiv și sunt specifice fiecărui furnizor de echipamente. De asemenea, implementarea unui nou serviciu la nivelul întregii rețele presupune configurarea fiecărui echipament al acesteia pentru a suporta serviciul respectiv.

Software Defined Networking reprezintă o oportunitate pentru a rezolva toate aceste probleme. Câteva din ideile de bază ale acestui concept le reprezintă introducerea programabilității dinamice a dispozitivelor de comutare prin intermediul interfețelor deschise, decuplarea planurilor de control și de date, precum și menținerea unei perspective globale asupra întregii rețele. În timp ce elementele planului de date devin simple comutatoare, dar foarte eficiente și direct programabile, componentele planului de control vor fi reprezentate de o singură entitate, controlerul sau sistemul de operare al rețelei. Aplicațiile ce implementează logica de direcționare a pachetelor rulează peste controler și sunt mult mai simplu de dezvoltat în comparație cu rețelele tradiționale. Software Defined Networking prezintă o paradigmă majoră ce va schimba modul de dezvoltare și evoluție al rețelelor de calculatoare.

Lucrarea a prezentat exigențele la care sunt supuse rețelele de calculatoare și limitările pe care funcționarea acestora le prezintă, toate acestea conducând către un nou concept. De asemenea, lucrarea a descris modul de funcționare a conceptului SDN, protocolul pe care se bazează acesta, precum și componentele de bază ale acestei arhitecturi. Implementarea practică a presupus realizarea unei rețele definite în software, simularea acesteia și prezentarea modului de funcționare. Am realizat un set de trei aplicații de tip SDN ce au avut ca scop prezentarea beneficiilor pe care acest concept le aduce.

Aplicația de filtrare a traficului reprezintă o măsură de securitate pe care orice companie o poate utiliza în vederea protejării propriilor servere de către utilizatori neautorizați. Aceasta poate fi dezvoltată ulterior pentru o inspecție mai detaliată a pachetelor de intrare în rețea, cum ar fi identificatorul VLAN, adresa IP sau portul TCP. De exemplu, o astfel de aplicație poate fi utilizată pentru a permite doar accesul pe portul TCP 21 către un server de tip FTP, restul traficului fiind respins.

Implementarea politicilor de prioritizare și de restricționare a traficului reprezintă cea de-a doua aplicație prezentată în această lucrare. O astfel de aplicație își poate găsi foarte ușor utilitatea în cadrul unor furnizori de servicii de telecomunicații ce doresc să ofere clienților o lățime de bandă mai mare sau mai mică în funcție de tipul abonamentului. De asemenea, pentru același utilizator, aplicația poate fi dezvoltată pentru a prioritiza traficul de voce sau video în timp real, față de cel de date.

Aplicația de colectarea a statisticilor traficului reprezintă un modul pe care orice companie îl poate implementa în vederea monitorizării propriilor echipamente de comutare. O astfel de aplicație este utilă pentru a depista eventuale noduri supraîncărcate în vederea echilibrării traficului prin rețea. Aplicația poate fi dezvoltată pentru a realiza statistici pentru fiecare utilizator, pentru fiecare port al dispozitivelor de comutare sau chiar pentru fiecare aplicație ce utilizează rețeaua. În combinație cu aplicația de prioritizare a traficului, un furnizor de servicii de telecomunicații poate urmări respectarea obligațiilor contractuale dintre acesta și utilizatori.

Un alt aspect ce trebuie subliniat îl reprezintă simplitatea în funcționare și implementare pe care o aduce conceptul Software Defined Networking. Dacă în cazul rețelelor tradiționale implementarea politicilor de filtrare a traficului presupune configurarea mai multor liste de acces și atribuirea lor pe diferite interfețe ale echipamentelor de comutare sau, în unele cazuri, achiziționarea de dispozitive specializate în acest scop, în SDN toate acestea sunt realizate cu ajutorul unei aplicații cu câteva linii de cod. De asemenea, asigurarea unui anumit QoS utilizatorilor rețelei impune o configurare mult mai dificilă decât aplicația prezentată.

Sofware Defined Networking reprezintă unul din trendurile actuale din lumea IT alături de Network Functions Virtualization ( NFV ) și Internet of Things ( IoT ). NFV reprezintă un concept de arhitectură ce propune virtualizarea întregii clase de noduri ale unei rețelei. IoT este constituit din totalitatea obiectelor fizice ce sunt prevăzute cu un identificator unic și prezintă abilitatea de a transmite date printr-o rețea fără a necesita implicarea umană.

Network Functions Virtualization presupune implementarea funcțiilor de rețea ( HLR/HSS, MME, SGSN, RNC, Node B, eNode B ) într-un software ce poate rula pe orice server standard și care poate migra după necesități către diverse locații în rețea, fără a fi necesară instalarea unui echipament dedicat. NFV și SDN sunt două concepte complementare, dar nu total dependente. NFV, bazându-se pe separarea planurilor de date și de control propusă de SDN, își poate mări performanțele, simplifica problemele de compatibilitate cu implementările existente și poate facilita procedurile de operare și mentenanță. NFV este capabil să susțină SDN prin furnizarea infrastructurii pe care acesta va putea rula. De asemenea, Network Functions Virtualization se aliniază cu SDN din perpectiva utilizării unor dispozitive de comutare și a unor servere accesibile din punctul de vedere al costului.

SDN, prin capacitatea sa de a direcționa inteligent traficul și de a utiliza eficient resursele rețelei, va facilita prelucrarea uriașă a datelor ce o aduce Internet of Things. SDN va elimina blocajele și va asigura eficiență pentru a ajuta ca datele generate de dispozitivele IoT să fie procesate fără a pune o presiune mai mare asupra rețelelor. Dispozitivele IoT se vor răspândi în toate domeniile noastre de activitate, de la sănătate la agricultură și de la autoturisme la locuințe inteligente. De exemplu, proprietarul unei locuințe poate folosi aplicația de filtrare a traficului pentru a nu permite utilizatorilor externi să interacționeze cu dispozitivele IoT din aceasta.

Legat de realizările personale, aș putea enumera parcurgerea unor tutoriale pentru înțelegerea funcționării emulatorului Mininet, precum și participarea la un curs despre Software Defined Networking organizat în cadrul Facultății de Automatică și Calculatoare în colaborare cu Cisco România. În prezent sunt înscris la un curs online despre Software Defined Networking organizat de Coursera și Universitatea Princeton. De asemenea, pe parcursul acestui an am urmat cursul Orange Educational Programme – Engineering organizat de Orange România în cadrul facultății. Pe perioada ultimilor doi ani de studii mi-am aprofundat cunoștințele de rețelistică urmând cele patru module Cisco Certified Networking Associate, iar pe perioada verii îmi voi susține certificarea.

Ca dezvoltări ulterioare, mi-am propus realizarea unei balansări a încărcării pe legăturile dintre dispozitivele de comutare astfel încât rețeaua să fie echilibrată din acest punct de vedere. De asemenea, doresc introducerea unui modul grafic astfel încât și un utilizator mai puțin experimentat să poate folosi aceste aplicații. Voi continua dezvoltarea celor trei aplicații realizate pentru o filtrare și o prioritizare a traficului mai precise, urmând ca acestea să fie implementate pe unul din serverele din centrul de date al Orange România.

Bibliografie și referințe

[1] http://cleanslate.stanford.edu/ accesat la data: 02.06.2015

[2] Paul Goransson, Chuck Black, Software Defined Networks: A comprehensive aproach, Editura Morgan Kaufmann, 2014, pag. 90

[3] Paul Goransson, Chuck Black, Software Defined Networks: A comprehensive aproach, Editura Morgan Kaufmann, 2014, pag. 93

Thomas D. Nadeau, Ken Gray – Software Defined Networks , Editura Shroff, 2013

Paul Goransson, Chuck Black – Software Defined Networks: A comprehensive aproach, Editura Morgan Kaufmann, 2014

Patricia A. Morreale, James M. Anderson – Software Defined Networking: Design and Deployment, Editura CRC Press, 2014

Open Networking Foundation – Software-Defined Networking: The New Norm for Networks, 2012

http://mininet.org/ accesat la data de: 23.03.2015

Open Networking Foundation – OpenFlow Switch Specification v1.0, 2009

Veena S., Chandan Pal, Ram P. Rustagi, K. N. B. Murthy – A Framework for Implementing Realistic Custom Network Topology in Mininet, 2014

Kreutz Diego, Fernando Ramos, P. Verissimo, C. E. Rethenberg – Software-Defined Networking: A Comprehensive Servey, 2014

M. Kobayashi, S. Seetharaman, G. Parulkar – Maturing of OpenFlow and Software-defined Networking through deployments, 2014

Teixeira J. A. Barros – A new Framework to enable rapid innovation in Cloud Datacenter through a SDN approach, 2013

SDNCentral – Network Virtualization Report, 2014

Network Functions Virtualisation – An Introduction, Benefits, Enablers, Challenges & Call for Action, 2012

N. McKeown, T. Anderson, H. Balakrishnan – OpenFlow: Enabling Innovation in Campus Networks, 2008

POX Wiki: https://openflow.stanford.edu/display/ONL/POX+Wiki – accesat la data de: 22.04.2015

CodeAcademy Python: http://www.codecademy.com/en/tracks/python – accesat la data de: 26.04.2015

Python documentation: https://docs.python.org/3/ – accesat la data de: 22.04.2015

Mininet Python API: http://mininet.org/api/index.html – accesat la data de: 23.04.2015

Anexa A

Codul Python pentru descrierea topologiei

#!/usr/bin/python

from mininet.net import Mininet

from mininet.node import Controller, RemoteController, OVSKernelSwitch, UserSwitch

from mininet.cli import CLI

from mininet.log import setLogLevel

from mininet.link import Link, TCLink

def topology():

"Create a network."

net = Mininet( controller=RemoteController, link=TCLink, switch=OVSKernelSwitch )

print "***Creating nodes***"

C1 = net.addController( 'C1', controller=RemoteController, ip='127.0.0.1', port=6633 )

S1 = net.addSwitch('S1', listenPort = 6673, mac='00:00:00:00:00:01')

S2 = net.addSwitch('S2', listenPort = 6674, mac='00:00:00:00:00:02')

S3 = net.addSwitch('S3', listenPort = 6675, mac='00:00:00:00:00:03')

S4 = net.addSwitch('S4', listenPort = 6676, mac='00:00:00:00:00:04')

S5 = net.addSwitch('S5', listenPort = 6677, mac='00:00:00:00:00:05')

S6 = net.addSwitch('S6', listenPort = 6678, mac='00:00:00:00:00:06')

S7 = net.addSwitch('S7', listenPort = 6679, mac='00:00:00:00:00:07')

S8 = net.addSwitch('S8', listenPort = 6680, mac='00:00:00:00:00:08')

S9 = net.addSwitch('S9', listenPort = 6681, mac='00:00:00:00:00:09')

S10 = net.addSwitch('S10', listenPort = 6682, mac='00:00:00:00:00:10')

c1 = net.addHost('c1', mac='00:00:00:00:01:01', ip='10.0.0.1/8')

c2 = net.addHost('c2', mac='00:00:00:00:01:02', ip='10.0.0.2/8')

c3 = net.addHost('c3', mac='00:00:00:00:01:03', ip='10.0.0.3/8')

c4 = net.addHost('c4', mac='00:00:00:00:01:04', ip='10.0.0.4/8')

s1 = net.addHost('s1', mac='00:00:00:00:01:05', ip='10.0.0.5/8')

s2 = net.addHost('s2', mac='00:00:00:00:01:06', ip='10.0.0.6/8')

h1 = net.addHost('h1', mac='00:00:00:00:02:01', ip='10.2.0.7/8')

h2 = net.addHost('h2', mac='00:00:00:00:02:02', ip='10.3.0.8/8')

print "***Creating links***"

net.addLink(S1, S2, 1, 1)

net.addLink(S1, S7, 2, 2)

net.addLink(S1, S6, 3, 3)

net.addLink(S1, S8, 4, 4)

net.addLink(S2, S3, 2, 2)

net.addLink(S2, S8, 3, 3)

net.addLink(S3, S9, 3, 3)

net.addLink(S3, S4, 1, 2)

net.addLink(S4, S7, 1, 1)

net.addLink(S4, S5, 3, 3)

net.addLink(S5, S6, 1, 1)

net.addLink(S6, S10, 2, 2)

net.addLink(S8, s1, 1, 0)

net.addLink(S8, s2, 2, 0)

net.addLink(S9, c1, 1, 0)

net.addLink(S9, c2, 2, 0)

net.addLink(S4, h1, 4, 0)

net.addLink(S5, h2, 2, 0)

net.addLink(S10, c3, 1, 0)

net.addLink(S10, c4, 3, 0)

print "***Starting network***"

net.start()

print "***Running CLI***"

CLI( net )

print "***Stopping network***"

net.stop()

if __name__ == '__main__':

setLogLevel( 'info' )

topology()

Anexa B

1. Aplicație de filtrare a traficului

from pox.core import core

import pox.openflow.libopenflow_01 as of

from pox.lib.revent import *

from pox.lib.util import dpidToStr

from pox.lib.addresses import EthAddr

from collections import namedtuple

import os

import csv

log = core.getLogger()

policyFile = „/home/pox/ext/firewall-policies.csv”

class Firewall (EventMixin):

def __init__ (self):

self.listenTo(core.openflow)

log.debug(„Enabling Firewall Module”)

self.policy = []

with open(policyFile, ‚rb’) as f:

reader = csv.DictReader(f)

for row in reader:

self.policy.append((EthAddr(row[‚mac0’]), EthAddr(row[‚mac1’])))

self.policy.append((EthAddr(row[‚mac1’]), EthAddr(row[‚mac0’])))

def _handle_ConnectionUp (self, event):

for (src, dst) in self.policy:

match = of.ofp_match()

match.dl_src = src

match.dl_dst = dst

msg = of.ofp_flow_mod()

msg.match = match

event.connection.send(msg)

log.debug(„Firewall rules installed on %s”, dpidToStr(event.dpid))

def launch ():

core.registerNew(Firewall)

2. Politici de filtrare

Anexa C

Aplicație pentru colectarea statisticilor

from pox.core import core

from pox.lib.util import dpidToStr

import pox.lib.packet as pkt

import pox.openflow.libopenflow_01 as of

from pox.lib.recoco import Timer

from pox.openflow.of_json import *

import csv

import os

import time

log = core.getLogger()

def _timer_func ():

for connection in core.openflow._connections.values():

connection.send(of.ofp_stats_request(body=of.ofp_flow_stats_request()))

log.debug("Sent %i flow/port stats request(s)", len(core.openflow._connections))

def _handle_flowstats_received (event):

stats = flow_stats_to_list(event.stats)

log.debug("FlowStatsReceived from %s: %s", dpidToStr(event.connection.dpid), stats)

iperf = {'traffic': 0, 'packet': 0, 'flows': 0}

web = {'traffic': 0, 'packet': 0, 'flows': 0}

ftp = {'traffic': 0, 'packet': 0, 'flows': 0}

for f in event.stats:

if f.match.tp_dst == 5001 or f.match.tp_src == 5001:

iperf['traffic'] += f.byte_count

iperf['packet'] += f.packet_count

iperf['flows'] += 1

else:

if f.match.tp_dst == 80 or f.match.tp_src == 80:

web['traffic'] += f.byte_count

web['packet'] += f.packet_count

web['flows'] += 1

else:

if f.match.tp_dst == 21 or f.match.tp_src == 21:

ftp['traffic'] += f.byte_count

ftp['packet'] += f.packet_count

ftp['flows'] += 1

os.chdir('/home/mininet/mininet/share/statistici')

csvFile = open('/home/mininet/mininet/share/statistici/S%s.csv' %event.connection.dpid, 'a')

columns = [str(time.strftime("%H:%M:%S")), iperf['traffic'], iperf['packet'], iperf['flows'], web['traffic'], web['packet'], web['flows'], ftp['traffic'], ftp['packet'], ftp['flows']]

for column in columns:

csvFile.write('%s;' %column)

csvFile.write('\n')

csvFile.close()

def launch ():

core.openflow.addListenerByName("FlowStatsReceived", _handle_flowstats_received)

Timer(2, _timer_func, recurring=True)