1.Definitia Arhitectura NGN-объединены

Difiniția și arhitectura NGN
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 .
Tehnologii, protocoale și echipamente
 Tehnologiile de acces de bandă largă ADSL, VDSL,
FTTx, LTE, WiMax, etc;
 Sistemul de transmisiuni DWDM– multiplexarea
densă a lungimilor de undă) la nivelul fizic;
 Metoda de comutație rapidă de pachete după etichetă
MPLS 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).
Principalele cauze migrării rețelei PSTN spre NGN
 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.
Integrarea pe verticală în rețelele convenționale
vs de integrarea pe orizontală în NGN:
Services in NGN environments
Services in legacy environments

Voice Internet Video MM
Data
Video Telephone Services
Services
Services (WWW,
(TV,
movie, etc)
e-mail, N
etc)
G
Video Data
N IP (Common Platform)
Services Network
Network
PSTN (PSDN,
internet)
Fixed and Mobile broadband
Aspecte fundamentale NGN
 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;
 suportă o gamă largă de servicii, 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;
Aspecte fundamentale NGN (continuare)
•convergența serviciilor între rețelele fixe și mobile FMC;
•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 de 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.
Arhitectura NGN
Arhitectura NGN deseori se prezintă pe trei nivele

funcționale:
 Nivelul transport și comutație.

 Nivelul control rețea și semnalizare.
 Nivelul servicii, control servicii și aplicații.
Application Servers Servicii, control servicii
Management Servers ș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

LDAP -Lightweight Directory Access Protocol
SNMP - Simple Network Management Protocol
Arhitectura NGN
Arhitectura NGN detalizată
Schema de structură a rețelei core si de acces
Numărul de abonaţi (mii) şi ratele de penetrare a serviciilor de telefonie fixă
Număr abonați, rate de penetrare şi tehnologii de
acces la Internet la puncte fixe
Evoluția nr. de abonați în bandă largă în funcție de tehnologia de acces (mii)

Evoluția ratelor de penetrarea serviciilor de acces în
bandă largă la puncte fixe
Ponderea conexiunilor la Internet fix, în funcție de tehnologiile de acces
Sursa: ANRCETI
Ponderea conexiunilor la Internet fix, în funcție de viteza de transfer al datelor
Sursa: ANRCETI
Evoluția ratelor de penetrare a serviciilor de acces la Internet mobil și Internet fix
Sursa: ANRCETI
Sistemul de semnalizare 7 (SS7)
Sistem de semnalizare pe canal comun (CCS)
Standard mondial pentru telecomunicații definit de către

ITU. Recomandările ITU-T seria Q.7xx.
Standardul SS7 definește procedurile prin care elementele

de rețea în PSTN fac schimb de informații utilizînd rețeua de
semnalizare digitală pentru controlul, rutarea și setarea
apelului în rețele fixe sau mobile
SEMNALIZAREA CAS in E1
Rețeaua și protocolul SS7 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
autentificarea abonatului mobil.
• Portabilitatea numerelor la nivel local.
• Servicii fără taxă (800) și cu taxă majorată (900).
• Servicii suplimentare, cum ar fi redirecț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).
REȚEAUA DE SEMNALIZARE
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.
Tipuri de link-uri de semnalizare SS7
(Signaling Link Types)
A Link: "A" (access) - conectează un punct de semnalizare terminal sau punct de semnalizare
sursă (de ex. SSP sau SCP) la un STP; pe link-ul A se transmit doar mesaje generate de către
sau destinate punctului de semnalizare terminal.
B Link: "B" (bridge) - interconectează STP-urile primare ale unei rețele cu STP-urile primare ale
unei alte rețele; perechile de STP-uri interconectate se situează la același nivel ierarhic.
C Link: "C" (cross) - conectează perechi asociate de STP-uri care realizează funcții identice;
aceste legaturi sunt utilizate pentru a creste fiabilitatea rețelei de semnalizare; o legatura C este
utilizată doar atunci când un STP nu are alta ruta disponibilă către un punct de semnalizare
destinație.
D Link: "D" (diagonal) - conectează o pereche de STP secundare (de exemplu, locale sau
regionale) la o pereche de STP primare (de exemplu, gateway inter-rețea) într-o configurație
quad-link4; conectează perechi de STP-uri de la nivele ierarhice diferite.
E Link: "E" (extended) – conectează un SSP la un STP alternativ pentru a furniza o legatura de
semnalizare alternativă; legaturile E sunt utilizate de regulă, doar daca un grad mai ridicat de
fiabilitate justifica cheltuielile suplimentare; aceste legaturi asigură conectivitate de rezervă la
rețeaua SS7 în situația în care STP-ul asociat punctului de comutație nu poate fi atins pe linkul A.
F Link: "F" (fully associated) - conectează în mod direct două puncte de semnalizare terminale
(SSP-uri sau SCP-uri); aceste legaturi permit numai semnalizare asociată; aceste legaturi nu sunt
utilizate de regulă în rețele care includ STP-uri.
Arhitectura SS No. 7 (FIG. 2/Q.700)
Nivele OSI
Application INAP MAP
Presentation
TCAP ISUP
Session
Transport SCCP
Network MTP Nivel 3
Data Link MTP Nivel 2
Physical MTP Nivel 1
7
Partea de transfer a mesajelor (Message Transfer
Part - MTP)
Nivelul 1 definește caracteristicile fizice, electrice și
funcționale ale unei legături de date de semnalizare și mijloacele
pentru a o accesa. El este purtător pentru link-ul de semnalizare.
Nivelul 2 oferă funcționalitatea la nivel de link. Aceasta
asigură schimbul fiabil de mesaje de semnalizare dintre cele
două puncte de capăt ale unui link de semnalizare și
încorporează capabilități, cum ar fi controlul fluxului, validarea
secvenţei de mesaje, detecţie de erori.
Nivelul 3
• asigură adresarea nodurilor şi rutarea mesajelor între punctele
de semnalizare din reţeaua SS7;
• asigură rerutarea traficului de pe legăturile şi punctele de
semnalizare defecte şi controlează traficul când apar congestii;
• asigură transferul mesajelor între punctele de semnalizare de-a
lungul reţelei SS7 indiferent dacă există sau nu legătură directă
între aceste puncte.
Partea de control a conexiunii de semnalizare -
Signaling Connection Control Part (SCCP)
SCCP furnizează funcții adiționale MTP-ului pentru asigurarea

serviciilor orientate și neorientate pe conexiune și îndeplinește două funcții
majore care lipsesc la MTP:
 Prima este de a se adresa la aplicații într-un punct de semnalizare. MTP-

ul poate primi/trimite mesaje numai din/spre nod ca unul întreg; aceasta nu
destinge aplicațiile software într-un nod.
 A doua este Translația de Titlu Global (Global Title Translation – GTT). Un
titlu global este o adresă (un numar 800, cartele de apel, sau numar de
abonat mobil) care este translată de catre SCCP într-un „point code” de
destinație și un număr de subsistem. Un număr de subsistem identifică în
mod unic o aplicație în punctul de semnalizare de destinație. Astfel GTT
eliberează punctul de semnalizare original de sarcina cunoașterii tuturor
destinațiilor posibile.
SCCP este utilizat ca și un strat de transport pentru serviciile bazate pe

TCAP (Transaction Capabilities Applications Part ).
Partea de aplicații a capabilitații de tranzacție -
Transaction Capabilities Application Part (TCAP)
TCAP sprijină schimbul de date între aplicații din rețeaua

SS7 utilizând serviciul SCCP fără conexiune.
Interogările și răspunsurile sunt trimise între SSP și SCP.
Datele sau informațiile preluate sunt trimise înapoi sub forma unui
mesaj TCAP la punctul de semnalizare care a solicitat. De
exemplu, un SSP trimite o interogare TCAP pentru a determina
numărul de rutare asociat cu un număr format 800 sau pentru a
verifica numărul personal de identificare (PIN) al utilizatorului de
card.
În cazul rețelelor de telefonie mobilă (GSM), TCAP
transportă mesajele Partea Aplicațiilor Mobile (MAP - Mobile
Application Part) trimise între comutatoare mobile și baze de date
pentru autentificarea utilizatorului, identificarea echipamentelor și
serviciilor de roaming.
Formatele unităților de semnalizare (SU)
(MSU)
(LSSU)
(FISU)
INDICATOR LUNGIME LI
Length indicator = 0: Fill-in signal unit (FISU)

Length indicator = 1 or 2: Link status signal unit (LSSU)
Length indicator > 2: Message signal unit (MSU)
N2 N4 N3 N2
Etic.
CK Polinomul generator
Cîmpul SIO= SI+ SSF
(octetul informațiilor de serviciu este împărțit în indicatorul serviciu și
cîmpul subserviciu, nivelul 3)
Bits D C B A
• 0 0 0 0 Signalling network management
Bits
messages
• 0 0 0 1 Signalling network testing and
D C (A B rezerva)
maintenance messages • 0 0 International
• 0 0 1 0 Spare
• 0 0 1 1 SCCP network
• 0 1 0 0 Telephone User Part
• 0 1 0 1 ISDN User Part
• 0 1 Spare (for
• 0 1 1 0 Data User Part (call and circuit- international use only)
related messages)
• 0 1 1 1 Data User Part (facility • 1 0 National network
registration and cancellation messages)
• 1 0 0 0 Reserved for MTP Testing User • 1 1 Reserved for
Part
• 1 0 0 1 Broadband ISDN User Part
national use
Cîmpul SIO
• 1 0 1 0 Satellite ISDN User Part Biți 4 4 directia
Ramase sunt in rezerva transmitere
DCBA DCBA
SSF SI
ETICHETA (nivelul 3)
SLS OPC DPC
4 14 14
Lungime (bit)
Signalling Link Selection (SLS)

Originating Point Code (OPC)
Destination Point Code (DPC)
Figure 3/Q.704 – Routing label structure
De la 2 până la 272 bytes
Link status signal unit (LSSU)
• Status field format (SF)

Status indications, bits (ramași în rezervă)
CBA
• 0 0 0 – Status indication "O“ (out of alignment);
• 0 0 1 – Status indication "N“ ("normal" alignment
status);
• 0 1 0 – Status indication "E“ ("emergency" alignment
status);
• 0 1 1 – Status indication "OS“ (out of service);
• 1 0 0 – Status indication "PO“ ("processor outage")
• 1 0 1 – Status indication "B“ ("Busy")
Numerotarea în rețelele de
telecomunicații
PNN al Republicii Moldova
Din Rec. ITU-T E.164 - structura numerotării pentru arii geografice
Țări membre ITU, total 193 țări fiecare cu CC
Repartizarea primei cifre a CC pe glob
Repartizarea resursei de numerotare din PNN după prima cifră
Formatul Atribuire Tipul de numere

numerelor din PNN
0 Prefix național
00 Prefix internațional
1XXXXX Coduri şi numere naționale scurte Non-geografice
2XXXXXXX Numere pentru rețele şi servicii publice de Geografice
comunicații electronice furnizate la puncte fixe
3XXXXXXX Numere pentru rețele şi servicii publice de Geografice şi independente
comunicații electronice furnizate la puncte fixe de locație, furnizate la puncte
şi numere independente de locație fixe şi nomade
4XXXXXXX Rezervă
5XXXXXXX Numere pentru rețele şi servicii publice de Geografice
comunicații electronice furnizate la puncte fixe
6XXXXXXX Numere pentru rețele şi servicii publice de Non-geografice
comunicații electronice furnizate la puncte
mobile
7XXXXXXX Numere pentru rețele şi servicii publice de Non-geografice
comunicații electronice furnizate la puncte
mobile
8XXXXXXX Numere pentru servicii diverse (servicii cu Non-geografice
acces gratuit, servicii cu cost partajat, etc.)
9XXXXXXX Numere pentru servicii cu tarif special Non-geografice
unde: X = 0 ... 9
unde: X = 0 ... 9
unde: X = 0 ... 9
unde: X = 0 ... 9
Protocoale de semnalizare în
NGN
Protocolul de initiere a sesiunii
SIP
*RFC 3261+ “SIP: Session Initiation
Protocol”, IETF, June 2002
(înlocuiește vechiul standard RFC 2543 din 1999)
Componentele funcționale ale rețelei SIP
(UAC) (UAS)
Structura mesajelor SIP
Linia de start
Anteturile
Linie goală (CRLF)*
Conținutul(corpul)
SDP
Linia de start –CERERE
Tip cerere SP Adresa destinație SP Versiune SIP

(Method SP Request-URI SP SIP-Version)
INVITE sip:bob@biloxi.com SIP/2.0
Linia de start - RASPUNS
Versiune SIP SP Cod răspuns SP Descrierea textuală

(SIP-Version SP Status-Code SP Reason-Phrase)
SIP/2.0 100 Trying
Cererea Descrierea
INVITE Stabilește o sesiune între participanți.
ACK Confirmare transmisă ca răspuns la cererea INVITE.
CANCEL Anulează o tranzacție în așteptare la care încă nu este primit răspuns

final.
INFO Oferă un mecanism de transport a informației de nivelul aplicațiilor care

poate îmbunătăți o aplicație SIP (DTMF, GPS locație).
BYE Încheie o sesiune.
MESSAGE Transferuri de mesaje instant între utilizatori aproape în timp real.
REGISTER Înregistrează informații de contact.
NOTIFY Informează un abonat cu privire la schimbarea de stare a resursei (s-a

petrecut un eveniment pentru care s-a cerut confirmare).
OPTIONS Interoghează serverul cu privire la capabilitățile sale.
PRACK Similar cu ACK, însă pentru transmitere fiabilă a răspunsurilor provizorii.
PUBLISH Similar cu REGISTER in cea ce privește posibilitatea unui utilizator să
creeze, modifice și elimine o stare într-o altă entitate care gestionează
această stare în numele utilizatorului.
1xx: Provizoriu – cererea este primită și este în curs
de procesare (caută, apelează, așteaptă, etc.); 100
Trying
2xx: Succes – cererea a fost recepționată, este
înțeleasă și acceptată; 220 OK
3xx: Redirecționare – sînt necesare acțiuni
suplimentare pentru a completa cererea; 302 Moved
Temporarily
4xx: Eroare client – cererea conține greșeli sintactice
sau nu poate fi procesată de acest server; 403 Forbidden
5xx: Eroare server – serverul nu a reușit să
proceseze cererea aparent validă; 503 Service
Unavailable
6xx: Eroare globală – cererea nu poate fi îndeplinită
la orice server. 603 Decline
Anteturi SIP
Cîmpurile anteturilor SIP conțin informații detaliate despre cerere sau răspuns.
field-name: field-value *(;parameter-name=parameter-value)
Cerere & Răspuns Cerere Răspuns
Accept (Accept: audio/*; q=0.2, Authorization Proxy-Authenticate

audio/basic)
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:
From: sip:+37338551212@gatewaymd2.md;tag=887s
Accept-Language: ro, en-gb;q=0.8, en;q=0.7
Allow: IVITE, ACK, OPTIONS, CANCEL, BYE
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
bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
;received=192.0.2.1
Max-Forwards: 68
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 (numărul de octeți din corpul mesajului)
Identificatorul uniform de resurse (URI)
SIP URI are două formate majore,
o formă similară cu o adresă e-mail
user @ host
Exemple:
sip:ion.nazaroi@tlc.utm.md
sip:ion.nazaroi@195.1.2.3
sau alta ca un număr de telefon:

phone-number @host;user=phone
Exemplu
sip:+373 38555000@domain.com;user=phone
sip:+37338555212@server.phone2net.com;user=phone
Descrierea sesiunii în corpul mesajului
Agenții utilizatori SIP folosesc protocolul descriere sesiune SDP
(Session Description Protocol, RFC4566).
Linii de text de forma: <tip> = <value>
Descrierea sesiunii:
• v=protocol version, V=0
• o=owner and session identifier: Identificarea initiatorului sesiunii.
• s=session name: Nume sesiune (Optional).
• i=session information: Info aditionale.
• e=email address: Adresa initiatorului.
• p=phone number: Numar de contact.
Descrieri de timp:
t= (time the session is active): Linia ”t=” specifica pornirea și
oprirea sesiunii. Formatul este: t=<start-time> <stop-time>.
Descrierea media:
m= (media name and transport address): informații cu privire la
fluxurile de media "video", "audio", "text”.
Exemplu de descriere sesiune de protocolul SDP [RFC4566]:
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 (URI)
e=j.doe@example.com (Jane Doe)
c=IN IP4 224.2.17.12/127 (info conexiune)
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)
Diagrama SIP
A ……. Proxy ……. Proxy ……. B
(Registrator)
Register Register
200 Ok 200 Ok
Invite
100 Trying Invite
100 Trying Invite
180 Ringing
180 Ringing
180 Ringing 200 Ok
200 Ok
200 Ok
Ack
Media Session
Bye
200 Ok
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 |
|------------------------------------------------->|
| |
Exemplu de stabilire a unei sesiuni SIP
M1 INVITE Alice -> atlanta.com proxy
Max-Forwards: 70 (numărul maxim de hop-uri pentru transmiterea cererii SIP)
CSeq: 314159 INVITE
Content-Length: 142
(Alice's SDP nu se prezintă)
M2 100 Trying atlanta.com proxy -> Alice

SIP/2.0 100 Trying
;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 0
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
;received=192.0.2.2
;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 0
Protocolul datagramelor utilizator
User Datagram Protocol (UDP)
RFC 768/1980
Protocolul de transport UDP asigură multiplexarea
pachetelor de date și de control folosind numere de port separate:
Numere de porturi
Exemple de porturi bine cunoscute :

20 FTP – Data, 53 - DNS, 80 - HTTP, 546 - DHCP Client, 547 -
DHCP Server
Socket
Antetul UDP
Lungimea max a pachetului IP:
65 535-20 (IP antet)-8 (UDP antet)
=65 507 (practic se utilizează 8192
octeți date)
(max 65 507 octeți)
Lungimea totală a Dacă nu se folosește

datagramei UDP în octeți (dezactivată)
(date+antet) Se completează cu 0-uri
Pseudo-antetul UDP
Antetul UDP nu conține informații despre adresa sursei și a destinației,
prin urmare, chiar dacă portul destinatarului se potrivește, este imposibil de
spus cu exactitate că mesajul a ajuns la locul potrivit. Pentru a verifica dacă
mesajul UDP a ajuns la destinație, se folosește un pseudo-antet:
Câmpul „protocol” conține valoarea 17 (00010001 în formă binară,
0x11 în hexadecimal) - identificatorul protocolului UDP.
Câmpul „Lungimea datagramei UDP” conține lungimea mesajului

UDP (antetul UDP + date; lungimea antetului pseudo nu este luată în
considerare) în octeturi, adică coincide cu același câmp din antetul UDP.
Pseudo-antetul nu este inclus în mesajul UDP. Este folosit pentru a

calcula checksum-ul înainte de a trimite mesajul. La recepție
destinatarul își compune pseudo-antetul folosind adresa gazdei de la
care a sosit mesajul și propria sa adresă.
La primirea mesajului, destinatarul calculează din nou checksum-ul

(luând în considerare câmpul checksum) și, dacă rezultatul este un
număr binar de șaisprezece unități (adică 0xffff sau zicimal 65 535),
atunci checksum-ul este considerat a fi convergent și mesajul este
primit corect.
Suma de control:
RFC 1071
exemplu: add two 16-bit integers

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
suma 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
Deoarece adresele IP sunt utilizate în calculul checksum-ului

UDP, ulrimul este strâns legat de nivelul IP. Prin urmare, UDP
poate rula doar pe IP.
Încapsularea și decapsularea
Protocolul TCP
Updated by: 1122, 3168, 6093, 6528 INTERNET STANDARD
RFC: 793 TRANSMISSION CONTROL PROTOCOL
DARPA INTERNET PROGRAM

PROTOCOL SPECIFICATION
September 1981
TCP este un protocol fiabil orientat pe conexiune, cap la cap.
TCP prevede o comunicare fiabilă dintre perechile de procese

din calculatoarele gazdă atașate rețelelor de comunicații
interconectate.
Orientat la conexiune, fiabil de la cap la cap
(unicast):
Nu există erori de biți din datorită checksum.
Păstrarea ordinei pachetelor.
Fără duplicare de pachete.
Fără pierderi de pachete.

ANTETUL TCP
ANTETUL TCP
Portul sursa (16 biti) - identifica portul ce trimite datele.
Portul destinatie (16 biti) - identifica portul ce recepteaza datele.
Sequence number (numarul secventei) (32 biti) - are un rol

dublu:
- daca flag-ul SYN este prezent atunci acesta este numarul
initial al secventei si primul byte de date este numarul secventei plus 1.
- daca flag-ul SYN nu este prezent atunci primul byte de date
este numarul secventei.
Acknowledgment number(32 biti) – daca este setat flag-ul ACK

atunci valoarea acestui camp este numarul de secventa pe care
expeditorul validarii il asteapta.
Offset de date (4 biti) – specifica marimea header-ului TCP in

cuvinte de 32 de biti. Marimea minima este 5 si cea maxima este 15 de
unde rezulta o un minim de 20 octeți si un maxim de 60. Acest camp isi
ia numele si din faptul ca este deasemenea offsetul de la startul
pachetului TCP.
Rezervat (4 biti) – existent pentru folosiri ulterioare si trebuie setat la 0.
Flag-urile de control sunt in numar de 8 a cate un bit:

CWR - Congestion Window Reduced, este flagul trimis de sursa pentru a
indica ca a primit un segment TCP cu flagul ECE setat.
ECE (ECN-Echo) – indica faptul ca peer-ul TCP este ECN (Explicit
Congestion Notification).
URG – indica daca campul Pointer URGent este important.
ACK – indica daca campul ACK (Validare ) este important.
PSH – functia Push
RST – resetare conexiune
SYN – sincronizare a numerelor de secventa
FIN – incheierea segmentului de date
Window (16 biti) – marimea ferestrei destinatie ce specifica numarul de
bytes ( peste numarul de secvente din campul de validare ) pe care receptorul
este dispus sa il primeasca
Verificare(Checksum) (16 biti) – este folosit pentru verificarea existentei

erorilor din antet sau segmentul de date
Pointer urgenta (16 biti) – daca flagul URG este setat, atunci acest camp
este un offset din numarul de secventa ce indica ultimul byte urgent de date.
Optiuni (biti variabili) – lungimea totala a campului trebuie sa fie
multiplu de 32 si campul offset de date trebuie ajustat in concordanta
0 – sfarsitul listei de optiuni
1 – fara operator ( NOP, Padding )
2 – lungimea maxima a segmentui
3 – dimensiunea ferestrei
4 – validare selectiva
5–
6–
7–
8 – timestamp
Ultimul camp nu face parte din header. Continutul acestui camp ramane
la latitudinea nivelului de protocol superior si face parte din header.
Data – aceasta este portiunea de date a pachetului TCP. Poate fi

reprezentata de orice protocol de aplicatii. Cele mai des folosite sunt
HTTP, Telnet, SSH, FTP.
Pseudoheader adăugat la datagrama TCP
Protocoale de semnalizare în
NGN
Protocolul de initiere a sesiunii
SIP
*RFC 3261+ “SIP: Session Initiation
Protocol”, IETF, June 2002
(înlocuiește vechiul standard RFC 2543 din 1999)
Componentele funcționale ale rețelei SIP
(UAC) (UAS)
Structura mesajelor SIP
Linia de start
Anteturile
Linie goală (CRLF)*
Conținutul(corpul)
SDP
Linia de start –CERERE
Tip cerere SP Adresa destinație SP Versiune SIP

(Method SP Request-URI SP SIP-Version)
Linia de start - RASPUNS
Versiune SIP SP Cod răspuns SP Descrierea textuală

(SIP-Version SP Status-Code SP Reason-Phrase)
SIP/2.0 100 Trying
Cererea Descrierea
INVITE Stabilește o sesiune între participanți.
ACK Confirmare transmisă ca răspuns la cererea INVITE.
CANCEL Anulează o tranzacție în așteptare la care încă nu este primit răspuns

final.
INFO Oferă un mecanism de transport a informației de nivelul aplicațiilor care

poate îmbunătăți o aplicație SIP (DTMF, GPS locație).
BYE Încheie o sesiune.
MESSAGE Transferuri de mesaje instant între utilizatori aproape în timp real.
REGISTER Înregistrează informații de contact.
NOTIFY Informează un abonat cu privire la schimbarea de stare a resursei (s-a

petrecut un eveniment pentru care s-a cerut confirmare).
OPTIONS Interoghează serverul cu privire la capabilitățile sale.
PRACK Similar cu ACK, însă pentru transmitere fiabilă a răspunsurilor provizorii.
PUBLISH Similar cu REGISTER in cea ce privește posibilitatea unui utilizator să
creeze, modifice și elimine o stare într-o altă entitate care gestionează
această stare în numele utilizatorului.
1xx: Provizoriu – cererea este primită și este în curs
de procesare (caută, apelează, așteaptă, etc.); 100
Trying
2xx: Succes – cererea a fost recepționată, este
înțeleasă și acceptată; 220 OK
3xx: Redirecționare – sînt necesare acțiuni
suplimentare pentru a completa cererea; 302 Moved
Temporarily
4xx: Eroare client – cererea conține greșeli sintactice
sau nu poate fi procesată de acest server; 403 Forbidden
5xx: Eroare server – serverul nu a reușit să
proceseze cererea aparent validă; 503 Service
Unavailable
6xx: Eroare globală – cererea nu poate fi îndeplinită
la orice server. 603 Decline
Anteturi SIP
Cîmpurile anteturilor SIP conțin informații detaliate despre cerere sau răspuns.
field-name: field-value *(;parameter-name=parameter-value)
Cerere & Răspuns Cerere Răspuns
Accept (Accept: audio/*; q=0.2, Authorization Proxy-Authenticate

audio/basic)
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:
From: sip:+37338551212@gatewaymd2.md;tag=887s
Accept-Language: ro, en-gb;q=0.8, en;q=0.7
Allow: IVITE, ACK, OPTIONS, CANCEL, BYE
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
bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1
;received=192.0.2.2
;received=192.0.2.1
Max-Forwards: 68
CSeq: 314159 INVITE
Content-Length: 142 (numărul de octeți din corpul mesajului)
Identificatorul uniform de resurse (URI)
SIP URI are două formate majore,
o formă similară cu o adresă e-mail
user @ host
Exemple:
sip:ion.nazaroi@tlc.utm.md
sip:ion.nazaroi@195.1.2.3
sau alta ca un număr de telefon:

phone-number @host;user=phone
Exemplu
sip:+373 38555000@domain.com;user=phone
sip:+37338555212@server.phone2net.com;user=phone
Descrierea sesiunii în corpul mesajului
Agenții utilizatori SIP folosesc protocolul descriere sesiune SDP
(Session Description Protocol, RFC4566).
Linii de text de forma: <tip> = <value>
Descrierea sesiunii:
• v=protocol version, V=0
• o=owner and session identifier: Identificarea initiatorului sesiunii.
• s=session name: Nume sesiune (Optional).
• i=session information: Info aditionale.
• e=email address: Adresa initiatorului.
• p=phone number: Numar de contact.
Descrieri de timp:
t= (time the session is active): Linia ”t=” specifica pornirea și
oprirea sesiunii. Formatul este: t=<start-time> <stop-time>.
Descrierea media:
m= (media name and transport address): informații cu privire la
fluxurile de media "video", "audio", "text”.
Exemplu de descriere sesiune de protocolul SDP [RFC4566]:
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 (URI)
e=j.doe@example.com (Jane Doe)
c=IN IP4 224.2.17.12/127 (info conexiune)
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)
Diagrama SIP
A ……. Proxy ……. Proxy ……. B
(Registrator)
Register Register
200 Ok 200 Ok
Invite
100 Trying Invite
100 Trying Invite
180 Ringing
180 Ringing
180 Ringing 200 Ok
200 Ok
200 Ok
Ack
Media Session
Bye
200 Ok
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 |
|------------------------------------------------->|
| |
Exemplu de stabilire a unei sesiuni SIP
M1 INVITE Alice -> atlanta.com proxy
Max-Forwards: 70 (numărul maxim de hop-uri pentru transmiterea cererii SIP)
CSeq: 314159 INVITE
Content-Length: 142
(Alice's SDP nu se prezintă)
M2 100 Trying atlanta.com proxy -> Alice

SIP/2.0 100 Trying
;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 0
M3 INVITE atlanta.com proxy -> biloxi.com proxy
;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
;received=192.0.2.2
;received=192.0.2.1
CSeq: 314159 INVITE
Content-Length: 0
PROTOCOLUL H.323
• Recomandarea ITU-T H.323 ”Sisteme de

comunicații multimedia bazate pe pachete”
(12/09, ver.7)
• Versiunile anterioare au fost aprobate în 1996
(v.1), 1998 (v.2), 1999 (v.3), 2000 (v.4), 2003 (v.5),
2006(v.6)
Componentele unui sistem H.323
Terminale furnizează conferințe punct la
punct și multipunct pentru audio și, opțional
video și date.
Gateway-ul interconectează cu rețelele ISDN

sau PSTN.
Unitate de control multipunct (MCU) permite

organizarea conferințelor multipunct.
Gatekeeper-ul asigură controlul admiterii

apelului și traslarea adresei într-un domeniu
administrativ numit zonă H.323.
Schema-bloc a terminalului H.323
Echipament Video codec H.261, Sincronizar Conform definiției
I/O video H.263, H.264 e
recepție
Echipament Audio codec G.711, (Receive
I/O audio G.722, G.723, G.728, path delay) Int
G.729 erf
Aplicații date ață
utilizator Nivel ITU-T
H.225.0
Control sistem reț
ea
Control H.245
Interfață
utilizator de
Control apel
control a
H.225.0
sistemului
Control RAS
H.225.0
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 (MCU).
Terminalul, gateway-ul și MCU sunt puncte finale

(endpoint) care asigură inițierea și terminarea
fluxurilor media: audio, video sau de date, sau o
combinație a lor.
Gateway
Funcții Funcții
Funcții de
terminal terminal
conversie
H.323 SCN sau
sau MCU
MCU SCN
Rețea IP Rețea cu
comutație
circuite
Zona rețelei H.323
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).
 Controlul admisiei terminalelor în rețea.
 Controlul, managementul și rezervarea ratei de

transfer a rețelei.
 Rutarea mesajelor de semnalizare între terminalele

unei zone.
Stiva de protocoale H.323 în mediul IP
H.245 H.225 Audio/Video
Control RAS RTCP RTP
apel
TCP UDP
IP
Nivel Link date
Nivel Fizic
Deschiderea canalului RAS (folosește UDP, porturile 1719 (mesaje
H.225 RAS) și 1718 (descoperire GK multicast).
Protocolul RAS
• Descoperirea garekeeper-ului (manual sau automat –
GRQ, GCF/GRJ);
• Înregistrarea dispozitivelor terminale la GK (RRQ(se
anunta lista adreselor alias si de transport), RCF/RRJ);
• Controlul admiterii dispozitivelor terminale în rețea
(ARQ(adresa alias a terminalului solicitat), ACF (adresa canal
semnalizare, plafonul ratei de biti) /ARJ,);
• Localizarea dispozitivelor terminale (LRQ, LCF/LRJ);
• Controlul benzii de trecere (ratei de biți) în procesul
servirii apelului (BRQ, BCF/BRJ ;
• Obținerea informațiilor de stare de la dispozitivele
terminale (IRQ, IRR).
Gatekeeper
Terminal
GRQ (multicast IP 224.0.1.41, port
UDP 1718)
GCF/GRJ(anunta adresa transport can. RAS)
RRQ (transmite la adresa trans. can. RAS; se

anunta lista adreselor alias si de transport)
RCF/RRJ
LRQ Solicită datele de contact pentru una
(Location_Request) sau mai multe adrese E.164.
LCF Confirmare de locație trimisă de GK și

(Location_Confirm) conține adresele canalui de
semnalizare sau canalui RAS ale sale
sau ale dispozitivilui terminal solicitat.
LRJ Locație respinsă-trimis de GK-ele care

(Location_Reject) au primit cererea de localizare LRQ și
la care dispozitivul terminal nu este
înregistrat.
Mesajele de localizare
Protocolul de semnalizare apel H.225.0 (Q.931)
• SETUP - mesaj trimis de partea apelantă în scopul stabilirii
unei conexiuni. (către portul TCP bine cunoscut 1720).
• 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 e-a fost trimis
semnalul despre intrarea de apel.
• CONNECT - mesaj de informare a dispozitivului apelant că
utilizatorul solicitat a acceptat apelul. Mesajul posibil să
conțină adresa de transport a canalului de control H.245.
• RELEASE COMPLETE – mesaj trimis de dispozitivul terminal
apelat sau apelant cu scopul de eliberare a conexiunii.
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
(Stabilirea canalelor de control)
Protocolul de control a canalelor logice H.245 „Protocolul de
control pentru comunicații multimedia” (05/2011)
Canal logic (cu numărul 0) permite terminalelor:
• Determininarea dispozitivului terminal master și
terminal sclav în scopuri de management de protocol;
• Schimbul de capabilități și preferințe de comunicare (ce
codec-uri audio și video acceptă cealaltă parte);
• Deschiderea și închiderea canalele logice bi- sau
unidirecționale pentru fluxurile media;
• Alegerea modului de funcționare; (Videomode,
AudioMode, DataMode, EncryptionMode)
• Determinarea timpului de latență dus-întors;
• Efectuarea semnalizării pe bucla locală în scopuri de
întreținere.
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
RAS; H.225.0; H.245.

PROTOCOLUL H.248/MEGACO
Elaborat ITU și IETF

Primele versiuni – publicate în anul 2000.
În prezent:
ITU: H.248.1(v.3) 03.2013 în vigoare;
Extensii H.248.xx.
IETF: RFC3525 MEGACO(declarat istoric).
IT U - T H.248 Sub-series
Implementors
Guide
TELECOMMUNICATION
STANDARDIZATION SECTOR
OF ITU
(27 October 2017)
SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS

Infrastructure of audiovisual services – Communication procedures
Implementors’ Guide for the H.248 Sub-series of
Recommendations (“Media Gateway Control
Protocol”)
ITU-T Recommendation ITU-H.248.98
TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (02/2016)

SERIES H: AUDIOVISUAL AND MULTIMEDIA SYSTEMS
Infrastructure of audiovisual services – Communication procedures
Gateway control protocol: Support of remote media pause and
resume
Diagrama retelei H.248
PSTN/ISDN
PSTN/ISDN
Descompunerea funcției de media gateway H.323 în MGC și MG1...MGn

Abstracții utilizate în modelul de conexiune H.248:
Terminația inițiază sau oprește unul sau mai multe fluxuri
media.
• fizice și
• efemere
TerminationID -fiecare terminație are identificator unic;
Root - indentificator comun (adresare la toate terminațiile);
ALL - (adresare simultană la mai multe terminale);
CHOOSE - (selectare a terminației corespunzătoare).
Contextul este o asociere logică dintre cîteva terminații.

Atributele contextului sînt:
Identrificatorul (ContextID);
Descriptorul topologiei - descrie fluxurile informaționale între
terminațiile din interiorul GW-lui;
Indicatorul de prioritate (16 nivele, de la 0 pînă la 15-cea mai înaltă
prioritate);
Indicator pentru apelurile de urgență cu cea mai înaltă prioritate.
Exemplu de model de conexiune H.248.1
Media Gateway
Terminație
Terminație Canal SCN
Flux RTP Terminație
Context Canal SCN
Terminație
Terminație
Canal SCN
Flux RTP Context Context NULL
Terminație Terminație
Flux RTP Context Canal SCN
Exemplu Context : apel tlf
Medium=audio, Medium=audio,
T1 T2
Mode=sendReceive Mode=sendReceive
Context : multimedia
Stream=1,
medium=audio T1 T2
Stream=1,
medium=audio
T3
Stream=2,
medium=video
Stream=2,
medium=video
Comenzile H.248:
Add - adaugă o terminație la contextul indicat prin
ContextID.
Modify - modifică proprietățile terminației.
Subtract - elimină terminația din context.
Move - deplasează terminația dintr-ul context în altul.
AuditValue - MGC cere informații curente privind
proprietățile terminației.
AuditCapability - MGC solicită de la MG informații privind
valorile posibile pentru proprietățile terminației.
Notify - permite MG-lui să informeaze MGC de apariția
unor evenimente în gateway.
ServiceChange - permite MG să informeze MGC că o
terminație sau un grup de terminații va fe scos din serviciu sau
întors în serviciu, iar MGC poate instrui MG să introducă sau să
scoată din serviciu o terminație sau un grup de terminații.
Descriptorii H.248
Descriptorul determină parametrii unei comenzi și este element
sintactic al protocolului care grupează proprietățile conexe.
Formatul descriptorului:
DescriptorName=<someID>{parm=value,parm=value...}.
NumeDescriptor= <IdentificatorID> {parametru=valoare,
parametru=valoare…}.
Exemplu:
Media { Stream = 1 {
LocalControl {
Mode = Inactive,
tdmc/gain=2, ; in dB,
tdmc/ec=on
},
}
},
Events = 2222 {al/of {strict=state}}
Exemple Descriptori
• Mux • Signals
• Media: • Audit
• TerminationState • ServiceChange
• Stream: • DigitMap
 LocalControl • ObservedEvents
• Statistics
 Local
• Topology
 Remote
• Error
 Statistics • Extension
• Events
Media. Descriptorul Media specifică parametrii pentru toate fluxurile
media.
Acești parametri sînt structurați în 2 descriptori:
1.TerminationState Descriptor, care specifică proprietățile unei
terminații (care nu sînt dependente de flux, d.ex. Proprietatea ServiceStates descrie
una din următoarele stări: "Test", "OutOfService" sau "InService“)
2. Descriptori Stream -descrie un singur flux media bidirectional.
În cadrul descriptorului Stream există pînă la 4 descriptori subsidiari:
LocalControl, Local, Remote și Statistics.
Relația ierarhică dintre acesti descriptori este astfel:
Media Descriptor
TerminationState Descriptor
Stream Descriptor
LocalControl Descriptor (conține proprietățile Mode: "SendOnly", "RecvOnly",
"SendRecv", "Inactive" și "loopback”)
Local Descriptor (se referă la proprietățile fluxurilor media pe care MG le primește
de la entitatea distantă)
Remote Descriptor (-pe care MG le trimite entității distante)
Statistics Descriptor
Mux. Descriptorul multeplexare 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.
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
receptoriului pe furcă, etc.
Signals. Descriptorul Signals conține setul de semnale pe care

gateway-ul îl solicitată de la terminație, de exemplu, tonuri,
anunțuri sau semnale legate de butonul de furcă (hookswitch)
Audit. Descriptorul Audit specifică ce informații MGC dorește să

verifice. Solicita de la MG trimiterea a careva descriptor ( Event,
Media, Signals, ObservedEvents, Statistics și alții) cu valorile
curente referitor la evenimentele, semnalele, statisticile și
proprietăților sale.
DigitMap. Descriptorul DigitMap este un plan de apelare rezident
în MG în corespundere cu care se efectuează detectarea și
raportarea către MGC a cifrelor primite de terminație.
Protejat de trei cronometre:
timer de pornire (T), (duratei de așteptare a pornirii

culegerii cifrelor);
timer scurt (S), (ș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);
timer lung (L), (este nevoie de cel puțin încă o cifră,

atunci MG va mai aștepta un timp egal cu durata
determinată de timerul lung).
MESAJ
Descriptor-1
Comanda 1 …
Acțiunea 1: Descriptor-n
ContextID 1
***
Comanda n
Tranzacția 1 ***
Acțiunea n:
ContextID n
***
Tranzacția n
Structura mesajului H.248
Megaco/H.248 message
Header Transaction Transaction ... Transaction

Req or Reply Req or Reply Req or Reply
Trans Hdr Action ... Action
Ctx Hdr Ctx Properties Command ... Command
Cmd Hdr Descriptor ... Descriptor

În acest exemplu, adresele IP sînt: pentru RGW1 este
124.124.124.222, pentru RGW2 este 125.125.125.111, iar
pentru MGC este 123.123.123.4. Portul MEGACO este numărul
55555 pentru toate cele trei entități.
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}
}}}
MGC to RGW1:
MEGACO/3 [123.123.123.4]:55555
Context = - {
Modify = A4444 {
Media { Stream = 1 {
LocalControl {
Mode = Inactive,
tdmc/gain=2, ; in dB,(TDM Circuit Package, amplificarea=2dB,
ecocomp. Con.)
tdmc/ec=on
},
}
},
Events = 2222 {al/of {strict=state}}
}
}
}
RGW1 to MGC:
MEGACO/3 [124.124.124.222]:55555
Context = - {
Notify = A4444 {ObservedEvents =2222 {
19990729T22000000:al/of(init=OFF)}}
MGC to RGW1:
MEGACO/3 [123.123.123.4]:55555
Context = - {
Modify = A4444 {
Events = 2223 {
al/on(strict=state), dd/ce {DigitMap=Dialplan0}
},
Signals {cg/dt},
DigitMap= Dialplan0{
(0| 00|[1-
7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)}
}
}
}
Comutarea Multiprotocol cu Etichetă
MPLS
(Multiprotocol Label Switching)
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, inclusiv
T1/E1, ATM, Frame Relay și DSL.
Tehnologia multiprotocol de comutare cu
etichete (MPLS)
• Elaborat de IETF în anul 1997, acum în
vigoare RFC 3031/2001
• Î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
Modelul de bază al rețelei MPLS
Internet
LER
LER IP
LSR
LSR
MPLS LSR
LSR MPLS
LER IP
INCLUDE: LSR = Label Switched Router și LER = Label Edge Router;

LSP=Label Switched Path;
FEC=Forwarding Equivalency Class. 3
Forwarding Equivalence Class
O clasă de echivalență pentru expediere (FEC) este un flux de
pachete care sunt redirecționate de-a lungul aceleiași căi și sunt
tratate la fel în ceea ce privește expedierea.
Toate pachetele dintr-un FEC au aceeași etichetă. Cu toate
acestea, nu toate pachetele care au aceeași etichetă aparțin
aceluiași FEC, deoarece valorile clasei de trafic (TC) pot fi diferite.
Router-ul care distribuie pachetele pe clase FEC este LER de
intrare (clasifică și etichetează pachetele).
Exemple de atribuire la o clasă FEC:
Pachete cu anumit prefix al adresei IP de destinație la nivelul 3

Pachetele multicast aparținând unui anumit grup
Pachete cu același tratament de redirecționare, pe baza TC
(domeniului precedent sau IP DiffServ Code Point (DSCP)
Cadrele de nivel 2 transmise printr-o rețea MPLS (adresa MAC)
VPN concretă
Domeniul MPLS
Un set de noduri MPLS învecinate care se află sub un

singur domeniu administrativ.
Antetul MPLS
20 biți 3 biți 1 bit 8 biți
Eticheta TC S TTL
Distribuirea cu protocoalele TC: Traffic Class field
RFC 5462, 2009
(LDP, RSVP)
Antet N2 Antet MPLS Antet N3 (IP) Date

(Ethernet) utilizator
RFC 3031 nu specifică un singur protocol de distribuire a

etichetelor, sunt standardizate mai multe protocoale. Unele protocoale
existente așa ca RSVP-TE (ReSerVation Protocol- Traffic Engineering) și
BGP au fost extinse, dar a fost definit și un nou protocol - Label Distribution
Protocol (LDP).
Exemplu de comutație după etichetă
La intrarea intr-un domeniu MPLS pachetele sunt clasificate
în clase de echivalență (FEC)
LER LER
Adresa Eticheta Etichet Adresa

IP de ieșire a de IP,
intrare urmato
rul hop
LSR LSR
193.2/16 23 Eticheta Eticheta Eticheta Eticheta 57 220.1.1
de intrare de de intrare de .1
ieșire ieșire 193.2.3.4
193.2.3.4
Nivelul 2 Atribuire Scoate Nivelul
(L2) etichetă 23 42 42 57 etichet 2
inițială a (L2)
Termeni utilizați pentru descrierea manipulărilor cu etichetele:
SWAP - Eticheta de sus este îndepărtată și înlocuită cu o nouă etichetă.

PUSH - Una sau mai multe etichete sunt adăugate (împinse) deasupra
etichetei înlocuite.
POP - Eticheta de sus este eliminată.
Procedura PHP (Penultimate Hop Popping)
PHP folosește eticheta rezervată „Implicit Null”, valoare de etichetă 3. În acest caz
pierdem QoS pe baza MPLS TC. Pentru a păstra biții TC se folosește eticheta “Explicit
Null” , valoarea 0, care nu lasă penultimul hop să elimine eticheta. Trimite o valoare de
etichetă 0, dar cu biții TC intacți.
Stiva de etichete MPLS
Antet Eticheta Eticheta Eticheta Eticheta Antetul Date

nivelul MPLS MPLS MPLS MPLS nivelul
2 Nr.4 Nr.3 Nr.2 Nr.1 3
S=0 S=0 S=0 S=1
Ultima Prima
inscrisa inscrisa
prima ultima
citita citita
Stiva cu două antete MPLS
Domen comun: LSP1+LSP2
Domeniul 1 LSP2
Eticheta 14 se exlude,
PHP
LSP1 Domeniul 2
Exemplu de LSP arbore
Structura stivei de etichete pentru calea

LSP4
Nivele LSP Eticheta
Comună pentru LSP1,
4
LSP2, LSP3, LSP4
3
LSP3, LSP4
2
LSP4
1 doar LSP4
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:
1. Mesaje de descoperire, folosite pentru a anunța și a menține
prezența a unui LSR dintr-o rețea. (Hello, KeepAlive, pe UDP)
2. Mesaje de sesiune, utilizate pentru a stabili, întreține și înceta
sesiuni între perechi/peers LDP. (Initialization, Shutdown, Address,
Address Withdraw, pe TCP)
3. Mesaje de publicitate, utilizate pentru a crea, modifica și șterge
mapări de etichete pentru FEC. (Label Request, Label Abort Request,
Label Mapping, Label Withdraw, Label Release , pe TCP)
4. Mesaje de notificare, utilizate pentru a furniza informații
consultative și pentru a semnala informații despre eroare. (Notification,
de ex. Mesaj LDP, LDP PDU sau TLV greșit, erori fatale_Session
KeepAlive Timer Expiration, Unilateral Session Shutdown, pe TCP).
LDP este situat la nivelul aplicațiilor:
Antetul LDP are formatul:
Version PDU Length
LDP Indentifier
Versiune - numărul de versiune al protocolului, 1.
Lungimea PDU – număr pe doi octeți care specifică lungimea PDU în octeți, cu
excepția câmpurilor Versiune și Lungime PDU. Lungimea maximă admisă a PDU
este negociabilă, dar nu va depăși 4096 octeți.
Identificator LDP - Câmp de șase octeți care identifică în mod unic spațiul de
etichetă al LSR expeditor pentru care se aplică acest PDU. Primii patru octeți
identificați LSR și TREBUIE să fie o valoare unică la nivel global (un ID de router pe
32 de biți atribuit LSR, de regulă adresa IP). Ultimii doi octeți identifică un spațiu de
etichetă în cadrul LSR.
PDU LDP este un antet LDP urmat de unul sau mai multe mesaje LDP.
Mesajele LDP au următorul format:
U Message Type Message Length
Message ID
Mandatory Parameters (TLV)
Optional Parameters (TLV)
U – Unknown
Tip mesaj – Notification (0x0001), Hello (0x0100), Initialization (0x0200), KeepAlive ,
Address, Address Withdraw, Label Mapping, Label Request, Label Abort Request, Label
Withdraw, Label Release.
Lungimea mesajului - Specifică lungimea în octeți a ID-ului mesajului, parametrii
obligatorii și parametrii opționali.
ID mesaj - Valoare pe 32 de biți utilizată pentru identificarea acestui mesaj. Folosit de către
expeditor LSR pentru a facilita identificarea mesajelor de notificare care se pot aplica la
acest mesaj. Un LSR care trimite un mesaj de notificare în răspunsul la acest mesaj
TREBUIE să includă acest ID de mesaj în TLV de stare transportat de mesajul de notificare.
Parametri obligatorii - Set de lungime variabilă a parametrilor necesari ai mesajului.
Parametrii opționali - Set de lungime variabilă a parametrilor opționali ai mesajului.
LDP utilizează o schemă de codificare Type-Length-Value (TLV)
pentru a codifica informațiile transportate în mesajele LDP.
U – Unknown, F – Forward - 2 biți care determină comportamentul

atunci când LSR nu recunoaște tipul.
Tip - Codifică modul în care trebuie interpretat câmpul Valoare (Ex.
0x0200 - Generic Label, 0x0103 - Hop Count )
Lungime - Specifică lungimea câmpului Valoare în octeți.
Valoare - Octeți care codifică informațiile interpretate așa cum este
specificat de câmpul Tip.
Schema de codificare TLV este foarte generală. În principiu, totul care
apare într-un PDU LDP ar putea fi codificat ca TLV.
LDP definește mesajele, TLV-urile și procedurile în următoarele domenii:
 Descoperire de la egal la egal
 Stabilirea/Managementul sesiunii
 Distribuirea etichetelor
 Notificarea erorilor și a informațiilor de consiliere
Sesiune LDP între LSR-uri pentru a face schimb de etichete.
LSR menține etichetele ”învățate” într-o bază de informații pentru

etichete- Label Information Base (LIB).
Mesajul Hello este transmis de LSR periodic ca pachet UDP
către portul de descoperire LDP 646 pentru „toate routerele de pe
această subrețea” (multicast). Când un LSR alege să stabilească o
sesiune cu un alt LSR descoperit prin mesajul Hello, acesta
folosește procedura de inițializare LDP pe transportul TCP. După
finalizarea cu succes a procedurii de inițializare, cele două LSR-
uri sunt parteneri LDP și pot face schimb de mesaje publicitare.
După schimbul de mesaje Hello LSR-urile declanșează
stabilirea sesiunii LDP.
Stabilirea sesiunii este un proces în doi pași:

- Stabilirea conexiunii de transport
- Inițializarea sesiunii.
După ce LSR1 și LSR2 stabilesc o conexiune de transport, ei
negociază parametrii sesiunii prin schimbul de mesaje de
inițializare LDP.
Negocierea cu succes finalizează stabilirea unei sesiuni LDP
între LSR1 și LSR2 pentru publicitatea spațiilor de etichete.
Modificarea valorii câmpului TTL al antetului IP și antetului MPLS
Comutarea Multiprotocol cu Etichetă
MPLS
(Multiprotocol Label Switching)
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, inclusiv
T1/E1, ATM, Frame Relay și DSL.
Tehnologia multiprotocol de comutare cu
etichete (MPLS)
• Elaborat de IETF în anul 1997, acum în vigoare
RFC 3031/2001
• Î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
Modelul de bază al rețelei MPLS
Internet
LER
LER IP
LSR
LSR
MPLS LSR
LSR MPLS
LER IP
INCLUDE: LSR = Label Switched Router și LER = Label Edge Router;

LSP=Label Switched Path;
FEC=Forwarding Equivalency Class. 3
Forwarding Equivalence Class
O clasă de echivalență pentru expediere (FEC) este un flux de
pachete care sunt redirecționate de-a lungul aceleiași căi și sunt
tratate la fel în ceea ce privește expedierea.
Toate pachetele dintr-un FEC au aceeași etichetă. Cu toate
acestea, nu toate pachetele care au aceeași etichetă aparțin
aceluiași FEC, deoarece valorile clasei de trafic (TC) pot fi diferite.
Router-ul care distribuie pachetele pe clase FEC este LER de
intrare (clasifică și etichetează pachetele).
Exemple de atribuire la o clasă FEC:
Pachete cu anumit prefix al adresei IP de destinație la nivelul 3

Pachetele multicast aparținând unui anumit grup
Pachete cu același tratament de redirecționare, pe baza TC
(domeniului precedent sau IP DiffServ Code Point (DSCP)
Cadrele de nivel 2 transmise printr-o rețea MPLS (adresa MAC)
VPN concretă
Domeniul MPLS
Un set de noduri MPLS învecinate care se află sub un

singur domeniu administrativ.
Antetul MPLS
20 biți 3 biți 1 bit 8 biți
Eticheta TC S TTL
Distribuirea cu protocoalele TC: Traffic Class field
RFC 5462, 2009
(LDP, RSVP)
Antet N2 Antet MPLS Antet N3 (IP) Date

(Ethernet) utilizator
RFC 3031 nu specifică un singur protocol de distribuire a

etichetelor, sunt standardizate mai multe protocoale. Unele protocoale
existente așa ca RSVP-TE (ReSerVation Protocol- Traffic Engineering) și
BGP au fost extinse, dar a fost definit și un nou protocol - Label Distribution
Protocol (LDP).
Exemplu de comutație după etichetă
La intrarea intr-un domeniu MPLS pachetele sunt clasificate
în clase de echivalență (FEC)
LER LER
Adresa Eticheta Etichet Adresa

IP de ieșire a de IP,
intrare urmato
rul hop
LSR LSR
193.2/16 23 Eticheta Eticheta Eticheta Eticheta 57 220.1.1
de intrare de de intrare de .1
ieșire ieșire 193.2.3.4
193.2.3.4
Nivelul 2 Atribuire Scoate Nivelul
(L2) etichetă 23 42 42 57 etichet 2
inițială a (L2)
Termeni utilizați pentru descrierea manipulărilor cu etichetele:
SWAP - Eticheta de sus este îndepărtată și înlocuită cu o nouă etichetă.

PUSH - Una sau mai multe etichete sunt adăugate (împinse) deasupra
etichetei înlocuite.
POP - Eticheta de sus este eliminată.
Procedura PHP (Penultimate Hop Popping)
PHP folosește eticheta rezervată „Implicit Null”, valoare de etichetă 3. În acest caz
pierdem QoS pe baza MPLS TC. Pentru a păstrabiții TC se folosește eticheta Explicit Null
care nu lasă penultimul hop să elimine eticheta. Trimite o valoare de etichetă 0, dar cu
biții TC intacți.
Stiva de etichete MPLS
Antet Eticheta Eticheta Eticheta Eticheta Antetul Date

nivelul MPLS MPLS MPLS MPLS nivelul
2 Nr.4 Nr.3 Nr.2 Nr.1 3
S=0 S=0 S=0 S=1
Ultima Prima
inscrisa inscrisa
prima ultima
citita citita
Stiva cu două antete MPLS
Domen comun: LSP1+LSP2
Domeniul 1 LSP2
Eticheta 14 se exlude,
PHP
LSP1 Domeniul 2
Exemplu de LSP arbore
Structura stivei de etichete pentru calea

LSP4
Nivele LSP Eticheta
4
LSP2, LSP3, LSP4
3
LSP3, LSP4
2
LSP4
1 doar LSP4
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:
1. Mesaje de descoperire, folosite pentru a anunța și a menține
prezența a unui LSR dintr-o rețea. (Hello, KeepAlive, pe UDP)
2. Mesaje de sesiune, utilizate pentru a stabili, întreține și înceta
sesiuni între perechi/peers LDP. (Initialization, Shutdown, Address,
Address Withdraw, pe TCP)
3. Mesaje de publicitate, utilizate pentru a crea, modifica și șterge
mapări de etichete pentru FEC. (Label Request, Label Abort Request,
Label Mapping, Label Withdraw, Label Release , pe TCP)
4. Mesaje de notificare, utilizate pentru a furniza informații
consultative și pentru a semnala informații despre eroare. (Notification,
de ex. Mesaj LDP, LDP PDU sau TLV greșit, erori fatale_Session
KeepAlive Timer Expiration, Unilateral Session Shutdown, pe TCP).
LDP este situat la nivelul aplicațiilor:
Antetul LDP are formatul:
Version PDU Length
LDP Indentifier
Versiune - numărul de versiune al protocolului, 1.
Lungimea PDU – număr pe doi octeți care specifică lungimea PDU în octeți, cu
excepția câmpurilor Versiune și Lungime PDU. Lungimea maximă admisă a PDU
este negociabilă, dar nu va depăși 4096 octeți.
Identificator LDP - Câmp de șase octeți care identifică în mod unic spațiul de
etichetă al LSR expeditor pentru care se aplică acest PDU. Primii patru octeți
identificați LSR și TREBUIE să fie o valoare unică la nivel global (un ID de router pe
32 de biți atribuit LSR, de regulă adresa IP). Ultimii doi octeți identifică un spațiu de
etichetă în cadrul LSR.
PDU LDP este un antet LDP urmat de unul sau mai multe mesaje LDP.
Mesajele LDP au următorul format:
U Message Type Message Length
Message ID
Mandatory Parameters (TLV)
Optional Parameters (TLV)
U – Unknown
Tip mesaj – Notification (0x0001), Hello (0x0100), Initialization (0x0200), KeepAlive ,
Address, Address Withdraw, Label Mapping, Label Request, Label Abort Request, Label
Withdraw, Label Release.
Lungimea mesajului - Specifică lungimea în octeți a ID-ului mesajului, parametrii
obligatorii și parametrii opționali.
ID mesaj - Valoare pe 32 de biți utilizată pentru identificarea acestui mesaj. Folosit de către
expeditor LSR pentru a facilita identificarea mesajelor de notificare care se pot aplica la
acest mesaj. Un LSR care trimite un mesaj de notificare în răspunsul la acest mesaj
TREBUIE să includă acest ID de mesaj în TLV de stare transportat de mesajul de notificare.
Parametri obligatorii - Set de lungime variabilă a parametrilor necesari ai mesajului.
Parametrii opționali - Set de lungime variabilă a parametrilor opționali ai mesajului.
LDP utilizează o schemă de codificare Type-Length-Value (TLV)
pentru a codifica informațiile transportate în mesajele LDP.
U – Unknown, F – Forward - 2 biți care determină comportamentul

atunci când LSR nu recunoaște tipul.
Tip - Codifică modul în care trebuie interpretat câmpul Valoare (Ex.
0x0200 - Generic Label, 0x0103 - Hop Count )
Lungime - Specifică lungimea câmpului Valoare în octeți.
Valoare - Octeți care codifică informațiile interpretate așa cum este
specificat de câmpul Tip.
Schema de codificare TLV este foarte generală. În principiu, totul care
apare într-un PDU LDP ar putea fi codificat ca TLV.
LDP definește mesajele, TLV-urile și procedurile în următoarele domenii:
 Descoperire de la egal la egal
 Stabilirea/Managementul sesiunii
 Distribuirea etichetelor
 Notificarea erorilor și a informațiilor de consiliere
Sesiune LDP între LSR-uri pentru a face schimb de etichete.
LSR menține etichetele ”învățate” într-o bază de informații pentru

etichete- Label Information Base (LIB).
Mesajul Hello este transmis de LSR periodic ca pachet UDP
către portul de descoperire LDP 646 pentru „toate routerele de pe
această subrețea” (multicast). Când un LSR alege să stabilească o
sesiune cu un alt LSR descoperit prin mesajul Hello, acesta
folosește procedura de inițializare LDP pe transportul TCP. După
finalizarea cu succes a procedurii de inițializare, cele două LSR-
uri sunt parteneri LDP și pot face schimb de mesaje publicitare.
După schimbul de mesaje Hello LSR-urile declanșează
stabilirea sesiunii LDP.
Stabilirea sesiunii este un proces în doi pași:

- Stabilirea conexiunii de transport
- Inițializarea sesiunii.
După ce LSR1 și LSR2 stabilesc o conexiune de transport, ei
negociază parametrii sesiunii prin schimbul de mesaje de
inițializare LDP.
Negocierea cu succes finalizează stabilirea unei sesiuni LDP
între LSR1 și LSR2 pentru publicitatea spațiilor de etichete.
Modificarea valorii câmpului TTL al antetului IP și antetului MPLS
EVOLUȚIA MPLS
MPLS a evoluat substanțial de la primele sale zile de

implementare. Motivele pentru utilizarea MPLS într-o rețea s-au
schimbat, de asemenea. MPLS nu mai este utilizat doar pentru
a oferi o comandă rapidă de rutare IP.
Cele două mari schimbări ale tehnologiei MPLS sunt:
 MPLS-TE. Protocolul de rezervare resurse (RSVP) este

extins pentru a sprijini distribuirea etichetei MPLS - RSVP-TE,
tehnologia tunelului MPLS.
Aplicațiile MPLS L3VPN și MPLS L2VPN bazate pe

Pseudowire (PW) implementate în multe routere și comutatoare
MPLS ale mai multor furnizori. (RFC 4364)
Ingineria traficului MPLS (MPLS Traffic Engineering, MPLS TE)
Ingineria Traficului (TE) este preocupată de optimizarea performanței
rețelelor operaționale. În general, TE cuprinde aplicarea principiilor tehnologice
și științifice pentru măsurarea, modelarea, caracterizarea și controlul traficului,
precum și aplicarea unor astfel de cunoștințe și tehnici pentru repartizarea
uniformă a traficului în rețea. (RFC 2702)
În rețelele IP rutarea este guvernată pe principiul celui mai mic cost. Costul
respectiv este singura măsură care este atribuită la o legătură (de exemplu,
protocoalele de rutare OSPF și IS-IS au o metrică compusă, iar protocolul RIP
calculează doar numărul de hopuri). Ingineria traficului oferă posibilitatea de a
muta trafic de pe calea cea mai scurtă la o cale mai puțin încărcată a rețelei.
Rezervarea resurselor cu protocolul RSVP-TE
(procesul de creare a unui LSP)
RSVP-TE folosește două tipuri de mesaje pentru a configura LSP:
PATH și RESV. (RFC 3209)
Expeditorul (LER intrare) trimite mesaje PATH către receptor,

(LER ieșire) pentru a indica clasa de echivalență de expediere (FEC)
pentru care se dorește legarea/binding etichetelor. Deci mesajele PATH
sunt utilizate pentru a semnaliza și solicita legăturile de etichetă
necesare pentru a stabili LSP de la intrare la ieșire.
Mesajele PATH facilitează routerele de-a lungul traseului să facă
rezervările necesare pentru lățimea de bandă și pentru distribuirea
etichetelor la routere (în sus).
LER ieșire trimite informații de legare a etichetelor în mesajele
RESV, ca răspuns la mesajele PATH primite.
LSP este considerat operațional atunci când LER intrare
primește informațiile referitoare la etichetarea.
Un mesaj RSVP constă dintr-un antet comun, urmat de un
corp format dintr-un număr variabil de obiecte tip de lungime
variabilă.
Noile obiecte RSVP și funcția lor.
RSVP Object RSVP Descriere

Message
LABEL_REQUEST Path Cerere de etichetă către vecinul din aval
/downstream
LABEL Resv Eticheta MPLS alocată de vecinul din
aval//downstream
EXPLICIT_ROUTE Path Listă de hopuri care definește cursul TE
LSP
RECORD_ROUTE Path, Resv Lista hop / etichete înregistrată în timpul
configurării LSP
SESSION_ATTRIBUTE Path Atribute LSP solicitate (prioritate,
protecție, afinități)
Semnalizarea RSVP-TE are loc între LER itrare și LER ieșire
⊳ Crearea unui tunel LSP
Mesajul PATH: Mesajul RESERVATION:
•Session: ID unic pentru LSP •Label: se efectuează distribuirea
•Explicit Route: Specifică ruta de etichetelor upstream
la LER in. La LER ieș. •Style: specifică modul de rezervare
•Record Route: listarea LSR-urilor o Filtru fix: BW dedicat
traversate de LSP o Partajat explicit: BW partajat
•Record Route: Revenire cale LER ieș. (A)
(folosește cinci obiecte noi)
(Se evidențiază obiectele referitoare la MPLS-TE)

Rerutarea rapidă (Fast ReRoute, FRR), RFC 4090
În plus față de economiile de costuri și de evitare a congestiei, TE
ajută și la reluare la eșec/failover. Atunci când un tunel între două
puncte finale din rețea eșuează, TE conduce traficul prin legături
inactive, oferind astfel Rerutare rapidă (FRR) pe tunelurile TE.
REȚEA VIRTUALĂ PRIVATĂ (VPN) (RFC 4364)
Un VPN emulează o rețea privată a unei companii pe o infrastructură
comună a furnizorului de servicii. VPN poate furniza comunicații la nivelele
2 sau 3 OSI. Rețeaua privată necesită ca toate site-urile sale să fie
interconectate și să fie complet separate de alte VPN-uri. Însă când este
dorit se poate oferi conectivitate între diferite VPN si acces la Internet.
MPLS VPN oferă toate aceste servici.
Subsistem multimedia IP
(IMS - IP Multimedia Core Network
Subsystem )
IMS în rețelele convergente
Există două tipuri diferite de NGN:
 NGN bazat pe Softswitch
 NGN bazat pe IMS
Ambele au fost elaborate respectînd principiile NGN [ITU-
T Y.2018], cerințele către NGN [ITU-T Y.2201] și arhitecturi
funcționale NGN [ITU- T Y.2012].
Cu toate acestea abordările sunt diferite. Diferențele
esențiale între cele două tipuri sunt identificate după cum sunt
susținute serviciile PSTN/ISDN. "NGN pe baza IMS " este axat
mai mult pe aspectele de rețele mobile, în timp ce "NGN bazat
pe Softswitch", este axat pe aspectele de rețele fixe. În acelaș
timp, IMS-ul fiind inițial elaborat pentru rețelele mobile a fost
ulterior adaptat și la rețelele fixe.
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.
 IMS cuprinde toate elementele retelei nucleu(Core Network)
pentru furnizarea de servicii multimedia IP cuprinzând audio,
video, text, chat, etc. sau o combinație a acestora livrat peste
domeniul PS (comutare de pachete) [ETSI TS 123 002 V14.1.0 (2017-05;)].
 Concomitent cu furnizarea de servicii multimedia bazate pe
SIP terminalele NGN IMS de asemenea, sprijină furnizarea de
servicii de simulare PSTN / ISDN. IMS este pe deplin definit în
specificațiile tehnice (TS) 3GPP (Ex._3GPP TS 23.002 version 14.1.0 Rel. 14)
 Pentru prima dată conceptul IMS a fost publicat în
documentele 3GPP în martie 2002 in Rel.5.

R99 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14
2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016
HSPA
HSPA
HSPA
UMTS
LTE
LTE
Adv
UL
DL
EPC
Common
MMTel
IMS
IMS
NGN IMS susține următoarele:
Sesiuni IP multimedia
Asigurarea calității servicilor QoS
Interconectarea cu alte rețele cum ar fi rețelele CS fixe și
mobile, Internet
IP conectivitatea (IP CAN)- independența de tehnologia de
acces
Crearea și controlul serviciilor
Roaming
Securitatea comunicațiilor
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
între două sau mai multe noduri.
Identificarea utilizatorilor în IMS
Fiecare utilizator al subsistemului IM trebuie să aibă unul sau
mai multe Identități de utilizator private PrUI (3GPP TS 23.003).
Identitatea privată este atribuită de către operatorul de rețea de acasă și
utilizată în scopuri de înregistrare, autorizare, administrare și
contabilitate. Formatul PrUI:
"<IMSI>@ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org“
Dacă IMSI (International Mobile Subscriber Identity - Identitate internațională
de abonat mobil) este 259010999999999 (MCC = 259, MNC = 01), PrUI ia forma
259010999999999@ims.mnc001.mcc259.3gppnetwork.org
Concomitent fiecare utilizator al subsistemului IMS trebuie să
aibă unul sau mai multe identități de utilizator publice PuUI (3GPP TS
22.228), incluzând cel puțin una care ia forma unui URI SIP (IETF
RFC 3261). Identitatea de utilizator publică este utilizată de către orice
utilizator pentru a solicita comunicarea cu alți utilizatori. De exemplu,
acestă identitate ar putea fi inclusă pe o carte de vizită.
PuUI va utiliza fie schema SIP URI sau schema Tel URI.
De exemplu, bazate pe E.164 / TEL URI (tel:+37362345678) sau SIP
URI (SIP:my.name@company.org).
3GPP TS 23.003 V15.5.0 (2018-09)
Not more than 15 digits
3 digits 2 or 3
digits
MCC MNC MSIN
IMSI
IMSI este compus din trei părți: (Lista in T-SP-E.212B-2016)
1) Codul de țară mobil (MCC) format din trei cifre. MCC identifică în mod unic
țara de domiciliu a abonamentului mobil;
2) Codul rețelei mobile (MNC) format din două sau trei cifre pentru aplicațiile de
rețea 3GPP. MNC identifică PLMN-ul de origine al abonamentului mobil.
3) Numărul de identificare a abonaților mobili (MSIN) care identifică

abonamentul mobil în cadrul unui PLMN.
Country
MCC MNC ISO Country Network
Code
Eventis
259 04 md Moldova 373
Mobile
259 05 md Moldova 373 IDC/Unite

259 02 md Moldova 373 Moldcell
Orange/Vo
259 01 md Moldova 373
xtel
PuUI
Public :
PrUI User Identity 1
Private
User Identity 1
Service Profile 1
Public
User Identity 2
IMS
Subscription
Service Profile 2
Private Public
User Identity 2 User Identity 3
SIP URI _ RFC 3261 sau
TEL URL _ RFC 3966
Identificatorii privați și publici ai utilizatorului
(Public and private user identities).
Identitatea utilizatorului și relația cu profilul serviciului
Tel@operator.com
PuUI Profil
serviciu
IMS
subscriere PrUI PuUI Mobile@operator.com
Profil
PuUI serviciu
PC@operator.com
Tel@operator.com
PuUI
Profil
S-CSCF Profil PuUI
serviciu Mobile@operator.com
PuUI
PC@operator.com
Arhitectura rețelelor IMS
Trei planuri principale:
1. Accesul și de transport media
2. Control sesiune și semnalizare
3. Aplicații și servicii
Prezentare generală NGN IMS
Rf/Ro
Ut Charging
AS
Sh
Functions
Dh
ISC/Ma
UPSF Rf/Ro Iw
Cx Dx SLF IWF
Ib
Network
Attachment Mw Mx
Subsystem I/S-CSCF IBCF Ic
Mx
« Core IMS » Mi Mk
Mr
BGCF
e2
Mw
Other IP Networks
Mj Gq'
Mx Mg
P-CSCF MGCF SGF
MRFC Ie
PSTN/ISDN
Gq'
Gm Mp Mn
Resource and Admission Control Subsystem
MRFP T-MGF
UE I-BGF
IP Transfer (Access and Core)
Fig. 3 NGN IMS overview (3GPP TS 23.417 V7.0.0 ; ETSI TS 123 417 V7.0.0 (2007-12))_
Core IMS:
 I/S-CSCF Interrogating/Serving-Call Session Control Function
P-CSCF Proxy-Call Session Control Function
BGCF Breakout Gateway Control Function
MRFC Multimedia Resource Function Controller
MGCF Media Gateway Control Function
În afara core IMS:

•AS Application Server
•UPSF User Profile Server Function
•SLF Subscription Locator Function
•IWF Interworking Function
•IBCF Interconnection Border Control Function
•SGF Signalling Gateway Function
•MRFP Multimedia Resource Function Processor
•Tr-GW Transition Gateway
•I-BGF Interconnection-Border Gateway Function
Rețele definite prin software
(SDN - Software Defined networking)
SDN a fost dezvoltată în cadrul

grupului de lucru Open Networking
Foundation (ONF):
Open Networking Foundation (ONF)
“https://www.opennetworking.org/”
-organizație comercială nonprofit,
-fondată în 2011,
-finanțată de companii precum Deutsche
Telekom, Facebook, Google, Microsoft, Verizon și
Yahoo!
-ulterior numărul membrilor a crescut peste
150.
Scopul
-promovarea rețelelor definite prin software
(SDN),
-standardizarea protocolului OpenFlow și
-a tehnologiilor conexe.
Ion NAZAROI UTM 2
Figura de mai jos arată că peste 50% dintre experți consideră că până în
anul 2030 peste 50% din rețelele vor fi implementate cu SDN și NFV
(din raportul Comisiei Europene ” Implications of the emerging technologies Software-Defined
Networking and Network Function Virtualisation on the future Telecommunications Landscape”, 2016 )
Ion NAZAROI UTM 3

ONF evidențiază 4 limitări generale ale arhitecturilor de rețea
tradiționale :
Arhitectură statică și complexă:
volume mari și fluctuante de trafic multimedia cu diferite niveluri de QoS;
rețea tot mai complexă și mai dificil de gestionat;
număr mare de protocoale;
dificilă devine adăugarea nodurilor de rețea (personalul trb să gestioneze
fiecare echipament - modifica configurarea).
Politici inconsecvente:
pentru a pune în aplicare o politică de securitate la nivel de rețea,
personalul va trb să facă schimbări de configurație la mii de echipamente.
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ă echipamente
ale mai multor furnizori și este dificilă datorită naturii complexe și statice a
rețelei.
Dependența de furnizor:
operatorii de rețele și furnizorii de servicii trebuie să implementeze rapid
noi capabilități și servicii ca răspuns la cerințele utilizatorilor.
Ion NAZAROI UTM 4
Ion NAZAROI UTM 5
SDN elimina limitările infrastructurilor de rețea actuale.
Cerințe față de SDN:
 Adaptabilitate. Rețelele trebuie să se adapteze în mod dinamic
la necesitățile aplicațiilor, condițiilor rețelei.
 Automatizare. Schimbările în rețea trebuie efectuate automat,
astfel încât munca manuală și erorile să poată fi reduse.
 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 trebuie să permită
gestionarea rețelei la nivel de model, nu individual pentru fiecare
element al rețelei.
 Securitate integrată. Aplicațiile de rețea trebuie să integreze
securitatea ca serviciu de bază, nu ca soluție adăugată.
 Scalarea la cerere. Rețeua va permite ușor de extins sau redus
capacitățile și serviciile pentru a sprijini solicitările apărute.
Ion NAZAROI UTM 6
Evoluția tehnologilor de rețea
Rețele existente Retea bazata pe ProgrammableFlow
Control autonom și distribuit

Controlul trsm
Integrarea IT si a retelei
pachetelor
OSPF/
Control centralizat
BGP
ProgrammableFlow
Controller
Integration IT
Software
ソフトウェア
Controlul comutației
通信経路制御機能 Separarea OpenFlow
Hardware Trsm pachetelor
ハードウェア
Transmiterea pachetelor
パケット転送機能
ProgrammableFlow
Switch
Rețea ca black box
Ion NAZAROI UTM 7

Definiția SDN
O rețea definită prin software (SDN) este un set de tehnici care
permite programarea, orchestrarea, controlul și managamentul direct al
resurselor de rețea, care facilitează proiectarea, livrarea și operarea
serviciilor de rețea într-o manieră dinamică și scalabilă (Rec. ITU-T Y.3300)
Urmând definiția de mai sus, putem deduce

următoarele caracteristici importante ale unei rețele SDN:
1. Rețea programabilă
2. Managementul centralizat
3. Rețele configurabile dinamic
4. Protocoale și interfețe deschise
5. Rețea ușor monitorizată și tolerantă la defecțiuni

Ion NAZAROI UTM 8
Această abordare permite:
-controlul centralizat logic al rețelei, care reduce

numărul de puncte de control și de managament;
-sprijinirea virtualizării rețelelor ca o caracteristică

importantă a arhitecturii rețelei;
-controlul și managamentul resurselor de rețea

utilizând software;
- personalizarea rețelei, care este necesară pentru

implementarea eficientă a elementelor și operațiunilor.
Ion NAZAROI UTM 9

Arhitectura SDN decuplează funcțiile de control a rețelei de cele
de rutare. Controlul rețelei devine direct programabil, iar
infrastructura de bază abstractizată pentru aplicații și servicii.
Ion NAZAROI UTM 10

Arhitectură SDN funcțională
MMFO MMFA
Manage
Management relații externe
Orchestrare și Aplicații SDN
ment
Orchestrare și management multi-nivel

suport
nivel management SDN-AL
OSS aplicații AL
/BSS
MMFC ACI
Manage Orchestrare și Suport aplicații

ment suport
nivel management
SDN-CL
Servicii nivel
control CL control
Abstractizare
resurse
MMFR RCI
Manage Suport Suport control RL
ment management
MMF nivel SDN-RL
RL
resurse Procesare Transport
date date
(Rec.Y.3302. Functional architecture of software-defined

Ion NAZAROI UTM 2017)
networking. 11
Nivelul resurselor SDN (SDN-RL)
RCI
Nivelul
Suport Suport control RL resurse
management SDN
RL (SDN-RL)
Procesare Transport
date date
MMFR
Nivelul resurselor de rețea conține componentele funcționale:

Suport control RL - prezentarea modelelor de date ale resurselor de
rețea pentru abstractizare lor în SDN-CL.
Transport date - expedierea și rutarea datelor sub comanda nivelului de
control. Politica de rutare SDN-RL este configurată conform cerințelor
aplicațiilor SDN.
Procesare date – transcodarea și compresia traficului util al pachetelor
de date și ajustarea expedierii pachetelor de date conform cerințelor
aplicațiilor SDN.
Suport management - descrierea resurselor, nume furnizor, versiune
software și starea resurselor (de exemplu, încărcare CPU, memorie RAM sau
stocare utilizate). Ion NAZAROI UTM 12
Nivelul de control SDN (SDN-CL)
SDN relochează controlul resurselor de rețea către un

element de rețea dedicat, numit controlor SDN.
Controlorul asigură programarea, orchestrarea, controlul și
manajamentul resurselor de rețea prin software.
SDN-CL 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. Controlul resurselor este logic centralizat.
Adică controlorul se comportă ca o singură entitate,
independent de posibila implementare în formă distribuită.
Ion NAZAROI UTM 13

Componentele funcționale ale Controlorului
Ion NAZAROI UTM 14

Componentele funcționale ale SDN-CL:
Suport aplicații - oferă o viziune abstractizată a rețelei și este
utilizată de aplicații pentru a solicita controlorului să efectueze acțiunile
dorite.
Servicii, include: a) Serviciile de bază (sunt obligatorii) - funcții
comune utilizate în toate implementările SDN: monitorizarea topologiei,
nodurilor, linkurilor traseelor conform solicitării, precum și actualizarea
regulilor de expediere a datelor (programare flux).
b) Serviciile dependente de profil sunt legate de o anumită
implementare, de exemplu, gestionarea mobilității pentru rețelele
mobile.
Abstractizarea resurselor- oferă modele de date ale resurselor de
rețea astfel dezvoltatorii de servicii nu trebuie să cunoacă tehnologiile
din rețea. Ea asigură:
descoperirea resurselor (independene de tehnologie);
păstrarea topologiei curente a rețelei (fizice sau virtuale);
alocarea resurselor abstractizate pentru crearea rețelelor virtuale;
supravegherea performanței rețelei și defecțiunilor resurselor.UTM
Ion NAZAROI 15
Suport management și orchestrare a nivelului de
control – oferă managementul și orchestrarea
componentelor funcționale ale SDN-CL și a resurselor
de rețea pe baza politicilor MMF.
De asemenea, componenta funcțională CL-MSO:

obține informații de monitorizare pentru măsurarea
indicatorilor-cheie de performanță (KPI) ai serviciului și
a resurselor alocate lui;
ține evidența stării resurselor alocate și disponibile
pentru identificarea blocajelor (actuale sau potențiale);
permite conectări inter-domenii, transmiterea
identității și acreditărilor corespunzătoare cererii.
(un domeniu SDN este o colecție de entități SDN-RL
sub o entitate SDN-C). Ion NAZAROI UTM 16
Nivelul aplicațiilor SDN (SDN-AL)
MMFA
Orchestrare și Nivel
suport
management
Aplicați...e SDN ... Aplicați e SDN aplicații
SDN
AL (SDN-AL)
ACI
SDN-AL orchestrează aplicațiile SDN și include următoarele:

 gestionarea depozitului codurilor aplicațiilor SDN;
 crearea, modificarea și ștergerea aplicațiilor SDN;
monitorizarea performanței aplicațiilor SDN;
 detectarea, izolarea și corectarea defecțiunilor aplicațiilor SDN;
securizarea aplicațiilor SDN furnizate de operatorii de rețea;
interacționarea cu nivelul de control (vizualizarea rețelei furnizate
de SDN-CL prin intermediul modelelor de date prin punctul de
referință ACI). Ion NAZAROI UTM 17
Funcțiile de management multi-nivel (MMF)
Funcțiile MMF gestionează nivelurile SDN și asigură:
1)interacțiunea cu sistemele de management ale terților, pentru
facturare, suport clienți, colectare de statistici etc;
2)orchestrarea serviciilor MMF și reconfigurarea coordonată
(orchestrată) a resurselor SDN-RL;
3)inventarierea echipamentelor, izolarea defectelor, optimizarea
performanțelor, configurarea inițială a nivelurilor SDN-RL, SDN-
CL și SDN-AL și securizarea comunicațiilor (funcțiile FCAPS);
4)managementul ciclului de viață al componentelor software ale
nivelurilor SDN;
5)eficientizarea consumului 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.
Ion NAZAROI UTM 18
Protocolul OpenFlow
OpenFlow, the Controller – Switch
Interface (Southbound Interface)
Elaborat în cadrul ONF. Publicat într-un șir de specificații

OpenFlow Switch Specification
https://www.opennetworking.org/software-defined-
standards/specifications/
Începe OpenFlow Switch Specication Version 1.0.0 din 12.2009
(TS 001)
....
OpenFlow Switch Specification Version 1.5.1 din martie 2015 (TS
NAZAROI
025) UTM FET
1
Pentru interacțiunea dintre Controlor și OF Switch se folosește
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.
Pe acestă bază
State-transmite
Conf -configurează
informații despre
elementele OF Switch
schimbările
și controlează fluxurile
apărute în rețea.
de pachete în rețea.
NAZAROI
UTM 2
Protocolul OpenFlow, Open Daylight, OpenStack
OpenStack este o platformă
software open-source de cloud
computing, implementată ca
infrastructură ca serviciu (IaaS)
Controlerul OpenDaylight
este software JVM și poate fi
rulat de pe orice sistem de
operare și hardware, care
acceptă Java.
Ion NAZAROI UTM 3
Structura generală a unui switch SDN constă din trei
componente-cheie:
interfața cu controlorul,
nivelul de abstractizare,
sistem de procesare a pachetelor.
Spre controlor
Protocolul OpenFlow
Interfață controlor
Tabela de fluxuri
Nivel abstractizare
Sistem de procesare pachete
NAZAROI
UTM 4
Interfața controlor menține un canal securizat de
comunicare OpenFlow între comutator și controlor.
Controlorul instalează în comutator regulile de potrivire a
pachetelor.
Nivelul de abstractizare oferă o vedere abstractă a

sistemului de procesare a pachetelor. Menține una sau mai
multe tabele de fluxuri pentru a stoca regulile de potrivire a
pachetelor. Tabela de fluxuri conține o listă cu înregistrări
de flux (intrări), care specifică regula după care se
identifică pachetul potrivit și acțiunile care ar trebui
efectuate la toate pachetele din flux care sau potrivit.
Sistemul de procesare a pachetelor 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
NAZAROI
matrice de comutare pentru interconectarea
UTM lor. 5
Controlor Controlor
OpenFlow PDUs:
OpenFlow/TLS/TCP/IP OpenFlow Switch
Datapath
Canal Canal
OpenFlow OpenFlow Tabelă Tabelă
de grup de grup
Fluxuri pachete Canal de Control Fluxuri pachete
date: date: */IP
TCP/IP sau UDP/IP
Port
Port Tabelă Tabelă Tabelă
fluxuri fluxuri fluxuri
Port
... Port
Pipeline/Conductă
Componentele principale ale OpenFlow Switch

NAZAROI
UTM 6
Specificația OpenFlow definește trei tipuri de
tabele în arhitectura comutatoarelor logice:
Tabela de fluxuri – compară 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);
Tabela de grup către care tabela de fluxuri poate

direcționa fluxul de pachete, pentru a declanșa o
varietate de acțiuni;
Tabela de măsură poate declanșa acțiuni legate

de performanța pe flux. NAZAROI
UTM 7
Tabela de fluxuri (flow table)
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
Blocul de bază al arhitecturii comutatorului logic OpenFlow este

tabela de fluxuri.
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 figura de sus - a). NAZAROI
UTM 8
Câmpuri de comparare (Match fields ). Se utilizează ca criteriu
pentru a determina dacă un pachet primit se potrivește cu această
înregistrare.
Constă din următoarele câmpuri obligatorii:
Port de intrare. Identificatorul portului (fizic sau virtual) switch-
ului pe care a sosit pachetul.
Port de ieșire. Identificatorul portului de ieșire din setul de
acțiuni.
Adresele sursă și destinație Ethernet. 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.
Adrese IPv4 sau IPv6 sursă și de destinație. O adresă
exactă, valoare bitmascată, a unei măști de subrețea sau ”wildcard”.
Porturile TCP sursă și destinație. Valoarea exactă sau
"wildcard".
Porturile UDP sursă și destinație. Valoarea
NAZAROI
exactă sau
"wildcard“. UTM 9
Tabelula de grup
• Tabela 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.
Fiecare tabelă de grup constă dintr-un număr de rânduri,
numite înregistrări de grup, compuse din patru componente:
Group Group Counters Action

Identifier Type Buckets
Identificator de grup. Număr întreg de 32 biți care identifică în
mod unic grupul de pe comutatorul OpenFlow.
Tip de grup. Determină semantica grupului.
Contoare. Se actualizează când pachetele sunt procesate de
grup.
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
NAZAROI
trebuie executate și parametrii asociați. UTM 10
Tabela de măsurare
Tabela 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, care limitează un set de fluxuri la o lățime de bandă aleasă
sau operațiuni de politici QoS mai complexe.
Meter Meter Bands Counters

Identifier
Fiecare înregistrare 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ă. NAZAROI
UTM 11
Procesarea pachetelor în conductă (pipeline)
Procesarea în conductă se desfășoară în două etape, de
intrare și de ieșire:
Pachet in
Procesare de intrare
Port Tabelă Tabelă Tabelă Executare Tabelă

intrare fluxuri fluxuri fluxuri
... set de
0 1 n
acțiuni grup
Procesare de ieșire
Tabelă Tabelă . ... Tabelă Executare Port

fluxuri fluxuri fluxuri set ieșire
e e+1 e+m acțiuni
NAZAROI
Pachet out PPPP
UTM P Packet out 12
Prelucrarea pachetelor într-un comutator OpenFlow: pachetul primit se
potrivește cu tabela de flux și se transmite spre controlor dacă nu se potriveste.
Controlorul decide ce să facă cu pachetul și îl trimite înapoi la comutator.
Comutatorul execută apoi acțiunea pe care controlorul a definit-o. Dacă
pachetul se potrivește cu o intrare în tabela de flux, acțiunea este executată
direct.
NAZAROI
UTM 13
Potrivirea și executarea instrucţiunilor în tabela de fluxuri
Găsiți înregistrarea Înregistrare flux TABELA de FLUXURI
flux cu cea mai înaltă
prioritate la potrivire Înregistrare flux
Aplică instrucțiunile
Potrivire
Înregistrare flux
•
•
•
Înregistrare flux
Înregistrare flux
lipsă-tabel Clear-Action: Goto- Tabela
Set de • set de acțiune gol Table de
acțiuni Write-Action: {table fluxuri
{set de acțiuni} -id}
• îmbinare în set de
acțiuni
Câmpuri
conductă Aplicare-acțiuni
{listă de acțiuni}:
- modifică pachetul, Executare
-actualizează câmpurile de set de
potrivire, acțiuni
Extrage
Pache t câmpurile -actualizează câmpurile
antetului c conductei,
• -dacă spre ieșire sau grup
→ clone de pachet.
Pachete de clone
Ieșire
NAZAROI
UTM 14
Intrare pachet
- set gol de acțiuni
- inițiere câmpuri pipeline
- start cu tabela de fluxuri 0
Actualizare contoare.
Executare set Da Executare set acțiuni:
instrucțiuni: -actualizarea
-actualizarea setului de anteturilor pachetului
Este acțiuni Goto -actualizarea
potrivire Da -actualizarea anteturilor tabela Nu câmpurilor potrivire
în tabela pachetului n? -actualizarea
n? -actualizarea câmpurilor câmpurilor pipeline
potrivire (conductă)
- actualizare câmpurilor
pipeline
Nu - dacă e necesar,
clonarea pachetului Acțiune Da
la ieșire grup?
Este
Da Nu
înregistrare
„table-
miss” ?
Nu Acțiune
Aruncare
ieșire?
pachet
Nu
Aruncare
pachet Da
Procesare intrare
Procesare ieșire
Start procesare ieșire

-stabilire set acțiuni Sunt
Da tabele
Nu
-trecere la prima tabelă ieșire
Ieșire?
Actualizare contoare.
Executare set Da
instrucțiuni: Executare set acțiuni:
-actualizarea setului de -actualizarea anteturilor
Este
Da acțiuni Goto Nu pachetului
potrivire
-actualizarea anteturilor tabela -actualizarea câmpurilor
în tabela
pachetului n? potrivire
n?
-actualizarea -actualizarea câmpurilor
câmpurilor potrivire pipeline (conductă)
Nu - actualizare câmpurilor
pipeline
- dacă e necesar,
clonarea pachetului Aruncare Acțiune
Este Nu
la ieșire pachet ieșire?
înregistrare
„table- Da
miss” ?
Da
Nu Packet out
NAZAROI
Aruncare pachet UTM 15
Mesaje OpenFlow
Protocolul OpenFlow acceptă trei tipuri de mesaje:
 Controler-to-switch. Utilizate pentru a gestiona direct sau a inspecta
starea comutatorului: Configuration, Modify-State, Read-States, Packet Out.
 Asincron. Inițiate de OFSwitch și utilizate pentru a informa controlorul
despre evenimentele din rețea și schimbările de stare ale comutatorului.
Packet-in, Flow-Removed, Port-status.
 Simetric. Inițiate de comutator sau controlor și sunt trimise fără
solicitare. Hello, Echo, Error.
Fiecare tip de mesaj începe cu un antet OpenFlow comun:

/* 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);
NAZAROI
UTM 16
END
NAZAROI
UTM 17
Virtualizarea funcțiilor de rețea
(NFV)
NFV este procesul de decuplare a funcțiilor de rețea

de la hardware și rularea acestora pe o platformă software.
ETSI NFV ISG (Industry Specification Group): „A încurajat
industria și mediul academic să participe la ecosistemul NFV prin
crearea de programatori de cercetare în jurul NFV și să creeze noi
cursuri didactice pentru a forma o nouă generație de studenți care să
fie multi-calificați în rețele și software.”
 Ideea principală din spatele NFV este de a decupla
funcționalitatea rețelei de hardware. În modelul de rețea
tradițional, fiecare funcție de rețea necesită un
echipament suplimentar, o componentă „fieră”, în timp ce
în modelul NFV, o bază fizică este suficientă, iar extinderea
funcțiilor de rețea se realizează în cloud.
 În 2012, la Congresul Mondial “SDN and OpenFlow
World Congress”, un număr de principali operatori de
telecomunicații din lume, inclusiv AT&T, Verizon, Deutsche
Telekom, Orange, NTT Group, au desemnat NFV drept
concept integral pentru rețelele 5G.
 Cerințele și standardele deschise care stau la baza NFV
sunt elaborate de grupul ISG (Industry Specification Group)
al ETSI (European Telecommunications Standards
Institute).
Prezentare generală a Releases-urilor ETSI NFV
Release 1 Release 2 Release 3
• Focus: fezabilitatea • Focus: • Focus:
NFV. interoperabilitatea Perfecționarea
• Furnizarea studiilor soluțiilor NFV. cadrului arhitectural
și specificațiilor de • Specificații ale NFV, pregătirea NFV
bază. interfețelor și pentru implementare
• Definirea descriptorilor. și operare.
arhitecturii NFV: • Realizarea
•Interfețe, modelare
Infrastructură interoperabilității
(NFVI), soluțiilor bazate pe etc. pentru a sprijini
Funcții de rețea arhitectura NFV: funcții noi:
virtualizate (VNF), Pachete VNF și Cadru de politici,
Integrarea VNF în descriptorii VNF și VNF instantaneu,
serviciile de rețea NS, Managementul
(NS) Interfețe interne și NFV-MANO,
Gestionarea și externe NFV-MANO. Licențierea,
orchestrarea NFV Site-uri multiple,
(NFV-MANO). Cloud-nativ etc.
Release 4
• Focus: orchestrarea, cloudificarea și simplificarea

implementării și operațiunilor rețelei.
• Interfețe, modelare etc. pentru a sprijini funcții noi, cum ar
fi (nu lista exhaustivă):
• Implementări bazate pe containere,
• Suport suplimentar 5G,
• Concepte de arhitectură bazate pe servicii,
• Funcții OAM generice etc.
NFV ISG a devenit gazda dezvoltării tehnologiei NFV și

coordonează lucrările de standardizare și implementare a NFV
cu alte organizații de standardizare și comunități open source.
https://youtu.be/Q1Kzu2vyuqs
Obiectivele NFV sunt:
 Reducerea CAPEX în comparație cu implementările

hardware dedicate. Funcțiile de rețea (NF) se realizează de
hardware-ul commercial-off-the-shelf (COTS) (servere și
dispozitive de stocare de uz general) prin tehnici de virtualizare
software. Partajarea și reducerea numărului de hardware.
 Creșterea flexibilității prin localizarea software-ului în cele
mai potrivite locuri, de ex. la sediul clienților, birouri, noduri de
rețea, centre de date etc.
 Inovarea rapidă a serviciilor implementate pe software.
 Reducerea OPEX rezultată din automatizarea și
procedurile de operare comune.
 Reducerea consumului de energie realizat prin migrarea
sarcinilor de lucru și oprirea hardware-ului neutilizat.
 Utilizarea interfețelor standardizate între funcțiile de rețea
virtualizate, infrastructură și entitățile de management asociate.
Astfel de elemente decuplate pot fi furnizate de diferiți producători.
Primii prestatori de servicii de comunicații (CSP) încep să
demonstreze eficiența pentru NFV/SDN (AT&T, China Telecomm, NTT)
Diagrama de mai sus este confirmată și de un studiu

realizat în laboratorul Nokia/Alcatel-Lucent Bell Labs, care a
evidențiat economii operaționale de la 25% până la 40% datorită
simplificării proceselor prin utilizarea NFV. Studiul a evidențiat
economiile de 39 de miliarde de euro dacă operatorii europeni ar
trece la noul model de operare NFV/SDN/MANO.
CSPs Leading NFV/SDN Deployments
COMPANIA LOCAȚIA COMPANIA LOCAȚIA
AT&T North America Orange EMEA
British Telecom EMEA SK Telecom Asia Pacific
China Telecom Asia Pacific Telefonica Europe and

Americas
Deutsche EMEA Telstra Asia Pacific

Telecom
Korea Telecom Asia Pacific Verizon North America
NTT DoCoMo Asia Pacific Vodafone EMEA
Bridging the IT/Network Operations Gap to Accelerate NFV Deployment and Achieve
Operational Excellence© 2018 Dell Inc. or its subsidiaries.
Principiul de bază al NFV (Network Functions Virtualisation):
Separarea funcțiilor de rețea (NF-network functions)
de hardware-ul pe care ele rulează utilizând abstractizărea
hardware-lui virtualizat (ETSI GS NFV 003 V1.5.1 (2020-01)).
Funcția de rețea (NF) este:
Bloc funcțional - element într-o infrastructură de
rețea care are interfețe externe și comportament funcțional
bine definite (de exemplu, nod de rețea).
NFV propune utilizarea tehnologiilor de virtualizare IT
pentru a înlocui echipamentele de rețea cu servere, switch-
uri și unități de stocare toate standarde de mare volum.
Acestea pot fi instalate în centre de date, noduri de rețea și
la sediul utilizatorilor.
Funcțiile de rețea se implementează prin software-ul
serverilor standarde fără a fi necesară instalarea de
echipamente specifice pentru fiecare funcție.
NFV- transferă funcțiile de rețea într-un spațiu virtual
bazat pe servere standard:
Virtualizarea funcțiilor de rețea oferă multe
avantaje, printer care:
• Reduceri la costuri de echipamente și consum de
energie prin adoptarea mai largă a serverelor standarde și
partajarea infrastucturii de calcul.
• Accelerarea introducerii pe piață a inovaților.
• Utilizarea unei singure platforme pentru diferite

aplicații și partajarea resurselor între servicii și baze de
clienți.
• Rețeaua și serviciile pot fi scalate rapid după

necesitate.
Domenii de aplicare și exemple de utilizare NFV
NFV este aplicabil oricărei funcții de procesare a pachetelor de date în
rețelele mobile și fixe. Exemple de funcții care pot fi virtualizate:
•Elemente de comutare : routers, BRAS, CG-NAT.
• Noduri de rețea mobilă: HLR/HSS, SGSN, GGSN/PDN-GW, RNC, Nod B.
• Funcții conținute în routerele și set top box-urile rezidențiale.
• Elemente de gateway de tunelare: gateway-uri VPN IPSec / SSL.
• Analiza traficului: măsurare DPI, QoE.
• Asigurarea serviciului, monitorizarea SLA, testarea și diagnosticarea.
• Platforme și elemente NGN: IMS, SBC-uri.
• Funcții convergente și pe larg utilizate în rețele: servere AAA, control de
politici și platforme de facturare.
• Optimizare la nivel de aplicație: CDN-uri, servere cache, echilibratoare de
trafic, acceleratoare de aplicații.
• Funcții de securitate: firewall-uri, scanere de viruși, sisteme de detectare a
intruziunilor, protecție împotriva spamului.
În plus, odată cu apariția tehnologiei 5G, există un impuls către dezvoltarea
de noi servicii în timp real în domeniile plăților mobile, realității augmentate,
conducerii autonome și Internetului obiectelor (IoT)
Structura NFV la nivel înalt (ETSI GS NFV 002 V1.2.1)
Funcții de rețea virtualizate (VNFs)
VNF VNF VNF VNF
Infrastructura NFV (NFVI) NFV

management
Calcul Stocare Rețea și
virtual virtuală virtuală orchestrare
(MANO)
Nivel de virtualizare
Calcul Stocare Rețea
Resurse Hardware
NFV asigură implementarea funcțiilor de reșea NF ca
entități software care rulează peste infrastructura NFV (NFVI).
În NFV se identifică trei domenii principale de lucru :

• Virtualised Network Function (VNF), Funcția de rețea
virtualizată, ca implementare software a unei funcții de rețea
care rulează pe NFVI.
• NFV Infrastructure (NFVI), Infrastructura NFV (NFVI), care

include diversitatea resurselor fizice și modul în care acestea pot
fi virtualizate.
• NFV Management and Orchestration (MANO), Managementul

și orchestrarea NFV , care acoperă orchestrarea și gestionarea
ciclului de viață al resurselor fizice și software care sprijină
virtualizarea infrastructurii și gestionarea ciclului de viață al
VNF-urilor.
Modelul funcțional NFV detaliat (ETSI GS NFV 002)
Os-Ma
OSS/BSS Orchestrator
Descrierea infrastructurii, Se-Ma

Or-Vnfm
VNF și a serviciului
Or-
VNF
EM 1 EM 2 EM 3 Ve-Vnfm
Manager(i)
Ve-Vnfm
VNF 1 VNF 2 VNF 3
Vn-Nf
Vi-Vnfm
NFVI
Or-Vi
virtual virtuală virtuală
Manager(i)
Nf-Vi Infrastructură
virtualizată
Nivel de virtualizare
VI-Ha VI-Ha
Resurse hardware
Managemant și
Resursă Resurs Resursă
Orchestrare NFV
calcul stocare rețea
(MANO)
Puncte de referință:
de executare , principale NFV , alte
Structura arhitecturală se concentrează pe noile
blocuri funcționale și puncte de referință aduse de
virtualizarea rețelei.
Trebuie remarcat faptul că punctele de referință

nu sunt interfețe (software sau hardware). Aceste
puncte reprezintă specificații ale informațiilor care ar
trebui transmise prin ele, precum și unde și cum ar
trebui procesate.
Arhitectura NFV include următoarele
blocuri funcționale:
Funcția de rețea virtualizată (VNF).
Element Management (EM).
Infrastructura NFV, care include:
 resursele hardware și virtualizate și
 nivelul de virtualizare.
Manager(i) infrastructurii virtualizate.
Manager(i) VNF.
Orchestrator NFV.
Descrierea serviciului, VNF și a infrastructurii.
Sisteme de suport operațiuni și afaceri
(OSS/BSS).
Funcția de rețea virtualizată (VNF)
 VNF este o virtualizare a unei funcții de rețea într-o

rețea tradițională non-virtualizată.
 Exemple de NF-uri sunt elemente de rețea, ca
Serving Gateway (SGW), Packet Data Network Gateway
(PGW), Residential Gateway (RGW), servere Dynamic
Host Configuration Protocol (DHCP), firewall-uri etc.
 Comportamentul funcțional și starea unui NF sunt
indiferente dacă NF este virtualizat sau nu.
 VNF poate fi implementat pe mai multe VM-uri,
unde fiecare VM găzduiește o singură componentă a
VNF. În alte cazuri, VNF integral poate fi implementat și
într-o singură VM.
Element Management (EM)
EM efectuează managementul tipic pentru
unul sau mai multe VNF-uri (funcționalitatea de
gestionare FCAPS pentru VNF).
Aceasta include managamentul funcțiilor de
rețea furnizate de VNF după cum urmază:
• Gestionarea defecțiunilor
• Configurarea.
• Facturarea utilizării.
• Colectarea rezultatelor măsurării performanței.
• Managementul securității.
Infrastructura NFV (NFVI) este totalitatea tuturor
componentelor hardware și software care creează mediul în
care sunt desfășurate, gestionate și executate VNF-urile.
 Infrastructura NFV poate fi amplasată în mai multe locații
(NFVI-PoP). Rețeaua care interconectează aceste locații face
parte din NFVI. Pentru VNF, nivelul de virtualizare și resursele
hardware arată ca o singură entitate.
 Hardware-ul include resulsele de calcul, stocare și rețeaua
care asigură respectiv procesarea, stocarea și conectivitatea la
VNF-uri prin nivelul de virtualizare (hipervizorul). Resursele de
calcul și stocare sunt colocate. Rețeaua este compusă din
routere, switch-uri și linkuri prin cablu sau wireless.
 NFV diferențiază două tipuri de rețele:
• Rețea NFVI-PoP care interconectează resursele de calcul
și stocare conținute într-un NFVI-PoP dar include și echipamente
de comutare și rutare pentru conectivitate externă.
• Rețea de transport care interconectează NFVI-PoP –urile
și NFVI-PoP la alte terminale care nu sunt conținute în NFVI-PoP.
Nivelul de virtualizare și resursele virtualizate
abstractizează resursele hardware și decuplează software-ul
VNF de hardware.
Nivelul de virtualizare este responsabil pentru:
 Abstractizarea și înpărțirea logică a resurselor fizice.
 Asigurarea software-ului VNF utilizarea infrastructurii
virtualizată subiacentă.( )
 Furnizarea de resurse virtualizate către VNF. ( )
De obicei, nivelul de virtualizare este realizat sub formă
de hipervizoare și VM-uri. Utilizarea hipervizorilor este una
dintre soluțiile tipice actuale pentru implementarea VNF-urilor.
Alte soluții pentru realizarea VNF-urilor pot include software-ul
care rulează pe un server non-virtualizat prin intermediul unui
sistem de operare (OS).
Hardware-ul de rețea este abstractizat și realizează căi
virtualizate de conectivitate între VM-urile unui VNF sau între
diferite VNF. Mai multe tehnici permit acest lucru, de exemplu
Rețea locală virtuală (VLAN).
Principiul virtualizării în NFVI
Hipervizor [Y.3510]: Software de sistem care permite mai multor

sisteme de operare să partajeze o singură gazdă hardware.
Managerul(ii) infrastructurii virtualizate (VIM)
efectuează controlul și gestionarea interacțiunii dintre VNF și resursele
de calcul, stocare și rețea aflate sub autoritatea sa, precum și
virtualizarea acestora.
Aceasta include:
 Managementul resurselor, responsabile de:
 Inventarierea de software (de exemplu, hipervizoare), resurse de
calcul, stocare și rețea dedicate infrastructurii NFV.
 Alocarea mijloacelor de virtualizare, de ex. VM-uri pe hipervizoare,
resurse de calcul, stocare și conectivitate de rețea relevantă.
Gestionarea și alocarea resurselor infrastructurii, de ex. majorarea
resurselor alocate VM-urilor, creșterea eficienții energetice și
recuperarea resurselor.
 Operațiuni, pentru:
 Vizibilitatea și gestionarea infrastructurii NFV.
 Analiza cauzelor fundamentale a problemelor de performanță din
perspectiva infrastructurii NFV.
 Colectarea informațiilor privind defectele de infrastructură.
 Colectarea de informațiilor pentru planificarea capacității,
monitorizare și optimizare.
Managerul (i) VNF (Virtual Network Function Manager VNFM)
Un manager VNF este responsabil pentru gestionarea ciclului
de viață VNF (de exemplu, instanțierea, actualizarea,
interogarea, scalarea, terminarea). Pot fi implementați mai mulți
manageri VNF. Un Manager VNF poate fi implementat pentru
fiecare VNF sau un Manager VNF poate deservi mai multe VNF.
Orchestratorul NFV (Network Functions Virtualisation

Orchestrator NFVO)
este responsabil de orchestrarea și gestionarea infrastructurii și
resurselor software NFV și de realizarea serviciilor de rețea pe
NFVI.
Orchestratorul NFV are două responsabilități principale:
• orchestrarea resurselor NFVI pe mai multe VIM-uri (Virtualised
Infrastructure Manager), îndeplinind funcțiile de orchestrare a
resurselor;
• gestionarea ciclului de viață al serviciilor de rețea, îndeplinind
funcțiile de orchestrare a serviciilor de rețea.
Descrierea infrastructurii, VNF și a serviciului
Set de date care oferă informații cu privire la șablonul de
implementare VNF, graful de redirecționare VNF, informații legate
de servicii și modele de informații privind infrastructura NFV.
Aceste șabloane/descriptori sunt utilizate intern în cadrul
managementului și orchestrării NFV. Blocurile funcționale NFV
Management and Orchestration (MANO) gestionează informațiile
conținute în șabloane/descriptori și pot expune (subseturi de)
astfel de informații blocurilor funcționale aplicabile, după
necesitate.
Tehnologia NFV este o parte cheie a cloud computing,

rețelei 5G, rețelelor centrelor de date (data center networking),
SD-WAN și multor altor.
Relația NFV cu SDN
NFV și SDN sunt complementare:
NFV poate furniza infrastructura pe care rulează software-

ul SDN. Mai mult, NFV este complet aliniat cu obiectivele SDN în
utilizarea serverelor și switch-urilor standarde.
Tehnologiile SDN și NFV gestionează rețelele, dar se
bazează pe metode diferite:
 SDN separă planurile de control și cel al resurselor pentru a

oferi o vedere centralizată a rețelei.
 NFV separă funcțiile de rețea de hardware-ul pe care ele

rulează. Utilizeză abstractizărea hardware-lui virtualizat și se
concentrează în principal pe optimizarea serviciilor de rețea.
SDN este un concept important și o tehnologie derivată care

îmbunătățește considerabil controlul și gestionarea rețelei de
infrastructură NFV.
Blocurile funcționale ale unei arhitecturi SDN pot fi

implementate sub formă de funcții de rețea virtualizate găzduite
într-o infrastructură NFV.

SDN în cadrul arhitectural NFV (ETSI GS NFV-EVE 005 V1.1.1)
Os-Ma
OSS/BSS Orchestrator
Descrierea infrastructurii, Se-Ma

Cazul a: VNF și a serviciului
Or-Vnfm
Or-
comutator fizic sau
router EM 1 EM 2 EM 3 Ve-Vnfm VNF
Manager(i)
 Cazul b: switch
Ve-Vnfm
virtual sau router VNF 1 VNF 2 VNF 3 d

 Cazul c: e-switch, Vn-Nf
Vi-Vnfm
NFVI
switch bazat pe SDN Or-Vi
software activat virtual virtuală virtuală b
Manager(i)
într-un server NIC Nf-Vi Infrastructură
virtualizată
 Cazul d: Nivel de virtualizare

VI-Ha VI-Ha
comutator sau Resurse hardware
router ca VNF Managemant și
Resursă Resurs Resursă
calcul stocare rețea a Orchestrare NFV
c (MANO)
Resursă SDN
Poziția controlerului SDN într-un cadru arhitectural NFV
Os-Ma
Cazul 1: OSS/BSS 4
Orchestrator
controlerul SDN este Descrierea infrastructurii, Se-Ma

Or-Vnfm
fuzionat cu VNF și a serviciului
Or-
funcționalitatea VIM
 Cazul 2: EM 1 EM 2 EM 3 Ve-Vnfm VNF
Manager(i)
Ve-Vnfm
controlerul SDN este
virtualizat ca VNF. VNF 1 VNF 2 VNF 3 2
 Cazul 3: Vn-Nf
Vi-Vnfm
NFVI 3
controlerul SDN face Or-Vi
parte din NFVI și nu virtual virtuală virtuală
Manager(i)
este un VNF. Nf-Vi Infrastructură
virtualizată
 Cazul 4: Nivel de virtualizare 1

VI-Ha
controlerul SDN face VI-Ha
Resurse hardware
parte din OSS / BSS. Managemant și
Resursă Resursă
 Cazul 5: calcul
Resurs
stocare rețea
Orchestrare NFV
(MANO)
controlerul SDN este PNF
un PNF. 5
Cloud Computing
Termenul ”cloud” în cloud computing se referă la mijloacele
prin care resursele de calcul și stocare, aplicațiile pot fi livrate
utilizatorilor ca serviciu oriunde și oricând. Cloud computing este
practica utilizării unei rețele de servere la distanță găzduite pe Internet
pentru a stoca, gestiona și prelucra date. Datele și aplicațiile deservite
de cloud sunt accesibile unui grup de utilizatori din întreaga rețea, dar
infrastructura și tehnologia cloud nu sunt vizibile pentru utilizatorii
finali. Factorul cheie al cloud computing-ului este virtualizarea. Ea
oferă capacitatea de a partaja clusterele de server ca un grup de
resurse de calcul.
Conform Y.3500 - cloud computing este un model (paradigmă)

care permite accesul din rețea la un grup scalabil și elastic de resurse
fizice sau virtuale care pot fi partajate, cu autoservire și administrare
la cerere.
Infrastructura cloud este formată din servere, dispozitive
de stocare, rețele, software de virtualizare, software de
management cloud și software implementare.
Principiul cloud computingului este de a oferi funcții de

calcul, stocare și software „ca serviciu”.
Serviciile cloud includ software-ul, infrastructura și spațiul de
stocare livrate prin Internet la cerința utilizatorilor finali.
Există trei modele majore de servicii de cloud computing
Model Explicații Exemple
IaaS Clientul primește resurse precum Amazon Web
puterea de procesare, stocarea, lățimea Services (AWS),
de bandă a rețelei, CPU și alimentarea. RackSpace,
Odată ce utilizatorul primește GoGrid,
infrastructura, controlează sistemul de Verizon, IBM,
operare, datele, aplicațiile, serviciile, AT&T.
securitatea bazată pe gazdă și așa mai
departe.
PaaS Clientului i se oferă hardware-ul, rețeaua MS Azure, Google
și sistemul de operare pentru a forma un App Engine,
mediu de găzduire. Utilizatorul își poate Keynote Systems,
instala aplicațiile și activa servicii din Caspio, Tibco,
mediul de hosting. WaveMaker.
SaaS Utilizatorului i se oferă acces la o Salesforce.com,
aplicație. Nu are control asupra Google, MS,
hardware-ului, rețelei, securității sau Ramco, Zoho.
sistemului de operare.
Infrastructura ca serviciu (IaaS) oferă resurse de calcul pentru a auto-
gestiona resursele de procesarea, stocarea și alte resurse.
Platformă ca serviciu (PaaS) model în care consumatorului i se oferă
posibilitatea de a utiliza infrastructura cloud pentru a găzdui software-ul
de bază cu implementarea ulterioară pe acesta a aplicațiilor noi sau
existente (aplicații proprii, personalizate sau replicate achiziționate).
Software ca serviciu (SaaS) model în care consumatorul are posibilitatea
de a utiliza software-ul aplicației furnizorului accesibil de pe diferite dispozitive
client, de exemplu, dintr-un browser sau interfață de program.
Software as a service (SaaS)
Platform as a service (PaaS)
Infrastructure as a service (IaaS) (VM)
Hardware as a service (HaaS)
(CPU, memory, disk, network)
Hardware ca Serviciu (HaaS) înseamnă cumpărarea de porțiuni

hardware de la centrele de date ca serviciu de abonament pay-as-you-go.
Modele de implementare în cloud
Cloud computing se împarte în trei clase: public, privat și hibrid.
Tipul de Beneficii Dezavantaje
cloud
Public • Investiție redusă (plătiți • Securitate: închiriere
pe măsură ce utilizați) multiplă și transferuri pe
• Foarte scalabil internet
• Serviciu mai rapid pe • Confidențialitate și
piață fiabilitate
Privat • Mai mult control și • Cost mai mare: investiții
fiabilitate mari în hardware,
• Securitate mai mare administrare și întreținere
• Performanță mai mare
Hibrid • Flexibilitate operațională: • Securitate,
atât publică, cât și privată confidențialitate și
• Scalabilitate: rulați preocupări de integritate
periodic sarcini de lucru pe
cloudul public
• Rentabil
Guvernul Republicii Moldova a lansat în februarie 2013 sistemul de
cloud privat (MCloud). Acesta reprezintă cel mai mare și complex proiect
de IT și infrastructură, care a fost implementat vreodată în Moldova, cu o
valoare totală de 6,5 milioane USD – finanțat și gestionat de Banca
Mondială
Principalele produse MCloud:
IaaS,
MPass (serviciul guvernamental de autentificare şi control al
accesului),
 MSign (serviciul electronic guvernamental integrat de semnătură
digitală),
MPay (serviciul guvernamental de plăţi electronice).
MCloud reprezintă mediul guvernamental de cloud computing

pentru găzduirea și operarea eficientă a sistemelor informaționale
guvernamentale. Platformă modernă de servicii de tip Iaas & SaaS,
dedicate dezvoltării, automatizării serviciilor și extinderii către terțe părți în
calitate de furnizori de cloud.
MCloud e bazat pe produsele VMware vRealize Suite, sisteme
convergente FlexPod formate din matrici de discuri NetApp FAS și servere
Cisco UCS.

1.Definitia Arhitectura NGN-объединены

Încărcat de

Informații document

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

1.Definitia Arhitectura NGN-объединены

Încărcat de

Drepturi de autor:

Formate disponibile

Difiniția și arhitectura NGN

NGN este o rețea bazată pe comutația de pachete,

Services in NGN environments

Services in legacy environments

 bazată pe transfer de pachete IP pentru

Arhitectura NGN deseori se prezintă pe trei nivele

 Nivelul transport și comutație.

Softswitches Control rețea și

API - Application Programming Interface

Evoluția nr. de abonați în bandă largă în funcție de tehnologia de acces (mii)

Sistem de semnalizare pe canal comun (CCS)

Standard mondial pentru telecomunicații definit de către

Standardul SS7 definește procedurile prin care elementele

• Operații de bază legate de stabilirea, taxarea și

Application INAP MAP

Network MTP Nivel 3

Data Link MTP Nivel 2

Physical MTP Nivel 1

SCCP furnizează funcții adiționale MTP-ului pentru asigurarea

 Prima este de a se adresa la aplicații într-un punct de semnalizare. MTP-

SCCP este utilizat ca și un strat de transport pentru serviciile bazate pe

TCAP sprijină schimbul de date între aplicații din rețeaua

Length indicator = 0: Fill-in signal unit (FISU)

Signalling Link Selection (SLS)

• Status field format (SF)

Formatul Atribuire Tipul de numere

Linie goală (CRLF)*

Tip cerere SP Adresa destinație SP Versiune SIP

Linia de start - RASPUNS

Versiune SIP SP Cod răspuns SP Descrierea textuală

CANCEL Anulează o tranzacție în așteptare la care încă nu este primit răspuns

INFO Oferă un mecanism de transport a informației de nivelul aplicațiilor care

REGISTER Înregistrează informații de contact.

NOTIFY Informează un abonat cu privire la schimbarea de stare a resursei (s-a

Cerere & Răspuns Cerere Răspuns

Accept (Accept: audio/*; q=0.2, Authorization Proxy-Authenticate

INVITE sip:bob@192.0.2.4 SIP/2.0

sau alta ca un număr de telefon:

A ……. Proxy ……. Proxy ……. B

M2 100 Trying atlanta.com proxy -> Alice

Exemple de porturi bine cunoscute :

(max 65 507 octeți)

Lungimea totală a Dacă nu se folosește

Câmpul „Lungimea datagramei UDP” conține lungimea mesajului

Pseudo-antetul nu este inclus în mesajul UDP. Este folosit pentru a

La primirea mesajului, destinatarul calculează din nou checksum-ul

exemplu: add two 16-bit integers

Deoarece adresele IP sunt utilizate în calculul checksum-ului

RFC: 793 TRANSMISSION CONTROL PROTOCOL

DARPA INTERNET PROGRAM

TCP este un protocol fiabil orientat pe conexiune, cap la cap.

TCP prevede o comunicare fiabilă dintre perechile de procese

Nu există erori de biți din datorită checksum.

Păstrarea ordinei pachetelor.

Fără duplicare de pachete.

Fără pierderi de pachete.

Portul destinatie (16 biti) - identifica portul ce recepteaza datele.

Sequence number (numarul secventei) (32 biti) - are un rol

Acknowledgment number(32 biti) – daca este setat flag-ul ACK

Offset de date (4 biti) – specifica marimea header-ului TCP in

Flag-urile de control sunt in numar de 8 a cate un bit:

Verificare(Checksum) (16 biti) – este folosit pentru verificarea existentei

Data – aceasta este portiunea de date a pachetului TCP. Poate fi

Linie goală (CRLF)*