Documente Academic
Documente Profesional
Documente Cultură
Library TUM
Reason: I attest to the
accuracy and integrity of
this document
UNIVERSITATEA TEHNICĂ A
MOLDOVEI
CICLU DE PRELEGERI
Chişinău
2019
0
UNIVERSITATEA TEHNICĂ A MOLDOVEI
CICLU DE PRELEGERI
Chişinău
Editura „Tehnica-UTM”
2019
1
CZU 004.4(075)
N 29
2
INTRODUCERE
7
Figura 1.1. Conceptul SDN
8
Figura 1.2. Structura stratificată SDN
9
MMFO MMFA
nivle
externe
Manage Orchestrare și Aplicații SDN SDN-AL
nivel management
m l i-ut
OSS aplicații AL
/BSS
ACI
Management
imnm nșaageet
MMFC
control CL control
Abstractizare
rOc hest
resurse
MMFR RCI
Manage Suport Suport control RL
ment management SDN-RL
nivel RL
resurse Procesare Transport
date date
10
MMFA
Orchestrare și Nivel
suport Aplicație SDN ... Aplicație SDN aplicații
management
...
SDN
AL
(SDN-AL)
ACI
12
MMFC ACI
Suport aplicații CL
Servicii CL
Orchestr- Servicii de bază Servicii specifice
are și
suport Nivelul de
manage- Abstractizareconrol resurse
ment CL SDN CL)
Repozitoriu Descoperire
(SDN-
de topologie resurse
RCI
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.
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
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.
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
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
24
Spre controlor
Protocolul OpenFlow
Interfață controlor
Tabelă de fluxuri
Nivel abstractizare
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
27
Controlor Controlor
OpenFlow PDUs:
OpenFlow/TLS/TCP/IP OpenFlow Switch
Datapath
Canal Canal
OpenFlow OpenFlow Tabelă Tabelă
de grup de grup
Fluxuri pachete Canal de Control Fluxuri pachete
Pipeline/Conductă
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).
31
2.2. Tabelul 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
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.
38
2.4. Tabelul de măsurare
Pachet in
Procesare de intrare
Procesare de ieșire
40
Găsiți înregistrarea Înregistrare flux TABELĂ de FLUXURI
flux cu cea mai înaltă
prioritate la potrivire Înregistrare flux Aplică instrucțiunile
Înregistrare flux
Potrivire
•
•
•
Î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}: Executare
- modifică pachetul,
-actualizează câmpurile de set de
acțiuni
Extrage potrivire,
Pachet câmpurile -actualizează câmpurile
antetului conductei,
-dacă spre ieșire sau grup
→ clone de pachet.
Pachete de clone
Ieșire
42
Intrare pachet
- set gol de acțiuni
- inițiere câmpuri pipeline
- start cu tabela de fluxuri 0
Da
Actualizare contoare.
Executare set Executare set acțiuni:
instrucțiuni: -actualizarea
-actualizarea setului de anteturilor pachetului
Este acțiuni Goto Nu -actualizarea
Da -actualizarea anteturilor tabela câmpurilor potrivire
potrivire în tabela n? -actualizarea
pachetului
n? -actualizarea câmpurilor câmpurilor pipeline
potrivire (conductă)
- actualizare câmpurilor
pipeline
Nu - dacă e necesar,
clonarea pachetului la Acțiune Da
ieșire grup?
Este Da înregistrare
„table- Nu
miss” ?
Nu Acțiune
Aruncare
ieșire?
pachet
Da
Nu
Aruncare
pachet Procesare intrare
Procesare ieșire
Nu Da
Packet out
Aruncare pachet
44
2.6.1. Mesaje controler-to-switch
46
2.6.3. Mesaje simetrice
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 */
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 */
/* 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 */
49
OFPT_GET_ASYNC_REQUEST = 26, /* Controller/switch
message */
OFPT_GET_ASYNC_REPLY = 27, /* Controller/switch
message
*/
OFPT_SET_ASYNC = 28, /* Controller/switch message */
/* Asynchronous messages. */
OFPT_TABLE_STATUS = 31, /* Async message */
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
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
55
REȚELE DEFINITE PRIN SOFTWARE
Ciclu de prelegeri
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