. Cap1final donesdn [609086]

13 – 13 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data
1. Structura rețelei de telefonie fixă în raionul Ialoveni

Odată cu apariția unor tehnologii ca cloud,virtualizarea funcțiilor de rețea, a devenit
posibil ca arhitectura rețelei unei companii să poată fi scalată rapid și ușor .
Aplicațiile ce rulează în rețea necesită resurse de calcul, de stocare și de rețea.
În mod tradițional, infrastructura de server e și de stocare e instalată și configurată de
administratorii de sistem și apoi separat, administratorii de rețea sunt răspunzători de conectarea
echipamentelor și integraea l or în rețea . Această abodare devine ineficientă în cadrul rețelelor
automatizate Mai mult decât atât, arhitectura tradițională a rețelei a fost proiectată pentru un
mediu static , în timp ce flexibilitatea rețelei este o nevoie din ce în ce mai actuală.
Aici intervine Software Defined Network (SDN) . SDN facilitează gestionarea și
integrarea mai ușoară a infrastructurii de rețea cu serverul și infrastructura de stocare. Drept
urmare, resursele necesare pentru implementarea aplicațiilor pot fi furnizate într -un mod flexibil.
Open Networking Fo rum(ONF) definește SDN ca o arhitectură
emergentă,dinamică,ușor de gestionat, eficientă din punct de vedere al costurilor și adaptabilă,
ceea ce o face ideală pentru caracterul dinamic al lățimii de bandă. Această arhitectură
decuplează fun cțiile de control și redirecționare a rețelei permițând controlul rețelei să devină
direct programabil, iar infrastructura de bază să fie abstractizată pentru aplicații și servicii de
rețea. Protocolul OpenFlow este protocolul de bază în SDN. Despre acest a vom discuta mai jos.
Pentru a înțelege conceptul de decuplare a celor 2 planuri: Data Plane și Control Plane
trebuie să înțelegem principiul de funcționare a unei rețele tradiționale prezentat ă în figura 1.
După cum se poate observa acesta are 3 component e:
Planul de date : Actul de a muta pachetul dintr -un port de intrare într -un port de ieșire
este responsabilitatea planului de date. Acesta este cunoscut și sub numele de Forwarding Plane .
De exemplu, în comutatoarele Ethernet, pachet ele care vin dintr -un port sunt transmise prin unul
sau mai multe dintre porturile rămase.
Planul de control : Folosind exemplul anterior, pentru a trimite pachetul către portul de
ieșire corect, este posibil ca planul de date să aibă nevoie de informații suplimentare. În cazul
comutatoarelor Ethernet, portul de ieșire este identificat folosind adresa MAC de destinație
învățată de switch . Acest act de învățare și conștientizare a topologi ei de rețea este
responsabilitatea planului de control. Planul de control învaț ă și adună informații despre rețea

14 – 14 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data folosind diverse protocoale. Într -un comutator, buclele de rețea sunt detectate folosind spanning
tree protocol . În rutare, protocolul OSPF ( Open Shortest Path Firs t) ajută la învățarea topologiei
rețelei. Lucrul important este că planul de date folosește informațiile construite de planul de
control.
Planul de management: În timp ce rețelele își fac treaba în procesarea și redirecționarea
traficului de date, este important să le monitorizezi starea de lucru și să le configurezi . Această
capacitate de a gestiona și controla un dispozitiv de rețea este responsabilitatea planului de
management. Mecanismele comune de gestionare a rețelelor includ interfața liniei de comandă
(CLI), protocolul SNMP ș.a. RESTful API folosind HTTP a câștigat în popularitate ca protocol
de plan de management recent. De obicei, administratorii de rețea sunt utilizatorii finali ai
capabilităților planului de gestionare.

Figura 1 : Arhitectura unei rețele tr adiționale
Aspectele cheie despre planurile unei rețele:
Pentru a înțel ege motivele migrării spre SDN trebuie să fie discutate următoarele aspecte
a celor 3 planuri dintr -o rețea tradițională.
Deciziile de comutare sunt luate local într -un dispozitiv de rețea, iar aceste decizii se
bazează pe planul de control.
Actul real de expediere a pachetelor trebuie să fie într -adevăr rapid, pentru a satisface
cerințele de performanță a rețelei. Aceasta este implementată folosind un hardware specializat
bazat pe Application -Specific Integrated Circuit(ASIC ).
Planul de control implică învățarea a mai multe dispozitive de rețea, cum ar fi
comutatoarele și routerele pentru cele mai comune scenarii. Este relativ mult mai lent decât
planul de comutare.

15 – 15 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data Toate dispozitivele de rețea trebuie să suporte protocoale standard pentru a învăța cu
exactitate topologia rețelei, conectivitatea și informațiile aferente. La rândul său, aceasta
înseamnă că entitățile planului de control trebuie să existe pe fiecare dispozitiv.
În situații cu mai mulți furniz ori, interoperabilitatea planului de control și a planului de
management este crucială pentru buna funcționare a rețelelor. O parte din protocoalele planului
de management, cum ar fi Simple Network Management Protocol (SNMP ), sunt necesare pentru
a rula pe dispozitivele de rețea. Cu toate ace stea, cel mai critic aspect al managementului este
funcțiile centralizate oferite de sistemele de gestionare a rețelei Element Management System și
Network Management System (EMS și NMS).

Provocări le cu care se confruntă rețelele tradiționale
După cum s -a văzut anterior, rețelele tradiționale sunt construite și operate pe baza celor
trei planuri de rețea. Rețelele au o natură statică și au fost configurate manual pe baza
solicitărilor de servicii. Să vedem acum ce provocări se confruntă în arhitectura tradițională a
rețelelor.
Provocările planului de control
Problema cea mai evidentă cu care se confruntă planul de control este aceea a
interoperabilității. Deși există standarde pentru majoritatea protocoalelor, suportul fiecărui
furnizor pentru standarde poate varia. Și chiar și pentru același furnizor, comportame ntul
protocolului ar putea diferi între versiuni. Acest lucru va duce la incompatibilitate și va limita
inteligența care poate fi construită folosind planul de control. Pentru optimizarea costurilor,
precum și flexibilitatea, operatorii de cloud nu salută dependența de un furnizor . Prin urmare,
este foarte important ca planul de control să fie robust și ‚deschis’ pe întregul cloud.
O altă problemă cu care se confruntă planul de control este aceea a sc alabilității . Am
văzut că entitățile control plane (proto coale și așa mai departe) rulează pe dispozitive de rețea.
Aceste dispozitive au resurse de calcul limitate, iar pentru rețelele la scară largă, prelucrarea
planului de control poate fi împiedicată din această cauză. Metodele tradiționale pentru scalarea
planului de control era actualizare hardware a dispozitivului complet, fie cel puțin placa de
procesare a planului de control de pe dispozitivul de rețea. În implementările cloud, aceasta va fi
o provocare serioasă, mai ales că apl icațiile și sarcinile de lucru virtualizate sunt menite să
varieze în funcție de cerere.
Provocările planului de management
În timp ce planul de control are protocoale standard care asigură interoperabilitatea de
bază, planul de management poate fi implem entat cu standarde complet proprii. Protocoalele,

16 – 16 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data cum ar fi SNMP, sunt utile, dar pentru o experiență mai bună a utilizatorilor, majoritatea ven-
dorilor își implementează propriile sisteme CLI și / sau Element Management Systems (EMS).
Acest lucru face ca managementul rețelelor multi -vendor să fie foarte greoi.
Implementarea bazată pe cloud și infrastructura corespunzătoare trebuie să fie extrem de
elastic ă. Aceasta înseamnă că resursele trebuie alocate și eliminate la cerere. Platformele cloud,
cum ar fi OpenStack, necesită furnizarea resurselor prin intermediul API -urilor pr ogramabile .
Acest lucru permite alocarea resurselor de calcul, stocare și rețea în mod dinamic și optim. Pro-
gramabilitatea în rețelele tradiționale a fost susținută prin automatiza rea comenzilor CLI sau prin
alte north -bound interfaces. Dar, datorită abordării tradiționale , a fost dificilă integrarea acestor
API-uri cu API -uri de calcul și de stocare.
Aplicațiile tradiționale necesitau hardware specializat în rețea, cum ar fi load balancere ,
firewall -uri și așa mai departe. Pe măsură ce aplicațiile au devenit virtualizate, a fost imperativ ca
funcțiile de rețea specializate să fie disponibile și în formă virtuală. Această tendință este denu-
mită în mod obișnuit ca Virtual Network Fu nction Virtualization (NFV). Aceasta înseamnă că
capabilitățile de rețea pot fi inițiate și implementate ca aplicații software, independent de hard-
ware -ul real. Pentru a susține această capacitate, platformele cloud necesită definirea rețelelor
folosind ab stractizări. Aceste abstractizări permit ca aplicațiile și resursele aferente să fie definite
ca entități software. Iar platformele cloud pot orchestra sau instantana aceste entități la cerere.

Arhitectura SDN
A fost analizată arhitectura tradițională a r ețelei și provocările cu care se confruntă. Să ne
uităm acum la o arhitectură tipică SDN și cum abordează aceste provocări.
În figura 2 e prezentată o arhitectură simplificată SDN în care planul de control este
centralizat într -un control ler. De asemene a, se consideră OpenFlow drept protocolul dintre planul
de control centralizat și planul de date. În timp ce OpenFlow este cel mai popular protocol SDN
între planul de control și planul de date, platformele SDN precum OpenContrail folosesc XMPP
și BGP .

17 – 17 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data

Figura 2: Arhitectura SDN
Îmbunătățirea planului de control cu SDN
În rețelele tradiționale, planul de control a fost distribuit și rulat pe fiecare dispozitiv de
rețea. Modelul SDN permite centralizarea planului de control . Acest plan de control centralizat
este practic o entitate so ftware denumită în mod obișnuit controler SDN. Prin centralizarea
planului de control, problema de interoperabilitate este abordată într -o mare măsură. Planul de
control centralizat programează dispozitivul folosind tehnologii precum OpenFlow. Toți
furnizo rii care acceptă protocoale precum OpenFlow pot fi ușor integrați în control erele SDN. În
plus, planul de date al dispozitivelor noi poate fi programat cu ușurință, deoarece baza de
informații a planului de control este disponibilă cu ușurință.
Problema sc alabilitășii este, de asemenea, abordată mai ușor cu un control ler centralizat.
Un control ler este, proiectat pentru a rula pe platforme hardware populare. De fapt, este posibilă
și rularea contro llerelor ca mașini virtuale. Acest lucru permite planului de control să se extindă
independent de scara planului de date și să utilizeze hardware ieftin.

Îmbunătăț irile planului de management cu SDN
Chiar și cu arhitectura tradițională a rețelei, funcționalitatea de gestionare a fost deja
centralizată ca sisteme de gestionare a rețelei. Cu arhitectura SDN, există avantaje suplimentare
în care interacțiunea planului de management cu planul de control poate fi suportată direct pe
contro ller. Acest lucru este foarte important atunci când sunt g estionate rețele mari și, de
asemenea, rețele multiv endor. Un alt beneficiu al control lerelor este modelarea sau abstractizarea
mai bună a funcționalității rețelei. Întrucât software -ul de management se ocupă acum de un
singur contro ller centralizat, putem susține interfețe programa bile mai solide, deoarece

18 – 18 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data complexitatea este ascunsă de planul de gestion are. Aceasta are ca rezultat planul de gestionare
care expune abstractizări de rețea care pot fi exploatate de platforme cloud precum OpenStack.

Modele de date și Protocoale
Modelele de date definesc structura, sintaxa și semantica datelor codifica te, în timp ce
formatele de codare definesc formatul pentru codificarea datelor oferind o reprezentare flexibilă
care poate fi citită de om. Vom analiza limbajului de modelare a datelor YANG (RFC 6020) .

YANG

RFC 6020 defineșt e YANG astfel: „YANG este un limbaj de modelare a datelor utilizat
pentru modelarea configurației și a datelor de stare manipulate de Network Configuration
Protocol (NETCONF), remote calls NETCONF și notificările NETCONF.”
Modelele de date YANG definesc structura, sintaxa, și semantica datelor codate.
NETCONF definește primitive pentru a codifica, vizualiza și manipula datele. YANG prezintă
formatul de date XML care poate fi citit de om pe care îl acționează NETCONF. Datele despre
nod sunt structurate ierarhic și oferă o separare a datelor de configurare și a datelor de stare. De
asemenea, definește un format de plasare a constrângerilor pe date și cadru pentru extensiile de
bază.
Modulul YANG conține informații despre antet, include, importuri, definiți i de tip de
date de element, configurare, declarație de date, subscrieri la notific ări și acțiuni RPC.
Pentru a vizualiza mai u șor structura unui fișier YANG se pot utiliza o serii de
instrumente. Unul din cele mai populare este pyang. Acesta este un program Python pentru
validarea modulelor YANG (RFC 6020). De asemenea, este utilizat pentru a converti modulele
YANG în module YIN echivalente .

Rezultatul comenzii pyang -f tree ietf -interfaces.yang este prezentat mai
jos.

19 – 19 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data

Figura 3: Reprezentarea unui fișier YANG în format tree

După cum se poate observa acesta este alcătuit din mai multe compartimente :
• Numele modulului YANG – reprezintă întregul fișier . yang
• Container – un grup de elemente grupate logic. În fiecare fișier exit ă cîte un
container pentru configurare și pentru starea elementului descris.
• Listă – fiecare container poate conține una sau mai multe liste cum ar fi o listă de
interfețe.
• Leaf – element al listei ce se referă la o caracteristică a elementului descri s
• Key – referin ța la fie care eleme nt din listă
• Tipul de Date – Tipul de date atribuit la Leaf
Înscrierele r w și ro provin de la Read and Write și respretiv Read -Only .

YIN

Reprezentarea XML a YANG este definită ca YANG Independent Notation (YIN). YIN
convertește declarațiile YANG în XML, păstrând structura și conținut ul YANG. Conversia este
fără pierderi și reversibilă, menținând echivalența semantică completă. Conversia instrucțiunilor
YANG în XML permite utilizarea analizatorilor XML, eliminând nevoia analizorului YANG.
Cu ajutorul aceluaiși tool pyang putem obține reprezentarea YI N a unui fișier YANG :
pyang ietf-interfaces.yang -f yin

20 – 20 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data

Figura 4: Reprezentarea parțiala a ietf -interfaces.yang în f ormat YIN

NETCONF

NETCONF (RFC 6241) definește un mecanism de Remote Call Procedure (RPC) baz at
pe XML pentru instalarea, manipularea și ștergerea configurației dispozitivelor de rețea. Datorită
conceptual din JunosScript codificat XML de la Juniper, bazat pe RPC JunosScript, NETCONF
este proiectat pentru a fi un operator de rețea și DevOps priete nos, cu costuri mici de implemen-
tare și întreținere. NETCONF operează la nivelul de configurare și management al rețelei.
NETCONF acceptă distincția dintre datele de configurare și datele privind starea
operațională a dispozitivului, are posibilitatea de a salva și restaura datele de configurare ale dis-
pozitivului și compară datele de configurare pe mai multe dispozitive. Suportă configurație ba-
zată pe tranzacții și configurare pe rețea bazată pe model pe mai multe dispozitive. Modelele de
tranzacție asigu ră coerența, independența și durabilitatea datelor de configurare. Acceptă orches-
trarea întârziată a datelor de configurare către dispozitiv, activarea întârziată a serviciului,
testarea și respingerea configurației și redarea configurației la versiunile anterioare.

21 – 21 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data

Figura 5: Stack -ul protocolului NETCONF
Protocolul NETCONF are o structură multilayer :
• Nivelul Conșinut(Conten t Layer) :Răspunde de configurările dispozitivelor și
stocarea notificarilor .
• Nivelul Opera ții(Operation Layer ): Set de operații pentru manipularea datelor
de configura re din stocul de date.
• Layer -ul mesaje RPC : Acceptă apeluri de procedură la distanță (RPC) și no-
tificări.
• Protoclo de transport securizat : Protocol de transport securizat bazat pe TCP
pentru transport de mesaje fiabile. Secure Shell (SSH) este opțiune oblig atorie și
TLS ca opțiune alternativă.
NETCONF oferă mecanisme pentru extinderea capabilităților dincolo de specificațiile de
bază definite în RFC 6241 (Writable -Running*, Candidate configuration*, Confirmed Commit,
Rollback -on-Error, Validate, Distinct Sta rtup*, și URL și XPath capabilities ). NETCONF Man-
ager (client) inițiază conexiunea cu serverul (dispozitivul) NETCONF cu un mesaj <hello> care
indică capacitățile clientului. Serverul răspunde cu un mesaj <hello> care conține capabilități le
dispozitiv ului. Prin aceste 2 linii echipamentele fac schimb de informație de bază despre capabil-
itățile lor, totodată acesta acționează ca un mechanism de extindere și modificare a capabilităților
curente.
RFC 5277 definește notificările evenimentului NETCONF, oferind un mecanism asin-
cron de livrare a mesajelor. Clientul NETCONF inițiază o cerere SUBSCRIBE pentru a primi
notificări despre eveniment, iar serverul NETCONF răspunde la solicitările SUBSCRIBE . Dacă
solicitarea este reușită, serverul anunță o apariție a even imentelor către clienții abonați la even-
iment.

22 – 22 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data Extensible Messaging and Presence Protocol (XMPP)
Extensible Messaging and Presence Protocol (XMPP) este o tehnologie deschisă pentru
comunicare în timp real, folosind limbajul extensibil de marcare (XML) ca format de bază pentru
schimbul de informații. În esență, XMPP oferă o modalitate de a trimite bucăți mici de XML de
la o entitate la alta în timp real.
Protocolul are definite metode care permit configurarea și eliminarea fluxurilor XML,
criptarea canalel or, autentificarea, gestionarea erorilor și primitive de comunicare pentru mesag-
erie, disponibilitatea rețelei („prezență”) și interacțiuni cerere -răspuns.
XMPP este utilizat într -o gamă largă de aplicații. Pentru a ne imagina posibilitățile sale,
este util s ă descompunem XMPP la nivel înalt în servicii și aplicații. Serviciile sunt definite în
două specificații principale publicate de Internet Engineering Task Force (IETF) , RFC 3920 și
RFC 3921 , RFC 6120 și în zeci de specificații de extensie publi cate de Fundația de Standarde
XMPP (seria „XEP”); aplicațiile sunt programe software și scenarii de implementare care sunt
de interes comun pentru persoane și organizații, deși serviciile de bază vă permit să construiți și
alte multe tipuri de aplicații.
XMPP poate oferi următoarele servicii:
• Criptarea canalului de comunicații
• Autentificare
• Prezență
• Contact list
• Mesagerie one -to-one
• Mesagerie multi -party
• Notificări
• Service Discovery
• Schimb de capabilități
• Formulare structurate de date
• Workflow Management
• Sesiuni media peer -to-peer

În baza serviciilor oferite putem constru i următoarele tipuri de a plicații
• Mesagerie Instantă
• Grupchat
• Gaming

23 – 23 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data • Controlul sistemelor
• Geolocație
• Middleware and cloud computing
• Data syndication
• Voice over IP

OPEN FLOW
OpenFlow este un standard deschis , un protocol de comunicații care permite planului de
control să funcționeze separat și să interacționeze cu planul de forwarding a mai multor dis-
pozitive dintr -un punct central, decuplarea rolurilor ducînd la o funcționalitate și o pro gramabili-
tate ridicat ă.
Componentele unui switch OpenFlow
Un Switch OpenFlow e alcătuit din una sau mai multe tabele de fluxuri și o tabelă de
grup care asigură comutara pachetelor și unul sau mai multe canale OpenFlow către un controller
extern(figura1). Switch -ul OpenFlow comunică cu control lerul și control lerul gestionează
switch -ul prin protocolul OpenFlow.
O tablel ă de grup este alcătuită dint -un grup de entități și permite switch -ului OpenFlow
să aplice metode de comutare(select,all) pentru grupul de entități vizat.
OpenFlow Controller este o entitate care interacționează cu switch -ul OpenFlow folosind
protocolul OpenFlow . În cele mai multe cazuri, un OpenFlow Controller este un software care
controlează logic mai multe switch -uri OpenFlow .
Prin protocolul OpenFlow control lerul poate adăuga/updata sau șterge intrări din tabela
de fluxuri în 2 moduri: reactiv(în baza pachetelor primite în procesul învățării topologiei ) sau
proaciv (fluxuri programate în pralabil) .
Într-o rețea OpenFlow,fiecare switch Open Flow conține cel puțin o tabelă de fluxuri și un
set de fluxuri în tabela dat ă. Un flux este un element dintr -un tabel de flux uri folosit pen tru a po-
trivi și prelucra pachetele. Conține un set de câmpuri de potrivire, o prioritate pentru precedența
de potrivire, un set de contoare pentru pachete și un set de instrucțiuni de aplicat .

24 – 24 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data

Figura 6 : Componentele unui switch OpenFlow
Potrivirea este procesul d e comparare a unui set de antete din pachetet cu cîmpurile de
potrivire a unei intrări de flux din pipeline.
Un cîmp de potrivire este parte a unui flux. Drep t cîmpuri de potrivire pot servi mai multe
antete a pachetului(portul ingress,metadata). În une le cazuri un cîmp poate lua valoare ‘wildcard’
adică se poate potrivi cu orice valoare.
Un pachet de instrucții aplicat e atașat la fiecare intrare de lux și descriu modul de
procesare OpenFlow ce va avea loc în cazul cînd un pachet se potrivește cu o intrare de flux.
Acesta poate modifica procesare pipeline -ul cum ar fi direcționarea pachetului spre o altă tabelă
de fluxuri sau conține un set de acțiuni ce se adaugă la cel existent,sau setul de acțiuni poate fi
aplicat imediat.
Pachetul va începe mai întâi în ta belul 0 și va verifica intrări le în funcție de prioritate.
Cea mai mare prioritate se va potrivi mai întâi (de exemplu, 200, apoi 100, apoi 1). Dacă fluxul
trebuie să continue către un alt tabel, instrucțiunea goto îi spune pachetului să meargă la
tabelul specificat în instrucțiuni.
Această prelucrare a conductelor se va realiza în două etape, procesarea ingress și
prelucrarea engress (figura 7) .

25 – 25 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data

Figura7 : Prelucrearea ingress și cea en gress
Dacă se găsește o intrare potrivită, instrucțiunile asociate cu intrarea specifică a fluxului
sunt executate. Dacă nu se găsește nicio potrivire într -un tabel de fluxuri, rezultatul depinde de
configurația intrării fluxului Table -miss.
Intrarea în fluxul Table -miss este ultima din tabel, cu prioitate 0 și și poate să se
potrivească cu orice header . Acesta poate prinde tot traficul și acționa supra lui așa cum este
configurat. Poate trimite pachhetul la controller, poate face drop pachetului sau să continuie la
următorul tabel.( figura 8)

Porturile OpenFlow
Porturile OpenFlow sunt interfețele de rețea pen tru trecerea pachetelor între procesarea
OpenFlow și restul rețelei.
Un switch OpenFlow trebuie să suporte trei tipuri de porturi: fizice,logice și porturi
rezervate, dintre care cele fizice și logice sunt definite ca porturi standard OpenFlow.
Tot în port urile OpenFlow standard intră și porturile locale rezervate.

Porturile fizice sunt porturile care corespund unei interfețe hardware pe switch. În unele
implimentari switch -urile OpenFlow pot fi virtualizate pe un shitch hardware. În acest caz portul
fizic pe pe switch -ul hardware reprezintă un port virtual.

26 – 26 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data

Figura 8: Procesarea pachetelor în mediu OpenFlow
Porturile logice sunt porturile ce nu corespun direct unei inerfețe hardware. De exemplu
LAG( LinkAggregation Groups ),tuneluri,interfețe loopback. Acestea se pot mapa la o varietate de
porturi fizice.
Unica diferență între porturile logice și cele fizice este că pachetul asociat portului logic
trebuie completat cu un cîmp extra numit Tunnel -ID iar cînd un pachet primit pe un port logic e
trimis la controller ambele porturi,cel logic și cel fizic ce -i corespunde vor fi raportate către
controller.
Porturile rezervate sunt utilizate pentru ac țiuni generice de forwading. Aceste porturi
sunt utilizate pentru transmiterea pachetelor spre controller,flooding sau comutare non –
OpenFlow.
Există mai multe tipuri de porturi rezervate definite de standartul OpenFlow:
ALL,CONTROLLER,TBLE,IN_PORT, ANY,UNSET,LOCAL, NORMAL,FLOOD. Porturile

27 – 27 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data LOCAL,NORMAL,FLOOD sunt porturi opționale și depind de implimentare a switch -ului iar
restul porturilor sunt obligatorii.
Switch -urile Open Flow -only nu suport ă porturile FLOOD și cele de tip NORMAL.
Switchurile OpenFlow hibride le suportă. Acestea sunt utilizate în Switch -urile hibrite pentru a
permite interacțiunea dintre partea OpenFlow și cea non -OpenFlow a switch -ului.

Shitch -urile Open Flow -only și cele hibride

Switch-urile OpenFlow -only sunt switch -urile ce nu au implimentat planul de decizie și
au doar planul data și cel de forwarding. Astfel acestea cînd primesc un pachet necunoscut nu pot
lua o decizie locală și îl va ruta spre contr oller prin portul rezervat CONTROLLER. Traficul
poate fi procesat doar prin OpenFlow pipeline.
Switch -urile OpenFlow hibride suportă atît procesarea normală a pachetelor căt și cea
bazat ă pe protocolul OpenFlow.
Acest lucru înseamnă că pute tem utiliza c omutarea tradițională L2 Ethernet, izolarea
VLAN, rutarea L3, procesarea ACL și QoS prin planul de control local al switch -ului
conc omitent interacțion înd cu partea OpenFlow folosind diferite mecanisme de clasificare.
Deci e posibil scenariul în care jumate d in porturi sunt gestionate de mecanismul de
control local al switch -ului iar cealaltă jumate de un controler. Transferul pachetului de la un
port OpenFlow spre un port gestionat de planul de control locar se face prin porturile rezervate
NORMAL și FLOOD.

Figura 9: Comutarea pachetelor într -un switch hibrid

28 – 28 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data
Mesajele OpenFlow
Protocolul OpenFlow suportă 3 tipuri de mesaje fiecare cu sub -tipurile sale specifice
• Controller to Switch
• Asincrone
• Simetrice
Mesajele controller to switch sunt mesaje inițiate de controller și utilizate pentru a
gestiona și inspecta starea switch -ului.
Mesajele asincrone sunt mesajele inițiate de switch și utilizate pentru a informa
controlleru l despre evenimentele din rețea și schimbările de stare a switch -ului.
Mesajele simetrice pot fi inițiate de ambele părți (switch și controller) și trimise fără
solicitare.

Sub-tipuri de mesaje Controller – Switch – sunt mesajele inițiate de controller și nu
necesită răspuns de la switch.
– Features este utilizat de controller pentru a cere indentitatea și capabilitățile de bază
a switch -ului; switch -ul va răspunde cu un features -replay care specifică indentitatea
și capabilitățile sale de bază. Deobicei ac est schimb are loc la inițierea canalului
OpenFlow între controller și switch.
– Configuration este utilizat pentru a cere și seta parametrii de configurare a switch –
ului. Switch -ul poate doar răspunde la acest tip de cerere din partea controllerului.
– Modify -State este un mesaj trimis de controller pentru a grstiona starea switch -ului.
Scopul general acestor mesaje estea de a adăuga/șterge/modifica fluxurile sau
grupurile de fluxuri, a insera/șterge un set de acțiuni din tabelele OpenFlow și pentru
a seta pro prietățile porturilor.
– Read -State este un mesaj folosit de controller pentru a colecta informații de la
switch -uri cum ar fi:configurația curentă,statistici,capabilități.
– Packet -out sunt utilizate de controller pentru a trimite pachetele la portul specific at a
switch -ului și pentru a comuta pachetele primite prin mesaje Packet -in. Acestea
trebuie să conțină un pachet complet sau referința(ID -ul) din bufferul switch -ului.
Masajul trebuie de asemenea să conțină o listă de acțiuni ce se aplică în ordinea
specificată; o listă goală de acțiuni duce la drop packet.

29 – 29 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data – Barrier sunt mesajele de tip cerere/răspuns utilizate de controller pentru a primi
confirmări că cerințele au fost îndeplinite sau pentru a primi notificări despre
operațiuni finalizate.
– Role -Request este utilizat de controller peentru a cere/seta rolul canalului său
OpenFlow , a cere sau seta Controller ID. Acesta este util atunci cînd un switch se
conectează la controllere multiple.
– Asynchronous -Configuration se utilizează de controller cu scopul de a cere/seta un
filtru adițional a mesajelor asincrone ce le va primi pe canalul său OpenFlow. Acest
tip de mesaj devine util atunci cînd se utilizează controllere multiple. Deobicei acest
schimb are loc în faza de stabilire și negociere a canalului OpenFlow.

Sub-tipuri de mesaje Asincrone sunt mesajele ce sunt trimise fără solicitare de la switch de
către controller. Switch -urile trimit mesajele asincrone spre controller pentru a informa
controllerul despre sosirea pachetelor sau schimbări de stare a switch -ului. Principalele mesaje
asincrone sunt descrise mai jos:
– Packet -in Prin acest mesaj se face transferul de control a pachetului de la switch spre
controller. Pentru aceasta se utilizează portul rezervat CONTROLLER. Alte
evenimente cum ar fi verificarea T TL(Time To Live) vor genera mesaje packet -in
spre controller.
– Flow -Removed informează controllerul despre ștergerea unei intrări din tabela de
fluxuri. Aces te mesaje su nt trimise doar pentru intrările cu flagul
OFPFF_SEND_FLOW_REM setat.
– Port -status informe ază controllerul despre o schimbare la nivel de port. Switch -ul va
trimite astfel de mesaje spre control ler atunci cînd i se cer configurațiile de port sau
schimările de stare a portului.
– Role -status informează controllerul despre sch imbarea rolului său (ma ster or slave)
în rețea. Acest lucru are loc atunci cînd un nou controller se desemnează master iar
switch -ul va trimite un mesaj role -status spre vechiul controller master.
– Controller -status – informează controllerul despre schimbul de stare a unui canal
OpenFlow. Switch -ul trimite acest mesaj către toate controllerele din rețea cînd se
înregistrează o schimbare a unui canal OpenFlow. Acest process ajută la înlăturarea
erorii dacă controllerele pierd capacitatea de a cominica între ele.

30 – 30 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data – Flow -monitor infomeaz ă controllerul despre schimbările din tabela de fluxuri. Un
controller poate defini un set de monitori pentru a urmări aceste schimbări la nivel de
tabele.

Sub-tipuri de mesaje Simetrice sunt mesajele trimise fără solicitări în oricare dintre
direcții(co ntroller/sitch or switch/controller)
– Hello sunt mesajele ce schimbate între controller și switch pe parcursul stabilirii
conexiunii
– Echo este un mesaj de tip cerere/răspns ce poate fi trimis de ambele părți. Acestea
sunt utilizate în scopul verificării con exiunii dintre controller și switch,măsurării
latenței conexiunii sau a lățimii de bandă.
– Error sunt utilizate de ambele părți pentru a informa despre problemele de la celălalt
capăt al conexiunii. Deobicei sunt utilizate de switch pentru informa despre o cerere
corruptă inițiată de controller.
– Experimenter este o cale standartd de verificare a funcționalitășilor noi în mediul
OpenFlow. Acestea sunt utilizate deobicei pentru funcții noi din viitoarele versiuni a
protocolului.

Mininet
Mininet este un em ulator de rețea ce crează o rețea de terminale(hosts),switch –
uri,controlere și link-uri virtuale.Host -urile Mininet rulează Linux Network standard. Switch –
urile suportă protocolul OpenFlow pentru a oferi flexibilitate,rutare customizabilă și suport SDN.
Mininet
– Oferă un mediu de testare pentru dezvoltarea aplicațiilor OpenFlow
– Oferă posibilitatea mai multor developeri să lucreze la aceiași topologie
– E capabil de testare unor topologii complexe fără a fi nevoie ce conexiuni fizice
– Oferă posibilitatea utiliz ării unor topologii customizate și parametrizate
– Oferă un Python API pentru crearea și experimentarea reșelelor
Aproape fiecare sistem de operare virtualizează resursele de calcul folosind o
abstractizare a procesului. Mininet utilizează virtualizarea baza tă pe procese pentru a rula mai
multe entități (suportă până la 4096) hosts și switch -uri rețele pe un singur nucleu OS.
Codul Mininet este aproape în întregime Python, cu excepția unei utilități scurte C.

31 – 31 -9/11/2019 9/11/2019 Coala
Mod Coală N Document Semn. Data Mininet combină mai multe avantaje ale emulatoare lor,mediilor de test hardware și a
simulatoarelor de rețea:
Comparat cu un sistem de virtualizare acesta pornește mai rapid, suportă topologii mai
mari,oferă o lățime de bandă mai mare,se instalează mai ușor fiind distribuit dub forma unor
imagini VM(Virtu al Machine)
Comparat cu mediile de test hardware acesta este gratui și mereu disponibil,ușor de
configurat și de restartat
Comparativ cu simulatoarele acesta utilizează cod real,nemodificat a aplicațiilor,
nucleului OS ,a controlerului sau Open vSwitch fii nd ușor de conectat la dispozitive de rețea
reale.