Digitally signed by

Library TUM
Reason: I attest to the
accuracy and integrity of
this document
UNIVERSITATEA TEHNICĂ A MOLDOVEI

REȚELE DEFINITE PRIN SOFTWARE

CICLU DE PRELEGERI

Chişinău
2019
 
0 
 UNIVERSITATEA TEHNICĂ A MOLDOVEI

FACULTATEA ELECTRONICĂ ŞI TELECOMUNICAŢII

DEPARTAMENTUL TELECOMUNICAŢII

REȚELE DEFINITE PRIN SOFTWARE

CICLU DE PRELEGERI

Chişinău
Editura „Tehnica-UTM”
2019

1 
CZU 004.4(075)
N 29

Lucrarea de față este o continuare logică a tematicii cursului

Sisteme și rețele de comunicații digitale (SRCD) care include
tendințele actuale de dezvoltare a tehnologiilor de rețea. Cursul de
prelegeri este divizat în două compartimente. În primul compartiment
sunt descrise principiile generale și arhitectura funcțională a Rețelei
definite prin software (SDN) în corespundere cu standardele Uniunii
Internaționale a Telecomunicațiilor (ITU).
În al doilea capitol se expune protocolul OpenFlow. Sunt descrise
componentele principale ale OpenFlow switch și modul cum se
procesează pachetele de date în cadrul acestui comutator. În final sunt
expuse mesajele și formatul de bază al protocolului OpenFlow.
Obiectivul principal al acestei părți a cursului SRCD constă în
însușirea cunoștințelor de bază privind tehnologiile viitoare și
emergente în domeniul TIC.
Ca parte a cursului Sisteme și rețele de comunicații digitale
lucrarea este destinată studenţilor UTM cu profilul Electronică şi
comunicaţii, specialităţile 0714.1 Tehnologii și sisteme de
telecomunicații, 0714.2 Rețele și software de telecomunicații, 0714.3
Comunicații radio și televiziune, 0710.1 Inginerie și management în
telecomunicații, cu forma de studii la zi şi cu frecvenţă redusă.
Autor: conf.univ., dr. Ion NAZAROI
Recenzent: conf.univ., dr. Nicolae BEJAN
DESCRIEREA CIP A CAMEREI NAȚIONALE A CĂRȚII
Nazaroi, Ion.
Reţele definite prin software: Ciclu de prelegeri / Ion Nazaroi;
Univ. Tehn. a Moldovei, Fac. Electronică şi Telecomunicaţii, Dep.
Telecomunicaţii. – Chişinău: Tehnica-UTM, 2019. – 56 p.
55 ex.
ISBN 978-9975-45-571-8.
004.4(075)
N 29

ISBN 978-9975-45-571-8 © U.T.M., 2019

2 
 INTRODUCERE

Calea de evoluție a NGN către viitoarele rețele (FN) și IMT-2020

este ghidată de posibilitățile tot mai mari de integrare a tehnologiilor
avansate de comunicații (de exemplu SDN, NFV și CDN) cu
tehnologii avansate ale informației (de exemplu, cloud computing,
tehnologii Web). Pentru a susține această abordare, arhitectura NGN
definită în Recomandarea ITU-T Y.2012 este menținută și actualizată
de Grupurile de lucru ITU ținând cont de cele mai recente tendințe
din domeniu [1]. Evoluția arhitecturii NGN va include tehnologii
inovatoare, în special, utilizarea tehnologiilor SDN (software-defined
networking) și virtualizarea funcțiilor de rețea (NFV).
Creșterea numărului de servicii și aplicații duce la cererea
incontinuu de majorare a capacităților de transmisie și de extindere a
infrastructurii rețelelor. Rețelele de telecomunicații de astăzi includ o
mare varietate de echipamente hardware. Diversitatea lor continuă să
crească. Lansarea de noi servicii necesită deseori integrare de
echipamente complexe dedicate serviciului și o proiectare costisitoare
a procedurii. Lansarea noilor servicii pe piață adesea necesită o
perioadă lungă de timp. Pe de altă parte, ciclul de viață al
echipamentelor devine tot mai scurt pe măsura accelerării inovațiilor
tehnologice și a serviciilor.
Pe baza acestor caracteristici, Open Networking Foundation
(ONF) citează patru limitări generale ale arhitecturilor de rețea
tradiționale [2]:
Arhitectură statică și complexă. Pentru a răspunde cerințelor
servirii volumelor mari și fluctuante de trafic multimedia cu diferite
niveluri de QoS și de securitate, tehnologia de rețea devine tot mai
complexă și mai dificil de gestionat. A crescut considerabil numărul
de protocoale utilizate în rețea, care deseori se adresează doar unei
porțiuni de cerințe de rețea. Dificilă devine adăugarea nodurilor de
rețea (routerelor, switchurilor). Personalul de gestionare a rețelei
trebuie să utilizeze instrumente de gestionare la nivel de echipament
pentru a modifica parametrii de configurare ai switchurilor,
routerelor, firewall-urilor și așa mai departe. Actualizările includ

3 
modificări ale listelor de control al accesului (ACL), setărilor LAN
virtuale, setărilor QoS în numeroase echipamente și alte ajustări
legate de protocol. Procedurile manuale trebuie să fie utilizate pentru
a configura echipamentele fiecărui furnizor.
Politici inconsecvente. Pentru a pune în aplicare o politică de
securitate la nivel de rețea, personalul va fi nevoit să facă schimbări
de configurație la mii de dispozitive. Într-o rețea mare, activarea a
unei noi mașini virtuale poate dura ore sau chiar zile pentru a
reconfigura ACL-urile în întreaga rețea.
Scalabilitate redusă. Cerințele față de rețele cresc rapid, ca
volum și ca varietate. Adăugarea de noduri de rețea și majorarea
capacității de transmisie implică echipamentele mai multor furnizori
și este dificilă datorită naturii complexe și statice a rețelei.
Dependența de furnizor. Operatorii de rețele și prestatorii de
servicii trebuie să implementeze rapid noi capabilități și servicii ca
răspuns la cerințele utilizatorilor. Lipsa de interfețe deschise pentru
funcțiile rețelei lasă operatorii limitați de ciclurile relativ lente ale
produselor furnizorilor.
Astfel chiar și cu capacitatea sporită a sistemelor de transmisie și
cu performanțele mai mari ale elementelor de rețea, arhitecturile
tradiționale de rețea sunt din ce în ce mai inadecvate în fața
complexității, variabilității și volumului ridicat al traficului impus.

1. REȚELE DEFINITE PRIN SOFTWARE

Rețelele definite prin software (SDN) au apărut ca o paradigmă

de rețea care poate elimina limitările infrastructurilor de rețea actuale.
Cum sunt concepute SDN pentru a răspunde cerințelor de rețea în
evoluție? Alianța Open Data Center (ODCA) oferă o listă concisă a
cerințelor, care includ următoarele [3]:
Adaptabilitate. Rețelele trebuie să se adapteze și să răspundă în
mod dinamic la necesitățile aplicațiilor, condițiile rețelei și a politicii
de afaceri.
Automatizare. Schimbările de politici trebuie efectuate automat,
astfel încât munca manuală și erorile să poată fi reduse.

4 
 Mentenabilitate. Introducerea de noi funcții și capabilități
(actualizări de software, corecții) trebuie să fie cu întreruperi minime
ale operațiunilor.
Managementul modelului. Software-ul de gestionare a rețelei
trebuie să permită gestionarea rețelei la un nivel de model mai rapid
decât să implementeze modificări conceptuale prin reconfigurarea
elementelor individuale ale rețelei.
Mobilitate. Funcțiile de control trebuie să găzduiască mobilitatea,
inclusiv pentru dispozitivele utilizatorilor mobili și serverele virtuale.
Securitate integrată. Aplicațiile de rețea trebuie să integreze
securitatea fără probleme ca serviciu de bază, în loc ca soluție
complimentară.
Scalarea la cerere. Implementările trebuie să aibă capacitatea de
a mări sau micșora rețelele și serviciile lor pentru a sprijini solicitările
apărute.

1.1 Definiția SDN

Rețelele de comunicații servesc diferite tipuri de trafic.

Varietatea aplicațiilor este în creștere continuă. Având proprietăți
stohastice diferite traficul cere și o abordare diferențiată. Pentru a
susține cerințe divergente dependente de aplicație, este necesar ca
rețelele să devină mai controlabile și mai ușor de gestionat. Astfel
orientarea rețelelor pe servicii este în creștere.
Conceptul de rețea definită prin software se caracterizează prin
cinci trăsături fundamentale:
1) separarea funcțiilor,
2) centralizarea controlului,
3) simplificarea nodurilor de rețea,
4) automatizarea și virtualizarea rețelelor,
5) utilizarea standardelor deschise.
Caracteristica fundamentală a SDN este separarea funcțiilor de
control de cele de rutare a fluxurilor de trafic. Funcția de rutare
include tabelele de expediere a pachetelor, bazate pe adresa MAC,
adresa IP, ID-ul VLAN etc. Pachetele care sosesc pot fi transmise

5 
spre un port de ieșire, aruncate, consumate sau replicate. Un pachet
poate fi aruncat dacă memoria tamponului este depășită sau datorită
limitării ratei specifice QoS. În cazuri speciale pachetul necesită
prelucrare de către planul de control (consumat) și retransmis planului
resurselor. În cele din urmă, un caz special de expediere se referă la
multicast. Atunci pachetul de intrare trebuie să fie replicat înainte de
expedierea copiilor sale diferitelor porturi de ieșire.
Astfel în SDN nodurile de rețea (routere, switchuri) sunt
simplificate și conțin doar funcțiile de comutație. Software-ul
complicat care rulează pe nod și controlează în mod autonom sute de
mii de linii este eliminat din dispozitiv și plasat într-un controlor
centralizat. Partea de control fiind realizată pe nivel separat oferă
șansa de introducere a unui control centralizat logic și programabil al
resurselor de rețea prin intermediul interfețelor și protocoalelor
standardizate.
Resursele de rețea sunt abstractizate. Abstractizarea oferă
programatorului o vedere globală a rețelei și îl eliberează de
necesitatea cunoașterii rețelei compusă din mai multe mașini. Apare
posibilitatea a virtualiza rețeaua, a decupla serviciul de rețea de
rețeaua fizică de bază. Deci, prin abstractizarea și programarea
resurselor de rețea, rețelele pot fi controlate într-o manieră automată,
ceea ce permite operații mai agile ale rețelelor.
O caracteristică a Open SDN este că interfețele sale trebuie să
rămână standard, bine documentate și nu de proprietate (non-
proprietary). Ca urmare, viteza cu care tehnologia de rețea este
dezvoltată este mult sporită, deoarece o mulțime de persoane și
organizații sunt capabile să se aplice problemelor actuale ale rețelei.
Prezența acestor interfețe deschise încurajează, de asemenea,
proiectele „open source” legate de SDN. Pe lângă facilitarea
cercetării și experimentării, interfețele deschise permit
interoperabilitatea echipamentelor de la diferiți furnizori. În mod
normal, acest lucru generează un mediu concurențial care reduce
costurile consumatorilor de echipamente de rețea. Această reducere a
costurilor echipamentelor de rețea a făcut parte din agenda SDN de la
înființarea acesteia.

6 
 Această abordare permite:
- controlul centralizat logic al rețelei, care reduce numărul de
puncte de control și de management;
- sprijinirea virtualizării rețelelor ca o caracteristică importantă a
arhitecturii rețelei;
- definirea, controlul și managementul resurselor de rețea
utilizând software;
- furnizarea serviciilor de rețea într-o manieră deterministă, în
conformitate cu comportamentul solicitat;
- personalizarea rețelei, care este necesară pentru implementarea
eficientă a rețelelor și operațiunilor.
Reieşind pe cele aduse mai sus Uniunea Internațională a
Telecomunicațiilor (ITU) definește SDN astfel:
O rețea definită prin software (SDN) este un set de tehnici care
permite programarea, orchestrarea, controlul și managementul direct
al resurselor de rețea, care facilitează proiectarea, livrarea și
operarea serviciilor de rețea într-o manieră dinamică și scalabilă [4].

1.2. Arhitectura SDN

Arhitectura SDN decuplează funcțiile de control ale rețelei de

cele de rutare. Controlul rețelei devine direct programabil, iar
infrastructura de bază abstractizată de la aplicațiile și serviciile de
rețea (figura 1.1).
SDN mută controlul resurselor de rețea către un element de rețea
dedicat, numit controler SDN. Controler-ul asigură programarea,
orchestrarea, controlul și menajamentul resurselor de rețea prin
software.
Resursele de rețea distribuite îndeplinesc funcțiile rețelei, cum ar
fi transportul și rutarea pachetelor de date. Controler-ul SDN
utilizează o interfață standardizată (interfața de control al resurselor)
pentru gestionarea și configurarea centralizată a resurselor rețelei.

7 
 Figura 1.1. Conceptul SDN

Controler-ul SDN oferă o vizualizare abstractă a resurselor de

rețea pentru aplicațiile SDN printr-o altă interfață standardizată
(interfața de control al aplicației). Aplicația SDN poate personaliza și
automatiza gestionarea resurselor de rețea abstracte într-o manieră
programabilă prin intermediul acestei interfețe. Rețineți că controler-
ul SDN poate furniza diferite tipuri de interfețe la aplicațiile SDN
(mai mult abstracte sau orientate spre obiecte).
Rețeaua poate fi programată de aplicații care rulează pe partea
superioară a arhitecturii - nivelul aplicații SDN.
Arhitectura funcțională SDN stratificată este prezentată în figura
1.2. Ea este formată din nivelul aplicațiilor SDN (SDN-AL), nivelul
de control SDN (SDN-CL) și nivelul resurselor SDN (SDN-RL).
Funcțiile de management multi-nivel (MMF) oferă capabilități de
gestionare a funcționalităților nivelurilor SDN enumerate mai sus.

8 
 Figura 1.2. Structura stratificată SDN

Ele includ funcționalități pentru gestionarea defecțiunilor,

configurației, contabilității, performanței și securității (abrevierea
engleză FCAPS - fault, configuration, accounting, performance and
security). Exemple de astfel de funcționalități sunt inventarierea de
echipamente, actualizarea software-ului, izolarea defectelor,
optimizarea performanțelor, eficientizarea energetică și configurarea
inițială a resurselor de rețea, a controler-elor și a aplicațiilor SDN. În
mod specific, gestionarea autonomă, adică adaptarea continuă la
starea rețelei, poate fi realizată de către nivelul de control SDN.
Arhitectura SDN descrisă trebuie să ia în considerare factorii care
sunt importanți în rețelele publice de mari dimensiuni, spre exemplu,
interacțiunea cu sistemul de suport operațional (OSS-Operation
Support System) / sistemul de suport afaceri (BSS-Business Support
System) existent al operatorilor.
O prezentare de ansamblu a arhitecturii funcționale SDN organizată
pe niveluri este dată de figura 1.3. [5]

9 
             MMFO                              MMFA 
    Manage
          
Management relații externe
Orchestrare și Aplicații SDN
    ment

Orchestrare și management multi-nivel

suport
                                                                                                                                                                   SDN-AL
  nivel management
OSS aplicații  AL
/BSS  
                                                                      MMFC  ACI
   
Manage Orchestrare și
                   Suport aplicații
ment suport
        SDN-CL
nivel management Servicii nivel
control  CL control
      
                                                                        Abstractizare
  resurse
 
  MMFR      RCI
Manage Suport Suport control RL
ment management
nivel RL SDN-RL
resurse Procesare Transport
date date

Figura 1.3. Arhitectură SDN funcțională

În continuare vor fi descrise funcționalitățile nivelurilor

aplicațiilor SDN (SDN-AL), de control SDN (SDN-CL) și resurselor
SDN (SDN-RL), precum și funcțiile de management multi-nivel
(MMF).

1.2.1. Nivelul aplicațiilor SDN (SDN-AL)

SDN-AL este alcătuit din componenta funcțională de suport

management și orchestrare a nivelului aplicațiilor (AL-MSO) și
componente funcționale aplicații SDN (figura 1.4). Nivelul
aplicațiilor interacționează cu cel de control prin punctul de referință
al interfeței de control al aplicației (ACI), iar cu MMF– prin punctul
de referință MMFA.

10 
  

MMFA
 
Orchestrare și    Nivel
suport
management
Aplicație SDN
             ...                    . . .      Aplicație SDN aplicații
SDN
AL (SDN-AL)
                                       
                      ACI

Figura 1.4. Componente funcționale SDN-AL

Componenta funcțională AL-MSO orchestrează aplicațiile SDN

cu sprijinul MMF și include următoarele:
-gestionarea depozitului codurilor aplicațiilor SDN;
-gestionarea ciclului de viață al aplicațiilor SDN (crearea,
modificarea și ștergerea);
-monitorizarea performanței aplicațiilor SDN pentru a satisface
cerințele SLA;
-detectarea, izolarea și corectarea defecțiunilor aplicațiilor SDN;
-securizarea (inclusiv autentificarea și gestionarea identității)
aplicațiilor SDN furnizate de operatorii de rețea.
Componenta funcțională AL-MSO oferă capabilități pentru
furnizarea resurselor care sunt utilizate pentru a rula aplicațiile SDN,
pe baza cererilor primite de la MMF.
Notă. Conform definiției ITU: Orchestrarea SDN este un proces
care supraveghează și direcționează un set de activități și interacțiuni
ale rețelei definite prin software cu scopul de a realiza anumite
lucrări în mod automat [5].
Componenta funcțională a aplicației SDN interacționează cu
nivelul de control pentru ca ultimul să adapteze automat
comportamentul și proprietățile resurselor de rețea. Pentru aceasta ea
folosește vizualizarea abstractizată a rețelei furnizate de SDN-CL prin
intermediul modelelor de date expuse prin punctul de referință ACI.
În funcție de cazurile de utilizare SDN (de exemplu, centre de date,
rețele mobile, rețele de acces) interfețele ACI pot fi diferite.
11 
 Sub termenul "Aplicația SDN" se înțelege o aplicație care
controlează și gestionează resursele de rețea (de exemplu, pentru
rutare specifică a aplicației) prin utilizarea capabilităților furnizate
prin punctul de referință ACI.
Componenta funcțională a aplicației SDN constă din software-ul
necesar pentru implementarea acesteia.

1.2.2. Nivelul de control SDN (SDN-CL)

Nivelul de control, numit deseori Controlor, este entitatea

centrală a SDN. El controlează comportamentul resurselor SDN-RL
(transportul și procesarea datelor), în urma solicitărilor primite de la
aplicații și conform politicilor MMF. SDN-CL operează cu resursele
furnizate de nivelul resurselor și expune o vedere abstractizată a
acestora pentru aplicații.
Componentele funcționale ale nivelului de control sunt
prezentate de figura 1.5.
SDN-CL interacționează cu nivelul resurselor, utilizând punctul
de referință al interfeței de control al resurselor (RCI), și cu funcțiile
de management multi-nivel MMF utilizând punctul de referință al
nivelului de control MMFC.
Componenta funcțională de suport aplicații (CL-AS) este
utilizată de nivelul aplicațiilor pentru a accesa informațiile de rețea și
a solicita controlorul să efectueze acțiuni solicitate de aplicație. Ea
ascunde detalii despre topologia rețelei subiacente (underlying),
oferind o viziune globală și abstractizată a acestei rețele. Informațiile
de rețea expuse pentru nivelul aplicațiilor sunt abstractizate în formă
de modele de date și informații. În cazul virtualizării rețelei,
componenta funcțională CL-AS poate expune un subset de resurse de
rețea sub controlul exclusiv al unui controlor și al unui nivel de
aplicați externe.

12 
 MMFC  ACI
   
Suport
    aplicații CL
 
 
Servicii
  CL
Orchestr- Servicii de bază  Servicii specifice
are și  
suport Nivelul de
manage- Abstractizare
control resurse
ment CL SDN
Repozitoriu(SDN-CL) Descoperire
de topologie   resurse
 
Alocare resurse Supraveghere
 
resurse
 
 
RCI

Figura 1.5. Componentele funcționale SDN-CL

Componenta funcțională a serviciilor CL furnizează un set de

funcții programabile de control și opțional de management (dacă sunt
delegate de MMF) care acoperă, de exemplu, topologii de rețea fizică
și virtuală, configurarea elementelor de rețea și gestionarea expedierii
traficului. Ea include servicii de bază și servicii specifice (de profil).
Componenta serviciilor de bază legate cu funcții de conectivitate este
obligatorie în toate realizările SDN (de exemplu, rețelele mobile,
transportul optic, mediul cloud sau virtualizarea funcțiilor de rețea
(NFV)). Ea include funcții comune utilizate în toate implementările
SDN, așa ca, descoperirea și monitorizarea topologiei, monitorizarea
resurselor (nodurilor și linkurilor) sau calcularea, selectarea și
monitorizarea traseului conform unei solicitări, actualizarea sincronă
sau asincronă a regulilor de expediere a datelor (programare flux).
13 
Serviciile dependente de profil sunt legate de o anumită implementare
SDN sau combinare a mai multor astfel de servicii, de exemplu,
gestionarea mobilității pentru rețelele mobile.
Componenta funcțională de abstractizare a resurselor (CL-RA).
Scopul principal al componentei CL-RA este de a sprijini
programabilitatea unificată a resurselor în SDN-RL. Modelele de date
și informații ale resurselor de rețea furnizează o imagine abstractă și
unificată asupra acestor resurse către SDN-CL. Astfel ca dezvoltatorii
de servicii sau funcții de control să-și poată simplifica logica
programelor fără o cunoaștere detaliată a tehnologiilor din rețea.
Componenta funcțională CL-RA include, dar nu se limitează la,
următoarele elemente:
 de descoperire a resurselor independente de tehnologie;
 repozitoriu de topologie care păstrează topologia curentă a
rețelei fizice și virtuale (dacă este creată);
 de alocare a resurselor abstractizate pentru crearea rețelelor
virtuale;
 de supraveghere a resurselor care monitorizează defecțiunile
și performanța resurselor de pe nivelul SDN-RL.
Componenta funcțională de suport management și orchestrare a
nivelului de control (CL-MSO) oferă suportul de management și
orchestrare a componentelor funcționale ale SDN-CL și a resurselor
de rețea pe baza politicilor oferite de MMF.
De asemenea, componenta funcțională CL-MSO:
 obține informații de monitorizare pentru măsurarea și
înregistrarea indicatorilor-cheie de performanță (KPI) ai fiecărui
serviciu CL și cantitatea de resurse alocate unui serviciu CL pe baza
acestor indicatori de performanță;
 ține evidența stării generale a resurselor alocate și disponibile
în SDN-CL. Comparația resurselor alocate în SDN-CL cu indicatorii
KPI ai serviciului CL poate ajuta la identificarea blocajelor actuale
sau potențiale;
 oferă capabilități de operațiuni între diferite domenii SDN, de
exemplu, transmiterea identității și acreditărilor corespunzătoare cu

14 
cererile adresate. Un domeniu SDN este o colecție de entități SDN-
RL sub o entitate SDN-CL;
 anumite sarcini de management (dacă sunt delegate de MMF)
pot fi efectuate de către SDN-CL, în special sarcini care sunt strâns
legate de operațiunile de control și pot fi optimizate în comun pentru
utilizarea resurselor sau pentru performanță.
În concluzie se accentuează că nivelul de control, controlorul este
creierul rețelei. El poate fi centralizat, distribuit sau hibrid. În cazul
centralizat un controlor gestionează toate resursele de rețea și
păstrează o vedere globală a întregii rețele. În timp ce nivelul de
control distribuit utilizează mai multe controloare care sunt distribuite
pe întreaga rețea. Nivelul de control de tip hibrid se bazează pe
ambele concepte atât centralizat, cât și distribuit.
Indiferent de tip, controlul este logic centralizat. Termenul
”logic” înseamnă că controlorul se comportă ca o singură entitate,
independent de posibila implementare în formă distribuită.
Cele mai utilizate sisteme la nivelul de control SDN sunt Open
Network Operating System (ONOS) [8], OpenDaylight (ODL) [9],
Floodlight [10], OpenContrail, Ryu, FlowVisor, BEACON, NOX și
POX.

1.2.3. Nivelul resurselor SDN (SDN-RL)

Elementele rețelei fizice sau virtuale ale nivelului resurselor

realizează transportul și prelucrarea pachetelor de date în
conformitate cu deciziile controlorului. Informațiile privind
furnizarea de politici (inclusiv informațiile despre configurația rețelei)
care rezultă din deciziile luate de SDN-CL, precum și informațiile
privind resursele de rețea, sunt schimbate prin punctul de referință al
RCI. Informațiile de control sunt furnizate de SDN-CL către SDN-RL
(de exemplu, pentru configurarea unei resurse de rețea). În sens opus
SDN-RL transmite notificări (nesolicitate) dacă este detectată o
modificare a resurselor de rețea. Comutatoarele SDN sunt noduri de
rețea non-inteligente care redirecționează fluxurile de date conform
regulilor instalate în ele de controlor. Cele mai comune comutatoare

15 
SDN sunt switch-urile OpenFlow care funcționează pe protocolul
OpenFlow. Switch-ul OpenFlow are tabele de fluxuri care oferă
prevederi pentru căutarea/potrivirea și apoi transmiterea pachetelor pe
baza regulilor/acțiunilor din tabelă. Descrierea mai detaliată a
protocolului OpenFlow este dată de capitolul 2.
Resursele de rețea includ entități virtuale sau fizice, care susțin
funcționalități de:
 expediere a datelor, cum ar fi comutatoare de rețea cu
reguli de expediere a datelor, configurate de SDN-CL;
 calculare a rutelor, cum ar fi router-ele IP cu capabilități
de control al rutei distribuite, personalizate de SDN-CL,
ca parte a executării dinamice a politicilor ingineriei
traficului;
 procesare a datelor, cum ar fi module pentru transcodarea
media și compresie de date.
Componentele funcționale ale nivelului resurselor sunt prezentate
de figura 1.6.
Componenta funcțională suport control (RL-CS) oferă modele de
date sau de informații ale resurselor de rețea, care sunt abstractizate în
SDN-CL. Ea însăși poate realiza abstractizarea resurselor în loc de
SDN-CL, dacă abstractizarea resurselor este susținută de tehnologia
utilizată.
Componenta funcțională RL-CS permite actualizarea datelor de
transport și de procesare, de exemplu, dacă se adaugă un nou protocol
sau un set nou de specificații de interfață. Programabilitatea
componentei funcționale RL-CS este susținută de MMF.

16 
 

      RCI
                             
                                     Nivelul
Suport Suport control RL resurse
management SDN
RL (SDN-RL)
Procesare Transport
date date
MMFR
 

Figura 1.6. Componentele funcționale SDN-RL

Componenta funcțională transport date (RL-DT) oferă

funcționalități de expediere și de rutare a datelor.
Funcția de expediere a datelor gestionează fluxurile de date
primite pentru a le expedia pe căile de redirecționare a datelor care au
fost calculate și stabilite conform cerințelor definite de aplicațiile
SDN.
Controlul funcționalității de expediere a datelor este asigurat de
nivelul de control. Politica de rutare SDN-RL poate fi configurată de
SDN-CL conform cerințelor aplicațiilor SDN.
Funcțiile de redirecționare și de rutare a datelor sunt extensibile.
De exemplu, extinderea capabilităților de transport date pentru
manipularea unui nou format de cadru de date.
Componenta funcțională de procesare date (RL-DP) furnizează
funcționalități pentru examinarea și manipularea datelor.
Funcționalitățile de procesare a datelor permit modificarea formatului
sau a traficului util al pachetelor de date și ajustarea expedierii
pachetelor de date în corespundere cu cerințele aplicațiilor SDN.
Funcționalitățile de procesare a datelor sunt extensibile. Ca
exemple pot servi extinderea capabilităților existente de prelucrare a
datelor prin încorporarea unor noi tehnici de procesare a datelor, cum
ar fi algoritmi noi de codificare.

17 
 Componenta funcțională suport management (RL-MS) asigură
descrierea resurselor, nume furnizor, versiune software și starea
resurselor (de exemplu, încărcare CPU, memorie RAM sau stocare
utilizate). RL-MS poate include și un agent de management care
efectuează anumite operațiuni de management locale, dacă ele sunt
delegate de către MMF.
Acest agent poate fi utilizat pentru descoperirea resurselor
dependente de tehnologie, pentru monitorizarea locală programabilă a
entității SND-RL (pentru a limita volumul de date schimbate între
nivelurile SDN-CL și SDN-RL) sau pentru efectuarea așa-numitului
comportament autonom [6].
Notă. O comportare autonomă (AB) este definită ca un
comportament sau acțiune declanșate de un element de luare a
deciziilor în încercarea de a realiza obiectivul definit. Obiectivul este
definit prin modul în care elementul decizional gestionează o entitate
gestionată, aflată sub controlul său (pentru detalii vezi [6]).
Componenta funcțională RL-MS oferă, de asemenea, o
gestionare a ciclului de viață al tuturor componentelor software ale
nivelului resurse, inclusiv componenta funcțională suport control RL-
CS.

1.2.4. Funcțiile de management multi-nivel (MMF)

Funcțiile de management multi-nivel MMF gestionează

nivelurile SDN, adică ale aplicațiilor SDN-AL, de control SDN-CL și
ale resurselor SDN-RL. Interacțiunea cu aceste niveluri se efectuează
folosind punctele de referință MMFA, MMFC și MMFR.
Funcțiile MMF asigură:
1) interacțiunea cu sistemele de management ale terților, pentru
facturare, suport clienți, colectare de statistici sau furnizare de servicii
dinamice (prin punctul de referință MMF OSS / BSS (MMFO) din
figura 1.7);
2) orchestrarea serviciilor MMF dinamic implementate și
reconfigurarea coordonată (orchestrată) a resurselor SDN-RL;

18 
 3) inventarierea echipamentelor, izolarea defectelor, optimizarea
performanțelor, configurația inițială a nivelurilor SDN-RL, SDN-CL
și SDN-AL și securizarea comunicațiilor (pe scurt funcțiile FCAPS –
gestionarea defecțiunilor, configurației, contabilității, performanței și
securității);
4) managementul ciclului de viață al componentelor software ale
nivelurilor SDN;
5) eficientizare consum de energie electrică a resurselor virtuale
și fizice utilizate pentru implementarea tuturor nivelurilor, prin
analiză și monitorizarea stării resurselor;
6) managementul funcționalităților nivelurilor SDN.
După cum se arată în figura 1.7, MMF include componentele
funcționale: managementul nivelului de resurse (RLM),
managementul nivelului de control (CLM), managementul nivelului
aplicațiilor (ALM), orchestrarea și managementul multi-nivel
(MMO) și managementul relațiilor externe (ERM). Liniile interne ale
blocului MMF nu reprezintă puncte de referință. Acestea arată pur și
simplu relațiile dintre componentele funcționale.
MMF poate delega anumite operațiuni de management, în special
acelea care necesită un schimb intensiv de date cu nivelul de control
SDN-CL. Deseori se decide ca unele acțiuni să fie efectuate direct de
către SDN-CL (de exemplu, așa-numitele operațiuni de management
autonom [6]). Operațiunile delegate sunt efectuate de componentele
funcționale AL-MSO, CL-MSO și RL-MS.
În continuare sunt descrise mai detaliat componentele funcționale
ale MMF identificate mai sus (figura 1.7).
Componenta funcțională de management al nivelului de resurse
(RLM) este responsabilă de gestionarea resurselor fizice și virtuale
ale nivelului resurselor SDN-RL.
RLM realizează următoarele funcții:
1) măsoară și raportează datele privind utilizarea resurselor (de
exemplu, pentru scopuri de facturare);
2) solicită și primește indicații de management de la MMO cu
informațiile de rigoare pentru orchestrarea multi-nivel specifică
RLM;

19 
  
 
OSS/BSS  
 
                                                               MMFO
 
Funcții management multi-nivel  
(MMF)  
Management  
relații externe  
(ERM)  
Orchestrare  
și Management  MMFA  Nivelul aplicațiilor SDN
management nivel aplicații   (SDN-AL)
multi-nivel (ALM)  
(MMO)  
Management  
nivel control  MMFC  Nivelul de control SDN
(CLM)   (SDN-CL)
 
Management  
nivel resurse  MMFR  Nivelul resurselor SDN
(RLM) (SDN-RL)

Figura 1.7. Structura internă și punctele de referință MMF

3) autentifică, autorizează și detectează acțiunile anormale asupra

SDN-RL (opțional);
4) abstractizează resursele fizice și virtuale specifice tehnologiei
utilizate în informații generale independente de tehnologie;
5) monitorizează și asigură performanța resurselor fizice și
virtuale ale SDN-RL pe baza indicatorilor de calitate (KPI-urilor
date), inclusiv gestionarea consumului de energie al resurselor;
6) corelează relația dintre resursele virtuale și cele fizice din
SDN-RL;
7) detectează și analizează evenimentele anormale care cauzează
căderea resurselor virtuale și fizice și generează politici de rezolvare a
defecțiunilor;
8) stochează conținutul descoperit de resurse și gestionează ciclul
de viață al conținutului în repozitoriu;

20 
 9) colectează stările resurselor și a evenimentelor și le analizează
în scopul gestionării FCAPS;
10) descoperă și resetează (bootstrapping) resursele fizice și
virtuale în SDN-RL;
11) oferă un punct de referință MMFR care este utilizat pentru
solicitarea și primirea operațiilor de gestionare și a informațiilor
asociate din / către SDN-AL.
Componenta funcțională de management al nivelului de control
(CLM) gestionează resursele utilizate pentru implementarea funcțiilor
nivelului de control SDN-CL (hardware, platforme software, linkuri
care leagă planul de control cu alte planuri). Asigură disponibilitatea
și scalabilitatea ridicată a managementului SDN-CL, precum și
controlul traficului generat între entitățile SDN-CL și entitățile SDN-
RL sau SDN-AL.
Funcțiile CLM sunt după cum urmează:
1) solicitarea și primirea de la MMO a indicațiilor de
management al nivelului de control;
2) furnizarea de resurse de control la nivelul SDN-CL și scalarea
lor în funcție de cerere și disponibilitate;
3) definirea, stocarea și recuperarea politicilor (de afaceri,
tehnice, de securitate, confidențialitate și de certificare) care se aplică
serviciilor nivelului de control;
4) monitorizarea și asigurarea performanței resurselor SDN-CL
pe baza indicatorilor KPI;
5) autentificarea și autorizarea, dar și detectarea atacurilor
anormale față de SDN-CL (opțional);
6) detectarea evenimentelor anormale care cauzează defecțiuni,
analiza cauzelor defectării și recuperarea efectivă a resurselor SDN-
CL defecte;
7) stocarea conținutului descoperit și gestionarea ciclului de viață
al lui (creare, modificare, ștergere) în repozitoriu;
8) colectarea stărilor și evenimentelor din resursele SDN-CL și
analiza lor pentru managementul performanței, defecțiunilor și
securității;
9) descoperirea și stocarea resurselor de control în SDN-CL;

21 
 10) furnizarea unui punct de referință MMFC care este utilizat
pentru solicitarea și primirea operațiilor de gestionare și a
informațiilor asociate către / de la SDN-CL.
Componenta funcțională CLM poate furniza, de asemenea, o
gestionare energetică eficientă a resurselor CL. Mecanismele utilizate
de managementul resurselor RL în domeniul energiei pot fi aplicate și
în CL.
Componenta funcțională de management al nivelului aplicațiilor
(ALM) gestionează resursele SDN-AL.
Funcțiile CLM sunt după cum urmează:
1) oferă o interfață internă cu blocul de orchestrare și
management multi-nivel (MMO) pentru solicitarea și primirea
indicațiilor de management de la MMO specifice nivelului
aplicațiilor;
2) furnizarea de aplicații și resurse relevante SDN-AL;
3) măsurarea și raportarea datelor privind utilizarea resurselor
SDN-AL pentru o facturare ulterioară. Datele privind utilizarea
resurselor pot fi măsurate pentru fiecare aplicație SDN sau pentru
fiecare client;
4) monitorizarea performanțelor aplicațiilor SDN pentru a
îndeplini cerințele SLA;
5) gestionarea securității aplicațiilor SDN terțe (autentificare,
autorizare);
6) detectarea, izolarea, recuperarea defecțiunilor aplicației SDN;
7) stocarea conținuturilor descoperite și gestionarea ciclului de
viață al acestor conținuturi în repozitoriu (crearea, modificarea și
ștergerea aplicațiilor SDN);
8) colectarea evenimentelor și statutului resurselor nivelului
SDN-AL și analizarea acestora în scopul gestionării defectelor,
calității și securității;
9) descoperirea aplicațiilor aflate în execuție și a componentelor
funcționale utilizate în SDN-AL;
10) furnizarea unui punct de referință MMFA pentru componenta
funcțională AL-MSO care este utilizată pentru solicitarea și primirea

22 
operațiilor de gestionare și a informațiilor asociate către / de la SDN-
AL.
Componenta funcțională de management al relațiilor externe
(ERM) gestionează colaborarea cu entități externe de management.
Componenta funcțională ERM joacă un rol de interfață reprezentativă
a managementului SDN față de entitățile de management extern.
Anume:
1) oferă un punct de referință MMFO către OSS / BSS pentru
solicitarea și primirea operațiilor de gestionare și a informațiilor
asociate la / de la OSS / BSS;
2) abstractizarea informațiilor de management SDN pentru
schimbul cu entitățile externe de management în scopul de ascundere
a informațiilor de gestiune inter-domeniu;
3) gestionează cererile/răspunsurile cu entitățile externe de
management;
4) oferă schimburi externe de politică SDN între MMF și
entitățile de management extern, analize de date, contabilitate.
Asigură interacțiunea cu sisteme externe de DevOps* pentru o
dezvoltare eficientă a funcțiilor SDN;
5) oferă o interfață internă MMFO în scopul orchestrării inter-
domenii între SDN MMF și OSS / BSS.
*) DevOps este o cultură și o practică de inginerie software care
urmărește unificarea dezvoltării (Dev) și operării (Ops) software-ului.
Componenta funcțională de orchestrare și management multi-
nivel (MMO) gestionează ciclul de viață al aplicațiilor SDN și
serviciilor de rețea și orchestrează managementul multi-nivel al
resurselor pe întregul domeniu al operatorului SDN (de exemplu, mai
multe centre de date interconectate de o rețea de transport WAN).
MMO asigură orchestrarea furnizării și configurării resurselor SDN-
RL și coordonează operațiunile de management între nivelurile SDN-
AL, SDN-CL și SDN-RL, în special relația dintre resursele
virtualizate și cele fizice ale nivelurilor SDN. De asemenea MMO
interacționează cu componentele funcționale ALM, CLM și RLM
pentru solicitarea și primirea operațiilor de management și a
informațiilor asociate pentru orchestrarea multi-nivel.

23 
 2. PROTOCOLUL OPENFLOW

Pentru a transforma conceptul de SDN în practică, trebuie

îndeplinite două cerințe:
1) să existe o arhitectură logică comună în toate comutatoarele,
routerele și alte dispozitive de rețea care să fie gestionate de un
controler SDN;
2) este necesar și un protocol standard, securizat între controler-
ul SDN și dispozitivul de rețea.
În întâmpinarea acestor cerințe vine protocolul OpenFlow. El
este un standard deschis pentru un protocol de comunicare între
nivelul de control și nivelul resurselor SDN. OpenFlow este și o
specificație a structurii logice de funcționare a dispozitivului de rețea.
Structura de nivel înalt pentru un switch SDN constă din trei
componente-cheie: interfața cu controlorul, nivelul de abstractizare și
un sistem de procesare a pachetelor (figura 2.1).
Interfața controlorului menține un canal securizat și
implementează protocolul OpenFlow pentru comunicarea între
comutator și un controlor SDN. Această interfața permite
controlorului să controleze acțiunile efectuate de comutator prin
instalarea și actualizarea regulilor de potrivire a pachetelor.
Nivelul de abstractizare se află între interfața controlorului și
sistemul de procesare a pachetelor. Acest nivel oferă o vedere
abstractă a sistemului de procesare a pachetelor. El menține una sau
mai multe tabele de fluxuri pentru a stoca regulile de acțiune de
potrivire a pachetelor primite. Tabelul de fluxuri conține o listă cu
înregistrări de flux, fiecare fiind formată din câmpuri de potrivire și
set de instrucțiuni. Fiecare înregistrare de flux specifică regula după
care se identifică pachetul potrivit și acțiunile care ar trebui efectuate
la toate pachetele din flux.

24 
 Spre controlor

Protocolul OpenFlow

Interfață controlor

  Tabelă de fluxuri
Nivel abstractizare
 

Sistem de procesare pachete

Figura 2.1. Structura generală a switch-ului OpenFlow

Sistemul de procesare a pachetelor într-un comutator SDN

efectuează acțiunile de redirecționare și prelucrare a pachetelor. El
cuprinde un set de porturi de intrare, un set de porturi de ieșire și o
matrice de comutare pentru interconectarea lor. Pentru fiecare pachet
primit de la un port de intrare, sistemul de procesare caută tabelele de
fluxuri din stratul de abstractizare pentru a identifica înregistrarea
fluxului, potrivită acestui pachet. Instrucțiunile stocate în înregistrarea
fluxului specifică acțiunile pe care sistemul de procesare ar trebui să
le efectueze pe pachet. Printre acțiunile tipice se numără transmiterea
pachetului la un port de ieșire sau către controlor, modificarea unei
părți a pachetului și abandonarea pachetului.
Planul resurselor SDN cuprinde elementele de rețea care mai des
sunt switch-uri SDN și îndeplinesc funcții de procesare și
redirecționare a pachetelor. Totuși în unele cazuri ele efectuează mai
multe funcții, cum ar fi firewall-ul, controlul accesului și balansarea
traficului.
Unele tehnologii tradiționale de comutare a pachetelor (de
exemplu, hardware-ul și software-ul pentru implementarea matricei
de comutare care transferă pachetele de la porturile de intrare la
porturile destinate de ieșire, cu debit mare și întârziere scurtă) joacă
25 
încă un rol crucial în comutatorul SDN, în mod special în sistemul lui
de procesare. Însă, spre deosebire de comutatoarele tradiționale, care
rulează protocoale de rutare pentru expedierea pachetelor, în
comutatoarele SDN funcțiile de luare a deciziilor sunt eliminate și
transferate către controlor. Ca urmare, comutatorul SDN efectuează
doar procesarea pachetelor, respectând regulile impuse de controlor.
Comutatoarele SDN pot fi realizate software sau hardware.
Primele utilizează software care rulează pe servere convenționale cu
CPU și sisteme de operare standarde (de ex., Linux). Implementările
bazate pe hardware utilizează echipamente specializate, cum ar fi
memorii adresabile pentru conținut (CAM) și procesoare de rețea.
Implementările bazate pe software și hardware au fiecare propriile lor
avantaje și limitări. De aceea au apărut și comutatoare SDN
combinate care sunt bazate pe software și hardware pentru a exploata
pe deplin avantajele lor și pentru a-și depăși limitele respective.
Astfel hardware specializate sunt utilizate și în SDN pentru a realiza
comutarea de pachete de înaltă performanță.

2.1. Componentele principale ale OpenFlow Switch

Deși există protocoale alternative pentru interfața RCI,

OpenFlow este în prezent standardul de facto al interfeței sudice
pentru controlul comutatoarelor SDN și este considerat unicul
protocol general non-proprietar pentru programarea comutatoarelor
SDN. Ca urmare, în continuare se expune nivelul resurselor SDN
realizat pe switch-urile OpenFlow și comunicarea acestora cu un
controlor OpenFlow.
Protocolul OpenFlow este definit în versiunile specificației
pentru comutatoarele OpenFlow, elaborate și publicate de Open
Networking Foundation (ONF) (tabelul 2.1).

26 
 Tabelul 2.1. Versiunile OpenFlow
Versiune Dată
OF 1.0 Decembrie 2009
OF 1.1 Februarie 2011
OF 1.2 Decembrie 2011
OF 1.3 Iunie 2012
OF 1.4 Octombrie 2013

Cele expuse mai departe se bazează pe specificația OpenFlow

Switch versiunea 1.5.1, ONF TS-025, publicată la 26 martie 2015 [7].
Această specificație acoperă componentele și funcțiile de bază ale
comutatorului, precum și protocolul OpenFlow de gestionare a
switch-ului OpenFlow de către controlorul distant.
Arhitectura unui switch generic OpenFlow este prezentată în
figura 2.2. Așa cum este definit în specificația comutatorului
OpenFlow [7], componenta principală a comutatorului OpenFlow
include:
 setul de porturi de intrare,
 setul de porturi de ieșire,
 conducta (pipeline) OpenFlow cu una sau mai multe
tabele de fluxuri,
 canal securizat TLS (Transport Layer Security) pentru
comunicarea cu unul sau mai multe controloare
OpenFlow (pentru o gestionare partajată a comutatorului).
La fel ca și în orice switch de pachete, funcția de bază a unui
comutator OpenFlow este a prelua pachete de la porturile de intrare și
a le transmite la porturile de ieșire destinate.

27 
  
 
 
Controlor  Controlor 
 
 
 
             OpenFlow PDUs: 
OpenFlow/TLS/TCP/IP                             OpenFlow Switch 
 
                                                       Datapath
Canal Canal    
OpenFlow  OpenFlow    Tabelă  Tabelă 
 
 
  de grup  de grup 
 
           Canal de Control      
Fluxuri pachete                                                                                                                          Fluxuri pachete
                            
date:                                                                                                                                           date:  */IP            
 
TCP/IP sau UDP/IP                                                                                                                                               
    Port 
Port Tabelă Tabelă   Tabelă
 
fluxuri  fluxuri    fluxuri 
Port
                                                 . . . 
  Port 
     
 
Pipeline/Conductă 
                                                                   
   
 

Figura 2.2. OpenFlow Switch

Porturile OpenFlow sunt interfețele de rețea pentru trecerea

pachetelor între procesarea OpenFlow și restul rețelei. Comutatoarele
OpenFlow se conectează logic între ele prin porturile OpenFlow.
OpenFlow definește trei tipuri de porturi:
Portul fizic corespunde unei interfețe hardware a comutatorului.
De exemplu, pe un switch Ethernet, porturile fizice se potrivesc cu
interfețele Ethernet. În unele implementări, comutatorul OpenFlow
poate fi virtualizat. În aceste cazuri, un port fizic OpenFlow poate
reprezenta o felie (slice) virtuală a interfeței hardware
corespunzătoare comutatorului.
Portul logic nu corespunde direct unei interfețe hardware a
comutatorului. Porturile logice sunt abstracții de nivel superior care
pot fi definite în comutator folosind metode non-OpenFlow (de
exemplu, grupuri de agregare a linkurilor, tuneluri, interfețe
loopback). Diferența dintre portul fizic și cel logic este că un pachet
asociat unui port logic poate avea un câmp de conductă suplimentar
numit Tunel-ID.
28 
 Portul rezervat specifică acțiuni de expediere generice, cum ar
fi trimiterea și primirea pachetelor de la controlor, difuzarea
(broadcasting) pachetelor sau redicționarea pachetelor utilizând
metode non-OpenFlow, cum ar fi o procesare "normală" de
comutație. Există mai multe tipuri de porturi rezervate obligatorii:
ALL, CONTROLLER, TABLE, IN_PORT, ANY, UNSET, LOCAL.
De exemplu, portul CONTROLLER reprezintă canalul OpenFlow
utilizat pentru comunicarea dintre comutator și controlor. Porturile
rezervate NORMAL și FLOOD se utilizează în mediile hibride și
permit interacțiunea dintre conducta OpenFlow și conducta hardware
a comutatorului.
Comutatoarele OpenFlow-hibrid acceptă atât funcționarea
OpenFlow, cât și funcționarea normală a comutării Ethernet. Deci, un
comutator-hibrid are jumătate din porturile sale cu comutare
tradițională, în timp ce cealaltă jumătate este configurată pentru
OpenFlow. Jumătatea OpenFlow este gestionată de controler-ul
OpenFlow, iar cealaltă jumătate de către unitatea de control locală a
comutatorului. Trecerea traficului între aceste conducte necesită
utilizarea unui port rezervat NORMAL sau FLOOD (figura 2.3).

Figura 2.3. Portul rezervat NORMAL într-un switch hibrid

29 
 Caracteristica importantă a comutatorului SDN este funcție de
redirecționare simplă, fără software încorporat pentru a lua decizii
autonome. În cadrul fiecărui switch se utilizează o serie de tabele
pentru a gestiona fluxurile de pachete. Pentru fiecare pachet primit,
comutatorul OpenFlow identifică mai întâi fluxul căruia îi aparține
pachetul și apoi execută instrucțiunile de procesare specificate pentru
acest flux. Dacă comutatorul nu găsește reguli de potrivire pentru
pachetul de date respectiv, atunci aproximativ 200 de octeți de date
sunt trimise la controlor, care urmează să decidă ce acțiuni adecvate
trebuie luate. Controlorul modifică tabelele de fluxuri din comutator,
astfel încât atunci când pachetele de date similare sosesc la
înregistrările comutatorului se utilizează regulile de potrivire definite
și datele sunt direcționate conform acțiunilor corespunzătoare fără să
trimită pachetul din nou la controlor. Ca urmare, switch-urile și
routerele pot fi simplificate datorită gestionării de către un controlor
logic centralizat, ce sporește performanța și flexibilitatea rețelei.
Căutarea fluxului de potrivire a fiecărui pachet primit și
determinarea acțiunilor care ar trebui luate pentru pachet reprezintă
responsabilitatea principală a conductei (pipeline) OpenFlow.
Funcțiile principale ale comutatorului OpenFlow sunt
următoarele:
Suport control. Interacționează cu nivelul de control SDN
pentru a sprijini programabilitatea prin intermediul interfețelor de
control al resurselor. Comutatorul comunică cu controlerul și acesta
gestionează comutatorul prin intermediul protocolului OpenFlow.
Expedierea datelor. Acceptă fluxurile de pachete primite de la
alte comutatoare sau sisteme terminale și le redirecționează de-a
lungul căilor de expediere calculate și stabilite conform regulilor
definite de aplicațiile SDN.
Aceste reguli de expediere utilizate de comutator sunt incluse în
tabelele de expediere care indică pentru anumite categorii de pachete
care ar fi următorul hop în rută. În plus față de expedierea simplă a
unui pachet, dispozitivul de rețea poate modifica antetul pachetului
înainte a-l expedia sau să renunțe la pachet. Pachetele care sosesc pot
fi plasate într-o coadă de intrare, în așteptarea procesării de către

30 
dispozitivul de rețea, iar pachetele transmise sunt în general plasate
într-o coadă de ieșire, în așteptarea transmisiei.
Canalul OpenFlow realizează interfața care conectează fiecare
comutator la controlor. Prin această interfață, controlorul OpenFlow
configurează și gestionează comutatorul, recepționează evenimentele
de la comutator și trimite pachetele din comutator. În mod tipic, un
controlor gestionează mai multe canale OpenFlow, fiecare la diferite
switch-uri. Un comutator OpenFlow poate suporta un canal la un
controlor sau câteva canale la diferite controloare OpenFlow. În cazul
câtorva controloare ele partajează gestionarea comutatorului, mai des
pentru creșterea fiabilității rețelei. Un canal OpenFlow este de obicei
criptat folosind protocolul de securitate al stratului de transport
(TLS), dar poate rula direct pe TCP.
Specificația OpenFlow [7] definește trei tipuri de tabele în
arhitectura comutatoarelor logice:
 Tabel de fluxuri (flow table);
 Tabel de grup (group table);
 Tabel de măsură (meter table).
Tabelul de fluxuri compară (matches) pachetele primite cu un
anumit flux și specifică ce funcții vor fi efectuate pe pachete. Pot
exista mai multe tabele de fluxuri care funcționează, înlănțuite, în
conductă (pipeline), după cum se explică ulterior.
În termeni generali, un flux este o secvență de pachete care
traversează o rețea și care conțin un set de valori egale ale antetului.
De exemplu, un flux ar putea consta din toate pachetele cu aceleași
adrese IP sursă și destinație sau cu același identificator LAN
(VLAN).
Tabelul de fluxuri poate direcționa fluxul de pachete către un
tabel de grup, care poate declanșa o varietate de acțiuni.
Tabelul de măsură (meter table) poate declanșa acțiuni legate
de performanța pe flux.
Mai jos se expun mai detaliat funcțiile fiecărui tip de tabele din
cele trei menționate.

31 
2.2. Tabelul de fluxuri

Blocul de bază al arhitecturii comutatorului logic OpenFlow este

tabelul de fluxuri (flow table). Fiecare pachet care intră într-un
comutator trece prin una din mai multe tabele de fluxuri. Fiecare tabel
de fluxuri constă dintr-un număr de rânduri, numite înregistrări (flow
entries), alcătuite din șapte componente, așa cum este definit în lista
care urmează (figura 2.4, a).

Match  Priority  Counters  Instructions Timeouts  Cookie  Flags 

fields 
                                                   a) Câmpurile de înregistrare ale tabelei de fluxuri 
 
 
 
 
Ingr  Egr  Ethr  Ethr Ethr  IP  IPv4 IPv4 IPv6 IPv6 TCP  TCP  UDP UDP 
port  port  SA  DA  Type port SA  DA  SA  Da  Src  Dest Src  Dest
b) Câmpurile de comparare/potrivire ale tabelei de fluxuri 
 
Figura 2.4. Formate de înregistrare ale tabelului de fluxuri
OpenFlow

 Match fields (Câmpuri de comparare/potrivire). Se utilizează

ca criteriu pentru a determina dacă un pachet primit se potrivește cu
această înregistrare.
 Priority (Prioritate). Prioritatea relativă a înregistrărilor din
tabele. Acesta este un câmp de 16 biți. Valoarea zero corespunde
celei mai mici priorități. Înregistrarea cu prioritate mai mare în tabel
va fi potrivită înainte de cea cu o prioritate mai mică.
 Counters (Contoare). Specificația OpenFlow definește o
varietate de contoare. Contoarele sunt menținute pentru fiecare tabel
de fluxuri, înregistrări de fluxuri, port, rând, grup de coșuri, pentru a
urmări statisticile referitor la fluxul care corespunde acestei
înregistrări. Contorul este actualizat când un pachet este potrivit,
selectat după un anumit criteriu. Tabelul 2.2 enumeră contoarele care
trebuie să fie suportate obligatoriu de comutatorul OpenFlow.
32 
 Tabelul 2.2. Contoarele OpenFlow obligatorii
Contor Utilizare Bit
Număr de referințe (înregistrări Pe tabelă de fluxuri 32
active)
Durata (secunde) Pe înregistrare tabel 32
Pachete recepționate Pe port 64
Pachete transmise Pe port 64
Durata (secunde) Pe port 32
Pachete transmise Pe rând 64
Durata (secunde) Pe rând 32
Durata (secunde) Pe grup 32
Durata (secunde) Pe măsurare 32

Durata se referă la timpul în care înregistrarea fluxului, portul,

grupul, rândul sau măsurarea au fost instalate în comutator și trebuie
urmărite cu precizie de secundă.
 Instructions (Instrucțiuni). Pentru a fi executate atunci când
un pachet se potrivește cu această înregistrare. Executarea
instrucțiunilor poate avea drept rezultat modificarea conținutului
pachetului, actualizarea setului de acțiuni asociat cu pachetul și
ajustarea secvenței de procesare înlănțuită în conductă (pipeline)
pentru pachet.
 Timeouts (Perioadele de expirare). Perioada maximă de timp
sau timpul de inactivitate înainte de respingerea fluxului de către
comutator. Fiecare înregistrare de flux are un idle_timeout și un
hard_timeout asociate cu acesta. Un câmp hard_timeout mai mare ca
0 face ca înregistrarea fluxului să fie eliminată după numărul de
secunde dat, indiferent de câte pachete au fost potrivite. Un câmp
idle_timeout diferit de 0 secunde face ca înregistrarea fluxului să fie
eliminată dacă nu s-a potrivit nici un pachet în timpul dat.
 Cookie. Valoarea de date pe 64 biți, aleasă de controlor. Poate
fi utilizată de controlor pentru filtrarea statisticilor, modificarea și
ștergerea fluxului. La procesarea pachetelor nu se utilizează.
 Flags (Steaguri). Modifică modul în care sunt gestionate
înregistrările de flux, de exemplu, fanionul
33 
OFPFF_SEND_FLOW_REM declanșează fluxul de mesaje eliminate
pentru acea înregistrare de flux.

2.2.1. Câmpurile de potrivire ale tabelului de fluxuri

O înregistrare din tabelul de fluxuri este identificată prin

câmpurile de potrivire și de prioritate. Câmpurile de potrivire și de
prioritate luate împreună identifică o înregistrare unică a fluxului într-
un anumit tabel de fluxuri.
Un pachet se potrivește cu o înregistrare de flux dacă toate
câmpurile de potrivire ale înregistrării de flux corespund antetului și
câmpurilor conductei pachetului. Înregistrarea fluxului cu valori
”wilcards” pentru toate câmpurile (toate câmpurile sunt omise) cu
prioritatea egală cu 0 se numește înregistrare de flux lipsă-tabel
(table-miss). Valoarea de tip ”wildcard” semnifică că este posibilă
orice valoare și se notează prin semnul de asterisc (*). Înregistrarea
de flux lipsă-tabel este ultima din tabel. Ea este ca un catch-all
(prinde tot, capturează), iar acțiunile care trebuie luate depind de
modul în care este configurată această înregistrare. Fiecare tabel de
fluxuri trebuie să susțină o înregistrare lipsă-tabel pentru a procesa
insuccesele tabelului.
Componenta câmpurilor de potrivire a unei înregistrări din tabel
constă din următoarele câmpuri obligatorii (figura 2.4,b):
 Port de intrare. Identificatorul portului switch-ului pe care a
sosit pachetul. Acesta poate fi un port fizic sau un port virtual definit
de switch. Obligatoriu în tabelele de intrare.
 Port de ieșire. Identificatorul portului de ieșire din setul de
acțiuni. Obligatoriu la tabelele de ieșire.
 Adresele sursă și destinație Ethernet. Fiecare înregistrare
poate fi o adresă exactă, o valoare bitmascată pentru care sunt
verificați doar câțiva biți din adresă sau o valoare de tip ”wildcard”
(se potrivesc cu orice valoare).
 Tipul câmpului Ethernet. Indică tipul de încărcare utilă a
pachetului Ethernet.
 Port IP. IP versiunea a 4-a sau a 6-a.

34 
  Adrese IPv4 sau IPv6 sursă și de destinație. Fiecare
înregistrare poate fi o adresă exactă, o valoare bitmascată, o valoare a
unei măști de subrețea sau o valoare de tip ”wildcard”.
 Porturile TCP sursă și destinație. Valoarea exactă sau
valoarea "wildcard".
 Porturile UDP sursă și destinație. Valoarea exactă sau
valoarea "wildcard".
Câmpurile de comparare menționate trebuie să fie acceptate de
orice comutator compatibil OpenFlow. Însă pot fi și un șir de câmpuri
acceptate ca opționale: porturile sursă și destinație ale protocolului
SCTP (Stream Control Transmission Protocol); metadate (informații
suplimentare care pot fi transmise de la un tabel la altul în timpul
procesării unui pachet); valoarea etichetei MPLS, clasa de trafic și
QoS; identificator VLAN și prioritate utilizator VLAN (câmpurile din
antetul unui LAN virtual IEEE 802.1Q, dacă SDN suportă VLAN-
uri); port fizic (utilizat pentru a desemna portul fizic subiacent atunci
când pachetul este recepționat pe un port logic) etc.
Astfel, OpenFlow poate fi utilizat cu trafic de rețea care implică o
varietate de protocoale și servicii de rețea. Rețineți că, la nivelul
MAC (de link), este acceptat numai Ethernet. Prin urmare,
OpenFlow, așa cum este definit în prezent, nu poate controla traficul
nivelului 2 pe rețelele fără fir.
Acum se poate defini mai precis termenul de flux. Din punctul de
vedere al unui comutator individual, un flux este o secvență de
pachete care se potrivește cu o înregistrare specifică într-un tabel de
fluxuri. Definiția este orientată pe pachete, în sensul că aceasta este o
funcție a valorilor câmpurilor de antet ale pachetelor care constituie
fluxul și nu o funcție a căii pe care o urmăresc prin rețea. O
combinație de înregistrări de flux pe mai multe comutatoare definește
un flux legat de o anumită cale.
Folosind protocolul de comutare OpenFlow, controlorul poate
adăuga, actualiza și șterge înregistrările fluxului în tabelele de fluxuri,
atât reactiv (ca răspuns la pachete) cât și proactiv.
Înregistrările fluxului sunt create reactiv atunci când controlorul
învață în mod dinamic locul dispozitivelor în topologia rețelei și

35 
trebuie să actualizeze tabelele de fluxuri ale acestor dispozitive
pentru a construi conectivitatea cap-la-cap. Deoarece comutatoarele
OpenFlow doar expediază traficul, toată logica de expediere trebuie
mai întâi să fie programată și apoi dictată de către controlor. De
exemplu, dacă o gazdă de pe comutatorul A solicită să comunice cu o
gazdă de pe comutatorul B, mesajul mai întâi va fi trimis
controlorului pentru a construi calea spre această gazdă. Controlorul
va consulta adresele MAC ale switch-urilor și modul în care se
conectează, programând logica în tabelele de fluxuri ale fiecărui
comutator. Mesajele care vor urma vor fi trimise direct pe calea
construită de controlor.
Înregistrările de flux proactive sunt programate în prealabil,
înainte de sosirea traficului. Dacă este posibil ca două dispozitive ale
rețelei să comunice, controlorul poate programa din timp înregistrări
de flux corespunzătoare ca puncte finale ale OpenFlow.

2.2.2. Componenta Instrucțiuni a tabelului de fluxuri

Componenta Instructions a înregistrării tabelului de fluxuri

constă dintr-un set de instrucțiuni care sunt executate dacă pachetul se
potrivește cu înregistrarea. Înainte a descrie tipurile de instrucțiuni,
trebuie să definim termenii acțiune și set de acțiuni.
Acțiune este expedierea pachetelor, modificarea pachetelor și
operațiile de procesare în tabelele de grup.
Un set de acțiuni este o listă de acțiuni asociate unui pachet care
sunt acumulate în timp ce pachetul este procesat de fiecare tabel și
care sunt executate atunci când pachetul iese din conducta de
procesare.
Specificația OpenFlow include următoarele acțiuni:
 Output (Ieșire): Expedierea pachetului către portul specificat.
Portul ar putea fi un port de ieșire către un alt switch sau portul către
controler. În acest din urmă caz, pachetul este încapsulat într-un
mesaj către controlor.
 Set-Queue (setare coadă): Setează ID-ul de coadă pentru
pachet. Când pachetul este expediat către un port utilizând acțiunea

36 
de ieșire, ID-ul de coadă determină ce coadă atașată la acest port este
utilizată pentru programarea și expedierea pachetului. Modul de
expediere este dictat de disciplina cozii și este folosit pentru a oferi
suport parametrilor QoS de bază.
 Group (Grupa): Procesarea pachetului prin grupul specificat.
 Push-Tag/Pop-Tag (Împinge-etichetă/Trage-etichetă): Push
sau pop unui tag pentru pachetele VLAN sau MPLS.
 Set-Field (setare câmp): acțiunea Set-Field este identificată
după tipul de câmp și modifică valoarea câmpului respectiv din
antetul pachetului.
 Change-TTL (schimbă TTL): Acțiunea ChangeTTL modifică
valorile TTL (time to live - timp pentru a trăi) din IPv4, limita de
hop-uri IPv6 sau TTL în antetul MPLS.
 Drop (cădere): Nu există acțiune explicită care să reprezinte
căderea. În schimb, pachetele ale căror seturi de acțiuni nu au nici o
acțiune Output trebui să fie aruncate.
Tipurile de instrucțiuni pot fi grupate în patru categorii:
 Direcționarea pachetului prin conductă (pipeline):
Instrucțiunea Goto-Table direcționează pachetul către un tabel de-a
lungul conductei. Instrucțiunea Meter (măsurare) direcționează
pachetul către un contor specificat.
 Efectuarea acțiunii asupra pachetului: acțiunile pot fi
efectuate pe pachet atunci când sunt potrivite cu o înregistrare din
tabel. Instrucțiunea Apply-Actions (aplicați-acțiuni) aplică acțiunile
specificate imediat, fără a schimba setul de acțiuni asociat cu acest
pachet. Această instrucțiune poate fi utilizată pentru a modifica
pachetul dintre două tabele din conductă.
 Actualizarea setului de acțiuni: instrucțiunea Write-Actions
îmbină acțiunile specificate în setul de acțiuni curent pentru pachetul
dat. Instrucțiunea Clear-actions elimină toate acțiunile din setul de
acțiuni.
 Actualizarea meta datelor: o valoare de metadate poate fi
asociată unui pachet. Este folosit pentru a transporta informații de la
un tabel la următorul. Instrucțiunea Write-Metadata actualizează
valoarea meta datelor existentă sau creează o nouă valoare.

37 
2.3. Tabelul de grup

Un tabel de grup constă din înregistrări de grup. Abilitatea unei

înregistrări de flux pentru a indica un grup, permite OpenFlow să
prezinte metode suplimentare de redirecționare (spre exemplu, cele
selectate sau toate).
În cursul procesării în conductă, tabelul de fluxuri poate
direcționa un flux de pachete spre tabelul de grup. Tabelul de grup și
acțiunile de grup permit OpenFlow să reprezinte un set de porturi ca o
singură entitate pentru expedierea pachetelor. Pentru a reprezenta
diferite abstracții de expediere, cum ar fi multicasting-ul sau
broadcasting-ul, sunt furnizate diferite tipuri de grupuri.
Fiecare tabel de grup constă dintr-un număr de rânduri, numite
înregistrări de grup, compuse din patru componente (figura 2.5):

Group  Group  Counters  Action 

Identifier  Type  Buckets 

Figura 2.5. Câmpurile de înregistrare ale tabelului de grup

 Group identifier (identificator de grup). Număr întreg de 32

biți care identifică în mod unic grupul de pe comutatorul OpenFlow.
 Group type (tip de grup). Determină semantica grupului.
 Counters (contoare). Se actualizează când pachetele sunt
procesate de grup.
 Action buckets (coșuri de acțiune). O listă ordonată a
coșurilor de acțiune, în care fiecare coș de acțiune conține un set de
acțiuni care trebuie executate și parametrii asociați. Acțiunile dintr-un
coș sunt întotdeauna aplicate ca set de acțiuni.
Un coș conține de obicei acțiuni care modifică pachetul și o
acțiune de ieșire care expediază pachetul spre un port. El poate
include, de asemenea, o acțiune de grup care invocă un alt grup dacă
comutatorul acceptă înlănțuirea, în acest caz procesarea pachetelor
continuă în grupul invocat.

38 
2.4. Tabelul de măsurare

Un tabelul de măsurare constă din înregistrări de măsură, care

definesc măsurările pe flux. Măsurările pe flux permit OpenFlow să
implementeze limitările ratei, o operație simplă QoS care limitează un
set de fluxuri la o lățime de bandă aleasă.
Măsurările pe flux pot, de asemenea, să permită OpenFlow să
implementeze operațiuni de politici QoS mai complexe, cum ar fi
contorizarea bazată pe DSCP (Differentiated Services Code Point - cei
șase biți mai semnificativi ai câmpului DiffServ din IP), care poate
clasifica un set de pachete în mai multe categorii bazate pe rata sa.

Meter Identifier Meter Bands Counters

Figura 2.6. Câmpurile înregistrării tabelului de măsurare

Fiecare înregistrare (figura 2.6) conține:

• identificator: un număr întreg de 32 de biți, care identifică în
mod unic contorul;
• benzile de măsurare: o listă neordonată de benzi de măsurare,
unde fiecare bandă de măsură specifică rata și modul de procesare al
pachetului;
• contoare: actualizate atunci când pachetele sunt procesate de
tabel.

2.5. Procesarea pachetelor în conductă (pipeline)

Conducta OpenFlow a fiecărui comutator logic OpenFlow

conține una sau mai multe tabele de fluxuri, fiecare din aceste tabele
conține multiple înregistrări de flux. Procesarea în conducta
OpenFlow definește modul în care interacționează pachetele cu tabele
de fluxuri. Un comutator OpenFlow trebuie să aibă cel puțin un tabel
de fluxuri de intrare, dar de regulă are mai multe tabele. Un
comutator OpenFlow cu un singur tabel de fluxuri este valabil, dar în
acest caz procesarea în conductă este mult simplificată. Tabelele de
39 
fluxuri dintr-o conductă OpenFlow sunt numerotate pornind de la 0 în
ordinea în care pot fi traversate de pachete.
Procesarea în conductă se desfășoară în două etape, procesarea de
intrare și procesarea de ieșire (figura 2.7).
 
 
Pachet in
   
Procesare   de
 
intrare
 
 
 
Port Tabelă Tabelă   Tabelă Executare Tabelă
 
intrare fluxuri fluxuri   fluxuri de
       ...  set
0 1   n grup
      acțiuni
 
 
 
 
 
 
 
Procesare   de ieșire
  
  
 
Tabelă Tabelă  .       ...  Tabelă Executare Port
fluxuri fluxuri   fluxuri set ieșire
e e+1   e+m acțiuni
 
 
 
                                                                     Pachet out                             PPPP            P                      Packet out 

Figura 2.7. Fluxul de pachete prin conducta de procesare

Separarea celor două etape este indicată de primul tabel de ieșire.

Pentru fiecare pachet procesarea începe cu potrivirea antetului
pachetului cu înregistrările de flux ale tabelului 0. Alte tabele de
fluxuri de intrare pot fi utilizate în funcție de rezultatul de potrivire al
tabelului precedent. Dacă, ca rezultat al procesării de intrare,
pachetul trebuie transmis către un port de ieșire, comutatorul
OpenFlow va începe să efectueze procesarea de ieșire în contextul
acelui port de ieșire.
Procedura de potrivire și de executare a instrucțiunilor într-un
tabel de fluxuri este ilustrată în figura 2.8.

40 
 Găsiți înregistrarea
Înregistrare flux TABELĂ de FLUXURI
flux cu cea mai înaltă
prioritate la potrivire Înregistrare flux
Aplică instrucțiunile
Potrivire
Înregistrare flux
•
•
•
Înregistrare flux
Înregistrare flux
lipsă-tabelă Clear-Action: Goto- Tabelă
Set de • set de acțiune gol Table de
acțiuni Write-Action: {table fluxuri
{set de acțiuni} -id}
• îmbinare în set de
acțiuni
Câmpuri
conductă Aplicare-acțiuni
{listă de acțiuni}:
- modifică pachetul, Executare
-actualizează câmpurile de set de
potrivire, acțiuni
Extrage
Pachet câmpurile -actualizează câmpurile
antetului conductei,
-dacă spre ieșire sau grup
→ clone de pachet.
Pachete de clone
Ieșire

Figura 2.8. Potrivirea și executarea instrucţiunilor în tabelul de

fluxuri
Dacă o înregistrare de flux este potrivită, se execută setul de
instrucțiuni asociat acelei înregistrări. Executarea instrucțiunilor
poate transfera pachetul într-un alt tabel de fluxuri care are un număr
mai mare de tabel (adică prelucrarea conductei poate merge numai
înainte, nu și înapoi). Fiecărui pachet i se asociază un set de acțiuni.
Acest set este gol în mod implicit pentru un pachet care începe
procesarea în conducta OpenFlow. În timpul procesului, fiecare
înregistrare de flux potrivită pachetului poate modifica setul de
acțiuni al pachetului utilizând instrucțiunile Write Action sau Clear
Action. Setul de acțiuni este transmis între tabelele de fluxuri.
Procesarea în conductă se oprește când setul de instrucțiuni dintr-o
41 
înregistrare de flux potrivită nu conține o instrucțiune Goto-Table.
Apoi acțiunile din setul de acțiuni al pachetului sunt executate
(pentru mai multe detalii vezi [7]).
Diagrama grafică care ilustrează procesarea pachetului în
conducta OpenFlow la transferul lui prin comutator este prezintă de
figura 2.9 [7].
În mod obișnuit sunt mai multe tabeluri de fluxuri. Potrivirea
începe de la primul tabel și poate continua cu următoarele tabele ale
conductei. Pachetul trebuie să fie întâi potrivit cu înregistrările
tabelului cu numărul 0 în ordinea descreșterii priorității lor. Pentru
tabelul 0, valoarea meta datelor și setul de acțiune este nul.
Procesarea continuă la fiecare tabel după cum se prezintă pe
schemă (figura 2.9).
Alte tabele de fluxuri de intrare pot fi utilizate în funcție de
rezultatul potrivirii (match-ului) din tabelul 0. Dacă în rezultatul
procesării de intrare pachetul este transmis către un port de ieșire,
comutatorul OpenFlow va efectua procesarea de ieșire în contextul
acelui port de ieșire.
1. Dacă există o potrivire pentru una sau mai multe înregistrări,
alta decât înregistrarea de flux lipsă-tabel, rezultatul este definit ca
fiind potrivit cu intrarea cu cea mai mare prioritate. După cum s-a
menționat mai sus, prioritatea este o componentă a unei înregistrări în
tabel și este setată prin OpenFlow (prioritatea este determinată de
utilizator sau de aplicație).

42 
 Intrare pachet  
- set gol de acțiuni
 
- inițiere câmpuri pipeline
 
- start cu tabela de fluxuri 0
 
   
Actualizare contoare.
Executare set Da Executare set acțiuni:
instrucțiuni: -actualizarea
-actualizarea setului de anteturilor pachetului
Este acțiuni Goto -actualizarea
potrivire Da -actualizarea anteturilor tabela Nu câmpurilor potrivire
în tabela pachetului n? -actualizarea
n? -actualizarea câmpurilor câmpurilor pipeline
potrivire (conductă) 
- actualizare câmpurilor
pipeline
Nu - dacă e necesar,
clonarea pachetului Acțiune Da
la ieșire grup?
Este
Da Nu
înregistrare
„table-
miss” ?
Nu Acțiune
Aruncare
ieșire?
pachet
Nu
Aruncare
pachet Da
Procesare intrare
Procesare ieșire

Start procesare ieșire
‐stabilire set acțiuni  Sunt
Da tabele
Nu
‐trecere la prima tabelă ieșire
Ieșire?

Actualizare contoare.
Executare set Da
instrucțiuni: Executare set acțiuni:
-actualizarea setului de -actualizarea anteturilor
Este
Da acțiuni Goto Nu pachetului
potrivire
-actualizarea anteturilor tabela -actualizarea câmpurilor
în tabela
pachetului n? potrivire
n?
-actualizarea -actualizarea câmpurilor
câmpurilor potrivire pipeline (conductă) 
Nu - actualizare câmpurilor
pipeline
- dacă e necesar,
clonarea pachetului Acțiune
Este Aruncare Nu
la ieșire pachet ieșire?
înregistrare
„table- Da
miss” ?

Da
Nu Packet out
Aruncare pachet

Figura 2.9. Diagrama grafică simplificată de procesare a

pachetelor în comutatorul OpenFlow
43 
 Următorii pași pot fi apoi executați:
a) se actualizează contoarele asociate cu această înregistrare;
b) se execută instrucțiunile asociate înregistrării. Aceasta poate
include actualizarea setului de acțiuni, valorii meta datelor și
efectuarea acțiunilor;
c) pachetul este apoi trimis la următoarul tabel de fluxuri, la
tabelul de grup, la tabelul de măsurare sau direcționat spre un port de
ieșire.
2. Dacă potrivirea este doar pe înregistrarea lipsă-tabel, care
poate conține instrucțiuni, ca și cu orice altă înregistrare. În practică,
înregistrarea lipsă-tabelă indică una dintre cele trei acțiuni:
a) pachetul se trimite către controlor. Acest lucru va permite
controlorului să definească un nou flux pentru acesta și alte pachete
similare sau să renunțe la pachet;
b) pachetele se redirecționează către alt tabel de fluxuri,
următorul în conductă;
c) pachetul se aruncă.
3. Dacă nu există potrivire cu nici o înregistrare și nu există
înregistrarea lipsă-tabel, pachetul este aruncat.
Procesarea în conducta de ieșire se desfășoară în același mod ca
și în cazul procesării de intrare, cu excepția faptului că nu există o
prelucrare în tabelul de grup la capătul conductei de ieșire.
Pentru tabelul final în conductă, redirecționarea către un alt tabel
de fluxuri nu este posibilă. Când pachetul este în final direcționat
către un port de ieșire, setul de acțiuni acumulat este executat și
pachetul este pus în așteptare pentru ieșire.

2.6. Mesaje OpenFlow

Protocolul OpenFlow definește mesajele și formatele lor folosite

între controlor (nivelul de control) și dispozitivul de rețea (nivelul
resurselor). Protocolul OpenFlow acceptă trei tipuri de mesaje:
controler-to-switch, asincron și simetric, fiecare cu multiple
subtipuri.

44 
2.6.1. Mesaje controler-to-switch

Mesajele de la controlor spre comutator sunt inițiate de către

controlor și utilizate pentru a gestiona direct sau a inspecta starea
comutatorului. Aceste mesaje includ:
Features (Caracteristici) - controlorul solicită identitatea și
capacitățile de bază ale comutatorului. Această solicitare are loc de
regulă la inițierea canalului OpenFlow.
Configuration (Configurația) - setarea și interogarea parametrilor
de configurare din comutator.
Modify-State (Modică-Starea) - pentru a gestiona starea
comutatorului. A adăuga, șterge și modifica intrările de flux / grup, a
introduce / elimina coșurile de acțiuni în tabelele OpenFlow și a seta
proprietățile porturilor.
Read-States (Citește starea) - pentru a colecta diverse informații
de la comutator, cum ar fi configurația curentă, statisticile și
capabilitățile lui.
Packet Out (Pachet transmis) - pentru a trimite pachetele dintr-un
port specificat al comutatorului. Mesajul trebuie să conțină fie un
pachet complet, fie un ID tampon referitor la un pachet stocat în
comutator. De asemenea, mesajul trebuie să conțină o listă de acțiuni
aplicabile în ordinea în care sunt specificate (o listă goală de acțiuni
elimină pachetul).
Barrier (Barieră) - Solicitările/răspunsurile de barieră sunt
utilizate de controlor pentru a se asigura că au fost îndeplinite
subordonările mesajelor sau pentru a primi notificări pentru
operațiile finalizate.
Role-Request (Solicitare rol) - pentru a seta rolul canalului
OpenFlow sau a ID-ul său. Acest mesaj este deosebit util atunci când
comutatorul este conectat la câteva controloare.
Asynchronous-Configuration (Configurarea asincronă) - setarea
unui filtru suplimentar pentru mesajele asincrone pe care controlorul
dorește să le primească pe canalul OpenFlow. Se utilizează de regulă
atunci când comutatorul se conectează la mai mulți controlori și se
realizează la stabilirea canalului OpenFlow.

45 
2.6.2. Mesaje asincrone

Mesajele asincrone sunt inițiate de către comutator și utilizate

pentru a informa controlorul despre evenimentele din rețea și
schimbările de stare ale comutatorului. Principalele tipuri de mesaje
asincrone sunt descrise mai jos:
Packet-in: Transferul controlului pachetului către controlor.
Flow-Removed (Flux eliminat): Informează controlorul despre
eliminarea unei înregistrări de flux dintr-un tabel de fluxuri. Mesajele
Flow-Removed sunt trimise doar pentru înregistrările de flux cu
fanionul OFPFF_SEND_FLOW_REM. Mesajul este generat ca
urmare a solicitării controlorului de ștergere a fluxului sau la
expirarea timpului rezervat pentru comutarea fluxului (TTL), sau din
alte motive.
Port-status (Stare-port): Informează controlorul despre
modificarea pe un port. Comutatorul trimite mesajul de stare port
controlorului după schimbarea configurației sau modificarea de stare
a portului. De exemplu, modificată în mod direct de utilizator sau la
căderea linkului.
Role-status (Stare-rol): Informează controlorul despre o
schimbare a rolului său. Atunci când un nou controlor se desemnează
ca master (principal), comutatorul trebuie să trimită mesaj de stare
fostului controlor master.
Controller-Status (Stare-controler): Informează controlorul
despre modificarea stării unui canal OpenFlow. Comutatorul trimite
aceste mesaje tuturor controlorilor atunci când starea canalului
OpenFlow la oricare comutator se schimbă. Acest lucru poate ajuta la
procesarea erorii dacă controlorii pierd capacitatea de a comunica
între ei.
Flow-monitor (Monitor de flux): Informează controlorul despre
schimbări în tabelul de fluxuri. Un controlor poate defini un set de
monitori pentru a urmări schimbările în tabelele de fluxuri.

46 
2.6.3. Mesaje simetrice

Mesajele simetrice sunt inițiate de comutator sau controlor și sunt

trimise fără solicitare. Tipurile de mesaje simetrice utilizate sunt
descrise mai jos:
Hello (Salut) - Mesajele de salut sunt schimbate între comutator
și controlor la pornirea conexiunii.
Echo (Ecou) - Mesajul de solicitare ecou poate fi trimis de
comutator sau de controlor și trebuie să se finalizeze cu răspuns ecou.
Este utilizat în principal pentru a verifica viabilitatea unei conexiuni
între controlor și comutator și poate fi folosit pentru a măsura latența
sau lățimea de bandă.
Error (Eroare) - Mesajele de eroare sunt utilizate de către
comutator sau controlor pentru a anunța despre careva probleme la
cealaltă parte a conexiunii. Acestea sunt utilizate mai des de către
comutator pentru a indica o defecțiune a unei solicitări inițiate de
controlor.
Experimenter (Experimentator) - Mesajele Experimenter oferă
comutatoarelor un mod standard de experimentare a funcționalităților
suplimentare în spațiul de tip OpenFlow.

2.7. Formatul de bază al protocolului OpenFlow

Miezul specificației switch OpenFlow este setul de structuri

utilizate pentru mesajele OpenFlow Switch Protocol. Protocolul
OpenFlow este implementat folosind mesajele descrise mai sus și
transmise prin canalul OpenFlow. Fiecare tip de mesaj este descris de
o structură specifică, dar care începe cu un antet OpenFlow comun.
Structura mesajului poate include și alte structuri care pot fi comune
pentru mai multe tipuri de mesaje. Fiecare structură definește ordinea
în care informațiile sunt incluse în mesaj și pot conține alte structuri,
valori, enumerări sau mascări binare (bitmasks). Toate mesajele
OpenFlow sunt trimise în format big-endian.
OpenFlow este un protocol simplu binar, prin urmare, mesajele
OpenFlow nevalide, generate de implementările OpenFlow, vor

47 
genera mesaje având o lungime greșită sau anumite câmpuri cu valori
nevalide. Se recomandă monitorizarea acestor condiții pentru a
detecta neconformitatea implementării.
Fiecare mesaj începe cu antetul OpenFlow [7]:

/* Header on all OpenFlow packets. */

struct ofp_header {
uint8_t version; /* OFP_VERSION. */
uint8_t type; /* One of the OFPT_ constants. */
uint16_t length; /* Length including this ofp_header. */
uint32_t xid; /* Transaction id associated with this packet.Replies
use the same id as was in the request to facilitate pairing. */
};
OFP_ASSERT(sizeof(struct ofp_header) == 8);

OFP VERSION - specifică versiunea protocolului de comutare

OpenFlow utilizat. Cel mai semnificativ bit din câmpul de versiune
este rezervat și trebuie să fie setat la 0. Ceilalți 7 biți inferiori indică
numărul de versiunii ale protocolului. Versiunea protocolului descrisă
aici este 1.5.1 ce corespunde versiunii ofp 0x06.
Câmpul type (tipul) poate avea următoarele valori [7]:

enum ofp_type {
/* Immutable messages. */
OFPT_HELLO = 0, /* Symmetric message */
OFPT_ERROR = 1, /* Symmetric message */
OFPT_ECHO_REQUEST = 2, /* Symmetric message */
OFPT_ECHO_REPLY = 3, /* Symmetric message */
OFPT_EXPERIMENTER = 4, /* Symmetric message */

/* Switch configuration messages. */

OFPT_FEATURES_REQUEST = 5, /* Controller/switch
message */
OFPT_FEATURES_REPLY = 6, /* Controller/switch message */

48 
 OFPT_GET_CONFIG_REQUEST = 7, /* Controller/switch
message */
OFPT_GET_CONFIG_REPLY = 8, /* Controller/switch
message */
OFPT_SET_CONFIG = 9, /* Controller/switch message */

/* Asynchronous messages. */
OFPT_PACKET_IN = 10, /* Async message */
OFPT_FLOW_REMOVED = 11, /* Async message */
OFPT_PORT_STATUS = 12, /* Async message */

/* Controller command messages. */

OFPT_PACKET_OUT = 13, /* Controller/switch message */
OFPT_FLOW_MOD = 14, /* Controller/switch message */
OFPT_GROUP_MOD = 15, /* Controller/switch message */
OFPT_PORT_MOD = 16, /* Controller/switch message */
OFPT_TABLE_MOD = 17, /* Controller/switch message */

/* Multipart messages. */
OFPT_MULTIPART_REQUEST = 18, /* Controller/switch
message */
OFPT_MULTIPART_REPLY = 19, /* Controller/switch message
*/

/* Barrier messages. */
OFPT_BARRIER_REQUEST = 20, /* Controller/switch message
*/
OFPT_BARRIER_REPLY = 21, /* Controller/switch message */

/* Controller role change request messages. */

OFPT_ROLE_REQUEST = 24, /* Controller/switch message */
OFPT_ROLE_REPLY = 25, /* Controller/switch message */

/* Asynchronous message configuration. */

49 
 OFPT_GET_ASYNC_REQUEST = 26, /* Controller/switch
message */
OFPT_GET_ASYNC_REPLY = 27, /* Controller/switch message
*/
OFPT_SET_ASYNC = 28, /* Controller/switch message */

/* Meters and rate limiters configuration messages. */

OFPT_METER_MOD = 29, /* Controller/switch message */

/* Controller role change event messages. */

OFPT_ROLE_STATUS = 30, /* Async message */

/* Asynchronous messages. */
OFPT_TABLE_STATUS = 31, /* Async message */

/* Request forwarding by the switch. */

OFPT_REQUESTFORWARD = 32, /* Async message */

/* Bundle operations (multiple messages as a single operation).

*/
OFPT_BUNDLE_CONTROL = 33, /* Controller/switch message
*/
OFPT_BUNDLE_ADD_MESSAGE = 34, /* Controller/switch
message */

/* Controller Status async message. */

OFPT_CONTROLLER_STATUS = 35, /* Async message */};

Câmpul length indică lungimea totală a mesajului, inclusiv și

antetul, astfel nu se utilizează nici un indiciu suplimentar pentru a
distinge cadrul.
Câmpul t xid determină identificatorul acestei tranzacții.
În capitolul 2 s-a încercat a oferi cititorului o înțelegere la nivel
general al OpenFlow. Pentru cititorul interesat de o înțelegere mai
aprofundată a acestui protocol, indiferent de interesul academic, nu

50 
există nici o alternativă specificațiilor OpenFlow, în special cea citată
în acest capitol [7]. Aceste specificații sunt, totuși, foarte detaliate și
nu este ușor pentru un novice OpenFlow să le urmeze. Credem că
acest capitol va servi ca un excelent punct de plecare și ghid pentru
acel cititor care trebuie să se aprofundeze în specificațiile
voluminoase care cuprind versiunile OpenFlow.
Pentru aprofundarea și actualizarea cunoașterii mai multor
aspecte legate de SDN se recomandă consultarea periodică a site-
urilor [8,9,10].

51 
 BIBLIOGRAFIE

1. https://www.itu.int/en/ITU-T/studygroups/2017-
2020/13/Pages/q2.aspx.
2. Open Networking Foundation. Software-Defined Networking:
The New Norm for Networks. ONF White Paper, April 13, 2012.
3. Open Data Center Alliance. Open Data Center Alliance
Master Usage Model:Software-Defined Networking Rev. 2.0. White
Paper. 2014.
4. Recommendation ITU-T Y.3300. Framework of software-
defined networking. 2014.
5. Recommendation ITU-T Y.3302. Functional architecture of
software-defined networking. 2017.
6. ETSI GS AFI 002 V1.1.. Autonomic network engineering for
the self-managing Future Internet (AFI); Generic Autonomic Network
Architecture. 2013.
7. ONF TS-025. OpenFlow Switch Specification, Version 1.5.1.
March 26, 2015.
https://www.opennetworking.org/images/stories/downloads/sdn-
resources/onf-specifications/openflow/openflow-switch-v1.5.1.pdf.
8. Website: Open Networking Foundation,
http://opennetworking.org
9. Website: OpenDaylight, https://www.opendaylight.org/
10. Website: Project Floodlight,
http://www.projectfloodlight.org/floodli ght/

52 
 ACRONIME ȘI ABREVIERI
Acronimele și abrevierile sunt sortate după alfabet.

ACI Application Control Interface

ACL Access Control List
AL Application Layer
ALM Application Layer Management
AL-MSO Application Layer Management Support and
Orchestration
API Application Programming Interface
BSS Business Support System
CAM Content Addressable Memory
CDN Content Deliveri Network
CL Control Layer
CL-AS Control Layer Application Support
CL-MSO Control Layer Management Support and Orchestration
CL-RA Control Layer Resource Abstraction
CLM Control Layer Management
DevOps Development Operations
DPID Datapath ID
DSCP Differentiated Services Code Point
ERM External Relationship Management
FCAPS Fault, Configuration, Accounting, Performance and
Security
FN Future Networks
IEEE Institute of Electrical and Electronics Engineers
IMT-2020 International Mobile Telecommunications
IP Internet Protocol
ITU International Telecommunications Union
KPI Key Performance Indicator
LAN Local Area Network
MAC Media Access Control
MMF Multi-layer Management Functions
MMFA Multi-layer Management Functions Application layer
MMFC Multi-layer Management Functions Control layer

53 
MMFO Multi-layer Management Functions OSS/BSS
MMFR Multi-layer Management Functions Resource layer
MMO Multi-Layer Management Orchestration
MPLS Multiprotocol Label Switching
NFV Network Functions Virtualization
NGN Next Generation Networks
NOX Network Operative System
ODCA Open Data Center Aliance
ODL OpenDaylight
ONOS Open Network Operating System
ONF Open Networking Foundation
OSS Operations Support System
POX NOX in Python
QoS Quality of Service
RAM Random Access Memory
RCI Resource Control Interfaces
RL Resource Layer
RL-CS Resource Layer Control Support
RL-DP Resource Layer Data Processing
RL-DT Resource Layer Data Transport
RL-MS Resource Layer Management Support
RLM Resource Layer Management
SCTP Stream Control Transmission Protocol
SDN Software-Defined Networking
SDN-AL SDN Application Layer
SDN-CL SDN Control Layer
SDN-RL SDN Resource Layer
SLA Service Level Agreement
TCP Transmission Control Protocol
TLS Transport Layer Security
TTL Time-To-Live
UDP User Datagram Protocol
VLAN Virtual Local Area Network
WAN Wide Area Network

54 
 CUPRINS

INTRODUCERE.................................................................................3
1. REȚELE DEFINITE PRIN SOFTWARE.....................................4
1.1 Definiția SDN...........................................................................5
1.2 Arhitectura SDN.......................................................................7
1.2.1 Nivelul aplicațiilor SDN (SDN-AL)........................10
1.2.2 Nivelul de control SDN (SDN-CL)..........................12
1.2.3 Nivelul resurselor SDN (SDN-RL)..........................15
1.2.4 Funcțiile de management multi-nivel ......................18
2. PROTOCOLUL OPENFLOW...................................................24
2.1 Componentele principale ale OpenFlow Switch................26
2.2 Tabelul de fluxuri.................................................................32
2.2.1 Câmpurile potrivire ale tabelului de fluxuri.............34
2.2.2 Componenta Instrucțiuni a tabelului de flux............36
2.3 Tabelul de grup....................................................................38
2.4 Tabelul de măsurare.............................................................39
2.5 Procesarea pachetelor în conductă (pipeline).....................39
2.6 Mesaje OpenFlow................................................................44
2.6.1 Mesaje controler-to-switch.......................................45
2.6.2 Mesaje asincrone......................................................46
2.6.3 Mesaje simetrice........................................................47
2.7 Formatul de bază al protocolului OpenFlow.......................47
BIBLIOGRAFIE................................................................................52
ACRONIME ȘI ABREVIERI...........................................................53

55 
 REȚELE DEFINITE PRIN SOFTWARE
Ciclu de prelegeri

Autor: Ion Nazaroi

Redactor: E. Gheorghișteanu
––––––––––––––––––––––––––––––––––––––––––––––––––––––
Bun de tipar 15.03.19 Formatul 60x84 1/16
Hârtie ofset. Tipar RISO Tirajul 55 ex.
Coli de tipar 3,5 Comanda nr. 29
––––––––––––––––––––––––––––––––––––––––––––––––––––––
U.T.M., 2004, bd. Ştefan cel Mare şi Sfânt, 168
Editura „Tehnica – UTM”
2045, Chişinău, str. Studenţilor, 9/9

56