Digitally signed by

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

VIRTUALIZAREA FUNCȚIILOR DE REȚEA

Ciclu de prelegeri

Chişinău
2021
 UNIVERSITATEA TEHNICĂ A MOLDOVEI

FACULTATEA ELECTRONICĂ ŞI TELECOMUNICAŢII

DEPARTAMENTUL TELECOMUNICAŢII
ȘI SISTEME ELECTRONICE

VIRTUALIZAREA FUNCȚIILOR DE REȚEA

Ciclu de prelegeri

Chişinău
Editura „Tehnica-UTM”
2021
 CZU 004.7(075.8)
N 29

Prezenta lucrare se încadrează în tematica Tehnologii inovatoare de

rețea. Virtualizarea funcțiilor de rețea NFV de comun cu Rețelele definite
prin software SDN realizate prin practici de implementare în Cloud
conduc la transformări tehnologice semnificative în domeniul
telecomunicațiilor fixe și mobile. Tehnologia NFV se bazează pe
tehnologia de virtualizare standard și servere industriale.
Ciclul de prelegeri Virtualizarea funcțiilor de rețea 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 DIN RM

Nazaroi, Ion.
Virtualizarea funcțiilor de rețea: Ciclu de prelegeri/
Ion Nazaroi; Universitatea Tehnică a Moldovei,
Facultatea Electronică și Telecomunicații, Departamentul
Telecomunicații și Sisteme Electronice. – Chișinău:
Tehnica-UTM, 2021. – 96 p.: fig., tab.
Bibliogr.: p. 87-88 (19 tit.). – 50 ex.
ISBN 978-9975-45-674-6.
004.7(075.8)
N 29

ISBN978-9975-45-674-6 © UTM, 2021

 INTRODUCERE

Rețelele moderne de telecomunicații conțin o varietate din ce

în ce mai mare de echipamente proprietare. Lansarea de noi servicii
necesită deseori reconfigurarea rețelei și instalarea la fața locului a
echipamentelor noi. Acestea la rândul lor necesită spațiu
suplimentar, energie electrică și personal de întreținere instruit. Într-
o lume digitală, ciclurile de inovare se accelerează și necesită o mai
mare flexibilitate și dinamism decât le permit soluțiile bazate pe
hardware.
Volumul traficului de date în rețelele de telecomunicații este
într-o creștere fenomenală, în mare parte, cauzată de răspândirea
serviciilor OTT (over the top). Pentru a menține rentabilitatea
rețelei, operatorii implementează concepte de scalabilitate și
capacitate la cerere, deseori utilizând virtualizarea și cloud
computing.
Deci, sunt necesare medii configurabile dinamic și complet
automatizate, care permit rețelelor să fie agile și capabile să
răspundă automat la nevoile serviciilor și traficului care îl parcurg.
Ca rezultat, tehnologiile de virtualizare și cloud computing au
început să fie implementate în rețelele de telecomunicații sub forma
rețelelor definite prin software (SDN) și a virtualizării funcțiilor de
rețea (NFV). Cu NFV/SDN rețeaua devine programabilă și mai
agilă.
NFV este o abordare complementară a rețelei definite prin
software (SDN) pentru gestionarea rețelei. În timp ce ambele
gestionează rețelele, ele se bazează pe metode diferite. SDN separă
nivelul de control de cel al resurselor pentru a oferi o vedere
centralizată a rețelei, iar NFV se concentrează în principal pe
optimizarea serviciilor de rețea. NFV este o parte-cheie a cloud
computing-ului, dezvoltării 5G, rețelelor de centre de date (data
center networking), SD-WAN și multe altele.
Industria telecomunicațiilor se află la mijlocul unei
transformări semnificative condusă de cerințele aplicațiilor și

3
rețelelor 5G, realizată de tehnologii precum NFV/SDN și practici de
implementare native în cloud. Aceasta este probabil cea mai mare
transformare tehnologică și de afaceri a industriei de
telecomunicații de la consolidarea infrastructurilor de comunicații
mobile. Rețelele de telecomunicații în urma acestor transformări
vor deveni extrem de distribuite și complet definite de software,
funcționând în principal pe resurse cloud omogene [1].
Virtualizarea funcției de rețea NFV se bazează pe tehnologia
de virtualizare standard și servere industriale. Pentru comoditatea
cititorului, în primul capitol se propune o succintă recapitulare a
tipurilor și metodologiilor de virtualizare în tehnologia informației
(IT). Informațiile aduse corespund nivelului de cunoaștere minim
necesar pentru a înțelege noțiunile de bază ale tehnologiei NFV.
Descrierea principiilor de bază, arhitecturii și blocurilor
funcționale ale tehnologiei NFV sunt prezentate în capitolul doi.
Pentru a ilustra rolul fiecărei entități funcționale și a
interacțiunii dintre ele, în capitolul trei se examinează un exemplu
de implementare a NFV într-o rețea IMS.
Ultimul capitol se axează pe exemple de posibilă
implementare a tehnologiei rețelelor definite prin software SDN în
cadrul arhitectural NFV.
Lucrarea finalizează cu descrierea platformei CORD care
permite operatorilor de rețea să creeze servicii inovatoare.
Platforma Oficiu central reproiectat ca centru de date sau abreviat
CORD folosește tehnologiile SDN, NFV și Cloud pentru a construi
un centru de date agile pentru rețelele de frontieră. Exemplul
prezentat se referă la rețeaua de acces formată din CPE (Customer
premises equipment) la domiciliu și terminale de linie optică OLT
(optical line terminator ) GPON, Switch-ul de agregare și BNG
(Broadband Network Gateway) la oficiul central. Implementarea
presupune utilizarea doar a elementelor SW și HW open source.
Descrierea tehnologiei SDN și a platformei IMS pot fi găsite
în lucrările editate de autor anterior [13,15].

4
 1. VIRTUALIZAREA ÎN TEHNOLOGIA INFORMAȚIEI

Virtualizarea funcțiilor de rețea transformă modul în care sunt

construite și operate rețelele de telecomunicații. La baza acestei
transformări se află tehnologia de virtualizare standard și înlocuirea
diferitor tipuri de echipamente de rețea cu servere „standard
industriale”.
În cele ce urmează se propune o succintă recapitulare a
tehnologiilor, tipurilor și metodologiilor de virtualizare în IT.
Nivelul informațiilor aduse este relevant înțelegerii implementării
tehnologiei NFV.

1.1. Definiția virtualizării

Virtualizarea este procesul de rulare a instanței virtuale a
unui computer într-un strat abstractizat de hardware-ul real. Cel mai
frecvent, virtualizarea se referă la rularea simultană a mai multor
sisteme de operare pe un singur server fizic.
Serverul virtualizat se comportă ca un server fizic și este
denumit mașină virtuală (VM). O „mașină virtuală” nu are
comunicare directă cu hardware-ul real. Hardware-ul fizic „din
lumea reală” pe care rulează VM este denumit în general gazdă, iar
mașina virtuală emulată pe acea mașină este denumită în general
invitată. O gazdă poate emula mai mulți invitați, fiecare dintre
aceștia putând emula diferite sisteme de operare și platforme
hardware.
Pentru aplicațiile care rulează deasupra mașinii virtuale, ea
apare ca și cum ar fi propria mașină dedicată, unde sistemul de
operare, bibliotecile și alte programe sunt unice pentru sistemul
virtualizat invitat și neconectate la sistemul de operare gazdă
subiacent.
Există trei domenii largi de virtualizare:
a) virtualizarea serverului;
b) virtualizarea rețelei;
c) virtualizarea funcțiilor de rețea (NFV).

5
 a) Virtualizarea serverului este procesul de împărțire a unui
server fizic în mai multe servere virtuale unice și izolate prin
intermediul unei aplicații software. Fiecare server virtual poate rula
propriile sale sisteme de operare independent.
Software-ul de virtualizare a serverului permite mai multor
sisteme de operare să ruleze independent unul de celălalt pe o
singură mașină dintr-un centru de date. Software-ul de virtualizare
numit Hypervisor încapsulează o versiune invitată a sistemului de
operare și emulează resurse hardware. În acest fel, software-ul de
virtualizare folosește hypervizoare pentru a permite mai multe
instanțe de server să ruleze pe o singură mașină.
b) Virtualizarea rețelei este un concept confundat adesea cu
NFV. În realitate, ea a apărut înaintea NFV și are puțină relevanță
pentru acesta. Nu are o relație cu ideile de virtualizare care au fost
discutate până acum. Folosește cuvântul „virtual” într-un context
diferit de virtualizarea serverului. Virtualizarea rețelei este o
abordare în care o singură rețea fizică este împărțită logic în mai
multe rețele logice. Aceste rețele partajează infrastructura
subiacentă, dar pentru utilizatorul final această partajare nu este
vizibilă, iar protocoalele și tehnologiile utilizate fac ca aceste rețele
să pară complet independente și rețele separate care rulează pe o
infrastructură dedicată. Rețelele logice (sau rețelele virtuale așa
cum sunt adesea menționate) oferă izolare, confidențialitate și
segregare între rețele la nivel de rețea.
Cel mai relevant exemplu de virtualizare a rețelei este
utilizarea rețelei LAN virtuale (VLAN). Alte exemple de astfel de
tehnologii de rețea virtuală sunt rețeaua privată virtuală IP de
nivelul 3 (L3VPN), LAN extensibilă virtuală (VXLAN),
comutatorul ATM și circuitele virtuale permanente (SVC/PVC).
Fiecare dintre aceste tehnologii suprapune rețele virtuale pe o rețea
fizică.
Pentru furnizorii de servicii de internet (ISP) posibilitatea de
suprapunere a câtorva rețele prin partajarea infrastructurii face
posibilă oferirea de servicii fără implementarea rețelelor fizice

6
separate pentru fiecare dintre ele. Tehnicile de virtualizare a rețelei
permit rularea simultană a serviciilor, precum accesul la internet în
bandă largă, streaming video și voce peste IP ca rețele separate
logic într-o rețea fizică comună, ceea ce conduce la o economie
semnificativă a costurilor de implementare, gestionare și întreținere
a infrastructurii.
c) Virtualizarea funcțiilor de rețea (NFV) extinde ideea
virtualizării serverului la echipamentele cu funcții specifice în rețea.
Succesul virtualizării serverului a motivat operatorii de rețea să se
desprindă de la principiul „un dispozitiv, o funcție pe hardware
specializat” și să treacă la sisteme de operare din rețea care rulează
într-un mediu virtualizat. Cu NFV sistemul de operare este
virtualizat și rulează pe servere COTS, iar volumul de resurse de
calcul și stocare necesar poate fi ușor ajustat. Virtualizarea
funcțiilor de rețea utilizează o serie de instrumente dezvoltate
pentru virtualizarea serverului, relativ matură.

1.2. Tehnici de virtualizare

Virtualizarea oferă un mediu hardware virtual izolat pentru a
rula un sistem de operare sau o aplicație. Mediul rezultat este
denumit de obicei o mașină virtuală. Uneori acest mediu virtual
este denumit container (deoarece oferă un mediu autonom). Într-o
definiție mai strictă a acestor termeni, există o diferență subtilă între
mașini virtuale și containere. Ambele oferă medii virtualizate. Dar
modul în care sunt implementate trebuie să fie diferențiat, deoarece
are un impact asupra nivelului de izolare și performanță atins.
Mașinile virtuale au trei componente principale:
• sistem de operare-gazdă;
• manager de mașini virtuale (VMM sau hypervizorul);
• sistem de operare invitat.
Sistemul de operare-gazdă este sistemul de operare care
rulează direct pe hardware și are vizibilitatea întregului set de
resurse hardware disponibile pentru a fi alocate mașinilor virtuale.

7
Mașinile virtuale sunt create în interiorul sistemului de operare-
gazdă.
Pentru virtualizarea proceselor se utilizează aşa-numiţii
hypervisori. Hypervizorul este stratul de virtualizare în arhitectura
NFV. Un hypervizor permite crearea, alocarea resurselor,
modificarea parametrilor și ștergerea mașinii virtuale. Hypervisorii
sunt clasificați în două tipuri numite tip-1 și tip-2.

Aplicație Aplicație Aplicație

OS invitat OS invitat OS invitat

Hypervizor

Resurse Hardware

Figura 1.1. Hypervizor de tip 1

Hypervisor de tip 1 – sistem de operare compact care rulează

direct pe platforma hardware (server dedicat) fără a fi nevoie de un
sistem de operare subiacent (figura 1.1). Pe o singură platformă
hardware pot rula simultan mai multe sisteme de operare guest
(invitat/oaspete), mașini virtuale.
Fiecare sistem de operare invitat primește de la hypervizor o
iluzie de control deplin asupra tuturor resurselor „de nivel inferior”
ale computerului. Este similar cu modul în care sistemul de operare
rulează pe un hardware real. În același timp, aplicația are mult mai
puține capabilități pentru gestionarea resurselor de calcul.
Majoritatea procesoarelor actuale Intel și AMD pentru
desktopuri și servere acceptă tehnologia de virtualizare și împart

8
sistemul de operare în două niveluri de privilegii - modul kernel și
modul utilizator.
Exemple de hypervizoare de tip 1 sunt Xen, VMware ESXi,
Hyper-V și multe altele.
Deoarece rulează direct pe hardware, această implementare se
mai numește și implementare bare-metal (simplu-metal). Alte
denumiri sunt hypervizor X sau microkernel.

Aplicație Aplicație Aplicație

OS invitat OS invitat OS invitat

Hypervizor Hypervizor Hypervizor

Sistem de operare-gazdă

Resurse Hardware

Figura 1.2. Hypervizor de tip 2

Hypervizor de tip 2 rulează ca o aplicație software obișnuită

pe un sistem de operare-gazdă (figura 1.2). Sistemul de operare-
gazdă poate fi orice sistem de operare tradițional cu capacități de
virtualizare. Hypervizorul rulează ca o aplicație pe acest sistem de
operare împreună cu alte aplicații și procese și are resurse hardware
specifice alocate acestuia.
Într-un mediu virtualizat de tip 2, rolul gazdei este menit doar
să ofere o platformă pentru ca hypervizorul să ruleze și să ofere
interfața pentru comunicare cu dispozitivele, memoria, discurile și
alte periferice. În general, sistemul de operare-gazdă nu este destinat
să ruleze aplicații cu resurse mari.
9
 Cele mai populare hypervizoare de tip 2 sunt Oracle VM
VirtualBox, VMware Workstation, KVM.
Hypervizorul de tip 2 este mai ușor de dezvoltat, deoarece nu
există dependență de hardware. Tot din acest motiv suportă o
varietate mai largă de hardware.
Hypervizorul de tip 1, datorită interacțiunii directe cu
hardware-ul, este mai flexibil și mai sigur. El este mai ușor de
optimizat, deoarece codul lui este dezvoltat exclusiv pentru
funcționalitatea hypervizorului. Performanța acestui tip de
hypervizor este, în general, mai mare decât versiunile de tip 2,
deoarece dependența de comunicarea cu hardware-ul prin sistemul
de operare-gazdă este eliminată.
Sistem de operare invitat. Mașina virtuală, ca și orice alt
server, are nevoie de un sistem de operare pentru a porni, gestiona
dispozitivele și rula aplicațiile. Sistemul de operare care rulează pe
acest server virtual se numește sistem de operare invitat (OS
invitat). Acest sistem de operare poate fi de orice tip, dar trebuie să
fie compatibil cu resursele hardware oferite de hypervizor. De
exemplu, un sistem de operare bazat pe arhitectura RISC (Reduced
Instruction Set Computer) nu poate rula nativ pe un hypervizor care
oferă o arhitectură Intel x86, utilizând resurse CPU CISC (Complex
Instruction Set Computer).
Sistemul de operare invitat nu are vizibilitate asupra
adevăratelor resurse hardware sau a altei mașini virtuale care ar
putea fi prezentă de o altă instanță a hypervizorului.
Utilizatorul din sistemul de operare invitat poate rula orice
număr de aplicații acceptate de sistemul de operare respectiv. Când
aplicația dorește să acceseze resursele de disc, memorie sau CPU,
hypervizorul acționează ca intermediar. El transmite cererea către
resursele gestionate de sistemul de operare-gazdă. Răspunsul la
aceste solicitări este transmis înapoi către hypervizor de către
sistemul de operare-gazdă, apoi către sistemul de operare invitat
solicitant, creând impresia că sistemul de operare invitat comunica
direct cu acele entități hardware.

10
 Comunicarea în rețea. Mașinile virtuale sunt medii izolate și
au nevoie de conectivitate pentru a transmite date în afara serverului
fizic pe care sunt găzduite sau pentru comunicare între mașinile
virtuale găzduite pe același server. În acest scop este utilizată placa
sau controlerul de interfață de rețea NIC (Network Interface
Controller ) ale serverului fizic. Ca și în cazul altor resurse, cum ar
fi CPU și memorie, NIC-urile fizice sunt partajate între mașinile
virtuale. Pentru această partajare sunt folosite diverse tehnici. Una
dintre ele este bazată pe hypervizor care creează instanțe NIC
virtuale (vNIC) și le prezintă ca NIC-uri sistemului de operare
invitat. Hypervizorul (în cazul tipului 1) sau sistemul de operare-
gazdă (în cazul tipului 2) mapează multiple vNIC la NIC fizice.
Pentru a realiza conectivitatea vNIC la NIC fizic este utilizat un
switch virtual (vSwitch).

1.3. Containere și Docker

Container este un mediu virtual de execuție care rulează
deasupra unui singur nucleu (kernel) de sistem de operare (OS) și
emulează mai degrabă un sistem de operare decât hardware-ul de
bază. Containerul partajează nucleul sistemului de operare-gazdă cu
alte containere. Partea partajată a sistemului de operare este doar
pentru citire. Containerele pot rula aplicații independente fără
niciun sistem de operare invitat.
Virtualizarea bazată pe containere își are rădăcinile în evoluția
nucleelor UNIX/Linux. Datorită acestei relații strânse, uneori
containerele sunt numite containere Linux (LXC), deși nu toate
containerele sunt LXC.
Virtualizarea prin utilizarea containerului este diferită de o
mașină virtuală. Containerizarea nu creează o nouă mașină virtuală
în sistemul de operare-gazdă. Containerele izolează și definesc
restricții în ceea ce privește utilizarea resurselor sistemului. Din
acest motiv, containerele sunt adesea menționate ca un mediu
virtual pentru a le diferenția de mașinile virtuale. Totuși, termenii

11
mediu virtual, mașină virtuală și containere sunt destul de des
folosiți ca sinonime.
Containerele oferă virtualizare ușoară prin tehnica de
virtualizare a sistemului de operare. Pentru a realiza acest lucru, se
utilizează capabilități integrate în nucleul Linux, cum ar fi
namespace, cgroup, chroot, apparmor și altele. Două dintre aceste
capabilități de nucleu, izolarea spațiului de nume (namespace) și
grupul de control (cgroup), contribuie mai mult decât celelalte la
containerizare.
Izolarea spațiului de nume (namespace) a fost implementată
în nucleele Linux pentru a limita vizibilitatea anumitor resurse
utilizate de un proces și pentru a nu permite proceselor care folosesc
spații de nume separate să-și vadă reciproc resursele. Aplicația
utilizează propriul spațiu de nume și poate genera multe procese în
acest spațiu. Aceste procese și ID-uri de proces nu sunt vizibile
pentru alte aplicații care nu utilizează același spațiu de nume de
proces.
Una dintre condițiile prealabile pentru virtualizare este de a nu
restricționa utilizarea resurselor. De exemplu, spațiul de nume de
montare (mount) nu poate limita cantitatea maximă de spațiu pe disc
pe care un proces îl poate consuma. Alocarea resurselor este
realizată prin funcționalitatea grupului de control. Control-group
(cgroup) gestionează resursele kernel-ui Linux. Funcționalitatea
cgroup controlează resurse precum CPU, memorie, I/O de disc etc.
Astfel, capabilitățile kernel-ui cgroup și namespace se completează
reciproc. Cgroup impune restricțiile privind cantitatea de resurse
care poate fi utilizată de procese. Pe de altă parte, namespace
permite independența și vizualizarea separată a resurselor
sistemului la proces. LXC folosește combinația acestor două
(precum și alte caracteristici) pentru a implementa virtualizarea.
Care sunt diferențele importante dintre cele două metodologii
de virtualizare - container și mașină virtuală?
În cazul containerizării, nucleul sistemului de operare-gazdă
este partajat de toate containerele, iar virtualizarea are loc la nivel

12
de proces prin utilizarea funcțiilor nucleului (cum ar fi namespace,
cgroup).
Deoarece containerul folosește sistemul de operare-gazdă, nu
este necesar să ruleze un nou sistem de operare. Aceasta permite
containerelor să ruleze aplicații direct în interiorul OS-gazdă, spre
deosebire de o mașină virtuală, unde este necesar un sistem de
operare pentru ca o aplicație să poată fi rulată. Acest lucru
economisește resurse când aplicațiile care urmează a fi virtualizate
pot utiliza același nucleu, binare și biblioteci ca sistemul de operare-
gazdă. Partajarea kernel-ului OS, a programelor binare și a
bibliotecilor-gazdă economisește resurse, dar are unele dezavantaje
în comparație cu implementarea unei mașini virtuale.
O aplicație care are nevoie de un alt sistem de operare nu
poate fi introdusă într-un container de pe această gazdă. Mașinile
virtuale sunt mai flexibile și pot rula orice tip de aplicație și pe orice
sistem de operare invitat care necesită aceeași arhitectură hardware
ca și gazda. Din cauza partajării nucleului între containere, există o
posibilă vulnerabilitate în care comportamentul unui container îi
poate afecta pe ceilalți.
Aplicațiile care rulează într-un container pot fi aplicații
autonome sau un sistem de operare invitat. Pe baza aplicației,
containerele pot fi împărțite în două categorii:
• container OS;
• container de aplicare.
Containerul este denumit container de sistem de operare
(OS) dacă aplicația din container este un sistem de operare. La fel,
ca și în cazul mașinilor virtuale, acest sistem de operare se numește
OS invitat. Aplicațiile rulează apoi în cadrul acestui OS invitat. În
acest tip de containere, aplicația folosește bibliotecile și binare de
sistem din OS invitat ceea ce elimină dependența de bibliotecile și
binarele sistemului de operare-gazdă, asigură o mai bună izolare și
securitate pentru aplicația containerizată.
Containerele OS se aseamănă cu mașinile virtuale, dar în loc
de hypervizor folosește API pentru containere. Evident, sistemul de

13
operare invitat trebuie să fie compatibil cu nucleul gazdei, de
exemplu, un sistem de operare Windows nu poate rula pe un nucleu
Linux.
Containerele pentru aplicații sunt pur și simplu containere
care rulează direct aplicația. Aplicația folosește binarele și
bibliotecile din sistemul de operare-gazdă și același kernel, dar are
propriul spațiu de nume pentru rețea și punct de montare pe disc.
Containerele pentru aplicații pot rula la un moment dat un singur
serviciu.
Utilizarea containerelor de aplicații face posibilă izolarea
diferitelor servicii care rulează în sistemul de operare-gazdă. Se
creează astfel un grup de containere de aplicații, fiecare oferind un
serviciu. Această abordare a arhitecturii software a câștigat multă
popularitate în ultimii ani și este denumită microservicii.
Docker. Containerul este compus din fișiere de configurare,
fișiere pe disc care reprezintă spațiul său de nume, fișiere
executabile și biblioteci ale aplicației. Ca urmare, portarea unui
container nu este la fel de simplă ca mutarea doar a fișierului de
configurare și a aplicației binare. LXC nu oferă o modalitate de a
împacheta împreună fișierele și mediul container ca grup.
Replicarea și portarea unui container de la o gazdă la alta poate
necesita considerații speciale. Pentru înlăturarea acestor inconviențe
se utilizează așa-numitul docker.
Docker este o tehnologie open source dezvoltată pentru a
permite replicarea, ambalarea și portabilitatea containerelor.
Docker împachetează aplicațiile în containere - componente
executabile standardizate care combină codul sursă al aplicației cu
toate bibliotecile sistemului de operare (OS) și dependențele
necesare pentru a rula codul în orice mediu. Cu docker devine mai
ușor și mai sigur construirea, implementarea și gestionarea
containerelor.
Docker este un sistem de operare pentru containere.
Dezvoltatorii, utilizând setul de instrumente docker, construiesc,
implementează, rulează, actualizează și opresc containerele,

14
folosind comenzi simple și automatizări care economisesc munca.
Similar cu modul în care o mașină virtuală virtualizează (elimină
necesitatea de a gestiona direct) hardware-ul serverului,
containerele virtualizează sistemul de operare al unui server. Docker
este instalat pe fiecare server și oferă comenzi pentru a construi,
porni sau opri containere.
Software-ul care găzduiește containerele se numește Docker
Engine. Docker Engine este un software de conectivitate la
infrastructură care lansează și gestionează containere. Docker
Engine funcționează cu fișiere Docker Image. Fișierele de imagini
Docker împachetează împreună aplicația, toate binarele și
dependențele necesare ca o singură imagine care poate fi portată și
reprodusă.
Kubernetes. Kubernetes este un instrument de orchestrare a
containerelor dezvoltat și pus la dispoziție ca sursă deschisă de
Google. Scopul său este de a gestiona grupurile de containere. În
timp ce Docker gestionează ciclul de viață al containerului,
Kubernetes ajută la implementarea și plasarea containerului în
mașini virtuale noi sau existente.
În mod tradițional, platformele NFV erau limitate la
utilizarea tehnologiilor de virtualizare standard (de exemplu, Xen,
KVM, VMWare, Hyper-V etc.) care rulează OS invitați pe baza
unor sisteme de operare de uz general precum Windows, Linux sau
FreeBSD.
În ultimul timp, o serie de tehnologii de virtualizare ușoare
(lightweight virtualization technologies), inclusiv containere,
unikernel-uri (VM-uri specializate) și distribuții minimaliste ale
sistemelor de operare de uz general (minimalistic distributions of
general-purpose OSes), au apărut ca abordări de virtualizare care
pot fi utilizate la construirea unei platforme NFV [2].
Unikernels sunt în esență mașini virtuale cu o singură
aplicație bazate pe sisteme de operare minimaliste. Astfel de
sisteme de operare minimaliste au cheltuieli generale minime și au
spațiu cu o singură adresă (spațiu unicast) și programator

15
(scheduler) cooperativ (reducând astfel costurile de comutare ale
contextului).
Crearea unei distribuții minimaliste a unui sistem de operare
de uz general, cum ar fi Linux sau FreeBSD, implică două acțiuni:
(1) configurarea nucleului astfel încât să fie activate doar modulele
necesare (de exemplu, eliminate driverele străine); și (2) includerea
doar a bibliotecilor și aplicațiilor necesare la nivel de utilizator și
executarea doar a unei cantități minime de procese.
De exemplu, în [3] sunt descrise provocările construirii unei
astfel de platforme și se discută în ce măsură aceste tehnologii,
precum și VM-urile tradiționale, sunt capabile să le abordeze.

2. VIRTUALIZAREA FUNCȚIILOR DE REȚEA

2.1. Descrierea generală a NFV

Virtualizarea funcțiilor de rețea este rezultatul adaptării
modului virtualizării serverului la rețea.
În 2012, la Congresul Mondial SDN and OpenFlow World
Congress, un număr de principali operatori de telecomunicații din
lume, inclusiv AT&T, Deutsche Telekom, NTT Group, Orange,
Verizon, au inițiat un nou concept, numit virtualizarea funcțiilor de
rețea (NFV) în cadrul Institutului European de Standarde în
Telecomunicații (ETSI) [4].
Cerințele și standardele deschise care stau la baza NFV sunt
elaborate de grupul ISG (Industry Specification Group) al ETSI
(European Telecommunications Standards Institute). NFV ISG a
devenit gazda dezvoltării tehnologiei NFV și coordonează lucrările
de standardizare și implementare a NFV cu alte organizații de
standardizare și comunități open source.
Rezultatele activității grupului ETSI NFV sunt divizate în așa-
numitele Release-uri.
În Relegase-ul 1 ETSI NFV stabilește cadrul general al
tehnologiei și este preocupat de demonstrarea fezabilității
conceptelor și principiilor NFV. Următorul Release 2 oferă un set

16
de specificații detaliate care abordează aspectele virtualizării rețelei,
a cerințelor în ceea ce privește orchestrarea, gestionarea,
performanța, fiabilitatea și securitatea, precum și interfețele,
modelele de informații și date necesare. Obiectivul principal al
Release-ului 3 îl constituie integrarea procedurilor NFV cu practica
operațională, astfel încât infrastructurile și serviciile NFV să poată
fi încorporate în procesele industriale actuale și să ofere o cale de
migrare clară.
În ultimul, la momentul scrierii acestei lucrări, Release 4, sunt
abordate următoarele domenii tehnice:
• consolidarea aspectelor de infrastructură prin optimizarea
abstractizării infrastructurii NFV (NFVI), încorporând tehnologiile
ușoare de virtualizare (cu containere), pentru reducerea cuplării
funcțiilor la infrastructură;
• consolidarea automatizării NFV, prin îmbunătățirea
gestionării și orchestrării ciclului de viață, simplificarea gestionării
funcțiilor și serviciilor;
• optimizarea cadrului de management și orchestrare
(MANO);
• simplificarea spațiului de specificații NFV pentru a ușura
implementarea soluțiilor NFV, a procedurilor de certificare și
integrare a tehnologiei în rețea;
• întărirea securității orchestrării, funcțiilor și serviciilor NFV.
În modelul de rețea tradițional, fiecare funcție de rețea
necesită un echipament suplimentar, o componentă „fieră”.
Virtualizarea elimină dependența dintre o funcție de rețea (NF) și
hardware-ul acesteia prin crearea unui mediu de execuție
standardizat și a interfețelor de gestionare a funcțiilor de rețea
virtualizate (VNF). Acest lucru are ca rezultat partajarea hardware-
ului fizic de mai multe VNF-uri sub formă de mașini virtuale (VM).
Punerea în comun a hardware-ului facilitează partajarea masivă și
agilă a resurselor infrastructurii NFV (NFVI) de către VNF. Acest
fenomen este deja văzut în infrastructurile de cloud computing.
Realizând modele de servicii ca infrastructura ca serviciu (IaaS),

17
Platforma ca serviciu (PaaS) sau Software ca serviciu (SaaS),
proprietarul VNF nu deține neapărat infrastructura NFV necesară
pentru buna funcționare a VNF.
Tehnologiile de virtualizare și cloud permit ca funcțiile de
rețea convenționale să fie implementate flexibil sub formă de
software pe servere standard. Astfel, ideea principală a NFV este
decuplarea funcțiilor de rețea de la hardware și rularea acestora pe o
platformă software (figura 2.1).

Figura 2.1. Infrastructura rețelei tradiționale în comparație

cu cea virtualizată

Prin virtualizarea infrastructurii partajate NFV, reprezintă o

modalitate mai eficientă de livrare și gestionare a funcțiilor de rețea.
Virtualizarea funcțiilor de rețea oferă mai multe avantaje, printre
care:
• reducerea costurilor de echipamente și consumului de
energie prin adoptarea mai largă a serverelor standarde și partajarea
infrastructurii de calcul;
18
 • accelerarea introducerii pe piață a inovaților;
• utilizarea unei singure platforme pentru diferite aplicații și
partajarea resurselor între servicii și baze de clienți;
• scalarea rapidă a rețelei și serviciilor după necesitate.
Cu NFV, tehnologia de virtualizare IT standard este adaptată
pentru a consolida infrastructura de rețea eterogenă bazată pe
diferite tipuri de echipamente pe servere, switch-uri și stocare
standarde de volum mare din industrie. Aceasta implică
implementarea funcțiilor de rețea în software care rulează pe o
infrastructură omogenă, standard industrială. Acest software poate
fi introdus în diferite locații din rețea, după cum este necesar.
Utilizarea NFV simplifică implementarea serviciilor de rețea,
reduce costurile de implementare și operaționale, facilitează
automatizarea gestionării rețelei și încurajează inovația. Tehnologia
a devenit un element esențial al proiectării moderne a rețelei.
NFV este aplicabil oricărei funcții de procesare a pachetelor
de date în rețelele fixe și mobile. Exemple de funcții care pot fi
virtualizate:
• elemente de comutare: routers, BRAS, CG-NAT;
• noduri de rețea mobilă: HLR/HSS, SGSN, GGSN/PDN-
GW, RNC, Nod B;
• funcții conținute în routerele și set top box-urile rezidențiale;
• elemente de gateway de tunelare: gateway-uri VPN
IPSec/SSL;
• analiza traficului: măsurare DPI, QoE;
• asigurarea serviciului, monitorizarea SLA, testarea și
diagnosticarea;
• platforme și elemente NGN: IMS, SBC-uri;
• funcții convergente și pe larg utilizate în rețele: servere
AAA, control de politici și platforme de facturare;
• optimizare la nivel de aplicație: CDN-uri, servere cache,
echilibratoare de trafic, acceleratoare de aplicații;
• funcții de securitate: firewall-uri, scanere de viruși, sisteme
de detectare a intruziunilor, protecție împotriva spamului.

19
 În plus, odată cu apariția tehnologiei 5G, există un impuls
către dezvoltarea de noi servicii în timp real în domeniile plăților
mobile, realității augmentate, conducerii autonome și internetului
obiectelor (IoT).

2.2. Cadrul NFV la nivel înalt

Virtualizarea funcțiilor de rețea se bazează pe implementarea
NF ca entități software care rulează peste infrastructura NFV
(NFVI). Figura 2.2 ilustrează cadrul NFV la nivel înalt.
În cadrul virtualizării funcțiilor de rețea NFV la nivel înalt se
identifică trei domenii principale de lucru [5]:
• funcția de rețea virtualizată (Virtualised Network Function
VNF), ca implementare software a unei funcții de rețea care rulează
pe infrastructura NFVI;
• infrastructura NFVI (NFV Infrastructure NFVI) care include
diversitatea resurselor fizice și modul în care acestea pot fi
virtualizate;
• managementul și orchestrarea NFV (NFV Management and
Orchestration, MANO) care acoperă orchestrarea și gestionarea
ciclului de viață al resurselor fizice și software, sprijină virtualizarea
infrastructurii și gestionarea ciclului de viață al VNF-urilor.
Definițiile termenilor utilizați pentru entitățile conceptuale din
sfera ISG NFV sunt date de ETSI în recomandarea ETSI GR NFV
003 „Virtualizarea funcțiilor de rețea (NFV); Terminologia pentru
principalele concepte în VNF” [6].
Cadrul NFV permite construirea și gestionarea dinamică a
instanțelor VNF și a relațiilor dintre acestea cu privire la schimbul
de date, control, gestionare, dependențe și alte atribute.

20
 Funcții de rețea virtualizate (VNFs)

VNF VNF VNF VNF

Infrastructura NFV (NFVI) NFV

management
Calcul Stocare Rețea și
virtual virtuală virtuală orchestrare
(MANO)

Nivel de virtualizare

Calcul Stocare Rețea

Resurse Hardware

Figura 2.2. Cadrul NFV la nivel înalt

Există cel puțin următoarele relații între funcțiile de rețea

virtualizate VNF:
• cu graf de redirecționare (Forwarding Graph) VNF (VNF-
FG) care specifică conectivitatea între VNF-uri, de exemplu, un lanț
de VNF-uri pe calea către un server Web (firewall, NAT, balansator
de sarcină);
• ca set de VNF în care nu este specificată conectivitatea
dintre VNF, de exemplu un pool de servere Web, gateway-uri
rezidențiale virtualizate, independente.
Un serviciu de rețea cap-la-cap (end-to-end) cum ar fi accesul
la internet, rețea privată virtuală, poate fi descris de un graf de
redirecționare al funcțiilor de rețea (NF) interconectate și punctele
terminale.

21
 Figura 2.3 reprezintă un exemplu de graf de redicționare VNF
al unui serviciu de rețea end-to-end (E2E) cu diferite niveluri care
sunt implicate în procesul de virtualizare al acestor funcții. În acest
exemplu, serviciul de rețea end-to-end este compus din cinci VNF-
uri și două puncte finale. Decuplarea hardware-ului și software-ului
în virtualizarea funcțiilor de rețea se realizează printr-un nivelul de
virtualizare. Acest nivel abstractizează resursele hardware ale
infrastructurii NFV. Funcțiile de rețea virtualizate rulează deasupra
nivelului de virtualizare, care face parte din NFV.

Figura 2.3. Exemplu de graf de redirecționare VNF al unui

serviciu cap-la-cap (end-to-end)

În figura 2.3 este reflectat cazul unui VNF-FG imbricat (adică

VNF-FG-2) construit din alte funcții de rețea virtualizate (VNF-2A,
VNF-2B și VNF-2C). Obiectivul este ca interfețele dintre VNF-uri
și infrastructura dintr-un mediu multifurnizor să se bazeze pe
standarde acceptate de toți.
22
 VNF este o entitate abstractă definită de software, iar
instanța VNF este instanțarea în timp de execuție a VNF. Instanțele
funcțiilor de rețea virtualizate VNF pot fi implementate pe diferite
resurse fizice dispersate geografic, de exemplu resurse de calcul și
hypervizori, doar cu condiția respectării cerințelor de performanță
ale serviciilor end-to-end. În orice caz, instanțele VNF și
infrastructura de suport trebuie să fie vizibile în scopuri de
configurare, diagnostic și depanare, iar comportamentul serviciul de
rețea E2E virtualizat trebuie să fie echivalent cu cel non-virtualizat.

2.3. Arhitectura NFV

Cadrul arhitectural NFV este descris la nivel funcțional și se
concentrează pe modificările care pot apărea în rețeaua unui
operator în caz de virtualizare a funcțiilor rețelei și nu se axează pe
careva implementări specifice. Descrierea structurii arhitecturale ce
urmează se referă la noile blocuri funcționale și puncte de referință
aduse de virtualizarea rețelei.
Trebuie remarcat faptul că punctele de referință reprezintă
specificații ale informațiilor care ar trebui transmise prin ele,
precum și unde și cum ar trebui procesate. Pe scurt, un punct de
referință este un concept arhitectural care definește și expune o
vedere externă a unui bloc funcțional.
Arhitectura NFV include următoarele blocuri funcționale [5]:
 Funcția de rețea virtualizată (VNF).
 Element Management (EM).
 Infrastructura NFV, care include:
 resursele hardware și virtualizate;
 nivelul de virtualizare.
 Descrierea serviciului, VNF și a infrastructurii.
 Sisteme de suport operațiuni și afaceri (OSS/BSS).
 Manager(ii) infrastructurii virtualizate.
 Manager(ii) VNF.
 Orchestrator NFV.

23
 Os-Ma
OSS/BSS Orchestrator

Descrierea infrastructurii, Se-Ma

Or-Vnfm
VNF și a serviciului
Or-

VNF
EM 1 EM 2 EM 3 Ve-Vnfm
Manager(i)
Ve-Vnfm

VNF 1 VNF 2 VNF 3

Vn-Nf
Vi-Vnfm
NFVI
Or-Vi
Calcul Stocare Rețea
virtual virtuală virtuală
Manager(i)
Nf-Vi Infrastructură
virtualizată

Nivel de virtualizare
VI-Ha VI-Ha
Resurse hardware
Managemant și
Resursă Resurs Resursă
Orchestrare NFV
calcul stocare rețea
(MANO)

Puncte de referință:
de executare , principale NFV , alte

Figura 2.4. Cadrul arhitectural de referință al NFV

24
 Figura 2.4 reprezintă cadrul arhitectural NFV care include
blocurile funcționale nominalizate mai sus și punctele de referință.
Ultimele sunt clasificate în trei tipuri – de executare, principale și
alte.
Principalele puncte de referință și cele de executare sunt
prezentate prin linii continui și se află în sfera NFV. Acestea sunt
ținte potențiale pentru standardizare.
Punctele de referință punctate, denumite alte, sunt disponibile
în implementările actuale, dar ar putea avea nevoie de extensii
pentru gestionarea virtualizării funcției de rețea. Cu toate acestea,
punctele de referință punctate nu sunt în prezent principalul obiectiv
al NFV. În general, un punct de referință în arhitectură definește o
vedere externă pe care o expune un bloc funcțional al arhitecturii.
Un punct de referință este de obicei realizat ca o interfață standard
în design-ul sistemului.
Cadrul arhitectural prezentat se concentrează pe
funcționalitățile necesare pentru virtualizare, dar nu specifică ce
funcții de rețea ar trebui virtualizate, deoarece aceasta este doar o
decizie a proprietarului rețelei.
În ceea ce urmează sunt descrise mai detaliat blocurile
funcționale ale arhitecturii NFV.

2.3.1. Funcția de rețea virtualizată (VNF)

Funcția de rețea virtualizată VNF este o virtualizare a unei
funcții de rețea într-o rețea tradițională non-virtualizată.
Comportamentul funcțional și starea unei funcții de rețea sunt
indiferente dacă această funcție este virtualizată sau nu. Drept
exemple de funcții de rețea pot servi funcțiile realizate de SGW
(Serving Gateway), PGW (Packet Data Network Gateway), RGW
(Residential Gateway), serverul DHCP (Dynamic Host
Configuration Protocol), firewall-ul etc. VNF-urile pot fi legate
între ele ca blocuri de construcție într-un proces cunoscut sub
numele de lanț de servicii (service chaining). Deși conceptul nu este

25
nou, înlănțuirea serviciilor - și procesul de furnizare a aplicațiilor -
sunt simplificate și scurtate folosind VNF-uri.
Comportamentul funcțional și interfețele SWA (Software
Architecture) ale VNF cu alte funcții de rețea, managerul VNF, EM
și NFVI sunt bine definite.

EM

SWA-4

VNF
VNF
VNFC SWA-2 VNFC
SWA-1 aSW SWA-3 Manager
Ve-Vnfm-vnf
Vn-Nf Vn-Nf
SWA-5 SWA-5
NFVI

Figura 2.5. Vedere funcțională a VNF

Figura 2.5 reprezintă arhitectura internă a unui VNF și oferă

mai multe detalii despre entitățile și interfețele relevante [7].
Funcția de rețea virtualizată este capabilă să ruleze pe infrastructura
NFV (NFVI), fiind orchestrată de NFVO și managerul VNF.
VNF-urile sunt construite pentru diferite funcții de rețea, care
pot funcționa individual sau combinate. Un VNF poate fi compus
din una sau mai multe componente numite VNFC. VNFC este o
entitate software implementată într-un container de virtualizare
(figura 2.6). O funcție virtualizată VNF realizată de un set de VNFC
apare în exterior ca un singur sistem integrat. Aceeași VNF poate fi
implementă ca un VNFC monolitic, integrat vertical, sau folosind
VNFC separate, a câte unul pentru planul de control și planul de
date. Componentele VNFC ale unui VNF sunt conectate într-un
26
graf. Dacă VNF are o singură componentă VNFC, atunci graful de
conectivitate internă este numit nul.

VNF1 VNF 2
VNFC1
VNFC1
VNFC2 VNFC3

container de
virtualizare a) VNF cu o singură b) VNF cu multiple
componentă componente

Figura 2.6. Compoziție VNF

Modul în care un furnizor VNF pregătește un VNF dintr-un

set de VNFC depinde de mai mulți factori, așa ca performanța,
scalabilitatea, fiabilitatea, securitatea, integrarea componentelor de
la alți furnizori VNF, considerații operaționale, baza de cod
existentă etc. În general, nu există doi furnizori VNF care vor
structura un VNF din același VNFC-uri.
Instanțele VNFC (VNFCI) sunt elementele constitutive de
executare care alcătuiesc o instanță VNF. Pentru a instanția funcția
de rețea virtuală definită de un VNF, managerul VNF creează unul
sau mai multe VNFCI, unde fiecare VNFCI se află în propriul
container de virtualizare.
Există mai multe opțiuni pentru modul în care pot fi create
instanțele VNFC individuale, și anume:
• containere de virtualizare încărcate complet sau parțial;
• containere de virtualizare goale pregătite pentru folosire și
încărcare.
De exemplu, dacă este utilizată ultima opțiune, atunci fișierul
de încărcare a containerului de virtualizare este NULL. NFVO și
VNF Manager indică VIM să creeze un container de virtualizare gol
cu o interfață SWA-5 (Vn-Nf) asociată, care să fie gata de utilizare.

27
 Configurarea implementării și comportamentul operațional al
unei VNF sunt descrise de un șablon de specificații numit
descriptorul funcției de rețea virtualizată (VNFD). Configurarea
de implementare definește starea și mediul pentru un VNF care
urmează a fi implementat, pe când comportamentul operațional
definește funcțiile necesare pentru ca un VNF să fie operat și
gestionat corect. Fiecare VNF are exact un descriptor VNF asociat
(VNFD) care este utilizat în procesul implementării VNF și
gestionării ciclului de viață al unei instanțe VNF.
Deci, VNFD descrie cerințele de resurse virtuale ale unui
VNF. Acesta este utilizat de funcțiile de gestionare și orchestrare
NFV pentru a determina modul de executare a operațiilor ciclului de
viață VNF.
Figura 2.7 ilustrează un exemplu simplificat de descriptor
VNF (VNFD) și relația acestuia cu VNF. Exemplul din această
figură arată o instanță VNFI care este formată din 4 instanțe VNFCI
de 3 tipuri diferite: „A”, „B” și „C”. Fiecare tip VNFC are propriile
cerințe privind sistemul de operare (OS) și mediul de execuție (de
exemplu, mașina virtuală). Aceste resurse virtuale și cerințele lor de
interconectivitate sunt descrise în elementele modelului de date care
formează un VNFD. Pe lângă cerințele de resurse, un VNFD
conține referințe lipsite de ambiguitate la binare VNF, scripturi,
date de configurare etc., care sunt necesare pentru funcțiile de
gestionare și orchestrare NFV la configurarea corespunzătoare a
VNF.
Cerințele pentru resursele NFVI (de exemplu, cerințe de
conectivitate, lățime de bandă, latență etc.) nu sunt arătate în figura
2.7, dar sunt prezente în VNFD. VNFD poate specifica, de
asemenea, reguli de localizare (de exemplu, unele instanțe VNFC
trebuie să fie pe VM-urile furnizate pe resursele situate în același
rack).
Funcțiile de gestionare și orchestrare NFV iau în considerare
toate atributele VNFD pentru a verifica fezabilitatea instanțierii

28
unui VNF dat, de exemplu se verifică ce tip de resurse necesită
fiecare instanță VNFC.

Figura 2.7. Descriptorul VNFD și funcția VNF asociată

Cerințele de resurse NVFI pentru un VNF se pot referi la

puterea de procesare a CPU, volumul memoriei, latența
conectivității etc. Ele pot fi definite și ca „clasă de servicii” a
infrastructurii NFVI care îndeplinește acele caracteristici și mapează

29
o anumită categorie de VM-uri preconfigurate în domeniul
operatorului.
Ca orice produs, un VNF necesită dezvoltarea continuă a
noilor funcționalități și întreținerea celor existente. Modificările
introduse în timpul dezvoltării și întreținerii sunt adesea clasificate
în actualizări și upgrade-uri. Deși nu există o definiție formală a
unei actualizări (update) și a unui upgrade, la general ele se pot
distinge astfel:
• o actualizare (update) VNF nu introduce funcționalități noi
și interfețe noi;
• un upgrade VNF introduce noi funcționalități și noi
interfețe.
Diferența-cheie constă în faptul că upgrade-urile VNF
necesită planificare la nivelul serviciului de rețea, în timp ce
actualizările VNF pot fi implementate fără coordonare cu alte VNF
participante la același graf de redirecționare VNFFG.
O VNF poate presupune o serie de stări interne care reprezintă
statutul ei (tabelul 2.1). Tranzițiile dintre aceste stări oferă modele
arhitecturale pentru unele funcționalități VNF așteptate.

Tabelul 2.1. Stările instanței VNF

Stare Descriere
Nulă Instanța VNF nu există și este pe cale
să fie creată
Instanțiată neconfigurată Instanța VNF există, dar nu este
configurată pentru serviciu
Instanțiată configurată- Instanța VNF este configurată pentru
inactivă serviciu
Instanțiată configurată- Instanța VNF participă la serviciu
activă
Încheiată (terminată) Instanță VNF a încetat să mai existe

30
 Înainte ca un VNF să-și poată începe ciclul de viață, trebuie să
existe o condiție prealabilă ca VNF să fie încărcat (înregistrarea
VNF la NFVO și încărcarea datelor VNF (VNFD, imagini SW
etc.)). Se poate face o comparație cu ciclul de viață al unui
echipament fizic: se despachetează, se plasează într-o locație, se
alimentează, se conectează la rețea și trece prin diferite etape ale
configurațiilor. Procesul de instanțiere a unui VNF este echivalentul
despachetării, instalării și alimentării unui echipament de rețea.
Pașii de configurare sunt similari cu cei utilizați în dispozitivele
fizice după cum se arată în continuare:
1. La integrarea unui dispozitiv, virtual sau fizic, inițial este
necesară crearea unei adrese IP pentru gestionare (de exemplu,
atribuirea unei adrese prin DHCP). Pentru VNF, configurația este
specificată în VNFD și utilizată în procesul de creare a VM.
2. Înainte ca echipamentul să poată furniza orice funcție,
fiecăreia dintre interfețele sale de date trebuie să i se atribuie o
adresă, de nivelul L2 sau trei L3 (de exemplu, atribuirea adreselor
IP pentru toate interfețele unui router). Pentru instanțierea VNF,
configurația dată este, de asemenea, parte a procesului de creare a
VM.
3. Urmează configurarea de bază, după care dispozitivul de
rețea poate începe să își îndeplinească funcțiile.
Alte evenimente ale ciclului de viață includ scoaterea din
exploatare a VM, actualizarea software-ului pentru o VM,
recuperarea dintr-o stare de eșec sau mutarea unei VM într-o altă
locație. Toate evenimentele sunt gestionate de componenta NFV
MANO așa cum este descris în paragraful 2.4.
Evoluția în virtualizarea serverului are o influență directă
asupra modului în care sunt implementate VNF. De exemplu,
microserviciile cu containere sunt explorate ca o opțiune pentru a
31
optimiza în continuare eficiența implementării NFV, deoarece
timpul de reîncărcare și ștergere a containerelor este mult mai scurt.
Pe termen lung, această opțiune poate justifica o tendință spre
utilizarea containerelor în NFV, mai degrabă decât o mașină
virtuală.
În mod similar, unele îmbunătățiri sunt împinse în virtualizare
datorită utilizării sale de către NFV. De exemplu, interconectivitatea
VNF utilizează aceleași instrumente pe care le utilizează
virtualizarea pentru a interconecta mașinile virtuale sau
containerele. Acest lucru a determinat dezvoltarea unor switch-uri
virtuale mai eficiente, precum și tehnici optimizate de procesare a
pachetelor la nivel de nucleu și la nivelul cardului de interfață de
rețea (NIC), cum ar fi kitul de dezvoltare a planului de date (DPDK)
de la Intel.

2.3.2. Element Management (EM)

Elementul Management (EM) este un bloc funcțional definit
în cadrul ETSI menit să ajute la implementarea funcțiilor de
gestionare a unuia sau mai multor VNF-uri. Domeniul de aplicare al
EM este analog cu sistemul tradițional de gestionare a elementelor
(EMS). În rețeaua tradițională EMS este intermediară între sistemul
de gestionare a rețelei NMS (Network Management System) și
elementele fizice ale rețelei care îndeplinesc funcțiile de rețea. EM
comunică cu VNF, folosind protocoale specializate rămase din
rețeaua tradițională (proprietare), dar utilizează standarde deschise
definite de ETSI pentru a comunica cu VNFM. Deci, EM este un
intermediar pentru VNFM pentru operațiuni și gestionarea VNF-
urilor, așa cum se arată în figura 2.8. Funcțiile FCAPS (fault,
configuration, accounting, performance, and security) sunt

32
gestionate de VNFM, dar necesită sprijinul din partea EM pentru a
interacționa cu VNF pe marginea acestui aspect al managementului.

Managementul
FCAPS al VNF
prin intermediul
EM

VNF
EM #1 Manager(s)
(VNFM)
Metode proprietere
VNFM
pentru FCAPS
interacționeză
VNF #1 direct cu VNF
pentru FCAPS

Figura 2.8. Gestionarea VNF de către VNFM direct sau prin EM

Funcționalitatea de gestionare FCAPS include managementul

funcțiilor de rețea furnizate de VNF după cum urmează:
• gestionarea defecțiunilor;
• configurarea;
• facturarea utilizării;
• colectarea rezultatelor măsurării performanței;
• managementul securității.
Într-o rețea complet virtualizată, necesitatea în EM va
disparea, iar funcțiile FCAPS vor fi în întregime în responsabilitatea
VNFM.

2.3.3. Infrastructura NFV

Infrastructura NFV (NFVI) este totalitatea tuturor
componentelor hardware și software care creează mediul în care
sunt desfășurate, gestionate și executate VNF-urile. Infrastructura
33
NFV poate fi amplasată în mai multe locații (NFVI-PoP). Rețeaua
care interconectează aceste locații face parte din NFVI.
Pentru VNF, nivelul de virtualizare și resursele hardware arată
ca o singură entitate.
Hardware-ul include resursele de calcul, stocare și rețeaua
care asigură respectiv procesarea, stocarea și conectivitatea la VNF-
uri prin nivelul de virtualizare (hypervizor). Resursele de calcul și
stocare sunt colocate. Rețeaua este compusă din routere, switch-uri
și linkuri prin cablu sau wireless.
NFV diferențiază două tipuri de rețele:
 rețea NFVI-PoP care interconectează resursele de calcul și
stocare conținute într-un NFVI-PoP, dar include și echipamente de
comutare și rutare pentru conectivitate externă;
 rețea de transport care interconectează NFVI-PoP-urile, la
punctele de prezență NFVI-PoP ale altor rețele și la alte terminale
care nu sunt conținute în NFVI-PoP.
Nivelul de virtualizare și resursele virtualizate abstractizează
resursele hardware și decuplează software-ul VNF de hardware.
Nivelul de virtualizare efectuează:
 abstractizarea și împărțirea logică a resurselor fizice;
 utilizarea infrastructurii virtualizate subiacentă de către
VNF;
 furnizarea resurselor virtualizate către VNF.
De regulă, nivelul de virtualizare este realizat sub formă de
hypervizoare. Un hypervizor este un program software care
împarte resursele unei gazde hardware și creează mașini virtuale
(VM) izolate una de alta. Fiecărei VM i se atribuie CPU virtualizat
(vCPU), NIC virtualizat (vNIC) și dispozitiv de stocare virtualizat
(vStorage) create de hypervizor. După cum s-a subliniat în ETSI GS
NFV-INF 004 [8], în practică, o vCPU poate fi o partajare de timp a
34
unui CPU real sau în cazul CPU-urilor multicore, poate fi o alocare
a unuia sau mai multor nuclee pentru o VM. De asemenea, este
posibil ca hypervizorul să imită un set de instrucțiuni CPU care este
diferit de setul de instrucțiuni native CPU.
Software-ul de hypervizor rulează fie direct pe partea
superioară a hardware-ului (hypervizor de tip I), fie pe partea
superioară a unui sistem de operare de găzduire (hypervizor de tip
II).
Utilizarea hypervizorului este una dintre soluțiile tipice
actuale pentru implementarea VNF-urilor. Abordarea bazată pe
hypervizor nu pune nici o constrângere asupra tipului de sistem de
operare pe care îl utilizează componentele VNF (VNFC) ale unui
VNF. Alte soluții pentru realizarea VNF-urilor este virtualizarea
bazată pe containere, numită și virtualizarea la nivel de sistem de
operare (OS).
Figura 2.9 oferă o comparație la nivel înalt a arhitecturilor
software pentru soluțiile de hypervizor și de container OS. În cazul
hypervizorului, imaginea software a VNFC încărcată în containerul
de virtualizare include aplicația și kernelul OS invitat. În soluțiile de
container OS imaginea software a VNFC încărcată în containerul de
virtualizare include doar aplicația de rețea efectivă.
Tehnologia de virtualizare a OS permite contextul de execuție
parțial partajat pentru diferite containere. Un astfel de context de
execuție partajat este denumit frecvent pod (păstaie, modul) de
container. Un pod poate include sisteme de fișiere partajate,
interfețe de rețea partajate și alte resurse partajate ale OS care sunt
accesibile din fiecare container din acel modul.

35
 Aplicație Aplicație
VNFC imagine
OS kernel OS kernel
invitată invitată Aplicație Aplicație
OS OS
Hypervizor kernel kernel
invitată invitată
OS gazdă Hypervizor

Hardware Hardware

Hypervizor tip 2 Hypervizor tip1

VNFC imagine
Aplicație Aplicație

OS kernel gazdă partajat

Hardware

OS containere

Figura 2.9. Compararea soluțiilor hypervizor și OS containere

În plus, față de hypervizor mediul de execuție a OS container

oferă și servicii kernel [9].
Deoarece soluțiile de OS containere se bazează pe un design
destul de ușor în care toate instanțele VNFC au același OS kernel,
acestea sunt adesea considerate o alternativă la soluțiile de
hypervizor când este nevoie de implementarea mai multor instanțe

36
ale unei funcții de rețea (de exemplu, instanțe pe utilizator pentru un
gateway rezidențial virtual).
În timp ce virtualizarea bazată pe hypervizor oferă o
flexibilitate ridicată în migrarea instanțelor VNFC de la o gazdă de
calcul la alta. Tehnologiile de virtualizare OS containere are o serie
de limitări ale capacităților de migrare. Acest lucru este legat de
distribuția stărilor de execuție VNFC între spațiile utilizatorului și
ale kernel-ului și dificultățile în migrare a structurilor kernel-ului
specifice containerelor (de exemplu, descriptori de proces OS,
descriptori de fișiere).
Containerele sunt o tehnologie ușoară de virtualizare la nivel
de sistem de operare, care partajează kernel-ul gazdă. Containerele
nu abstractizează resursele hardware, spre deosebire de virtualizarea
bazată pe hypervizor. Astfel, pentru anumite scenarii containerele
pot funcționa mai bine în comparație cu mașinile virtuale bazate pe
hypervizori. În alte zone, containerele pot să nu asigure nivelul de
performanță sau să nu suporte tipul de utilizare. În general,
comparativ cu soluțiile bazate pe hypervizor, această abordare poate
rula mai multe instanțe VNFC pe aceeași gazdă fizică, reducând
astfel costurile infrastructurii.
Pentru a rezuma, este esențial înainte de a alege tehnologia de
virtualizare potrivită să se ia în considerare cerințele de abstractizare
și performanță ale sarcinilor de lucru VNF.
Hardware-ul de rețea este abstractizat și realizează căi
virtualizate de conectivitate între VM-urile unui VNF sau între
diferite VNF. Conectivitatea poate fi realizată pe mai multe tehnici,
de exemplu printr-o rețea locală virtuală (VLAN).

37
 Elementele principale ale NFVI sunt ilustrate în figura 2.10:
 CPU - procesorul generic care execută codul VNFC;
 NIC - controlerul interfeței de rețea asigură interconectarea
fizică cu infrastructura domeniu de rețea;
 HDD – depozitare, un spațiu de stocare la scară largă și
nevolatil. În implementarea practică, acestea includ discuri rotative
(HDD) și unități SSD.

NFVI

Figura 2.10. Infrastructura NFV

Arhitectura infrastructurii NFV (NFVI) este separată în trei

domenii, și anume, domeniul de calcul (inclusiv stocarea),
domeniul hypervizorului și domeniul rețelei de infrastructură [10].
Aceste domenii sunt în mare parte distincte atât la nivel funcțional,
38
cât și practic. Poziționarea generală a acestor domenii în cadrul
arhitectural de referință NFV este reprezentată în figura 2.11.

HD

IND
CD

Figura 2.11. Domenii NFVI:

HD - domeniul hypervizor; CD - domeniul de calcul (inclusiv stocarea);
IND - domeniul rețelei de infrastructură.

Aceste domenii sunt în mare măsură autonome din punct de

vedere al dotării și dezvoltării fiecărui domeniu. Totuși, limitele
dintre domenii nu sunt definite cu precizie și există o anumită
suprapunere funcțională între ele.
Rolul domeniului de calcul este de a furniza resurse de
calcul și stocare COTS, utilizate împreună cu un hypervizor necesar
pentru a găzdui componentele individuale ale VNF-urilor. Deci,
domeniul de calcul oferă o interfață cu domeniul infrastructurii de
39
rețea, dar nu asigură însăși conectivitatea la rețea. Prin utilizarea
echipamentelor pe scară largă ale industriei IT se asigură costuri
reduse la echipamente și consum redus de energie. Bazându-se pe
tehnici de virtualizare, devine posibil să se concentreze volumul de
lucru pe un număr mai mic de servere în timpul din afara orelor de
vârf (de exemplu, noaptea), astfel încât toate celelalte servere să
poată fi oprite sau puse într-un mod de salvare a energiei.
Virtualizarea funcției de rețea se bazează pe tehnologii
moderne, cum ar fi cele dezvoltate pentru cloud computing. La baza
acestor tehnologii cloud se află mecanisme de virtualizare:
virtualizarea hardware-ului prin intermediul hypervizoarelor,
precum și utilizarea switch-urilor Ethernet virtuale (vSwitch) pentru
conectarea traficului între mașinile virtuale și interfețele fizice.
Domeniul hypervizor mediază resursele domeniului
computerului către mașinile virtuale ale aplicațiilor software. În
esență, hypervizorul poate emula fiecare piesă a platformei
hardware chiar și un set complet de instrucțiuni CPU. Domeniul
hypervizor abstractizează resursele hardware din domeniul de
calcul. Domeniul hypervizor se suprapune cu domeniul rețelei de
infrastructură, deoarece poate include elemente software de
comutare virtuală (vSwitch) și router virtual (vRouter), precum și
resurse de rețea abstracte furnizate de domeniul de calcul, cum ar fi
controlere de interfață de rețea (NIC) și switch-uri încorporate
(embedded, eSwitch).
Dacă există câteva mașini virtuale care rulează pe aceeași
mașină-gazdă, este necesară interconectarea ditre ele. Pentru a
asigura conectivitatea între VM-uri și între fiecare VM și NIC-urile
reale hypervizorul oferă NIC-uri virtuale emulate pentru VM-uri și
un comutator Ethernet virtual (vSwitch).
Există o serie de caracteristici disponibile în hardware-ul
serverelor actuale care îmbunătățesc performanțele VM-urilor.
Acestea includ:
• procesoare multicore care acceptă mai multe fluxuri de
execuție paralele independente;

40
 • procesoare sistem pe cip care integrează mai multe nuclee,
interfețe DRAM, interfețe de rețea, interfețe de stocare și accelerare
hardware;
• instrucțiuni specifice CPU pentru a controla alocarea
memoriei și accesul direct pe dispozitivele I/O la alocările de
memorie VM;
• îmbunătățiri ale magistralei PCIe, în special SR-IOV (Single
Root-Input Output Virtualisation).
Acestea permit VM-urilor de înaltă performanță să ruleze
eficient ca și cum ar rula nativ pe hardware, fiind sub controlul
complet al hypervizorului.
Domeniul rețelei de infrastructură îndeplinește o serie de
roluri și oferă următoarele:
• canal de comunicare între VNFC-urile unui VNF distribuit;
• canal de comunicare între diferite VNF-uri;
• canal de comunicare între VNF-uri și elementele de
orchestrare și gestionare a acestora;
• canal de comunicare dintre componentele NFVI și
elementele de orchestrare și gestionare a acestora;
• mijloace de implementare la distanță a VNFC-urilor;
• resurse de interconectare cu rețeaua de transport existentă.
Serviciile de conectivitate de bază sunt găzduite de interfața
containerului de infrastructură în numele VNF-urilor. Rolul
infrastructurii este de a furniza un număr mare de instanțe de
servicii de conectivitate discrete. În general, este o cerință
fundamentală ca aceste servicii să fie separate între ele și să nu fie
interconectabile între ele. Aceasta este antiteza rețelei universale a
internetului sau a PSTN-lui.
În arhitectura NFV ESTI, blocul NFVI are nivelul de
virtualizare implementat printr-un hypervizor (dacă se utilizează
VNF ca mașini virtuale) sau LXC/Docker (când se utilizează
containere pentru VNF).

41
 2.3.4. Sistemul de suport operațiuni și afaceri (OSS/BSS)
Sistemul de suport operațiuni și afaceri OSS/BSS este o
entitate externă față de NFV care interacționează cu componente
funcționale din cadrul NFV-MANO. Funcțiile OSS/BSS în rețeaua
unui operator asigură gestionarea și orchestrarea sistemelor
moștenite cu vizibilitate completă a serviciilor furnizate.
NFV este o schimbare de paradigmă a modului în care rețelele
actuale sunt construite, operate și modului în care serviciile
furnizate sunt gestionate. Gestionarea rețelei adică adăugarea,
schimbarea și eliminarea resurselor devine dinamică. Pentru ca
NFV-MANO să ofere toate avantajele tehnologiei NFV, ea trebuie
să se integreze și să interacționeze cu entități de management
existente (OSS, BSS), utilizând interfețe oferite de acele entități și
oferind propriile interfețe pentru a fi utilizate de entități externe.
Pentru ca furnizorii de servicii să obțină întregul beneficiu al
NFV, o simplă extindere a modelelor OSS/BSS existente pentru
virtualizare nu va fi suficientă. Evoluția NFV-MANO și OSS/BSS
trebuie coordonată astfel, încât împreună să susțină următoarele:
• interfețe deschise, pentru a facilita automatizarea,
operațiunile de autoservire la nivel de servicii și produse;
• automatizare adaptivă în care funcțiile de management
analizează cerințe de resurse, permițând infrastructurii să furnizeze
resursele și serviciile necesare în acel moment;
• politici care ghidează deciziile necesare pentru a schimba tot
sau o parte a sistemului pentru a îndeplini o funcție dată;
• servicii personalizate care sunt configurate de către operator
sau utilizator pentru a se potrivi preferințelor și cerințelor
individuale ale clienților.
Gestionarea serviciilor end-to-end de către OSS/BSS necesită
convergența prezentării informațiilor de management atât din
sistemele de rețea moștenite, cât și din cele bazate pe NFV.
Un rol important îl are procesarea automatizată în timp real.
Gestionarea agilă a funcțiilor, aplicațiilor și serviciilor de rețea oferă
noi oportunități de venituri, reducând în același timp costurile.

42
Automatizarea poate fi susținută de o abordare aliniată între
OSS/BSS și funcționalitatea NFV-MANO bazată pe următoarelr:
• interfețe deschise și standardizate;
• modele comune de informații;
• mapări la diferite modele de date;
• capacitatea de analize de date în timp real.
Este necesară o abordare flexibilă și dinamică a
managementului bazată pe politici. O provocare-cheie în contextul
OSS/BSS și NFV este suportul procesării în timp real a unei
cantități uriașe de date de la mai multe surse de date (structurate,
semistructurate și nestructurate). Pentru a răspunde nevoii de
operare dinamică a managementului și orchestrării NFV, arhitectura
de management trebuie să sprijine integrarea în timp de execuție a
funcțiilor și proceselor de management. Acest lucru este diferit de
integrarea statică de astăzi, deoarece implică faptul că interfețele
trebuie să fie adaptive pentru a sprijini agilitatea proceselor.
Această abordare adaptivă permite în continuare o evoluție
constantă a sistemelor vechi existente pentru a se integra cu NFV.

2.4. Cadrul arhitectural de management și orchestrare

NFV-MANO
Cadrul arhitectural NFV-MANO se concentrează pe noile
blocuri funcționale aduse de NFV și punctele de referință dintre ele
(figura 2.12). Fiecare dintre blocurile funcționale are un set bine
definit de responsabilități și operează pe entități bine definite,
utilizând serviciile oferite de alte blocuri funcționale.
Cadrul arhitectural NFV-MANO identifică următoarele
blocuri funcționale [11]:
• managerul infrastructurii virtualizate (VIM);
• manager VNF (VNFM);
• orchestrator NFV (NFVO).
Cadrul arhitectural NFV-MANO identifică și următoarele
depozite de date:

43
 • Catalog NS;
• Catalog VNF;
• Depozit de instanțe NFV;
• Depozit de resurse NFVI.

Os-Ma-nfvo
OSS/BSS Orchestrator NFV (NFVO)

Catalog Catalog Instanțe Resurse

NS VNF NFV NFVI

Or-Vnfm
Ve-Vnfm-em
EM Manager VNF (VNFM)

Ve-Vnfm-vnf Vi-Vnfm
VNF
Vn-Nf Nf-Vi Or-Vi
Managerul infrastructurii virtualizate
NFVI
(VIM)

NFV - MANO

Figura 2.12. Cadrul arhitectural NFV-MANO cu puncte de referință

Cadrul arhitectural NFV-MANO definește punctele de

referință pentru a identifica comunicarea care trebuie să aibă loc
între blocurile funcționale. Identificarea și definirea acestor puncte
este importantă pentru a se asigura că fluxul de informații este
consistent în implementările furnizorilor blocurilor funcționale. De
asemenea, ele ajută la stabilirea unui mod deschis și comun de
schimb de informații între blocurile funcționale.

44
 Lista care urmează descrie aceste puncte de referință mai
detaliat.
Os-Ma-nfvo: definește comunicarea dintre OSS/BSS și
NFVO și este singurul punct de referință dintre aceste entități. Este
utilizat pentru descrierea serviciului și gestionarea pachetelor VNF,
interogarea serviciului de rețea și a instanțelor VNF din OSS/BSS,
transmiterea evenimentelor și informațiilor despre utilizarea și
performanța instanțelor serviciului de rețea la OSS/BSS.
Ve-Vnfm-vnf: definește comunicarea dintre VNFM și VNF.
Este utilizat de VNFM pentru gestionarea ciclului de viață VNF și a
schimbului de informații de configurare și stare cu VNF.
Ve-Vnfm-em: definește comunicarea dintre blocurile
funcționale VNFM și EM. Suportă gestionarea ciclului de viață
VNF, gestionarea defecțiunilor și a configurației.
Nf-Vi: definește schimbul de informații dintre VIM și
blocurile funcționale din NFVI. VIM îl folosește pentru a aloca, a
gestiona și a controla resursele NFVI.
Or-Vnfm: definește comunicarea dintre NFVO și VNFM,
cum ar fi instanțierea VNF și alte fluxuri de informații legate de
ciclul de viață VNF.
Or-Vi: orchestratorul NFV (NFVO) este definit pentru a avea
un mod direct de comunicare cu VIM pentru a influența gestionarea
resurselor infrastructurii, cum ar fi rezervarea resurselor pentru
VM-uri sau adăugarea de software VNF.
Vi-Vnfm: definește standardele pentru schimbul de informații
între VIM și VNFM, cum ar fi cererea de actualizare a resurselor
pentru VM care rulează un VNF.
Vn-Nf: este singurul punct de referință care nu include nici un
bloc funcțional de managament. Acest punct de referință este
destinat să comunice cerințele de performanță și portabilitate ale
VNF către blocul de infrastructură.

45
 2.4.1. Managerul(ii) infrastructurii virtualizate
Managerul infrastructurii virtualizate (VIM) efectuează
controlul și gestionarea resurselor de calcul, stocare și rețea NFVI,
aflate sub autoritatea sa, precum și virtualizarea acestora. Un VIM
poate fi specializat în gestionarea unui anumit tip de resursă NFVI
(de exemplu, numai pentru calcul, numai pentru stocare, numai
pentru rețea) sau poate fi capabil să gestioneze mai multe tipuri de
resurse NFVI.
Conform listei de resurse hardware specificate în arhitectură,
managerul infrastructurii virtualizate efectuează:
 Managementul resurselor responsabil de următoarele:
 Inventarierea de software (hypervizoare), resurse de calcul,
stocare și rețea dedicate infrastructurii NFV. VIM menține depozite
pentru imagini software, pentru a simplifica alocarea resurselor de
calcul virtualizate.
 Gestionarea imaginilor software (adăugarea, ștergerea,
actualizarea, interogarea, copierea) așa cum este solicitat de alte
blocuri funcționale NFV-MAN (de exemplu, NFVO).
 Alocarea mijloacelor de virtualizare, de exemplu, VM-uri
pe hypervizoare, resurse de calcul, stocare și conectivitate de rețea
relevantă. VIM păstrează un inventar alocării resurselor virtuale
resurselor fizice.
 Gestionarea și alocarea resurselor infrastructurii, de
exemplu, majorarea resurselor alocate VM-urilor, creșterea
eficienții energetice și recuperarea resurselor.

 Operațiuni pentru următoarele:

 Vizibilitatea și gestionarea infrastructurii NFV.
 Sprijinirea gestionării grafurilor de redirecționare VNF
(creare, actualizare, ștergere), prin crearea și întreținerea de legături
virtuale, rețele, subrețele și porturi virtuale. Gestionarea politicilor
de securitate pentru a asigura controlul accesului la rețea.
 Colectarea informațiilor despre performanță și erori ale
resurselor hardware (calcul, stocare și rețea), resurselor software

46
(hypervizoare) și resurselor virtualizate (VM). Analiza cauzelor
fundamentale ale problemelor de performanță din perspectiva
infrastructurii NFV.
 Colectarea informațiilor privind defectele de infrastructură.
 Colectarea de informațiilor pentru planificarea capacității,
monitorizare și optimizare.

2.4.2. Managerul VNF (VNFM)

Managerul VNF este responsabil pentru gestionarea ciclului
de viață al instanțelor VNF, inclusiv operațiuni precum:
• instanțierea VNF, inclusiv configurația VNF de șablonul
(template) de implementare VNF;
• verificarea fezabilității instanțierii VNF, dacă este necesar;
• scalarea VNF (creșterea sau reducerea capacității VNF);
• actualizarea sau upgradarea VNF (suport software VNF sau
modificări de configurație de diversă complexitate);
• colectarea rezultatelor măsurării performanței NFVI și
informațiilor despre defecțiuni legate de instanța VNF;
• gestionarea integrității instanței VNF pe parcursul ciclului
său de viață;
• terminarea VNF (eliberarea resurselor NFVI asociate VNF
și returnarea lor în grupul de resurse NFVI).
Unui manager VNF i se poate atribui gestionarea unei sau mai
multor instanțe VNF, de același sau diferite tipuri. Este posibilă
implementarea câtorva manageri VNF.
VNFM are acces la depozitul de pachete VNF (VNF Package)
disponibile, reprezentate prin descriptorii VNFD asociați. Depozitul
este menținut de NFVO sau de o altă entitate externă.
Majoritatea funcțiilor managerului VNF sunt funcții generice
aplicabile oricărui tip de VNF. Cu toate acestea, cadrul arhitectural
NFV-MANO susține și cazurile în care instanțele VNF au
funcționalități specifice pentru gestionarea ciclului lor de viață. O
astfel de funcționalitate deosebită este specificată în pachetul VNF.

47
 2.4.3. Orchestratorul NFV (NFVO)
Orchestratorul NFV este responsabil de orchestrarea și
gestionarea infrastructurii și resurselor software NFV și de
realizarea serviciilor de rețea pe NFVI.
Orchestratorul NFV are două responsabilități principale:
1) orchestrarea resurselor NFVI pe mai multe VIM-uri
(Virtualised Infrastructure Manager);
2) gestionarea ciclului de viață al serviciilor de rețea,
îndeplinind funcțiile de orchestrare a serviciilor de rețea.
Mai detaliat:
1) Funcția orchestrarea resurselor NFVI accesează resursele
într-un mod abstract, independent de orice VIM și guvernează
instanțele VNF care partajează resursele infrastructurii NFVI.
Următoarea listă exprimă setul neexhaustiv de funcționalități
efectuate de funcția orchestrarea resurselor NFVI:
• validarea și autorizarea solicitărilor de resurse NFVI de la
managerul (managerii) VNF, deoarece acestea pot avea impact
asupra modului în care resursele solicitate sunt alocate pe unul sau
mai multe puncte de prezență NFVI-PoP. Acordarea resurselor
solicitate este guvernată de politici și poate necesita rezervare
prealabilă;
• gestionarea resurselor NFVI, inclusiv distribuirea,
rezervarea și alocarea lor către instanțele de serviciu de rețea și
instanțele VNF, utilizând un depozit de resurse NFVI. Localizarea
și accesarea unuia sau mai multor VIM-uri și furnizarea locației
VIM corespunzător către VNFM;
• managementul relației dintre instanțele VNF și resursele
NFVI alocate acelor instanțe VNF prin utilizarea depozitului de
resurse NFVI și a informațiilor primite de la VIM;
• gestionarea și aplicarea politicilor pentru instanțele
serviciului de rețea și instanțele VNF. De exemplu, controlul
accesului, rezervarea și alocarea resurselor NFVI, optimizarea
plasării pe baza regulilor de afinitate (affinity)* sau antiafinitate
(anti-affinity) etc.;

48
 *) NOTĂ. Afinitate - politică persistentă care forțează linkurile
virtuale (VL) să partajeze aceeași conectivitate fizică.
Antiafinitate - politică persistentă care obligă linkurile virtuale
(VL) să nu partajeze nici o conectivitate fizică.
„Persistent” este utilizat aici pentru a indica faptul că afinitatea
sau antiafinitatea rămâne în vigoare până când consumatorul nu
solicitată o schimbare.

• colectarea informațiilor de utilizare a resurselor NFVI de

către instanțele VNF, de exemplu, informațiilor despre cantitatea de
resurse NFVI consumate prin interfețele NFVI și corelarea lor cu
instanțele VNF.

2) Orchestrarea serviciului de rețea de către NFVO include

funcții precum:
• încărcarea (Onboarding)* serviciul de rețea, adică
înregistrarea serviciu de rețea în catalog și asigurarea că toate
șabloanele care descriu NS sunt încărcate;

*) NOTĂ. Onboarding - etapă a ciclului de viață al unei funcții de

rețea virtuală (VNF) sau a unui serviciu de rețea (NS) care definește și
înregistrează VNF sau NS în catalog.

• instanțierea serviciului de rețea și gestionarea ciclului de

viață al ei (adică crearea serviciului de rețea folosind artefactele NS
încorporate), actualizarea, interogarea, scalarea, colectarea
rezultatelor măsurării performanței, corelarea evenimentelor,
terminarea;
• scalarea serviciul de rețea, adică creșterea sau reducerea
capacității serviciului de rețea;
• validarea și autorizarea solicitărilor de resurse NFVI din
partea managerilor VNF, deoarece acestea pot avea impact asupra
serviciilor de rețea. Acordarea operațiunii solicitate trebuie să fie
guvernată de politici;

49
 • actualizarea serviciului de rețea prin modificarea
configurației serviciului de rețea, cum ar fi schimbarea conectivității
inter-VNF sau a instanțelor VNF constitutive;
• crearea, ștergerea, interogarea și actualizarea VNFFG-urilor
asociate unui serviciu de rețea;
• încheierea serviciului de rețea, adică încetarea instanțelor
VNF constitutive, eliberarea resurselor NFVI asociate NS-urilor și
returnarea în grupul de resurse NFVI, dacă este cazul.

2.4.4. Exemplu de gestionare a unui serviciu cap la cap

Pentru a ajuta la înțelegerea modului în care blocurile
funcționale MANO interacționează colectiv se va examina un
exemplul de serviciu de rețea simplu.

Figura 2.13. Exemplu de gestionare a unui serviciu cap la cap

de blocurile funcționale ale MANO
50
 Figura 2.13 reprezintă o versiune simplificată de gestionare a
procesului de implementare a serviciului E2E.
Următorii pași descriu acest proces:
• Pasul 1. Vizualizarea completă a topologiei end-of-end este
vizibilă pentru NFVO.
• Pasul 2. NFVO instanțiază VNF-urile necesare și le
comunică VNFM.
• Pasul 3. VNFM determină numărul de VM-uri necesare,
precum și resursele de care fiecare dintre acestea va avea nevoie și
revine la NFVO cu această cerință pentru a putea îndeplini crearea
VNF.
• Pasul 4. Deoarece NFVO are informații despre resursele
hardware, acesta validează dacă există suficiente resurse disponibile
pentru ca VM-urile să fie create. NFVO trebuie acum să inițieze o
cerere pentru a crea aceste VM-uri.
• Pasul 5. NFVO trimite solicitarea către VIM pentru a crea
VM-urile și pentru a aloca resursele necesare acelor VM-uri.
• Pasul 6. VIM solicită nivelului de virtualizare să creeze
aceste VM-uri.
• Pasul 7. Imediat ce VM-urile sunt create cu succes, VIM
comunică acest lucru înapoi la NFVO.
• Pasul 8. NFVO notifică VNFM că VM-urile de care are
nevoie sunt disponibile pentru a aduce VNF-urile.
• Pasul 9. VNFM configurează acum VNF-urile cu parametrii
specifici.
• Pasul 10. După configurarea cu succes a VNF-urilor, VNFM
comunică către NFVO că VNF-urile sunt gata, configurate și
disponibile pentru utilizare.

2.4.5. Descrierea infrastructurii, VNF și a serviciului

(repozitorii NFV)
Repozitoriile NFV conțin seturi de date care oferă informații
cu privire la șablonul de implementare VNF, graful de

51
redirecționare VNF, informații legate de servicii și modele de
informații privind infrastructura NFV. Aceste șabloane/descriptori
sunt utilizați intern în cadrul managementului și orchestrării NFV.
Blocurile funcționale NFV Management and Orchestration
(MANO) gestionează informațiile conținute în șabloane/descriptori
și pot expune (subseturi de) astfel de informații blocurilor
funcționale aplicabile, după necesitate.
Deci, repozitoriile NFV conțin elemente de informații
utilizate la gestionarea și orchestrarea NFV. Acest paragraf descrie
elementele de informații relevante pentru îmbarcarea și gestionarea
ciclului de viață al VNF și NS.
Serviciul de rețea descrie relația dintre VNF și, eventual, PNF
(Physical Network Functions) și linkurile necesare pentru
conectarea VNF-urilor implementate în rețeaua NFVI. Link-urile
sunt utilizate pentru interconectarea VNF-urile la PNF-uri și
punctele finale.
Se utilizează mai multe categorii de informații:
• informații care se află în descriptori. Acestea sunt șabloane
de implementare (deployment templates) care conțin informații
relativ statice utilizate în procesul de îmbarcare VNF și NS;
• informații care se află în înregistrări. Acestea conțin date de
rulare relativ dinamice, reprezentând instanțe VNF sau NS. Aceste
date sunt menținute pe tot parcursul vieții instanței;
• informații care pot fi transmise între blocurile funcționale la
aceste interfețe.
Informația este structurată în elemente de informații. Un
element de informații conține informații specifice. Poate conține o
singură valoare, dar poate conține și alte elemente de informații.
Prin urmare, elementele de informații pot construi o structură
arbore, specificând separarea acestor elemente.
Elementul de informații poate fi clasificat în trei tipuri
diferite: file (leafs), elemente de referință și sub elemente care
sunt practic un element în sine. Fiecare dintre aceste elemente de

52
informații are un nume unic de-a lungul întregii căi din arbore care
duce la acel element din rădăcina arborelui.
O filă este un singur element de informații care specifică o
valoare. Tipul de date al valorii depinde de informațiile pe care ar
trebui să le transporte.
Elementul de referință este un element de informații care
poartă o referință la un alt element de informații. Acest lucru poate
fi reprezentat de un URI, dar depinde de implementarea concretă a
modelului informațional.
Sub element este un element de informații în sine care
specifică un alt nivel în arbore.
După cum s-a explicat mai sus, fiecare dintre aceste elemente
are un nume unic între ramurile unui arbore. Numele elementului
este reprezentat ca parte a anteturilor clauzelor de mai jos. Clauzele
în sine conțin tabele cu patru coloane. Prima coloană conține
numele elementului de informații, a doua indică tipul său. A treia
coloană oferă cardinalitatea elementului de informații. Dacă
cardinalitatea este un număr întreg pozitiv x, atunci elementul apare
exact de x ori. A patra coloană descrie serviciul. Pentru ilustrare
este adus un fragment de tabel ce descrie serviciul de rețea NSD
(tabelul 2.2).
Tabelul 2.2. Elemente de bază NSD
Cardi-
Nume Tip nalita- Descriere
te
Id Filă 1 ID-ul descriptorului serviciiului
de rețea
vendor Filă 1 Furnizor al serviciului de rețea
vld Referință 0 ... N Legătură virtuală care face
parte din serviciul de rețea
connection Element 1 ...N Acest element descrie un punct
_point de conexiune care acționează ca
punct final al serviciului de
rețea
53
 Pentru a descrie un serviciu de rețea și componentele sale sunt
introduse elemente de informații care reprezintă aceste componente.
Există patru elemente de informații definite în afară de elementul de
informație de serviciu de rețea (NS) de nivel superior:
• element de informații despre funcția de rețea virtualizată
(VNF);
• element de informații despre funcția de rețea fizică (PNF);
• element de informație Link Virtual (VL);
• element de informație VNF Forwarding Graph (VNFFG).
Elementele de informații NS, VNF și PNF includ descrieri ale
punctelor de conexiune.
Elementele de informații pot fi utilizate în două contexte
diferite: ca descriptori într-un context de catalog sau ca
înregistrări de instanță într-un context de execuție.
Descriptorul de servicii de rețea (NSD) este un șablon de
implementare pentru un serviciu de rețea care face referire la toți
ceilalți descriptori ce descriu componentele care fac parte din acel
serviciu de rețea.
Descriptorul VNF (VNFD) este un șablon de implementare
care descrie un VNF în ceea ce privește cerințele sale de
implementare și comportament operațional. VNFD este utilizat în
principal de VNFM în procesul de instanțare VNF și gestionare a
ciclului de viață al unei instanțe VNF. Informațiile furnizate în
VNFD sunt, de asemenea, utilizate de NFVO pentru a gestiona și a
orchestra serviciile de rețea și resursele virtualizate pe NFVI.
VNFD conține cerințe de conectivitate, interfață și KPIs care pot fi
utilizate de blocurile funcționale NFV-MANO pentru a stabili
linkuri virtuale adecvate în cadrul NFVI între instanțele sale VNFC
sau între o instanță VNF și interfața punctului final cu celelalte
funcții de rețea.
Descriptorul grafului de redirecționare (VNFFGD - VNF
Forwarding Graph Descriptor) este un șablon de implementare care
descrie o topologie a serviciului de rețea sau o porțiune a serviciului

54
de rețea, făcând referință la VNF și PNF și la linkurile virtuale care
le conectează.
Descriptorul de link virtual (VLD) este un șablon de
implementare care descrie cerințele de resurse necesare pentru o
legătură între VNF-uri, PNF-uri și puncte finale ale serviciului de
rețea, care pot fi îndeplinite prin diferite opțiuni de linkuri
disponibili în NFVI. NFVO poate selecta o opțiune după
consultarea VNFFG pentru a determina NFVI adecvat care trebuie
utilizat pe baza unor necesități funcționale.
Descriptorul de funcții de rețea fizică (PNFD) descrie
cerințele de conectivitate, interfață și KPIs ale linkurilor virtuale
către o funcție de rețea fizică atașată. Acest lucru este necesar dacă
un dispozitiv fizic este încorporat într-un serviciu de rețea pentru a
facilita evoluția rețelei.
NFVO încorporează toți descriptorii:
 NSD, VNFFGD și VLD într-un catalog NS;
 VNFD este integrat într-un catalog VNF ca parte a unui
pachet VNF.
După cele explicate mai sus se poate defini succint fiecare tip
de repozitoriu reprezentat în figura 2.12.
Catalogul NS reprezintă depozitul tuturor serviciilor de rețea
integrate, susținând crearea și gestionarea șabloanelor de
implementare NS (Network Service Descriptor (NSD), Virtual Link
Descriptor (VLD) și VNF Forwarding Graph Descriptor
(VNFFGD)) prin intermediul operațiunilor de interfață expuse de
NFVO.
Catalogul VNF reprezintă depozitul tuturor pachetelor VNF
încorporate, susținând crearea și gestionarea pachetului VNF
(descriptori VNF, imagini software, fișiere manifest etc.) prin
operații de interfață expuse de NFVO. Atât NFVO, cât și VNFM,
pot interoga catalogul VNF pentru găsirea și recuperarea unui
VNFD pentru a sprijini diferite operațiuni (de exemplu, validarea
sau verificarea fezabilității instanțierii).

55
 Depozitul de instanțe NFV conține informații despre toate
instanțele VNF și instanțele serviciului de rețea. Fiecare instanță
VNF este reprezentată de o înregistrare VNF, iar fiecare instanță NS
este reprezentată de o înregistrare NS. Aceste înregistrări sunt
actualizate pe parcursul ciclului de viață al instanțelor respective,
reflectând modificările rezultate din executarea operațiunilor de
gestionare a ciclului de viață NS și a operațiunilor de gestionare a
ciclului de viață VNF. Aceasta susține responsabilitățile NFVO și
VNFM în menținerea integrității și vizibilității instanțelor NS,
respectiv a instanțelor VNF, și a relației dintre acestea.
Depozitul de resurse NFVI conține informații despre
resursele NFVI disponibile, rezervate și alocate, astfel cum sunt
abstractizate de VIM în toate domeniile de infrastructură.
Informațiile sunt utilizate în scopul rezervării, alocării și
monitorizării resurselor. Depozitul de resurse NFVI joacă un rol
important în susținerea orchestrării și guvernării resurselor de
NFVO.

3. EXEMPLU VIRTUALIZARE MRF IMS

În infrastructurile de rețea „toate IP” există o mulțime de

elemente de rețea descompuse din categoria de funcții de rețea de
tip „gateway”. Un model de descompunere bine cunoscut este
separarea nivelului de control de cel de comutație și transport
utilizat de protocolul H.248.1 [12]. Clauza B.1 din [7] oferă un
astfel de exemplu cu domeniul de aplicare al funcției de rețea
„server media”.
Exemplu dat ce referă la descrierea cazului de virtualizare a
funcției resurse multimedia MRF a NGN IMS [§ 2.5 din 13]
instanțiată ca o funcție de rețea virtualizată VNF. Virtualizarea
MRF este deosebit de relevantă, deoarece face parte din subsistemul
multimedia IP (IMS) și listată ca una dintre funcțiile de rețea care
urmează a fi virtualizate în mod prioritar. Concomitent, acest

56
exemplu ilustrează cazul în care MRF-P și MRF-C au nevoie de
resurse diferite.

3.1. Descrierea funcției MRF supusă virtualizării

Funcția resurse multimedia MRF (Multimedia Resource
Function) este definită de 3GPP ca o funcție de resurse multimedia
compusă din două elemente standardizate: controler MRFC și
procesor MRFP (figura 3.1). Acestea oferă împreună mecanisme
pentru serviciile legate de media, cum ar fi conferințe, anunțuri
multimedia sau transcodarea. Controlerul MRFC comunică cu
procesorul MRFP prin interfața Mp, utilizând protocolul H.248.1.

Rf/Ro

Ut Charging
AS
Sh
Functions
Dh
ISC/Ma
UPSF Rf/Ro Iw
Cx Dx SLF IWF
Ib
Network
Attachment Mw Mx
Subsystem I/S-CSCF Ic
Mx IBCF
« Core IMS » Mi Mk
Mr
BGCF
e2
Mw

Other IP Networks
MRB
Mj
Mx Mg
P-CSCF MGCF
MRFC Ie

Gq' Gq'
SGF
PSTN/ISDN

Mn
Gm RACS MRF Mp RACS

MRFP T-MGF
C-BGF I-BGF
UE
Transport Processing Functions (Access and Core)

Figura 3.1. Reprezentarea MRFC și MRFP în NGN IMS

În Release-ul 8 al 3GPP a fost introdus și brokerul MRB

(Media Resource Broker). Mai multe detalii despre MRB și relațiile
dintre MRF și alte componente IMS pot fi găsite în ETSI TS 123
218 [14]. Pe extern brokerul MRB este conectat cu MRFC, funcția
57
de control a sesiunii de apel - servire (S-CSCF) și serverul de
aplicații (AS).
În cele ce urmează este luată în considerare utilizarea IMS
MRF (cu MRFC și MRFP) și MRB.

3.2. Instanțierea IMS MRF într-un mediu virtualizat

Figura 3.2 descrie cele 4 subfuncții principale ale acestei
instanțari IMS MRF.

Figura 3.2. Instanțierea IMS MRF într-un mediu virtualizat

1) MRF-C reprezintă funcția de control a MRF. Controlorul

MRF-C comunică prin semnalizările protocolului SIP cu S-CSCF și
controlează procesorul MRF-P prin protocolul H.248. Sarcinile
entității funcționale MRF-C sunt următoarele:
 controlul resurselor fluxului media din MRF-P;
 interpretarea informațiilor provenite de la un AS și S-
CSCF (de exemplu, a identificatorului sesiunii) și controlul
corespunzător al MRF-P;
 generarea CDR-urilor (Call Detail Record).
2) MRF-P reprezintă funcția de procesare multimedia a MRF
sub controlul MRF-C. Procesorul MRF-P efectuează toate
manipulările necesare pentru susținerea conferințelor multimedia,
furnizarea de anunțuri multimedia, implementarea capabilităților
IVR (Interactive Voice Response).
3) Load Balancer sau MRB (Media Resource Broker) are
drept scop echilibrarea încărcării sesiunii SIP către mai multe
instanțe MRF-C.
58
 4) Managerul de elemente MRF este responsabil de
următoarele:
• configurarea subfuncțiilor;
• gestionarea interacțiunilor dintre aceste subfuncții;
• solicitarea și colectarea valorilor din sistemul extern. În
corespundere cu adresările parvenite se efectuează calculul
numărului de încercări de apel pe secundă per instanță MRFC,
calculul timpului până la sesiunea SIP stabilită, calculul timpului de
preluare a resurselor audio/video etc.;
• implementarea elasticității (potrivirea în timp util a cererii și
ofertei) și solicitarea resurselor care să fie alocate pe infrastructura
virtualizată. Adăugarea sau eliminarea resursei la o mașină virtuală
VM cum ar fi vCPU sau vRAM. Adăugarea sau eliminarea instanței
VM unei instanțe MRF-C/MRF-P.
Maparea MRF-C și MRF-P se efectuează pe două VNFC-uri
diferite, dar pot fi grupate și într-un singur VNFC.
Figura 3.3 reprezintă un MRF virtualizat care cuprinde cele 4
subfuncții identificate mai sus.

Figura 3.3. Interacțiunea MRF cu OSS/BSS, management

și orchestrare NFV și infrastructură NFV

59
 Se observă că, ca orice alt VNF, MRF virtualizat
interacționează cu alte elemente ale arhitecturii NFV, cum ar fi
Managementul și orchestrarea NFV, Infrastructura NFV, OSS/BSS
și sistemele existente.
O instanțiere MRF virtualizată necesită interfețe atât cu
platforma de Management și Orchestrare, cât și cu infrastructura
virtualizată.

3.3. Cerințele privind managementul și orchestrarea

O instanțiere MRF virtualizată necesită interacțiunea cu
managementul și orchestrarea de-a lungul ciclului său de viață
pentru:
• planificarea MRF virtualizat;
• implementarea MRF virtualizat;
• gestionarea MRF virtualizat pe durata rulării:
- MRF în timp real (live) necesită valori ale SLA definite
în prealabil cu mediul de gestionare și orchestrare care să fie
transmise către funcția de rețea (sau către EM a funcției de rețea);
- MRF în timp real necesită, de asemenea, o anumită
gestionare a scalabilității;
- ar putea fi necesare upgrade-uri, implementarea unei noi
imagini sau versiuni noi;
• ștergerea unei instanțe MRF. Această solicitare necesită să
fie transmisă către management și orchestrare pentru a elimina
instanța VNFC dată sau o instanță VNF întreagă, cu sau fără
Element Management.

3.4. Cerințele privind infrastructura

Cerințele privind infrastructura sunt următoarele:
• alocarea de resurse mașinilor virtuale ale VNF care include:
- alocarea procesorului virtual și a memoriei RAM virtuale
garantate și negarantate;

60
 - alocarea resurselor rețelei IP, cum ar fi subrețele IP,
VLAN-urile și setul de adrese IP ce corespund cerințelor privind
lățimea de bandă și QoS (pierderea de pachete, Jitter, latență);
- capacitate de stocare virtuală care se potrivește cu lățimea
de bandă de citire/scriere I/O prognozată;
• definirea grupului de VM-uri împreună cu regulile lor de
afinitate și antiafinitate;
• modificarea politicii de alocare pentru scenariul scale-in și
scale-out;
• setarea unui set de sonde ale indicatorilor-cheie de
performanță cu praguri corespunzătoare pentru fiecare mașină
virtuală alocată. Această cerința este necesară pentru a informa
VNF (sau VNF EM) în caz de lipsă de resurse;
• oferirea capacității de operațiuni pe VM, cum ar fi migrarea
în timp real a unei VM de la o resursă HW pe alta, oprirea VM și
ștergerea instanței VM.
În ceea ce privește cerințele față de OSS/BSS și sistemele
moștenite, instanțierea MRF virtualizată necesită doar o interfață cu
aceste sisteme existente.
În continuare se expune un caz ilustrativ al mapării
subfuncțiilor de mai sus la VNF și VNFC. Pentru fiecare VNF
identificată, este definit un descriptor VNF (VNFD) cu informații
descrise în termeni funcționali împărțiți în informații de
implementare și operaționale, care abordează ciclul de viață al VNF.

3.5. Virtualizarea funcțiilor resurse media

3.5.1. Virtualizarea MRB
MRB se mapează ca un VNF separat și se implementează
singur, deoarece este posibil ca MRB și MRF să provină de la
diferiți furnizori de VNF. La implementare MRB utilizează modelul
de redundanță Active/Standby. În caz de eșec al MRB VNF activ,
acesta este detectat de cel în așteptare și ultimul trece în activ.
Pentru disponibilitate sunt necesare două mașini virtuale VM (2
instanțe). Numărul de vCPU și vRAM necesare este indicat de

61
descriptorul VNF. Pentru a spori disponibilitatea generală a soluției
se recomandă implementarea a două instanțe pe două VM-uri
situate pe resurse hardware fizice diferite. Se cere o conexiune de
rețea sigură între instanțele MRB. Rețea IP disponibilă cu cel puțin
0,9999, maximum un Ping pierdut în caz de eșec al rețelei, cota
pachetelor pierdute mai mică de 0,5%, întârziere dus-întors mai
mică de 120 ms, întârziere de jitter mai mică de 40 ms.
Din punct de vedere operațional să se asigure suport pentru
procesele tipice în sprijinul tranzițiilor de stare VNF: instanțiere,
configurare, pornire, oprire și terminare.

3.5.2. Virtualizarea MRF

Alegerea tipică este gruparea logică a MRF-C și MRF-P
împreună pe aceeași VM. Presupunând că o componentă VNFC
trebuie să corespundă cu o VM, atunci MRF-C și MRF-P sunt
combinate într-o singură componentă VNFC numită MRF-C+P.

MRF

MRF-
C+P

MRF
Stocare

Figura 3.4. Imaginea MRF VNF

62
 MRF-C are nevoie de o anumită stocare externă (de tip
RDBMS sau SAN) cu propriul model de redundanță. Reprezentarea
MRF VNF este ilustrată în figura 3.4.

Cerințe de implementare privind MRF-C+P

Funcția MRF-C+P se implementează utilizând modelul de
redundanță activă N + 1. Număr VM de la 2 până la 16 instanțe.
Limita maximă este de 32, dar 16 este o limită superioară practică.
Descriptorul VNF va indica numărul de vCPU și vRAM necesare.
Pentru fiabilitate se implementează cel puțin 2 instanțe VNFC pe 2
VM-uri situate pe resurse hardware fizice diferite.
MRF-P procesează probe multimedia periodic la fiecare 10
ms. Virtualizare presupune trecerea procesării digitale a semnalului
de la HW specializată la DSP (Digital Signal Processor) software,
cu capacitate de procesare dependentă de infrastructura virtualizată
subiacentă.

Cerințe de implementare privind stocarea MRF

Funcția de stocare MRF este implementată utilizând un model
de redundanță master/slave cu un VNFC master și unul sau mai
multe slave. Numărul VM două sau mai multe instanțe.
Descriptorul VNF va indica numărul de CPU și memoria necesară.
Pentru fiabilitate instanțele master și slave se implementează pe
diferite VM-uri situate pe resurse hardware fizice diferite.
Regula de afinitate cere gruparea VNFC-urile MRF-C+P și
VNFC-urile MRF de stocare împreună pe același hardware ce
asigură performanțe mai bune și limitează impactul în caz de eșec.
MRF are o relație internă (MRF-C+P ↔ MRF Stocare) și
două externe (MRF-C+P ↔ MRB) și (MRF-C+P ↔ Server de
aplicații). Pentru toate aceste relații, cerința de conexiune de rețea
bună trebuie să respecte caracteristici similare ca cele pentru relații
MRB (rețea IP disponibilă cu cel puțin 0,9999, maximum un Ping
pierdut în caz de eșec al rețelei, cota pachetelor pierdute mai mică

63
de 0,5%, întârziere dus-întors mai mică de 120 ms, întârziere de
jitter mai mică de 40 ms).

3.6. Îmbarcarea și desfășurarea serviciului IMS MRF

Îmbarcarea și desfășurarea serviciului IMS MRF utilizează
VNF-urile MRB și MRF împreună cu graful de redirecționare
format din 2 VNF, MRB și MRF (figura 3.5).

Figura 3.5. Funcțiile de rețea virtualizate IMS MRF VNF

și graful de redirecționare

Înainte de trecerea la descrierea îmbarcării IMS MRF e utilă

totalizarea celor descrise în etapele anterioare.
IMS MRF VNF va utiliza 3 resurse HW și 7 VM-uri:
Resursa HW # 1 cu 3 VM-uri:
• VM-1 pentru o instanțiere a MRB (MRB-1) utilizată ca
activă;
• VM-2 pentru o instanțiere a MRF-C+P (MRF-1);
• VM-3 pentru o instanțiere a MRF Storage (MRF Storage-1)
folosită ca master.
64
 Resursa HW # 2 conține și ea 3 VM-uri:
• VM-4 pentru o instanțiere a MRB (MRB-2) utilizată ca
standby;
• VM-5 pentru o instanțiere a MRF-C+P (MRF-2);
• VM-6 pentru o instanțiere a stocării MRF (MRF Storage-2),
utilizată ca sclav.
Resursa HW # 3 conține o singură VM (VM-7) cu o
instanțiere a MRF-C+P (MRF-3).
MRB, MRF-C+P și MRF Storage au 3 modele de redundanță
diferite (Activ/Standby pentru MRB, N + 1 pentru MRF-C+P și
Master/Slaves pentru MRF Storage) ce influențează direct asupra
NFVO.
Conform regulii de afinitate, MRB, MRF-C+P și MRF
Storage sunt colocalizate pe aceleași resurse hardware.
Conform regulilor de antiafinitate, MRB primar și secundar
sunt situate pe resurse hardware diferite. Același lucru este valabil
și pentru stocarea MRF primară și secundară.
Condițiile preliminare pentru îmbarcare sunt:
• codul pentru ambele funcții virtualizate VNF (MRB, MRF)
cu descriptorii VNFD corespunzători;
• IMS MRF VNF Forwarding Graph cu descriptorul
corespunzător VNF Forwarding Graph Descriptor (VNFFGD);
• imagini VM* pentru diferitele componente (MRB, MRF-
C+P, MRF Storage).

*) NOTĂ. O imagine a mașinii virtuale este un șablon care

conține o configurație software pentru crearea de noi instanțe. Imaginile
pot fi sisteme de operare simple sau pot avea software instalate pe ele,
cum ar fi baze de date, servere de aplicații sau alte aplicații.

Scopul principal al celor ce urmează este descrierea

orchestrării și gestionării funcției IMS MRF, utilizând NFVO și
NFVI ca principali actori ai îmbărcării și desfășurării serviciului
respectiv.

65
 Procesul general de îmbarcare IMS MRF VNF cu graful de
redirecționare este prezentat în figura 3.6.
Acest scenariu de îmbarcare presupune că s-au realizat toate
configurările de rețea necesare ca premisă (de exemplu, VLAN cu
QoS adecvat, găuri în firewall deschise, multicast/IGMP activat).
Succesiunea generală a îmbarcării este următoarea:
1) NFVO primește o cerere de îmbarcare MRB VNF cu
descriptorul MRB VNFD atașat.
2) NFVO validează conținutul MRB VNFD și, dacă este
valid, îl stochează în catalogul său VNF.

MRB
VNFD
NFVO

1- Îmbarcare MRB 2- Validare MRB VNFD și

stocare în catalogul VNF

MRF Catalog
VNFD VNF

3 – Îmbarcare MRF 4- Validare MRF VNFD și

stocare în catalogul VNF

IMS MRF Catalog

VNFFGD VNF

5 – Îmbarcare IMS MRF 6-Validare IMS MRF VNFFGD

și stocare în catalogul NS

7 – Returnare eroare Catalog

NS

Figura 3.6. Îmbarcarea IMS MRF VNF Forwarding Graph

66
 3) NFVO primește o cerere de îmbarcare MRF VNF cu MRF
VNFD atașat.
4) NFVO validează conținutul MRF VNFD și, dacă este valid,
îl stochează în catalogul său VNF.
5) NFVO primește o cerere de îmbarcare a grafului de
redirecționare IMS MRF VNF cu IMS MRF VNFFGD atașat.
6) NFVO validează conținutul IMS MRF VNFFGD. Aceasta
verifică dacă MRB și MRF VNFD sunt prezenți în catalogul VNF,
deoarece aceștia sunt menționați de IMS MRF VNFFGD. Dacă IMS
MRF VNFFGD este valid, NFVO îl stochează în catalogul său NS.
7) Dacă există o eroare, eroarea se returnează către apelant.
În final, cei doi descriptori VNFD (MRB, MRF) și
descriptorul IMS MRF VNF Forwarding Graph sunt acum
îmbarcați și disponibili pentru NFVO.

3.7. Provizionarea și configurarea instanței IMS MRF

Concomitent cu comanda pentru provizionarea (pregătirea)
grafului de redirecționare IMS MRF VNF orchestratorul NFVO
primește și datele de definire a instanțierii care conțin toate
informațiile de instanțiere necesare:
• numărul de MRB provizionate (2 în acest caz de utilizare);
• numărul de perechi MRF-C+P implementate (3 în acest caz
de utilizare);
• numărul MRF de stocare implementate (2 în acest caz);
• adresa IP pentru componenta externă S-CSCF;
• adresa IP pentru componenta externă a serverului de
aplicații.
Secvențierea generală a implementării este următoarea (figura
3.7):
1) NFVO primește cererea de „provizionare IMS MRF” cu
datele instanțierii definite mai sus.

67
 2) NFVO verifică dacă IMS MRF VNF Forwarding Graph
este îmbarcat și descriptorul respectiv este prezent în catalogul NS,
precum și prezența MRB VNFD și MRF VNFD în catalogul VNF.
3) NFVO verifică validitatea datelor de instanțiere furnizate
față de VNFD-urile catalogate pentru MRB și MRF și IMS MRF
VNFFGD.

1- Provizionarea IMS MRF

NFVO
2-Verifică îmbarcarea
IMS MRF VNFFG,
Date Catalog MRB VNF și MRF VNF.
Instanțiere NS
3-Validează datele de
instanțiere față de datele
catalogate VNFD și
Catalog
VNF VNFFGD

4- Verifică regulile de
afinitate și anti-afinitate
pentru a determina
locația instanțelor

5- Verifică
disponibilitatea
6- Returnare eroare resurselor identificate

Figura 3.7. Implementarea IMS MRF - pașii inițiali

4) NFVO aplică regulile de afinitate și antiafinitate pentru

fiecare VNF și VDU (Virtualisation Deployment Unit) pentru a
determina locația instanțelor. În urma validării trebuie să fie
confirmată necesitatea a 7 VM-uri pe 3 resurse HW diferite, așa

68
cum a fost descris anterior. Caracteristicile necesare pentru fiecare
VM sunt furnizate de informațiile din VNFD.
5) NFVO validează disponibilitatea îndeplinirii cererii de
către resursele identificate în etapa anterioară.
6) Dacă există o eroare, ea se returnează către apelant.

3.8. Implementarea IMS MRF pentru resursa HW 1

Fazele de implementare a funcției IMS MRF sunt prezentate
pentru hardware #1 (figura 3.8). Pentru HW#2 și HW#3 etapele
sunt similare. Numerotarea pașilor este în continuarea celor din
paragraful precedent.

NFVO 7-Creare server NFVI

(MRB-1,VM-1,...) 8- 8-Creare VM-1
VM-1
Răspuns VM-1 info Răspuns VM-1 info

9-Creare server
(MRF-1, VM-2,...)
10- Creare VM-2
Răspuns VM-2 info
VM-2
Răspuns VM-2 info

11-Creare server
(MRF Storage-1,
VM-3,...)
12- Creare VM-3 VM-3
Răspuns VM-3 info
Răspuns VM-3 info

Figura 3.8. Pași de implementare IMS MRF pentru resursa HW 1

69
 7) NFVO trimite o comandă de creare server către
infrastructura NFV pentru a crea VM-1, unde va fi găzduită
instanța MRB-1 cu informațiile provenite de la MRB VNF.
8) NFVI trimite la rândul său o cerere către hypervizor pentru
a crea VM-1, folosind imaginea furnizată. NFVI returnează
informația despre VM creată la NFVO.
9) NFVO trimite o comandă de creare server către NFVI
pentru a crea VM-2, unde va fi găzduită instanța MRF-1 cu
informațiile provenite de la MRF VNF.
10) NFVI trimite la rândul său o cerere către hypervizor
pentru a crea VM-2, folosind imaginea furnizată. NFVI returnează
informația despre VM creată la NFVO.
11) NFVO trimite o comandă de creare server către NFVI
pentru a crea VM-3, unde va fi găzduită instanța MRF Storage-1 cu
informațiile provenite de la MRF VNF.
12) NFVI trimite la rândul său o cerere către hypervizor
pentru a crea VM-3, folosind imaginea furnizată. NFVI returnează
informația despre VM creată la NFVO.
13) Dacă există o eroare, ea se returnează către apelant.
14) Pașii de la 7 la 13 se repetă pentru a doua resursă HW#2
pentru a crea:
a) VM-4 ce găzduiește MRB-2 (rol: standby);
b) VM-5 ce găzduiește MRF-2, (rol: activ);
c) VM-6 ce găzduiește MRF Storage 2 (rol: slave).
15) Pașii 8 și 9 se repetă pentru a treia resursă HW#3 pentru a
crea VM-7 ce găzduiește MRF-3 (rol: activ).

NOTĂ. Pașii de la 7 la 15 sunt prezentați ca ordonați pentru

ușurința citirii, dar crearea serverelor se poate face în orice ordinea și ar
putea fi paralelizate.

16) Imediat ce VM este creată, acesta pornește și așteaptă

fișierul său de definire a instanțierii (figura 3.9).
17) NFVO adaugă la datele de definire a instanțării datele din
VNFD și datele obținute ca urmare a creării VM (de exemplu,
70
adrese IP, mască de subrețea etc.). Acest fișier global de definire a
instanțierii conține informații despre tipul de VDU care rulează pe
fiecare VM (MRB, MRF, MRF Storage), rolul fiecărei instanțe
(activ/standby, master/slave), adresele IP ale celorlalte instanțe de
același tip pentru redundanță, adrese IP ale componentelor externe
(S-CSCF, App Server).

16- Așteaptă fișierul

NFVO 17-Generează fișierul VM#X de definire
de definiție a VNF
instanțierii augmentate

18- Copie fișierul de Sto 20-Citește fișierul

definire a instanțierii în care de definire
stocare

Pornește aplicația

21-Aplicația se
sincronizează
cu alte

Figura 3.9. Diagrama IMS MRF de desfășurare a secvenței –

faza de configurare

18) NFVO trimite apoi fișierul de definiție a instanțierii

augmentate într-o locație de stocare predefinită care va fi montată
de VM corespunzătoare. Acest fișier va fi utilizat pentru a furniza
configurația inițială a aplicației.

71
 19) Imediat ce toate fișierele de definire a instanțierii au fost
transmise, NFVO oferă un răspuns de succes la furnizarea IMS
MRF.
20) Fiecare VM citește fișierul de definire a instanțierii, își
descoperă tipul VDU și pornește aplicația.
21) Pe baza tipului său de VDU și a datelor din fișierul
definiție a instanței, instanța aplicației (MRB-1, MRB-2, MRF-1,
MRF-2, MRF-3, MRB Storage-1 și MRB Storage-2) se
sincronizează între ele. De exemplu, registrele secundare cu cele
primare.
După obținerea fișierului de definiție a instanțierii de VM
aplicația se configurează și pornește în mod automat.
Succesiunea descrisă este ilustrată de diagrama de secvență
(figura 3.9) în care VM#X este una dintre instanțările VM și
VNF#X este una dintre instanțele artefactului aplicației.

4. INTEGRAREA SDN ÎN CADRUL

ARHITECTORAL NFV

4.1. Principii generale

SDN și NFV sunt două tehnologii inovatoare independente.
Cu toate acestea, multe dintre obiectivele SDN sunt împărtășite de
NFV, astfel încât cele două beneficiază una de cealaltă și susțin
adoptarea reciprocă a acestora. Aceste două tehnologii pot ajuta la
introducerea rapidă de noi servicii, la reducerea cheltuielilor prin
trecerea de la hardware proprietar scump la hardware COTS cu
costuri mai mici.
Cu NFV, funcționalități precum firewall-uri, balansatoare de
sarcină, inspecția profundă a pachetelor DPI și nodurile IP
Multimedia Subsystem (IMS) care în mod tradițional se
implementează pe hardware specializate, sunt livrate ca funcții de
rețea virtuală (VNF) bazate pe software pe infrastructură cloud de
tip operator.

72
 SDN, pe de altă parte, simplifică conectivitatea dintre
elementele de rețea fizice și virtuale la nivelul 2/3 prin protocoale
de virtualizare a rețelei, cum ar fi OpenFlow.
Principiile generale și arhitectura rețelelor definite prin
software SDN, precum și protocolul OpenFlow sunt explicate în
[15].
NFV și SDN introduc schimbări radicale în arhitectura rețelei
de telecomunicații. Atât SDN cât și NFV oferă abordări diferite
pentru implementarea rețelei flexibile, scalabile, elastice și agile.
Deși aceste două tehnologii pot fi implementate independent,
principiile SDN pot fi aplicate NFV prin virtualizarea funcției de
rețea, precum și prin separarea funcției nivelului de control de
nivelul resurselor. Principiile NFV și SDN pot fi aplicate majorității
elementelor de rețea de acces și la nivel de core. Routerele și
comutatoarele, în rețelele LAN și WAN, pot fi înlocuite cu
comutatoare white box care acceptă abordări SDN cum ar fi
OpenFlow. În mod similar, majoritatea elementelor bazate pe
hardware, cum ar fi nodurile IMS, platformele EPC (Evolved
Packet Core) și platformele CDN (Content Delivery Network), pot
fi virtualizate pe infrastructura cloud cu NFV. Furnizorii de servicii
cloud explorează, de asemenea, alternative pentru migrarea
echipamentelor periferice ale clienților (CPE) bazate pe hardware,
cum ar fi STB (Set Top Boxes), la principiile bazate pe NFV.
În cadrul arhitectural NFV, soluțiile SDN ar putea fi utilizate
în domeniul infrastructurii, în domeniul chiriașilor sau în ambele.
Când este utilizat în domeniul infrastructurii, controlerul SDN
acționează ca un controler de rețea, conform ETSI GS NFV-MAN
001 [11]. Controlerul de rețea este bloc funcțional care centralizează
unele sau toate funcționalitățile de control și gestionare ale unui
domeniu de rețea și oferă o vedere abstractă a domeniului său către
alte blocuri funcționale prin interfețe bine definite.
În prezenta lucrare, SDN se referă la controlul software al
resurselor fizice sau virtuale ale rețelei care utilizează interfețe

73
standard (API-uri deschise) pentru a facilita interoperabilitatea și
evoluția într-un mediu multifurnizor.
Controlerul SDN nu este neapărat o entitate fizică autonomă,
el poate fi de exemplu o componentă software a VIM. Dacă
tehnologia SDN este utilizată în domeniul infrastructurii, managerul
VIM, controlerul SDN și resursele de rețea (fizice sau virtuale)
formează o ierarhie pentru furnizarea de servicii de conectivitate. În
unele cazuri, mai multe controlere SDN formează o ierarhie între
management și resurse, în funcție de plasarea funcționalității.
Responsabilitatea controlerului SDN include funcții de control
foarte specifice, interacționând cu agenții responsabili de funcțiile
de control și management.
În IETF RFC 7426 [16] se discută distincția dintre nivelul de
control și funcțiile de management într-un mediu SDN. Pe scurt,
nivelul de control ia decizii cu privire la modul în care pachetele
sunt redirecționate de resursele de rețea și impune aceste decizii
resurselor de rețea pentru executare. Funcțiile de managament sunt
în principal responsabile de monitorizarea, configurarea și
întreținerea resurselor de rețea, de exemplu luarea deciziilor cu
privire la starea resurselor rețelei. Distincția dintre nivelul de
control și cel de management a devenit oarecum confuză datorită
centralizării logice a controlului, care este specifică mai mult
managementului.
Deci, nivelul de control se ocupă de traficul de date, nivelul
de management are responsabilitatea configurării, monitorizării
defecțiunilor și gestionării resurselor de rețea.
După cum s-a menționat mai sus, accentul se pune pe modul
în care serviciile de rețea și resursele asociate ar putea fi integrate
cu cadrul arhitectural NFV. În procesul de integrare a SDN în NFV
apar multe probleme tehnice și nontehnice cu privire la entitățile
funcționale care constituie acest cadru arhitectural integrat, cum ar
fi:
• poziția resurselor SDN;
• poziția controlerului SDN;

74
 • softwarizarea și virtualizarea diferitelor entități SDN;
• interacțiunea dintre managerul de elemente EM, managerii
VNF, controlorii SDN și aplicațiile SDN care devin VNF activate;
• ierarhia rețelelor SDN;
• poziția rețelelor SDN suprapuse;
• altele.
Diferite entitățile SDN pot fi plasate în mai multe locații în
cadrul NFV. În cele ce urmează se va discuta despre plasarea
resurselor, controlerului și aplicațiilor SDN în structura NFV.

4.2. Poziționarea entităților SDN în cadrul arhitectural

NFV
Mediul SDN poate fi virtualizat sau nonvirtualizat.
Arhitectura NFV acceptă și poate interacționa cu diferite
componente SDN într-o manieră perfectă.
Primele entități care ar trebui luate în considerare în procesul
de integrare a tehnologiilor sunt resursele SDN. Pot fi examinate
mai multe scenarii de locație a resurselor SDN reale sau a
imaginilor lor în cadrul NFV.
Aceste variante posibile de locație sunt reprezentate în figura
4.1.
Locul de plasare a comutatoarelor și routerelor SDN sunt
evidențiate printr-un pătrățel cu literă înscrisă in el:
• Cazul a. Comutator sau router ca echipamente SDN
hardware în calitate de resursă în cadrul NFV.
• Cazul b. Switch sau router virtuale ca și componenți ai
infrastructurii NFVI.
• Cazul c. E-switch, switch bazat pe software adaptat la SDN
într-un server NIC.
• Cazul d. Comutator sau router ca funcție de rețea virtualizată
VNF.
În cazul d, resursa ar putea fi în mod logic parte a NFVI sau
ar aparține unui domeniu independent al arendașului (tenant)*.

75
 *) NOTĂ. Arendaș sau chiriaș (tenant): unul sau mai mulți
utilizatori de servicii NFV-MANO care partajează accesul la un set de
resurse fizice, virtuale sau de servicii [6].

Os-Ma
OSS/BSS Orchestrator
(NFVO)

Descrierea infrastructurii, Se-Ma

Or-Vnfm
VNF și a serviciului
Or-

VNF
EM 1 EM 2 EM 3 Ve-Vnfm
Manager(i)
Ve-Vnfm
(VNFM)

VNF 1 VNF 2 VNF 3 d

Vn-Nf
Vi-Vnfm
NFVI
Or-Vi
Calcul Stocare Rețea
virtual virtuală virtuală b
Manager(i)
Nf-Vi Infrastructură
virtualizată
(VIM)
Nivel de virtualizare
VI-Ha VI-Ha
Resurse hardware
Managemant și
Resursă Resurs Resursă
calcul stocare rețea a Orchestrare NFV
c (MANO)

X - Resurse SDN

Figura 4.1. Locații posibile de resurse SDN în cadrul

arhitectural NFV [17]

76
 Un exemplu de caz d este ilustrat în NFV PoC#14 (clauza
B.5) [18]. Acest PoC (Proof of Concept) a demonstrat utilizarea
SDN într-un mediu NFV împărțind Gateway-rile de servicii (SGW)
și pachete (PGW) al arhitecturii LTE (Long Term Evolution) în
straturi de control și de date cu interfețe deschise între ele. PoC#14
demonstrează că funcționalitatea stratului de date ar putea fi
implementată ca VNF și controlată ca resursă de rețea.
O altă entitate considerată în procesul de integrare a
tehnologiilor este controlerul SDN, care interacționează cu resursele
de rețea SDN prin intermediul interfeței de control al resurselor RCI
(Resource Control Interfaces). Un controler SDN poate interacționa
cu mai multe resurse de rețea SDN.
Există câteva posibile scenarii de locație a controlerului SDN
în cadru NFV (figura 4.2):
• Cazul 1. Controlerul SDN poate fi fuzionat cu
funcționalitatea managerului de infrastructură virtualizată (VIM). În
acest caz, cele două funcții nu se disting.
• Cazul 2. Controlerul SDN poate fi virtualizat în calitate de
funcție de rețea VNF în sine, cu managerul său EM & VNF sau ca
parte dintr-o VNF.
• Cazul 3. Controlerul SDN ca parte din infrastructura NFVI.
Acesta este un caz clasic al controlerului SDN pentru conectivitatea
de rețea din NFVI, unde controlerul SDN nu este implementat ca
VNF.
• Cazul 4. Controlerul SDN ca parte din sistemele de suport
operațiuni și afaceri OSS/BSS.
• Cazul 5. Controlerul SDN poate fi și ca funcție de rețea
fizică (PNF).
Pot exista controlere SDN pentru infrastructura fizică,
infrastructura virtuală și funcțiile de rețea virtuală și fizică. Unele
dintre aceste controlere SDN pot fi plasate în blocurile funcționale
NFVI sau MANO.

77
 Os-Ma
Orchestrator
4 OSS/BSS V (NFVO)

Descrierea infrastructurii, Se-Ma

Or-Vnfm
VNF și a serviciului
Or-

IV
VNF
EM 1 EM 2 EM 3 Ve-Vnfm
Manager(i)
Ve-Vnfm
(VNFM)

2 VNF 1 VNF 2 VNF 3 III

Vn-Nf
Vi-Vnfm
NFVI 3
Or-Vi
Calcul Stocare Rețea
virtual virtuală virtuală
Manager(i)
Nf-Vi Infrastructură
virtualizată
(VIM)
Nivel de virtualizare
VI-Ha VI-Ha
1 II
Resurse hardware
Managemant și
Resursă Resurs Resursă
Orchestrare NFV
calcul stocare rețea
I (MANO)
PNF
5

Aplicație SDN - Controler SDN-

Figura 4.2. Locații posibile ale controlerului și aplicației SDN

în cadrul arhitectural NFV

78
 Controlerele SDN ar putea apărea ierarhizate pe blocuri
funcționale. De exemplu, un controler SDN colocalizat cu VIM
(cazul 1) invocă un controler SDN în NFVI (cazul 3) pentru a aloca
resurse de rețea NFVI. Cazul dat este posibil când controlerul VIM
SDN controlează direct vSwitch activat SDN și indirect printr-un
controler NFVI SDN comutatoarele SDN fizice. Controlerul SDN
virtualizat (cazul 2) poate fi o componentă VNFC sau o VNF, sau
un serviciu de rețea (NS) compus din mai multe VNF ca
subelemente ale controlerului SDN.
Controler SDN se implementează într-un cadru arhitectural
NFV printr-o imagine software și o descriere a resurselor necesare
dată de descriptorii respectivi.
A treia entitate considerată este aplicația SDN. O aplicație
SDN poate interacționa cu mai multe controlere SDN. Sunt posibile
mai multe scenarii de poziționare a aplicațiilor SDN în cadrul
arhitectural NFV, cum ar fi:
• Cazul I, ca parte a unui PNF. Echipamentul de rețea poate fi
un dispozitiv fizic care interacționează cu un controler SDN.
• Cazul II, ca parte a VIM. VIM poate fi o aplicație care
interacționează cu un controler SDN în NFVI - de exemplu,
OpenStack Neutron ca VIM care interacționează cu un controler
SDN în NFVI.
• Cazul III, virtualizată ca VNF. O careva aplicație SDN ar
putea fi un VNF care interacționează cu un controler SDN. De
exemplu, o funcție virtualizată PCRF (Policy Control and Routing
Function) VNF ar putea interacționa cu un controler SDN pentru
gestionarea politicilor și redirecționarea traficului.
• Cazul IV, ca parte a unui EM. Aplicația SDN ca manager de
elemente care interacționează cu controlerul SDN pentru a colecta
unele valori sau a configura unii parametri.
• Cazul V, ca parte a OSS/BSS. Aplicația SDN
interacționează cu controlerul SDN în OSS/BSS pentru definițiile
serviciului SDN pentru chiriași.

79
 În desfășurare sunt o serie de proiecte care utilizează în mod
colectiv instrumentele open source disponibile atât în SDN, cât și în
NFV. Un astfel de exemplu este proiectul comun Open Networking
Lab (ON.Lab) și AT&T numit CORD (Central Office Re-
Architected as Datacenter). Acest proiect este discutat mai detaliat
pentru a prezenta și explica integrarea SDN și NFV.

4.3. Proiectul CORD

CORD® este un proiect open source al ONF (Open
Networking Foundation) și acceptat ca proiect în portofoliul Linux
Foundation. CORD (Central Office Re-architected as a Datacenter)
este un exemplu de integrare a NFV și SDN [19]. Oficiul central
(CO) reproiectat ca centru de date CORD folosește tehnologiile
SDN, NFV și Cloud pentru a construi un centru de date agile pentru
rețelele de frontieră. Prin integrarea mai multor proiecte open
source CORD oferă o platformă deschisă, programabilă și agilă care
permite operatorilor de rețea să creeze servicii inovatoare.
Structurile moderne ale centrelor de date virtualizate trebuie
să îndeplinească anumite cerințe pentru a accelera implementarea
aplicațiilor de nouă generație. Centrele de date care implementează
tehnologia CORD utilizează o arhitectură numită Leaf-spine.

4.3.1. Arhitectura centrelor de date Leaf-spine

În centrele de date de astăzi este preluat un design topologic
care se numește topologie Leaf - spine (figura 4.3).
Într-un centru de date, în partea de sus a fiecărui rack cu
servere există o pereche de comutatoare. Pentru redundanță, fiecare
server din rack are o conexiune la ambele switch-uri.

80
 Figura 4.3. Topologia Leaf-Spine a arhitecturii centrului de date

Pentru a se referi la aceste tipuri de comutatoare se folosește

termenul ToR (top-of-rack), deoarece acestea se află fizic în partea
de sus a unui rack. Aceste comutatoare ToR acționează ca leaves
(frunze) în topologia Leaf-spine.
Porturile comutatorilor leaf au una dintre cele două
responsabilități:
(1) conectarea la un nod (de exemplu, un server din rack sau
un router);
(2) conectarea la un comutator spine.
Se observă că fiecare comutator leaf se conectează la fiecare
comutator spine. Ca urmare, nu este nevoie de interconectări între
comutatoarele spine. Prin interconectarea comutatoarelor ToR ale
centrului de date într-o topologie leaf-spine, toate comutatoarele
sunt la aceeași distanță unul față de celălalt (adică un singur hop).
În această arhitectură de tip Clos cu două niveluri, fiecare
comutator de nivel inferior (strat leaf) este conectat la fiecare dintre
comutatoarele de nivel superior (stratul spine) într-o topologie full-
mesh. Stratul leaf constă din comutatoare de acces care se
conectează la dispozitive precum servere, routere. Stratul spine este
core-ul rețelei și este responsabil pentru interconectarea tuturor
comutatoarelor leaf.

81
 4.3.2. Proiectul R-CORD
Diagrama generică a arhitecturii CORD este reprezentată de
figura 4.4. Arhitectura CORD include un set de hardware și
software. Sistemul de operare ONOS (Open Network Operating
System) este utilizat ca controler SDN. Sistemul de operare ONOS®
este principalul controler open source SDN pentru construirea de
soluții SDN/NFV de generație următoare găzduit de Linux
Foundation.
Serviciile de rețea sunt implementate de VNF-urile care
rulează pe hardware COTS, iar orchestrarea NFVI se efectuează de
OpenStack. OpenStack este o platformă open source de cloud
computing, desfășurată în cea mai mare parte ca infrastructură ca
serviciu (IaaS) atât în cloud public, cât și privat.
Sistemul de operare în cloud deschis XOS îmbină aceste
elemente pentru a face posibilă crearea, gestionarea, rularea și
oferirea de servicii. XOS îndeplinește rolul de VNFM, rulează
deasupra OpenStack și ONOS pentru managementul serviciilor în
CORD.
Așa cum se arată în figura 4.4, serverele COTS și rețeaua de
bază sunt construite în stilul leaf - spine al arhitecturii centrului de
date.
Echipa de coordonare tehnică (TST) CORD a stabilit un șir de
proiecte sub umbrela CORD printre care:
 Rezidențial - Residential CORD (R-CORD);
 De întreprindere - Enterprise CORD (E-CORD);
 Mobil - Mobile CORD (M-CORD);
 Pentru analize - Analytics for CORD (A-CORD).

82
 XOS

Controler Orchestrator
SDN (ONOS) NFVI (OpenStack)

SPINE SPINE
Switch Switch

Leaf Leaf Leaf Leaf

Switch Switch Switch Switch

I/O Servere Servere I/O

Acces WhiteBox WhiteBox Metro

Figura 4.4. Arhitectura CORD

În cele ce urmează va fi explicat mai detaliat doar proiectul

CORD rezidențial.
CORD rezidențial (R-CORD) a fost dezvoltat cu scopul de a
transforma oficiile centrale (CO) convenționale din rețele de acces
ale operatorilor în ceva similar cu centrele de date ale furnizorilor
de servicii cloud. R-CORD include servicii care valorifică
tehnologiile rețelelor de acces prin fibra optică (GPON, G.Fast,
10GPON) și cablul coaxial DOCSIS (Data Over Cable Service
Interface Specification).

83
Obiectivele principale sunt:
 reducerea cheltuielilor CAPEX/OPEX;
 evitarea dependenței de furnizorii de echipamente de
telecomunicații;
 crearea de servicii agile.
Exemplul dat prevede utilizarea SDN, NFV și Cloud la
rețeaua de acces formată din CPE (Customer premises equipment)
la domiciliu și terminale de linie optică OLT (optical line
terminator ) GPON, Switch-ul de agregare și BNG (Broadband
Network Gateway) la oficiul central CO. Implementarea presupune
utilizarea doar a elementelor SW și HW open source. De exemplu,
echipamente HW: White BoX SDN Switch, server x86, Open OLT
blade, Open Blade ROADM și soluții SW: ONOS, OpenStack,
XOS.
În primul rând, planul de control OLT (conectarea ONT,
autentificarea, alocarea/gestionarea abonat 802.1X VLAN, IGMP
snooping, OAM etc.) procesat de CPU în placa de control a OLT
veche a fost îndepărtat și plasat pe serverul x86 situat în rețea
(aplicația vOLT din figura 4.5).
Dispozitivul OLT dezagregat și virtualizat pentru GPON este
numit vOLT.
Funcțiile care erau îndeplinite de planul de control al BNG în
sistemul vechi vor fi gestionate de asemenea de aplicația vOLT.
Aplicația vOLT interacționează:
I) cu serverul Radius (pentru autentificare);
II) cu controlerul SDN (pentru alocarea VLAN per abonat la
blade-ul cardului de linie OLT);
III) cu aplicație de control SF (switch fabric) pentru
configurarea căii la structura comutatorului în CO.
Rolul plăcii de control, care este de a controla, configura și
gestiona placa de comutare și cârdurile de linie GPON prin
interfețele proprietare ale furnizorului, este înlocuit de controlerul
SDN ONOS. Plăcile de comutare sunt înlocuite de switch-uri ToR
(Leaf) în CO.
84
 Figura 4.5. Oficiul central GPON după implementarea R-CORD

În cele din urmă, cardurile de linie GPON din OLT sunt

înlocuite de palete (blade) de card de linie Open GPON care au doar
caracteristica PON MAC.
Aceste palete (blades) nu fac parte dintr-un sistem OLT cu
șasiu pentru mai multe linii, ci sunt dispozitive independente în

85
sine. Fiecare paletă (blade) de cartelă open GPON este conectată la
un comutator ToR prin porturi uplink de 40 Gbps.
L3 CPE (cunoscut și sub numele de RG, Residential
Gateway) instalat în casele abonaților este responsabil de funcții
precum autentificarea, DHCP și NAT. CPE este virtualizat și toate
funcțiile software sunt mutate pe containerul din VM-ul din serverul
vSG (Virtual Subscriber Gateway) situat în CO. La domiciliul
abonatului rămâne doar CPE HW (funcțiile de Switch și Wi-Fi
modem).
Odată cu efectuarea modificărilor descrise, rețeaua de acces
moștenită se va transforma într-o arhitectură complet inovată,
bazată pe SDN și NFV.
Planul de date din rețeaua de acces este procesat de HW open
source și VNF (vSG) la prețuri reduse. HW open source este
controlat de controlerul SDN și orchestratorul NFV, care sunt, de
asemenea, SW open source, cum ar fi ONOS, XOS și OpenStack.
Încheiere. Transformarea digitală bazată pe NFV este o
revoluție care se desfășoară în industria comunicațiilor electronice.
Ea poate fi comparată doar cu înlocuirea centralelor telefonice
automate (CTA) analogice cu cele digitale, care a avut loc în urmă
cu 40-50 de ani și a durat mulți ani în șir. La fel, ca „digitalizarea”
CTA în urmă cu jumătate de secol, „NFV-zarea” probabil va dura
destul de mult timp.

86
 BIBLIOGRAFIE

1. ETSI White Paper No. #32, 1st edition. Network

Transformation (Orchestration, Network and Service Management
Framework). ISBN No. 979-10-92620-29-0. 2019.
2. IETF RFC 8568. Network Virtualization Research
Challenges, 2019.
3. S. Natarajan, R. Krishnan, A. Ghanwani, D.
Krishnaswamy, P. Willis, A. Chaudhary, and F. Huici. "An
Analysis of Lightweight Virtualization Technologies for NFV",
draft-natarajan-nfvrg-containers-for-nfv-03, 2016.
4. NFV White paper: ”Network Functions Virtualisation, An
Introduction, Benefits, Enablers, Challenges & Call for Action.
Issue 1”, 2012.
Accesibil http://portal.etsi.org/NFV/NFV_White_Paper.pdf.
5. ETSI GS NFV 002: ”Network Functions Virtualisation
(NFV); Architectural Framework, v1.2.1”, 2014.
6. ETSI GS NFV 003: ”Network Functions Virtualisation
(NFV); Terminology for Main Concepts in NFV”, 2020.
7. ETSI NFV-ISG, NFV-SWA 001: ”Network Function
Virtualization (NFV); Virtual Network Functions Architecture,
v1.1.1”, 2014.
8. ETSI GS NFV-INF 004: ”Network Functions Virtualisation
(NFV); Infrastructure; Hypervisor Domain”, 2015.
9. ETSI GS NFV-EVE 004. ”Network Functions
Virtualisation (NFV); Virtualisation Technologies; Report on the
application of Different Virtualisation Technologies in the NFV
Framework”. 2016.
10. ETSI GS NFV-INF 001: ”Network Functions
Virtualisation (NFV); Infrastructure Overview, v.1.1.1”, 2015.
11. ETSI GS NFV-MAN 001. ”Network Functions
Virtualisation (NFV); Management and Orchestration, v1.1.1”,
2014.

87
 12. Nazaroi Ion. Sisteme și rețele de comunicații digitale.
Ciclu de prelegeri. Partea 2. Chișinău: Editura ”Tehnica-UTM”,
2015. - 60 p.
13. Nazaroi Ion. Subsistemul mutimedia IP. Ciclu de
prelegeri. Chișinău: Editura ”Tehnica-UTM”, 2020. - 87 p.
14. ETSI TS 123 218: ”Digital cellular telecommunications
system (Phase 2+); Universal Mobile Telecommunications System
(UMTS); LTE; IP Multimedia (IM) session handling; IM call
model; Stage 2 (3GPP TS 23.218)”.
15. Nazaroi Ion. Rețele definite prin software. Ciclu de
prelegeri. Chișinău: Editura ”Tehnica-UTM”, 2019. - 56 p.
16. IETF RFC 7426. ”Software-Defined Networking (SDN):
Layers and Architecture Terminology”, 2015.
17. ETSI GS NFV-EVE 005: ”Network Functions
Virtualisation (NFV); Ecosystem; Report on SDN Usage in NFV
Architectural Framework, v1.1.1”, 2015.
18.https://nfvwiki.etsi.org/index.php?title=E2E_vEPC_Orche
stration_in_a_multi-vendor_open_NFVI_environment#PoC_Report
19. https://opennetworking.org/cord/

88
 ACRONIME ȘI ABREVIERI

Acronimele și abrevierile sunt date după alfabet.

AAA Authentication, Authorization and Accounting

AN Access Node
AMD Advanced Micro Devices
API Application Programming Interface
AR Access Router
ARPU Average Revenue Per User
AS Application Server
ATM Asynchronous Transfer Mode
BGP Border Gateway Protocol
BNG Broadband Network Gateway
BRAS Broadband Remote Access Server
BS Base Station
BSS Business Support System
CAPEX Capital Expenses
CDN Content Delivery Network
CDR Call Detail Record
CI/CD Continuous Integration/Continuous Deployment
CG-NAT Carrier-grade NAT
CO Central Office
CORD Central Office Re-architected as a Datacenter
COTS Commercial Off The Shelf
CPE Customer Premises Equipment
CPU Central Processing Unit
CPU CISC CPU Complex Instruction Set Computer
CSCF Call Session Control Function
CSP Cloud Service Provider
DevOps Development and Operations
DHCP Dynamic Host Configuration Protocol
DOCSIS Data Over Cable Service Interface Specification
DPI Deep Packet Inspection

89
DPDK Data Plane Development Kit
DSL Digital Subscriber Line
DSP Digital Signal Processor
E2E End-to-End
EM Element Manager
EMS Element Management System
EPC Evolved Packet Core
ETSI European Telecommunications Standards Institute
FCAPS Fault, Configuration, Accounting, Performance and
Security
FG Forwarding Graph
FTTdp Fibre-To-The distribution point
FTTH Fibre-To-The Home
FTTN Fibre-To-The-Node
FTTP Fibre To The Premises
FW Firewall
GGSN Gateway GPRS Support Node
GPON Gigabit Passive Optical Network
GPRS General Packet Radio Services
GUI Graphical User Interface
GW Gateway
HA/LB High Availability/Load Balancing
HDD Hard Disk Drive
HLR Home Location Register
HSS Home Subscriber Server
HTTP Hypertext Transfer Protocol
HW Hardware
IaaS Infrastructure as a Service
I-CSCF Interrogating-Call Session Control Function
IDS Intrusion Detection System
IGMP Internet Group Management Protocol
IMS IP Multimedia Subsystem
I/O Input Output
IoT Internet of Things

90
IP Internet Protocol
IPSec Internet Protocol Security
ISP Internet Service Provider
IT Information Technology
IVR Interactive Voice Response
KPI Key Performance Indicator
KVM Kernel Virtual Machine
L3VPN Layer 3 Virtual Private Networks
LAN Local Area Network
LB Load Balancer
LTE Long-Term Evolution
LTE-A Long-Term Evolution-Advanced
LXC Linux container
MAC Media Access Control
MANO Management and Orchestration
MGCF Media Gateway Control Function
MRB Media Resource Broker
MRF Media Resource Function
MRF-C Multimedia Resource Function Controller
MRF-P Multimedia Resource Function Processor
NaaS Network as a Service
NAT Network Address Translation
NF Network Function
NFV Network Functions Virtualisation
NFVI Network Functions Virtualisation Infrastructure
NFVIaaS Network Functions Virtualisation Infrastructure as a
Service
NFVI-PoP Network Functions Virtualisation Infrastructure Point
of Presence
NFV ISG NFV Industry Specification Group
NFV-MANO NFV Management and Orchestration
NFVO NFV Orchestrator
NGN Next Generation Networks
NIC Network Interface Controller

91
NIST National Institute of Standards and Technology
NMS Network Management System
NS Network Service
NSD Network Service Descriptor
OLT Optical Line Termination
ONF Open Networking Foundation
ONOS Open Network Operating System
ONT Optical Network Terminal
ONU Optical Network Unit
OPEX Operational Expenses
OS Operating System
OSS Operations Support System
OTT Over-The-Top
PaaS Platform as a Service
PCI Peripheral Component Interconnect
PCRF Policy and Charging Control Function
PDN-GW Packet Data Network Gateway
PGW Packet Data Network Gateway
PNF Physical Network Function
PNFD Physical Network Function Descriptor
PoC Proof of Concept
PON Passive Optical Network
PoP Point of Presence
PSTN Public Switched Telephone Network
QoE Quality of Experience
QoS Quality of Service
RAM Random Access Memory
RAN Radio Access Network
RCI Resource Control Interfaces
R-CORD Residential Central Office Re-architected as a Datacenter
RDBMS Relational DataBase Management System
RISC Reduced Instruction Set Computer
RGW Residential Gateway
RNC Radio Network Controller

92
 SaaS Software as a Service
SAN Storage Area Network
SBC Session Border Controller
SDD Solid-State Drive
SDN Software Defined Networks
S-CSCF Serving Call Session Control Function
SD-WAN Software Defined Wide Area Network
SGW Serving Gateway
SGSN Serving GPRS Support Node
SIP Session Initiation Protocol
SLA Service Level Agreement
SNMP Simple Network Management Protocol
SR-IOV Single Root Input Output Virtualisation
SSD Solid State Disk
SSL Secure Sockets Layer
STB Setup Box
SVC/PVC Switched Virtual Circuit /Permanent Virtual Circuit
SW SoftWare
SWA Software Architecture Work group
ToR Top-of-Rack
URI Uniform Resource Indetifier
vCPU Virtualised CPU
VDU Virtualisation Deployment Unit
VIM Virtual Infrastructure Manager
VL Virtual Link
VLD Virtual Link Descriptor
VLAN Virtual Local Access Network
VM Virtual Machine
VMM Virtual Machine Manager
VNF Virtual Network Function
VNF FG VNF Forwarding Graph
VNFC Virtualised Network Function Component
VNFCI VNF Component Instance
VNFD VNF Descriptor

93
VNFFG VNF Forwarding Graph
VNFFGD VNFFG Descriptor
VNFI VNF Instance
VNFM Virtualised Network Function Manager
vNIC Virtual Network Interface Controller
VPN Virtual Private Network
VPLS Virtual Private LAN Service
vRAM Virtualised Random Access Memory
VR/AR Virtual Reality/Augmented Reality
VXLAN Virtual Extensible LAN
WAN Wide Area Network

94
 CUPRINS

Introducere........................................................................................3
1. Virtualizarea în tehnologia informației......................................5
1.1 Definiția virtualizării.............................................................5
1.2 Tehnici de virtualizare...........................................................7
1.3 Containere și Docker...........................................................11

2. Virtualizarea funcțiilor de rețea...............................................16

2.1 Descrierea generală a NFV.................................................16
2.2 Cadrul NFV la nivel înalt.....................................................20
2.3 Arhitectura NFV...................................................................23
2.4 Cadrul arhitectural de management și orchestrare NFV-
MANO..................................................................................43

3. Exemplu virtualizare MRF IMS…………..……......................56

3.1 Descrierea funcției MRF supusă virtualizării .................57
3.2 Instanțierea IMS MRF într-un mediu virtualizat..…..….58
3.3 Cerințele privind managementul și orchestrarea…..…...60
3.4 Cerințele privind infrastructura……….……………..…60
3.5 Virtualizarea funcțiilor resurse media..………………...61
3.6 Îmbarcarea și desfășurarea serviciului IMS MRF….......64
3.7 Provizionarea și configurarea instanței IMS MRF…......67
3.8 Implementarea IMS MRF pentru resursa HW 1......…...69

4. Integrarea SDN în cadrul arhitectoral NFV................................72

4.1 Principii generale...................................………………...72
4.2 Poziționarea entităților SDN în cadrul arhitectural NFV.75
4.3 Proiectul CORD…………………….........…….……….80
Bibliografie......................................................................................87
Acronime și abrevieri......................................................................89

95
 Virtualizarea funcțiilor de rețea

Ciclu de prelegeri

Autor: Ion NAZAROI

––––––––––––––––––––––––––––––––––––––––––––––––––––––
Bun de tipar 09.02.21 Formatul 60x84 1/16
Hârtie ofset. Tipar RISO Tirajul 50 ex.
Coli de tipar 6,0 Comanda nr. 12
––––––––––––––––––––––––––––––––––––––––––––––––––––––
2004, UTM, bd. Ştefan cel Mare şi Sfânt, 168
Editura „Tehnica-UTM”
2045, Chişinău, str. Studenţilor, 9/9