Voip
De la Publicitate Enciclopedica
Cuprins |
VoIP in reteaua MOICANE
Aplicaţia de telefonie peste IP este bazată pe standardul H.323. Aplicaţia de VoIP va fi o implementare a tuturor protocoalelor H.323 permise cu ajutorul RSVP şi a opţiunilor de multicast. Va fi folosit sursa Open H.323 pentru Microsoft Windows2000 Operating System. Open H.323 oferă coduri sursă freeware. Să presupunem acum că avem o convorbire între un profesor şi un student, ambii utilizatori ai serviciului de telefonie peste IP. Să vedem cum ar arăta din punct de vedere tehnic o asemenea convorbire. Sudentul apelează profesorul trimiţându-i o cerere de tip H.225 call request. Iniţial, aplicaţia profesorului se află în modul de aşteptare pentru noi apeluri. Atunci când studentul apelează profesorul folosind adresa IP unicast a profesorului, se deschide o sesiune RSVP. Profesorul acceptă apelul sosit folosind interfaţa grafică (un mesaj H.225 accept e trimisă studentului). Atunci, aplicaţiile profesorului şi studentului încep să schimbe mesaje de tip H.245, mesaje ce aparţin standardului H.323 şi care se ocupă cu negocierea parametrilor prin care se va face schimbul de informaţie. Toate mesajele necesare vor fi schimbate conform standardului H.323. Descrierea standardului H.323 a fost făcută în capitolul anterior. Atunci când negocierea între profesor şi student ia sfârşit, aplicaţiile celor doi vor crea module media ce vor transmite şi recepţiona vocea. Acestea sunt modulele numite Media-Transmit şi Media-Receive şi sunt responsabile cu mai multe operaţiuni printre care transmiterea şi recepţia audio prin reţea, convertirea de la audio stream la pachetele RTP şi invers, codarea şi decodarea şi producerea de mesaje de raport RTCP. Penru a fi şi mai clar, modulele de transmisie vor prelua semnalul de voce de la componentele ce se ocupă cu recepţionarea lor (microfonul ataşat computerului, de exemplu). Apoi semnalul de media va fi codat conform standardului G.711. Semnalul codat va fi apoi încărcat în pachete RTP. Modulele de transmisie sunt responsabile cu trimiterea pachetelor RTP şi RTCP. În cazul studentului, aceste pachete vor fi trimise către adresa unicast a profesorului. În cazul profesorului, pachetele vor fi trimse unui grup multicast de adrese IP. Pe de altă parte, modulele de recepţie sunt reponsabile cu recepţia pachetelor RTP şi cu schimbul de pachete RTCP. Modulele de recepţie vor extrage semnalul media încărcat în pachetele RTP. Apoi îl vor decoda şi îl va reda plăcii audio cu care e echipat terminalul. Aplicaţia studentului va recepţiona pachete RTP de la o adresă IP multicast. Aplicaţia profesorului va recepţiona de la adrese IP unicast al tuturor studenţilor conectaţi. Este de observat că în timpul unei sesiuni, aplicaţia studentului a încărcat un modul de transmisie şi unul de recepţie. Pe de altă parte, aplicaţia profesorului a încărcat unul de transmisie (către adresă multicast) şi unul sau mai multe pentru recepţie (un modul de recepţie pentru fiecare student conectat).
Modulul Media-Transmit
Modulul Media-Transmit este responsabil cu captura semnalului audio de la sursă (microfon) şi transmiterea lui prin reţea sub formă de pachete RTP. Deasemenea, modulul generează şi transmite rapoarte RTCP. Toate conversiile de date de la semnalul audio pur la pachetele RTP se fac intern. Modulul conţine următoarele :
- Filtru de captare
Filtrul de fapt este un „wrapper” pentru driverele echipamentelor de captare capabil de a genera semnal audio captat. Termenul de semnal audio captat defineşte ieşirea oricărui echipament hardware care are rolul de a recepţiona audio, ca de exemplu camere, TV tunere sau plăci de sunet.
- Filtru de codare G.711
Codează semnalul audio necompresat în format G.711
- Filtru RTP Send Payload Handler
Responsabil cu segmentarea semnalului audio codat în pachete RTP ca şi cu asignarea corectă a etichetelor de timp pentru header-ele RTP.
- Filtru RTP Render
Este filtrul care forwardează pachetele RTP în cadrul reţelei. Este deasemenea responsabil cu generarea pachetelor RTCP Sender. Mesajele RTCP ce sosesc sunt recepţionate tot de acest filtru care, ca răspuns, ia măsurile adecvate (de exemplu, absenţa unor mesaje RTCP face ca filtrul să se oprească din a mai transmite spre reţea). Modulul de transmisie arată astfel :
Modulul Media Receiver
Modulul Media Receiver este responsabil cu recepţia pachetelor RTP din reţea, cu conversiile necesare a încărcăturii pachetelor şi cu redarea semnalului audio rezultat. Ca şi în cazul modulului de transmisie, modulul de recepţie generează rapoarte RTCP şi face conversiile necesare. Modulul conţine următoarele :
- Filtrul Source RTP
Filtrul lucrează ca o sursă de pachete RTP. Toate pachetele recepţionate sunt rapid date spre următorul filtru neordonate şi ne-bufferate. Ca şi în cazul filtrului RTP Sender, şi acest filtru generează pachete RTCP şi primeşte pachete RTCP.
- Filtrul Receive Payload Handler
Responsabil cu reordonare şi reasamblarea pachetelor în buffere. Deasemenea, acest filtru asignează o etichetă fiecărui buffer funcţie de etichetele pe care le au deja pachetele RTP primite
- Filtru Decoder G.711
Decodează fluxul codat G.711
- Filtru Audio Render
Filtru ce redă semnalul audio necomprimat. Modulul de recepţie arată identic cu cel de transmisie.
Calitatea Serviciului (componenta RSVP)
Pachetele RTP sunt trimse în reţea pe nişte rute rezervate. Aplicaţia de VoIP va starta un daemon RSVP. În cazul studentului, aplicaţia VoIP porneşte procedura RSVP atunci când studentul apelează profesorul. Iniţial, studentul începe prin a folosi standardul H.225. Când profesorul primeşte apelul de început de la student, un server RSVP va fi lansat de aplicaţia profesorului. De fapt, procesul de server este o sesiune stand-by. Acest proces e pornit de recepţia unui mesaj PATH şi răspunde aplicaţiei studentului cu un mesaj RESV. Informaţiile incluse în apelul de debut sunt folosite pentru crearea sesiunii. Când studentul primeşte mesajul de acceptare de la profesor, el iniţializează o sesiune RSVP. Atunci el porneşte sesiunea şi un mesaj Path este trimis către aplicaţia profesorului. RSVP este Resource Reservation Protocol şi este descris în RFC 2205 (versiunea 1 din 1997) şi în RFC 2750 (cu toate update-urile din 2000). Protocolul RSVP este parte a arhitecturii IETF Integrated Services (IntServ) descrisă în RFC 1633-1944 care permite diferitelor echipamente să comunice cererile QoS. IntServ produce un protocol pentru semnalizarea cererilor QoS ale aplicaţiilor şi încorporează specificaţii pentru descrierea cererilor de servicii şi alte funcţionalităţi ale echipamentelor şi a altor elemente de reţea care suportă QoS. IntServ este îndreptat spre suportul traficului de date în timp real aşa ca video sau voce. RSVP a fost creat pentru a semnala cererile de QoS peste conexiunile Internetului. Este un protocol bazat pe protocolul IP, hop-by-hop care informează echipamentele de pe o anumită cale a unui flux de date despre cererile pentru calitatea serviciului. Obligaţia de bază a protocolului este să rezerve resurse astfel încât aplicaţia să poată primi cantitatea de lărgime de bandă dorită. În această încercare de rezervare de resurse, politica de management a lărgimii de bandă poate fi aplicată prin „policy objects”, mai departe crescând eficienţa alocării de bandă. În fond, RSVP este o metodă de a emula o reţea cu comutaţie de circuite peste o reţea cu comutaţie de pachete. Din cauza funcţionării în IP, reţelele bazate pe acest protocol plasează responsabilitatea pentru menţinerea stării conexiunii doar la echipamentele terminaţii ale reţelei, deci RSVP cere ca fiecare ruter intermediar să menţină informaţiile despre starea conexiunii. RSVP poate fi folosit pentru trafic unicast şi multicast. În cazul traficului multicast, un emiţător (sender) înaintează o copie a fiecărui pachet către mai mulţi receptori. O raţiune pentru creearea acestei legături bazate pe receptor-rezervări este multicastul. Acest tip de trafic adesea presupune cereri de rezervare de la diferiţi receptori cu caracteristici foarte diferite – şi astfel de un astfel de protocol e nevoie pentru a suporta aceste cereri. Din cauza complexităţii fluxurilor multicast, rezervările trebuie să fie unificate. În traficul multicast, pachetele ce trebuiesc livrate spre diferite next-hop-uri sunt replicate. În RSVP, cererile de rezervare trebuie unificate la fiecare punct de replicare. Într-adevăr, cererile multiple de rezervare sunt combinate în aceste puncte de unificare şi apoi înaintate ca o singură cerere de rezervare. Aceasta are legătură cu conceptul de rezervări disincte şi rezervări multiple, ambele suportate de RSVP. În cazul rezervărilor distincte, o singură rezervare este făcută pentru fiecare emiţător upstream o dată. În cazul rezervărilor multiple, un număr de emiţători intr-un flux multicast folosesc o aceeaşi rezervare. (Receptorul sau destinaţia e referit ca downstream , iar transmiţătorul e referit ca upstream.) Există subcategorii de moduri de rezervare. În modul Wild-Card Filter (WF), o singură cerere de rezervare e generată şi împărţită între toate fluxurile de la toţi emiţătorii. În modul Fixed Filter(FF), fiecare emiţător generează câte o cerere distinctă de rezervare. În modul Share Explicit (SE), mai mulţi emiţători selectaţi împart o aceeaşi cerere de rezervare. Aceste moduri de rezervare ajută la optimizarea rezervărilor de la diferiţi emiţători în acelaşi timp. RSVP este executat printr-o serie de mesaje. Un pachet standard RSVP are headerul format din :
- câmpuri de 4 biţi :
Vers- arată numărul versiunii protocolului ; Flags – câmp nespecificat.
- câmpuri de 8 biţi :
Reserved Field Send TTL – indică time to live al mesajului trimis Message Type indică funcţia mesajului
- câmpuri de 16 biţi :
Header-ul e urmat de un set de obiecte care includ informaţiile necesare pentru descrierea şi caracterizarea acelui mesaj particular. Aceste obiecte sunt împărţite în clase şi fiecare clasă de obiecte poate conţine mai multe tipuri ce caracterizează formatul datelor în detaliu mai mare.
Există 2 tipuri de RSVP : Nativ şi UDP-încapsulat. În cazul Nativ, header-ul şi încărcătura sunt încapsulate în datagrame IP, cu numărul de protocol 46. RSVP UDP-încapsulat poate permite terminalelor să comunice cu primul şi ultimul hop, chiar dacă aceste terminale nu suportă RSVP. În RSVP, un mesaj PATH este transmis de la emiţător la un receptor (sau un receptor multiplu). Mesajele PATH reţin informaţii de cale în fiecare nod străbătut de-a lungul căii; minim, un mesaj PATH conţine adresa IP a fiecărui hop de dinainte în calea străbătută. Aceste adrese IP stabilesc calea pentru transmiterea mesajelor „cerere de rezervare subsecventă” RESV.
Mesajul PATH conţine un obiect Sessiune care include adresa de destinaţie şi informaţiile de port şi un obiect „Previous Hop” (PHOP) care defineţte ruterul precedent în direcţia fluxului. În plus, mesajul PATH conţine obiectele Sender Template şi un Sender Traffic Specification (Tspec). Sender Template conţine specidicaţii de filtru (FilterSpecs) şi identifică formatul traficului pe care emiţătorul îl va trimite. Sender Tspec caracterizează fluxul de trafic pe care emiţătorul intenţionează să-l genereze, în sensul atributelor ca lărgime de bandă, jitter sau întârziere. Mesajul PATH mai poate conţine un obiect Adspec care descrie tipul serviciului, caracteristici ale performanţelor specifice serviciului şi suma resurselor disponibile pentru o rezervare particulară. Adspec e trimis către controllerul local de trafic din fiecare nod sau ruter de-a lungul căii pentru updatare.
Mesajul PATH mai poate conţine un obiect Policy Data care include informaţii despre sursă sau hopul precedent al unui flux de date. Procesul de control al politicii foloseşte date de politică pentru a stabili autorizări şi feed-back-uri pentru fluxul de date. În afară de primirea mesajelor PATH, ruterele ce suportă RSVP au o stare PATH care, la minimum reţin adresa IP a hopului precedent (PHOP). Această informaţie e utilizată pentru a răspunde în direcţie inversă cu mesaje RESV. Starea PATH informează componentele reţelei de-a lungul căii despre celelalte noduri RSVP.
Receptorul face cererea de rezervare prin transmiterea înapoi a unui mesaj RSVP în direcţie inversă (spre sursa datei). Mesajul RESV include o specificaţie de rezervare Rspec, care specifică ce tip de servici este cerut (Guaranteed sau Controlled Load). Guaranteed Service oferă o conexiune ca un circuit virtual, pe când Controlled Load depăşeşte un derviciu „best-efort”, dar nu e la nivelul Guaranteed Service.
Mesajul RESV include informaţii despre modurile de rezervare ca şi un FlowDescriptor care conţine un obiect FlowSpec şi un obiect FilterSpec. Obiectul FlowSpec stabileşte parametrii QoS pentru procesul de programare (aranjare) a pachetelor. FilterSpec îndeplineşte aceeaşi funcţie în procesul de clasificare a pachetelor. În afara primirii mesajului RESV, ruterele si nodurile de reţea RSVP-enabled au un proces de control al admisiei care indică care dintre noduri pot suporta cererile impuse de QoS. Dacă acest proces se încheie cu succes, mesajul RESV este timis către următorul ruter. Ruterele ce cunosc RSVP de-a lungul căii organizează şi prioritizează pachetele în funcţie de cereri. Aceste sisteme trimit pachetele de date ce vin către un clasificator de pachete, apoi sunt stocate într-o coadă de aşteptare a unui organizator de pachete. Un filtru de pachete asignează (mapează) pachetelor o anumită clasă de servicii, definid clase de rute şi QoS pentru aceste pachete. Organizatorul de pachete forţează alocarea de resurse şi selectează pachetele pentru transmisie.
După ce ultimul ruter de-a lungul căii garantează cererea, o confirmare de rezervare (ResvConf) notifică recepţiei că cererea a fost plină de succes. RSVP este un protocol soft-state aşa încât rezervările trebuiesc periodic reconfirmate. Această caracteristică ajută la schimbările în rutere şi schimbările în alcătuirea grupurilor de multicast.
Sesiunile se termină prin transmiterea unor mesaje ce anulează căile sau stările de rezervare in nodurile spre recepţie. Mesajul PathTear sunt create de transmiţători (sau de opţiunea de timed out al RSVP) în fiecare nod pe cale şi trimise către toţi receptorii. Trimis de nodul care l-a creat, mesajul anulează starea căii în fiecare nod de-a lungul căii. Mesajele Path Tear anulează stările de rezervare în aceste noduri sau echipamente. În cazul unei erori de control al emisiei, un mesaj de eroare este trimis către cel ce a trimis cererea. Dacă unul dintre nodurile reţelei nu poate executa starea PATH, el trimite un mesaj PathError (PathErr) către emiţător. Dacă o stare de rezervare nu poate fi invocată, atunci componenta trimite un mesaj Reservation Error (ResvErr) către emiţător.
RSVP pote fi combinat cu alte protocoale QoS şi tehnologii ca de exemplu Differentiated Services (DiffServ) sau MPLS (Multiprotocol Label Switching). DiffServ marchează şi prioritizează traficul, iar RSVP asigură resursele necesare pentru a transmite acel trafic. Este de asemenea compatibil cu MPLS, adică MPLS este capabil de a asigna etichete în concordanţă cu specificaţiile RSVP Flowspec. Ca puncte negative, complexitatea şi sofisticarea RSVP scade performanţa pe ruterele backbone-ului. Este simplu de aplicat pe unele aplicaţii de complexitate mai scăzută, însă RSVP este adesea înlocuit de alte protocoale pe backbone-ul reţelei, ca de exemplu DiffServ.
Arhitectura de reţea DiffServ
- DiffServ a fost creat pentru a oferi o modalitate mai simpla pentru a stabili clase de servicii diferenţiate pentru traficul Internet. În modelul IntServ, resursele sunt alocate pentru fluxuri individuale, ceea ce duce către limităţi de scalabilitate. În modelul DiffServ, traficul este divizat într-un număr mic de clase înaintate(forwarding), iar resursele sunt alocate pe clase. Nivelurile de performanţă dorite sunt atinse printr-o combinaţie dintre provisoning, prioritizare şi control al admisiei. Aceasta este în contrast cu alte tehnici , ca de exemplu rezervarea de resurse cap-la-cap, tehnică care stă la baza RSVP. DiffServ a fost proiectat pentru a oferi servicii pentru mai multe clase agregate conţinând mai multe fluxuri. Simplitatea este dată de faptul că aceste fluxuri sunt grupate ăntr-un număr relativ mic de agregate care primesc un număr limitat de tratamente diferenţiate (definite prin politici) prin reţea.
Unul dintre scopurile DiffServ a fost să elimine nevoia de stări de rezervare de resurse pentru fiecare flux, ca şi a semnalizărilor din fiecare router de-a lungul căii. Mai toate clasificările şi politicile sunt făcute la marginea reţelei. În partea centrală a sa, routerele inspectează doar un câmp din header-ul pachetului IP – câmpul DiffServ – pentru a determina unde să trimită pachetul în continuare, ca diferenţă faţă de păstrarea informaţiei pentru fiecare flux în parte (Câmpul DiffServ se mai numeşte câmp DS sau octet DS). Scopul suprem al arhitecturii DiffServ este de a simplifica înaintarea prin partea centrală a reţelei şi de a plasa spre marginea reţelei sarcinile de procesare ce apare o dată cu clasificarea traficului. Această arhitectură este mai adecvată pentru facilitarea nivelelor de scalabilitate cerute de reţelele din ziua de astăzi, decât multe alte posibile variante. Arhitectura DiffServ este descrisă în detaliu în RFC 2475. Atunci când traficul apare pe o interfaţă de intrare într-o reţea cu arhitectura Diffserv, acesta este clasificat şi supus unui proces de admisie preconfigurat, apoi este făcut să îndeplinească cererile de politică în concordanţă cu o clasificare specifică. Apoi fluxul de date asignat unui comportament agregat. Aceasta este făcută prin marcarea câmpurilor IDS a headerelor pachetelor IP cu DSCP (Differentiated Services Code Point) corespunzător. Valoarea DSCP iniţiază un comportament per-hop (PHB –per-hop behaviour) în componentele reţelei şi clasifică nivelul serviciului pentru pachetul respectiv.(Termenul PHB specifică tratamentul specific de înaintare a unui pachet care apare într-un nod particular.)
În DiffServ, câmpul Type of Service (TOS) din headerul IPv4 este înlocuit de câmpul DS care conţine o valoare pe care routerele DiffServ o folosesc pentru a determina un PHB specific pentru fiecare nod de-a lungul căii. Primii 6 biţi ai câmpului DS compun DSCP. Acesta este în concordanţă cu PHB , care este recepţionat de la fiecare pachet ce conţine acest câmp la fiecare nod. Valoarea din câmpul DSCP se numeşte code points. Ultimii 2 biţi din cadrul câmpului DS se numesc CU (Curently Unused) şi suportă versiunile anterioare de echipamente ce nu cunosc DiffServ şi care utilizează octetul TOS pentru a determina tratamentul de înaintare(forwarding). Câmpul DS poate avea până la 64 de valori.
Octetul DS este deasemenea ingredientul fundamental pentru asigurarea SLA (Service Level Agreement) între componenţii unei reţele sau între reţele propriu-zise. Mai exact, TCA (Traffic Conditioning Agreements) sunt definite pentru atingerea acestui scop. TCA poate include parametrii privind profilul traficului(întârzieri, lărgimi de bandă, priorităţi, etc) şi instrucţiuni privind tratamentul aplicat altor pachete.
Cele două procese fundamentale în implementarea DiffServ sunt classificarea si condiţionarea.(Fig). În DiffServ, traficul este condiţionat şi clasificat la frontiera reţelei pe baza parametrilor TCA ce există stabiliţi între providerul de servicii şi clientul reţelei.
În DiffServ, un clasificator selectează pachetele funcţie de informaţia in headerul pachetului corelat cu politicile stabilite pentru controlul admisiei. Există două tipuri de clasificatoare DiffServ: Behavior Aggregate(BA) şi Multi Field (MF). Clasificatorul BA clasifică pchetele funcţie de valoarea DSCP din headerul pachetului. Clasificatorul MF clasifică pachetele după unul sau mai multe câmpuri din header, ceea ce permite o alocare a resurselor mult mai complexă decât oferă BA. Acesta permite o marcare a pachetelor bazată pe adresele sursă sau destinaţie, porturile sursă sau destinaţie, ID-ul protocolului printre alte variabile. Condiţionarea implică metering, marking, shaping şi dropping.
Un meter monitorizează traficul după modul în care acesta este clasificat. El determină care tip de trafic are anumite caracteristici, şi , deasemenea, poate ţine statistici despre trafic, statistici folosite in procesele de contabilizare şi facturare a serviciului oferit. Markerul setează câmpul DS cu o valoare specifică. Pachetele pot fi marcate pentru un anumit flux pentru a ajuta la asigurarea secvenţei corecte a PHB pentru acel flux. Markerul poate fi folosit pentru remarcări (de exemplu pentru schimbarea unei valori a octetului DS) sau pentru a sterge marcarea pentru pachetele ce nu mai corespund profilului. Pachetele ce ajung în diferite domenii trebuie remarcate repetat pentru a asigura proprietatea de a fi în concordanţă cu profilul traficului din domeniul în care intră. (Un domeniu este un set de noduri de reţea care operează după un set de politici şi definiţii PHB comune). Funcţia shaperului este de a reţine pachetele în cozi pentru a asigura ca traficul să fie în profilul declarat, de multe ori reţinând multe pachete până a le elimina din nou în reţea.
Atunci când un flux depăşeşte specificaţiile de trafic, pachetele în exces pot fi pur şi simplu aruncate din acel flux. Alternativ, pachetele pot fi întârziate sau li se poate reduce nivelul de prioritate. Aceste măsuri sunt luate atunci când, de exemplu, un flux depăşeşte rata de transmisie negociată. Un aspect cheie al implementării DiffServ este determinarea căror pachete vor primi prioritate la înaintare. Există două tipuri primare de înaintări: Expedited Forwarding (EF) şi Assured Forwarding (AF). EF oferă minim de întârzieri, jitter, pierderi de pachete şi banda asigurată. În EF , rata de sosire a pachetelor trebuie sa fie mai mică decât rata de ieşire la acel nod. Pachetele care nu corespund profilului de trafic sunt aruncate sau oferite în afara secvenţei. EF este destinat aplicaţiilor cu sensibilitate la întârzieri ca traficul audio sau video. În AF, există 4 clase , fiecare conţinând 3 proceduri de aruncare a pachetelor. Priorităţile de aruncare sunt date pentru a determina care pachete să fie aruncate în timpul perioadelor de congestie în reţea. Pachetele ce nu mai satisfac profilul sunt aruncate în conformitate cu procedurile. Pachetele cu prioritate mai mare sunt aruncate primele.
În DiffServ, SLA între clienţi şi service provider stabilesc criteriile de politică şi definesc profilurile de trafic. Traficul e clasificat şi condiţionat la interfaţa de intrare în reţea, insă dacă traficul trebuie să traverseze mai multe domenii, unele dintre aceste procese pot fi efectuate şi la interfeţele de ieşire din reţea sau în nodurile interioare ale reţelei. Internetul şi unele reţele de companii conţin mai multe domenii. Asigurarea lărgimii de bandă de-a lungul mai multor domenii este principala problemă dacă se doreşte un anumit nivel QoS cap-la-cap. Profilul traficului care traversează frontiera dintre două domenii se specifică în SLA care există între cele două domenii. Dar o dată cu creşterea traficului între două domenii, creşte şi nevoia de a ajusta profilul traficului, ducând la nevoia unei alocări de resurse mult mai flexibilă. Aici apare Bandwith Broker(BB). BB începe cu o setare cap-la-cap a legăturii cu alţi BB de-a lungul căii dorite, făcând negocieri de resurse prin mai multe domenii. BB performează control al admisiei, control de politici, agregări şi urmăriri de rezervări. BB poate facilita cererile de rezervare dintre reţeaua unei întreprinderi şi utilizatorii ei.
DiffServ are potenţialul de a suporta trafic multicast, dar unele estimări de trafic trebuiesc realizate înainte de folosirea lui pe o scara mare. Faptul că membrii grupurilor de multicast se pot schimba foarte repede face dificilă cunoaşterea cantităţii de trafic implicată într-o sesiune multicast – o nevoie pentru asigurarea calităţii unei transmisii multicast. În plus, un arbore de distribuţie multicast poate avea un punct de intrare şi mai multe puncte de ieşire, ceea ce complică estimarea de trafic. În continuare se depun eforturi pentru determinarea unei coabitări între DiffServ şi RSVP. Ideea este de a se utiliza RSVP la marginea reţelei şi DiffServ în interiorul ei. Cele două tehnologii au câteva proprietăţi complementare care ar face din această combinaţie o soluţie de aplicat. RSVP excelează la managementul pe flux unic, dar nu e scalabil. Deasemenea, deoarece e mult mai complex decât DiffServ, se recomandă a nu se utiliza pe backbone de reţea.
Pe de altă parte, DiffServ are capabilităţi de management de resurse limitat , dar este mult mai scalabil decât RSVP. De aceea, folosirea RSVP ca metodă de acces şi a DiffServ ca metodă de forwarding ar putea fi o soluţie foarte eficientă în încercarea de a susţine nivelurile de QoS peste o reţea.
