SRCD 1

UNIVERSITATEA TEHNICĂ A MOLDOVEI
Facultatea Inginerie şi Management în

Electronică şi Telecomunicaţii
Catedra Telecomunicaţii
SISTEME ŞI REŢELE DE COMUNICAŢII DIGITALE

Partea 1
CICLU DE PRELEGERI
Chişinău
Editura „Tehnica-UTM”
2014
1
Lucrarea de faţă include prima parte a cursului
Sisteme şi reţele de comunicaţii digitale şi este divizată în
două compartimente. În primul compartiment este dată
definiţia şi arhitectura reţelelor de noua generaţie NGN,
motivele şi cauzele migrării reţelelor clasice PSTN spre
reţelele NGN. În partea a doua a lucrării – detaliat, se
analizează protocolul de iniţiere a sesiunii SIP.
Obiectivul principal al acestui curs constă în însuşirea
cunoştinţelor de bază privind reţelele de noua generaţie
inclusiv arhitectura reţelei, componentele funcţionale,
protocoalele utilizate, platformele tehnologice actuale şi
viitoare.
Cursul Sisteme şi reţele de comunicaţii digitale este
destinat studenţilor UTM cu profilul 525 Electronică şi
comunicaţii, specialităţile Teleradio – comunicaţii, cu forma de
studii la zi şi cu frecvenţă redusă.
Autor: conf.univ., dr. Ion NAZAROI
Recenzent: conf.univ., dr. Nicolae BEJAN
Redactor: E. Gheorghişteanu
––––––––––––––––––––––––––––––––––––––––––
Bun de tipar 22.05.14 Formatul 60x84 1/16
Hârtie ofset. Tipar RISO Tirajul 55 ex.
Coli de tipar 4,0 Comanda nr.51
–––––––––––––––––––––––––––––––––––––––––––––
U.T.M., 2004, bd. Ştefan cel Mare şi Sfânt, 168
2068, Chişinău, str. Studenţilor, 9/9
© UTM, 2014
2
INTRODUCERE
Dezvoltarea actuală a sistemelor şi reţelelor de comunicaţii

digitale, atît în domeniul comunicaţiilor fixe cît şi al
comunicaţiilor mobile, este orientată pe introducerea şi
utilizarea de tehnologii care permit integrarea diferitelor tipuri
de servicii în cadrul reţelelor de telecomunicaţii unice.
Combinarea suportului reţelei de telecomunicaţii cu cel
informatic permite exploatarea capabilităţilor oferite pentru
aplicaţii noi şi performante.
O serie de noi tehnologii, protocoale şi echipamente
elaborate în ultimele două decenii au avut o influenţă
hotărîtoare asupra trecerii de la reţelele clasice la cele de
noua generaţie NGN. Printre principalele pot fi numite:
Tehnologiile de acces de bandă largă ADSL, VDSL,
FTTx, LTE, WiMax, etc;
Sistemul de transmisiuni DWDM (Dense Wavelength
Division Multiplexing – multiplexarea densă a lungimilor de
undă) la nivelul fizic;
Metoda de comutaţie rapidă de pachete după etichetă
MPLS (Multiprotocol Label Switching) la nivelul "2.5";
Dezvoltarea de tehnologii Ethernet dincolo de LAN;
Noi echipamente terminale, aparate telefonice IP, PC,
IPad, smartphonuri,etc;
Dezvoltarea de protocoale adecvate pentru a oferi
servicii de comunicaţii voce bazate pe pachete (SIP, H.323);
Digitalizarea fluxurilor de media (voce, date, imagini).
În sfîrşit dar nu în ultimul rînd aici se poate menţiona şi
dezvoltarea vertiginoasă a serviciilor Internet bazate pe suita
de protocoale TCP/IP.
În acelaşi rînd, printre principalele cauze care au
determinat operatorii de telecomunicaţii tradiţionali să iniţieze
migrarea reţelei PSTN spre o reţea de noua generaţie pot fi
enumerate:
3
-tendinţa de utilizare a unei tehnologii mai eficiente
decît cele bazate pe comutaţia de circuite pentru
transmiterea traficului de voce, de comun cu integrarea
transmisiunilor voce, date, imagini într-o reţea unică;
-solicitări din partea utilizatorilor de noi servicii, în
special cele care necesită o bandă largă de transmisiune cum
ar fi acces rapid la Internet, video la cerere (VoD), IPTV,
jocuri interactive (entertainment), etc;
-concurenţa ascendentă din partea prestatorilor de
servicii de telefonie internaţională prin Internet astfel ca
Skype, Microsoft, Yahoo şi alte companii, precum şi cea din
partea prestatorilor de telefonie IP locali.
Sub influenţa acestor forţe motrice sectorul serviciilor de
comunicaţii a suferit deja schimbări importante pe parcursul
cîtorva ani. Centralele tradiţionale PSTN de clasa 5 şi clasa 4
se substituie cu Gateway-uri de acces şi trunchiuri sub
controlul Softswitch-ului sau a Media Gateway Controler-ului
şi în continuare cu trecerea treptată la platforma IMS (IP
Multimedia Subsystem). Reţelele magistrale migrează pe
tehnologii ALL-IP/MPLS deseori în contextul implementării
sistemelor de transmisiuni DWDM la nivelul fizic. La nivelul
doi se dezvoltă reţelele de transport Giga- şi Metro-Ethernet.
Pe larg se desfăşoară reţelele pe fibră optică inclusiv şi pe
ultima milă. Tot mai mulţi abonaţi utilizează tehnologii de
bandă largă ce asigură o viteză înaltă de acces şi gamă largă
de servicii Triple Play. Devine posibilă şi tot mai des
implementată convergenţa fix-mobil. Convergenţa fix-mobil
(FMC) este tendinţa de conectivitate între reţelele de
telecomunicaţii fixe şi fără fir (wireless). Scopul FMC este a
optimiza transmiterea tuturor comunicaţiilor de date, voce sau
video utilizatorilor finali indiferent de locaţia lor sau de
dispozitivele utilizate.
Obiectivul principal al acestui curs constă în însuşirea
cunoştinţelor de bază privind reţelele de noua generaţie
4
inclusiv arhitectura reţelei, componentele funcţionale,
protocoalele utilizate, platformele actuale şi viitoare.
Prima parte a cursului de prelegeri include expunerea
generală a reţelelor de noua generaţie şi continuă cu
protocolul de semnalizare cheie pentru aceste reţele –
protocolul de iniţiere a sesiunii SIP.
Lucrarea în cauză este destinată studenţilor ultimului an
universitar, masteranzilor, dar autorul speră să fie de folos şi
tuturor celor din domeniul TIC interesaţi de subiectele
abordate.
1. PREZENTAREA GENERALĂ A NGN
1.1 Definiţia NGN
Reţea de noua generaţie NGN (Next Generations Network)

este un termen generic utilizat pentru descrierea reţelelor
aflate actualmente în curs de dezvoltare şi implementare
intensivă.
Conform definiţiei Uniunii Internaţionale a
Telecomunicaţiilor (ITU), termenul NGN este o reţea bazată
pe comutaţia de pachete, capabilă să ofere servicii de
telecomunicaţii cu utilizarea a multiple tehnologii de transport
de bandă largă (broadband) cu asigurarea unui nivel adecvat
de calitate a serviciilor (QoS) şi la care funcţiile relevante
serviciilor sînt independente de tehnologiile de transport. Ea
asigură acces nerestricţionat a utilizatorilor la reţele şi
furnizori de servicii competitivi şi/sau la servicii la alegerea sa,
capabilă să susţină mobilitate generalizată, conducînd astfel
la furnizarea consistentă şi în mod independent de locaţie
servicii către utilizatori [1].
5
O reţea NGN este caracterizată prin următoarele aspecte
fundamentale:
- bazată pe transfer de pachete IP pentru transportarea
tuturor tipurilor de informaţii;
- organizată pe nivele: acces/ transport,
control/semnalizare şi aplicaţii/servicii cu interfeţe deschise
între aceste nivele ;
- nivelul de control/semnalizare separat de la nivelul de
transport/comutaţie;
- funcţiile referitor la servicii sînt independente de
tehnologiile de transport folosite ;
- suportă o gamă largă de servicii, aplicaţii şi mecanisme
bazate pe servicii în bloc, inclusiv servicii în timp real, de
striming şi multimedia;
- capabilă de transmisii de bandă largă cap-la-cap cu
asigurarea calităţii serviciilor (QoS) pentru toate tipurile de
trafic;
- convergenţa serviciilor între reţelele fixe şi mobile;
- acces nerestricţionat al utilizatorilor la diferiţi furnizori
de servicii;
- suportă multiple tehnologii de transport pe ultima milă;
- conlucrează cu reţelele existente prin interfeţe
deschise;
- mobilitate generalizată;
- o varietate scheme de identificare, care pot fi rezolvate
la adresele IP în scopul de rutare în reţele;
- tehnologii mai ieftine şi mai eficiente în comparaţie cu
tehnologiile actuale;
- conforme cu toate cerinţele de reglementare, de
exemplu în ceea ce priveşte comunicaţiile de urgenţă şi de
securitate, de confidenţialitate etc.
Uniunea Internaţională a Telecomunicaţiilor a alocat în
mod special pentru NGN seria Y.2000 şi a elaborat deja un
şir de recomandări. Primele printre acestea au fost
recomandările – Y.2001 (12/2004) „Descrierea generală a
6
reţelei NGN” şi Y.2011 (10/2004) „Principii generale şi
modelul etalon generalizat al reţelei de noua generaţie”.
Printre ultimele publicaţii ITU-T relevante din această serie la
momentul scrierii acestei lucrări sînt Y.2026(07/2012) ”
Cerinţe funcţionale şi de arhitectură a reţelei de nouă
generaţia privind sprijinul aplicaţiilor şi serviciilor în reţelele de
senzori omniprezente”, Y.2724 (11/2013) " Cadru pentru
susţinerea OAuth şi OpenID în reţele de noua generaţie ",
Y.2254 (01/14) ” Capabilităţile de multi-conectare în sprijinul
serviciilor îmbunătăţite de telefonie multimedia” şi altele.
O altă instituţie preocupată de elaborarea standardelor
pentru NGN este Institutul European pentru Standardizare în
Telecomunicaţii ETSI (European Telecommunications
Standardization Institute). ETSI determină NGN ca o reţea
funcţional stratificată cu interfeţe deschise, care permite
desfăşurarea de servicii independente de acces prin
intermediul reţelelor fixe şi mobile convergente. Este bazată
pe pachete şi utilizează protocolul internet IP pentru a
transporta diverse tipuri de trafic (voce, date, video şi
semnalizări).
Trebuie remarcat că reţelele NGN se implementează deja
de mai mulţi ani într-un şir de ţări, inclusiv şi în Republica
Moldova, astfel tehnologia nu este de fapt ”următoarea
tehnologie”, dar ea este deja una existentă. Termenul este,
totuşi, acceptat şi pe larg utilizat în domeniu.
1.2 Arhitectura NGN
Arhitectura NGN deseori se prezintă pe trei nivele

funcţionale:
1. Nivelul transport şi comutaţie.
2. Nivelul control reţea şi semnalizare.
3. Nivelul servicii, control servicii şi aplicaţii.
În mod simplificat aceste nivele sînt prezentate în figura 1.1.
7
Application Servers Servicii, control
Management Servers servicii și aplicații
API/Parlay/LDAP
SNMP
…
Softswitches Control rețea și

semnalizare
MGCP
Megaco/H.248
…
Media Gateways Transport și
comutație
API - Application Programming Interface
Fig.1.1 Arhitectura NGN
Între aceste nivele se stabilesc interfeţe standardizate,

deschise. Astfel nivelele devin independente şi se pot
dezvolta de sine stătător.
1.2.1 Nivelul transport şi comutaţie
Nivelul de transport şi comutaţie include două subnivele:

reţeaua core (nucleu, magistrală) şi reţeaua de acces (figura
1.2).
Reţeaua core este constituită din rutere magistrale (Core
Node) şi de frontieră (Edge Node) şi se bazează de regulă pe
tehnologia IP/MPLS. La nivelul fizic se utilizează fibra optică
cu sisteme de multiplexare cu divizarea densă a lungimii de
undă DWDM (Dense wavelength division multiplexing) ,
8
Ethernet sau STM-64. Comutaţia pachetelor IP se
efectuează de rutere sau switch-uri de nivelul 3. Astfel se
obţine o infrastructură cu comutaţie dispersată ceea ce este
mai eficient decît concentrarea comutaţiei în cadrul reţelelor
de conexiune ale centralelor digitale sincrone utilizate în
PSTN.
Fig. 1.2 Schema de structură a reţelei core şi de acces
Utilizatorii finali sînt conectaţi la NGN prin interfaţa

utilizator-la-reţea (UNI), în timp ce alte reţele sînt
interconectate între ele prin interfaţa reţea-la-reţea (NNI).
Reţeaua de acces include echipamentul terminal al
abonatului, linia de abonat şi nodul de acces (AN) de bandă
largă sau îngustă.
Terminalele abonaţilor pot fi aparate telefonice
convenţionale, televizor precum şi echipamente cu grad
sporit de inteligenţă bazate pe IP cum ar fi telefon SIP,
9
notebook, tabletă, smartphon, phablet, etc (figura 1.3). Liniile
de abonat pot fi pe fire de cupru, fibre optice, cablu coaxial,
frecvenţe radio, canale prin satelit sau combinarea dintre
acestea.
Fig. 1.3 Setul de terminale la edificiul abonatului
Tehnologiile utilizate pentru asigurarea accesului de bandă

largă sînt ADSL, VDSL, GPON, DVB (Digital Video
Broadcasting), WiFi, WiMAX (Worldwide Interoperability for
Microwave Access) şi altele. Cu diversificarea şi creşterea
continuă a volumului de date transmise prin reţea sînt cerute
viteze tot mai mari de conectare a punctelor terminale la
nodurile de acces. Doar un singur exemplu arată la ce viteze
se planifică să fie asigurat accesul la servicii de comunicaţii
electronice. În Agenda digitală pentru Europa (DAE), o
iniţiativă a strategiei Europa 2020 pentru o economie
inteligentă a fost stabilit obiectivul de bază ca fiecare cetăţean
european pînă în anul 2020 să fie asigurat cu acces de
bandă largă a reţelelor de noua generaţie la viteza de cel
10
puţin 30 Mbps, iar pentru 50% din gospodării - de cel puţin
100 Mbps.
În calitate de noduri de acces pot fi utilizate AGW (Access
Gateway), RAGW (Residential AGW), IAD (Integrated Access
Device), ATA (Analog Telephone Adapter) pentru conectarea
telefoanelor PSTN, iar rutere sau switch-uri pentru puncte
terminale SIP/H.323. Telefoanele convenţionale anologice
POTS TE se conectează prin două fire de cupru a/b, iar cele
digitale ISDN TE - prin interfaţa U(S/T). Nodurile de acces
existente cum sînt centralele departamentale PBX sau cu
acces în protocolul V.5 se conectează la AGW prin fluxuri
digitale E1, SHDSL sau ISDN PRA. Pentru interconectarea
centralelor CTA ale reţelei PSTN se folosesc fluxuri digitale
E1 şi TGW (Trunking Gateway). Oricare Media Gateway
asigură trecerea de la fluxurile digitale ale PSTN la fluxurile
RTP sau de semnalizare ale reţelei IP/MPLS (figura 1.4).
Fig. 1.4 Schema de structură MGW
11
1.2.2 Nivelul control reţea şi semnalizare
Controlul semnalizării de apel în NGN este efectuat de

serverul de apeluri numit Softswitch. Echipamentul
Softswitch îndeplineşte mai multe funcţii printre care:
- efectuează dirijarea unui apel în reţea pe baza
semnalizării şi a informaţiilor legate de abonat;
- controlează serviciile de interconectare pentru media
gateway şi pentru terminalele VoIP;
- permite transferul controlului apelului către un alt
element din reţea;
- păstrarea şi gestionarea datelor abonaţilor în mod
direct sau prin intermediul gateway-lui;
- şi alte funcţii de gestionare cum ar fi înregistrarea,
gestionare erori, facturarea, etc.
La acest nivel se referă şi gateway-ul de semnalizări SGW
care realizează trecerea de la sistemul de semnalizare pe
canal comun SS#7 utilizat în reţeaua cu comutaţie de circuite
SCN (Switched Circuit Network) la semnalizarea SIGTRAN
bazată pe IP a reţelei NGN.
1.2.3 Nivelul servicii, control servicii şi aplicaţii
După cum s-a menţionat anterior, în NGN funcţiile legate

de servicii sînt independente de tehnologiile de transport
utilizate. Decuplarea aplicaţiilor de reţele permite prestatorilor
de servicii elaborarea aplicaţiilor pe diferite platforme şi
furnizarea serviciilor concurenţiale în condiţii non-
discriminatorii. Nivelul servicii, control servicii şi aplicaţii este
conectat la nivelul control reţea şi semnalizare prin
intermediul unor API-uri (Application Program Interface).
Serviciile multimedia, telefonie, date (WWW, e-mail, etc) şi
video (IPTV, video la cerere, videoconferinţă, etc) pot fi punct-
punct, punct-multipunct sau multipunct-multipunct.
12
Nivelul servicii, control servicii şi aplicaţii include servere
de aplicaţii şi servere media (teleconferinţă, Interactive Voice
Response -IVR, etc). Aplicaţiile sunt încorporate în serverele
de aplicaţii dedicate acestui scop. Deseori serverele de
aplicaţii sunt completate cu servere care găzduiesc baze de
date cu conţinut adiţional (sistemul de facturare, sistemul de
administrare al reţelei, administrarea performanţei reţelei,
colecţii de video-clipuri sau de ştiri, etc.).
Împreună cu o nouă arhitectură, reţeaua de noua
generaţie aduce un nivel suplimentar de complexitate în
comparaţie cu cel al reţelelor fixe existente. În special,
suportul a multiple tehnologii de acces şi a mobilităţii
generalizate aduce la necesitatea susţinerii unei varietăţi largi
de configuraţii.
1.3 Protocoale de semnalizare în NGN
Migrarea spre NGN, după cum s-a arătat mai sus, prezintă
mai curînd un proces evoluţionist decît revoluţionar. Acest
proces evident se soldează în primul rînd cu un impact
semnificativ asupra semnalizării, deoarece semnalizarea este
punctul de pornire a evoluţiei reţelei. Reieşind din acest
considerent, în ceea ce urmează vor fi expuse principalele
protocoale de semnalizare NGN.
Semnalizarea în reţeaua de telecomunicaţii înseamnă
efectuarea unui schimb de semnale funcţionale între
echipamentele ei în scopul stabilirii, modificării, monitorizării
sau eliberării unui apel sau sesiuni de comunicare. În NGN în
acest scop se utilizează un şir de protocoale numite de
semnalizare.
În figura 1.5 se prezintă un fragment al unei reţele NGN cu
includerea principalelor elemente: două Softswitch-uri care
controlează echipamentele reţelei, gateway-ul de acces AGW
la care se conectează terminalele convenţionale ale
abonaţilor, gateway-ul de trunchiuri TGW şi cel de
13
semnalizare SGW pentru interconectarea diferitor tipuri de
reţele - NGN şi PSTN şi segmente de reţele bazate pe
protocolul SIP şi protocolul H.323 la care se conectează
terminale SIP sau H.323 respectiv. La nivelul aplicaţiilor ca
exemple sînt arătate serverul media şi serverele de aplicaţii
ce aparţin unor terţe părţi.
Fig.1.5 Fragment reţea NGN şi protocoale utilizate
Din figura 1.5 se pot observa şi tipurile de protocoale de

semnalizare şi transport ce se utilizează şi la ce segment al
reţelei se referă acestea. Astfel, pentru controlul gateway-
urilor se utilizează protocoalele H.248 sau MGCP, pentru
semnalizare apel - protocoalele SIP sau H.323, pentru
interacţiunea dintre două softswitch-uri – protocoalele SIP-T,
H 323 sau BICC, pentru transportul fluxurilor de date utilizator
– protocolul RTP/RTCP, etc.
14
Stiva de protocoale de semnalizare poate fi clasificată în
corespundere cu funcţiile sale: (i) în protocoale de dirijare
sesiune (control apel) şi (ii) protocoale de control a media
gateway-urilor AGW, TGW şi SGW (figura 1.6).
Fig.1.6 Stiva de protocoale pentru NGN
La primul tip se referă protocolul de iniţiere a sesiunii SIP

şi protocolul umbrelă H.323 care vor fi studiate mai detaliat în
cadrul acestui curs. Suita de protocoale SIGTRAN este
folosită ca metodă de transport peste IP pentru pachetele de
semnalizare pe canal comun SS7 din reţelele PSTN.
Ca exemple de protocoale de control a media gateway sînt
aduse protocolul H.248, numit şi MEGACO, şi protocolul
MGCP. Protocolul MGCP este substituit treptat de protocolul
H.248 şi de aceea în continuare nu se examinează.
La nivelul de transport sînt indicate protocoalele pe care
rulează protocoalele de semnalizare enumerate. Acestea sînt
protocoalele de transport bine cunoscute UDP, TCP, dar şi
15
protocolul de transport cu controlul fluxului de date SCTP
(Stream Control Transmission Protocol). Pentru comparaţie,
pe figură se arată şi locul unde în această arhitectură se
situează protocolul de transport în timp real RTP cu ajutorul
căruia se efectuează transmisia informaţiei media cum ar fi
vocea, video sau alt tip de date în timp real.
2. PROTOCOLUL DE INIŢIERE A SESIUNII SIP
Protocolul de iniţiere a sesiunii SIP (Session Initiation

Protocol) a fost elaborat în cadrul Grupului operativ de
inginerie a internetului (Internet Engineering Task Force -
IETF) şi publicat pe 270 de pagini ale standardului RFC 3261
[2] în iunie 2002. Iniţial SIP a fost definit de standardul RFC
2543 în anul 1999.
Protocolul SIP se atribuie nivelului aplicaţiilor şi asigură
crearea, modificarea sau încheierea sesiunilor de comunicare
multimedia cu unul sau mai mulţi participanţi. Conceptul de
sesiune a fost introdus pentru prima dată de protocolul de
descriere a sesiunii SDP în RFC 2327 ca un schimb de fluxuri
de date multimedia între participanţi. Ca exemple de sesiune
pot servi apelul telefonic, conferinţa video, controlul de la
distanţă al unui calculator, schimbul de date între utilizatori,
chatul, schimbul instantaneu de mesaje etc.
Într-o sesiune SIP este posibilă, de asemenea, suplinirea
numărului participanţilor la sesiunile deja în desfăşurare, de
exemplu, în cadrul unei conferinţe multicast. Deşi protocolul
SIP nu efectuează el însăşi transportul fluxurilor media (acest
rol îi revine protocolului RTP), totuşi SIP-ul permite ca aceste
fluxuri media să fie adăugate sau îndepărtate de la o sesiune
existentă. O calitate importantă a acestui protocol este
admiterea aşa- numitei mobilităţi personale. Aceasta
înseamnă că utilizatorul SIP poate accesa reţeaua oriunde,
indiferent de locaţie, fiind identificat prin unul dintre SIP URI-
urile (identificator uniform de resurse) sale.
16
Protocolul SIP nu este un sistem de comunicare integrat
pe verticală. El este mai degrabă o componentă care poate fi
utilizată de comun cu alte protocoale IETF pentru a construi o
arhitectură multimedia completă. În mod tipic această
arhitectură include aşa protocoale, cum ar fi SDP (RFC 4566
[3]) pentru descrierea sesiunii multimedia, RTP (RFC 3550),
pentru transportul de date în timp real şi furnizarea feedback-
ului pentru asigurarea calităţii QoS, RTSP (RFC 2326) pentru
a controla livrarea de media streaming şi H.248 pentru
controlul gateway-urilor la PSTN. Prin urmare, SIP se
utilizează în asociere cu alte protocoale pentru a furniza
servicii complete utilizatorilor. Totuşi, funcţionarea SIP nu
depinde de oricare dintre aceste protocoale.
2.1 Componentele funcţionale ale reţelei SIP
O reţea bazată pe protocolul SIP include pînă la patru

componente funcţionale:
Agent utilizator (UA - User Agent)
Server Registrator
Proxy Server
Server Redirecţionare
Agentul utilizator UA este entitate logică care poate activa
în calitate de agent utilizator client UAC sau agent utilizator
server UAS.
Agentul utilizator client UAC este o aplicaţie care iniţiază
noi cereri, iar agentul utilizator server UAS este o aplicaţie
care răspunde la cereri. Rolul de client sau server al UA se
menţine doar pe durata tranzacţiei. Deci, dacă aplicaţia
răspunde la cerere ea joacă rolul de agent utilizator server cît
durează tranzacţia, iar dacă mai tîrziu ea generează o cerere
atunci îşi asumă rolul de agent utilizator client la procesarea
noii tranzacţii. De exemplu, pentru a iniţia o sesiune UAC al
apelantului trimite un mesaj de invitaţie INVITE care este
primit de UAS al solicitatului. Pe de altă parte, pentru a
17
termina sesiunea, aplicaţia celui apelat deja în rolul de UAC
transmite un mesaj de eliberare BYE care este primit de către
UAS al apelantului. Exemple de dispozitive ale reţelei SIP care
au funcţionalitatea de UAC şi UAS sînt telefonul SIP,
calculatorul, PDA-ul, gateway-ul, robotul telefonic, agentul de
apel, etc.
Serverul Registrator este o bază de date care indică locaţia
tuturor agenţilor utilizatori UA din domeniu. Acesta acceptă
cererile de înregistrare REGISTER de la UA şi menţine mai
multe tipuri de adrese SIP URI pentru fiecare utilizator.
Registratorul indică, de asemenea, adresa curentă ca prima
prioritate de la care utilizatorul doreşte să trimită cererea şi la
care să primească răspunsul. Deseori serverul Registrator este
plasat împreună cu serverul Proxy pentru acest domeniu.
Agentul utilizator poate înregistra mai multe dispozitive. Spre
exemplu, un telefon SIP la oficiu şi altul la domiciliu. În acelaşi
timp pe un singur aparat pot fi înregistraţi mai mulţi utilizatori.
Proxy serverul este o entitate intermediară care acţionează şi
ca server, şi ca client în scopul de a face cereri în numele altor
clienţi. Serverul proxy primeşte cereri de iniţiere a sesiunii făcute
de la UAC şi interogează Serverul Registrator pentru a obţine
adresa curentă a destinatarului (UAS). Apoi, înaintează invitaţia
la sesiune direct la UAS solicitat, dacă el este situat în acelaşi
domeniu, sau la un alt server Proxy, în cazul în care UAS are
reşedinţa într-un alt domeniu.
Serverul Redirecţionare este folosit pentru a furniza adrese
alternative pentru o cerere. Pot exista mai multe motive pentru
care acest lucru ar fi de dorit. De exemplu, operatorul de reţea
poate dori să trimită adrese alternative de rutare a unei cereri ca
un mijloc de partajare a sarcinii atunci cînd Proxy serverul este
supraîncărcat.
Este important să se înţeleagă că o entitate SIP nu este un
”obiect” fizic. Entităţile SIP sînt logice. Serverele enumerate mai
sus sînt entităţi funcţional distincte, dar ele pot fi realizate pe
acelaşi hardware.
18
2.2 Structura mesajelor SIP
Protocolul SIP se bazează pe text şi utilizează setul de

caractere ISO 10646 în codificarea UTF-8 (RFC 2279). El a
fost derivat din Protocolul de Transfer Hypertext (HTTP -
Hypertext Transfer Protocol) dar nu este o extensie a
ultimului. SIP se bazează pe tranzacţii cerere / răspuns.
Fiecare tranzacţie constă dintr-o cerere SIP (care va fi una
din mai multele metode - cereri) şi cel puţin un răspuns.
Un mesaj SIP este fie o cerere de la un client UAC la un
server UAS, sau un răspuns de la un server la un client.
Mesajul este format din trei părţi (fig.2.1): linia de start,
anteturile şi conţinutul (corpul).
Linia de start
Anteturile
Linie goală (CRLF)*
Conţinutul(corpul)
*) Linia de start, fiecare antet şi linia goală trebuie să fie

terminată cu CRLF (Carriadge Return, Line Feed). Linia goală
trebuie să fie prezentă chiar dacă Conţinutul (corpul) nu este.
Fig. 2.1 Mesajul SIP
1) Linia de start
Fiecare mesaj începe cu linia de start. Cu ea începe sau
mesajul - Cerere, sau mesajul - Răspuns după cum urmează:
Linia - Cerere include tipul cererii, adresa URI, care
indică utilizatorul sau serviciul la care se adresează această
19
solicitare şi versiunea SIP. Fiecare element este separat
printr-un singur caracter SP (spaţiu gol).
Tip cerere SP Adresa destinaţie SP Versiune SIP
(Method SP Request-URI SP SIP-Version)
Linia - Răspuns este o linie de stare. Ea constă din
versiunea protocolului urmată de un cod numeric şi o frază
textuală asociată cu acest cod de răspuns. Fiecare element
este separat printr-un singur caracter SP.
Versiune SIP SP Cod răspuns SP Descrierea textuală
(SIP-Version SP Status-Code SP Reason-Phrase)
2) Anteturile
Cîmpurile anteturi SIP sînt folosite pentru a transmite
atributele mesajului. Ele conţin informaţii detaliate despre
cerere sau răspuns care includ, de exemplu, adresele de
destinaţie şi de iniţiere, informaţii de rutare etc. Antetul SIP
este similar în sintaxă şi semantică cu antetul protocolului
HTTP (unele antete sînt de fapt împrumutate de la HTTP).
Antetul poate să includă mai multe linii. Unele anteturi SIP,
cum ar fi Via, Contact, Route, pot apărea de mai multe ori
într-un mesaj sau, alternativ, pot lua mai multe valori separate
prin virgulă într-un singur antet.
3) Conţinutul (corpul)
Corpul mesajului este utilizat pentru descrierea sesiunii
iniţiate utilizînd protocolul SDP sau MIME (Multipurpose
Internet Mail Extensions). De exemplu, într-o sesiune
multimedia aceste informaţii includ tipurile de codecuri audio
şi video folosite, ratele de discretizare sau orice alt text sau
date binare care descriu cumva sesiunea. Protocolul SIP face
o distincţie clară între informaţiile de semnalizare, incluse în
linia de start, şi cîmpurile anteturi, pe de o parte, şi
informaţiile ce descriu sesiunea, care sînt în afara domeniului
de aplicare a SIP, pe de altă parte.
20
2.3 Cereri SIP
În specificaţia RFC 3261 sînt definite şase tipuri de cereri

numite metode (methods): REGISTER pentru înregistrarea
de informaţii de contact; INVITE, ACK şi CANCEL pentru
crearea de sesiuni; BYE pentru terminarea sesiunilor şi
OPTIONS pentru interogarea serverelor cu privire la
capabilităţile lor. Ulterior prin alte RFC au fost definite
metode suplimentare (tabelul 2.1). În tabel se aduce
descrierea specificaţiei şi se indică numărul RFC prin care ea
a fost definită şi luna/anul publicării.
Tabelul 2.1 Lista metode/cereri SIP

Cererea Descrierea RFC
INVITE Stabileşte o sesiune între 3261/06.2002
participanţi. * şi
6026/09.2010
ACK Confirmare transmisă ca 3261
răspuns la cererea INVITE.
CANCEL Anulează o tranzacţie în 3261
aşteptare la care încă nu
este primit răspunsul final.
INFO Oferă un mecanism de 6086/01.2011

transport a informaţiei de
nivelul aplicaţiilor care
poate îmbunătăţi o
aplicaţie SIP (DTMF, GPS
locaţie).
21
Tabelul 2.1 (continuare)
1 2 3
BYE Încheie o sesiune. 3261
MESSAGE Transferuri de mesaje 3428/12.2002
instant între utilizatori
aproape în timp real.
Transferul mesajelor
înainte şi înapoi este
suficient de rapid pentru
ca participanţii să menţină
o conversaţie interactivă.
NOTIFY Informează un abonat cu 6665/06.2012

privire la schimbarea de
stare a resursei (s-a
petrecut un eveniment
pentru care s-a cerut
confirmare).
OPTIONS Interoghează serverul cu 3261
privire la capabilităţile sale.
PRACK Similar cu ACK, însă 3262/06.2002
pentru transmitere fiabilă a
răspunsurilor provizorii.
PUBLISH Similar cu REGISTER în 3903/10.2004
ceea ce priveşte
posibilitatea unui utilizator
să creeze, modifice şi să
elimine o stare într-o altă
entitate care gestionează
această stare în numele
utilizatorului.
22
1 2 3
REFER Indică faptul că 3515/04.200
destinatarul trebuie să 3
contacteze o terţă parte,
folosind informaţiile de
contact furnizate în cerere.
REGISTER Înregistrează informaţii de 3261
contact.
SUBSCRIBE Cereri de stare curentă şi 6665/06.201
actualizări de stare de la 2
un nod distant.
UPDATE Actualizează parametrii 3311/
unei sesiuni. 09.2002
*) RFC 3261 a înlocuit specificaţia anterioară RFC 2543 din

martie 1999.
Mai jos este dată descrierea mai detaliată a fiecărei cereri

în parte. Pentru o studiere mai profundă se poate consulta
RFC-ul corespunzător, indicat în coloniţa 3 a tab.2.1.
Metoda INVITE indică faptul că utilizatorul este invitat să
participe la o sesiune. Corpul mesajului conţine o descriere a
sesiunii la care apelantul este invitat. Pentru un apel dintre
doi abonaţi în pereche (punct-punct), apelantul indică tipul de
media/informaţiei, care el este capabil s-o primească şi,
eventual, parametrii fluxului media pe care-i va transmite.
Dacă invitaţia se acceptă atunci cel apelat indică în corpul
mesajului tipul media pe care el, la rîndul său, poate
recepţiona şi transmite.
Metoda ACK confirmă că clientul a primit răspuns final la o
cerere INVITE. Este posibil ca cererea să conţină corpul
mesajului cu descrierea finală a sesiunii pentru a fi utilizată de
cel apelat. În cazul în care corpul mesajului ACK este gol,
23
atunci apelatul foloseşte descrierea sesiunii date în cererea
INVITE.
Metoda CANCEL anulează o cerere în curs cu aceleaşi
valori de identificare în cîmpul antetului, dar nu afectează o
cerere completată . O cerere se consideră completată dacă
serverul a returnat un răspuns final de stare.
Metoda INFO este folosită pentru a transporta informaţii
care nu schimbă starea apelului. Scopul cererii INFO este a
transporta informaţii de nivelul aplicaţiilor între agenţii
utilizatori SIP. Datele aplicaţiei se transferă în cadrul datelor
utile ale corpului mesajului INFO. De exemplu, în protocolul
SIP-T (telefonie) astfel sînt transmise informaţiile de
semnalizare ISUP. Mesajele INFO diferă de alte mesaje SIP
deoarece ele transportă informaţiile aplicaţiilor şi de aceea
dimensiunea şi rata mesajelor este direct determinată de
aplicaţie. Unele aplicaţii, cum ar fi trimiterea tonurilor DTMF,
pot genera o explozie de pînă la 20 de mesaje pe secundă.
Alte aplicaţii, cum ar fi actualizări constante de localizare
GPS, ar putea genera o rată mare de cereri INFO pe durata
utilizării dialogului INVITE.
Cererea BYE se utilizează de UAC sau de UAS pentru a
informa cealaltă parte a dialogului despre încheierea sesiunii.
Un UA care primeşte o cerere BYE în cadrul unui dialog
existent trebuie să termine sesiunea încetînd să trimită şi să
primească fluxuri media.
Metoda MESSAGE este utilizată pentru expedierea de
mesaje instant similar cu trimiterea SMS de la un telefon
celular sau de la un pager bidirecţional. Cererile MESSAGE
în mod normal transportă conţinutul mesajului instant în
corpul MIME (Multipurpose Internet Mail Extensions) al
cererii. Dimensiunile datelor mesajului nu trebuie să
depăşească 1300 bytes pentru a evita problemele cu
segmentarea SIP. Pentru a nu admite congestii se cere ca
clienţii să nu trimită o nouă cerere MESSAGE pînă ce nu vor
primi confirmarea de primire la cea anterioară.
24
Metoda SUBSCRIBE este utilizată pentru a solicita
informaţii despre starea curentă sau schimbarea de stare a
unei resurse de la un nod distant. Exemple de servicii care
folosesc cererea SUBSCRIBE sînt callback automat (bazat
pe evenimentele de stare a terminalului), lista prietenilor
(bazată pe evenimentele de prezenţă a utilizatorului),
indicarea mesajelor în aşteptare (bazată pe evenimentele de
schimbare de stare a cutiei poştale). Conceptul general este
că entităţile reţelei se pot abona/subscrie la urmărirea stării
resursei sau a apelului în reţea. Ca urmare, aceste entităţi
vor transmite notificări la schimbarea de stare a resursei,
apelului. În cerere se indică durata subscrierii. În scopul
prelungirii abonării este nevoie de actualizarea periodică a
subscrierii utilizînd noi cereri SUSCRIBE.
Metoda NOTIFY este transmisă pentru informarea
utilizatorilor despre evenimentele de schimbare de stare la
care abonaţii s-au subscris. Subscrierile sînt create folosind
metoda SUBSCRIBE. După acceptarea cererii de subscriere
notificatorul trebuie să trimită imediat cererea NOTIFY pentru
a comunica abonatului care este starea curentă a resursei.
Această cerere NOTIFY este trimisă în cadrul dialogului
creat de cererea SUBSCRIBE.
Metoda OPTIONS permite unui UA a interoga un alt UA
sau un server Proxy despre capabilităţile sale. Aceasta
permite clientului UAC să determine metodele acceptate,
tipurile de conţinut, extensii, codec-uri etc. ale UAS fără a
"apela" cealaltă parte. De exemplu, dacă un client nu este
sigur de opţiunile suportate de UAS el îl poate interoga pe
ultimul cu o cerere OPTIONS înainte de a transmite cererea
INVITE. Listarea de opţiuni primită de la serverul de
destinaţie va fi returnată în cîmpul antetului Supported al
cererii INVITE. Toţi agenţii utilizatori UA trebuie să suporte
metoda OPTIONS.
Metoda PRACK (Provisional Response
ACKnowledgement method) se foloseşte pentru transmiterea
25
fiabilă a răspunsurilor provizorii. Protocolul SIP defineşte
două tipuri de răspunsuri, provizorii şi finale.
Răspunsurile finale se referă la rezultatul prelucrării cererii
şi sînt transmise în mod fiabil. Pe cînd răspunsurile provizorii
oferă informaţii cu privire la cererea în progres şi se transmit
conform RFC 3261 în mod nefiabil. Mai tîrziu însă s-a
observat că fiabilitatea în mai multe cazuri este importantă şi
pentru un răspuns provizoriu, inclusiv pentru a asigura
interoperabilitatea cu PSTN. De aceea în RFC 3262 a fost
propusă o metodă suplimentară PRACK pentru a sprijini o
transmisie fiabilă a răspunsurilor provizorii.
Metoda REGISTER este folosită de clienţii SIP pentru a
înregistra locaţia lor curentă (una sau mai multe adrese de
contact URI) şi asocierea lor cu o adresă publică ("adresa de
înregistrare" în terminologia IETF şi "identitate publică" în
terminologie 3GPP). Serverul SIP, care acceptă aceste
cereri, se numeşte registrator (Registrar).
Metoda PUBLISH este similară cu REGISTER în ceea ce
priveşte posibilitatea unui utilizator să creeze, modifice şi
elimine o stare într-o altă entitate care gestionează această
stare în numele utilizatorului. De exemplu, o aplicaţie de
evenimente SIP pentru indicarea mesajelor în aşteptare ar
putea folosi mecanismul PUBLISH pentru colectarea stărilor
cutiilor poştale şi de voce dintre un set de agenţi utilizatori.
Metoda este folosită pentru înregistrarea de stare a
evenimentului la entitatea responsabilă de colectare a acestor
evenimente.
Metoda REFER indică faptul că destinatarul trebuie să
contacteze o terţă parte, folosind informaţiile de contact
furnizate în cerere. De exemplu, aceasta poate fi utilizată
pentru transferul apelului.
Metoda UPDATE permite unui client să actualizeze
parametrii sesiunii (cum ar fi tipul fluxurilor media şi codec-
urile lor), dar nu are nici un impact asupra stării dialogului.
Este similar cu re-INVITE dar, spre deosebire de aceasta,
26
poate fi transmis înainte de a fi primit răspuns la cererea
INVITE precedentă. Exemplu. Un apelant trimite o cerere
iniţială INVITE, care conţine o ofertă. Cel apelat generează
un răspuns la această ofertă. Odată cu finalizarea schimbului
de cerere /răspuns, sesiunea este stabilită, doar că dialogul
este încă în stare timpurie. Apelantul decide să actualizeze
unele aspecte ale sesiunii, de exemplu, să treacă în
aşteptare/on hold. Deci, el generează o cerere UPDATE, cu o
nouă ofertă.
2.4 Răspunsuri SIP
Linia de stare a răspunsului conţine un cod (Status-Code)

compus din trei cifre şi o frază textuală asociată cu acest cod
de răspuns. Codul indică rezultatul încercării serverului să
înţeleagă şi să satisfacă o cerere. Cifrele codului sînt
destinate utilizării de automate, în timp ce partea textuală ce
oferă o scurtă descriere a codului numeric este destinată
utilizatorului uman. Codurile sînt în concordanţă cu codurile
de răspuns HTTP/1.1, însă sînt mai extinse. Răspunsurile
SIP sînt de două tipuri şi şase clase. Cele mai multe
răspunsuri (2xx, 3xx, 4xx, 5xx, şi 6xx) sînt "finale" şi termină
tranzacţia SIP curentă. Răspunsurile 1xx sînt "provizorii" şi nu
termină tranzacţia SIP. Clasa răspunsului este determinată
de prima cifră a codului. Protocolul SIP/2.0 admite şase valori
pentru prima cifră, deci şase clase:
1xx: Provizoriu – cererea este primită şi este în curs de
procesare (caută, apelează, aşteaptă, etc.);
2xx: Succes – cererea a fost recepţionată, este înţeleasă şi
acceptată;
3xx: Redirecţionare – sînt necesare acţiuni suplimentare
pentru a completa cererea;
4xx: Eroare client – cererea conţine greşeli sintactice sau
nu poate fi procesată de acest server;
27
5xx: Eroare server – serverul nu a reuşit să proceseze
cererea aparent validă;
6xx: Eroare globală – cererea nu poate fi îndeplinită la
orice server.
Mai jos se aduc cîteva exemple de răspunsuri dintre cele
mai des utilizate cu explicaţiile de rigoare.
Provizorii 1xx:
Răspunsurile provizorii, cunoscute şi ca informaţionale,
indică că serverul contactat efectuează unele acţiuni
suplimentare şi nu are încă un răspuns definitiv. Serverul
transmite răspuns 1xx dacă se aşteaptă ca obţinerea unui
răspuns final va dura mai mult de 200 ms. Răspunsurile
provizorii nu sînt transmise în mod fiabil.
100 Trying
Răspunsul indică că cererea a fost primită de server, dar
sînt necesare careva acţiuni suplimentare (de exemplu,
consultarea bazei de date).
180 Ringing
Agentul utilizator a primit cererea IVITE şi apelează
utilizatorul solicitat.
Succes 2xx:
Cererea a fost recepţionată cu succes, este înţeleasă şi
acceptată.
220 OK
Cererea este procesată cu succes. Informaţiile returnate în
corpul răspunsului depind de metoda utilizată în cerere.
Redirecţionare 3xx:
Răspunsurile 3xx oferă informaţii despre noua locaţie a
utilizatorului sau despre serviciile alternative care ar putea fi
în măsură să satisfacă cererea.
301 Moved Permanently
Utilizatorul nu mai poate fi găsit la adresa indicată în
cerere (Request-URI) şi, ca urmare, clientul trebuie să
încerce cu noua adresă indicată în cîmpul antetului de
contact. Solicitantul trebuie să actualizeze orice directoare
28
locale, agende şi cache-uri de localizare a utilizatorului cu
această nouă valoare. Pe viitor cererile vor fi direcţionate la
adresa (adresele) nouă.
302 Moved Temporarily
Clientul solicitant trebuie să încerce din nou să transmită
cererea dar la altă adresă (adrese) indicată în cîmpul
antetului Contact. Dacă durata de validitate a noii adrese nu
este arătată, atunci ea este validă doar pentru acest caz.
Eroare client 4xx:
Răspunsurile 4xx sînt definite ca un eşec al unei cereri la
un anumit server. Clientul nu trebuie să încerce din nou să
transmită aceeaşi cerere fără a o modifica.
400 Bad Request
Cererea nu poate fi înţeleasă ca urmare a sintaxei
incorecte. În răspuns se expun motivele mai în detaliu, de
exemplu, ”este absent cîmpul antetului Call-ID”.
401 Unauthorized
Cererea trebuie să conţină autentificarea utilizatorului.
Acest răspuns este emis de agenţii utilizatori server UAS şi
serverul Registrator, în timp ce serverele Proxy folosesc în
acest sens răspunsul 407 (Proxy autentificare necesară).
403 Forbidden
Serverul a înţeles cererea, dar refuză s-o îndeplinească.
Autorizarea nu va ajuta şi cererea nu trebuie repetată.
405 Not Found
Serverul are informaţii definitive că utilizatorul nu există în
domeniul specificat în cerere.
408 Reguiest Timeout
Serverul nu ar reuşi să producă un răspuns într-un timp
corespunzător, de exemplu dacă nu a reuşit să determine
locaţia utilizatorului la timp. Clientul poate repeta cererea fără
a o modifica oricînd mai tîrziu.
29
415 Unssuported Media Type
Serverul refuză să deservească cererea, deoarece corpul
mesajului cererii este într-un format care nu este suportat de
către server pentru metoda solicitată.
480 Temporarily Unavailable
Sistemul terminal al celui apelat a fost contactat cu succes,
dar solicitantul nu este disponibil pentru moment (de
exemplu, a activat funcţia "Nu deranjaţi", nu este logat; logat,
dar într-o stare care împiedică comunicarea cu el).
Eroare server 5xx:
Răspunsurile 5xx comunică despre eşecul serverului
atunci cînd serverul însuşi a comis o eroare.
500 Server Internal Error
Serverul a întîmpinat o condiţie neaşteptată care a
împiedicat îndeplinirea cererii. Dacă această stare este
temporară, serverul va indica cînd clientul poate încerca din
nou cererea folosind cîmpul antetului Retry-After.
503 Service Unavailable
Serverul este temporar în incapacitatea de a procesa
cererea din cauza suprasolicitării sau lucrărilor de întreţinere
a serverului.
504 Server Time-out
Serverul nu a primit un răspuns în timp oportun de la un
server extern, accesat în încercarea de a procesa cererea.
Eroare globală 6xx:
Răspunsurile 6xx indică faptul ca un server are informaţii
definitive cu privire la un anumit utilizator, nu doar pe cazul
particular de adresă URI indicată în cerere.
600 Busy Everywhere
Sistemul final solicitat a fost contactat cu succes, dar cel
apelat este ocupat şi nu doreşte să preia apelul în acest
moment.
603 Decline
Sistemul final solicitat a fost contactat cu succes, dar
utilizatorul în mod explicit nu doreşte sau nu poate participa.
30
Lista completă a răspunsurilor SIP, la data scrierii acestei
lucrări (martie 2014), cu indicarea standardului RFC prin care
tipul dat de mesaj a fost adoptat, este dată în tabelul 2.2.
Tabelul 2.2 Lista codurilor de răspunsuri SIP

Cod Descrierea textuală Referinţă
răspuns
1xx Provisional
100 Trying [RFC3261]*
180 Ringing
181 Call Is Being Forwarded
182 Queued
183 Session Progress
199 Early Dialog Terminated [RFC6228]
2xx Successful
200 OK
202 Accepted (Deprecated) [RFC6665]
204 No Notification [RFC5839]
3xx Redirection
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
305 Use Proxy
380 Alternative Service
4xx Request Failure

400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
31
1 2 3
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
410 Gone
412 Conditional Request Failed [RFC3903]
413 Request Entity Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Unsupported URI Scheme
417 Unknown Resource-Priority [RFC4412]
420 Bad Extension
421 Extension Required
422 Session Interval Too Small [RFC4028]
423 Interval Too Brief
424 Bad Location Information [RFC6442]
428 Use Identity Header [RFC4474]
429 Provide Referrer Identity [RFC3892]
430 Flow Failed [RFC5626]
433 Anonymity Disallowed [RFC5079]
436 Bad Identity-Info [RFC4474]
437 Unsupported Certificate [RFC4474]
438 Invalid Identity Header [RFC4474]
439 First Hop Lacks Outbound [RFC5626]
Support
440 Max-Breadth Exceeded [RFC5393]
469 Bad Info Package [RFC6086]
470 Consent Needed [RFC5360]
480 Temporarily Unavailable
481 Call/Transaction Does Not
Exist
482 Loop Detected
32
1 2 3
483 Too Many Hops
484 Address Incomplete
485 Ambiguous
486 Busy Here
487 Request Terminated
488 Not Acceptable Here
489 Bad Event [RFC6665]
491 Request Pending
493 Undecipherable
494 Security Agreement Required [RFC3329]
5xx Server Failure

500 Server Internal Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Server Time-out
505 Version Not Supported
513 Message Too Large
580 Precondition Failure [RFC3312]
6xx Global Failures

600 Busy Everywhere
603 Decline
604 Does Not Exist Anywhere
606 Not Acceptable
*)Pentru răspunsurile la care specificaţia nu este indicată se

subînţelege implicit standardul RFC3261 [2].
33
2.5 Anteturi SIP
Cîmpurile anteturilor SIP conţin informaţii detaliate despre
cerere sau răspuns. Acestea includ adresele de destinaţie şi
de iniţiere a cererii, precum şi informaţiile de rutare. Cîmpurile
anteturilor sînt compuse din nume şi valoare care sînt
separate prin două puncte (":"):
field-name: field-value
În cîmpul nume se scrie numele antetului, de exemplu,
dintre cele din tabelul 2.3. Cîmpul valoare este text codificat
în UTF-8 sau combinaţie de expresii simbolice (token-uri),
spaţiu gol, caractere de separare şi şiruri de caractere închise
în ghilimele. Cele mai multe anteturi existente urmează un
format comun pentru cîmpurile valori. Ele sînt bazate pe
secvenţa de perechi ”nume-parametru= valoare-parametru”,
care se divizează prin simbolul punct şi virgulă ”;”:
field-name: field-value *(;parameter-name=parameter-value)
De exemplu:
Contact: <sip:alice@atlanta.com>;expires=3600
Parametrii cîmpului de antet SIP şi valorile acestora
trebuie să fie documentate într-un RFC pentru a fi înregistrate
de către autoritatea IANA. Această documentaţie trebuie să
explice pe deplin sintaxa, modul de utilizare şi semantica
parametrului sau a valorii parametrului. Intenţia acestei
cerinţe este a asigura interoperabilitatea între implementări
independente şi pentru a preveni coliziunile de nume.
Cea mai mare parte din cîmpurile de antet SIP pot fi
extinse prin definirea de noi parametri. Noii parametri de antet
SIP sînt înregistraţi de către IANA [4].
Anteturile SIP se împart în patru categorii: comune (cerere
şi răspuns), de cerere, de răspuns şi de conţinut. Anteturile
din categoria comune, pot fi utilizate atît pentru cerere cît şi
pentru mesajele de răspuns. Denumiri de anteturi comune,
pentru cereri şi pentru mesaje răspuns, sînt prezentate în
tabelul 2.3.
34
Tabelul 2.3 Anteturi SIP [2]
Cerere &
Cerere Răspuns
Răspuns
Accept Authorization Proxy-
Authenticate
Accept-Encoding In-Reply-To Retry-After
Accept-Language Max-Forwards Server
Allow Priority Unsupported
Call-ID (i) Proxy-Authorization Warning
Contact (m) Proxy-Require WWW-
Authenticate
Cseq Require
Date Route
Expires Subject (s)
From (f) User-agent
Record-Route
Timestamp
To (t)
Via (v)
Exemple de anteturi de conţinut sînt: Content-encoding,
Content-length, Content-type.
Lista actualizată a anteturilor SIP poate fi consultată pe
site-ul IANA [4].
Protocolul SIP prevede un mecanism care permite
reprezentarea într-o formă prescurtată a numelui comun de
35
cîmp de antet. Aceasta ar putea fi utilă atunci cînd mesajele
devin prea mari pentru a fi transmise cu transportul de care
dispune (de exemplu, mai mare de unitatea maximă de
transmisie (MTU) atunci cînd se utilizează protocolul UDP).
Numele de antet poate apărea în forme atît lungi, cît şi scurte
în acelaşi mesaj. Implementările trebuie să accepte ambele
forme ale fiecărui nume de antet.
Tabelul 2.4 Forma abreviată a anteturilor

Nume antet (Formatul lung) Formatul
Compact
Accept-Contact a
Allow-Event u
Call-ID i
Contact m
Content-Encoding e
Content-Length l
Content-Type c
Event o
From f
Identity y
Identity-Info n
Refer-To r
Referred-By b
Reject-Contact j
Request-Disposition d
Session-Expires x
Subject s
Supported k
To t
Via v
În cele ce urmează, mai detaliat, sînt expuse doar unele

dintre cele mai des utilizate anteturi. La necesitate, descrierea
anteturilor SIP se poate consulta în specificaţiile RFC.
36
Numărul RFC-ului pentru fiecare antet SIP este dat în
registrul IANA [4].
Accept. Cîmpul antetului inclus în cerere (antet- cerere)
poate fi folosit pentru a specifica anumite tipuri de media care
sînt acceptabile pentru răspuns. Antetul Accept poate fi
utilizat pentru a indica faptul că cererea este limitată în mod
specific la un set mic de tipuri dorite.
Exemplu: Accept: audio/*; q=0.2, audio/basic
Exemplul ar trebui interpretat ca "prefer audio / de bază,
însă poţi trimite orice tip audio dacă este cel mai disponibil,
dar va urma o cădere în calitate de 80%." Simbolul asterisc
indică că se acceptă orice subtip de media de tipul audio.
Factorul de calitate q permite agentului utilizator să indice
gradul relativ de preferinţă pentru clasa media, folosind scala
de valori q de la 0 pînă la 1. Dacă parametrul de calitate are
valoarea 0, aceasta înseamnă că conţinutul este
”neacceptabil" pentru client. Valoarea implicită este q=1.
Alte exemple.
Accept: application/sdp Este implicit dacă nu este
prezent antetul Accept.
Accept. Text/* Se acceptă orice schemă de codare text.
Accept: application/h.245;q=0.1, application/sdp;q=0.9 Să
se utilizeze SDP, dacă este posibil, dacă nu - atunci H.245.
Accept –Language. Cîmpul de antet Accept-Language
este utilizat în cereri pentru a indica limbile preferate pentru
expunerile de motive sau în descrierea sesiunii, sau în
răspunsuri de stare ca descriere în corpul mesajului. Dacă
antetul Accept-Language nu este prezent, atunci serverul
trebuie să asume că toate limbile sînt acceptabile pentru
client.
Exemplu.
Accept-Language: ro, en-gb;q=0.8, en;q=0.7
Allow. În cîmpul antetului Allow se listează setul de
metode care sînt susţinute de UA, care generează mesajul.
Includerea antetului Allow în răspunsurile la cereri, cu
37
excepţia metodei OPTIONS, reduce numărul de mesaje
necesare.
Exemplu:
Allow: IVITE, ACK, OPTIONS, CANCEL, BYE
Call-ID. Cîmpul de antet Call-ID este obligatoriu în toate
cererile şi răspunsurile SIP. Acest antet este folosit pentru a
identifica în mod unic un apel între doi agenţi utilizatori. Call-
ID-ul trebuie să fie un identificator aleatoriu criptografic.
Caracterul aleatoriu al Call-ID-ului împiedică o terţă parte să
ghicească întîmplător sau intenţionat Call-ID-ul şi să prezinte
cereri false. Call-ID este întotdeauna creat de agentul
utilizator şi nu este modificat de careva server.
Forma compactă a cîmpului antetului Call-ID-ul este i.
Exemple:
Call-ID:f81d4fae-7dec-11d0-a765 00a0c91e6bf6@biloxi.com
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4
Contact. Valoarea cîmpului antetului Contact oferă un URI al
cărui semnificaţie depinde de tipul de cerere sau de răspuns
în care este inclus. O valoare de cîmp antet poate conţine un
nume de afişare, un URI cu parametri şi parametri de antet.
În cazul în care valoarea cîmpului antet conţine un nume de
afişare, URI şi toţi parametrii URI se includ între "<" şi ">". În
cazul în care aceste simboluri "<" şi ">" nu sînt prezente, toţi
parametrii după URI sînt parametri de antet, dar nu parametri
URI.
Există doi parametri suplimentari definiţi pentru utilizare în
cîmpurile antetului Contact: q şi expires. Ele se plasează la
sfârşitul URI şi se separă prin virgulă. Parametrul valoare q
este utilizat pentru a indica preferinţa relativă, reprezentată de
un număr zecimal în intervalul 0 pînă la 1. Parametrul expires
indică cît timp URI este valabil şi este folosit doar la
înregistrări. Parametrul conţine un număr întreg de secunde
sau o dată în formă SIP.
Forma compactă a cîmpului antetului Contact este m (de la
"moved").
38
Exemplu:
Contact: "Mr. Watson" <sip:watson@worcester.bell-
elephone.com>
;q=0.7; expires=3600,
"Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
Cseq. Cîmpul de antet Cseq (Comand Sequence - Secvenţă
comandă) este necesar în fiecare cerere şi conţine un număr
de secvenţă urmat de numele cererii. Numărul de secvenţă
începe cu orice valoare arbitrară care creşte cu 1 pentru
fiecare cerere şi trebuie să fie un întreg fără semn în
diapazonul de la 1 pînă la . Antetul CSeq serveşte la
comanda operaţiunilor într-un dialog, pentru a oferi un mijloc
de a identifica în mod unic tranzacţia şi a diferenţia cererea
nouă de cererea retransmisă. Antetul Cseq al răspunsului la o
cerere este copia valorii cîmpului antetului CSeq din cererea
respectivă.
Exemplu:
CSeq: 4711 INVITE
Date. Cîmpul antet Date este folosit pentru a transmite
data la care cererea sau răspunsul este trimis (zona de timp
GMT). Acest antet este utilizat atunci cînd dispozitivele derivă
ora locală şi data din reţea. La înregistrare în reţea
dispozitivul primeşte antetul Date în răspuns. Acest lucru
permite agentului utilizator să stabilească în mod automat
data şi ora lor. Acest lucru este utilizat, de exemplu, în
telefoanele mobile.
Exemplu:
Date: Sat, 15 Mar 2014 23:29:00 GMT
From. Antetul From indică iniţiatorul cererii. Acest cîmp
trebuie să fie prezent în toate cererile SIP şi este pur şi
simplu copiat în răspunsurile SIP. Antetul From poate conţine
un nume de afişare opţional între ghilimele duble, urmat de
URI expeditorului cererii (între semnele "<>''). Sistemul
foloseşte numele de afişare Anonymous (Anonim, fără
ghilimele), în cazul în care identitatea clientului trebuie să
39
rămînă ascunsă. Antetul poate conţine şi un tag (etichetă)
folosit pentru a identifica un anumit apel. Tag-ul este un
număr aleatoriu criptografic, cu cel puţin 32 de biţi de
randomizare, care se adaugă la anteturile From şi To pentru
a identifica în mod unic un dialog.
Forma compactă a cîmpului antetului From este f.
Exemple:
From: "A. G. Bell" <sip:agb@bell-telephone.com> ;tag=a48s
From: sip:+37338551212@gatewaymd2.md;tag=887s
f:Anonymous<sip:c8oqz84zk7z@privacy.org>;tag=hyh8
To. Cîmpul antetului To este folosit pentru a indica
destinatarul cererii şi este necesar în fiecare mesaj SIP. Orice
răspuns generat de un UA va conţine cîmpul de antet To cu
adăugarea unui tag. Valoarea tag-ului antetului To este
folosită alături de tag-ul antetului From şi valoarea Call-ID,
pentru a identifica în mod unic un dialog SIP.
Forma compactă a cîmpului antetului To este t.
Exemple:
To: Helpdesk <sip:helpdesk@company.com>;tag=287447
t: sip:+37338555212@server.phone2net.com
Via. Scopul principal al antetului Via este a înregistra ruta
urmată de cerere, permiţînd astfel SIP Proxy intermediare să
transmită răspunsurile SIP înapoi, urmînd aceeaşi cale. O UA
generînd o cerere înregistrează propria sa adresă în cîmpul
antetului Via. În timp ce ordinea apariţiei pentru majoritatea
anteturilor SIP nu este importantă, pentru antetul Via ea este
semnificativă, deoarece este folosită pentru rutarea
răspunsurilor. Un Proxy îndrumînd cererea adaugă în partea
de sus a listei de cîmpuri antet Via un cîmp de antet Via care
conţine propria lui adresă. Proxy include şi un parametru
specific branch care serveşte ca un identificator de transfer
ramificat (cererea transmisă în paralel pe mai multe direcţii de
plecare) şi este utilizat de Proxy pentru a detecta bucle de
rutare. Un Proxy sau UA generînd un răspuns la o cerere
copie toate cîmpurile de antet Via de la cerere şi le include în
40
răspuns păstrînd ordinea. Apoi trimite răspunsul la adresa
specificată în partea de sus a cîmpului de antet Via. Un Proxy
cînd primeşte un răspuns verifică dacă adresa din partea de
sus a cîmpului de antet Via corespunde adresei lui şi o
şterge.
Cîmpurile antetului Via conţin numele protocolului, numărul
versiunii şi protocolul de transport (SIP/2.0/UDP,
SIP/2.0/TCP.), adresa URI şi posibil numărul de port şi
careva parametri, cum ar fi received, rport, branch, maddr şi
ttl. Parametrii sînt necesari în unele cazuri speciale, de
exemplu, dacă pe ruta mesajului sînt NAT (translator de
adresă reţea) sau firewall Proxy.
Forma compactă a cîmpului antetului Via este v.
Exemple:
Via: SIP/2.0/UDP 100.101.102.103
;branch=z9hG4bK776a
Via: SIP/2.0/UDP pchome101@aol.com:5060; branch=
z9hG4bK713a2
Valoarea parametrului de ramificaţie branch este
identificatorul tranzacţiei SIP iniţiată de elementul care
introduce antetul Via. Pentru implementări compatibile cu
specificaţia RFC 3261 [2], valoarea parametrului de branch
trebuie să înceapă cu cookie-ul magic din 7 simboluri
"z9hG4bK". Aceste cifre indică faptul că mesajul a fost
prelucrat cu ajutorul proceselor şi procedurilor definite în RFC
3261 SIP 2.0.
Max-Forwards. Cîmpul antetului Max-Forwards este
folosit pentru a indica numărul maxim de hop-uri pentru
transmiterea cererii SIP. Valoarea cîmpului antetului este un
număr întreg din intervalul 0-255 decrementat de fiecare
Proxy şi arată de cîte ori este permisă redirecţionarea cererii.
Valoarea iniţială recomandată este de 70.
Exemplu:
Max-Forwards: 6
41
2.6 Localizarea utilizatorilor după adresa SIP
Într-o reţea SIP destinaţia este determinată după

identificatorul uniform de resurse URI (Uniform Resource
Indentifier). Identificatorul uniform de resurse (URI) este o
secvenţă compactă de caractere alfanumerice care identifică
o resursă abstractă sau fizică. Deci un SIP URI identifică o
resursă de comunicare. La fel ca toate URI-urile, SIP URI-
urile pot fi plasate în pagini web, mesaje e-mail, sau literatură
tipărită. Acestea conţin informaţii suficiente pentru a iniţia şi
menţine o sesiune de comunicare cu resursa. Ca exemple de
resurse de comunicaţii pot servi următoarele:
un utilizator al unui serviciu on-line;
un apel pe un telefon multi-line;
o cutie poştală pe un sistem de mesagerie;
un număr PSTN, la un serviciu de gateway;
un grup (cum ar fi "vînzări" sau "helpdesk"), într-o
organizaţie.
Un SIP URI are două formate majore, o formă similară cu
o adresă e-mail sau alta ca un număr de telefon:
Sintaxa generală pentru adresa SIP în format de e-mail
este user @ host. Partea de utilizator este un nume de
utilizator, deseori acelaşi ca adresa lui de e-mail. Partea
gazdă este un nume de domeniu care poate fi rezolvat la o
adresă IP folosind sistemul DNS sau direct o adresă de reţea
numerică IP4 sau IP6.
Formatul general al unui număr de telefon în forma de
un SIP URI este phone-number @host;user=phone. Partea
gazdă indică un gateway sau server care poate ajunge la
acest număr de telefon. Parametrul „uzer=phone” indică
faptul că porţiunea de utilizator a URI (partea din stînga
semnului @) trebuie să fie tratată ca un tel URI. Astfel
"sip:+373 38555000@domain.com;user=phone" ar trebui să
fie tratat ca tel:+37338555000.
42
Adresele URI sînt utilizate în mesajele SIP pentru a indica
iniţiatorul, destinaţia curentă şi destinatarul final, precum şi
pentru a specifica adresele de redirecţionare.
2.7 Descrierea sesiunii în corpul mesajului
La iniţierea sesiunilor VoIP de teleconferinţă multimedia

sau de video streaming apare necesitatea de a transmite
detalii referitor la tipul media, adresele de transport, precum şi
capacităţile gazdelor participanţilor. Aceste tipuri de informaţii
se includ în corpul mesajului SIP. În cadrul dialogului
ofertă/răspuns agenţii utilizatori SIP folosesc protocolul
descriere sesiune SDP pentru schimbul de informaţii despre
sesiune şi capabilităţile sale. După ce UAC şi UAS au
negociat parametrii sesiunii ea poate fi stabilită.
Descrierea sesiunii în SDP este în întregime textuală cu
caractere ISO 10646 în codificarea UTF-8. Numele de
cîmpuri şi atribute SDP folosesc numai subsetul US-ASCII al
UTF-8.
Descrierea sesiunii SDP constă dintr-un număr de linii de
text de forma:
<tip> = <value>
unde <tip> este un caracter şi <valoare> este text
structurat al cărui format depinde de <tip>.
Protocolul SDP oferă trei categorii de descriere:
descrieri la nivel de sesiune,
descrieri de timp,
descrieri tip media.
În descriere unele linii sînt obligatorii pe cînd altele -
opţionale, însă toate trebuie să apară exact în ordinea dată
de standardul RFC 4566 (respectarea acestei ordini simplifică
detectarea erorilor). Liniile opţionale sînt marcate cu asterisc
"*". Mai jos se prezintă descriptorii care sînt admişi.
43
Descrieri la nivel de sesiune:
 v= (protocol version). Identifică versiunea de SDP.
Numărul versiunii este v=0.
 o= (originator and session identifier). Identifică
iniţiatorul sesiunii şi sesiunea în sine. Formatul pentru acest
descriptor este:
o=<username><session id><version>
<network type><address type><address>
Numele de utilizator este un singur cuvînt (nu poate
conţine spaţii) şi este ID-ul utilizatorului iniţiator al sesiunii.
Parametrul <versiune> este un număr de versiune pentru
sesiunea dată. Pentru <network type> este folosit "IN" pentru
a indica Internetul, dar sînt posibile şi alte tipuri pe viitor (de
exemplu, "IMS"). Tipul adresei denotă versiunea de IP
folosită fie IPv4 sau IPv6. Adresa este a gazdei care a iniţiat
sesiunea.
 s= (session name). Este numele textual al sesiunii.
 i=* (session information). Acest descriptor furnizează
informaţii suplimentare despre sesiune. Este prevăzut pentru
utilizare de către participanţii la sesiune în combinaţie cu
numele de sesiune.
 u=* (URI of description). Descrierea identificatorului
uniform de resurse (URI). Pentru descrierea sesiunii SIP este
permisă utilizarea nu mai mult de un cîmp URI.
 e=* (email address). Descriptorul permite iniţiatorului
sesiunii să furnizeze o adresă de e-mail, astfel încît
participanţii îl vor putea contacta referitor la sesiune. Pentru
fiecare sesiune pot fi furnizate mai multe adrese.
 p=* (phone number). Similar cu adresa de e-mail,
numărul de telefon poate fi folosit de către participanţi pentru
a apela în cadrul sesiunii. Acest lucru, ca şi adresa de e-mail,
are sens în cazul unor conferinţe multimedia şi nu vor fi
utilizate pentru comunicaţii de voce simple.
 c=* (connection information). Informaţiile despre
conexiune se prezintă în următorul format:
44
c=<network type><address type><connection address>
Tipul de reţea este acelaşi ca şi în descriptorul ”o”. Tipul de
adresă fie o adresă IPv4 sau IPv6, iar adresa de conexiune
identifică adresa IP reală care poate fi utilizată pentru
conexiuni.
 b=* (bandwidth information lines). Identifică lăţimea de
bandă necesară pentru sesiune. Acesta este compus din doi
parametri după cum se arată aici:
b=< bwtype >:<bandwidth >
Unde <bwtype> este un modificator alfanumeric care
determină semnificaţia cifrei <bandwidth>. Modificatorul poate
fi una dintre cele două valori: fie "CT" - total pentru conferinţă
sau "AS" pentru aplicaţii specifice. CT semnifică lăţimea de
bandă totală pe toate site-urile şi toate media utilizate pentru
sesiune. AS denotă lăţimea de bandă la un singur site cu o
singură aplicaţie. Valoarea numerică a lăţimii de bandă este
exprimată în kilobytes pe secundă.
Descrieri de timp:
 t= (time the session is active). Linia ”t=” specifică
pornirea şi oprirea sesiunii. Formatul este: t=<start-time>
<stop-time>. Primul subcîmp determină timpul de start iar al
doilea subcîmp timpul de oprire a sesiunii. Valorile sînt cifre
zecimale exprimate în secunde în corespundere cu NTP
(Network Time Protocol) cu începere din anul 1900 [RFC
5905].
Dacă <stop-time> este setat la zero, atunci durata
sesiunii nu este limitată, deşi ea nu va deveni activă pînă
după timpul marcat de <start-time>. Dacă <start-time> este,
de asemenea, setat la zero atunci sesiunea este considerată
ca fiind permanentă.
 r=* (zero or more repeat times). Acest cîmp este
utilizat pentru a indica cînd sesiunea se va repeta din nou.
Indică deplasarea de la timpul de pornire (adică în cît timp
după ora de start sesiunea va fi repetată). Formatul pentru
cîmpul timp repetare este:
45
r=<repeat interval><active duration><list of offsets from start
time>
Descriptorul indică intervalul de repetare (de exemplu,
zilnic), durata activă a sesiunii la fiecare apariţie şi
deplasarea, prima şi ultima delta în secunde de la ora de
începere pentru fiecare dintre sesiunile repetate. Standardul
pentru prescurtare permite prezentarea timpului nu doar în
secunde dar şi cum se arată mai jos:
r=7d 1h 0 25h
În exemplu, sesiunea se repetă fiecare săptămînă, durata
e de 1 oră, primul offset 0 pentru sesiunea actuală, iar al
doilea - de 25 ore.
 z=* (time zone adjustments). Acesta permite
participanţilor să facă ajustări la fusul orar.
Descrieri la nivel de sesiune (continuare):
 k=* (encryption key). Dacă este folosită criptarea,
atunci acest cîmp identifică cheile de criptare necesare pentru
a citi sarcina utilă. Standardele nu identifică mecanismul
exact pentru schimbul de chei, ci mai degrabă un vehicul prin
care cheile de criptare ar putea fi schimbate. Formatul acestui
descriptor este:
k=<method><key parameter>
 a=* (zero or more session attribute lines – zero sau
mai multe linii cu atribute sesiune). Atributele sînt folosite ca
mijloc de extindere a SDP pentru alte aplicaţii. De exemplu,
dacă o anumită aplicaţie necesită un atribut care nu este
definit de IETF, atunci aplicaţia dată poate fi numită în cîmpul
acestui atribut. Orice entitate care recepţionează şi nu
înţelege acest atribut pur şi simplu îl ignoră. Cîmpurile
atributelor "de nivel de sesiune" transmit informaţii
suplimentare care se aplică la întreaga sesiune dar nu la
careva flux media în mod individual.
Descrieri tip media. Descrierea media furnizează
informaţii cu privire la media specifice pentru o sesiune.
 m= (media name and transport address). Descrierea
46
media furnizează informaţii cu privire la fluxurile de media
specifice pentru o sesiune. Formatul pentru descrierea media
este după cum urmează:
m=<media><port><proto><media formats>
Subcîmpul <media> descrie tipul de media. În prezent
sunt definite următoarele tipuri de media: "video", "audio",
"text", "aplicaţie" şi "mesaj". Lista poate fi extinsă în viitor.
Subcîmpul <port> este numărul portului de transport la
care fluxul media se transmite. Semnificaţia portului de
transport depinde de reţeaua utilizată în conformitate cu
cîmpul "c =" în cauză şi de protocolul de transport definit în
următorul subcîmp <proto>. În prezent există două valori
acceptate pentru protocolul de transport: RTP / AVP, pentru
Real-Time Protocol folosind profilul Audio Video sau UDP.
Subcîmpul <media formats> identifică formatele media
care trebuie folosite pentru fiecare dintre tipurile de media
definite. Formatul media se identifică printr-un număr care
corespunde unui profil de identificare format. Numerele sînt
apoi folosite pentru a indexa careva atribute care furnizează
detalii suplimentare pentru formatul media. Descrierea media
poate fi constituită din unul sau mai multe atribute ("a ="
cîmpuri). Acestea sînt denumite "atribute la nivel de media" şi
adaugă informaţii despre fluxul de media.
De exemplu:
m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2
În exemplul dat se indică că sesiunea va sprijini media de tip
audio pe portul 49232, protocolul de transport utilizat este
RTP, profilul audio video RTP/AVP cu număr de identificare
98 (dinamic). Atributul furnizează detalii suplimentare în ceea
ce priveşte formatul audio. În acest exemplu, profile-ul
dinamic 98, codare liniară pe 16 biţi, rata de eşantionare de
16000 Hz şi 2 canale, deci stereo.
 i=* (media title - titlul media). Pentru definirea fiecărui
tip de media poate fi utilizat un singur cîmp "i =". Cîmpurile
47
acestea sînt destinate etichetării fluxurilor de media. Se
folosesc mai des atunci cînd sesiunea are mai multe fluxuri
media distincte de acelaşi tip de media.
 c=* (connection information -- optional if included at
session level). Informaţii despre conexiune. Este opţional
dacă descriptorul "c =" este inclus la nivelul de sesiune. O
descriere sesiune conţine un singur cîmp "c =" la nivel de
sesiune şi cîmp(uri) suplimentar(e) "c =" pentru fiecare
descriere media.
 b=* (zero or more bandwidth information lines). Acest
cîmp opţional denotă lăţimea de bandă propusă pentru a fi
utilizată de media.
 k=* (encryption key). Cîmpul cheie criptare este permis
înainte de prima intrare media (în cazul în care se aplică
pentru toate media în cadrul sesiunii) sau pentru fiecare
intrare media în parte, după caz. Formatul de chei şi utilizarea
lor sînt în afara scopului acestei lucrări.
 a=* (zero or more media attribute lines). Descrierea
media de atribute (cîmpuri "a ="), care sînt media specifice.
Spre exemplu, atributele a=sendonly şi a=recvonly semnifică
că dispozitivul ar trebui să fie pornit în modul doar trimitere
sau respectiv doar recepţie.
Un exemplu de descriere sesiune de protocolul SDP este
[RFC4456]:
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 8 ( 8 profile static, PCM A-law)
m=video 51372 RTP/AVP 99
48
a=rtpmap:99 h263-1998/90000 (99 profile dinamic, codare
video H.263 versiunea 1998, rata eşantionare 90000 Hz)
2.8 Exemplu de stabilire a unei sesiuni SIP
Exemplul adus arată funcţiile de bază ale SIP: localizarea

unui punct terminal, solicitarea sesiunii, negocierea parametrilor
de sesiune pentru stabilirea sesiunii şi terminarea sesiunii
stabilite.
Figura 2.2 prezintă un exemplu tipic de schimb de mesaje
între doi utilizatori, Alice şi Bob [2]. Fiecare mesaj este marcat
prin litera ”M” cu un număr de trimitere la text. De asemenea, se
arată două servere SIP Proxy care acţionează în numele Alice şi
Bob pentru a facilita stabilirea sesiunii.
Alice's atlanta.com biloxi.com Bob's
softphone proxy proxy SIP Phone
| | | |
| M1 INVITE | | |
|--------------->| M3 INVITE | |
| M2 100 Trying |--------------->| M5 INVITE |
|< | M4 100 Trying | >|
| |<-------------- | M6 180 Ringing |
| | M7 180 Ringing |< -------------- |
| M8 180 Ringing |<---------------| M9 200 OK |
|< | M10 200 OK |< |
| M11 200 OK |<---------------| |
|<---------------| | |
| M12 ACK |
| >|
| Media Session |
|<================================================>|
| M13 BYE |
|< |
| M14 200 OK |
| >|
Fig. 2.2 Exemplu de stabilire a unei sesiuni SIP
49
Solicitanta este Alice care apelează telefonul SIP al lui
Bob utilizînd SIP URI sip:bob@biloxi.com , unde biloxi.com
este domeniul furnizorului de servicii SIP a lui Bob. Respectiv
adresa SIP URI a lui Alice este sip:alice@atlanta.com.
M1 INVITE Alice -> atlanta.com proxy
INVITE sip:bob@biloxi.com SIP/2.0

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP nu se prezintă)
În acest exemplu, tranzacţia începe cu cererea INVITE

trimisă de softphone-ul lui Alice şi adresată lui Bob conform
SIP URI. Cererea conţine o serie de anteturi. Cîmpurile
anteturilor sînt atribute care furnizează informaţii suplimentare
despre mesaj. Cererea INVITE de mai sus include
următoarele anteturi:
Via conţine adresa (pc33.atlanta.com), la care Alice se
aşteaptă să primească răspunsuri la această cerere. Antetul
conţine şi un parametru branch care identifică această
tranzacţie.
To cu un nume de afişare (Bob) şi adresa SIP URI (sip:
bob@biloxi.com), spre care cererea a fost direcţionată iniţial.
From conţine, de asemenea, un nume de afişare (Alice)
şi adresa SIP a solicitantului (sip: alice@atlanta.com). Cîmpul
de antet include şi un tag (etichetă) care conţine un şir aleator
(1928301774), care a fost adăugat la URI de softphone.
Acesta este utilizat pentru identificarea dialogului.
50
Call-ID conţine un identificator unic global al apelului
generat ca o combinaţie dintre un şir aleatoriu şi numele de
gazdă al softphone-lui sau adresei IP.
CSeq sau Secvenţa de comandă conţine un număr
întreg şi denumirea cererii. Numărul CSeq este incrementat
de fiecare nouă cerere din cadrul dialogului şi este un număr
de ordine tradiţional.
Contact conţine un URI SIP care reprezintă o rută
directă pentru a contacta Alice compus din nume de utilizator
şi nume de domeniu. Astfel viitoarele cereri spre Alice trebuie
să sosească la adresa indicată.
Max-Forwards serveşte pentru a limita numărul de hop-
uri ale cererii pe care le poate face pe drumul spre destinaţie.
Acesta constă dintr-un număr întreg, care este decrementat
cu unu la fiecare hop.
Content-Type conţine o descriere a corpului mesajului
(nu se prezintă).
Content-Length conţine numărul de octeţi din corpul
mesajului.
Corpul mesajului descrie sesiunea utilizînd protocolul SDP şi
este similar celui din exemplul de mai sus (pargraful 2.7).
Scopul optimizării expunerii corpul mesajului SDP aici este
omis.
M2 100 Trying atlanta.com proxy -> Alice
SIP/2.0 100 Trying

;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 0
Serverul Proxy primeşte cererea SIP de la UAC şi o

transmite mai departe din numele solicitantului, iar în sens
opus trimite softphone-ului lui Alice răspunsul 100 Trying.
51
Răspunsul 100 Trying indică faptul că invitaţia a fost primită şi
că Proxy-ul lucrează în numele ei pentru a ruta invitaţia către
destinaţie. Acest răspuns conţine aceleaşi cîmpuri ale
anteturilor To, From, Call-ID, CSeq şi Via cu parametrul
branche ca şi în M1 INVITE. Aceasta permite softphone-lui
Alice să coreleze răspunsul cu INVITE.
M3 INVITE atlanta.com proxy -> biloxi.com proxy

Via: SIP/2.0/UDP
bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.1
Max-Forwards: 69
CSeq: 314159 INVITE
Content-Length: 142
M4 100 Trying biloxi.com proxy -> atlanta.com proxy
SIP/2.0 100 Trying

Via: SIP/2.0/UDP
;received=192.0.2.2
;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 0
52
Serverul Proxy biloxi.com primeşte IVITE şi răspunde
înapoi serverului Proxy atlanta.com cu mesajul 100 Trying
pentru a indica faptul că a primit INVITE şi acum această
cerere se procesează. Serverul Proxy consultă baza de date
a serviciului de localizare unde este înregistrată adresa IP
curentă a lui Bob.
M5 INVITE biloxi.com proxy -> Bob
INVITE sip:bob@192.0.2.4 SIP/2.0

Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1
Via: SIP/2.0/UDP
;received=192.0.2.2
;received=192.0.2.1
Max-Forwards: 68
CSeq: 314159 INVITE
Content-Length: 142
Serverul Proxy biloxi.com adaugă un alt cîmp de antet

Via cu propria adresă şi transmite cererea INVITE la telefonul
SIP al lui Bob.
M6 180 Ringing Bob -> biloxi.com proxy
SIP/2.0 180 Ringing

;received=192.0.2.3
Via: SIP/2.0/UDP
;received=192.0.2.2
;received=192.0.2.1
53
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Content-Length: 0
Telefonul SIP al lui Bob primeşte INVITE şi îl alertă pe

Bob despre primirea apelului de la Alice. Telefonul lui Bob
sună şi pentru informare transmite înapoi prin cele două
Proxy-uri în sens opus răspunsul 180 Ringing.
M7 180 Ringing biloxi.com proxy -> atlanta.com proxy
SIP/2.0 180 Ringing

Via: SIP/2.0/UDP
;received=192.0.2.2
;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 0
Fiecare Proxy utilizează cîmpul antetului Via pentru a

determina direcţia în care să trimită răspunsul şi elimină
propria adresa din vîrf. Toate Proxy care au retransmis
cererea INVITE trebuie să primească în direcţie opusă
mesajele de răspuns la aceasta cerere.
M8 180 Ringing atlanta.com proxy -> Alice
SIP/2.0 180 Ringing

;received=192.0.2.1
54
CSeq: 314159 INVITE
Content-Length: 0
După primirea răspunsului 180 Ringing softphone-ul lui

Alice afişează un mesaj pe ecranul PC sau se generează
semnalul de revers apel.
M9 200 OK Bob -> biloxi.com proxy
SIP/2.0 200 OK
;received=192.0.2.3
Via: SIP/2.0/UDP
;received=192.0.2.2
;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 131
(Bob's SDP nu se prezintă)
După ce Bob ridică receptorul, telefonul SIP al lui trimite

răspunsul 200 OK, prin care se informează clientul că cel
solicitat a răspuns la apel. Acest răspuns conţine în corpul
mesajului descrierea tipului de sesiune (în protocolul SDP
care aici nu se prezintă) care se doreşte să se stabilească cu
UAC. Ca urmare, există un schimb în două faze a mesajelor
SDP: iniţial de la softphone-ul lui Alice trimis spre SIP
telefonul lui Bob în corpul cererii INVITE şi apoi prin
răspunsul 200 OK în direcţie inversă. Datorită acestui
mecanism bazat pe un simplu model de ofertă/răspuns se
efectuează negocierea capabilităţilor agenţilor utilizatori ai
dialogului. Cîmpurile anteturilor Via, To, From, Call-ID şi Cseq
55
ale acestui răspuns sînt copiate din respectivele cîmpuri ale
cererii INVITE. Telefonul SIP al lui Bob a adăugat un tag în
cîmpul antetului To. Această etichetă va fi inclusă de către
ambele terminale ale dialogului în toate cererile şi
răspunsurile viitoare în cadrul acestui apel. Cîmpul antetului
Contact conţine un URI, la care Bob poate fi contactat în
direct de la telefonul lui SIP. Anteturile Content-Type şi
Content-Length se referă la corpul mesajului (nu se prezintă)
care conţine informaţii în SDP despre tipul media de la Bob.
M10 200 OK biloxi.com proxy -> atlanta.com proxy
SIP/2.0 200 OK
Via: SIP/2.0/UDP
;received=192.0.2.2
;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 131
M11 200 OK atlanta.com proxy -> Alice
SIP/2.0 200 OK
;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 131
56
Răspunsul 200 (OK) este direcţionat înapoi prin cele

două Proxy-uri şi este primit de softphone-ul lui Alice, care
opreşte tonul de revers apel şi indică faptul că s-a răspuns la
apel.
M12 ACK Alice -> Bob
ACK sip:bob@192.0.2.4 SIP/2.0

Max-Forwards: 70
CSeq: 314159 ACK
Content-Length: 0
Softphone-ul lui Alice trimite un mesaj de confirmare ACK

pentru telefonul SIP al lui Bob ce confirmă primirea
răspunsului final (200 OK). În acest exemplu, mesajul ACK
este trimis direct de la softphone-ul lui Alice la SIP telefonul
lui Bob ocolind cele două Proxy-uri. Acest lucru se întâmplă
deoarece terminalele au aflat reciproc adresele din cîmpule
antetului Contact prin schimbul de mesaje INVITE/200 OK,
care nu erau cunoscute la momentul trimiterii INVITE.
În aşa mod sesiunea media între Alice şi Bob este
stabilită. Agenţii utilizatori trimit pachete media în formatul în
care au fost de acord prin schimbul de SDP. În general,
pachetele media cap la cap au o cale diferită de cea a
mesajelor de semnalizare SIP.
M13 BYE Bob -> Alice
BYE sip:alice@pc33.atlanta.com SIP/2.0

Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
To: Alice <sip:alice@atlanta.com>;tag=1928301774
57
CSeq: 231 BYE
Content-Length: 0
Sesiunea se încheie după ce Bob închide primul

telefonul. Se observă că telefonul SIP al lui Bob menţine
propriul spaţiu de numerotare CSeq care, în acest exemplu,
începe cu 231. Deoarece cererea M13 Bye se transmite de la
Bob, adresele URI în anteturile To şi From precum şi tag-urile
au fost schimbate.
M14 200 OK Alice -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10
From: Bob <sip:bob@biloxi.com>;tag=a6c85cf
To: Alice <sip:alice@atlanta.com>;tag=1928301774
CSeq: 231 BYE
Content-Length: 0
Alice confirmă primirea BYE prin răspunsul 200 OK, care

termină sesiunea. Trimiterea mesajului de confirmare ACK în
acest caz nu se mai cere.
58
ANEXĂ
Exerciţiu. Pentru următoarele fluxuri:

a) determinaţi cine trimite şi cine primeşte fiecare mesaj;
b) desenaţi diagrama fluxului de apel;
d) determinaţi rolul fiecărui flux.
Mesajul 1
INVITE sips:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.atlanta.example.com:5061
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sips:alice@atlanta.example.com>;tag=1234567
To: Bob <sips:bob@biloxi.example.com>
Call-ID: 12345600@atlanta.example.com
CSeq: 1 INVITE
Contact: <sips:alice@client.atlanta.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces
Content-Length: ...
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=
c=IN IP4 client.atlanta.example.com
t=0 0
a=rtpmap:0 PCMU/8000
Mesajul 2
SIP/2.0 180 Ringing
;received=192.0.2.103
To: Bob <sips:bob@biloxi.example.com>;tag=23431
CSeq: 1 INVITE
Contact: <sips:b54gh42f5@biloxi.example.com>
Content-Length: 0
59
Mesagul 3
SIP/2.0 200 OK
;received=192.0.2.103
CSeq: 1 INVITE
Contact: <sips:b54gh42f5@biloxi.example.com>
Supported: replaces, gruu
Content-Length: ...
v=0
o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com
s=
c=IN IP4 client.biloxi.example.com
t=0 0
Mesagul 4
ACK sips:b54gh42f5@biloxi.example.com SIP/2.0
;branch=z9hG4bK74bfL
Max-Forwards: 70
CSeq: 1 ACK
Content-Length: 0
Mesagul 5
INVITE sips:alice@client.atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061
;branch=z9hG4bKnashds
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=23431
To: Alice <sips:alice@atlanta.example.com>;tag=1234567
CSeq: 1024 INVITE
Contact: <sips:bob-Mixer@client.biloxi.example.com>;isfocus
60
Content-Length: ...
v=0
s=
t=0 0
Mesagul 6
SIP/2.0 200 OK
;branch=z9hG4bKnashds7
;received=192.0.2.113
CSeq: 1024 INVITE
Contact: <sips:alice@client.atlanta.example.com>
Supported: replaces
Content-Length: ...
v=0
o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com
s=
c=IN IP4 client.atlanta.example.com
t=0 0
Mesagul 7
ACK sips:alice@client.atlanta.example.com SIP/2.0
;branch=z9hG4bKnash3G
Max-Forwards: 70
CSeq: 1024 ACK
Content-Length: 0
61
Mesagul 8
INVITE sips:carol@chicago.example.com SIP/2.0
;branch=z9hG4bKnashJfd
Max-Forwards: 70
To: Carol <sips:carol@chicago.example.com>
Call-ID: sdjfdjfskdf@biloxi.example.com
CSeq: 42 INVITE
Contact: <sips:bob-Mixer@client.biloxi.example.com>;isfocus
Content-Length: ...
v=0
s=
t=0 0
Mesagul 9
SIP/2.0 200 OK
;received=192.0.2.113
To: Carol <sips:carol@chicago.example.com>;tag=341313
CSeq: 42 INVITE
Contact: <sips:carol@client.chicago.example.com>
Supported: replaces
Content-Length: 0
Mesagul 10
SIP/2.0 200 OK
;received=192.0.2.113
62
CSeq: 42 INVITE
Contact: <sips:carol@client.chicago.example.com>
Supported: replaces
Content-Length: ...
v=0
o=carol 2890844922 2890844922 IN IP4 client.chicago.example.com
s=
c=IN IP4 client.chicago.example.com
t=0 0
Mesagul 11
ACK sips:carol@client.chicago.example.com SIP/2.0
;branch=z9hG4bKnash431
Max-Forwards: 70
CSeq: 42 ACK
Content-Length: 0
BIBLIOGRAFIE
1. ITU-T Recommendation Y.2001 (12/2004) - General

overview of NGN (http://www.itu.int), 2005.
2. J. Rosenberg, H. Schulzrinne, G. Camarillo, A.
Johnston, J. Peterson, R. Sparks, M. Handley, and E.
Schooler, “SIP: session initiation protocol,” RFC 3261,
Internet Engineering Task Force, June 2002.
3. M. Handley, V. Jacobson, c. Perkins. ” SDP: session
description protocol.,” RFC 4566, Internet Engineering Task
Force, July 2006.
4. http://www.iana.org/assignments/sip-parameters/sip-
parameters.xhtml#sip-parameters-12
63
CUPRINS
Introducere. ........................................................................... 3
1. Prezentarea generală a NGN. .......................................... 5
1.1 Definiţia NGN. ............................................................ 5
1.2 Arhitectura NGN. ......................................................... 7
1.2.1 Nivelul transport şi comutaţie ............................ 8
1.2.2 Nivelul control reţea şi semnalizare. ................ 12
1.2.3 Nivelul servicii, control servicii şi aplicaţii .........12
1.3 Protocoale de semnalizare în NGN. .......................... 13
2. Protocolul de iniţiere a sesiunii SIP ............................... 16
2.1 Componentele funcţionale ale reţelei SIP ................ 17
2.2 Structura mesajelor SIP ........................................... 19
2.3 Cereri SIP .................................................................21
2.4 Răspunsuri SIP ........................................................ 27
2.5 Anteturi SIP ............................................................. 34
2.6 Localizarea utilizatorilor după adresa SIP................ 42
2.7 Descrierea sesiunii în corpul mesajului.................... 43
2.8 Exemplu de stabilire a unei sesiuni SIP .....................49
Anexă ...................................................................................59
Bibliografie. ......................................................................... 63
64
SISTEME ŞI REŢELE DE COMUNICAŢII DIGITALE

Partea 1
CICLU DE PRELEGERI
Chişinău
64
2014
Facultatea Inginerie şi Management în

Electronică şi Telecomunicaţii
Catedra Telecomunicaţii
SISTEME ŞI REŢELE
DE COMUNICAŢII DIGITALE
Partea 2
CICLU DE PRELEGERI
Chişinău
641
Editura „Tehnica–UTM”
64
Lucrarea de faţă include partea a doua a cursului Sisteme
şi reţele de comunicaţii digitale(SRCD) şi este divizată în
două compartimente. În primul compartiment este descris
protocolul umbrelă H.323 inclusiv componentele şi
protocoalele acestui sistem. Capitolul finalizează cu aducerea
unui exemplu de setare a unui apel cu implicarea gatekeeper-
ului.
În al doilea capitol se expune protocolul de control al
Gateway-lui H.248/MEGACO. Se descrie modelul de
conexiune, comenzile şi descriptorii protocolului
H.248/MEGACO. În final se descrie un scenariu de setare a
unui apel H.248.
Obiectivul principal al acestei părţi a cursului SRCD
constă în însuşirea cunoştinţelor de bază privind protocoalele
de semnalizare utilizate în reţelele de noua generaţie.
Cursul Sisteme şi reţele de comunicaţii digitale este
destinat studenţilor UTM cu profilul 525 Electronică şi
comunicaţii, specialităţile Teleradio – comunicaţii, cu forma de
studii la zi şi cu frecvenţă redusă.
–––––––––––––––––––––––––––––––––––––––––––––––––
Bun de tipar 25.05.2015 Formatul 60x84 1/16
Hârtie ofset. Tipar RISO Tirajul 55 ex.
Coli de tipar 3,0 Comanda nr. 53
–––––––––––––––––––––––––––––––––––––––––––––––––
2004, UTM, bd. Ştefan cel Mare şi Sfânt, 168
© UTM, 2015
2
INTRODUCERE
Prima parte a cursului de prelegeri ”Sisteme şi reţele de

comunicaţii digitale” [1] a inclus expunerea generală a
reţelelor de noua generaţie NGN şi a protocolului de iniţiere a
sesiunii SIP.
Partea a doua a cursului de prelegeri continuă cu
expunerea altor două protocoale de semnalizare pe larg,
utilizate în reţelele de comunicaţii multimedia, şi anume,
protocolul umbrelă H.323 şi protocolul de control al gateway-
lui H.248/Megaco.
Lucrarea în cauză este destinată studenţilor ultimului an
universitar, masteranzilor, dar autorul speră să fie de folos şi
tuturor celor din domeniul TIC interesaţi de subiectele
abordate.
1. PROTOCOLUL H.323
1.1 Sumar
Protocolul H.323 a fost elaborat în cadrul Uniunii
Internaţionale a Telecomunicaţiilor (ITU), prima versiune fiind
publicată în 1996. Expunerea ce urmează se bazează pe
versiunea curentă sub numărul 7, adoptată în decembrie
2009 [2].
Recomandarea ITU-T H.323 ”Sisteme de comunicaţii
multimedia bazate pe pachete” [2] se referă la specificaţiile
tehnice pentru sistemele de comunicaţii multimedia bazate pe
reţele cu comutaţia de pachete care nu pot asigura o calitate
garantată a serviciului (QoS). Această recomandare descrie
componentele unui sistem H.323, care include terminale
H.323, Gateway-uri, Gatekeeper şi unităţi de control
multipunct MCU (Multipoint Control Unit) pentru conferinţe
(figura 1.1). Mesajele şi procedurile de control din cadrul
3
acestei recomandări definesc modul în care aceste
componente comunică.
MCU
IP
Fig. 1.1 Componentele reţelei H.323

Componentele reţelei H.323 comunică prin schimbul de
fluxuri informaţionale, clasificate după cum urmează:
Audio: vorbire digitalizată şi codificată. Fiecare flux
audio are şi un semnal de control audio.
Video: imagini digitale codate în mişcare (nu imagini
statice). Fiecare flux video are un semnal de control video.
Date: fişiere electronice cum ar fi imagini statice,
imagini de fax şi documente.
Controlul comunicaţiilor: semnale pentru a face schimb
de capabilităţi, deschiderea şi închiderea canalelor logice,
modul şi alte funcţii de control al comunicaţiilor.
4
Controlul apelurilor: semnale pentru stabilirea şi
eliberarea apelurilor.
Protocolul H.323 a fost creat aproximativ în acelaşi timp
ca şi protocolul de iniţiere a sesiunii SIP, dar a fost adoptat pe
scară mai largă şi desfăşurat mai devreme. Astăzi, cele mai
mult din traficul VoIP global se realizează prin intermediul
reţelelor H.323, cu miliarde de minute de trafic transportate în
fiecare lună.
1.2 Terminalul H.323

Conform definiţiei ITU, un terminal H.323 este un punct
final al reţelei care asigură comunicaţii bidirecţionale vocale
sau multimedia, în timp real cu un alt terminal H.323, gateway
sau unitate de control multipunct. Această comunicare constă
în schimbul de fluxuri audio, video, date şi semnale de control
între două sau mai multe terminale. Un terminal poate furniza
doar comunicare audio, sau audio şi de date, sau audio şi
video, sau toate trei concomitent. Exemple de terminale pot
servi telefonul IP, softphonul, IVR (Interactive voice
response), voicemail, camera video, PC-ul etc. Schema-bloc
tipică a unui terminal H.323 care asigură comunicaţii
multimedia este prezentată în figura 1.2 [2].
Pe diagramă sînt arătate elementele terminalului:
codecurile video şi audio, echipamentul de telematică,
unitatea de sincronizare la recepţie, unitatea de control a
sistemului şi modulul nivelului H.225.0.
5
Echipam Video codec
ent I/O H.261, H.263, zare
video H.264 recepţie
(Receive
Echipam Audio codec path
ent I/O G.711, G.722, delay) I
n
audio G.723, G.728, t
G.729 e
Aplicaţii Nivel
r
date ITU-T
H.225.0 f
utilizator
a
Control sistem ţ
Control ă
Interfaţă H.245
utilizator r
de control Control apel e
a sistemului H.225.0 ţ
e
a
Control RAS
H.225.0
Fig.1.2 Schema-bloc a terminalului H.323
Codecul video (H.261, H.263, H.264, etc.) codifică video

semnalul transmis de la sursă (de exemplu, camera de luat
vederi) şi decodifică semnalul video recepţionat din reţea
pentru afişarea lui pe ecran.
Codecul audio (G.711, G.722, G.723, G.726, etc.)
codifică semnalul audio transmis de la microfon şi decodifică
6
semnalul audio recepţionat din reţea cu emiterea lui spre
difuzor.
Canalul de date utilizator suportă aplicaţii telematice, cum
ar fi table electronice, transfer de imagini statice, schimb de
fişiere, acces la baze de date, conferinţe audiographice etc.
Unitatea de sincronizare la recepţie include întârzieri la
fluxurile media sosite în scopul sincronizării lor. Întârzierea
introdusă la recepţie are rolul a elimina jitterul (variaţia
întârzierii) prin memorarea octeţilor de voce şi redarea lor la
recepţie la intervale egale.
Unitatea de control a sistemului (H.245, H.225.0) asigură
semnalizarea pentru funcţionarea adecvată a terminalului
H.323. Ea asigură înregistrarea terminalelor la gatekeeper,
stabilirea şi încheierea canalelor logice, controlul apelurilor,
schimbul de capacităţi funcţionale. Unitatea de control a
terminalului implementează protocoalele de control ale
conexiunilor.
Modulul nivel H.225.0 la transmitere formatează
semnalele video, audio şi date utilizator şi de control în
mesaje de ieşire spre interfaţa de reţea. La recepţie modulul
preia semnalele video, audio, date utilizator şi de control din
mesajele de intrare de la interfaţa de reţea. În plus, el
efectuează formarea cadrelor logice, numerotarea lor
secvenţială, detectarea şi corectarea erorilor.
Conectarea terminalului la reţeaua bazată pe pachete se
efectuează prin interfaţa de reţea.
1.3 Gateway-ul H.323

Gateway-ul H.323 (GW) este un punct final al reţelei care
asigură în timp real comunicaţii bidirecţionale între terminalele
H.323 din reţeaua bazată pe pachete şi alte terminale dintr-o
reţea cu comutare de circuite. Funcţia principală a gateway-
ului este a converti vocea sau informaţia multimedia venită de
7
la reţeaua cu comutare de circuite (SCN) într-o formă
adecvată pentru transmiterea ei prin reţele bazate pe IP.
Această conversie constă în codificarea informaţiei şi
încadrarea ei în pachete RTP/UDP/IP, precum şi
transformarea inversă în sensul opus. În plus, gateway-ul
trebuie să asigure şi schimbul de mesaje de semnalizare între
SCN şi reţeaua H.323. În figura 1.3 este prezentat un
exemplu de configurare gateway la care se conectează
terminale din partea ambelor tipuri de reţea. Alte configuraţii
de gateway prevăd conectarea MCU la una sau la ambele
reţele.
Funcţii Funcţii de Funcţii

terminal terminal
H.323 SCN sau
conversie
sau MCU
MCU SCN
Reţea IP Reţea cu
comutaţie
circuite
Gateway
Fig.1.3 Exemplu de configuraţie gateway IP/PSTN
Astfel un GW are caracteristicile terminalului H.323 sau

MCU în reţeaua IP şi realizează funcţiile terminalului SCN
sau MCU SCN în reţeaua cu comutaţie de circuite.
Gateway-urile care suportă interconectarea doar cu
terminale pentru voce în PSTN sau ISDN trebuie să fie
8
capabile să genereze şi să detecteze semnalele DTMF
9
pentru 0-9, * şi #. În plus, ele pot fi capabile să genereze şi să
detecteze semnalele DTMF, tonuri şi semnale de telefonie
corespunzătoare acestor evenimente transmise cu o sarcină
utilă RTP specială (mesaje H.245).
Dacă gatekeeper-ul nu se foloseşte în reţeaua H.323
atunci GW trebuie să mai realizeze şi translarea numărului
E.164 în adresa de transport a reţelei IP.
Evident, dacă se efectuează o conexiune între două
terminale H.323 aflate într-o reţea IP atunci GW nu este
necesar.
1.4 Gatekeeper H.323

Gatekeeper-ul (în română - Portarul) efectuează controlul
terminalelor, gateway-urilor şi MCU interconectate în cadrul
unei zone de reţea H.323. Toate aceste entităţi se
înregistrează la acest gatekeeper (GK). Diferite părţi ale zonei
reţelei H.323 dispersate teritorial pot fi interconectate prin
rutere (figura 1.4).
10
Fig.1.4 Zona reţelei H.323
Ruterele şi switch-urile Ethernet funcţionează la nivelele

trei şi doi şi nu fac parte din entităţile reţelei H.323 care
activează la nivelul aplicaţiilor stivei TCP/IP.
Zona nu trebuie neapărat să aibă o topologie fizică
asociată. Mai degrabă, o zonă poate fi o structură logică
definită de administratorul de reţea.
Gatekeeper-ul furnizează următoarele servicii:
Translarea adresei numită alias (numele abonatului,
numărul telefonic, adresa poştei electronice etc.) în adresa de
transport a reţelei (adresa IP şi numărul portului TCP).
Translarea se efectuează cu ajutorul unui tabel de
corespondenţă care este actualizat folosind mesajele de
înregistrare descrise mai jos.
Controlul admisiei terminalelor în reţea. GK-ul trebuie
să autorizeze accesul în reţea utilizînd semnalizarea RAS
descrisă în paragraful 1.6.1.
11
Controlul, managementul şi rezervarea ratei de
transfer a reţelei. Spre exemplu, GK poate controla numărul
terminalelor care simultan accesează reţeaua.
Rutarea mesajelor de semnalizare între terminalele
unei zone. Sînt posibile două moduri de rutare. GK-ul poate
organiza canalul de semnalizare direct între terminale sau cu
retransmiterea mesajelor de semnalizare de la un terminal la
altul.
Nu poate exista decît un singur GK activ pe zonă (figura 1.5).
Fig.1.5 Zone H.323 cu Gatekeepere
Fiecare zonă poate suprapune mai multe subreţele cu un

GK care gestionează gateway-urile, terminalele, MCU din
aceste subreţele.
1.5 Unitatea de control multipunct MCU

Unitatea de control multipunct (MCU) este un dispozitiv
final al reţelei care asigură organizarea conferinţelor
multipunct cu participarea a trei sau mai multor terminale şi
gateway-uri. Iniţial într-o conferinţă pot participa doar două
terminale punct-la-punct, dar care ulterior se poate dezvolta
în una multipunct. MCU este format obligatoriu din Controller-
ul Multipunct (MC) şi, opţional, din Procesoare multipunct
(MP). În cel mai simplu caz, un MCU poate consta numai
dintr-un MC fără MP.
MC asigură negocierea cu toate terminalele pentru a
atinge niveluri de capacităţi comune de comunicaţii (ce
codecuri vor fi folosite), dar el nu efectuează mixarea sau
comutarea fluxurilor audio, video şi de date. Funcţiile de
12
mixare, comutare sau alt tip de procesare a fluxurilor media
se asigură de MP sub controlul MC. Controller-ul MC poate fi
fizic situat la Gatekeeper, Gateway, terminale, sau MCU.
(figura 1.6) [2].
Fig. 1.6 Locaţii posibile ale MC şi MP într-un sistem H.323
Pe figură se prezintă şi locaţia posibilă a procesorului.

Dacă în reţea sînt mai multe controllere MC atunci la iniţierea
conferinţei se desfăşoară procedura de determinare a
echipamentului ”master - slave” pentru a identifica
controller-ul MC care va administra această conferinţă.
1.6 Stiva de protocoale H.323

Protocolul H.323 este numit ”protocol umbrelă”, deoarece
include o familie de protocoale. Mai jos ne vom opri la
principalele protocoale ale stivei de protocoale H.323 şi
anume:
13
Protocolul RAS (Ragistration, Admission and Status)
folosit pentru înregistrarea, admiterea şi definirea statutului
dispozitivelor terminale ale reţelei.
Protocolul de semnalizare apel H.225.0.

Protocolul de control al canalelor logice H.245.
Fig. 1.7 Stiva de protocoale H.323 în mediul IP
Figura 1.7 [2] prezintă locul de plasare al protocoalelor de

semnalizări RAS, H.225.0 şi H.245 în reţeaua bazată pe IP.
Tot aici se observă şi modul cum rulează protocoalele
aplicaţiilor, fluxurilor media – de date, audio şi video. Săgeata
dintre H.245 şi H.225.0 subliniază că mesajele H.245 pot fi
tunelate în H.225.0.
14
1.6.1 Protocolul RAS
RAS este protocolul de semnalizare utilizat între gateway

şi gatekeeper [3]. Canalul RAS este deschis înainte de orice
alt canal şi este independent de canalele de transport media
şi de semnalizarea de apel (figura 1.8). RAS foloseşte User
Datagram Protocol (UDP), porturile 1719 (mesaje H.225
RAS) şi 1718 (descoperire GK multicast).
Fig.1.8 Deschiderea canalului RAS
Prin mesajele RAS se efectuează un şir de proceduri

după cum urmează:
Descoperirea gatekeeper-ului.
Înregistrarea dispozitivelor terminale la GK.
Controlul admiterii dispozitivelor terminale în reţea.
Localizarea dispozitivelor terminale.
Controlul benzii de trecere (ratei de biţi) în procesul
servirii apelului.
Obţinerea informaţiilor de stare de la dispozitivele
terminale.
15
Descoperirea gatekeeper-ului este o procedură prin care
dispozitivul final determină GK pentru a se înregistra la el.
Acest lucru poate fi realizat manual sau automat.
În cazul procedurii manuale dispozitivul final este
configurat cu adresa de transport a gatekeeper-ului asociat.
În acest fel, dispozitivul ştie apriori cu care gatekeeper el este
asociat şi deci se poate înregistra la el.
Descoperirea GK în mod automat se efectuează cu
ajutorul mesajelor de descoperire GK (tabelul 1.1):
Tabelul 1.1 Descoperirea GK

GRQ Cerere transmisă de dispozitivul
(Gatekeeper Request) final la GK.
GCF Răspuns de la GK în care se
(Gatekeeper Confirm) indică adresa de transport a
canalului RAS.
GRJ Răspuns al GK în caz de
(Gatekeeper Reject) respingere a înregistrării.
Dispozitivul final transmite în mod multicast mesajul GRQ

la portul UDP 1718 (bine-cunoscut). Unul sau mai multe GK
pot răspunde cu mesajul de confirmare GCF în care se
conţine adresa de transport a canalului RAS (figura 1.9).
Terminal Gatekeeper
GRQ
GCF/GRJ
Fig.1.9 Descoperire GK automată
16
Dacă răspunsul este primit de la mai mulţi GK atunci
dispozitivul terminal va alege unul la care se va înregistra în
continuare.
Înregistrarea este procesul prin care dispozitivul final se
alătură la o zonă şi informează gatekeeper-ul despre
adresele sale de transport şi lista adreselor alias.
Înregistrarea trebuie să se producă înainte de orice apel şi
poate să se efectueze periodic în funcţie de necesităţi.
În tabelul 1.2 sînt definite mesajele RAS de înregistrare şi
de anulare a înregistrării dispozitivelor finale la GK.
Tabelul 1.2 Înregistrarea la gatekeeper

RRQ Trimis de dispozitivul terminal la
(Registration_Request) GK cu adresa canalului RAS.
RCF Răspuns al GK care confirmă
(Registration_Confirm) înregistrarea dispozitivului final.
RRJ Răspuns al GK care respinge
(Registration_Reject) înregistrarea dispozitivului final.
URQ Trimis de dispozitivul final sau de
(Unregister_Request) GK la anularea înregistrării.
UCF Trimis de dispozitivul final sau de
(Unregister_Confirm) GK pentru confirmarea anulării
înregistrării.
URJ Arată că înregistrarea dispozitivul
(Unregister_Reject) final nu a fost anulată de GK
Dispozitivul final trimite cererea de înregistrare RRQ la

adresa de transport a canalului RAS al GK-lui care a fost
primită în procesul de descoperire (figura 1.10). Gatekeeper-
ul poate confirma înregistrarea (RCF) sau o respinge (RRJ).
17
Terminal Gatekeeper
RRQ
RCF sau RRJ
Fig.1.10 Iniţierea înregistrării terminalului la GK
Dispozitivul final poate anula înregistrarea prin trimiterea

cererii URQ la gatekeeper (figura 1.11). Acest lucru permite
dispozitivului să modifice adresa alias asociată cu adresa de
transport sau invers. Gatekeeper-ul răspunde fie cu un mesaj
de confirmare UCF sau respingere URJ în conformitate cu
politica sa.
Terminal Gatekeeper
URQ
UCF sau URJ
Fig.1.11 Iniţierea anulării înregistrării terminalului la GK
Gatekeeper-ul poate iniţia anularea înregistrării unui

terminal prin trimiterea cererii URQ la acest dispozitiv
(figura 1.12). Terminalul răspunde cu un mesaj de confirmare
- anulare înregistrare (UCF). Înainte de iniţierea unui apel
dispozitivul final va trebui să se re-înregistreze, posibil la alt
Gatekeeper.
18
Terminal Gatekeeper
URQ
UCF
Fig.1.12 Iniţierea de GK a anulării înregistrării terminalului
Controlul admiterii dispozitivelor terminale la resursele de

reţea se efectuează prin cererea Admission Reguest (tabelul
1.3). Cererea de admitere ARQ este trimisă de dispozitivul
final către GK la iniţierea oricărui apel.
Tabelul 1.3 Mesajele de admitere

ARQ Încercare de un dispozitiv final a iniţia
(Admission_Request) un apel.
ACF Autorizaţie de GK la admiterea
(Admission_Confirm) apelului. Acest mesaj conţine adresa
IP a gateway-ului terminal şi permite
GW solicitant să iniţieze procedura de
semnalizare pentru controlul apelului.
ARJ Refuză cererea dispozitivului final a
(Admission_Reject) avea acces la reţea pentru acest apel
particular.
În mesaj se conţine identificatorul dispozitivului care a
trimis cererea ARQ şi adresele necesare ale dispozitivului
solicitat. Suplimentar se indică plafonul de sus al ratei de biţi
de transmitere şi de recepţie a traficului utilizatorilor. La
admiterea apelului, Gatekeeper-ul include în mesajul de
confirmare ACF valoarea plafonului de sus al ratei de biţi şi
adresa de transport a canalului de semnalizare a terminalului
19
solicitat. Dacă lăţimea de bandă nu este disponibilă GK
trimite mesajul ARJ.
Localizarea dispozitivelor terminale (tabelul 1.4).
Dispozitivul terminal sau gatekeeper-ul care are adresa alias
pentru un punct final şi ar dori să determine informaţiile lui de
contact (adresele canalului de semnalizare şi canalului RAS)
poate emite cererea de locaţie (LRQ). Acest mesaj poate fi
trimis la adresa canalului RAS al unui anumit GK sau în mod
multicast pe adresa bine cunoscută ( Gatekeeper`s Discovery
Multicast) a mai multor GK-e. Gatekeeper-ul la care punctul
final solicitat este înregistrat va răspunde cu mesajul de
confirmare a locaţiei (LCF) care conţine datele de contact ale
dispozitivului solicitat sau ale sale.
Tabelul 1.4 Mesajele de localizare

LRQ Solicită datele de contact pentru una sau
(Location_Request) mai multe adrese E.164.
LCF Confirmare de locaţie trimisă de GK şi
(Location_Confirm) conţine adresele canalului de semnalizare
sau canalului RAS, ale sale sau ale
dispozitivului terminal solicitat.
LRJ Locaţie respins-trimis de GK-ele care au
(Location_Reject) primit cererea de localizare LRQ şi la care
dispozitivul terminal nu este înregistrat.
Gatekeeper-ul la care dispozitivul terminal solicitat nu

este înregistrat nu va răspunde la LRQ dacă cererea a fost
primită la adresa „Discovery multicast”.
Controlul ratei de biţi. Controlul ratei de biţi (lăţimii de
bandă) se efectuează iniţial prin secvenţa mesajelor de
admitere (ARQ / ACF / ARJ). Cu toate acestea, gatekeeper-ul
are posibilitatea să schimbe rata de biţi a dispozitivului
terminal în serviciu. Tabelul 1.5 defineşte mesajele RAS de
control ale ratei de biţi.
20
Tabelul 1.5 Mesajele de control ale ratei de biţi
BRQ Cererea de creştere sau scădere a
(Bandwidth_ ratei de biţi a apelului în desfăşurare
Change_Request) trimisă de dispozitivul terminal la GK.
BCF Mesaj trimis de gatekeeper dacă
(Bandwidth_ confirmă acceptarea cererii de
Change_Confirm) modificare a ratei de biţi.
BRJ Mesaj trimis de gatekeeper dacă
(Bandwith_ respinge cererea de modificare a ratei
Change_Reject) de biţi.
Dacă iniţiatorul schimbării ratei de biţi este GK-ul atunci

dispozitivul terminal obligatoriu acceptă propunerea de
reducere a vitezei şi decide de sine stătător în caz de
creştere a ei.
Tabelul 1.6 Mesaje informaţii de stare

IRQ Cerere de stare trimisă de
(Information_Request) gatekeeper la dispozitivul terminal.
IRR Mesaj trimis de dispozitivul terminal la
(Information_Request_ gatekeeper ca răspuns la IRQ sau
Response) dacă ultimul a solicitat actualizarea
periodică a informaţiei de stare.
IACK Confirmare trimisă de gatekeeper ca
(Informaţion_Acknowle răspuns la mesajul IRR.
dgement)
INACK Infirmare trimisă de gatekeeper ca
(Information_Negative răspuns la pierderea sau reţinerea
_Acknowledgement) mesajului IRR.
Informaţiile de stare. Dispozitivul terminal poate colecta şi

raporta informaţii despre apelurile servite care se folosesc
pentru calculele contabile sau de facturare. Gatekeeper-ul
21
poate solicita ca dispozitivul terminal să raporteze aceste
informaţii (tabelul 1.6).
Gatekeeper-ul nu ar trebui să solicite un anumit tip de
informaţii de la dispozitivul terminal dacă el nu a anunţat
despre abilitatea sa de a raporta aceste informaţii.
În faza finală de terminare a unui apel dispozitivul
terminal trimite la GK mesajul DRG (Disengage Request) la
care el va răspunde cu DCF (Disengage Confirm).
1.6.2 Protocolul de semnalizare apel H.225.0
Protocolul de semnalizare apel H.225.0[3] este utilizat

pentru stabilirea conexiunilor între dispozitivele terminale ale
reţelei H.323. Codificarea mesajelor este realizată prin
utilizarea recomandării ITU-T Q.931[4] elaborată anterior
pentru reţelele ISDN. În tabelul 4[3] sînt prezentate mesajele
obligatorii şi opţionale ale protocolului H.225.0 preluate din
Q.931 pentru reţeaua bazată pe pachete. În continuare vor fi
expuse mesajele protocolului H.225.0 mai des utilizate în
procesul de semnalizare a apelului.
SETUP - mesaj trimis de partea apelantă în scopul
stabilirii unei conexiuni. Se transmite către portul TCP bine
cunoscut 1720 al dispozitivului terminal solicitat.
CALL PROCEEDING - mesaj prin care dispozitivul
terminal apelant este informat că apelul este acceptat şi este
în proces de servire.
ALERTING - mesaj de informare a dispozitivului apelant
că utilizatorul solicitat nu este ocupat şi i-a fost trimis
semnalul despre intrarea de apel.
CONNECT - mesaj de informare a dispozitivului apelant
că utilizatorul solicitat a acceptat apelul. E posibil ca mesajul
să conţină adresa de transport a canalului de control H.245.
22
RELEASE COMPLETE – mesaj trimis de dispozitivul
terminal apelat sau apelant cu scopul de eliberare a
conexiunii.
Un scenariu de stabilire a unui apel cu implicarea GK-lui
este prezentat de figura 1.13.
Terminal 1 GK Terminal 2
ARQ(1)
ACF(2)
Setup (3)
Call proceeding (4)
ARQ(5)
ACF(6)
Alerting(7)
Connect(8)
Mesaje H.245
Mesaj RAS
Mesaj semnalizare apel H.225/0
Fig.1.13 Exemplu de scenariu semnalizare apel
23
Odată ce părţile au făcut schimb de mesaje de
semnalizare apel H.225.0, terminalele vor trece la stabilirea
canalului de control. Procedurile recomandării H.245 sînt
folosite peste canalul de control H.245 în scopul schimbului
de capabilităţi şi de deschidere a canalelor media.
Un canal de semnalizare H.225.0 permite transmisiunea
mesajelor diferitor apeluri. Diferenţierea dintre mesaje se face
după eticheta call reference. Aceasta permite GW-lui să
reducă simţitor timpul necesar pentru stabilirea conexiunilor.
Mesajele H.225.0 în sine sînt codate în conformitate cu
regulile de codare pachet (PER- Packed Encoding Rules) ale
ASN.1 (Abstract Syntax Notation One) şi transportate de
protocolul TCP.
1.6.3 Protocolul de control al canalelor logice H.245
Recomandarea ITU-T H.245 „Protocolul de control pentru

comunicaţii multimedia” (05/2011) specifică sintaxa şi
semantica mesajelor de control a canalelor logice, precum şi
un şir de proceduri folosite pentru negocierea în bandă la
începutul sau în timpul comunicării. Fiecare terminal deschide
doar un singur canal H.245 cu un alt dispozitiv. Procedurile
desfăşurate pe canalul de control H.245 asigură schimbul de
capabilităţi dintre terminale şi deschiderea canalelor pentru
transmisiunea fluxurilor media. Acest canal logic cu numărul 0
permite terminalelor:
a) determinarea dispozitivului terminal master şi terminal
sclav în scopuri de management de protocol;
b) schimbul de capabilităţi şi preferinţe de comunicare;
c) deschiderea şi închiderea canalelor logice bi- sau
unidirecţionale pentru fluxurile media;
d) alegerea modului de funcţionare;
e) determinarea timpului de latenţă dus-întors;
f) efectuarea semnalizării pe bucla locală în scopuri de
întreţinere.
24
Procedurile de determinare master-slave sînt utilizate
pentru a rezolva conflictele între două dispozitive terminale
care, de exemplu, încearcă să deschidă un canal
bidirecţional. Conform procedurii, două puncte finale fac
schimb de mesaje MasterSlaveDetermination pentru a
determina care terminal va fi master şi care slave. Fiecare
terminal poate opera fie ca master sau ca sclav. Dispozitivul
terminal stabileşte în cîmpul TerminalType o valoare care
corespunde tipului sau ( vezi tabelul 1 [2]) şi un număr
aleatoriu în intervalul de la 0 pînă la ( în cîmpul
StatusDeterminationNumber. Master va deveni acea entitate
care are în cîmpul TerminalType un număr mai mare sau,
dacă aceste cifre sînt egale, cea care are valoare înscrisă
mai mare în cîmpul StatusDeterminationNumber. Ca răspuns
la mesajele MasterSlaveDetermination primite, ambele
dispozitive transmit mesaje de confirmare
MasterSlaveDetermlnatlonAck, unde se indică care
echipament va fi master şi care sclav în această comunicare.
Schimbul de capabilităţi între dispozitivele terminale
urmează procedurile definite în ITU-T H.245 [5], care prevăd
tratarea în mod separat a capabilităţilor de recepţie şi de
transmisie. Capabilităţile la recepţie determină abilitatea
terminalului de a primi şi procesa fluxurile informaţiilor primite.
Emiţătorul va limita conţinutul informaţiilor transmise la ceea
ce a indicat receptorul că este capabil a o primi. Capabilităţile
la emitere descriu abilitatea terminalului de a transmite fluxuri
de informaţii. Descrierea dată oferă terminalului receptor
posibilitatea să aleagă moduri de operare în care preferă să
primească informaţia.
Coordonarea modului de funcţionare între terminale se
efectuează prin schimbul de mesaje TerminalCapabilitySet. În
aceste mesaje este inclus tabelul CapabilityTable unde
fiecărui tip de audio sau video codec i se atribuie un anumit
număr. De exemplu, codecurilor audio G.723.1, G.728 şi
25
video H.263 le-au fost atribuite numere separate (1, 2 şi
respectiv 3).
Numerele secvenţiale enunţate se grupează în structuri
numite AlternativeCapabilitySet. Fiecare set indică modul în
care terminalul este capabil să opereze. De exemplu, o listă
AlternativeCapabilitySet {G.711, G.723.1, G.728} înseamnă
că terminalul poate funcţiona în oricare dintre aceste moduri
audio, dar numai în unul. Aceste seturi de capabilităţi
alternative se grupează în structuri SimultaneousCapabilities
de funcţionare simultană. De exemplu, structura
SimultaneousCapabilities care conţine două liste în
AlternativeCapabilitySet, anume {H.261, H.263} şi {G.711,
G.723.1, G.728}. Aceasta înseamnă că terminalul poate
funcţiona simultan cu un codec video şi oricare dintre codec-
urile audio.
Capabilităţile actuale stocate în CapabilityTable sînt
adesea mai complexe decît prezentate aici. Pentru detalii se
poate consulta [5].
Dispozitivele terminale au posibilitatea la orice fază a
conexiunii să adauge noi funcţionalităţi sau să excludă unele
deja enunţate anterior prin transmiterea mesajelor
TerminalCapabilitySet. Terminalul care a recepţionat mesajul
TerminalCapabilitySet va trimite mesajul de confirmare
TerminalCapabilitySetAck.
Deschiderea şi închiderea canalelor logice bi- sau
unidirecţionale pentru fluxurile media. Pe fiecare canal logic
se transmit fluxuri informaţionale de la un emiţător la unul sau
mai multe receptoare. Fiecare dintre ele este identificat printr-
un număr de canal logic, care este unic pentru fiecare direcţie
de transmisie. Canalele logice sînt deschise şi închise
folosind mesajele şi procedurile ITU-T H.245:
Terminalul iniţiator va trimite mesajul
OpenLogicalChannel. În cazul în care canalul logic transportă
fluxuri media utilizînd RTP (audio sau video) mesajul
26
OpenLogicalChannel va include parametrul MediaControl-
Channel care conţine adresa de transport a protocolului de
control RTCP. Terminalul receptor răspunde cu un mesaj
OpenLogicalChannelAck. În cazul în care canalul logic va
transporta datele media folosind RTP unicast, atunci mesajul
OpenLogicalChannelAck va include atît parametrul Media-
Channel cu adresa de transport a protocolului RTP, cît şi
parametrul MediaControlChannel cu adresa de transport a
canalului RTCP. Dacă cererea a fost pentru un canal logic
unidirecţional, mesajul OpenLogicalChannelAck indică
acceptarea canalului unidirecţional. În cazul unei cereri pentru
un canal logic bidirecţional, mesajul indică acceptarea
canalului logic bidirecţional şi indică parametrii corespunzători
pentru canalul revers.
Închiderea canalelor logice poate fi efectuată cu mesajul
CloseLogicalChannel care este folosit de regulă pentru a
sprijini servicii suplimentare, cum ar fi ”plasat în aşteptare”.
Pentru o încheiere de conexiune obişnuită terminalele fac
schimb de mesaje EndSessionCommand. După schimbul de
aceste mesaje sînt închise nu numai canalele logice dar şi
canalul de control H.245.
Alegerea modului de funcţionare este utilizat de
terminalul receptor pentru a solicita anumite moduri de
transmisie de la terminalul de transmisie. De fapt este o listă
în ordinea de preferinţă (cel mai de preferat în primul rînd) a
modurilor în care terminalul ar dori să le primească. Fiecare
mod este descris cu ajutorul unui ModeDescription care la
rîndul său este definit de unul sau mai multe elemente
ModeElements.
ModeElement indică tipul de flux elementar care este
solicitat şi, opţional, modul de multiplexare. Tipul de flux
elementar poate fi: Videomode, AudioMode, DataMode,
EncryptionMode şi H235Mode. H235Mode indică faptul că se
solicită criptarea informaţiei media.
27
Determinarea timpului de latenţă dus-întors este utilizat
de entitatea Mode Request Signalling Entity în caz de
timeout. Terminalul de ieşire trimite cererea
RoundTripDelayRequest la care terminalul de intrare
răspunde prin RoundTripDelayResponse. Timpul de
propagare a semnalului între două terminale de comunicare
determină întârzierea dus-întors.
Semnalizarea pe bucla locală în scopuri de
întreţinere foloseşte un set de mesaje. Cererea
MaintenanceLoopRequest solicită un anumit tip de buclă. De
exemplu, mesajele mediaLoop şi logicalChannelLoop solicită
buclă locală pe un singur canal logic (indicat de
LogicalChannelNumber), în timp ce mesajul systemLoop se
referă la toate canalele logice. Partea vizată răspunde prin
MaintenanceLoopAcknowledge pentru a confirma că
terminalul va efectua bucla conform solicitării sau prin
MaintenanceLoopReject, dacă terminalul nu va efectua bucla.
La primirea comenzii MaintenanceLoopCommandOff
terminalul va deconecta toate buclele şi va restabili canalele
audio, video şi de date la starea lor normală.
1.7 Exemplu setare apel cu implicarea GK

În finalul expuneri protocolului H.323 se va examina un
exemplu de setare a unui apel între două terminale (de
exemplu, telefoane IP) ale reţelei H.323 (figura 1.14). Se
presupune că în reţea se utilizează gatekeeper-ul. Ambele
terminale sînt înregistrate la acest GK cu utilizarea mesajelor
RAS (vezi tabelul 1.2).
28
TERMINAL1 GK TERMINAL2
Admision Request
Amision Confirm
Setup
CallProceeding
Admision Request
Amision Confirm
Alerting
Connect
TerminalCapabilitySet
MasterSlaveDetermination
TerminalCapabilitySet + Ack
MasterSlaveDetermination +Ack
TerminalCapabilitySetAck
MasterSlaveDeterminationAck
OpenLogicalChannel
OpenLogicalChannel+Ack
OpenLogicalChannelAck
Fluxuri informaționale RTP
EndSessionCommand
EndSessionCommand
ReleaseComplete
DisengageRequest DisengageRequest
DisengageConfirm DisengageConfirm
Fig. 1.14 Fazele de stabilire a unei conexiuni

Notă: RAS; H.225.0; H.245.
29
Terminalul 1, care iniţiază apelul, cunoaşte numărul
apelat dar nu cunoaşte adresa IP asociată cu acest număr.
De aceea el trebuie să solicite permisiunea GK pentru a
efectua apelul prin trimiterea cererii de admitere. Cererea de
admitere (ARQ) va conţine numărul apelat care va fi rezolvat
la adresă IP a terminalului 2. Prin răspunsul său ACF
gatekeeper-ul anunţă această adresă terminalului1 (modelul
de apel direct, nu prin GK). Terminalul 1 va deschide un canal
de semnalizare H.225.0 la adresa furnizată de GK şi trimite
mesajul Setup. Terminalul 2 va răspunde mai întâi cu mesajul
H.225.0 CallProceeding pentru a indica că a început să
lucreze la stabilirea apelului. După aceea terminalul 2 va cere
permisiunea de apel de la GK cu mesajul ARQ. La care GK-ul
răspunde cu confirmarea de admitere ACF. Telefonul apelat
începe să sune şi acest lucru este semnalat celeilalte părţi cu
mesajul H.225.0 de alertare. Partea apelată ridică receptorul
şi terminalul 2 semnalează că apelul a fost acceptat prin
trimiterea mesajului H.225.0 Connect. Prin acest mesaj se
transmite şi adresa canalului de control H.245.
Din acest moment părţile vor trebui să negocieze
parametrii pentru canalele audio, opţional şi video. Pentru
aceste negocieri sînt folosite mesajele protocolului H.245.
Terminalul 1 deschide un canal TCP la adresa H.245 care a
primit-o prin mesajul Connect. Terminalele pot începe
schimbul de mesaje H.245. Negocierea H.245 are trei părţi:
Decide care terminal va fi "master" şi care "slave".
Acest lucru este mai important pentru conferinţe cu mai mulţi
participanţi, decît pentru un apel cu două părţi. Dar totuşi se
efectuează şi în acest caz.
Schimbul de informaţii cu privire la setul de capacităţi
ale fiecărei pârti. Fiecare terminal trebuie să ştie ce codec-uri
audio şi video acceptă cealaltă parte.
Negocierea canalelor logice prin care se decide cu
privire la parametrii canalului audio (opţional şi video) - adică
30
ce codec-uri vor fi utilizate şi care sînt adresele IP şi porturile
pentru fluxurile RTP.
În cele din urmă, cele două terminale pot începe să
trimită fluxurile informaţionale RTP şi cei doi se vor auzi unul
pe altul. Reţineţi că fiecare din cele două direcţii pot fi
codificate cu diferite codecuri.
La terminarea apelului cînd una dintre părţi pune
receptorul pe furcă se desfăşoară următoarele evenimente:
1. Terminalul 1 care a iniţiat finalizarea apelului va opri
transmiterea fluxurilor RTP, va închide canalele logice şi va
transmite pe canalul de control mesajul H.245
EndSessionCommand, ceea ce înseamnă că utilizatorul
doreşte să elibereze conexiunea. De la terminalul 2 se
aşteaptă mesajul de răspuns EndSessionCommand şi apoi
canalul de control H.245 se închide.
2. În cazul în care canalul de semnalizare H.225.0 este
încă deschis, terminalul1 trimite mesajul ReleaseComplet.
3. Fiecare dintre cele două terminale informează GK-ul
despre finalizarea apelului cu mesajul DRQ iar gatekeeper-ul
confirmă cu mesajul DCF.
Scopul acestui exemplu de conexiune a fost a oferi o
privire de ansamblu. Pentru mai multe detalii se poate
consulta standardul H.323 [2].
31
2. PROTOCOLUL H.248/MEGACO
2.1. Sumar
Protocolul de control al gateway-lui H.248/MEGACO

(MEdia GAteway COntrol) a fost elaborat separat de Uniunea
internaţională a telecomunicaţiilor ITU şi de Grupul operativ
de inginerie a internetului (Internet Engineering Task Force -
IETF). Primele versiuni ale protocolului au fost publicate în
anul 2000 de ITU la recomandarea H.248, iar de IETF în
standardul RFC 3015 numit Megaco. Ulterior în cadrul ITU
protocolul a evoluat spre versiunea a doua H.248.1, publicată
în 2002, apoi versiunea a treia din 2005, pe cînd IETF a
publicat în 2003 prin standardul Mecago RFC 3525 o
dezvoltare a versiunii 1. După unirea a două variante ale
protocolului ITU şi IETF într-un program comun de
dezvoltare, RFC 3525 a fost declarat istoric. Toată
responsabilitatea pentru dezvoltarea de mai departe a
protocolului de control a GW-lui a fost preluată de ITU. În
prezent este în vigoare recomandarea H.248.1 versiunea 3
din martie 2013 [6]. Extensiile H.248.1 apar ca noi
recomandări, suplimentare, care sînt numerotate H.248.XX.
La momentul scrierii acestui curs de prelegeri au fost
publicate recomandările numerotate pînă la XX=93, anume
H.248.93 din octombrie 2014.
Pentru a realiza o mai mare scalabilitate, în
recomandarea H.248.1 funcţia de gateway H.323 se
descompune (în eng. decompose) în subcomponente
funcţionale media gateway (MG) şi media gateway controler
(MGC) (figura 2.1).
Acest lucru permite, de asemenea, ca gateway-urile să
fie compuse din componente de la mai mulţi furnizori şi să fie
distribuite pe diferite platforme fizice.
32
Reţea comutaţie pachete IP
MGC
H.248 H.248
MG1 RTP MGn
E1 E1
PSTN/ISDN PSTN/ISDN
Fig. 2.1 Descompunerea media gateway H.323
Recomandarea H.248.1 defineşte protocoalele utilizate

între elementele unui astfel gateway descompus fizic. Relaţia
componentelor protocolului MEGACO este de tip stăpîn-sclav
(eng. master-slave). Un MGC (master) poate dirija unul sau
mai multe MG-uri (slaves) pe cînd un MG logic sau fizic se
poate înregistra doar la un singur MGC.
2.2. Modelul de conexiune H.248
Înainte de a descrie procedurile protocolului şi pentru a

înţelege acţiunile comenzilor H.248 este necesar a vedea
cum arată modelul intern al unui MG. Acest model MG este o
construcţie logică şi nu implică nici un fel de constrîngeri
33
asupra hardware sau firmware. Figura 2.2 prezintă structura
unui exemplu de model de conexiune H.248.
Terminaț ie
Terminaţie Canal SCN
Flux RTP Terminaţie
Context Canal SCN
Terminaţie Terminaţie
Flux RTP Canal SCN

Context Context NULL
Terminaţie Terminaț ie
Flux RTP Canal SCN
Context
Gateway media
Fig. 2.2 Exemplu de model de conexiune H.248.1
Modelul de conexiune al protocolului prezintă entităţile

logice din cadrul Media Gateway (MG) care sunt controlate
de către Media Gateway Controler (MGC). Principalele
abstracţii utilizate în acest model de conexiune sînt terminaţia
şi contextul.
34
Terminaţia iniţiază sau opreşte unul sau mai multe fluxuri
media. De exemplu, într-o conferinţă multimedia, în care
terminaţia poate fi multimedia, ea porneşte sau opreşte mai
multe fluxuri media.
Contextul este o asociere logică dintre cîteva terminaţii.
Există un tip special de context, numit contextul NULL, care
conţine toate tipurile de terminaţii care nu sunt prezente în
orice alt context. De exemplu, într-un gateway de acces
descompus, toate liniile inactive (libere) sînt reprezentate de
terminaţii în contextul NULL.
Diagrama din figura 2.2 reprezintă cîteva exemple de
posibile contexte. Cutia asterisc reprezintă asocierea logică a
terminaţiilor incluse în context.
2.2.1 Terminaţia
Terminaţiile sînt de două tipuri, fizice şi efemere.

Terminaţia fizică reprezintă o entitate fizică, de exemplu, un
canal TDM. Ea există atît timp cît este acest canal în GW.
Terminaţia efemeră reprezintă un flux RTP şi există doar pe
durata sesiunii.
Terminaţia este descrisă de un număr de proprietăţi
caracteristice care sînt grupate într-un set de descriptori. Ea
poate genera sau recepţiona anumite semnale. Terminaţiile
pot fi programate pentru a detecta evenimente ale căror
apariţie poate declanşa acţiuni din partea MG sau mesaje de
notificare a MGC.
Protocolul H.248 poate fi folosit pentru a crea noi
terminale şi modifica proprietăţile celor existente. Aceste
modificări includ posibilitatea de a adăuga sau elimina
evenimente şi/sau semnale.
Fiecare terminaţie are identificator unic (TerminationID),
atribuit de către MG în momentul creării acesteia. De
exemplu, pentru o terminaţie fizică, în calitate de identificator,
35
poate servi numărul fluxului digital E1 şi numărul slotului timp
în acest flux. Dacă cererea trebuie adresată la toate
terminaţiile atunci se foloseşte un identificator comun Root.
Cu TerminationID se utilizează şi un mecanism de adresare
în grup (wildcards): ALL şi CHOOSE. Primul este utilizat
pentru a se adresa simultan la mai multe terminale, al doilea -
oferă gateway-ului dreptul de selectare a terminaţiei
corespunzătoare.
2.2.2 Contextul
Contextul este o asociere între un număr de terminaţii

prin care se descrie topologia conexiunii. Numărul maxim de
terminaţii într-un context depinde de proprietăţile MG.
Gateway-urile care oferă doar conectivitate punct-la-punct
permit cel mult două terminaţii pe context, iar cele care susţin
conferinţe multipunct permit trei sau mai multe terminaţii pe
context.
Atributele contextului sînt:
Identificatorul (ContextID).
Descriptorul topologiei. Topologia contextului descrie
fluxurile informaţionale între terminaţiile lui, deci în interiorul
GW-lui. Contrar, proprietatea similară a unei terminaţii (de
exemplu, "SendOnly", "RecvOnly") descrie fluxurile
informaţionale de ieşire/intrare la gateway.
Indicatorul de prioritate. El indică GW-lui prioritatea cu
care trebuie să fie tratat contextul. De exemplu, la restartarea
gateway-lui, atunci cînd o mulţime de contexte trebuie tratate
simultan, MGC poate utiliza indicatorul de prioritate pentru a
nivela traficul şi controla succesiunea pornirii contextelor.
Prioritatea poate avea 16 nivele, în creştere de la 0 pînă la
15.
Indicator pentru apelurile de urgenţă cu cea mai înaltă
prioritate.
36
Protocolul are comenzi pentru a crea contexte, a adăuga
sau a scoate terminaţii din contextele existente, precum şi
pentru a deplasa terminaţia dintr-un context în altul. Contextul
se şterge implicit atunci cînd se lichidează ultima terminaţie
rămasă.
2.3 Comenzile H.248
Protocolul H.248 prevede 8 comenzi pentru manipularea

contextelor şi terminaţiilor. Cele mai multe comenzi sînt
trimise de MGC pentru controlul MG. Excepţie fac comenzile
Notify şi ServiceChange: Notify este trimisă de la Media
Gateway la Media Gateway Controller, iar ServiceChange
poate fi trimisă de ambele entităţi.
Comenzile protocolului H.248 cu descrierea lor de
ansamblu:
1. Add. Comanda Add adaugă o terminaţie la contextul
indicat prin ContextID. Dacă în comandă nu se specifică
contextul, atunci va fi creat un nou context. În cazul cînd în
loc de TerminationID se indică simbolul de grup $, atunci se
creează o nouă terminaţie efemeră care va fi atribuită
contextului.
2. Modify. Comanda Modify modifică proprietăţile
terminaţiei, evenimentele recepţionate sau semnalele trimise
de terminaţie.
3. Subtract. Comanda Subtract elimină terminaţia din
context. În răspuns la această comandă MG poate să
transmită MGC date statistice despre participarea terminaţiei
în context. Dacă comanda exclude ultima terminaţie din
context atunci se lichidează şi contextul.
4. Move. Comanda Move deplasează terminaţia dintr-ul
context în altul. Ea nu se foloseşte pentru mutarea terminaţiei
în contextul NULL sau scoaterea terminaţiei din acest
37
context, deoarece aceste manipulări se efectuează cu
ajutorul comenzilor Add şi Subtract.
5. AuditValue. Cu această comandă MGC cere informaţii
curente privind proprietăţile terminaţiei, evenimentele recente
sau semnalele transmise în canal, precum şi datele statistice
acumulate la moment.
6. AuditCapability. Cu această comandă MGC solicită
de la MG informaţii privind toate valorile posibile pentru
proprietăţi, evenimente şi semnale ale terminaţiei.
7. Notify. Comanda Notify permite MG-ului să informeze
MGC de apariţia unor evenimente în gateway.
8. ServiceChange. Comanda permite MG-ului să
informeze controller-ul MGC că o terminaţie sau un grup de
terminaţii este pe cale să fie scos din serviciu sau tocmai va fi
întors în serviciu. ServiceChange este de asemenea folosită
de către MG ca să anunţe disponibilitatea sa de înregistrare
la MGC, precum şi să notifice MGC de intenţia sau
efectuarea restartării MG. Prin trimiterea acestei comenzi
MGC poate anunţa MG despre handover (transfer). MGC
poate utiliza de asemenea ServiceChange pentru a instrui
MG să introducă sau să scoată din serviciu o terminaţie sau
un grup de terminaţii.
2.4 Descriptorii H.248
Parametrii unei comenzi sînt numiţi descriptori.

Descriptorul se defineşte ca element sintactic al protocolului
care grupează proprietăţile conexe. De exemplu, proprietăţile
unui flux media din MG poate fi setat de MGC prin includerea
descriptorilor corespunzători în comandă. Un descriptor
constă dintr-un nume şi o listă de elemente. Unele elemente
pot avea valori.
Aşadar parametrii comenzii sînt structuraţi într-un număr
de descriptori. În general, formatul text al unui descriptor este:
38
DescriptorName=<someID>{parm=value,parm=value...}.
Mai jos se enumeră unii dintre aceşti descriptori.
Mux. Descriptorul multiplexare Mux descrie tipul
purtătoarelor fluxurilor multimedia. Descriptorul include
următoarele tipuri de multiplexare: H.221, H.223, H.226, V.76
şi N × 64K. Sînt posibile extensii.
Media. Descriptorul Media specifică parametrii pentru
toate fluxurile media. Aceşti parametri sînt structuraţi în doi
descriptori: TerminationState Descriptor, care specifică
proprietăţile unei terminaţii care nu este dependentă de flux şi
unul sau mai mulţi descriptori Stream fiecare dintre care
descrie un singur flux media. În cadrul descriptorului Stream
există pînă la patru descriptori subsidiari: LocalControl, Local,
Remote şi Statistics. Relaţia ierarhică dintre aceşti descriptori
este astfel:
Media Descriptor
TerminationState Descriptor
Stream Descriptor
LocalControl Descriptor
Local Descriptor
Remote Descriptor
Statistics Descriptor
TerminationState. Descriptorul stare terminaţie

TerminationState conţine proprietatea ServiceStates,
proprietatea EventBufferControl şi posibil alte proprietăţi care
nu sînt specifice fluxului media.
Proprietatea ServiceStates descrie starea generală a
terminaţiei. O terminaţie poate fi în una din următoarele stări:
"Test", "OutOfService" sau "InService". Starea "Test" indică
faptul că terminaţia este testată, starea "OutOfService" indică
faptul că terminaţia nu poate fi utilizată în trafic, starea
39
"InService" indică faptul că o terminaţie poate fi sau este
utilizată în trafic normal. Starea implicită este "InService".
Proprietatea EventBufferControl specifică dacă
evenimentele detectate sînt memorate sau procesate imediat.
Stream. Descriptorul Stream specifică parametrii unui
singur flux bidirecţional.
LocalControl. Descriptorul LocalControl conţine
proprietăţile Mode, ReserveGroup şi ReserveValue, precum
şi cele care sînt specifice fluxului media.
Valorile permise pentru proprietatea Mode sînt: doar
trimite "SendOnly", doar recepţionează "RecvOnly", trimite şi
recepţionează "SendRecv", inactiv "Inactive" şi buclă locală
"loopback". Valorile "SendOnly", "RecvOnly" şi "loopback"
sînt în raport cu exteriorul contextului. De exemplu, dacă un
flux este setat în modul = "SendOnly" atunci terminaţia nu
pasează media recepţionate în context şi poate transmite
informaţia doar entităţilor în afara contextului. Valoarea
implicită pentru proprietatea Mode este inactiv "Inactive".
Proprietăţile ReserveValue şi ReserveGroup indică MG
ce resurse trebuie să rezerve cînd primeşte un descriptor
Local sau Remote. În cazul în care valoarea unei proprietăţi
Reserve este "True" (adevărat) atunci MG rezervă resurse
pentru toate cazurile specificate în descriptorii Local şi
Remote, dacă le are disponibile la moment. Dacă valoarea
este ”False” MG va rezerva un singur grup media din fiecare
descriptor Local şi Remote. Funcţiile ReserveValue şi
ReserveGroup sînt analogice. Prima indică MG să rezerve
resurse pentru un singur set de proprietăţi (de exemplu, un
singur codec cu atributele asociate acestuia), iar a doua
indică că MG trebuie să rezerve resurse pentru a sprijini un
grup sau mai multe grupuri fluxuri media.
Local şi Remote. MGC utilizează descriptorii Local şi
Remote pentru a indica MG să rezerve şi să aloce resurse
pentru decodarea şi codarea fluxurilor media la terminaţia la
40
care se aplică. Descriptorul Local se referă la proprietăţile
fluxurilor media pe care MG le primeşte de la entitatea
distantă. Descriptorul Remote se referă la proprietăţile
fluxurilor media pe care MG le trimite entităţii distante.
Events. Descriptorul Events conţine un RequestID şi o
listă de evenimente pe care Media gateway trebuie să le
detecteze şi despre care să raporteze. Sub eveniment se
înţelege, de exemplu, tonuri de disc sau de fax, ridicarea sau
punerea receptorului pe furcă etc. RequestID-ul este folosit
pentru a corela cererea cu notificările pe care aceasta le-ar
putea declanşa şi el este omis în cazul în care descriptorul
Events este gol (adică, evenimente nu se specifică).
Signals. Descriptorul Signals conţine setul de semnale
pe care gateway-ul îl solicită de la terminaţie. Aceste semnale
sunt, de exemplu, tonuri, anunţuri sau semnale legate de
butonul de furcă (hookswitch). Semnalele mai complexe pot
include o secvenţă de astfel de semnale simple.
Există trei tipuri de semnale:
• OnOff (OO) - semnalul durează pînă cînd este oprit, de
exemplu, de un descriptor Signals gol.
• TimeOut (TO) - semnalul durează pînă cînd o perioadă
anumită de timp expiră sau este oprit (ca mai sus).
• Brief (BR) - semnalul este foarte scurt şi se va opri de la
sine. În acest caz nu este nevoie de careva valoare de
timeout.
Audit. Descriptorul Audit specifică ce informaţii MGC
doreşte să verifice. Descriptorul de audit precizează lista de
descriptori sau proprietăţi individuale care urmează să fie
returnate de MG. Audit poate fi folosit în orice comandă
pentru a solicita de la MG trimiterea a oricărui descriptor cu
valorile curente referitor la evenimentele, semnalele,
statisticile şi proprietăţile sale. Printre descriptorii solicitaţi pot
fi: Mux, Event, Media, Signals, ObservedEvents, Statistics şi
alţii.
41
ServiceChange. Descriptorul ServiceChange se include
doar în comanda cu acelaşi nume şi indică ce tip de
schimbări se vor produce în serviciu. Descriptorul poate
conţine un şir de parametri după necesitate. Parametrul
Method indică, de exemplu, că terminaţiile specificate vor fi
scoase din serviciu cu careva reţinere sau imediat.
Parametrul Reason specifică cauza schimbării în serviciu,
parametrul Address determină adresa pentru comunicaţiile
ulterioare etc.
DigitMap. Descriptorul DigitMap descrie planul de
numerotare utilizat în reţea. DigitMap este un plan de apelare
rezident în Media gateway în corespundere cu care se
efectuează detectarea şi raportarea cifrelor primite de
terminaţie. Planul de numerotare poate fi descărcat în MG în
prealabil prin acţiuni de management sau definit într-un
descriptor DigitMap inclus în oricare din comenzile standard
ale protocolului utilizate pentru manipularea terminaţiei.
Colecţia de cifre a planului DigitMap este protejată de trei
cronometre, anume, timer de pornire (T), timer scurt (S) şi
timer lung (L).
1. Timerul de pornire (T) determină durata de aşteptare a
pornirii culegerii cifrelor adresei solicitate în corespundere cu
Digitmap. Cronometrul de pornire poate fi dezactivat (T = 0),
atunci MG va aştepta nelimitat venirea cifrelor.
2. Dacă în corespundere cu planul de apelare MG
determină că este nevoie de cel puţin încă o cifră, atunci el va
mai aştepta un timp egal cu durata determinată de timerul
lung (L) (de exemplu, 16 secunde).
3. În cazul în care şirul de cifre se potriveşte unui model
din digitmap, dar este posibil să mai sosească alte cifre care
ar duce la un alt model din planul de apelare, atunci MG nu
raportează imediat numărul solicitat dar mai aşteaptă un timp
egal cu valoarea cronometrului scurt (S) şi după aceea
decide care plan este vizat.
42
Pentru informaţii detaliate referitor la descriptorii
enumeraţi mai sus precum şi despre alţi descriptori ne
menţionaţi aici se poate consulta recomandarea H.248.1[6].
2.5 Tranzacţii H.248
Comenzile dintre Media Gateway Controller şi Media

Gateway sînt grupate în tranzacţii, fiecare dintre care este
identificată de un TransactionID. Tranzacţia constă din una
sau mai multe acţiuni. O acţiune la rîndul său este compusă
dintr-o serie de comenzi ale unui context (figura 2.3).
TRANZACŢIAx
Contextul1
(Acţiunea1) Comanda1 Comanda2
Comanda3 Comanda4
Contextul2
(Acţiunea2) Comanda1
Contextul3
(Acţiunea3) Comanda1 Comanda2
Comanda3
Fig.2.3 Tranzacţii, acţiuni şi comenzi
43
Comenzile în cadrul unei tranzacţii se procesează
secvenţial în ordinea în care ele apar în tranzacţie. După
procesarea fiecărei cereri TransactionRequest, se răspunde
prin TransactionReply. Răspunsul TransactionReply include
rezultatele procesării pentru toate comenzile din cererea
TransactionRequest corespunzătoare. TransactionReply
include valorile returnate pentru comenzile care au fost
executate cu succes şi descriptorul de eroare pentru
comenzile care au eşuat.
Într-un mesaj pot fi concatenate multiple tranzacţii.
Antetul mesajului include identitatea expeditorului.
Identificatorul mesajului (MID - Message Identifier) este un
nume prestabilit (de exemplu, adresa de domeniu, numele de
domeniu, numele dispozitivului) a entităţii care a transmis
mesajul. În mod implicit se recomandă utilizarea numelui de
domeniu.
Tranzacţiile dintr-un mesaj sînt tratate în mod
independent. Nu există nici o ordine prestabilită. Mesajul este
în esenţă doar un mecanism de transport.
2.6 Exemplu de setare a unui apel H.248
Exemplul de scenariu adus (figura 2.4) ilustrează

utilizarea elementelor protocolului H.248 pentru setarea unui
apel de la un GW rezidenţial la altul printr-o reţea bazată pe
IP. Pentru simplitate, în exemplu se presupune că ambele
gateway-uri rezidenţiale implicate în apel sînt controlate de
acelaşi Media Gateway Controller (vezi Apendix-ul I din [6]).
Solicitantul User A este conectat la RGW1, iar abonatul
solicitat – la RGW2. Exemplul descrie fazele unui apel de
succes. Procedura poate fi divizată în două procese: (1)
stabilirea conexiunii media RTP şi (2) eliberarea conexiunii
date după finalizarea sesiunii media. Pentru o mai bună
claritate se aduc listing-urile primelor comenzi cu descifrarea
detaliată.
44
RGW1 MGC RGW2
User A Service Change User B
Modify Service Change

Modify
A off-hook
Notify
Tonul disc Modify
Trimiterea
cifrelor Notify
Add
Modify Add
Revers
apel Apelare
B off-hook
Notify
Modify
Modify
RTP Media
AuditValue
AuditValueReply
B on-hook
Notify
A on-hook
Subtract
Subtract
Fig. 2.4 Scenariu de setare al unui apel H.248
În acest exemplu adresele IP sînt: pentru RGW1 -

124.124.124.222, pentru RGW2 - 125.125.125.111, iar pentru
45
MGC - 123.123.123.4. Portul MEGACO este numărul 55555
pentru toate cele trei entităţi.
1. RGW1 se înregistrează la MGC cu comanda
ServiceChange:
RGW1 to MGC:
MEGACO/1 [124.124.124.222]
Transaction = 9998 {
Context = - {
ServiceChange = ROOT {Services {
Method=Restart, Version=3,
ServiceChangeAddress=55555,
Profile=ResGW/1}
}}}
În calitate de identificator al terminaţiei se foloseşte

ROOT, adică rădăcina, deoarece comanda nu se referă la o
anumită terminaţie dar la GW-ul intregral.
2. În răspuns MGC transmite Replay (pe diagramă nu se

prezintă). De fapt la fiecare comandă se trimite un Replay,
care, pentru simplificare, nu este prezentat pe diagramă.
MGC to RGW1:
MEGACO/1 [123.123.123.4]:55555
Reply = 9998 {
Context = - {ServiceChange = ROOT {
Services {ServiceChangeAddress=55555}}}}
3. Cu comanda Modify MGC programează terminaţia

User A în contextul NULL. TerminationID este A4444,
streamID este 1, requestID în descriptorul Events este 2222.
Identificatorul mesajului (MID) expeditorului este adresa IP şi
portul [123.123.123.4]:55555. Proprietatea Mode pentru flux
este setată la inactiv. Notaţia "al" semnifică ”linie analogică” a
46
pachetului de supraveghere. Se presupune că sînt prevăzuţi
descriptorii Local şi Remote.
MGC to MG1:
MEGACO/3 [123.123.123.4]:55555
Transaction = 9999 {
Context = - {
Modify = A4444 {
Media { Stream = 1 {
LocalControl {
Mode = Inactive,
tdmc/gain=2, ; in dB,
tdmc/ec=on
},
}
},
Events = 2222 {al/of {strict=state}}
}
}
}
Un schimb similar se întâmplă între RGW2 şi MGC, ce

rezultă cu înregistrarea terminaţiei A5555 ca fiind inactivă.
Planul de apelare DigitMap poate fi încărcat în RGW
anterior. Atunci funcţia gateway-ului ar fi să aştepte ridicarea
receptorului de pe furcă (off-hook), pornirea tonului de disc şi
începerea colectării cifrelor DTMF. În acest exemplu vom
folosi DigitMap, care este trimis de MGC după ce este
detectată ridicarea receptorului.
Evenimentele desfăşurate în continuare pot fi explicate
succint după cum urmează:
Utilizatorul User A ridică receptorul (off-hook). RGW1
detectează această schimbare şi anunţă MGC prin comanda
Notify. MGC prin comanda Modify indică terminaţiei să trimită
tonul de disc apelantului şi să aştepte venirea cifrelor în
47
conformitate cu planul de apelare prezent în comandă. În
continuare cifrele în măsura culegerii lor de User A sînt
acumulate de RGW1. Tonul de disc este oprit după
detectarea primei cifre. După ce terminaţia A4444 primeşte
toate cifrele, la MGC se trimite un alt Notify. Controller-ul
analizează cifrele şi determină direcţia de plecare spre
RGW2. Terminaţia fizică A4444 şi terminaţia efemeră se
adaugă la un nou context în MG1 cu utilizarea comenzilor
Add.
Similar prin comenzi Add MGC va indica RGW2 să
includă terminaţia fizică A5555 şi terminaţia efemeră (de
exemplu, cu ID-ul A5556) a fluxului RTP stabilit într-un nou
context. MGC stabileşte de asemenea trimiterea apelului pe
A5555 pentru chemarea User B. În răspuns (Reply-urile pe
diagramă sînt omise) RGW2 trimite adresa IP şi numărul
portului, rezervate pentru această conexiune. Cu ajutorul
comenzii Modify MGC trimite informaţiile obţinute spre RGW1
indicînd şi aplicarea semnalului revers apel pe terminaţia
utilizatorului A. Cele două gateway-uri sînt acum conectate
între ele. RGW2 aşteaptă pînă ce User2 ridică receptorul şi
trimite Notify la MGC.
MGC generează o tranzacţie către RGW2 cu două
comenzi Modify, care duc la schimbarea modului de
funcţionare a ambelor terminaţii în sendrecv (bidirecţional–
trimite/recepţionează) şi oprirea semnalului de apel. În mod
similar controlorul trimite Modify la RGW1 pentru stoparea
revers apelului şi includerea modului de funcţionare a
terminaţiilor fizice şi efemere în sendrecv.
Acum cei doi utilizatori pot începe conversaţia (RTP
Media). Dacă pe parcurs se decide audierea unor terminaţii,
se utilizează comanda AuditValue. În exemplu se presupune
că MGC verifică terminaţia RTP în RGW2.
Apelul poate fi terminat fie de către utilizatorul apelant, fie
de cel apelat. Aici se presupune că primul a pus receptorul
48
(on-hook) utilizatorul chemat. Acest eveniment este raportat
de RGW2 la MGC prin comanda Notify. MGC trimite acum la
ambele gateway-uri comenzi Subtract, cîte una pentru
fiecare terminaţie. RGW1 precum şi RGW2 elimină fiecare
cele două terminaţii din context. Împreună cu ultima
terminaţie se lichidează şi contextul.
Este posibil ca MGC să solicite includerea în răspunsurile
primite de la RGW-uri a careva statistici.
În final controlorul stabileşte ca fiecare gateway să fie
gata pentru a detecta următorul eveniment off-hook. Este
posibil ca terminaţia să revină în contextul NULL în mod
implicit.
BIBLIOGRAFIE
1. I. Nazaroi. Sisteme şi reţele de comunicaţii digitale.
Partea1. Ciclu de prelegeri. –Chişinău: Editura ”Tehnica-
UTM”, 2014.
2. ITU-T Recommendation H.323 (12/2009) - Packet-based
multimedia communications systems (http://www.itu.int),
2009.
3. ITU-T Recommendation H.225.0 (12/2009) - Call
signalling protocols and media stream packetization for
packet-based multimedia communication systems
(http://www.itu.int), 2009.
4. ITU-T Recommendation Q.931 (05/1998) - ISDN user-
network interface layer 3 specification for basic call
control (http://www.itu.int), 1998.
5. ITU-T Recommendation H.245 (05/2011) - Control
protocol for multimedia communication
(http://www.itu.int), 2011.
6. ITU-T Recommendation H.248.1 (03/2013) - Gateway
control protocol: Version 3 (http://www.itu.int), 2013.
49
CUPRINS
Introducere. ......................................................................... 3
1. Protocolul 3.23 ........................................................... 3
1.1 Sumar. .................................................................... 3
1.2 Terminalul H.323 .................................................... 5
1.3 Gateway-ul H.323 .................................................... 7
1.4 Gatekeeper H.323 .................................................. 9
1.5 Unitatea de control multipunct MCU ...................... 11
1.6 Stiva de protocoale. ............................................... 12
1.6.1 Protocolul RAS .............................................. 14
1.6.2 Protocolul de semnalizare apel H.225.0 ........ 21
1.6.3 Protocolul de control al canalelor logice H.245 23
1.7 Exemplu setare apel cu implicarea GK ................ 27
2. Protocolul H.248/MEGACO. ...................................... 31
2.1 Sumar. ................................................................. 31
2.2 Modelul de conexiune h.248................................ 32
2.2.1 Terminaţia .................................................34
2.2.2 Contextul. .................................................. 35
2.3 Comenzile H.248 ................................................. 36
2.4 Descriptorii H.248 ................................................ 37
2.5 Tranzacţii H.248 .................................................. 42
2.6 Exemplu de setare a unui apel H.248...................43
Bibliografie. ........................................................................ 48
Digitally signed by
Library TUM
Reason: I attest to the
accuracy and integrity of
this document
4 0
50
9
WARE
CICLU DE PRELEGERI
R
E
Ț
E
L
E
D
E
F
I Chişinău
N
I
T
E
P
R
I
N
S
O
F
T
51
FACULTATEA ELECTRONICĂ ŞI TELECOMUNICAŢII

DEPARTAMENTUL TELECOMUNICAŢII
REȚELE DEFINITE PRIN SOFTWARE

CICLU DE PRELEGERI
Chişinău
Editura „Tehnica-
52 1
UTM”
53
CZU 004.4(075)
N 29
Lucrarea de față este o continuare logică a tematicii

cursului Sisteme și rețele de comunicații digitale (SRCD) care
include tendințele actuale de dezvoltare a tehnologiilor de
rețea. Cursul de prelegeri este divizat în două compartimente.
În primul compartiment sunt descrise principiile generale și
arhitectura funcțională a Rețelei definite prin software (SDN) în
corespundere cu standardele Uniunii Internaționale a
Telecomunicațiilor (ITU).
În al doilea capitol se expune protocolul OpenFlow. Sunt
descrise componentele principale ale OpenFlow switch și
modul cum se procesează pachetele de date în cadrul acestui
comutator. În final sunt expuse mesajele și formatul de bază al
protocolului OpenFlow.
Obiectivul principal al acestei părți a cursului SRCD constă
în însușirea cunoștințelor de bază privind tehnologiile viitoare și
emergente în domeniul TIC.
Ca parte a cursului Sisteme și rețele de comunicații digitale
lucrarea este destinată studenţilor UTM cu profilul Electronică
şi comunicaţii, specialităţile 0714.1 Tehnologii și sisteme de
telecomunicații, 0714.2 Rețele și software de telecomunicații,
0714.3 Comunicații radio și televiziune, 0710.1 Inginerie și
management în telecomunicații, cu forma de studii la zi şi cu
frecvenţă redusă.
DESCRIEREA CIP A CAMEREI NAȚIONALE A CĂRȚII
Nazaroi, Ion.
Reţele definite prin software: Ciclu de prelegeri / Ion
Nazaroi; Univ. Tehn. a Moldovei, Fac. Electronică şi
Telecomunicaţii, Dep. Telecomunicaţii. – Chişinău: Tehnica-
UTM, 2019. – 56 p.
55 ex.
ISBN 978-9975-45-571-8.
004.4(075)
N 29
ISBN 978-9975-45-571-8 54 © U.T.M., 2019
55
INTRODUCERE
Calea de evoluție a NGN către viitoarele rețele (FN) și IMT-2020
este ghidată de posibilitățile tot mai mari de integrare a tehnologiilor
avansate de comunicații (de exemplu SDN, NFV și CDN) cu tehnologii
avansate ale informației (de exemplu, cloud computing, tehnologii
Web). Pentru a susține această abordare, arhitectura NGN definită în
Recomandarea ITU-T Y.2012 este menținută și actualizată de
Grupurile de lucru ITU ținând cont de cele mai recente tendințe din
domeniu [1]. Evoluția arhitecturii NGN va include tehnologii inovatoare,
în special, utilizarea tehnologiilor SDN (software-defined networking) și
virtualizarea funcțiilor de rețea (NFV).
Creșterea numărului de servicii și aplicații duce la cererea
incontinuu de majorare a capacităților de transmisie și de extindere a
infrastructurii rețelelor. Rețelele de telecomunicații de astăzi includ o
mare varietate de echipamente hardware. Diversitatea lor continuă să
crească. Lansarea de noi servicii necesită deseori integrare de
echipamente complexe dedicate serviciului și o proiectare costisitoare
a procedurii. Lansarea noilor servicii pe piață adesea necesită o
perioadă lungă de timp. Pe de altă parte, ciclul de viață al
echipamentelor devine tot mai scurt pe măsura accelerării inovațiilor
tehnologice și a serviciilor.
Pe baza acestor caracteristici, Open Networking Foundation
(ONF) citează patru limitări generale ale arhitecturilor de rețea
tradiționale [2]:
Arhitectură statică și complexă. Pentru a răspunde cerințelor
servirii volumelor mari și fluctuante de trafic multimedia cu diferite
niveluri de QoS și de securitate, tehnologia de rețea devine tot mai
complexă și mai dificil de gestionat. A crescut considerabil numărul de
protocoale utilizate în rețea, care deseori se adresează doar unei
porțiuni de cerințe de rețea. Dificilă devine adăugarea nodurilor de
rețea (routerelor, switchurilor). Personalul de gestionare a rețelei
trebuie să utilizeze instrumente de gestionare la nivel de echipament
pentru a modifica parametrii de configurare ai switchurilor, routerelor,
firewall-urilor și așa mai departe. Actualizările includ
3
modificări ale listelor de control al accesului (ACL), setărilor LAN
virtuale, setărilor QoS în numeroase echipamente și alte ajustări legate
de protocol. Procedurile manuale trebuie să fie utilizate pentru a
configura echipamentele fiecărui furnizor.
Politici inconsecvente. Pentru a pune în aplicare o politică de
securitate la nivel de rețea, personalul va fi nevoit să facă schimbări de
configurație la mii de dispozitive. Într-o rețea mare, activarea a unei noi
mașini virtuale poate dura ore sau chiar zile pentru a reconfigura ACL-
urile în întreaga rețea.
Scalabilitate redusă. Cerințele față de rețele cresc rapid, ca
volum și ca varietate. Adăugarea de noduri de rețea și majorarea
capacității de transmisie implică echipamentele mai multor furnizori și
este dificilă datorită naturii complexe și statice a rețelei.
Dependența de furnizor. Operatorii de rețele și prestatorii de
servicii trebuie să implementeze rapid noi capabilități și servicii ca
răspuns la cerințele utilizatorilor. Lipsa de interfețe deschise pentru
funcțiile rețelei lasă operatorii limitați de ciclurile relativ lente ale
produselor furnizorilor.
Astfel chiar și cu capacitatea sporită a sistemelor de transmisie și
cu performanțele mai mari ale elementelor de rețea, arhitecturile
tradiționale de rețea sunt din ce în ce mai inadecvate în fața
complexității, variabilității și volumului ridicat al traficului impus.
1. REȚELE DEFINITE PRIN SOFTWARE
Rețelele definite prin software (SDN) au apărut ca o paradigmă de

rețea care poate elimina limitările infrastructurilor de rețea actuale.
Cum sunt concepute SDN pentru a răspunde cerințelor de rețea în
evoluție? Alianța Open Data Center (ODCA) oferă o listă concisă a
cerințelor, care includ următoarele [3]:
Adaptabilitate. Rețelele trebuie să se adapteze și să răspundă în
mod dinamic la necesitățile aplicațiilor, condițiile rețelei și a politicii de
afaceri.
Automatizare. Schimbările de politici trebuie efectuate automat,
astfel încât munca manuală și erorile să poată fi reduse.
4
Mentenabilitate. Introducerea de noi funcții și capabilități
(actualizări de software, corecții) trebuie să fie cu întreruperi minime
ale operațiunilor.
Managementul modelului. Software-ul de gestionare a rețelei
trebuie să permită gestionarea rețelei la un nivel de model mai rapid
decât să implementeze modificări conceptuale prin reconfigurarea
elementelor individuale ale rețelei.
Mobilitate. Funcțiile de control trebuie să găzduiască mobilitatea,
inclusiv pentru dispozitivele utilizatorilor mobili și serverele virtuale.
Securitate integrată. Aplicațiile de rețea trebuie să integreze
securitatea fără probleme ca serviciu de bază, în loc ca soluție
complimentară.
Scalarea la cerere. Implementările trebuie să aibă capacitatea de a
mări sau micșora rețelele și serviciile lor pentru a sprijini solicitările
apărute.
1.1 Definiția SDN
Rețelele de comunicații servesc diferite tipuri de trafic. Varietatea

aplicațiilor este în creștere continuă. Având proprietăți stohastice
diferite traficul cere și o abordare diferențiată. Pentru a susține cerințe
divergente dependente de aplicație, este necesar ca rețelele să devină
mai controlabile și mai ușor de gestionat. Astfel orientarea rețelelor pe
servicii este în creștere.
Conceptul de rețea definită prin software se caracterizează prin
cinci trăsături fundamentale:
1) separarea funcțiilor,
2) centralizarea controlului,
3) simplificarea nodurilor de rețea,
4) automatizarea și virtualizarea rețelelor,
5) utilizarea standardelor deschise.
Caracteristica fundamentală a SDN este separarea funcțiilor de
control de cele de rutare a fluxurilor de trafic. Funcția de rutare include
tabelele de expediere a pachetelor, bazate pe adresa MAC, adresa IP,
ID-ul VLAN etc. Pachetele care sosesc pot fi transmise
5
spre un port de ieșire, aruncate, consumate sau replicate. Un pachet
poate fi aruncat dacă memoria tamponului este depășită sau datorită
limitării ratei specifice QoS. În cazuri speciale pachetul necesită
prelucrare de către planul de control (consumat) și retransmis planului
resurselor. În cele din urmă, un caz special de expediere se referă la
multicast. Atunci pachetul de intrare trebuie să fie replicat înainte de
expedierea copiilor sale diferitelor porturi de ieșire.
Astfel în SDN nodurile de rețea (routere, switchuri) sunt
simplificate și conțin doar funcțiile de comutație. Software-ul complicat
care rulează pe nod și controlează în mod autonom sute de mii de linii
este eliminat din dispozitiv și plasat într-un controlor centralizat. Partea
de control fiind realizată pe nivel separat oferă șansa de introducere a
unui control centralizat logic și programabil al resurselor de rețea prin
intermediul interfețelor și protocoalelor standardizate.
Resursele de rețea sunt abstractizate. Abstractizarea oferă
programatorului o vedere globală a rețelei și îl eliberează de
necesitatea cunoașterii rețelei compusă din mai multe mașini. Apare
posibilitatea a virtualiza rețeaua, a decupla serviciul de rețea de
rețeaua fizică de bază. Deci, prin abstractizarea și programarea
resurselor de rețea, rețelele pot fi controlate într-o manieră automată,
ceea ce permite operații mai agile ale rețelelor.
O caracteristică a Open SDN este că interfețele sale trebuie să
rămână standard, bine documentate și nu de proprietate (non-
proprietary). Ca urmare, viteza cu care tehnologia de rețea este
dezvoltată este mult sporită, deoarece o mulțime de persoane și
organizații sunt capabile să se aplice problemelor actuale ale rețelei.
Prezența acestor interfețe deschise încurajează, de asemenea,
proiectele „open source” legate de SDN. Pe lângă facilitarea cercetării
și experimentării, interfețele deschise permit interoperabilitatea
echipamentelor de la diferiți furnizori. În mod normal, acest lucru
generează un mediu concurențial care reduce costurile consumatorilor
de echipamente de rețea. Această reducere a costurilor
echipamentelor de rețea a făcut parte din agenda SDN de la înființarea
acesteia.
6
Această abordare permite:
- controlul centralizat logic al rețelei, care reduce numărul
de puncte de control și de management;
- sprijinirea virtualizării rețelelor ca o caracteristică
importantă a arhitecturii rețelei;
- definirea, controlul și managementul resurselor de rețea
utilizând software;
- furnizarea serviciilor de rețea într-o manieră deterministă,
în conformitate cu comportamentul solicitat;
- personalizarea rețelei, care este necesară pentru
implementarea eficientă a rețelelor și operațiunilor.
Reieşind pe cele aduse mai sus Uniunea Internațională a
Telecomunicațiilor (ITU) definește SDN astfel:
O rețea definită prin software (SDN) este un set de tehnici
care permite programarea, orchestrarea, controlul și
managementul direct al resurselor de rețea, care facilitează
proiectarea, livrarea și operarea serviciilor de rețea într-o
manieră dinamică și scalabilă [4].
1.2. Arhitectura SDN

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

rețea pentru aplicațiile SDN printr-o altă interfață standardizată
(interfața de control al aplicației). Aplicația SDN poate personaliza și
automatiza gestionarea resurselor de rețea abstracte într-o manieră
programabilă prin intermediul acestei interfețe. Rețineți că controlerul
SDN poate furniza diferite tipuri de interfețe la aplicațiile SDN (mai mult
abstracte sau orientate spre obiecte).
Rețeaua poate fi programată de aplicații care rulează pe partea
superioară a arhitecturii - nivelul aplicații SDN.
Arhitectura funcțională SDN stratificată este prezentată în figura
1.2. Ea este formată din nivelul aplicațiilor SDN (SDN-AL),
nivelul de control SDN (SDN-CL) și nivelul resurselor SDN
(SDN-RL). Funcțiile de management multi-nivel (MMF) oferă
capabilități de gestionare a funcționalităților nivelurilor SDN
enumerate mai sus.
8
Figura 1.2. Structura stratificată SDN
Ele includ funcționalități pentru gestionarea defecțiunilor, configurației,
contabilității, performanței și securității (abrevierea engleză FCAPS -
fault, configuration, accounting, performance and security). Exemple
de astfel de funcționalități sunt inventarierea de echipamente,
actualizarea software-ului, izolarea defectelor, optimizarea
performanțelor, eficientizarea energetică și configurarea inițială a
resurselor de rețea, a controler-elor și a aplicațiilor SDN. În mod
specific, gestionarea autonomă, adică adaptarea continuă la starea
rețelei, poate fi realizată de către nivelul de control SDN.
Arhitectura SDN descrisă trebuie să ia în considerare factorii care
sunt importanți în rețelele publice de mari dimensiuni, spre exemplu,
interacțiunea cu sistemul de suport operațional (OSS-Operation
Support System) / sistemul de suport afaceri (BSS-Business Support
System) existent al operatorilor.
O prezentare de ansamblu a arhitecturii funcționale SDN organizată
pe niveluri este dată de figura 1.3. [5]
9
MMFO MMFA
Orchestrare și Aplicații SDN

Management relații externe ment suport
SDN-AL
nivel
Orchestrare și management multi-nivel
management
OSS AL
/BSS
MMFC ACI
Suport aplicații
ment suport SDN-CL
nivel Servicii nivel
CL
control
Abstractizare
resurse
MMFR RCI
Suport Suport control RL
ment SDN-RL
nivel RL
date date
Figura 1.3. Arhitectură SDN funcțională

În continuare vor fi descrise funcționalitățile nivelurilor aplicațiilor
SDN (SDN-AL), de control SDN (SDN-CL) și resurselor SDN (SDN-
RL), precum și funcțiile de management multi-nivel (MMF).
1.2.1. Nivelul aplicațiilor SDN (SDN-AL)
SDN-AL este alcătuit din componenta funcțională de suport

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

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

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

resurse
RCI
Figura 1.5. Componentele funcționale SDN-CL

Componenta funcțională a serviciilor CL furnizează un set de
funcții programabile de control și opțional de management (dacă sunt
delegate de MMF) care acoperă, de exemplu, topologii de rețea fizică
și virtuală, configurarea elementelor de rețea și gestionarea expedierii
traficului. Ea include servicii de bază și servicii specifice (de profil).
Componenta serviciilor de bază legate cu funcții de conectivitate este
obligatorie în toate realizările SDN (de exemplu, rețelele mobile,
transportul optic, mediul cloud sau virtualizarea funcțiilor de rețea
(NFV)). Ea include funcții comune utilizate în toate implementările
SDN, așa ca, descoperirea și monitorizarea topologiei, monitorizarea
resurselor (nodurilor și linkurilor) sau calcularea, selectarea și
monitorizarea traseului conform unei solicitări, actualizarea sincronă
sau asincronă a regulilor de expediere a datelor (programare flux).
13
Serviciile dependente de profil sunt legate de o anumită implementare
SDN sau combinare a mai multor astfel de servicii, de exemplu,
gestionarea mobilității pentru rețelele mobile.
Componenta funcțională de abstractizare a resurselor (CL-RA).
Scopul principal al componentei CL-RA este de a sprijini
programabilitatea unificată a resurselor în SDN-RL. Modelele de date
și informații ale resurselor de rețea furnizează o imagine abstractă și
unificată asupra acestor resurse către SDN-CL. Astfel ca dezvoltatorii
de servicii sau funcții de control să-și poată simplifica logica
programelor fără o cunoaștere detaliată a tehnologiilor din rețea.
Componenta funcțională CL-RA include, dar nu se limitează la,
următoarele elemente:
 de descoperire a resurselor independente de tehnologie;
 repozitoriu de topologie care păstrează topologia
curentă a rețelei fizice și virtuale (dacă este creată);
 de alocare a resurselor abstractizate pentru crearea
rețelelor virtuale;
 de supraveghere a resurselor care monitorizează
defecțiunile și performanța resurselor de pe nivelul
SDN-RL.
Componenta funcțională de suport management și
orchestrare a nivelului de control (CL-MSO) oferă suportul de
management și orchestrare a componentelor funcționale ale
SDN-CL și a resurselor de rețea pe baza politicilor oferite de
MMF.
De asemenea, componenta funcțională CL-MSO:
 obține informații de monitorizare pentru măsurarea și
înregistrarea indicatorilor-cheie de performanță (KPI) ai fiecărui
serviciu CL și cantitatea de resurse alocate unui serviciu CL pe
baza acestor indicatori de performanță;
 ține evidența stării generale a resurselor alocate și
disponibile în SDN-CL. Comparația resurselor alocate în SDN-
CL cu indicatorii KPI ai serviciului CL poate ajuta la
identificarea blocajelor actuale sau potențiale;
 oferă capabilități de operațiuni între diferite domenii
SDN, de exemplu, transmiterea identității și acreditărilor
14
corespunzătoare cu
15
cererile adresate. Un domeniu SDN este o colecție de entități SDN-
RL sub o entitate SDN-CL;
 anumite sarcini de management (dacă sunt delegate de
MMF) pot fi efectuate de către SDN-CL, în special sarcini care
sunt strâns legate de operațiunile de control și pot fi optimizate
în comun pentru utilizarea resurselor sau pentru performanță.
În concluzie se accentuează că nivelul de control, controlorul este
creierul rețelei. El poate fi centralizat, distribuit sau hibrid. În cazul
centralizat un controlor gestionează toate resursele de rețea și
păstrează o vedere globală a întregii rețele. În timp ce nivelul de
control distribuit utilizează mai multe controloare care sunt distribuite
pe întreaga rețea. Nivelul de control de tip hibrid se bazează pe
ambele concepte atât centralizat, cât și distribuit.
Indiferent de tip, controlul este logic centralizat. Termenul ”logic”
înseamnă că controlorul se comportă ca o singură entitate,
independent de posibila implementare în formă distribuită.
Cele mai utilizate sisteme la nivelul de control SDN sunt
Open Network Operating System (ONOS) [8], OpenDaylight
(ODL) [9], Floodlight [10], OpenContrail, Ryu, FlowVisor,
BEACON, NOX și POX.
1.2.3. Nivelul resurselor SDN (SDN-RL)
Elementele rețelei fizice sau virtuale ale nivelului resurselor

realizează transportul și prelucrarea pachetelor de date în conformitate
cu deciziile controlorului. Informațiile privind furnizarea de politici
(inclusiv informațiile despre configurația rețelei) care rezultă din
deciziile luate de SDN-CL, precum și informațiile privind resursele de
rețea, sunt schimbate prin punctul de referință al RCI. Informațiile de
control sunt furnizate de SDN-CL către SDN-RL (de exemplu, pentru
configurarea unei resurse de rețea). În sens opus SDN-RL transmite
notificări (nesolicitate) dacă este detectată o modificare a resurselor de
rețea. Comutatoarele SDN sunt noduri de rețea non-inteligente care
redirecționează fluxurile de date conform regulilor instalate în ele de
controlor. Cele mai comune comutatoare
16
SDN sunt switch-urile OpenFlow care funcționează pe protocolul
OpenFlow. Switch-ul OpenFlow are tabele de fluxuri care oferă
prevederi pentru căutarea/potrivirea și apoi transmiterea pachetelor pe
baza regulilor/acțiunilor din tabelă. Descrierea mai detaliată a
protocolului OpenFlow este dată de capitolul 2.
Resursele de rețea includ entități virtuale sau fizice, care susțin
funcționalități de:
 expediere a datelor, cum ar fi comutatoare de rețea
cu reguli de expediere a datelor, configurate de
SDN-CL;
 calculare a rutelor, cum ar fi router-ele IP cu
capabilități de control al rutei distribuite,
personalizate de SDN-CL, ca parte a executării
dinamice a politicilor ingineriei traficului;
 procesare a datelor, cum ar fi module pentru
transcodarea media și compresie de date.
Componentele funcționale ale nivelului resurselor sunt prezentate
de figura 1.6.
Componenta funcțională suport control (RL-CS) oferă modele de
date sau de informații ale resurselor de rețea, care sunt abstractizate în
SDN-CL. Ea însăși poate realiza abstractizarea resurselor în loc de
SDN-CL, dacă abstractizarea resurselor este susținută de tehnologia
utilizată.
Componenta funcțională RL-CS permite actualizarea datelor de
transport și de procesare, de exemplu, dacă se adaugă un nou
protocol sau un set nou de specificații de interfață. Programabilitatea
componentei funcționale RL-CS este susținută de MMF.
17
RCI
Suport Suport control RL Nivelul

manageme resurse
nt RL SDN
Procesare Transport
date date
Figura 1.6. Componentele funcționale SDN-RL

Componenta funcțională transport date (RL-DT) oferă
funcționalități de expediere și de rutare a datelor.
Funcția de expediere a datelor gestionează fluxurile de date
primite pentru a le expedia pe căile de redirecționare a datelor care au
fost calculate și stabilite conform cerințelor definite de aplicațiile SDN.
Controlul funcționalității de expediere a datelor este asigurat de
nivelul de control. Politica de rutare SDN-RL poate fi configurată de
SDN-CL conform cerințelor aplicațiilor SDN.
Funcțiile de redirecționare și de rutare a datelor sunt extensibile.
De exemplu, extinderea capabilităților de transport date pentru
manipularea unui nou format de cadru de date.
Componenta funcțională de procesare date (RL-DP) furnizează
funcționalități pentru examinarea și manipularea datelor.
Funcționalitățile de procesare a datelor permit modificarea formatului
sau a traficului util al pachetelor de date și ajustarea expedierii
pachetelor de date în corespundere cu cerințele aplicațiilor SDN.
Funcționalitățile de procesare a datelor sunt extensibile. Ca
exemple pot servi extinderea capabilităților existente de prelucrare a
datelor prin încorporarea unor noi tehnici de procesare a datelor, cum
ar fi algoritmi noi de codificare.
18
Componenta funcțională suport management (RL-MS) asigură
descrierea resurselor, nume furnizor, versiune software și starea
resurselor (de exemplu, încărcare CPU, memorie RAM sau stocare
utilizate). RL-MS poate include și un agent de management care
efectuează anumite operațiuni de management locale, dacă ele sunt
delegate de către MMF.
Acest agent poate fi utilizat pentru descoperirea resurselor
dependente de tehnologie, pentru monitorizarea locală programabilă a
entității SND-RL (pentru a limita volumul de date schimbate între
nivelurile SDN-CL și SDN-RL) sau pentru efectuarea așa-numitului
comportament autonom [6].
Notă. O comportare autonomă (AB) este definită ca un
comportament sau acțiune declanșate de un element de luare
a deciziilor în încercarea de a realiza obiectivul definit.
Obiectivul este definit prin modul în care elementul decizional
gestionează o entitate gestionată, aflată sub controlul său
(pentru detalii vezi [6]).
Componenta funcțională RL-MS oferă, de asemenea, o gestionare
a ciclului de viață al tuturor componentelor software ale nivelului
resurse, inclusiv componenta funcțională suport control RL- CS.
1.2.4. Funcțiile de management multi-nivel (MMF)
Funcțiile de management multi-nivel MMF gestionează nivelurile

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

(SDN-CL)
Nivelul resurselor SDN

(SDN-RL)
Figura 1.7. Structura internă și punctele de

referință MMF
3) autentifică, autorizează și detectează acțiunile anormale
asupra SDN-RL (opțional);
4) abstractizează resursele fizice și virtuale specifice
tehnologiei utilizate în informații generale independente de
tehnologie;
5) monitorizează și asigură performanța resurselor fizice și
virtuale ale SDN-RL pe baza indicatorilor de calitate (KPI-urilor
date), inclusiv gestionarea consumului de energie al resurselor;
6) corelează relația dintre resursele virtuale și cele fizice
din SDN-RL;
7) detectează și analizează evenimentele anormale care
cauzează căderea resurselor virtuale și fizice și generează
politici de rezolvare a defecțiunilor;
8) stochează conținutul descoperit de resurse și
21
gestionează ciclul de viață al conținutului în repozitoriu;
22
9) colectează stările resurselor și a evenimentelor și le
analizează în scopul gestionării FCAPS;
10) descoperă și resetează (bootstrapping) resursele fizice
și virtuale în SDN-RL;
11) oferă un punct de referință MMFR care este utilizat
pentru solicitarea și primirea operațiilor de gestionare și a
informațiilor asociate din / către SDN-AL.
Componenta funcțională de management al nivelului de control
(CLM) gestionează resursele utilizate pentru implementarea funcțiilor
nivelului de control SDN-CL (hardware, platforme software, linkuri care
leagă planul de control cu alte planuri). Asigură disponibilitatea și
scalabilitatea ridicată a managementului SDN-CL, precum și controlul
traficului generat între entitățile SDN-CL și entitățile SDN- RL sau
SDN-AL.
Funcțiile CLM sunt după cum urmează:
1) solicitarea și primirea de la MMO a indicațiilor de
management al nivelului de control;
2) furnizarea de resurse de control la nivelul SDN-CL și
scalarea lor în funcție de cerere și disponibilitate;
3) definirea, stocarea și recuperarea politicilor (de afaceri,
tehnice, de securitate, confidențialitate și de certificare) care se
aplică serviciilor nivelului de control;
4) monitorizarea și asigurarea performanței resurselor
SDN-CL pe baza indicatorilor KPI;
5) autentificarea și autorizarea, dar și detectarea atacurilor
anormale față de SDN-CL (opțional);
6) detectarea evenimentelor anormale care cauzează
defecțiuni, analiza cauzelor defectării și recuperarea efectivă a
resurselor SDN- CL defecte;
7) stocarea conținutului descoperit și gestionarea ciclului
de viață al lui (creare, modificare, ștergere) în repozitoriu;
8) colectarea stărilor și evenimentelor din resursele SDN-
CL și analiza lor pentru managementul performanței,
defecțiunilor și securității;
9) descoperirea și stocarea resurselor de control în SDN-CL;
23
10) furnizarea unui punct de referință MMFC care este
utilizat pentru solicitarea și primirea operațiilor de gestionare și
a informațiilor asociate către / de la SDN-CL.
Componenta funcțională CLM poate furniza, de asemenea, o
gestionare energetică eficientă a resurselor CL. Mecanismele utilizate
de managementul resurselor RL în domeniul energiei pot fi aplicate și
în CL.
Componenta funcțională de management al nivelului
aplicațiilor (ALM) gestionează resursele SDN-AL.
Funcțiile CLM sunt după cum urmează:
1) oferă o interfață internă cu blocul de orchestrare și
management multi-nivel (MMO) pentru solicitarea și primirea
indicațiilor de management de la MMO specifice nivelului
aplicațiilor;
2) furnizarea de aplicații și resurse relevante SDN-AL;
3) măsurarea și raportarea datelor privind utilizarea
resurselor SDN-AL pentru o facturare ulterioară. Datele privind
utilizarea resurselor pot fi măsurate pentru fiecare aplicație
SDN sau pentru fiecare client;
4) monitorizarea performanțelor aplicațiilor SDN pentru a
îndeplini cerințele SLA;
5) gestionarea securității aplicațiilor SDN terțe
(autentificare, autorizare);
6) detectarea, izolarea, recuperarea defecțiunilor aplicației SDN;
7) stocarea conținuturilor descoperite și gestionarea ciclului
de viață al acestor conținuturi în repozitoriu (crearea,
modificarea și ștergerea aplicațiilor SDN);
8) colectarea evenimentelor și statutului resurselor nivelului
SDN-AL și analizarea acestora în scopul gestionării defectelor,
calității și securității;
9) descoperirea aplicațiilor aflate în execuție și a
componentelor funcționale utilizate în SDN-AL;
10) furnizarea unui punct de referință MMFA pentru
componenta funcțională AL-MSO care este utilizată pentru
solicitarea și primirea
24
operațiilor de gestionare și a informațiilor asociate către / de la SDN-
AL.
Componenta funcțională de management al relațiilor
externe (ERM) gestionează colaborarea cu entități externe de
management. Componenta funcțională ERM joacă un rol de
interfață reprezentativă a managementului SDN față de
entitățile de management extern. Anume:
1) oferă un punct de referință MMFO către OSS / BSS
pentru solicitarea și primirea operațiilor de gestionare și a
informațiilor asociate la / de la OSS / BSS;
2) abstractizarea informațiilor de management SDN pentru
schimbul cu entitățile externe de management în scopul de
ascundere a informațiilor de gestiune inter-domeniu;
3) gestionează cererile/răspunsurile cu entitățile externe de
management;
4) oferă schimburi externe de politică SDN între MMF și
entitățile de management extern, analize de date, contabilitate.
Asigură interacțiunea cu sisteme externe de DevOps* pentru o
dezvoltare eficientă a funcțiilor SDN;
5) oferă o interfață internă MMFO în scopul orchestrării
inter- domenii între SDN MMF și OSS / BSS.
*) DevOps este o cultură și o practică de inginerie software care
urmărește unificarea dezvoltării (Dev) și operării (Ops) software-ului.
Componenta funcțională de orchestrare și management multi- nivel
(MMO) gestionează ciclul de viață al aplicațiilor SDN și
serviciilor de rețea și orchestrează managementul multi-nivel al
resurselor pe întregul domeniu al operatorului SDN (de exemplu, mai
multe centre de date interconectate de o rețea de transport WAN).
MMO asigură orchestrarea furnizării și configurării resurselor SDN-
RL și coordonează operațiunile de management între nivelurile SDN-
AL, SDN-CL și SDN-RL, în special relația dintre resursele virtualizate
și cele fizice ale nivelurilor SDN. De asemenea MMO
interacționează cu componentele funcționale ALM, CLM și RLM pentru
solicitarea și primirea operațiilor de management și a
informațiilor asociate pentru orchestrarea multi-nivel.
25
2. PROTOCOLUL OPENFLOW
Pentru a transforma conceptul de SDN în practică, trebuie

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

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

este în prezent standardul de facto al interfeței sudice pentru controlul
comutatoarelor SDN și este considerat unicul protocol general non-
proprietar pentru programarea comutatoarelor SDN. Ca urmare, în
continuare se expune nivelul resurselor SDN realizat pe switch-urile
OpenFlow și comunicarea acestora cu un controlor OpenFlow.
Protocolul OpenFlow este definit în versiunile specificației pentru
comutatoarele OpenFlow, elaborate și publicate de Open Networking
Foundation (ONF) (tabelul 2.1).
29
Tabelul 2.1. Versiunile OpenFlow
Versiune Dată
OF 1.0 Decembrie 2009
OF 1.1 Februarie 2011
OF 1.2 Decembrie 2011
OF 1.3 Iunie 2012
OF 1.4 Octombrie 2013
Cele expuse mai departe se bazează pe specificația OpenFlow

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

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

switch hibrid
32
Caracteristica importantă a comutatorului SDN este funcție
de redirecționare simplă, fără software încorporat pentru a lua
decizii autonome. În cadrul fiecărui switch se utilizează o serie
de tabele pentru a gestiona fluxurile de pachete. Pentru fiecare
pachet primit, comutatorul OpenFlow identifică mai întâi fluxul
căruia îi aparține pachetul și apoi execută instrucțiunile de
procesare specificate pentru acest flux. Dacă comutatorul nu
găsește reguli de potrivire pentru pachetul de date respectiv,
atunci aproximativ 200 de octeți de date sunt trimise la
controlor, care urmează să decidă ce acțiuni adecvate trebuie
luate. Controlorul modifică tabelele de fluxuri din comutator,
astfel încât atunci când pachetele de date similare sosesc la
înregistrările comutatorului se utilizează regulile de potrivire
definite și datele sunt direcționate conform acțiunilor
corespunzătoare fără să trimită pachetul din nou la controlor.
Ca urmare, switch-urile și routerele pot fi simplificate datorită
gestionării de către un controlor logic centralizat, ce sporește
performanța și flexibilitatea rețelei.
Căutarea fluxului de potrivire a fiecărui pachet primit și
determinarea acțiunilor care ar trebui luate pentru pachet reprezintă
responsabilitatea principală a conductei (pipeline) OpenFlow.
Funcțiile principale ale comutatorului OpenFlow sunt următoarele:
Suport control. Interacționează cu nivelul de control SDN pentru
a sprijini programabilitatea prin intermediul interfețelor de control al
resurselor. Comutatorul comunică cu controlerul și acesta gestionează
comutatorul prin intermediul protocolului OpenFlow.
Expedierea datelor. Acceptă fluxurile de pachete primite de la alte
comutatoare sau sisteme terminale și le redirecționează de-a lungul
căilor de expediere calculate și stabilite conform regulilor definite de
aplicațiile SDN.
Aceste reguli de expediere utilizate de comutator sunt incluse în
tabelele de expediere care indică pentru anumite categorii de pachete
care ar fi următorul hop în rută. În plus față de expedierea simplă a
unui pachet, dispozitivul de rețea poate modifica antetul pachetului
înainte a-l expedia sau să renunțe la pachet. Pachetele care sosesc
pot fi plasate într-o coadă de intrare, în așteptarea procesării de către
33
dispozitivul de rețea, iar pachetele transmise sunt în general plasate
într-o coadă de ieșire, în așteptarea transmisiei.
Canalul OpenFlow realizează interfața care conectează fiecare
comutator la controlor. Prin această interfață, controlorul OpenFlow
configurează și gestionează comutatorul, recepționează evenimentele
de la comutator și trimite pachetele din comutator. În mod tipic, un
controlor gestionează mai multe canale OpenFlow, fiecare la diferite
switch-uri. Un comutator OpenFlow poate suporta un canal la un
controlor sau câteva canale la diferite controloare OpenFlow. În cazul
câtorva controloare ele partajează gestionarea comutatorului, mai des
pentru creșterea fiabilității rețelei. Un canal OpenFlow este de obicei
criptat folosind protocolul de securitate al stratului de transport (TLS),
dar poate rula direct pe TCP.
Specificația OpenFlow [7] definește trei tipuri de tabele în
arhitectura comutatoarelor logice:
 Tabel de fluxuri (flow table);
 Tabel de grup (group table);
 Tabel de măsură (meter table).
Tabelul de fluxuri compară (matches) pachetele primite cu un
anumit flux și specifică ce funcții vor fi efectuate pe pachete. Pot exista
mai multe tabele de fluxuri care funcționează, înlănțuite, în conductă
(pipeline), după cum se explică ulterior.
În termeni generali, un flux este o secvență de pachete care
traversează o rețea și care conțin un set de valori egale ale antetului.
De exemplu, un flux ar putea consta din toate pachetele cu aceleași
adrese IP sursă și destinație sau cu același identificator LAN (VLAN).
Tabelul de fluxuri poate direcționa fluxul de pachete către un
tabel de grup, care poate declanșa o varietate de acțiuni.
Tabelul de măsură (meter table) poate declanșa acțiuni
legate de performanța pe flux.
Mai jos se expun mai detaliat funcțiile fiecărui tip de tabele din
cele trei menționate.
34
2.2. Tabelul de fluxuri
Blocul de bază al arhitecturii comutatorului logic OpenFlow este

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

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

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

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

câmpurile de potrivire și de prioritate. Câmpurile de potrivire și
de prioritate luate împreună identifică o înregistrare unică a
fluxului într- un anumit tabel de fluxuri.
Un pachet se potrivește cu o înregistrare de flux dacă toate
câmpurile de potrivire ale înregistrării de flux corespund
antetului și câmpurilor conductei pachetului. Înregistrarea
fluxului cu valori ”wilcards” pentru toate câmpurile (toate
câmpurile sunt omise) cu prioritatea egală cu 0 se numește
înregistrare de flux lipsă-tabel (table-miss). Valoarea de tip
”wildcard” semnifică că este posibilă orice valoare și se
notează prin semnul de asterisc (*). Înregistrarea de flux lipsă-
tabel este ultima din tabel. Ea este ca un catch-all (prinde tot,
capturează), iar acțiunile care trebuie luate depind de modul în
care este configurată această înregistrare. Fiecare tabel de
fluxuri trebuie să susțină o înregistrare lipsă-tabel pentru a
procesa insuccesele tabelului.
Componenta câmpurilor de potrivire a unei înregistrări din tabel
constă din următoarele câmpuri obligatorii (figura 2.4,b):
 Port de intrare. Identificatorul portului switch-ului pe
care a sosit pachetul. Acesta poate fi un port fizic sau un port
virtual definit de switch. Obligatoriu în tabelele de intrare.
 Port de ieșire. Identificatorul portului de ieșire din setul
de acțiuni. Obligatoriu la tabelele de ieșire.
 Adresele sursă și destinație Ethernet. Fiecare
înregistrare poate fi o adresă exactă, o valoare bitmascată
pentru care sunt verificați doar câțiva biți din adresă sau o
valoare de tip ”wildcard” (se potrivesc cu orice valoare).
 Tipul câmpului Ethernet. Indică tipul de încărcare utilă
a pachetului Ethernet.
 Port IP. IP versiunea a 4-a sau a 6-a.
39
 Adrese IPv4 sau IPv6 sursă și de destinație. Fiecare
înregistrare poate fi o adresă exactă, o valoare bitmascată, o
valoare a unei măști de subrețea sau o valoare de tip
”wildcard”.
 Porturile TCP sursă și destinație. Valoarea exactă sau
valoarea "wildcard".
 Porturile UDP sursă și destinație. Valoarea exactă sau
valoarea "wildcard".
Câmpurile de comparare menționate trebuie să fie acceptate de
orice comutator compatibil OpenFlow. Însă pot fi și un șir de câmpuri
acceptate ca opționale: porturile sursă și destinație ale protocolului
SCTP (Stream Control Transmission Protocol); metadate (informații
suplimentare care pot fi transmise de la un tabel la altul în timpul
procesării unui pachet); valoarea etichetei MPLS, clasa de trafic și
QoS; identificator VLAN și prioritate utilizator VLAN (câmpurile din
antetul unui LAN virtual IEEE 802.1Q, dacă SDN suportă VLAN- uri);
port fizic (utilizat pentru a desemna portul fizic subiacent atunci când
pachetul este recepționat pe un port logic) etc.
Astfel, OpenFlow poate fi utilizat cu trafic de rețea care implică o
varietate de protocoale și servicii de rețea. Rețineți că, la nivelul MAC
(de link), este acceptat numai Ethernet. Prin urmare, OpenFlow, așa
cum este definit în prezent, nu poate controla traficul nivelului 2 pe
rețelele fără fir.
Acum se poate defini mai precis termenul de flux. Din punctul de
vedere al unui comutator individual, un flux este o secvență de pachete
care se potrivește cu o înregistrare specifică într-un tabel de fluxuri.
Definiția este orientată pe pachete, în sensul că aceasta este o funcție
a valorilor câmpurilor de antet ale pachetelor care constituie fluxul și nu
o funcție a căii pe care o urmăresc prin rețea. O combinație de
înregistrări de flux pe mai multe comutatoare definește un flux legat de
o anumită cale.
Folosind protocolul de comutare OpenFlow, controlorul poate
adăuga, actualiza și șterge înregistrările fluxului în tabelele de fluxuri,
atât reactiv (ca răspuns la pachete) cât și proactiv.
Înregistrările fluxului sunt create reactiv atunci când controlorul
învață în mod dinamic locul dispozitivelor în topologia rețelei și
40
trebuie să actualizeze tabelele de fluxuri ale acestor dispozitive pentru
a construi conectivitatea cap-la-cap. Deoarece comutatoarele
OpenFlow doar expediază traficul, toată logica de expediere trebuie
mai întâi să fie programată și apoi dictată de către controlor. De
exemplu, dacă o gazdă de pe comutatorul A solicită să comunice cu o
gazdă de pe comutatorul B, mesajul mai întâi va fi trimis controlorului
pentru a construi calea spre această gazdă. Controlorul va consulta
adresele MAC ale switch-urilor și modul în care se conectează,
programând logica în tabelele de fluxuri ale fiecărui comutator.
Mesajele care vor urma vor fi trimise direct pe calea construită de
controlor.
Înregistrările de flux proactive sunt programate în prealabil,
înainte de sosirea traficului. Dacă este posibil ca două dispozitive ale
rețelei să comunice, controlorul poate programa din timp înregistrări de
flux corespunzătoare ca puncte finale ale OpenFlow.
2.2.2. Componenta Instrucțiuni a tabelului de fluxuri
Componenta Instructions a înregistrării tabelului de fluxuri constă

dintr-un set de instrucțiuni care sunt executate dacă pachetul se
potrivește cu înregistrarea. Înainte a descrie tipurile de instrucțiuni,
trebuie să definim termenii acțiune și set de acțiuni.
Acțiune este expedierea pachetelor, modificarea pachetelor și
operațiile de procesare în tabelele de grup.
Un set de acțiuni este o listă de acțiuni asociate unui pachet care
sunt acumulate în timp ce pachetul este procesat de fiecare tabel și
care sunt executate atunci când pachetul iese din conducta de
procesare.
Specificația OpenFlow include următoarele acțiuni:
 Output (Ieșire): Expedierea pachetului către portul
specificat. Portul ar putea fi un port de ieșire către un alt switch
sau portul către controler. În acest din urmă caz, pachetul este
încapsulat într-un mesaj către controlor.
 Set-Queue (setare coadă): Setează ID-ul de coadă
pentru pachet. Când pachetul este expediat către un port
utilizând acțiunea
41
de ieșire, ID-ul de coadă determină ce coadă atașată la acest port este
utilizată pentru programarea și expedierea pachetului. Modul de
expediere este dictat de disciplina cozii și este folosit pentru a oferi
suport parametrilor QoS de bază.
 Group (Grupa): Procesarea pachetului prin grupul specificat.
 Push-Tag/Pop-Tag (Împinge-etichetă/Trage-etichetă):
Push sau pop unui tag pentru pachetele VLAN sau MPLS.
 Set-Field (setare câmp): acțiunea Set-Field este
identificată după tipul de câmp și modifică valoarea câmpului
respectiv din antetul pachetului.
 Change-TTL (schimbă TTL): Acțiunea ChangeTTL
modifică valorile TTL (time to live - timp pentru a trăi) din IPv4,
limita de hop-uri IPv6 sau TTL în antetul MPLS.
 Drop (cădere): Nu există acțiune explicită care să
reprezinte căderea. În schimb, pachetele ale căror seturi de
acțiuni nu au nici o acțiune Output trebui să fie aruncate.
Tipurile de instrucțiuni pot fi grupate în patru categorii:
 Direcționarea pachetului prin conductă (pipeline):
Instrucțiunea Goto-Table direcționează pachetul către un tabel
de-a lungul conductei. Instrucțiunea Meter (măsurare)
direcționează pachetul către un contor specificat.
 Efectuarea acțiunii asupra pachetului: acțiunile pot fi
efectuate pe pachet atunci când sunt potrivite cu o înregistrare
din tabel. Instrucțiunea Apply-Actions (aplicați-acțiuni) aplică
acțiunile specificate imediat, fără a schimba setul de acțiuni
asociat cu acest pachet. Această instrucțiune poate fi utilizată
pentru a modifica pachetul dintre două tabele din conductă.
 Actualizarea setului de acțiuni: instrucțiunea Write-
Actions îmbină acțiunile specificate în setul de acțiuni curent
pentru pachetul dat. Instrucțiunea Clear-actions elimină toate
acțiunile din setul de acțiuni.
 Actualizarea meta datelor: o valoare de metadate poate
fi asociată unui pachet. Este folosit pentru a transporta
informații de la un tabel la următorul. Instrucțiunea Write-
Metadata actualizează valoarea meta datelor existentă sau
creează o nouă valoare.
42
2.3. Tabelul de grup
Un tabel de grup constă din înregistrări de grup. Abilitatea unei

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

Identifier Type Buckets
Figura 2.5. Câmpurile de înregistrare ale

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

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

măsurare
Fiecare înregistrare (figura 2.6) conține:
• identificator: un număr întreg de 32 de biți, care identifică
în mod unic contorul;
• benzile de măsurare: o listă neordonată de benzi de
măsurare, unde fiecare bandă de măsură specifică rata și
modul de procesare al pachetului;
• contoare: actualizate atunci când pachetele sunt
procesate de tabel.
2.5. Procesarea pachetelor în conductă (pipeline)
Conducta OpenFlow a fiecărui comutator logic OpenFlow

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

procesare
Separarea celor două etape este indicată de primul tabel
de ieșire. Pentru fiecare pachet procesarea începe cu
potrivirea antetului pachetului cu înregistrările de flux ale
tabelului 0. Alte tabele de fluxuri de intrare pot fi utilizate în
funcție de rezultatul de potrivire al tabelului precedent. Dacă,
ca rezultat al procesării de intrare, pachetul trebuie transmis
către un port de ieșire, comutatorul OpenFlow va începe să
efectueze procesarea de ieșire în contextul acelui port de
ieșire.
Procedura de potrivire și de executare a instrucțiunilor într-
un tabel de fluxuri este ilustrată în figura 2.8.
47
Găsiți înregistrarea
flux cu cea mai înaltă
Înregistrare flux TABELĂ de FLUXURI
prioritate la potrivire Înregistrare flux
Aplică instrucțiunile
Potrivire
Înregistrare flux
lipsă-tabelă Clear-Action:
de set de acțiune gol de
Write-Action:
{set de acțiuni} -id}
acțiuni
Câ
Aplicare-acțiuni
{listă de acțiuni}:
- modifică pachetul,
set de
potrivire, acțiuni
Extrage
conductei,
-dacă spre ieșire sau grup
→ clone de pachet.
Ieșire
Figura 2.8. Potrivirea și executarea

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

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

între controlor (nivelul de control) și dispozitivul de rețea (nivelul
resurselor). Protocolul OpenFlow acceptă trei tipuri de mesaje:
controler-to-switch, asincron și simetric, fiecare cu multiple subtipuri.
53
2.6.1. Mesaje controler-to-switch
Mesajele de la controlor spre comutator sunt inițiate de către

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

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

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

pentru mesajele OpenFlow Switch Protocol. Protocolul OpenFlow este
implementat folosind mesajele descrise mai sus și transmise prin
canalul OpenFlow. Fiecare tip de mesaj este descris de o structură
specifică, dar care începe cu un antet OpenFlow comun. Structura
mesajului poate include și alte structuri care pot fi comune pentru mai
multe tipuri de mesaje. Fiecare structură definește ordinea în care
informațiile sunt incluse în mesaj și pot conține alte structuri, valori,
enumerări sau mascări binare (bitmasks). Toate mesajele OpenFlow
sunt trimise în format big-endian.
OpenFlow este un protocol simplu binar, prin urmare, mesajele
OpenFlow nevalide, generate de implementările OpenFlow, vor
56
genera mesaje având o lungime greșită sau anumite câmpuri cu valori
nevalide. Se recomandă monitorizarea acestor condiții pentru a
detecta neconformitatea implementării.
Fiecare mesaj începe cu antetul OpenFlow [7]:
/* Header on all OpenFlow

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

OpenFlow utilizat. Cel mai semnificativ bit din câmpul de versiune este
rezervat și trebuie să fie setat la 0. Ceilalți 7 biți inferiori indică numărul
de versiunii ale protocolului. Versiunea protocolului descrisă aici este
1.5.1 ce corespunde versiunii ofp 0x06.
Câmpul type (tipul) poate avea următoarele valori [7]:
enum ofp_type {
/* Immutable messages. */
OFPT_HELLO = 0, /* Symmetric message */
OFPT_ERROR = 1, /* Symmetric message */
OFPT_ECHO_REQUEST = 2, /* Symmetric
message */ OFPT_ECHO_REPLY = 3, /*
Symmetric message */ OFPT_EXPERIMENTER =
4, /* Symmetric message */
/* Switch configuration messages. */

OFPT_FEATURES_REQUEST = 5, /*
Controller/switch
57
message */
OFPT_FEATURES_REPLY = 6, /* Controller/switch message */
58
OFPT_GET_CONFIG_REQUEST = 7, /* Controller/switch
message */
OFPT_GET_CONFIG_REPLY = 8, /*
Controller/switch message */
OFPT_SET_CONFIG = 9, /* Controller/switch message */
/* Asynchronous messages. */
OFPT_PACKET_IN = 10, /* Async
message */
OFPT_FLOW_REMOVED = 11, /* Async
message */ OFPT_PORT_STATUS = 12, /*
Async message */
/* Controller command messages. */

OFPT_PACKET_OUT = 13, /* Controller/switch
message */ OFPT_FLOW_MOD = 14, /*
Controller/switch message */ OFPT_GROUP_MOD =
15, /* Controller/switch message */ OFPT_PORT_MOD
= 16, /* Controller/switch message */
OFPT_TABLE_MOD = 17, /* Controller/switch
message */
/* Multipart messages. */
OFPT_MULTIPART_REQUEST = 18, /*
Controller/switch message
*/
OFPT_MULTIPART_REPLY = 19, /* Controller/switch message
*/
/* Barrier messages. */
OFPT_BARRIER_REQUEST = 20, /* Controller/switch message
*/
OFPT_BARRIER_REPLY = 21, /* Controller/switch message */
/* Controller role change request messages. */

OFPT_ROLE_REQUEST = 24, /* Controller/switch
59
message */ OFPT_ROLE_REPLY = 25, /*
Controller/switch message */
/* Asynchronous message configuration. */
60
OFPT_GET_ASYNC_REQUEST = 26, /*
Controller/switch message
*/
OFPT_GET_ASYNC_REPLY = 27, /* Controller/switch message
*/
OFPT_SET_ASYNC = 28, /* Controller/switch message */
/* Meters and rate limiters configuration messages. */

OFPT_METER_MOD = 29, /* Controller/switch message */
/* Controller role change event messages. */

OFPT_ROLE_STATUS = 30, /* Async
message */
/* Asynchronous messages. */
OFPT_TABLE_STATUS = 31, /* Async
message */
/* Request forwarding by the switch. */

OFPT_REQUESTFORWARD = 32, /* Async
message */
/* Bundle operations (multiple messages as a single operation).

*/
OFPT_BUNDLE_CONTROL = 33, /* Controller/switch message
*/
OFPT_BUNDLE_ADD_MESSAGE = 34, /* Controller/switch
message */
/* Controller Status async message. */

OFPT_CONTROLLER_STATUS = 35, /* Async
message */};
Câmpul length indică lungimea totală a mesajului, inclusiv și

antetul, astfel nu se utilizează nici un indiciu suplimentar pentru a
distinge cadrul.
61
Câmpul t xid determină identificatorul acestei tranzacții.
În capitolul 2 s-a încercat a oferi cititorului o înțelegere la nivel
general al OpenFlow. Pentru cititorul interesat de o înțelegere mai
aprofundată a acestui protocol, indiferent de interesul academic, nu
62
există nici o alternativă specificațiilor OpenFlow, în special cea citată în
acest capitol [7]. Aceste specificații sunt, totuși, foarte detaliate și nu
este ușor pentru un novice OpenFlow să le urmeze. Credem că acest
capitol va servi ca un excelent punct de plecare și ghid pentru acel
cititor care trebuie să se aprofundeze în specificațiile voluminoase care
cuprind versiunile OpenFlow.
Pentru aprofundarea și actualizarea cunoașterii mai multor aspecte
legate de SDN se recomandă consultarea periodică a site- urilor
[8,9,10].
63
BIBLIOGRAFIE
1. https://www.itu.int/en/ITU-
T/studygroups/2017- 2020/13/Pages/q2.aspx.
2. Open Networking Foundation. Software-Defined
Networking: The New Norm for Networks. ONF White Paper,
April 13, 2012.
3. Open Data Center Alliance. Open Data Center Alliance
Master Usage Model:Software-Defined Networking Rev. 2.0.
White Paper. 2014.
4. Recommendation ITU-T Y.3300. Framework of
software- defined networking. 2014.
5. Recommendation ITU-T Y.3302. Functional architecture
of software-defined networking. 2017.
6. ETSI GS AFI 002 V1.1.. Autonomic network engineering
for the self-managing Future Internet (AFI); Generic Autonomic
Network Architecture. 2013.
7. ONF TS-025. OpenFlow Switch Specification, Version
1.5.1. March 26,
2015.
https://www.opennetworking.org/images/stories/downloads/sdn-
resources/onf-specifications/openflow/openflow-switch-v1.5.1.pdf.
8. Website: Open Networking Foundation,
http://opennetworking.org
9. Website: OpenDaylight, https://www.opendaylight.org/
10. Website: Project Floodlight,
http://www.projectfloodlight.org/floodli ght/
64
ACRONIME ȘI ABREVIERI
Acronimele și abrevierile sunt sortate după alfabet.
ACI Application Control Interface

ACL Access Control List
AL Application Layer
ALM Application Layer Management
AL-MSO Application Layer Management Support
and Orchestration
API Application Programming Interface
BSS Business Support System
CAM Content Addressable
Memory CDN Content Deliveri Network
CL Control Layer
CL-AS Control Layer Application Support
CL-MSO Control Layer Management Support and Orchestration
CL-RA Control Layer Resource
Abstraction CLM Control Layer Management
DevOps Development Operations
DPID Datapath ID
DSCP Differentiated Services Code Point
ERM External Relationship Management
FCAPS Fault, Configuration, Accounting, Performance
and Security
FN Future Networks
IEEE Institute of Electrical and Electronics Engineers
IMT-2020 International Mobile Telecommunications
IP Internet Protocol
ITU International Telecommunications Union
KPI Key Performance Indicator
LAN Local Area Network
MAC Media Access Control
MMF Multi-layer Management Functions
MMFA Multi-layer Management Functions Application layer
MMFC Multi-layer Management Functions Control layer
65
MMFO Multi-layer Management Functions OSS/BSS
MMFR Multi-layer Management Functions Resource
layer MMO Multi-Layer Management Orchestration
MPLS Multiprotocol Label Switching
NFV Network Functions
Virtualization NGN Next Generation
Networks
NOX Network Operative
System ODCA Open Data Center
Aliance ODL OpenDaylight
ONOS Open Network Operating
System ONF Open Networking Foundation
OSS Operations Support System
POX NOX in Python
QoS Quality of Service
RAM Random Access Memory
RCI Resource Control Interfaces
RL Resource Layer
RL-CS Resource Layer Control
Support RL-DP Resource Layer Data
Processing RL-DT Resource Layer Data
Transport
RL-MS Resource Layer Management Support
RLM Resource Layer Management
SCTP Stream Control Transmission Protocol
SDN Software-Defined Networking
SDN-AL SDN Application
Layer SDN-CL SDN
Control Layer SDN-RL
SDN Resource Layer
SLA Service Level
Agreement
TCP Transmission Control Protocol
TLS Transport Layer Security
TTL Time-To-Live
UDP User Datagram Protocol
66
VLAN Virtual Local Area
Network WAN Wide Area Network
67
CUPRINS
INTRODUCERE. .............................................................................. 3
1. REȚELE DEFINITE PRIN SOFTWARE. ................. 4
1.1 Definiția SDN ................................................................. 5
1.2 Arhitectura SDN. ............................................................ 7
1.2.1 Nivelul aplicațiilor SDN (SDN-AL). ...................... 10
1.2.2 Nivelul de control SDN (SDN-CL). ........................ 12
1.2.3 Nivelul resurselor SDN (SDN-RL). .........................15
1.2.4 Funcțiile de management multi-nivel ...................... 18
2. PROTOCOLUL OPENFLOW. .......................................... 24
2.1 Componentele principale ale OpenFlow Switch. .......26
2.2 Tabelul de fluxuri. ...................................................... 32
2.2.1 Câmpurile potrivire ale tabelului de fluxuri. ...... 34
2.2.2 Componenta Instrucțiuni a tabelului de flux. 36
2.3 Tabelul de grup.......................................................... 38
2.4 Tabelul de măsurare. ................................................. 39
2.5 Procesarea pachetelor în conductă (pipeline) ..... 39
2.6 Mesaje OpenFlow. ..................................................... 44
2.6.1 Mesaje controler-to-switch. ..................................... 45
2.6.2 Mesaje asincrone......................................................46
2.6.3 Mesaje simetrice. ...................................................... 47
2.7 Formatul de bază al protocolului OpenFlow. ............. 47
BIBLIOGRAFIE. ...................................................................... 52
ACRONIME ȘI ABREVIERI. .................................................. 53
68 55
REȚELE DEFINITE PRIN SOFTWARE
Ciclu de prelegeri
Autor: Ion Nazaroi
Redactor: E. Gheorghișteanu
––––––––––––––––––––––––––––––––––––––––––––––––––––––
Bun de tipar 15.03.19 Formatul 60x84 1/16 Hârtie ofset. Tipar RISO Tirajul 55 ex.
Coli de tipar 3,5 Comanda nr. 29
––––––––––––––––––––––––––––––––––––––––––––––––––––––
U.T.M., 2004, bd. Ştefan cel Mare şi Sfânt, 168 Editura „Tehnica – UTM”
56
10. Stabilirea unui apel cu SIP
Exemplul adus arată funcţiile de bază ale SIP: localizarea unui punct terminal, solicitarea sesiunii, negocierea parametrilor de sesiune pentru
stabilirea sesiunii şi terminarea sesiunii stabilite.
Figura 2.2 prezintă un exemplu tipic de schimb de mesaje între doi utilizatori, Alice şi Bob [2]. Fiecare mesaj este marcat prin litera ”M” cu
un număr de trimitere la text. De asemenea, se arată două servere SIP Proxy care acţionează în numele Alice şi Bob pentru a facilita stabilirea
sesiunii.
Solicitanta este Alice care apelează telefonul SIP al lui Bob utilizînd SIP URI sip:bob@biloxi.com , unde biloxi.com este domeniul
furnizorului de servicii SIP a lui Bob. Respectiv adresa SIP URI a lui Alice este sip:alice@atlanta.com.
M1 INVITE Alice -> atlanta.com proxy
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 Max-Forwards: 70
From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710`
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp
Content-Length: 142
tranzacţia începe cu cererea INVITE
trimisă de Alice şi adresată lui Bob conform SIP URI. Cererea conţine o serie de anteturi. Cererea INVITE de mai sus include următoarele
anteturi:
Via conţine adresa (pc33.atlanta.com), la care Alice se aşteaptă să primească răspunsuri la această cerere. Antetul conţine şi un parametru
branch care identifică această tranzacţie.
To cu un nume de afişare (Bob) şi adresa SIP URI (sip: bob@biloxi.com).
From conţine, de asemenea, un nume de afişare (Alice) şi adresa SIP a solicitantului (sip: alice@atlanta.com). Cîmpul de antet include şi
un tag (etichetă) care conţine un şir aleator (1928301774), care a fost adăugat la URI de softphone. Acesta este utilizat pentru identificarea
dialogului
Call-ID conţine un identificator unic global .

CSeq sau Secvenţa de comandă conţine un număr întreg şi denumirea cererii.
Contact conţine un URI SIP care reprezintă o rută directă pentru a contacta Alice compus din nume de utilizator şi nume de domeniu.
Max-Forwards serveşte pentru a limita numărul de hop- uri ale cererii pe care le poate face pe drumul spre destinaţie.
Content-Type conţine o descriere a corpului mesajului.
Content-Length conţine numărul de octeţi din corpul mesajului.
11. Protocolul SDP descrierea sesiunii

Un exemplu de descriere sesiune de protocolul SDP este [RFC4456]:
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com (Jane Doe)
c=IN IP4 224.2.17.12/127 t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 8 ( 8 profile static, PCM A-law)
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000 (99 profile dinamic, codare video H.263 versiunea 1998, rata eşantionare 90000 Hz)
Descrierea sesiunii SDP constă dintr-un număr de linii de text de forma:
<tip> = <value>
unde <tip> este un caracter şi <valoare> este text structurat al cărui format depinde de <tip>.
Protocolul SDP oferă trei categorii de descriere:
- descrieri la nivel de sesiune,
- descrieri de timp,
- descrieri tip media.
Descrieri la nivel de sesiune:
 v= (protocol version). Identifică versiunea de SDP. Numărul versiunii este v=0.
 o= (originator and session identifier). Identifică iniţiatorul sesiunii şi sesiunea în sine.
 s= (session name). Este numele textual al sesiunii.
 i=* (session information). Acest descriptor furnizează informaţii suplimentare despre sesiune. Este prevăzut pentru utilizare de către
participanţii la sesiune în combinaţie cu numele de sesiune.
 u=* (URI of description). Descrierea identificatorului uniform de resurse (URI).
 e=* (email address). Pentru fiecare sesiune pot fi furnizate mai multe adrese.
 p=* (phone number). Similar cu adresa de e-mail, numărul de telefon poate fi folosit de către participanţi pentru a apela în cadrul sesiunii.
c=* (connection information). Informaţiile despre Tipul de adresă fie o adresă IPv4 sau IPv6, iar adresa de conexiune identifică adresa IP
reală care poate fi utilizată pentru conexiuni.
 b=* (bandwidth information lines). Identifică lăţimea de bandă necesară pentru sesiune.
Descrieri de timp:
 t= (time the session is active). Linia ”t=” specifică pornirea şi oprirea sesiunii. Formatul este: t=<start-time>
<stop-time>
Dacă <stop-time> este setat la zero, atunci durata sesiunii nu este limitată. Dacă <start-time> este, de asemenea, setat la zero atunci
sesiunea este considerată ca fiind permanentă.
 r=* (zero or more repeat times). Acest cîmp este utilizat pentru a indica cînd sesiunea se va repeta din nou.
 z=* (time zone adjustments). Acesta permite participanţilor să facă ajustări la fusul orar.
Descrieri la nivel de sesiune (continuare):
 k=* (encryption key). Dacă este folosită criptarea, atunci acest cîmp identifică cheile de criptare necesare pentru a citi sarcina utilă.
 a=* (zero or more session attribute lines – zero sau mai multe linii cu atribute sesiune).
Descrieri tip media. Descrierea media furnizează informaţii cu privire la media specifice pentru o sesiune.
1. m= (media name and transport address). Descrierea media furnizează informaţii cu privire la fluxurile de media specifice pentru o sesiune.
- i=* (media title - titlul media). Pentru definirea fiecărui tip de media poate fi utilizat un singur cîmp "i =".
 c=* (connection information -- optional if included at session level). Informaţii despre conexiune
 b=* (zero or more bandwidth information lines). Acest cîmp opţional denotă lăţimea de bandă propusă pentru a fi utilizată de media.
 k=* (encryption key). Cîmpul cheie criptare este permis înainte de prima intrare media (în cazul în care se aplică pentru toate media în
cadrul sesiunii) sau pentru fiecare intrare media în parte, după caz.
 a=* (zero or more media attribute lines). Descrierea media de atribute (cîmpuri "a ="), care sînt media specifice.
12. Protocolul Umbrela H.323. descrieri generale , elemente de baza si functii.
Recomandarea ITU-T H.323 ”Sisteme de comunicaţii multimedia bazate pe pachete” se referă la specificaţiile tehnice pentru sistemele de
comunicaţii multimedia bazate pe reţele cu comutaţia de pachete care nu pot asigura o calitate garantată a serviciului (QoS). Componentele unui
sistem H.323, includ: terminale H.323, Gateway-uri, Gatekeeper şi unităţi de control multipunct MCU (Multipoint Control Unit) pentru
conferinţe .
Terminalul H.323
Un terminal H.323 este un punct final al reţelei care asigură comunicaţii bidirecţionale vocale sau multimedia, în timp real cu un alt terminal
H.323, gateway sau unitate de control multipunct. Această comunicare constă în schimbul de fluxuri audio, video, date şi semnale de control
între două sau mai multe terminale. .
1.1 Gateway-ul H.323
Gateway-ul H.323 (GW) este un punct final al reţelei care asigură în timp real comunicaţii bidirecţionale între terminalele H.323 din reţeaua
bazată pe pachete şi alte terminale dintr-o reţea cu comutare de circuite. Funcţia principală a gateway- ului este a converti vocea sau informaţia
multimedia venită de la reţeaua cu comutare de circuite (SCN) într-o formă adecvată pentru transmiterea ei prin reţele bazate pe IP. Această
conversie constă în codificarea informaţiei şi încadrarea ei în pachete RTP/UDP/IP, precum şi transformarea inversă în sensul opus.
1.2 Gatekeeper H.323
Gatekeeper-ul (în română - Portarul) efectuează controlul terminalelor, gateway-urilor şi MCU interconectate în cadrul unei zone de reţea
H.323. Toate aceste entităţi se înregistrează la acest gatekeeper (GK).
Translarea adresei numită alias (numele abonatului, numărul telefonic, adresa poştei electronice etc.) în adresa de transport a
Controlul admisiei terminalelor în reţea.
Controlul, managementul şi rezervarea ratei de transfer a reţelei.
Rutarea mesajelor de semnalizare între terminalele unei zone.
1.4 Unitatea de control multipunct MCU

Unitatea de control multipunct (MCU) este un dispozitiv final al reţelei care asigură organizarea conferinţelor multipunct cu participarea a trei
sau mai multor terminale şi gateway-uri.
MC asigură negocierea cu toate terminalele pentru a atinge niveluri de capacităţi comune de comunicaţii (ce codecuri vor fi folosite), dar el
nu efectuează mixarea sau comutarea fluxurilor audio, video şi de date.
Protocolul H.323 este numit ”protocol umbrelă”, deoarece include o familie de protocoale.
22.Tehnologia multiprotocol de comutare cu etichete (MPLS): descrierea generală, motivarea denumirii, aplicații de bază.
MPLS este o tehnică de rutare în rețelele de telecomunicații care direcționează datele de la un nod la altul pe baza etichetelor fară a examina adresele de rețea
lungi, evitând astfel căutările complexe într-un tabel de rutare și accelerând fluxurile de trafic.
Etichetele identifică legăturile(căile) virtuale între nodurile
îndepărtate.
MPLS poate încapsula pachete de diferite protocoale de rețea, de aici, "multiprotocol " în numele său.
MPLS suportă o gamă largă de tehnologii de acces, inclusive T1/E1, ATM, Frame RelIay si DSL
Înlocuește rutarea bazată pe adresa IP pe comutație rapidă a pachetelor, bazată pe etichetă (fară căutare)
Nu depinde de protocoalele nivelelor 2 sau 3
Poate crea tunele pentru diferite tipuri de trafic
23.Modelul de bază al MPLS: ruter comutator de etichete LSR, ruter de frontiera al domeniului MPLS LER, tabela de expediere (comutatie),
modul de utilizare a etichetelor, protocol de distributie a etichetelor LDP, cale de comutatie de etichete LSP.
Label Distribution Protocol (LDP) RFC 5036
LDP este definit pentru distribuirea etichetelor și prezintă un set de proceduri și mesaje prin care Label Switched Routers (LSRs) stabilesc Label Switched Paths (LSPs) printr-o
rețea prin maparea
informațiilor de rutare.
Există patru categorii de mesaje LDP:
Mesaje de descoperire, folosite pentru a anunța și a menține prezența a unui LSR dintr-o rețea.
Mesaje de sesiune, utilizate pentru a stabili, întreține și înceta sesiuni între perechi/peers LDP.
Mesaje de publicitate, utilizate pentru a crea, modifica și șterge mapări de etichete pentru FEC.
Mesaje de notificare, utilizate pentru a furniza informații consultative și pentru a semnala informații despre eroare.
24. Formatul antetului MPLS, eticheta, clasa de echivalență (FEC), stiva de etichete, domeniu MPLS, tuneluri de trafic.
25. Subsistemul IP mutimedia (IMS), definiția, arhitectura stratificată ( pe nivele), puncte de referință.
IMS este o arhitectură standardizată a reţelei de generaţia următoare (NGN) care furnizează servicii multimedia mobile şi fixe
bazate pe protocolul SIP.
NGN IMS susține următoarele:
o Sesiuni IP multimedia
o Asigurarea calității servicilor QoS
o Interconectarea cu alte rețele cum ar fi rețelele CS fixe și mobile,Internet
o IP conectivitatea (IP CAN)- independența de tehnologia de acces
o Crearea și controlul serviciilor
o Roaming
o Securitatea comunicațiilor
o Sistem modern de tarificare a serviciilor
Arhitectura Subsistemul IP Multimedia Core Network este o colecție de diferite funcții, legate între ele prin intermediul unor interfețe
standardizate (puncte de referință, эталонные точки).O funcție nu este un nod: este posibilă gruparea a două funcții într-un singur nod sau, invers,
împărtirea unei funcții intre doua sau mai multe noduri.
IMS networks Architecture
Trei planuri principale:
-Accesul și de transport media
-Control sesiune și semnalizare
-Aplicații și servicii
26. Entitățile funcționale principale ale IMS: serverul de date abonați (HSS), funcția locație subscriere (SLF), funcția de
control a sesiunii de apel (CSCF) – serverele Proxy, Servire și Interogare.
Serverul de date abonați HSS( Home Subscriber Server)deține următoarele informații:
-de identificare a utilizatorului, de numerotare și adresare;
-de securitate (de control pentru accesul rețelei, autentificare și autorizare);
-despre locația utilizatorului la nivel de inter-sistem (înregistrarea utilizatorului și a locației);
-legate de profilul utilizatorului;
-care S-CSCF este alocat abonatului.
Funcția locație subscriere (Subscription Locator Function - SLF):
-Este interogat de către I-CSCF în timpul înregistrării și stabilirii sesiunea pentru a obține numele HSS care conține datele abonatului.
În plus, SLF este interogat de S-CSCF în timpul înregistrării.
-Este interogat de către AS pentru a obține numele HSS careconține datele abonatului.
- Este interogate de serverul 3GPP AAApentru a obține numele HSS care contine datele abonatului.
CSCF (Call Session Controll Fuction), functia de control a sesiunii de apel:
- Proxy CSCF
- Servire CSCF
- Interogare CSCF
Comun intre acestea trei , este ca toate joaa un rol in timpul inregistrarii i stabilirii sesiunii, precum si rutarii mesajelor SIP.
P-CSCF este primul punct de contact pentru utilizatorii din cadrul IMS. Aceasta înseamnă că toate mesajele SIP de la UE vor fi trimise la P-CSCF.
Ultimul redirecționează mesajele SIP primite de la UE către serverul S-CSCF, al cărui nume P-CSCF l-a primit ca urmare a procedurii de
înregistrare. În mod similar, toate mesajele SIP din rețea vor fi trimis de P-CSCF la UE.
Există patru sarcini unice alocate pentru P-CSCF:
-compresie/decompresie mesage SIP;
-asocierea de securitate IPSec (integritatea și confidențialitate semnalizarii SIP);
-interacțiunea cu PCRF;
-detecta și tratează cererea de stabilire a sesiunii de urgență.
Funcțiile îndeplinite de I-CSCF sunt:
-Atribuirea unui S-CSCF la o cerere de înregistrare SIP a utilizatorului.
-Rutarea cerererii SIP primite de la o altă rețea spre S-CSCF sau server de aplicații AS.
-Traducerea adresei E.164 din URI-urile cererii SIP în formatul telefon.
-Obținerea de la HSS a adresei S-CSCF.
-Transmiterea cerererii sau răspunsului SIP la S-CSCF.
- Generarea de CDR.
Funcțiile efectuate de S-CSCF sunt:
-Registrator, acceptă cereri de înregistrare.
-Server proxy, acceptă cereri și le deservește pe intern sau le transmite mai departe, eventual după traducere.
-Agent utilizator, adică poate independent genera și termina tranzacții SIP.
-Furnizează punctului terminal informații legate de serviciu (notificarea despre ton/anunț, alocarea de resurse media suplimentare,
notificarea de facturare).
-Transmite solicitarea sau răspunsul SIP la un BGCF pentrudirijarea apelurilor către retele CS.
27. Interconectarea intre două rețele IMS, funcția de control interconectare la frontieră (IBCF).
Functie de control interconectare la frontieră IBCF(Interconnection Border Control Function)

Funcția IBCF este utilizată pentru interconectarea între o rețea IMS și altă rețea IMS sau rețea IP non-IMS. IBCF acționează ca SIP proxy. Un
IBCF permite comunicarea între aplicații SIP, ascunde topologia de rețea, controlează cu H.248 gateway-ul de tranziție TrGW (Transition Gateway),
selectează modul de interconectare și generează datele de facturare.
IBCF introduce funcția de interlucrare IWF (Interworking Function) în calea de semnalizare atunci când rețelele participante la sesiune au
diferite profiluri SIP(de exemplu, între profilul SIP utilizat în IMS și celelalte profiluriSIP sau diferite protocoale SIP și H.323). În acest caz IWF
acționează ca un punct de intrare pentru rețeaua IMS. IWF și IBCF pot fi colocate într-un singur nod fizic.
Exemplu stabilire sesiune IMS:
28. Un subsistem multimedia IP IMS este capabil de a oferi toate serviciile
(prezente și viitoare), pe care le oferă Internetul. În acest fel, IMS va oferi
operatorilor de rețele posibilitatea să controleze și să taxeze fiecare serviciu.
Un MGCF (Media Gateway Controller Function) face conversia de protocol
între SIP și ISUP, face interfața cu SGW peste SCTP. Controlează de asemenea
resursele dintr-un MGW printr-o interfață H.248.
Un MGW face interfața cu planul media din rețelele CS, prin
transformarea RTP și PCM. El poate de asemenea face transcodarea când nu se
potrivesc codecurile (ex: IMS încearcă să folosească AMR, iar PSTN
folosește G.711).
29. SDN-ul (Software Defined Networking – Rețele definite prin sofware ) este
o abordare a rețelelor de calculatoare ce permite administratorilor de rețea să
gestioneze serviciile de rețea prin abstractizarea funcționalității la nivel
înalt.Conceptul oferă flexibilitate operatorilor de rețea și centrelor de date în
administrarea echipamentelor de rețea. Acest metodă este implementată cu
ajutorul aplicațiilor software care rulează pe servere externe .
Arhitectura SDN este :
- Direct programabilă - controlul rețelei nu mai depinde de direct de funcțiile
de expediere;
- Agilă - sustragerea controlului din expediere permite administratorilor să
ajusteze dinamic traficul de rețea pentru a satisface nevoia de schimbare;
- Gestionată la nivel central : Network Intelligence (Inteligența/Logica de
rețea) este centralizată în controllerele SDN care mențin o imagine de
ansamblu;
- Programabilă : SDN permite administratorilor de rețea să configureze,
gestioneze, asigure și optimizeze resursele de rețea foarte repede prin
intermediul programelor dinamice SDN;
- Bazată pe standarde deschise și furnizori neutrii: Când este implementat prin
standarde deschise, SDN-ul simplifică proiectarea și operarea rețelei, deoarece
instrucțiunile sunt furnizate de controllerele SDN în loc de protocoale specifice
ale furnizorilor;
30. Arhitectura SDN este organizată pe 3 niveluri : - aplicație; - control; -
infrastructură;
1.Nivelul de aplicație este constituit din totalitatea aplicațiilor care ajung la
utilizatori.Exemplu: Aplicație pentru videoconferințe sau management-ul
relațiilor cu clienții.
SDN Application (SDN App) SDN Applications sunt programe care în mod
83
explicit și direct comunică cerințele lor de rețea și comportamentul de rețea
dorit controllerului SDN prin intermediul NBI-Northbound interface.O
aplicație SDN este alcătuită dintr-o parte logică (SDN Application Logic) și
unul sau mai multe drivere SDN. Aplicațiile SDN pot expune singure un alt
strat de control abstractizat, astfel oferind interfețe de nivel mai înalt agenților
NBI.
2. Nivelul de control se referă la funcționalitatea ce permite aplicațiilor să

execute eficient și în siguranță, precum firewall-uri și/sau protecția împotriva
DDoS.
SDN Controller Controllerul SDN reprezintă "creierul" rețelei și este o entitate
logică centralizată responsabilă de traducerea cerințelor care vin din stratul
superior (SDN Application) pentru stratul inferior (SDN Datapath) și
furnizează o vedere abstractă a rețelei ce conține statistici și evenimente pentru
SDN App. Platforma unui controller SDN conține în mod obișnuit o colecție de
module care pot efectua diferite sarcini de rețea , precum inventarierea
dispozitivelor din rețea sau colectarea statisticilor. Se pot introduce extensii
pentru a îmbunătății funcționalitatea și pentru a susține capabilități mai
avansate precum rularea algoritmilor de analiză și orchestrarea unor noi reguli
în rețea. Două dintre cele mai cunoscute protocoale folosite de controllerul
SDN pentru a facilita comunicarea cu switch-uri sau routere sunt OpenFlow și
OVSBD. Aceste două protocoale se bazează pe ideea de centralizare a
deciziilor de expediere.
3. Infrastructura este alcătuită din echipamentele în sine, aici regăsinduse o
gamă diferită de modalități de gestionare a acestora în funcție de necesitatea și
scopul rețelei.
Printre beneficii sunt:
1. Controlul centralizat al mediilor multi-producător. Software-ul de control
SDN poate controla orice rețea ce folosește OpenFlow, indiferent de
producător, incluzând switchuri, routere și switchuri virtuale. În loc să
administreze grupuri de dispozitive de la producători individuali, se pot utiliza
arhitecturi și instrumente de management bazate pe SDN pentru a lansa,
configura și actualiza cu rapiditate dispozitive în cadrul întregii rețele.
2. Complexitate redusă prin automatizare. Prin OpenFlow, se permite un
framework flexibil de automatizare si administrare de rețea, ceea ce face
posibilă dezvoltarea de instrumente care automatizează multe sarcini care sunt
executate manual în prezent. Aceste instrumente de automatizare reduc
overheadul operational, reduc instabilitatea rețelei introdusă de eroarea
84
operatorului și suportă modelele emergente precum IT-as-aService.
3. Rată mai mare de inovare. OpenFlow accelerează inovația în business prin
permiterea operatorilor de rețea să programeze rețeaua în timp real pentru a
întruni diverse cerințe ale businessului și ale utilizatorilor pe măsură ce acestea
apar.
4. Fiabilitate și securitate crescută. SDN-ul permite industriei IT să definească
configurații de nivel înalt ce sunt apoi traduse în cadrul infrastructurii prin
OpenFlow. O arhitectură bazată pe OpenFlow elimină nevoia de a configura
individual dispozitive din rețea de fiecare dată când sunt schimbări, ceea ce
reduce probabilitatea de apariție a căderilor de rețea cauzate de inconsistențe în
configurație.
1 O serie de noi tehnologii, protocoale şi echipamente elaborate în ultimele

două decenii au avut o influenţă hotărîtoare asupra trecerii de la reţelele clasice
la cele de noua generaţie NGN. Printre principalele pot fi numite:
Tehnologiile de acces de bandă largă ADSL, VDSL, FTTx, LTE,
WiMax, etc;
Sistemul de transmisiuni DWDM (Dense Wavelength Division
Multiplexing – multiplexarea densă a lungimilor de undă) la nivelul fizic;
Metoda de comutaţie rapidă de pachete după etichetă MPLS
(Multiprotocol Label Switching) la nivelul "2.5";
Dezvoltarea de tehnologii Ethernet dincolo de LAN;
Noi echipamente terminale, aparate telefonice IP, PC, IPad,
smartphonuri,etc;
Dezvoltarea de protocoale adecvate pentru a oferi servicii de
comunicaţii voce bazate pe pachete (SIP, H.323);
Digitalizarea fluxurilor de media (voce, date, imagini).
În sfîrşit dar nu în ultimul rînd aici se poate menţiona şi dezvoltarea
vertiginoasă a serviciilor Internet bazate pe suita de protocoale TCP/IP.
1.2 Conform definiţiei Uniunii Internaţionale a Telecomunicaţiilor (ITU),
termenul NGN este o reţea bazată pe comutaţia de pachete, capabilă să ofere
servicii de telecomunicaţii cu utilizarea a multiple tehnologii de transport de
bandă largă (broadband) cu asigurarea unui nivel adecvat de calitate a
serviciilor (QoS) şi la care funcţiile relevante serviciilor sînt independente de
85
tehnologiile de transport. Ea asigură acces nerestricţionat a utilizatorilor la
reţele şi furnizori de servicii competitivi şi/sau la servicii la alegerea sa,
capabilă să susţină mobilitate generalizată, conducînd astfel la furnizarea
consistentă şi în mod independent de locaţie servicii către utilizatori.
1.3 O reţea NGN este caracterizată prin următoarele aspecte
fundamentale:
- bazată pe transfer de pachete IP pentru transportarea tuturor
tipurilor de informaţii;
- organizată pe nivele: acces/ transport, control/semnalizare şi
aplicaţii/servicii cu interfeţe deschise între aceste nivele ;
- nivelul de control/semnalizare separat de la nivelul de
transport/comutaţie;
- funcţiile referitor la servicii sînt independente de tehnologiile de
transport folosite ;
- suportă o gamă largă de servicii, aplicaţii şi mecanisme bazate pe
servicii în bloc, inclusiv servicii în timp real, de striming şi multimedia;
- capabilă de transmisii de bandă largă cap-la-cap cu asigurarea
calităţii serviciilor (QoS) pentru toate tipurile de trafic;
- convergenţa serviciilor între reţelele fixe şi mobile;
- acces nerestricţionat al utilizatorilor la diferiţi furnizori de servicii;
- suportă multiple tehnologii de transport pe ultima milă;
- conlucrează cu reţelele existente prin interfeţe deschise;
- mobilitate generalizată;
- o varietate scheme de identificare, care pot fi rezolvate la adresele
IP în scopul de rutare în reţele;
tehnologii mai ieftine şi mai eficiente în comparaţie cu tehnologiile actuale
2. Arhitectura NGN deseori se prezintă pe trei nivele funcţionale:

1. Nivelul transport şi comutaţie.
2. Nivelul control reţea şi semnalizare.
3. Nivelul servicii, control servicii şi aplicaţii.
86
Nivelul transport şi comutaţie
Nivelul de transport şi comutaţie include două subnivele: reţeaua core
(nucleu, magistrală) şi reţeaua de acces. Reţeaua core este constituită din rutere
magistrale (Core Node) şi de frontieră (Edge Node) şi se bazează de regulă pe
tehnologia IP/MPLS. La nivelul fizic se utilizează fibra optică cu sisteme de
multiplexare cu divizarea densă a lungimii de undă DWDM (Dense
wavelength division multiplexing) Ethernet sau STM-64. Comutaţia pachetelor
IP se efectuează de rutere sau switch-uri de nivelul 3. Astfel se obţine o
infrastructură cu comutaţie dispersată ceea ce este mai eficient decît
concentrarea comutaţiei în cadrul reţelelor de conexiune ale centralelor digitale
sincrone utilizate în PSTN. Tehnologiile utilizate pentru asigurarea accesului
de bandă largă sînt ADSL, VDSL, GPON, DVB (Digital Video Broadcasting),
WiFi, WiMAX (Worldwide Interoperability for Microwave Access) şi altele.
Nivelul control reţea şi semnalizare
Controlul semnalizării de apel în NGN este efectuat de serverul de apeluri
numit Softswitch. Echipamentul Softswitch îndeplineşte mai multe funcţii
printre care:
- efectuează dirijarea unui apel în reţea pe baza semnalizării şi a
informaţiilor legate de abonat;
- controlează serviciile de interconectare pentru media gateway şi
87
pentru terminalele VoIP;
- permite transferul controlului apelului către un alt element din
reţea;
- păstrarea şi gestionarea datelor abonaţilor în mod direct sau prin
intermediul gateway-lui;
- şi alte funcţii de gestionare cum ar fi înregistrarea, gestionare
erori, facturarea, etc.
La acest nivel se referă şi gateway-ul de semnalizări SGW care realizează
trecerea de la sistemul de semnalizare pe canal comun SS#7 utilizat în reţeaua
cu comutaţie de circuite SCN (Switched Circuit Network) la semnalizarea
SIGTRAN bazată pe IP a reţelei NGN.
Nivelul servicii, control servicii şi aplicaţii
După cum s-a menţionat anterior, în NGN funcţiile legate de servicii sînt
independente de tehnologiile de transport utilizate. Decuplarea aplicaţiilor de
reţele permite prestatorilor de servicii elaborarea aplicaţiilor pe diferite
platforme şi furnizarea serviciilor concurenţiale în condiţii non-
discriminatorii. Nivelul servicii, control servicii şi aplicaţii este conectat la
nivelul control reţea şi semnalizare prin intermediul unor API-uri (Application
Program Interface).
Serviciile multimedia, telefonie, date (WWW, e-mail, etc) şi video (IPTV,
video la cerere, videoconferinţă, etc) pot fi punct- punct, punct-multipunct sau
multipunct-multipunct.
Nivelul servicii, control servicii şi aplicaţii include servere de aplicaţii şi
servere media (teleconferinţă, Interactive Voice Response -IVR, etc).
Aplicaţiile sunt încorporate în serverele de aplicaţii dedicate acestui scop.
Deseori serverele de aplicaţii sunt completate cu servere care găzduiesc baze
de date cu conţinut adiţional (sistemul de facturare, sistemul de administrare al
reţelei, administrarea performanţei reţelei, colecţii de video-clipuri sau de ştiri,
etc.).
Împreună cu o nouă arhitectură, reţeaua de noua generaţie aduce un nivel
suplimentar de complexitate în comparaţie cu cel al reţelelor fixe existente. În
special, suportul a multiple tehnologii de acces şi a mobilităţii generalizate
aduce la necesitatea susţinerii unei varietăţi largi de configuraţii.
3. Rețeaua și protocolulSS7 sînt utilizate pentru:

Operații de bază legate de stabilirea, taxarea și eliberarea unui
apel, Servicii de telefonie mobilă, cum ar roaming-ul sau
88
autentificarea abonatului mobil, Portabilitatea numerelor la nivel
local,Servicii fără taxă (800) și cu taxă majorată (900), Servicii
suplimentare,cumarfiredirecționarea apelurilor, afișarea numărului
apelantului și teleconferința, Managementul rețelei pentru
comunicații eficiente și sigure la nivel mondial, SMS (Short
Message Service).
Puncte de semnalizare (Signaling Points). Toate nodurile
din rețeaua SS7 sunt numite puncte de semnalizare (SP). Fiecare
SP este identificat printr-o adresă unică numită cod de punct (PC).
SSP (Service Switching Point- puncte de comutație a
serviciului) – centrale telefonice de clasa 5 (local) și Clasa 4
(tandem) cu interfețe SS7.
STP (Signal Transfer Point- puncte de transfer a
semnalizării) - este un router și/sau o poartă de acces în
rețeaua SS7. Mesajele nu pot fi inițiate de către un STP.
SCP (Service Control Point- puncte de control serviciu) -
asigură accesul unei aplicații. Este o interfață pentru aplicații
cum ar fi bazele de date.
89
16 Fazele de stabilire a unei conexiuni intre doua
terminale H.323 cu implicarea GK.

Translarea adresei numită alias (numele abonatului,
numărul telefonic, adresa poştei electronice etc.) în adresa de
transport a reţelei (adresa IP şi numărul portului TCP).
Translarea se efectuează cu ajutorul unui tabel de
corespondenţă care este actualizat folosind mesajele de
înregistrare descrise mai jos.
Controlul admisiei terminalelor în reţea. GK-ul trebuie
să autorizeze accesul în reţea utilizînd semnalizarea RAS
descrisă în paragraful 1.6.1.
Controlul, managementul şi rezervarea ratei de
transfer a reţelei. Spre exemplu, GK poate controla numărul
terminalelor care simultan accesează reţeaua.
Rutarea mesajelor de semnalizare între terminalele
unei zone. Sînt posibile două moduri de rutare. GK-ul poate
organiza canalul de semnalizare direct între terminale sau cu
retransmiterea mesajelor de semnalizare de la un terminal la
altul.
Nu poate exista decît un singur GK activ pe zonă (figura 1.5).
Fig.1.5 Zone H.323 cu Gatekeepere
90
Fiecare zonă poate suprapune mai multe subreţele cu un
GK care gestionează gateway-urile, terminalele, MCU din
aceste subreţele.
17 Protocolul H.248: definiția, MGC și MG, elemente logice –

terminația și contextul.
Media Gateway Control Protocol (MGCP) este un
protocol utilizat în cadrul implementărilor de tip Voce pe IP
(VoIP). Recomandarea H.248.1 defineşte protocoalele
utilizate între elementele unui astfel gateway descompus fizic.
Relaţia componentelor protocolului MEGACO este de tip
stăpîn-sclav (eng. master-slave). Un MGC (master) poate
dirija unul sau mai multe MG-uri (slaves) pe cînd un MG logic
sau fizic se poate înregistra doar la un singur MGC.
Modelul de conexiune al protocolului prezintă entităţile
logice din cadrul Media Gateway (MG) care sunt controlate
de către Media Gateway Controler (MGC). Principalele
abstracţii utilizate în acest model de conexiune sînt terminaţia
şi contextul.
Terminaţia iniţiază sau opreşte unul sau mai multe
fluxuri media. De exemplu, într-o conferinţă multimedia, în
care terminaţia poate fi multimedia, ea porneşte sau opreşte
mai multe fluxuri media.
Contextul este o asociere logică dintre cîteva terminaţii.
Există un tip special de context, numit contextul NULL, care
conţine toate tipurile de terminaţii care nu sunt prezente în
orice alt context. De exemplu, într-un gateway de acces
descompus, toate liniile inactive (libere) sînt reprezentate de
terminaţii în contextul NULL.
2.1.1 Terminaţia
Terminaţiile sînt de două tipuri, fizice şi efemere.
Terminaţia fizică reprezintă o entitate fizică, de exemplu, un
91
canal TDM. Ea există atît timp cît este acest canal în GW.
Terminaţia efemeră reprezintă un flux RTP şi există doar pe
durata sesiunii.
Terminaţia este descrisă de un număr de proprietăţi
caracteristice care sînt grupate într-un set de descriptori. Ea
poate genera sau recepţiona anumite semnale. Terminaţiile
pot fi programate pentru a detecta evenimente ale căror
apariţie poate declanşa acţiuni din partea MG sau mesaje de
notificare a MGC.
Protocolul H.248 poate fi folosit pentru a crea noi
terminale şi modifica proprietăţile celor existente. Aceste
modificări includ posibilitatea de a adăuga sau elimina
evenimente şi/sau semnale.
Fiecare terminaţie are identificator unic (TerminationID),
atribuit de către MG în momentul creării acesteia. De
exemplu, pentru o terminaţie fizică, în calitate de identificator,
poate servi numărul fluxului digital E1 şi numărul slotului timp
în acest flux. Dacă cererea trebuie adresată la toate
terminaţiile atunci se foloseşte un identificator comun Root.
Cu TerminationID se utilizează şi un mecanism de adresare
în grup (wildcards): ALL şi CHOOSE. Primul este utilizat
pentru a se adresa simultan la mai multe terminale, al doilea -
oferă gateway-ului dreptul de selectare a terminaţiei
corespunzătoare.
2.1.2 Contextul
Contextul este o asociere între un număr de terminaţii
prin care se descrie topologia conexiunii. Numărul maxim de
terminaţii într-un context depinde de proprietăţile MG.
Gateway-urile care oferă doar conectivitate punct-la-punct
permit cel mult două terminaţii pe context, iar cele care susţin
conferinţe multipunct permit trei sau mai multe terminaţii pe
context.
Atributele contextului sînt:
Identificatorul
(ContextID).
92
Descriptorul topologiei. Topologia contextului descrie
fluxurile informaţionale între terminaţiile lui, deci în interiorul
GW-lui. Contrar, proprietatea similară a unei terminaţii (de
exemplu, "SendOnly", "RecvOnly") descrie fluxurile
informaţionale de ieşire/intrare la gateway.
Indicatorul de prioritate. El indică GW-lui prioritatea cu
care trebuie să fie tratat contextul. De exemplu, la restartarea
gateway-lui, atunci cînd o mulţime de contexte trebuie tratate
simultan, MGC poate utiliza indicatorul de prioritate pentru a
nivela traficul şi controla succesiunea pornirii contextelor.
Prioritatea poate avea 16 nivele, în creştere de la 0 pînă la
15.
Indicator pentru apelurile de urgenţă cu cea mai înaltă
prioritate.
Protocolul are comenzi pentru a crea contexte, a adăuga
sau a scoate terminaţii din contextele existente, precum şi
pentru a deplasa terminaţia dintr-un context în altul. Contextul
se şterge implicit atunci cînd se lichidează ultima terminaţie
rămasă.
Comenzile H.248, descrierea succintă a fiecărei
comenzi.
Comenzile H.248
Protocolul H.248 prevede 8 comenzi pentru manipularea
contextelor şi terminaţiilor. Cele mai multe comenzi sînt
trimise de MGC pentru controlul MG. Excepţie fac comenzile
Notify şi ServiceChange: Notify este trimisă de la Media
Gateway la Media Gateway Controller, iar ServiceChange
poate fi trimisă de ambele entităţi.
Comenzile protocolului H.248 cu descrierea lor de
ansamblu:
1. Add. Comanda Add adaugă o terminaţie la
contextul indicat prin ContextID. Dacă în comandă
93
nu se specifică contextul, atunci va fi creat un nou
context. În cazul cînd în loc de TerminationID se
indică simbolul de grup $, atunci se creează o nouă
terminaţie efemeră care va fi atribuită contextului.
2. Modify. Comanda Modify modifică proprietăţile
terminaţiei, evenimentele recepţionate sau
semnalele trimise de terminaţie.
3. Subtract. Comanda Subtract elimină
terminaţia din context. În răspuns la această
comandă MG poate să transmită MGC date
statistice despre participarea terminaţiei în context.
Dacă comanda exclude ultima terminaţie din context
atunci se lichidează şi contextul.
4. Move. Comanda Move deplasează terminaţia
dintr-ul context în altul. Ea nu se foloseşte pentru
mutarea terminaţiei în contextul NULL sau scoaterea
terminaţiei din acest context, deoarece aceste
manipulări se efectuează cu ajutorul comenzilor Add
şi Subtract.
5. AuditValue. Cu această comandă MGC cere
informaţii curente privind proprietăţile terminaţiei,
evenimentele recente sau semnalele transmise în
canal, precum şi datele statistice acumulate la
moment.
6. AuditCapability. Cu această comandă MGC
solicită de la MG informaţii privind toate valorile
posibile pentru proprietăţi, evenimente şi semnale
ale terminaţiei.
7. Notify. Comanda Notify permite MG-ului să
informeze MGC de apariţia unor evenimente în
94
gateway.
8. ServiceChange. Comanda permite MG-ului să
informeze controller-ul MGC că o terminaţie sau un
grup de terminaţii este pe cale să fie scos din
serviciu sau tocmai va fi întors în serviciu.
ServiceChange este de asemenea folosită de către
MG ca să anunţe disponibilitatea sa de înregistrare
la MGC, precum şi să notifice MGC de intenţia sau
efectuarea restartării MG. Prin trimiterea acestei
comenzi MGC poate anunţa MG despre handover
(transfer). MGC poate utiliza de asemenea
ServiceChange pentru a instrui MG să introducă sau
să scoată din serviciu o terminaţie sau un grup de
terminaţii.
95

SRCD 1

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SRCD 1

Încărcat de

Drepturi de autor:

Formate disponibile

UNIVERSITATEA TEHNICĂ A MOLDOVEI

Facultatea Inginerie şi Management în

SISTEME ŞI REŢELE DE COMUNICAŢII DIGITALE

Autor: conf.univ., dr. Ion NAZAROI

Recenzent: conf.univ., dr. Nicolae BEJAN

Dezvoltarea actuală a sistemelor şi reţelelor de comunicaţii

1. PREZENTAREA GENERALĂ A NGN

1.1 Definiţia NGN

Reţea de noua generaţie NGN (Next Generations Network)

1.2 Arhitectura NGN

Arhitectura NGN deseori se prezintă pe trei nivele

Softswitches Control rețea și

API - Application Programming Interface

Fig.1.1 Arhitectura NGN

Între aceste nivele se stabilesc interfeţe standardizate,

1.2.1 Nivelul transport şi comutaţie

Nivelul de transport şi comutaţie include două subnivele:

Fig. 1.2 Schema de structură a reţelei core şi de acces

Utilizatorii finali sînt conectaţi la NGN prin interfaţa

Fig. 1.3 Setul de terminale la edificiul abonatului

Tehnologiile utilizate pentru asigurarea accesului de bandă

Fig. 1.4 Schema de structură MGW

Controlul semnalizării de apel în NGN este efectuat de

1.2.3 Nivelul servicii, control servicii şi aplicaţii

După cum s-a menţionat anterior, în NGN funcţiile legate

1.3 Protocoale de semnalizare în NGN

Fig.1.5 Fragment reţea NGN şi protocoale utilizate

Din figura 1.5 se pot observa şi tipurile de protocoale de

Fig.1.6 Stiva de protocoale pentru NGN

La primul tip se referă protocolul de iniţiere a sesiunii SIP

2. PROTOCOLUL DE INIŢIERE A SESIUNII SIP

Protocolul de iniţiere a sesiunii SIP (Session Initiation

2.1 Componentele funcţionale ale reţelei SIP

O reţea bazată pe protocolul SIP include pînă la patru

Protocolul SIP se bazează pe text şi utilizează setul de

*) Linia de start, fiecare antet şi linia goală trebuie să fie

Fig. 2.1 Mesajul SIP

În specificaţia RFC 3261 sînt definite şase tipuri de cereri

Tabelul 2.1 Lista metode/cereri SIP

INFO Oferă un mecanism de 6086/01.2011

NOTIFY Informează un abonat cu 6665/06.2012

*) RFC 3261 a înlocuit specificaţia anterioară RFC 2543 din

Mai jos este dată descrierea mai detaliată a fiecărei cereri

2.4 Răspunsuri SIP

Linia de stare a răspunsului conţine un cod (Status-Code)

Tabelul 2.2 Lista codurilor de răspunsuri SIP

4xx Request Failure

5xx Server Failure

6xx Global Failures

*)Pentru răspunsurile la care specificaţia nu este indicată se

Tabelul 2.4 Forma abreviată a anteturilor

În cele ce urmează, mai detaliat, sînt expuse doar unele

Într-o reţea SIP destinaţia este determinată după

2.7 Descrierea sesiunii în corpul mesajului

La iniţierea sesiunilor VoIP de teleconferinţă multimedia

2.8 Exemplu de stabilire a unei sesiuni SIP

Exemplul adus arată funcţiile de bază ale SIP: localizarea

M1 INVITE Alice -> atlanta.com proxy

INVITE sip:bob@biloxi.com SIP/2.0

(Alice's SDP nu se prezintă)

În acest exemplu, tranzacţia începe cu cererea INVITE

SIP/2.0 100 Trying

Serverul Proxy primeşte cererea SIP de la UAC şi o