Rețele bazate pe virtualizare SDN [307419]

Rețele bazate pe virtualizare SDN

Lucrare de Disertație

Coordonator științific:

Conf. Univ. Dr. Petac Eugen

Absolvent: [anonimizat]

2016

[anonimizat], tehnica de calcul și resursele de rețea au fost păstrate separat în mod fizic și operațional. [anonimizat]. [anonimizat], [anonimizat], sisteme dar toate acestea au fost facute în scopul asigurării securității informaționale. Toate acestea s-au petrecut după introducerea în mediul centrelor de date a tehnicii de calcul ieftine dar cu mai multă putere de procesare, a stocării de date și rețelisticii pe care organizațiile au fost obligate să le integreze la un loc. Această schimbare paradoxală a [anonimizat].

Centrele de date au fost concepute în așa manieră încât să realizeze separația în mod fizic a [anonimizat], și partea de interconectare a lor cu utilizatorii dintr-o rețea. Puterea de calcul care a existat în aceste tipuri de centre de date a [anonimizat] e-mail, servere de baze de date sau oricare alt tip de funcționalitate pentru a fi utilizată în calculatoarele personale ale clienților.

[anonimizat], erau administrare de servere departamentale care furnizau servicii dedicate pentru traficul local. [anonimizat]-un număr relative mare de motive: pentru a [anonimizat] a [anonimizat].

Virtualizarea este o parte importantă a științei de calcul începând încă de la calculul distribuit. Utilizatorii aveau la dispoziție resurse virtuale care erau efectiv subdiviziuni logice împărțite ale unuia sau mai multor dispozitive. Conceptul de virtualizare a [anonimizat], variate și a oferit utilizatorilor de asemenea controlul și posibilitatea de customizare necesare.

[anonimizat] a aplicațiilor.

Cu ajutorul platformei Raspberry Pi 2 voi începe să construiesc în acest proiect de disertatie un sistem de comunicație virtualizat prin intermediul aplicațiilor SDN (Software defined networking). SDN este o tehnologie raltiv nouă care provine din principiile conceptului rețelelor programabile. [anonimizat]. Funcționalitatea principală ce definește o [anonimizat]. Prin distribuirea funcțiilor planului de control și a planului de date se va permite rețelelor să devină mai dinamice și mai inteligente – un dispozitiv de control centralizat poate transmite schimbările de flux de date către toate switch-urile si ruterele din rețea în timp ce supraveghează întreaga topologie.

Platforma Raspberry Pi 2 reprezintă un calculator în miniatură care poate fi achiziționat de pe piață la un pret relativ mic, având dimensiunea unui card de credit. Această platformă este foarte des utilizată în domeniile de cercetare și dezvoltare a noilor tehnologii de comunicație și programare prezente în toate zonele adiacente domeniului IT. Din punct de vedere al puterii de calcul, al aplicațiilor și interfețelor utilizate, capacitățile sale sunt următoarele:

– SoC (System on Chip): Broadcom 2836;

– CPU (Central Processing Unit) Quad-core ARM7 800MHz;

– GPU(Graphical Processing Unit): Videocore IV 250MHz;

– Memorie RAM (Read Access Memory): 1GB;

– GPIO (General Purpose Input/Output): 40pini;

– Interfețe și porturi de conectivitate: 4x USB 2.0, 100BaseT Ethernet, HDMI, card MicroSD;

– Dimensiuni: 85.60 × 56.5mm.

În funcționalitatea dispozitivelor conectate în rețeaua SDN voi integra sisteme de operare bazate pe distribuții de Linux. Deoarece este un sistem de operare bazat pe Unix, înseamnă că acest sistem a dobândit multe din caracteristicile urmașului său precum: multitasking (poate exeuta mai multe aplicații simultan), multiuser (mai mulți utilizatori pot utiliza un calculator simultan sau la interval de timp diferite, în sesiuni de lucru diferite), securitate (fiecare utilizator are drepturi și restricții la folosirea tuturor resurselor puse la dispoziție de acest sistem de operare), programe specializate (unul din principiile de bază afirma că programele care alcătuiesc sistemul de operare trebuie să aibe capacitatea de execuție a unei singure sarcini, dar într-un mod foarte eficient; problemele mai complexe vor fi rezolvate prin înlănțuirea execuției mai multor aplicații (fire de execuție) ceea ce conduce la următoarea caracteristică: interoperabilitate (aplicațiile trebuie să comunice între ele, astfel încât să poată fi folosite împreună).

O altă specificație se referă la respectarea standardelor (Linux este construit pe standarde, POSIX reprezentând unul din standardele de bază) și portabilitate (sistemele Linux rulează în prezent pe procesoare cu tehnologia x86, Alpha, Sun SPARC și UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, IBM S/390, MIPS, HP PA-RISC, Intel IA-64 și AMD x86-64).

Alte functionalități sunt reprezentate de: scalabilitate (sistemele Linux se regăsesc în dispozitive electronice cu utilitate casnică, PDA-uri, stații de lucru, sisteme desktop și sisteme server), customizare (oferă vaste opțiuni pentru rularea și configurarea programelor, a interfețelor). Un element caracteristic foarte important este modul de dezvoltare distribuit, specific oricărei aplicații software de tip open source. Versiunile noi ale sistemelor de operare Linux sunt dezvoltate în mod constant și apar cu mare rapiditate iar erorile de sistem sunt reparate în timp scurt (ceea ce este foarte important în momentul aparitiei “carențelor” în securitatea unui sistem).

Platforma de dezvoltare Raspberry PI 2 beneficiază de un număr generos de sisteme de operare dezvoltate de comunitatea Linux, și oferă multiple funcționalități, posibilități de dezvoltare a aplicațiilor, rularea testelor de performanță și optimizare a rețelelor, redarea conținutului multimedia și distribuirea într-o rețea locală sau prin Internet, automatizarea locuințelor prin sisteme de control și gestiune a resurselor energetice, securizarea locuințelor și supravegherea de la distanță a locațiilor. Câteva din sistemele de operare dezvoltate până în prezent sunt: Raspbian, Ubuntu Mate, Arch Linux, RISC OS, Pidora, Mediacenter,PiBang, RetroPIE.

În configurarea platformei din cadrul acestui proiect am decis să utilizez si să instalez sistemul de operare Ubuntu Mate care este o distributie de Linux ce reprezintă continuarea dezvoltării unei vechi distribuții cu denumirea Linux GNOME 2. Aceasta furnizează un mediu desktop intuitiv și atractiv utilizând “metaforizarea” pentru Linux tradițională cât și pentru alte sisteme de operare Unix-like. Distribuția MATE se află într-o dezvoltare activă cu scopul de a integra suport pentru tehnologiile noi apărute și totodată prezervând experiența unui sistem desktop clasic.

În acest proiect, voi conecta platforma de dezvoltare Raspberry PI 2 cu un dispozitiv de calcul, de preferință un laptop-PC, pentru a construi o rețea de comunicație administrată printr-un controler SDN (Software Defined Network). În final, voi demonstra și voi exemplifica rapiditatea comunicației între dispozitive, realizarea conexiunilor în mod automat o dată ce programarea și configurarea elementelor din rețea a fost îndeplinită, precum și transferarea cu succes a fișierelor de date între dispozitivele conectate în mediul SDN.

Tehnologia SDN în rețele de comunicație

Rețelele definite pe aplicații soft se referă la un mod de a organiza funcționalitatea rețelelor de calculatoare. SDN (Software Defined Networking) permite unei rețele să fie virtualizată, aducând un plus de control și suport pentru ingineria de trafic.

Rețelele care operează în prezent sunt rezultatele deciziilor de proiectare pentru rețele și protocoalelor trasate în anii 1970. La vremea aceea, s-a prevăzut că adresele pe 32 biți vor fi suficiente pentru a putea suporta toate adresele protocoalelor internet (Internet Protocol-IP) pe care internetul le-ar putea înregistra (în medie 16 milioane) – iar până în luna Februarie 2011, toate adresele IPv4 au ajuns să fie epuizate (Cert, 2013). Rețelele au fost considerate ca fiind statice, o dată stabilite, o topologie de rețea nu avea de suferit prea multe modificări, sau aproape nici una.

Serverele care sunt conectate la rețelele actuale au fost supuse unor modificări dramatice în ultimul deceniu. Apariția virtualizării serverelor a schimbat în mod fundamental utilizarea unui server. Actualmente serverele sunt dinamice și pot fi create și mutate dintr-o locație în alta foarte ușor, iar numărul serverelor care sunt capabile să utilizeze rețeua a crescut. Înainte de apariția virtualizării la scară mare a serverelor, aplicațiile erau asociate unui singur server care avea o locație fixă în rețea. Aceste aplicații utilizau rețeaua pentru a face schimb de informații cu alte aplicații care erau amplasate în mod similar în locații fixe.

În prezent, aplicațiile pot fi distribuite pe mai multe mașini virtuale (Virtual Machine-VM). Fiecare din aceste mașini poate face schimb de fluxuri de date între ele. Administratorii de rețea pot seta ca punctele finale ale unui flux de date să fie schimbate. Abilitatea de a migra mașinile virtuale creează provocări noi pentru multe din aspectele conținute în așa numită “rețea clasică”, acestea incluzând scheme de adresare și spațiu de domeniu împreună cu noțiunea de bază a unui proiect axat pe segmentare și rutare. (Open Networking Foundation, 2012).

Împreună cu virtualizarea serverelor, multe companii utilizează frecvent o singură rețea pentru a transmite toate informațiile de voce, video și date de care au nevoie. În rețelele derivate în prezent, conceptul de calitate a serviciului (Quality of Service-QoS) este utilizat pentru a furniza un nivel diferențiat de servicii pentru diferitele aplicații. Personalul administrativ al unei rețele trebuie să configureze separat fiecare echipament al unui producător și să seteze parametrii, precum lungimea de bandă, și QoS pe sesiune, pe bază de cerere a aplicației. Rețelele clasice sunt de tip static, iar acestea nu se pot adapta în mod dinamic la schimbările de trafic, aplicații sau alte solicitări necesare ale utilizatorului.

Rețelele definite pe aplicații software au apărut din munca de cercetare realizată inițial în 2004 ca o subdivizune provenită din studiile de cercetare pentru o nouă paradigmă de administrare a rețelelor, și care a rezultat în două forme diferite: cercetarea pentru platformă de control a rutării (RCP 40) a fost realizată la Universitățile Princeton și Carnegie Mellon, iar cercetarea în securizarea rețelelor a fost realizată în același timp ca parte din proiectul SANE Ethene de la Universitatea Stanford și Universitatea din California, la Berkley.

Studiul de cercetare inițial a fost implementat în 2008 de două grupuri diferite. Primul care s-a numit Nicira, și a fost ulterior achiziționat de VMWare, a creat NOX, un sistem de operare al rețelelor. În același timp, Nicira a conlucrat cu echipele de la Universitatea Stanford pentru a crea interfața switch-ului OpenFlow (Ferland, 2012; Open Networking Foundation, 2013). În 2011, setul de standarde al spațiului SDN, și Open Networking Foundation (http://www.opennetworking.org), ofereau suport pentru industria largă de rețele de comunicație. Acest parteneriat includea firme precum: Cisco, Juniper Networks, Hewlett-Packard, Dell, Broadcom, și IBM. Din componența sa au făcut parte membri care au fost angajați de la cele mai mari companii ale industriei de rețele: Google, Verizon, Yahoo, Microsoft, Deutsche Telekom, Facebook, și NTT.

Unul din cele mai importante evenimente în istoria tehnologiei SDN a avut loc în anul 2012 la Open Networking Summit, unde au participat peste 1000 de ingineri din industria rețelelor de comunicații, și unde Google a făcut public anunțul că tehnologiile lor fac parte deja din aria tehnologiei SDN. Google a anunțat că ei utilizează SDN ca și componentă a unei rețele larg răspândite

(WAN) utilizată pentru a interconecta centrele lor de date (Hölzle, 2012). Rețelele în prezent sunt construite prin interconectarea a zeci, sute, și uneori chiar mii de rutere de rețea sofisticate al căror rol este de a primi pachetele de date de la aplicații și apoi să le transmită către următorul ruter din calea de transmitere până la destinația finală a fiecărui pachet de date.

Figura 1.1 prezintă componentele unui ruter modern la un nivel înalt. Un ruter, așa cum este furnizat de producător, creează o stivă de funcții unificate care funcționează împreună. Această funcționalitate începe cu componenta hardware specializată în transmiterea pachetelor de date al cărui job este să primeasca pachete de date iar apoi să le transmită către următorul ruter pentru a livra eventual pachetele către aplicația destinatie. Toate aceste funcții de control reprezintă sistemul de operare al ruterului. Sistemul de operare este “bijuteria” informatică a producătorului de rutere care a fost optimizată să funcționeze împreună cu platforma fizică a acestuia.

În vârful acestei piramidei se află variate aplicații de comunicație, precum protocoale de rutare specializate care utilizează sistemul de operare și instrumentul fizic de transmitere al pachetelor pentru a atinge obiectivele tehnologice ale echipamentului.

Figura 1.1 – Arhitectura unui ruter de rețea modern.

Pentru a face lucrurile să lucreze în funcționalitatea rețelei, este necesară accesarea fiecărui ruter din rețea și introducerea unui set de comenzi pentru sistemul de operare în limbajul care a fost definit de producătorul ruterului. Efectul acestei operațiuni este să modifice comportamentul echipamentului. Aceste mediu este închis iar ruterele nu pot interacționa ușor cu alte componente care construiesc rețeua.

Cercetarea în domeniul SDN a fost puternic motivată de actualele probleme în rețelele de calculatoare. Acestea utilizează actualmente trei planuri separate pentru a împlini sarcinile: planul de date, planul de control și planul de administrare (Figura 1.2).

Planul de date are rolul de a procesa pachetele primite. Când un pachet este primit, funcționalitatea planului de date utilizează informațiile sale despre starea de transmitere locală și informațiile care sunt conținute în fiecare pachet pentru a lua o decizie în a anula sau transmite pachetul. Dacă planul de date decide să transmită pachetul, atunci el trebuie să identifice cărui calculator îi va trimite informația și care port al acelui calculator o va primi. Pentru a ține pasul cu toate pachetele care le primește planul de date, procesarea planului de date trebuie efectuată extrem de rapid.

Planul de control calculează stadiul de transmitere pe care planul de date îl va folosi pentru a transmite pachetele de date. Această stare de transmisie poate fi calculată utilizând algoritmi distribuiți sau algoritmi centralizați sau poate fi configurat manual. Planul de date și planul de control sunt foarte diferite, ele fiind construite pentru a îndeplini diferite sarcini. Planul de administrare este responsabil pentru coordonarea interacțiunii dintre planul de control și planul de date.

Figura 1.3 prezintă modul în care planul de date este construit folosind abstracțiuni. Un set de nivele de transport instabil a fost utilizat în ultimă instanță pentru a crea un nivel de transport stabil.

Figura 1.2 – Cele trei planuri ale unui ruter tradițional.

Figura 1.3 – Nivele de abstractizare ale planului de date.

Un set similar de abstracțiuni nu există pentru planul de control. De asemenea simplificarea de bază care este utilizată pentru a construi un plan de control este inexistentă. În schimb, un număr mare de mecanisme au fost create pentru a implementa diferitele tipuri de planuri de control.

Mecanismele planului de control au fost toate proiectate pentru a împlini o varietate de funcționalități dferite. Un exemplu ar fi planurile de control al rutării care implementează o varietate mare de algoritmi de rutare distribuită. Se pot utiliza planuri de control de izolare pentru a furniza lista de control acces (Access Control List-ACL), rețele locale virtuale (VLAN), paravane de protecție (firewall), etc. În final, există planuri de control bazate pe trafic de date ingineresc care pot utiliza modificări de lățime de bandă a conexiunii pentru a lua decizii de rutare și pentru a implementa protocolul MPLS (Multiprotocol Label Switching). Toate aceste abordări diferite încearcă să modifice rutarea pachetelor – acestea sunt menite să controleze modul în care starea de transmitere este calculată.

O insuficiență a planurilor de control care sunt utilizate în rețelele actuale este faptul că acestea nu sunt modulare – ele nu pot fi folosite împreună. Fiecare din planurile de control rezolvă o parte a problemei de control a rețelei, dar nu există o soluție care să rezolve controlul unei rețele. Efectiv, fiecare furnizează funcționalitatea limitată. Planurile de control moderne ale rețelelor furnizează mult mai multe mecanisme dar cu funcționalitate redusă. Acestea se datorează faptului că nu există o metodă de abstractizare a funcționării planului de control. La fiecare descoperire a unei noi probleme (ex. persoane obțin access în rețea în mod ilegal), o nouă soluție este definită. Toate aceste soluții noi implementează o parte a funcționalității necesare. Rezultatul proiectării planului de control reprezintă metoda prin care se creează disensiune între rețele business și necesitățile corporațiilor business. Un exemplu simplu ar fi selecția rutării datelor în rețelele clasice curente. Dacă o aplicație conține un set mare de date care necesită transferarea către o altă aplicație, ar putea folosi cea mai rapidă și costisitoare cale în rețea pentru că este disponibilă.

Totuși, dacă aplicația ar putea “comunica” cu rețeaua, ar putea descoperi o cale de transmisie mai lentă dar mai puțin costisitoare care ar putea deservi necesităților sale intr-un mod eficient. Proiectarea planului de control utilizată în rețelele prezente nu permite partajarea informațiilor de acest tip.

Sistemele bazate pe arhitectura centralizată CPU (Centralized CPU (Central Processing Unit)-Based Router Architecture, figura 1.4) sunt folosite de ruterele Cisco originale și de mai multe generații de rutere din clasa enterprise care au urmat. Din această categorie sunt prezente seriile de rutere Cisco: 800, 1600, 1700, 2500, 2600, 3600, 3700, 7200 precum și cele mai noi 1800, 2800, 3800 precum și seria de rutere cu servicii integrate (ISR – Integrated Services Router).

Figura 1.4 – Arhitectură centralizată bazată pe CPU.

Figura 1.5 – Arhitectură centralizată bazată pe circuit ASIC.

Arhitectură centralizată bazată pe circuite ASIC (Centralized ASIC (Application Specific Integrated Circuit) -Based Architectures, figura 1.5): ASIC este un circuit integrat complex, referit și ca un SoC (System on Chip), înțelegându-se prin acest termen un sistem de calcul realizat pe un singur microcircuit. El este dedicat implementării unei aplicații particulare, în cazul nostru switch/ ruter, mai degrabă decât unei utilizări generale. Un circuit ASIC este proiectat de o anumită companie și este realizat, în general, pentru un singur beneficiar (client). Familia de switch-uri Cisco Catalyst 6500, ruterele din seriile Cisco 7600, Cisco 7300, RPM-XF PXF și Cisco 10000 Edge Services Router (ESR) folosesc tehnologii bazate pe circuite ASIC

Arhitectură distribuită bazată pe procesoare (Distributed CPU-Based Architectures, Figura 1.6). Folosite în rețelele dezvoltate pe scară largă, ruterele necesită, pe lângă performanțe ridicate în ceea ce privește numărul mare de pachete redirecționate, și o mare densitate de porturi, ceea ce reduce costurile totale de hardware, precum și costurile operaționale, dat fiind faptul că un număr mai mic de dispozitive trebuie să fie gestionate. Literatura indică două abordări ce pot fi luate în calcul pentru a crește viteză de transmitere a unui ruter: păstrarea prelucrării centralizate, prin creșterea vitezei procesorului sau prin soluții bazate pe circuirte ASIC de mare viteză. Ambele abordări se dovedesc limitate, la un moment dat, în raport cu formularea de performanțe mai ridicate. O nouă soluție o reprezintă arhitectura distribuită bazată pe procesoare: la nivelul ruterului, funcțiile de procesare și de redirecționare a traficului sunt distribuite unor blocuri specializate (discrete line cards), bazate pe procesoare proprii și capabile să suporte și să gestioneze un anumit număr de interfețe de rețea.

Figura 1.6 – Arhitectură distribuită bazată pe procesoare.

Interconectarea acestor blocuri prin intermediul unor bus-uri interne de mare viteză, permite ca, din punct de vedere logic, să existe o apartenență la un singur domeniu de rutare, asigurându-se practic o funcționare unitară a dispozitivului, prezent la nivelul rețelei ca un singur ruter. Seriile de rutere Cisco 7500 și Cisco 12000 Gigabit Switch Router (GSR) sunt câteva din soluțiile bazate pe această arhitectură.

Arhitectură distribuită bazată pe circuite ASIC (Distributed ASIC – Based Architectures, figura 1.7): la nivelul ruterului, funcțiile de procesare și de redirecționare a traficului sunt distribuite unor blocuri specializate (discrete line cards), bazate pe circuite ASIC și capabile să suporte și să gestioneze un anumit număr de interfețe de rețea, cu interconectarea acestor blocuri prin intermediul unor bus-uri interne de mare viteză. Familia de rutere Cisco CRS-1 se bazează pe această tehnologie, având implementate blocuri modulare 40-Gbps line cards, circuite specializate ASIC, tehnologii Advanced Route Processors și Service-Intelligent Switching precum și beneficiind de sisteme de opearare Cisco IOS XR Software.

Figura 1.7 – Arhitectură distribuită bazată pe circuite ASIC.

1.1.1 Funcții de bază ale ruterelor

Ruterul poate ruta folosind:

Rute statice – programate în prealabil de către administratorul de rețea;

Rute dinamice – ruterele pot calcula dinamic rutele, pe baza protocoalelor de rutare dinamică, urmând să redirecteze pachetele pe aceste rute.

Ca dispozitiv de nivel 3 OSI, ruterul îndeplinește două funcții de bază, beneficiind de implementări specifice prezenței conceptuale a două planuri principale (figura 1.8) – de date (Data Plane) și de control (Control Plane):

Retransmitere (Forwarding numit și Switching de nivel 3 OSI), funcție specifică planului de date: preia fiecare pachet care sosește pe o interfață și “caută” în tabela de rutare interfața („linia”) de ieșire folosită pentru acest proces.

Completează și actualizează tabela de rutare (Routing), funcție specifică planului de control, aici intervenind protocoalele de rutare, în cazul rutării dinamice.

Figura 1.8 – O perspectivă funcțională asupra unui proces de rutare.

Procesarea tipică a pachetelor sosite pe o interfață a ruterului este prezentată în Figura 1.9, scopul fiind acela de determinare a interfeței de ieșire (exit interface) și, implicit a adresei IP a interfeței următorului ruter (next hop), direct conectat cu ruterul considerat.

Figura 1.9 – Procesarea pachetelor la nivelul unui ruter

Segmentarea conceptuală cu ajutorul planurilor de date și control este completată, ca soluții moderne, cu planurile de management (Management Plane) și de servicii (Services Plane). Funcțiile de bază implementate la nivelul acestor planuri sunt: planul de date – retransmitere; planul de control – protocolul de rutare, completarea și actualizarea tabelei de rutare; planul de management (administrare) – operații de administarare a traficului la nivelul rețelei; planul de servicii – traficul la nivelul clientului sau al aplicațiilor cu cerințe specializate de manipulare de trafic.

Ruterele cu arhitectură distribuită bazată pe procesoare au un procesor central care implementează planul de control (cele mai multe protocoale de rutare sunt proiectate să funcționeze astfel), în timp ce procesoarele de pe blocurile line cards implementează distribuit planul de date de mare viteză. Switch-urile Layer 3 de mare viteză implementează planul de date folosind hardware specializat, de exemplu TCAM – Ternary Content Addressable Memory.

În ccea ce privește funcția de retransmitere (Forwarding/Switching Layer 3) implementată software, sunt disponibile trei metode la nivelul sistemului de operare Cisco IOS:

Process Switching (Figura 1.10): Pachetele sunt prelucrate și transmise direct de către procesorul ruterului.

Fast Switching (Figura 1.11): Pachetele sunt transmise pe întreruperile procesorului, folosind intrări cache, create prin comutare de proces. O intrare cache nouă este creată atunci când este primul pachet în procesul de comutare spre o destinație data și comanda ip route-cache este activată (enable) pe interfața de ieșire. Verificarea activării se poate face folosind comanda R1# show ip interface nume_interfața în timp ce pentru vizualizarea conținutului curent a cache-ului Fast-Switching se poate folosi comanda: R1# show ip cache.

Cisco ExpressForwarding–CEF (Figura 1.12): Pachetele sunt transmise folosind o versiune precalculată și foarte bine optimizată a tabelei de rutare.

Figura 1.10 – Retransmitere prin metoda Process Switching.

Figura 1.11 – Retransmitere prin metoda Fast Switching.

Figura 1.12 – Retransmitere prin metoda Cisco ExpressForwarding–CEF.

Întâlnită și cu denumirea de Fast Path Switching, metodă de comutare CEF (Cisco Express Forwarding) creează și întreține două structuri de date:

FIB – Forwarding Information Base, cunoscută și sub numele de Tabela CEF (CEF Table): gestionează informații de redirecționare de nivel 3 OSI din tabelele de rutare și înregistrează next hop-ul pentru toate rutele.

Tabela de adiacență (Adjacency Table): conține informații de redirecționare de nivel 2 OSI, pentru fiecare intrare FIB, eliminând necesitatea că ruterul să trimită cereri ARP.

Retransmitere prin metoda Cisco ExpressForwarding–CEF presupune parcurgerea următoarelor etape (figura 1.12), toate la nivelul memoriei:

Frame-urile care ajung la ruter sund decapsulate, prin înlăturarea informațiilor de nivel 2 OSI.

Din FIB (Tabela CEF) se intră în posesia informației cu privire la next hop.

Ruterul găsește o intrare corespunzătoare next-hop-ului în tabela de adiacență.

Ruter-ul încapsulează pachetul cu informațiile de nivel 2 (găsite în tabela de adiacență), și realizează transmiterea frame-ului rezultat.

1.2 Planurile rețelei

Planul de control este proiectat să calculeze starea de transmitere de date sub trei constrângeri diferite:

1. Să fie în consistență cu nivelul inferior fizic și cel de program. Notația ASIC (Application-Specific Integrated Circuit) să fie cunoscută și disponibilă la nivel CLI (Command Line Interface) pentru a determina funcțiile pe care le realizează nivelul fizic și cel de programe în switch.

2. Să fie bazat pe o topologie de rețea completă.

3. Starea de transmitere să fie inserată în fiecare dispozitiv fizic de transmitere a datelor în rețea.

La fiecare proiectare a unui protocol de rețea, aceste trei puncte sunt reluate în cosiderare și alta soluție este creată. Această abordare nu este una sustenabilă.

Analogia programării:

La solicitarea creării unui program nou, acesta trebuie să împlinească următoarele cerințe: (1) Să recunoască elementele fizice peste care va (regiștrii, operațiuni limitate disponibile, etc.), și (2) să specifice unde va fi stocat fiecare bit. Abstracțiunile la nivelul sistemului fizic se vor crea rapid. În prima fază un limbaj de programare independent de platforma fizică va fi construit (compilator); apoi, va fi dezvoltată interfața virtuală de memorie (sistem de operare). Figura 1.13 prezintă diferitele arhitecturi pe care un ruter le poate avea în SDN. Funcționalitatea planului de date va fi ceea ce platforma fizică a ruterului va furniza. Planul de control și cel de administrare vor fi furnizate de o aplicație soft care va fi rulată pe o platformă separată dar conectată la ruter printr-o legătură de date securizată.

Figura 1.13 – Componentele unui router în SDN.

Pentru a defini funcționalitățile planului de control al rețelei, un set de funcții specifice este necesar. Prima funcție este un model general de transmitere care poate ascunde detaliile de nivel inferior al platformei fizice și al programelor care au fost utilizate pentru a crea switch-ul de rețea. Următoarea, este o funcție care va determina starea curentă în care se află rețeaua. Aceasta va fi utilizată în procesul de luare a deciziilor în întreaga rețea complexă. În final, o funcție pentru a configura rețeaua este necesară. Scopul este evitarea necesității de a configura fiecare dispozitiv fizic într-o rețea în care pot exista de la câteva mii la câteva milioane de dispozitive. Așadar, o funcție pentru simplificarea configurării se dovedește a fi necesară. Aceasta poate fi realizată prin calcularea configurației fiecărui dispozitiv fizic.

1.2.1 Funcția de transmitere

La analizarea celei mai bune metode de a construi un plan de control , una din cele mai bune funcții de implementat este aceea a transmiterii pachetelor. Efectul dorit este cel de a releva ceea ce se va întâmpla cu pachetul transmis fără a fi nevoie să urmărim calea către switch-ul în care va ajunge ulterior să fie implementat. Această particularitate subliniază că switch-ul de rețea trebuie să cunoască metodele de a utiliza fiecare set de circuite ASIC cu grade diferite de capabilități, iar aceasta nu ar trebui să afecteze în vreu fel funcția de transmitere. În plus, aplicația soft care este executată în switch poate fi furnizată de oricare producător, acest fapt de asemenea, nu are vreun impact asupra funcției de transmitere.

În lumea SDN aflată în constantă dezvoltare, interfața OpenFlow este o opțiune pentru comunicarea între planul de control al soft-ului centralizat și switch-ul de rețea. Firme producătoare precum Cisco și VMWare au dezvoltat propriile lor alternative la această interfață. Interfața OpenFlow este un set de interfețe de programare a aplicațiilor (API) care permite unui program soft extern să comunice cu un switch de rutare în rețea. Pachetul de rețea care va fi distribuit de API este denumit “intrare de flux” (flow entry). O intrare de flux preia forma unui model de pachet și o acțiune care se denumește astfel: <header, action>. O intrare de flux specifică dacă un pachet se potrivește modelului, caz in care switch-ul va lua o decizie (ex. abandonare, transmitere către un port specific, etc.).

OpenFlow este un limbaj general simplu pe care fiecare switch din rețea ar trebui să îl interpreteze. La un nivel mai înalt, ideea unei interfețe OpenFlow este ușor de acceptat. Totuși când detaliile încep să fie examinate, lucrurile devin în mod considerabil mai complexe. Pentru a implementa OpenFlow, este necesară luarea multor decizii de diferite facturi. Acestea pot include cât de bine să se facă selecțiile modelelor sau care decizii vor fi luate o dată ce un model a fost regăsit.

1.2.2 Funcția de stare a rețelei

Pentru a crea o stare a rețelei, primul lucru necesar este cel de a găsi o cale de indepărta pe cât posibil abstractizările din funcționalitatea distribuită în mod complex care va fi utilizată pentru a colecta informațiile necesare în construcția stării rețelei. Scopul final al stării rețelei este să prezinte o “viziune globală a rețelei”. Aceasta viziune se prezintă ca un grafic (obiecte și conexiuni) care conține informația asociată cu acesta: timpi de întârziere în rețea, capacitatea de conexiuni, rata de piederi recente. Atunci când graficul a fost creat, programul de control era capabil de luarea a deciziilor de acționare bazându-se pe graficul rețelei. Dacă accesul la grafic se realizează printr-un API, atunci elementele actuale ale rețelei care construiesc rețeaua pot fi controlate prin API.

Funcționalitatea de vizualizare globală a rețelei poate fi implementată ca parte a unui sistem de operare al rețelei. Acest program software poate rula pe servere separate de switch-urile utilizate în rețea. Poate fi de asemenea replicat pentru a aduce un plus de fiabilitate. Pentru păstrarea tuturor datelor curente, informația va fi transmisă bidirecțional între sistemul de operare al rețelei și serverele de rețea. Acest flux de informație va permite vizualizării globale a rețelei să fie actualizată constant cu informații privitoare la evenimentele ce au loc în fiecare switch al rețelei. De asemenea , fiecare switch ar putea fi apoi actualizat pentru a asigura un control precis al pachetelor de transmis.

Figura 1.14 prezintă o rețea tipică care folosește un șablon de rețea tradițională. Această rețea constă dintr -un set de switch-uri de rețea , care au sarcina de a ruta pachete ce conțin informații de utilizator, între ele. Există conexiuni doar între unele dintre switch-uri din rețea. Fiecare switch este accesibil printr-una sau mai multe căi de acces . Aceste conexiuni sunt de asemenea folosite pentru a permite fiecăruia dintre switch-urile de rețea să poată face schimb de informații de control pe care le pot folosi apoi pentru a actualiza " vizualizarea " individuală a fiecăruia asupra rețelei. Aceste informații sunt folosite ulterior pentru a modifica modul în care switch-urile transmit pachetele de date primite.

Figura 1.14 – Rețea de switch-uri.

Figura 1.15 prezintă o versiuna îmbunătățită a rețelei din Figura 1.14. Au fost adăugate mai multe detalii în cadrul mecanismelor de control care sunt utilizate în această rețea . Standardele sunt folosite pentru punerea în aplicare a unui algoritm de rutare de tip peer- based. Acest algoritm este, după condițiile necesare, un algoritm distribuit care rulează intre switch-urile vecine din rețea. Din cauza modului în care rețelele sunt concepute și puse în aplicare în prezent , acest algoritm de control este complicat dar și orientat pe sarcină specifică . De exemplu , mecanism de control ar putea fi algoritmul „prima cale mai scurtă” (SPF) care a fost adaptat pentru a permite calcularea a două căi disjuncte , care vor fi utilizate pentru transmiterea de pachete .

Figura 1.16 prezintă modul în care designul de rețea complicat din prezent poate fi simplificat prin noua abordare , pe care o oferă tehnologia SDN . În această rețea , există un algoritm software de uz general , care acum rulează pe sistemel de operare ale serverelor de rețea.

Acest program soft comunica către fiecare switch din rețea pentru a determina topologia reteleie, ex.: algoritmul de rutare SPF, algoritmul distribuit care rulează între dispozitive învecinate, algoritmul distribuit al sarcinilor specifice complexe.

Figura 1.15 – Mecanisme de control tradiționale.

Figura 1.16 – Rețea definită pe aplicație soft (SDN).

La colectarea acestor informați, se permite sistemului de operare al rețelei să creeze o imagine globală de rețea, așa cum este prezentat în Figura 1.16. Caracteristicile principale ale acestui model de program software sunt extensibilitatea și flexibilitatea.

Când exista o imagine globală de rețea disponibilă, este posibilă creearea unui program de control care operează la un nivel superior. Programul de control poate primi diferite forme: poate fi un program de rutare, un program de control al accesului, un program de inginerie de trafic, etc. Toate aceste modele diferite de programe de control pot utiliza vizualizarea globală a rețelei pentru a construi decizii de transmitere a pachetelor de date în rețea. Construirea deciziilor în mod centralizat, bazată pe o stare globală este diferită de rețelele din prezent, în care deciziile distribuite sunt construite pe baza cunoștiințelor locale imperfecte asupra stării globale a rețelei.
Funcția de control a rețelei este abordată în mod diferit în tehnologia SDN. Atunci când se utilizează SDN pentru a controla informațiile într-o rețea, modalitatea de control a programului este diferită de modalitatea în care este gestionata rutarea într-o rețea “tradițională”. Modul în care informațiile sunt utilizate pentru a determina modul în care fiecare dintre switch-uri în rețea ar trebui să trimită pachete, va fi de acum determinată pe baza vizualizării globale a rețelei (Figura1.17). Metoda prin care rețeaua determina modul de transmitere a pachetele care o străbat de-a lungul ei s-a modificat în mod radical. În locul unui algoritm distribuit în care fiecare switch din rețeaua realizează propriul set de calcule, se va folosi un program centralizat de control care preia această responsabilitate. Această logică de control funcționează ca un program în sistemul de operare de rețea și folosește un API pentru a interacționa cu vizualizarea globală a rețelei. În cele din urmă, cel mai bun mod de a vizualiza programul de control este cel realizat printr-un tip de algoritm grafic.

Figura 1.17 – SDN cu vizualizare globală aretelei și program de control.

Acest fapt schimbă modul în care problemele vor fi abordate atunci când există necesitatea realizarii unei modificari în rețea, vizavi de modul în care sunt rutate pachetele de informații. În loc de a restructura un algoritm de rutare distribuit, doar programul de control centralizat va fi cel ce va suferi modificări. Aceasta ușurează modalitatea de verificare, mentenanța și investigarea modalității prin care sunt transmise pachetele de date .

1.2.3 Funcția de configurare

Programul de control este locația unde comportamentul pachetului va lua forma. Rețeaua de bază nu cunoaște automat modul în care pachetele vor fi transmise. Spre exemplu , în cazul în care se constată că pachetele care vin de la nodul A nu ar trebui să se deplaeze până la nodul B, atunci programul de control va fi responsabil pentru realizarea acestei condiții . Rețeaua de bază nu poate conține o modalitate de a comunica dacă pachetele de la A ar trebui sau nu ar trebui să fie rutate prin nodul B.

Programul de control nu conține resursele pentru implementare a comportamentului de rutare pe o infrastructură de rețea fizică . În exemplu, programul de control nu este responsabil implementarea regulii că nodul A nu ar trebui să comunice cu nodul B. În schimb, aceasta va necesita ca informațiile detaliate de configurare să fie plasate în tabelele de transmitere din fiecare ruter de-a lungul fiecărui traseu în rețea.

Pentru a pune în aplicare această separație între programul de control și implementarea informațiilor de ieșire ale programului de control, în SDN programul de control interacționează cu o abstractizare a rețelei de bază, din care multe dintre detalii au fost eliminate. Graficul vizualizării globale a rețelei cu care programul de control ar putea interacționa conține suficiente detalii, astfel încât programul de control să fie capabil să redea obiectivele urmărite ("Pachetele de informații de la nodul nu vor fi transmise prin nodul B"). Numărul de detalii pe care vizualizarea globală a rețelei le va furniza programului de control va depinde de funcția pe care programul de control încearcă să o îndeplinească. QoS, controlul accesului, sau chiar traficul de inginerie au nevoie de diferite numere de detaliu în rețeaua de bază.

O perspectivă de abordare a acestui concept este să fie corelat cu mediul de limbaje de programare și compilatoare. Calculatorul care va fi utilizat pentru a rula programul conține un set de instrucțiuni specifice, și în cele din urmă programul construit va fi exprimat în acest limbaj. Se poate utiliza un limbaj de nivel înalt iar detaliile de nivel inferior care fac să ruleaze aplicația software pe platforma fizica vor fi interpretate de compilator.

Spre exemplu, Figura 1.18 prezintă un exemplu de rețea. Presupunând că un program de control execută o funcție de control al accesului, acesta va dori să prevină nodul A să comunice cu nodul B. Într -o rețea tradițională , programul de control ar trebui să efectueze calculele pentru a determina modul de rutare permis să se efectueze în această rețea , apoi urmând să fie configurate tabelele de rutare pe fiecare nod din rețea pentru a implementa rezultatele acestui algoritm de rutare. O modalitate alternativă de implementare a funcției de control al accesului este prezentarea algoritmului vizualizat în rețeuea din Figura 1.19. În această figură , numai interfețele externe ale rețelei sunt vizibile algoritmului. Algoritmul de control al accesului este interogat: "Căror noduri ar trebui să li se permită să vorbească cu alte noduri?”. O dată ce funcțiile de control al accesului identifica faptul ca nodul A nu ar trebui să ruteza pachete prin nodul B , atunci funcția este îndeplinită.

Figure 1.18 – Exemplu SDN: controlul accesului.

Figura 1.19 – Exemplu SDN : controlul accesului în vizualizare abstractă.

Responsabilitatea va fi atribuită "compilatorului" pentru a se asigura că toate informațiile rutate prin pachete sunt corect amplasate în tabele corecte de pachetele transmise în fiecare dintre switch-urile care formează rețeaua. Pentru a permite compilarea deciziilor de rutare ale programului de control să fie tradusă în comenzi de configurare reale pentru fiecare dintre switch-urile din rețeaua fizică, un nou nivel trebuie să fie adăugat la modelul SDN. Acest nivel se numește nivelul de virtualizare (Figura 1.20).

Unul dintre rolurile nivelului de virtualizare este de a prezenta o viziune abstractă a rețelei programulului de control – o vizualizare care are toate detaliile inutile eliminate. Programul de control va "vedea" o perspectivă simplă a rețelei. În exemplu, programul de control va decide astfel că dorește traficul de date de la nodul A să nu fie redirecționat prin nodul B.

Nivelul de virtualizare va prelua deciziile de control al accesului luate de programul de control și le va converti e în vizualizarea globală a rețelei. Vizualizarea actualizată a rețelei globale este apoi transferată către sistemul de operare al rețelei, căruia îi revine responsabilitatea de a configura în mod corespunzător fiecare dintre switch-urile care alcătuiesc rețeaua fizică reală.

De notat este faptul că platforma fizică de bază (hardware) nu mai trebuie să fie reprezentată de un ruter sofisticat. Un dispozitiv relativ simplu, care poate furniza hardware-ul de bază pentru transmiterea pachetelor va face față corespunzător. Acesta va comunica cu rețeaua folosind un protocol, cum ar fi OpenFlow.

Figura 1.20 – Componentele unei rețele SDN.

1.2.4 Separarea funcționalității

Arhitectura unei rețele bazată pe tehnologia SDN are o separare a funcționalității vizibilă. Partea de program de control al rețelei are rolul de îndeplinire a cerințelor operatorului pentru modul în care pachetele urmează să fie transmise în rețea. Funcționalitatea programului de control este determinată de cerințele operatorului. Când cerințelor impuse de operator se modifică, programul de control este singura parte a mediului SDN care trebuie să fie modificat. Nivelul de virtualizare este construit pentru a prelua punctul de vedere abstract, care este prezentat prin programul de control și să îl traducă în vizualizarea detaliată globală. În cele din urmă, sistemul de operare de rețea preia comenzile de control-rutare a pachetelor care au fost create pe baza vizualizării rețelei globale și le mapează către switch-urile fizice care formează rețeaua care este controlată.

API-ul pe care sistemul de operare de rețea îl utilizează pentru a comunica cu fiecare dintre switch-uri de rețea este determinat starea de abstractizare a rețelei. Interfața dintre sistemul de operare de rețea și switch-uri este determinată de abstractizarea transmiterii de date – posibil chiar interfața OpenFlow. Dacă au loc modificări în rețeaua fizică de bază, atunci aceste modificări vor fi transmise până la sistemul de operare de rețea. Odată ajunse acolo, ele vor fi reliefate în vizualizarea rețelei globale și în cele din urmă în vizualizarea abstractă a rețelei. Funcționând concomitent, sistemul de operare de rețea, nivelul de virtualizare și programul de control alcătuiesc nivelele planului de control SDN. La fel ca și planul de date al rețelei a avut întotdeauna nivele pentru a pune în aplicare funcționalitatea acestuia, într-o rețea bazată pe tehnologie SDN, acum planul de control conține nivele pentru a pune în aplicare funcționalitatea.

Utilizarea arhitecturii SDN nu simplifică necesitatea de a crea o rețea care funcționează în mod corespunzător. Cu toate acestea, ceea ce SDN aduce ca noutate este faptul ca înlătură complexitatea asociată aceastei necesități și o distribuie în jur. Sistemul de operare al rețelei și componentele din nivelul de virtualizare al SDN rămân segmente complexe ale aplicației software. Funcționalitatea acestor straturi care trebuiesc îndeplinite necesita ca ele să fie mari componente software și să aibă o mare complexitate logică proiectată în interior.O rețea bazată pe tehnologie SDN este capabilă să îndeplinească cateva obiective principale.

Primul este capabilitatea de a simplifica interfața pentru partea de program de program de control a planului de control. Această parte a rețelei poate fi definită acum cu cerințe specifice unui anumit utilizator. Partea cea mai dificilă de a crea o rețea care funcționează în mod corespunzător, codul complex, poate fi acum atribuită în piesa platformei SDN reutilizabilă a proiectului. Acest proiect este similar cu modul în care compilatoarele pentru limbajele software sunt proiectate, fiind dificile de construit. Ele conțin o mare complexitate, și trebuie să aibă o bună cale comunicație cu computerul fizic pe care programul va rula.

Aplicații

În SDN, serverul care execută planul de control este capabil să ruleze un set de aplicații de rețea adiționale. Multe din aceste aplicații sunt executate pe rutere individuale în rețele tradiționale.

Aplicațiile pot include funcționalități precum transmiterea de pachete de date, rețele virtuale private (VPN), securitate, lățime de bandă, virtualizarea rețelei, etc. Totuși, nici una din aceste aplicații nu prezintă multă importanță astfel încât să conducă la o schimbare a rețelelor clasice în rețele tip SDN în industrie. În rețelele de calculatoare care sunt proiectate și implementate în prezent, topologia este politica principală. Locațiile unde ruterele și firewall-urile sunt amplasate în rețea limitează răspândirea domeniului de distribuție, liste de control acces , etc. Multe companii iau în considerație să migreze retele lor corporate din lumea domeniului fizic în domeniul „cloud computing”.

Având implementate topologii care le premit să creeze politica de rețea corporate dorită, aceste corporații doresc să păstreze aceeași politică pentru rețele lor bazate pe cloud. Problema cu care se confrunta operatorii rețelelor de corporație este că puține companii dețin o vizualizare abstractă asupra politicii lor corporative care o dețin (Figura1.21).

Adevărată valoare care rezultă din utilizarea SDN este ca operatorul de rețea poate menționa o „topologie virtuală” a rețelei sale corporative către cloud. Rețeaua bazată pe cloud, care a fost implementată utilizând tehnologie SDN poate să nu respecte proiecarea fizică a rețelei pe care o înlocuiește și să implementeze în schimb această politică. Rezultatul final este că orice corporație poate acum să migreze fără probleme de la sau spre o rețea cloud de la rețeaua lor actuală. Pentru a face posibil acest lucru, politica de rețea corectă trebuie să fie integrată în cloud aceasta făcându-se prin extragerea actualei politici de rețea din rețeaua fizică existenta. Operatorii de rețea pot utiliza actuala topolgie a rețelei pentru a-și construi declarația politicii de rețea. Aceasta poate fi replicată în tehnologia cloud bazată pe SDN. Spre exemplu, mașinile virtuale existente într-o rețea pot fi transferate pe cloud, aplicând acceasi cerințe de politica de rețea pentru că ea există în aceeași topologie virtuală.

Tehnologia SDN oferă proiectanților de rețele enterprise și operatorilor posibilitatea să virtualizeze rețelele lor fiind singura tehnologie care permite această faciliate. Din aceste considerente, virtualizarea este cea mai mare evoluție a tehnolgiei SDN adusă în rețelele „tradiționale”.

Figura 1.21 – Cloud integrat cu mediul SDN.

1.4 Fog Computing și Internet of Things

Conceptul de “Internet of things” generează un volum și o varietate mare de date. Dar până ca datele să poată ajunge în “cloud” pentru a fi analizate, șansa de a fi utilizate sau introduse în anumite operații poate dispare. Această “foaie de hârtie” intenționată pentru profesioniștii din tehnonologie de operare din domeniul IT, explică un nou model de analizare și utilizare a datelor din IoT. Aceasta poartă numele de “edge computing” sau “Fog Computing”:

Analizează cele mai senzitive date de la granița infrastructurii, aproape de sursa care le generează în loc să trimită cantități mari de date către “cloud”.

Acționează asupra datelor în câteva milisecunde, bazându-se pe politicile corespunzătoare.

Trimite date selecționate către “cloud” pentru analiză istorică și stocarea pentru perioada de lungă durată.

Infrastructura IoT rapidizează luarea la cunoștiință și răspunsul la evenimentele care pot avea loc. În industriile de producție precum petrol și gaze, utilități, transport, extracții miniere și sectorul public, răspunsul rapid poate îmbunătăți rezolvarea unei probleme, poate crește nivelul serviciilor și sporirea securității.

Conectarea noilor tipuri de dispozitive la Internet poate creea de asemenea noi oportunități de afaceri. Exemplele includ achitarea asigurării RCA în timpul șofatului autovehiculului și mașina ca serviciu.

Figura 1.22 – Concept Rețea-Fog.

Pentru a monopoliza IoT este necesară utilizarea unei noi infrastructuri. Aplicațiile “cloud” de astăzi nu sunt construite pentru volumul, varietatea și rapiditatea datelor care IoT le generează. Miliarde de dispozitive neconectate dintru început generează mai mult de doi hexabytes de date în fiecare zi. Se estimează un număr de 50 de miliarde de “dispozitive” care vor fi conectate la Internet până în 2020. Translatarea datelor de la aceste dispozitive către cloud pentru analiza ar necesita vaste de lățimi de bandă.

Aceste câteva miliarde de dispozitive inteligente reprezintă de asemenea nenumărate tipologii de noi tehnologii. Unele reprezintă ideea de mașini de calcul care se conectează la un controler folosind un protocol industrial. Înainte ca informația să fie transmisă către cloud pentru analiza sau stocare, este necesară transformarea în IP.

Dispozitivele IoT compensează această provocare, generând date în mod constant, iar pentru analizarea lor este necesară ca această operație să fie foarte rapidă. De exemplu, când temperatura într-o cuvă chimică atinge limita acceptabilă, acțiuni corective trebuie luate imediat. În timpul necesar citirii de temperatură să ajungă de la un capăt al cloud-ului pentru analiză, șansa de a preveni o spargere în cuva poate fi pierdută.

Figura 1.23 – Internet of Things și Rețeaua – Fog.

Manevrarea cu success a volumului, varietății și vitezei datelor IoT este realizabilă doar prin utilizarea unui nou model de tehnică de calcul. Principalele cerințe sunt:

Minimizarea latenței: milisecundele contează când se dorește prevenirea închiderii liniilor de producție sau prevenirea căderilor de tensiune. Analizând datele în vecinătatea dispozitivului care le-a colectat poate face diferența între prevenirea unui dezastru și cascadarea unei căderi de sistem.

Conservarea lățimii de bandă a rețelei: Platformele petroliere din larg generează date de dimensiunea a 500 GB săptămânal. Avioanele comerciale generează date în valoarea de 10 TB pentru fiecare 30 de minute de zbor. Transportarea acestor vaste cantități de date de la mii sau sute de mii de dispozitive conectate la cloud nu este o soluție viabilă. Această operațiune nici nu este necesară, deoarece multe analize critice nu necesită procesare scalară în cloud sau stocare.

Probleme de securitate ale adreselor: Datele din IoT trebuie protejate atâta în timpul transmiterii cât și în restul timpului. Aceasta necesită monitorizare și răspuns automat pe tot timpul desfășurării posibilului atac fraudulos: înainte, în timpul actului și după terminarea acestuia.

Operare fiabilă: Datele IoT sunt utilizate din ce în ce mai mult pentru luare deciziilor care privesc securitatea cetățenilor și infrastructurii critice. Integritatea și disponibilitatea infrastructurii și datele nu trebuie să fie îndoielnică.

Colectarea și securizarea datelor de-a lungul unei zone întinse geografic cu diferite condiții de mediu: Dispozitivele IoT pot fi distribuite pe suprafețe de mii de kilometri. Dispozitivele dispuse în zone cu condiții dure precum autostrăzi, linii ferate, stații de măsurare în teren sau autovehicule necesită o structură de anduranță. Această condiție nu este necesară în cazul dispozitivelor utilizate în medii interioare controlate.

Arhitectura tradițională de tip cloud nu îndeplinește toate aceste cerințe. Abordarea predominantă este – mutarea tuturor datelor de la granițele rețelei către centrul de date pentru procesare – adaugă o foarte mare latență. Traficul generat de mii de dispozitive va depăși capacitatea lungimii de bandă foarte curând.

Reglementările industriale și îngrijorările pentru securitate interzice stocarea anumitor tipuri de date în afara zonei private. În plus, serverele cloud comunică doar prin intermediul IP, fără a utiliza toate celelalte protocoale integrate în dispozitivele IoT. Locația ideală de a analiza majoritatea datelor IoT este în mărginimea dispozitivelor care le produc și acționeaza asupra lor, aceasta se denumește Fog Computing.

Noțiunea de “fog” extinde pe aceea de “cloud” pentru a fi mai aproape de dispozitivele care produc și acționează asupra datelor conținute de IoT. Aceste dispozitive, de numite noduri fog, pot fi amplasate oriunde având o conexiune la rețeaua de date: pe o pardoseală dintr-o fabrică, pe vârful unui stâlp de tensiune electrică, de-a lungul unei linii ferate, într-un autovehicul sau pe o platformă petrolieră. Orice dispozitiv care conține tehnică de calcul, stocare și conectivitate la rețeaua de date poate îndeplini funcția de nod fog. Exemplele sunt multiple conținând controlere industriale, switch-uri, rutere, servere integrate, și camere de supraveghere.

IDC estimează că suma datelor analizate de la dispozitivele care sunt conectate la IoT se apropie de valoarea de 40%. Acesta este o motivație bună deoarece analiza datelor IoT aproape de locațiile unde sunt generate minimizează foarte mult latența. Sistemele descarcă trafic de mulți gigabytes din miezul rețelei, și păstrează datele signifiante în interiorul acesteia.

Aplicațiile de tip fog sunt diverse precum “Internet of Things” este (Figura1.24). Ceea ce acestea au în comun este este monitorizarea sau analiză în timp real a datelor de la dispozitivele conectate la rețea urmată de inițierea unei acțiuni. Acțiunea poate include comunicațiile mașină către mașină (M2M), sau comunicațiile om către mașină (HMI). Exemplele includ încuierea unei uși, schimbarea setărilor unui echipament, activarea sistemului de frânare la tren, apropierea imaginii la o cameră video, deschiderea unei vane ca răspuns la citirea valorii unei presiuni, crearera unui grafic de tip bare longitudinale, sau trimiterea unei alerte către un tehnician pentru a intenta o reparație preventivă. Aplicațiile din producție de tip fog proliferează rapid în manufacturare, petrol și gaze, utilități, transport, extracții miniere și sector public.

Dezvoltatorii portează sau scriu aplicațiile IoT pentru nodurile fog de la granițe rețelei. Cele mai apropiate noduri fog de granițe rețelei ingera datele de la dispozitivele IoT.În acel moment – crucial – aplicațiile de tip fog IoT redirecționează diferitele tipuri de date către locațiile optime pentru analiza, precum în tabelul de mai jos:

– Datele cele mai senzitive ca durată de timp sunt analizate în nodul de rețea cel mai apropiat de dispozitivele care le generează. Într-o rețea de distribuție Cisco Smart Grid, de exemplu, cerințele cele mai senzitive din punct de vedere al duratei de timp sunt cele de verificare a operării corecte a protecției și a buclelor de control. Așadar, nodurile de rețea cele mai apropiate de rețeaua de senzori pot cerceta semnalări ale problemelor și apoi acestea pot fi prevenite prin transmiterea comenzilor de control către actuatoare.

– Datele care mai pot aștepta intervale de câteva secunde sau minute sunt transmise către un nod de agregare pentru analiza și luare unei acțiuni. În exemplul de Smart Grid, fiecare substație poate avea nodul sau propriu de mod de agregare care raportează statusul operațional al fiecărui element furnizor din aval sau lateral.

– Datele care sunt mai puțin senzitive sunt trimise către cloud pentru analiză istorică, mari colecții de date de analiză, și stocare de lungă durată. De exemplu, fiecare din miile sau sutele de mii de noduri fog poate trimite sumare periodice de date de tabel către cloud pentru analiză istorică și stocare.

1.4.1 Metoda de funcționare în Fog și în Cloud

Noduri Fog:

Primesc informații de la dispozitivele IoT utilizând oricare protocol, în timp real.

Rulează aplicații dedicate IoT pentru analiza controlului în timp real, cu un răspuns de câteva milisecunde.

Furnizează stocare tranzitorie, de regulă 1-2 ore.

Trimite sumare de date periodic către cloud.

Platforma de tip Cloud:

Primește și admite sumarele de date de la mai multe noduri de tip fog.

Analizează datele din IoT și datele obținute de la alte surse pentru a câștiga o mai bună perspectivă de afaceri.

Poate trimite noi reguli aplicative către nodurile fog bazate pe aceste perspective.

Figura 1.24. Principii funcționare Rețea – Fog – Cloud

1.4.2 Beneficiile Tehnicii de calcul Fog

Extinzând noțiunea de cloud mai aproape de dispozitivele care generează și acționează asupra datelor, prezintă o mai bună idee de afaceri în următoarele posibilități:

Agilitate de afaceri mai bună: Cu programele potrivite, dezvoltatorii pot construi rapid aplicații și le pot instala oriunde este necesară aceasta. Aplicațiile Fog programează mașinile să opereze în modul în care clientul are nevoie.

Securitate îmbunătățită: Protejarea nodurilor fog utilizând aceeași politică de securitate, controale, și proceduri care au fost utilizate și în alte zone ale mediului IT. Se pot utiliza aceleași sisteme fizice de securitate și soluții cybersecurity.

Perspective profunde, cu controlul confidențialității: Analiza datelor senzitive la nivel local în locul transmiterii acestora către cloud pentru analiză. Se pot monitoriza și controla intern dispozitivele care colectează, analizează și stochează datele.

Costuri de operare reduse: Conservarea lățimii de bandă a rețelei prin procesarea datelor selectate local în locul transmiterii lor către cloud pentru analiză.

Soluția celor de la Cisco prezentat ca noua tehnologie de calcul se numește “Cisco Fog” (Figura 1.25). Aceasta reușește să împlinească toate cerințele necesare IoT întrucât face parte din Cisco IoT System, un set cuprinzător de produse utilizate în dezvoltarea, accelerarea valorilor, și inovația prin Internet of Things. Soluția Cisco Fog computing deține calitățile ncesare pentru:

Conectarea oricărui dispozitiv în IoT.

Securizarea dispozitivelor IoT și protejarea datelor produse în timpul transmiterii între granițele rețelei și cloud.

Dezvoltarea și lansarea rapidă a aplicațiilor de tip fog.

Direcționarea datelor către cea mai bună locație în scopul analizării: nodurile fog din cetrul de date a platformei cloud. Alegerea celei mai bune redirecționări este dependentă de senzitivitatea la timp precum și de cerințele de securizare a datelor.

Accesare automată și administrare simplificată al unui număr mare de noduri fog răspândite pe arii foarte mari.

Figura 1.25 – Structura Rețea Cisco – Fog

Cisco oferă toate programele și utilitarele necesare dezvoltării unei aplicații Fog precum și de la alți parteneri, incluzând următoarele aspecte:

Conectivitate în rețea;

Securitatea cibernetică și fizică;

Dezvoltarea și găzduirea aplicațiilor Fog;

Analize de date;

Administrare și automatizare.

Conectivitate în rețea

Se poate alege dintr-o gamă variată de noduri fog pentru a conecta diferite dispozitive IoT. Opțiunile includ rutere Cisco, switch-uri, puncte de acces wireless, camere de supraveghere și servere Cisco Unified.

Toate nodurile Cisco Fog dețin tehnologia de calcul computațional, interfețe de rețea, și capacitatea de stocare care simplifică administrarea și reduce consumul de resurse și cerințele de spațiu. Pot fi dezvoltate și îmbunătățite aplicațiile IoT în cloud, iar apoi pot fi lansate pentru a rula în cloud și în fog. Aceeași aplicație poate rula în diferite tipuri de noduri fog fără alte modificări necesare.

Securitatea cibernetică și fizică

Datele IoT necesită să fie securizate pe nodurile de fog precum și în timpul transmsiterii acestora către cloud. Pentru a controla accesul fizic la nodurile fog amplasate la distanță, precum substații utilitare sau amplasate de-a lungul căilor ferate sau autostrăzilor, se utilizează camerele de supraveghere Cisco și soluții de control acces.

Protejarea datelor pe durata transmisiei între noduri și cloud se face prin utilizarea soluțiilor Cisco de securitate cibernetică. Acestea furnizează protecție înainte, în timpul desfășurării și după producerea unui posibil atac. De exemplu se poate detecta activitatea anormală utilizând Cisco Netflow, Cisco TrustSec și Cisco Identity Services Engine(ISE). Prevenirea breșelor de securitate se face prin Cisco Advanced Malware Potection. Cu ajutorul Cisco Intrusion Prevention System (IPS) se întărește automat securizarea politicilor de securitate luând în atenție deosebită tinta amenințării. De regulă în mediile IT, răspunsul la o amenințare de atac poate fi carantina sau oprirea sistemului țintă. În mediul tehnologic operațional, răspunsul la aceeași amenințare poate se manifesta ca o alertă către operatorii de sistem pentru a lua cea mai bună acțiune bazată pe cunosțiintele deținute.

Platforma Aplicației

Pentru a simplifica dezvoltarea aplicațiilor fog, s-a replicat modelul de dezvoltare familiar al aplicației de cloud. Acesta functioneaza astfel:

IaaS: Găzduiește aplicații noi sau existente pe nodurile fog. Utilizează API-ul Cisco IOx care combină sistemul de operare Cisco IOS (Figura 1.26) si Cisco IOx este cel care rulează actualmente în majoritatea routerelor Cisco. Un alt producător de exemplu ar putea folosi Cisco IOx pentru a găzdui programe Rockwell FactoryTalk pe routere de producție în uzine. Utilizând API-uri Cisco IOx, aplicațiile fog pot comunica cu dispozitivele IoT care pot folosi oricare protocol. Aplicațiile fog pot de asemenea să trimită date IoT către cloud prin translatarea protocoalelor non-standard și proprietare în IP.

PaaS: Dezvolatarea aplicațiilor fog. Primul program de tip IoT PaaS, denumit Cisco DSX, simplifica dezvoltarea aplicațiilor fog în câteva moduri:

Abstractizarea dispozitivelor: Aplicațiile fog necesită să comunice cu multe tipologii de dispozitive IoT. Crearea unei aplicații separate pentru fiecare senzor de temperatură al unui furnizor, spre exemplu, ar fi de nedorit. Cisco DSX salvează dezvoltatorii de aplicații de acest efort prin oferirea unei vizualizări abstractizate a dispozitivelor IoT.

Oferă suport pentru multiple medii de dezvoltare. Aplicațiile IoT care se livrează în model “mașina ca serviciu“ sunt dezvoltate în medii diferite și limbaje de programare diverse. Cu Cisco DSX, nodurile fog suportă multiple medii de dezvoltare.

Administrarea simplificată a aplicațiilor fog. Managerierea unui număr crescător de aplicații fog ar fi de nedorit. Cisco DSX simplifică acest proces și pe cel de întărire automată a politicilor de securitate.

SaaS: Aplicația oferă și MaaS. Folosind Cisco SDX , un robot furnizor poate specifica funcțiile pe care un client le poate utiliza. Furnizorul poate oferi acces ulterior clientului la atribute adiționale printr-o simplă modificare de soft din sediul central.

Figura 1.26. Schema de funcționare Cisco IOx

Analize de Date: Serviciile Cisco Fog-Data

Administrarea volumului, varietății și vitezei datelor IoT se poate face prin utilizarea serviciilor Cisco Fog-Data.Aceste servicii direcționează datele către locul potrivit pentru analiza -cloud sau fog- bazându-se pe politicile folosite (Figura 1.27). Analizarea datelor IoT aproape de locul unde sunt colectate minimizează latența și decongestionează gigabytes de date sau trafic de rețea din miezul rețelei (păstrează datele importante în interiorul rețelei).

Pentru ințelegerea importanței serviciilor Cisco Fog-Data, este necesară o abordare de tip multi-schimbătoare de linii, precum cele de linii feroviare. Trimițând în mod constant flux video prin rețeaua celulară va fi în mod cert foarte costisitor. Așadar, majoritatea operatorilor stochează datele video de la sistemele instalate pe tren, așteptând să facă transmisia până când trenul sosește la un peron dotat cu tehnologie Wi-Fi. Dacă trenul deraiază, totuși fluxul video va deveni disponibil deoarece siguranța pasagerilor este în pericol. Utilizând serviciile Cisco Fog Data, dezvoltatorii de aplicații pot scrie o regulă în program care citește și recunoaște dacă senzorii detectează frânarea bruscă sau balansarea trenului, lansând imediat fluxul video pe rețeaua celulară către centrul de operare.

Figura1.27 – Schema funcționare servicii Cisco – Fog – Cloud.

Administrare și Automatizare

În funcție de industrie și aplicație, nodurile fog pot fi în număr de la câteva sute până la câte mii, sau zeci de mii. Furnizarea automatizată și administrarea simplificată a nodurilor se realizeaza utilizând aplicații de administrare Cisco.

Organizațiile care dețin rețele distribuite în teren, incluzând utilitățile și transporturile precum și companiile de extracții miniere, pot administra nodurile fog utilizând sisteme de management Cisco Connected Grid Network (CGNMS), care facparte din suita de programe Cisco Industrial Operations Kit (IOK). Cisco IOK este o soluție tip dispozitiv unic: un server Cisco UCS cu servicii virtualizate, precum ar fi rutere virtuale; administrare de rețea; securitate; autentificare, autorizare și administrarea de conturi (AAA); un server de rețea și un instrument de autoconfigurare. Serverele virtualizate și ruterele reduc implemenatrea în avans precum și costurile de întreținere; scripturile incluse reduc timpul de configurare a serviciilor de rețea de la câteva săptămâni la câteva zile.

Producătorii administrează nodurile de rețea proprii utilizând intrastructura Cisco Prime. Administratorii utilizează o singură interfață pentru a administra rețeaua, nodurile fog, aplicațiile și utilizatorii.

1.5 Cazuri de Utilizare

Linii ferate – Informații inteligente în timp real care descriu condițiile și evenimentele din tren, de pe șine, de pe peroane iar centrul de operare poate ajuta pasagerii prin:

● Mărirea siguranței pasagerilor: Analiza și corelarea datelor de la camerele de anduranță amplasate pe trenuri și pe peroane. Monitorizarea senzorilor de la roți și a frânelor pentru a determina când componentele au nevoie de mentenanță înainte ca aceste defecte să cauzeze un accident. Transmiterea automată a fluxului video de la camerele de supraveghere de la bord către centrul de operare dacă senzorii detectează un tren deraiat.

● Prevenirea atacurilor cibernetice pe sisteme operaționale critice: În acest caz se vor lua acțiuni automatizate precum suspendarea operațiunilor sau transferul controlului către un sistem de rezervă.

● Alertarea mecanicilor de tren în legătură cu condiții dificle de pe drumul în parcurgere: Nodurile fog colectează date de la senzorii aflați pe șinele de tren și pe trenuri pentru a detecta starea condițiilor de drum. Conductorii sunt alertați automat astfel încât ei să poată reduce viteza la nivele de siguranță. Supervizorii primesc de asemenea alerte dacă trenul este operat într-un mod nesigur.

● Sporirea confortului călătorilor: Furnizarea de Internet prin Wi-Fi în vagoanele de tren. Punctele de acces se vor conecta la nodurile fog instalate la bord. În plus față de furnizarea accesului la Internet prin Wi-Fi, nodurile fog se conectează cu nodurile Wi-Fi amplasate lângă linia ferată pentru a transmite informații în timp real despre variatele sisteme instalate pe tren.

Domeniul producției

● Sporirea controlului liniilor de producție: Schimbarea rapidă a liinilor de producție și introducerea unor noi produse. Nodurile fog pot transforma instrucțiunile provenite tip IP în instrucțiuni specifice protocoalelor utilizate de echipamentele de control ale producției.

● Reducerea timpul de indisponibilitate: Evitarea indisponiblității unor echipamente costisitoare prin efectuarea mentenanței predicitive. Nodurile fog colectează date de la mașinile industriale și raportează semnalele antecedente apariției problemelor.

● Securizarea mașinilor și a datelor: Analizarea datelor de la dispozitivele aflate în rețea pentru a detecta semnale incipiente ale atacurilor de rețea care pot afecta siguranța personalului sau a fabricii.

● Autorizarea accesului la mașinile industriale: Înaintea de oferirea accesului la o mașină, se va verifica dacă identitatea persoanei este cea comunicată și dacă este autorizată să utilizeze acea mașină specifică.

● Restaurarea energiei electrice mai rapid după o defecțiune: Nodurile fog colectează date de la stația electrică, din rețeaua de distribuție, substații, și puncte de transformare pentru conectarea clienților. Ele analizează in mod continuu datele pentru a identifica problemele incipiente și alertează operatorul de sistem.

● Detecția breșelor de securitate fizice cauzate de intrarea prin efracție: Camere ranforsate amplasate la stații diferite detectează breșele de securitate, și corelează evenimentele petrecute la multiple locații.

● Detecția potențialelor breșe de cybersecurity: Răspunsul automat ajută la prevenirea virusării care poate pune în pericol securitatea informațiilor.

1.6 Tehnologii și instrumente utilizate în virtualizarea SDN

1.6.1 OpenFlow

Openflow este o platformă de comunicație standard de rețea cu profil deschis care permite cercetătorilor să ruleze protocoale experimentale în rețele de zi cu zi. Openflow este introdus ca un element inovator în echipamentele de transmisie a datelor prin Ethernet precum switch-uri, rutere și echipamente de acces wireless și furnizează o nișă standardizată care permite cercetătorilor să ruleze experiemente fără a solicita producătorilor de echipamente să își expună programarea internă a echipamentelor de comunicație (Figura 1.28).

În utilizarea echipamentelelor clasice tip ruter sau switch, observăm că transmiterea rapidă a pachetelor de date (plan de transmisie ) și deciziile de rutare de nivel înalt (planul de control) sunt implementate în același echipament. Un echipament switch cu protocol OpenFlow separă aceste două funcțiuni în planuri distincte. Porțiunea care conține planul de transmisie a datelor rămâne implementata în switch, în timp ce planul de control al pachetelor de date este atribuit unui echipament de control, tipic unui server standard. Switch-ul OpenFlow și controlerul comunică prin intermediul protocolului OpenFlow, care definește mesajele precum: “packet-received,send-packet-out, modify-forwarding-table” și “get stats”.

Planul de transmisie a datelor dintr-un Switch OpenFlow prezintă o tabelă de abstractizare a fluxului de date nedefinită; fiecare entitate a fluxului de date din tabela conține un set de câmpuri ale pachetelor cărora corespund și o acțiune de executat (“send-out-port, drop”) . În momentul sosirii unui pachet de date nou într-un Switch OpenFlow, pentru care nu există flux de date corespunzător în tabelă, acesta trimite pachetul de date către controlerul său care va calcula și va lua decizia corespunzătoare manevrării acestui pachet: poate să îl anuleze, sau să atribuie un flux către switch care îi comunică cum să direcționeze pachetele de date similare ce pot sosi în viitor.

Platforma OpenFlow permite utilizatorului să dezvolte procotocoale inovatoare de rutare și transmiteri de pachete de date într-o rețea. Aceasta este utilizată în aplicațiile din domeniul mașinilor virtuale mobile, rețele cu securizare înaltă și rețele mobile bazate pe următoarea generație de IP.

Figura 1.28 – Schema principiu OpenFlow.

1.6.2 Switch-uri emulate virtual

Un switch Openflow este o platformă software sau un dispozitiv fizic care transmite pachete de date într-un mediu de rețea definit pe aplicații software (SDN). Switch-urile OpenFlow sunt bazate pe protocolul de comunicație OpenFlow sau oferă suport pentru acesta.

1.6.2.1 LINC OpenFlow Switch

LINC (Link Is Not Closed) este un switch OpenFlow emulat prin program dezvoltat prin utilizarea Erlang, un limbaj de programare funcțional care este implementat ca un nod de tip Erlang în spațiul pentru utilizator al sistemului de operare. LINC OpenFlow Switch are următoarele caracterisitici:

• Suporta protocoalele OpenFlow Protocol 1.2 și OpenFlow Protocol 1.3.

• Rulează multiple switch-uri logice pe platforma de switch modulată OpenFlow.

• Suport pentru protocolul administrativ OF-Config 1.1.1.

• Arhitectura modulară și ușor extensibilă.

LINC este o platformă de transmisie a datelor de tip open-source disponibilă prin implicarea comunității de dezvoltatori FlowForwarding.Org care promovează implementări gratuite tip open source ale licențelor Apache 2 bazate pe specificațiile OpenFlow (Figura 1.29). LINC este dezvoltat pentru a deservi ca și implementare de referință ce include setul întreg de caracteristici și specificații OpenFlow. Primele obiective obținute în urma dezvoltării aplicației LINC OpenFlow Switch sunt cele care ajută utilizatorii să dezvolte programul LINC în mod rapid și fără costuri pe platforma COTS, pentru a evalua distribuțiile de configurare OpenFlow și OF-Config, și pentru a furniza un răspuns către ONF (Open Networking Foundation).

LINC este scris în limbajul Erlang, limbaj dezvoltat de compania Ericsson. Acesta este un limbaj funcțional multi-scop care a fost construit de la început pentru a scrie aplicații soft real-time, distribuite, scalabile și cu toleranță la erori. Caracterisiticile limbajului Erlang prezentate în continuare au contribuit la conceperea șu dezvoltarea rapidă a aplicației LINC:

• Erlang OTP (Open Telecom Platform) reprezintă o colecție mare de librarii pentru Erlang care furnizează soluții pentru multe din problemele comune întâmpinate în rețelistica și sistemele de telecomunicații.

• Erlang asigură capabilități de administrare a biților extrem de conveniente ceea ce îl face corespunzător pentru operarea protocoalelor și comunicațiilor de cel mai jos nivel.

• Erlang integrează suport pentru crearea și administrarea proceselor cu scopul de a simplifica programarea concurentă.

Figura 1.29 – Schema principiu switch LINC.

1.6.2.2 OpenvSwitch

OpenvSwitch este o aplicație software pe mai multe nivele ce rulează sub licența de tip open source Apache 2. Scopul principal al aplicației este să ofere utilizatorului posibilitatea de a implementa o platformă de switch la calitate industrială care oferă suport pentru interfețe de administrare standard și permite funcțiilor de transmitere a datelor să fie controlate și extinse prin programare.

OpenvSwitch poate funcționa în mod fiabil ca un switch virtual în mediile de virtualizare VM. Un alt beneficiu adițional utilizării interfețelor vizibile și controlului standardizat la nivelul de virtualizare al rețelei, este proprietatea aplicației de a fi distribuită și implementată cu success în multiple servere fizice. Open vSwitch oferă suport multiplelor tehnologii de virtualizare bazate pe Linux inclusiv Xen/ XenServer, KVM și VirtualBox.

Cea mai mare parte a codului este scris în platforma-independenta a limbajului C și poate fi portata către alte medii de dezvoltare foarte ușor. Actuala versiune lansată a aplicației OpenvSwitch prezintă următoarele caracteristici:

Model VLAN (Vvirtual Local Area Network) standard 802.1Q cu porturi de tip „access”și „trunk”;

Conectvitatea NIC (Network Interface Card) cu sau fără LACP (Link Aggregation Control Protocol) pe switch-ul cu flux de transmisie;

NetFlow (program de vizualizare trafic), sFlow(R) (monitorizare traffic retea), și redundanță pentru vizibilitate crescută;

Configurare QoS (Quality of Service), plus politici de securitate;

Geneve (librarie), GRE (Generic Routing Encapsulation), GRE cu IPSEC (Iternet Protocl Security), VXLAN (Virtual Extensible LAN), și tunelare LISP (limbaj de programare);

Administrarea erorilor de conectivitate 802.1ag;

OpenFlow 1.0 plus numeroase extensii;

Bază de date configurabile tranzacțional cu conexiuni C și Python;

Direcționare a pachetelor de înaltă performanță utilizând un modul de kernel Linux.

Modulul de kernel Linux (Figura 1.30) inclus oferă suport pentru versiuni începând de la Linux 3.10 și mai sus. OpenvSwitch poate să funcționeze, cu un mic sacrificiu de performanță, în mod integral în spațiul de utilizator, fără a fi necesară asistenta unui modul de kernel. Acest tip de implementare este mai simplu de portat decât versiunea aplicației de switch bazată pe kernel și este utilizată în mod experiemental.

Figura 1.30 – Schema principiu OpenvSwitch.

1.6.3 Aplicații de control pentru switch cu protocol OpenFlow

Un controler OpenFlow reprezintă o aplicație software care administrează controlul fluxului de date într-un mediu SDN. Majoritatea aplicațiilor de control SDN sunt construite pe protocolul OpenFLow, ele deservind funcția de sistem de operare pentru o rețea de comunicație.

Protocolul OpenFlow conectează aplicația de control la dispozitivele fizice din rețea astfel încât sistemul de operare de pe controler să poată transmite switch-urilor de date destinațiile unde vor fi transmise pachetele de date. Controlerele utilizează protocolul OpenFlow pentru a configura dispozitivele din rețea și pentru a selecta cea mai bună cale de transport pentru aplicațiile comunicante.

Transportul pachetelor de date este administrat în mod dinamic și la un nivel mult mai detaliat datorită implementării planului de control al rețelei în aplicația software, element distinctiv față de funcționarea din sistemele dispozitivelor fizice de rețea clasice.

1.6.3.1 Controlerul SDN OpenDaylight

Aplicația OpenDaylight este o platformă SDN care oferă suport pentru integrarea oricărui tip de rețea indiferent de dimensiunea acesteia.

Controlerul face posibililă utlizarea serviciilor de rețea într-o varietate de echipamente fizice din mediile companiilor producătoare. Aceasta arhitectură de microservicii permite utilizatorilor să controleze aplicațiile, protocoalele și conexiunile și oferă posibilitatea conectivității între consumatorii externi și furnizori. Dezvoltarea platformei OpenDaylight este realizată de o comunitate răspândită global care creează și implementează îmbunătățiri majore la fiecare jumătate de an oferind suport pentru cele mai largi cazuri de utilizare SDN în domeniul industriei (Figura 1.31).

Majoritatea rețelelor de comunicație au fost dezvoltate pentru a furniza resurse relativ suficiente pentru volumele de trafic și transport de date actuale. Prin intermediul SDN se pot optimiza rețelele existente astfel încât să fie fiabile la nivelul cerințelor din zilele noastre, și să fie mult mai adaptabile la apariția solicitărilor viitoare. Deoarece nu există doar o singură implementare în mediul SDN, OpenDaylight se dezvoltă ca o platformă comună care poate fi configurată în orice mod pentru a răspunde cu succes oricăror necesități de viteză și volum al datelor dintr-o rețea. Controlerul integrează standarde și protocoale de tip open source și API-uri(interfața programabilă a aplicației) open source pentru realiza o platformă SDN care poate transforma o rețea clasică într-una programabilă, inteligentă și adaptabilă.

Codul aplicației de control OpenDaylight a fost integrat și dezvoltat în peste 20 de soluții de comunicație și aplicații ale producătorilor din această industrie, putând fi utilizat prin intermediul unor servicii și firme de consultanță.

Figura 1.31 – Schema principiu controler OpenDaylight.

1.6.3.2 Controlerul SDN Ryu

Controlerul Ryu este o aplicație de rețea componentă a mediului SDN. Acesta furnizează componente software cu interfețe programabile ale aplicațiilor bine definite care vin în ajutor utilizatorilor doritori să dezvolte noi aplicații de control și administrare a unei rețele (Figura 1.32).Ryu oferă suport pentru mai multe protocoale de comunicație din aria de administrare a dispozitivelor de rețea, precum OpenFlow, Netconf, OF-config, etc. Pentru protocolul OpenFlow, Ryu oferă suport pentru versiunile 1.0, 1.2, 1.3, 1.4, 1.5 și pentru extinderile Nacira. Codul aplicatiiei este disponibil gratuit sub licența Apache 2.0.

Figura 1.32 – Schema principiu controler Ryu.

1.6.3.3 Controlerul SDN NOX

NOX este o platformă de control a rețelei care oferă o interfață de programare la nivel înalt prin care aplicațiile de control și administrare a rețelei pot fi dezvoltate. Aplicațiile Nox determină modul în care fiecare flux este rutat sau este abandonat din rețeaua de comunicație, controlerul fiind dezvoltat în principal pentru a controla unul sau mai multe echipamente de tip switch prin protocolul OpenFlow.

Raportat la mediile standard de dezvoltare a rețelelor (dezvoltarea ruterelor într-un mediu Linux sau administrând un mediu Linux), NOX oferă un model de programare centralizat pentru o întreagă rețea. NOX este dezvoltat pentru a suporta atât rețele business extinse alcătuite din câteva sute de switch-uri (având mii de potențiali utilizatori conectați) cât și rețele mai mici alcătuite din câțiva utilizatori conectați în rețea (Figura 1.33).

Mediul NOX dispune de aplicații ce posedă o proprietate de abstractizare a resurselor rețelei, inclusiv topologia rețelei și locația tuturor utilizatorilor detectați ca fiind conectați. Principalele obiective NOX sunt:

Furnizarea unei platforme care permite dezvoltatorilor și cercetătorilor să inoveze în rețelele personale sau business utilizând echipamentele fizice de rețea. Dezvoltatorii aplicațiilor în NOX pot să controleze toate conectivitatea din rețea inclusive transmisia, rutarea, selecția calculatoarelor și utilizatorilor care au access în rețea, în plus controlerul având opțiunea de a putea interveni în oricare flux de date transmis.

Oferirea unei funcționalități a rețelei de nivel superior (administrare, vizibilitate, monitorizare, controlul accesului, etc.) pe switch-uri achizitionate la costuri foarte reduse.

Distribuirea aplicațiilor software de rețea utilizabile către operatori. Versiunile curente încorporează administrarea centrală pentru toate switch-urile din rețea, controlul de admitere la nivelul de utilizator și gazdă și un controler de politici de rețea.

Dezvoltarea modelului central de programare pentru o întreagă rețea – un singur program poate controla deciziile de transmisie pentru toate switch-urile din rețea.

Aplicațiile pot fi scrise în limbajul C/C++ sau în Python, deoarece NOX oferă o platformă de programare pentru aplicații de un nivel înalt pentru OpenFlow precum și pentru alte funcții de control din rețea.

Figura 1.33 – Schema principiu controler NOX.

1.6.3.4 Controler SDN Floodlight

Controlerul Floodlight este o platformă de control de nivel business, licențiată Apache și bazată pe limbajul de programare Java care poate funcționa atât în switch-uri fizice precum și în switch-uri virtuale care au instalat protocolul OpenFlow. Această platformă este dezvoltată și întreținută de o întreagă comunitate de specialiști ce include și o echipă de ingineri de la compania Big Switch Networks.

Protocolul utilizat conferă posibilitatea controlerului să modifice comportamentul dispozitivelor din rețea printr-un “set de instrucțiuni de transmisie” bine definit (Figura 1.34 ).

Floodlight este proiectat să funcționeze cu toate dispozitivele de rețea care apar precum switch-uri, rutere, switch-uri virtuale și puncte de acces wireless care suportă standardul OpenFlow. Funcționalitățile principale ale acestui controler sunt:

Suport pentru sistem de încărcare modular ceea ce îi conferă proprietatea de a fi simplu de extins și îmbunătățit.

Ușurință în instalare și configurare cu dependințe minimale.

Suport pentru o variată gama de switch-uri virtuale și fizice compatibile cu protocolul OpenFlow.

Proiectat să ofere performanțe inalte – este o platformă ce rulează pe mai multe fire de execuție.

Poate administra rețele de tip OpenFlow combinate cu rețele non-OpenFlow, de asemenea putând administra și multiple noduri de rețea formate din switch-uri fizice OpenFlow.

Figura 1.34 – Schemă principiu controler Floodlight.