Prezentarea Proiectului Moicane. Nevoia de Servicii cu Garantare a Calitatii

Capitolul I – Prezentarea proiectului MOICANE

Introducere

Fiecare dintre ultimele trei secole a fost dominat de o anumită tehnologie. Secolul al XVIII-lea a fost secolul marilor sisteme mecanice care au însoțit Revoluția Industrială. Secolul al XIX-lea a însemnat era mașinilor cu aburi. În secolul XX, tehnologia cheie este legată de colectarea, prelucrarea și distribuirea informației. Printre alte realizări, am asistat la instalarea rețelelor telefonice mondiale, la invenția radioului și a televiziunii, la nașterea și creșterea nemaivazută a industriei de calculatoare și la lansarea sateliților de comunicații.

Datorită progresului tehnologic rapid, aceste domenii converg în ritm alert, iar diferențele între colectarea, transportul, stocarea și prelucrarea informației dispar pe zi ce trece. Organizații cu sute de birouri răspândite pe o arie geografica largă se așteapta sa poată examina în mod curent printr-o simplă apăsare de buton chiar și echipamntele lor cele mai îndepărtate. Pe masură ce posibilitățile noastre de a colecta , prelucra și distribui informația cresc tot mai mult, cererea pentru o prelucrare și mai sofisticată a informației crește și mai rapid.

Deși industria de calculatoare este tânară în comparație cu alte industrii (de exemplu construcția de automobile și transportul aerian), domeniul calculatoarelor a cunoscut un progress specataculos într-un timp scurt. În primele decenii de existență, sistemele de calcul erau foarte centralizate, de obicei în interiorul unei singure încăperi. Adesea, această încăpere avea pereții de sticla prin care vizitatorii se puteau holba la marea minune electronică dinăuntru. O companie de marime mijlocie sau o universitate ar fi putut avea unul sau doua calculatoare, în timp ce instituțiile mari aveau cel mult câteva zeci. Ideea că în mai puțin de 20 de ani calculatoare la fel de puternice, mai mici decat un timbru poștal, vor fi produse pe scară largă în milioane de exemplare părea desprinsă dintr-un scenariu științifico-fantastic.

Întrepătrunderea dintre domeniul calculatoarelor și cel al comunicațiilor a avut o influență profunda asupra modului în care sunt organizate sistemele de calcul. Conceptul de “centru de calcul” – în accepțiunea sa de camera unde există un calculator mare la care utilizatorii vin să ruleze programele – este total depășit. Vechiul model al unui singur calculator care servește problemele de calcul ale organizației a fost înlocuit de un model în care munca este facută de un număr mare de calculatoare separate, dar interconectate. Aceste sisteme se numesc rețele de calculatoare.

Deosebim în acest context două tipuri de rețele :

Rețele pentru firme – conduc la o împarțire a resurselor cu următoarele scopuri :

disponibilitate a datelor firmei indiferent de locația geografică în care se află respectiva unitate

fiabilitate prin accesul la mai multe echipamente de stocare alternative

economia dată de raportul calitate/preț mult mai bun al calculatoarelor mici față de sistemele mari de calcul.

Rețelele pentru oameni – începând cu anii 1990, rețelele de calculatoare au început să furnizeze servicii la domiciliu pentru persoane particulare. Iată câteva :

Accesul la informație la distanță

Comunicațiile interpersonale

Divertismentul interactiv

Din punct de vedere al întinderii lor ca arie geografică, deosebim alte trei tipuri de rețele :

-rețele locale (LAN-Local Area Network) sunt rețele private localizate într-o singură cladire sau într-un campus de cel mult cațiva kilometri. LAN-urile se disting de alte tipuri de rețele prin 3 caracteristici : (1) mărime, (2) tehnologie de transmisie si (3) topologie. Astfel (1) LAN-urile au dimensiuni restrânse ceea ce înseamna că timpul de transmisie e limitat și dinainte cunoscut. Cunoscând această limită, este posibil să utilizăm anumite tehnici de proiectare. Deasemeni, se simplifică administrarea rețelei. Pentru (2), LAN-urile utilizează frecvent o tehnologie de transmisie care constă dintr-un singur mediu (cablu în special, dar există și Wireless LAN) la care sunt atașate toate mașinile. LAN-urile tradiționale funcționează la viteze cuprinse între 10 și 100 Mbps, au întârzieri mici (zeci de microsecunde) și produc erori foarte puține. În privința (3), mai cunoscute sunt rețeaua cu magistrala (cu cablu liniar), de exemplu standardul IEEE 802.3, popular numit Ethernet (funcționând la 10-100 Mbps) și standardul IEEE 802.5 numit inel cu jeton (token ring) ce lucrează la viteze de 4-16 Mbps.

-rețelele metropolitane (MAN-Metropolitan Area Network) este în linii mari o versiune extinsă de LAN și utilizează în mod normal topologii similare cu acesta. Un MAN se poate întinde pe zona ocupată de un grup de birouri învecinate sau pe suprafața unui întreg oraș și poate fi atât privata cât și publica. Un MAN poate suporta atât date cât și voce și dispune numai de un cablu sau două, fără să conțină elemente de comutare care deviază pachetele pe una din cele câteva linii posibile de ieșire.Un exemplu de MAN este standardul IEEE 802.6 denumit DQDB (Dual Queue Dual Bus- magistrala duală cu coadă distribuită). DQDB constă din două magistrale unidirecționale la care sunt conectate toate calculatoarele.

-rețelele larg raspândite geografic (WAN-Wide Area Network) – acoperă o arie geografică întinsă – deseori o țară sau un continent întreg. Rețeaua conține o colecție de mașini utilizate pentru a executa programele utilizatorilor, numite mașini gazda. Gazdele sunt interconectate printr-o subrețea de comunicație. În majoritatea rețelelelor larg răspândite geografic, subrețeaua este formată din două componente distincte: liniile de transmisie și elementele de comutare. Liniile de transmisie (numite și canale, circuite sau trunchiuri ) au ca sarcină transportul biților între mașini. Elementele de comutare sunt calculatoare specializate folosite pentru a conecta două sau mai multe linii de transmisie. Ca exemple de WAN-uri se pot aminti : PSTN (Public Switched Telephone Network- rețeaua publică de telefonie) sau Internet pentru a nu da decât să le zicem pe cele mai semnificative dintre rețelele de voce și date.

Ce este MOICANE ?

Tot din categoria de rețele larg raspândite geografic (WAN) face parte și rețeaua MOICANE, rețea care face subiectul acestui studiu.

MOICANE înseamnă Multiple Organisation Interconnection for Collaborative Advanced Network Experiments și este, asa cum îi spune și numele, o rețea pan-europeană utilizată în scopuri științifice.

MOICANE presupune o colaborare între mai mulți parteneri, fiecare cu atribuțiile sale, astfel :

-Alcatel Italia subsidiara italiană a Alcatel Group, lider in producția de echipamente și sisteme de telecomunicații și în sectorul de cabluri și fibră optică, activ în 130 de tări. Gama sa de produse și servicii se adresează unui grup larg de utilizatori, ca operatori de rețele fixe sau mobile, ISP-uri, industria în general, dar și utilizatori privați. Alcatel Italia este un mare producător pentru echipamente ATM și are un rol dual de Prime Contractor al rețelei MOICANE, cât și cel mai important provider de echipamente. Echipamentele Alcatel vor constitui baza rețelei în unele dintre insulele retelei MOICANE, ca și rețeaua de interconexiune dintre aceste insule.

-Consortio Pisa Ricerche (CPR) s-a consituit în 1987 cu scopul principal de a promova și coordona transferul de nouă tehnologie dinspre universități și centrele de cercetare către industrie. CPR este o organizație non-profit care are printre membri atât companii publice cât și companii private. Multimedia and Telematic Application (META) Centre din cadrul CPR oferă expertiză tehnică în sectorul de Multimedia Networking și Telecom.

-Flextel dezvoltă soluții inovative pentru Internet și Corporate Intranet, care să ofere funcții de calcul, acces, rutare și comutație pe aceeași platformă. În cadrul MOICANE, Flextel produce echipamente de rețea cu un înalt grad de adaptare care pot fi configurate ca IP routere sau servere de înaltă performanță care vor avea un rol cheie în asigurarea unor platforme flexibile de la care se vor dezvolta componente IP capabile să suporte QoS și să fie interfețe pentru diferitele soluții de arhitecturi de rețea și secțiuni de rețea (core și acces).

-INOV (INESC-Inovacao-Instituto de Novas Tecnologias) este o asociație privată, non-profit, dedicată cercetării, dezvoltării tehnologiei și oferirii de training avansat în IT și Telecom. INESC iși creează programul de cercetare în funcție de cererile din partea operatorilor naționali și internaționali.

-Wind (companie rezultată în urma fuziunii dintre Wind și Infostrada) este cel de-al doilea operator public pentru servicii de voce și date din Italia. Wind are mai mult de 4 milioane de clienți din care 2,5 milioane pentru voce și 1,5 milioane pentru servicii de internet. Traficul zilnic monitorizat într-o zi de lucru este de 31 milioane minute. Profitul este adus în proporție de 58% de sectorul de afaceri și 42% de sectorul rezidențial.

-NTUA-ICCS The Institute of Communication and Computers Systems (ICCS) este o parte privată asociată cu Departamentul de Inginerie Electrică și Calculatoare din cadrul National Technical University of Athens (NTUA). Se ocupă cu cercetarea și dezvoltarea în diverse aspecte ale sistemelor de telecomunicații. În cadrul MOICANE centrul de cercetare a NTUA va oferi cele mai multe aplicații care vor crea mediul de Laborator Virtual.

-Tekelek Systems este un lider în industria telecomunicațiilor și concentrează activități industriale de producere de componente, echipamente și sisteme. Compania creează și livrează produse ce sunt utilizate de operatorii de telecomunicații, de providerii de servicii și alți producători ce oferă noi servicii și asigură cea mai buna calitate în transmiterea vocii, datelor și video. În cadrul MOICANE, Tekelek se va ocupa cu livrarea unor echipamente de masură.

-OTE este cel mai mare operator de telecomunicații din Grecia . OTE Research deține mai multe laboratoare pentru partea de R&D în cadrul companiei. Deasemeni, OTE Research oferă posibilitatea de a testa servicii de rețea și aplicații avansate. In cadrul MOICANE, OTE are un rol dual : oferă utilizatori acestor servicii și aplicații avansate , dar și susține infrastructura pentru experimentele de QoS pentru serviciile de bandă largă bazate pe protocolul IP.

-ROMTELECOM este operatorul public național în România și are drepturi exclusive pentru oferirea serviciilor de voce pâna la liberalizarea pieței la 1 ianuarie 2003. În prezent, este în faza de restructurare care o va duce către transformarea dintr-o companie de stat într-o companie de telecomunicații competitive pe o piață concurențială. În cadrul MOICANE, Romtelecom va susține infastructura prin care vor fi evaluate serviciile de bandă largă.

-UPB (Universitatea Politehnica din Bucuresti) este cea mai veche și cea mai mare universitate tehnică din Romania. Are 12 facultăți inginerești, aproximativ 26000 de studenți și 3500 de oameni în staff-ul academic și de cercetare. În cadrul MOICANE, UPB va oferi o aplicație de e-learning și va evalua funcționalitatea acestuia prin folosirea studenților ca un test de caz.

Ideea proiectului

Proiectul țintește spre dezvoltarea unor noi metode experimentale atât in domeniul serviciilor de telecomunicații cât și în cel al noilor tehnologii avansate născute în ultima vreme. Proiectul se concentrează și va îmbunătați domeniul de design și monitorizare a unei arhitecturi complexe de telecomunicații prin folosirea unor instrumente de proiectare ajutată de calculator, metode avansate de comunicare (ca de exemplu audio sau video), instrumente de masură și sisteme de management a rețelei.

O atenție particulară va fi dată problemelor de interconectare, astfel încât managementul complexitații, eterogenității și al asigurării performanței să fie principala preocupare. Principala idee este aceea ca procesul de proiectare a rețelei să se facă printr-o exerimentare reală cu ajutorul masurăf-ul academic și de cercetare. În cadrul MOICANE, UPB va oferi o aplicație de e-learning și va evalua funcționalitatea acestuia prin folosirea studenților ca un test de caz.

Ideea proiectului

Proiectul țintește spre dezvoltarea unor noi metode experimentale atât in domeniul serviciilor de telecomunicații cât și în cel al noilor tehnologii avansate născute în ultima vreme. Proiectul se concentrează și va îmbunătați domeniul de design și monitorizare a unei arhitecturi complexe de telecomunicații prin folosirea unor instrumente de proiectare ajutată de calculator, metode avansate de comunicare (ca de exemplu audio sau video), instrumente de masură și sisteme de management a rețelei.

O atenție particulară va fi dată problemelor de interconectare, astfel încât managementul complexitații, eterogenității și al asigurării performanței să fie principala preocupare. Principala idee este aceea ca procesul de proiectare a rețelei să se facă printr-o exerimentare reală cu ajutorul masurătorilor, simulărilor cu ajutorul calculatorului și monitorizării sistemului. Acest lucru va permite inginerilor adoptarea unui mod teoretic mai avansat de conducere a unei rețele complexe in condiții reale.

Cu ajutorul analizoarelor de protocol, a instrumentelor de management si a simulărilor unor evenimente va fi posibil de descoperit adevăratul comportament al unor elemente dintr-o arhitectură complexă de interconectare. Acestea pot fi alcătuite din componente IP peste ATM (MPOA, IP peste ATM clasic), componente IP conform arhitecturilor Integrated Services (IntServ) sau Differentiated Services (DiffServ), rețele locale (LAN) sau integrarea rețelelor fixe cu rețelele mobile (Bluetooth sau IEEE 802.11b). În particular, sunt acoperite problemele de garantare a unui bine definit QoS peste aceste diferite rețele.

Proiectul incearcă să atingă următoarele ținte:

a) să realizeze o activitate de cercetare spre identificarea a noi soluții pentru transportul informației multimedia într-un scenariu de rețea ce trebuie să suporte aplicații de Laborator Virtual și E-Learning.

b) să implementeze noi componente pentru controlul traficului in rețelele cu comutare de pachete în stare sa suporte QoS adecvat pentru serviciul de Laborator Virtual.

c) sa dezvolte o interfață simplă si prietenoasă pentru o rețea complexă, cu multe opțiuni pentru diferitele tipuri de utilizatori.

Un aspect fundamental este studiul arhitectural si implementarea unei rețele cu comutație de pachete. Cu alte cuvinte, esența proiectului va fi dezvoltarea unei infrastrucuri de rețea capabilă să susțină necesarul de resurse pentru o aplicație de laborator virtual. De asemenea, din cauză că este realizat pe surse dezvoltate liber și este conform standardelor IETF, proiectul va oferi perfectă transparență pentru funcțiile diferitelor componente.Implementarea componentelor de rutare va da posibilitatea de a vizualiza performanțele acestora prin intermediul acestei interfețe prietenoase, arătînd astfel comportamentul in timp real al echipamentelor, evidențiind particularitațile fiecarui tip de rețea (policing, scheduling, discarding, shaping).

Una dintre problemele fundamentale este intr-adevăr lipsa informațiilor detaliate despre diferitele standarde, mai ales in ceea ce privește controlul traficului ca de exemplu controlul admisiei sau scheduling. Aceste funcții sunt in măsură să realizeze managementul de trafic diferențiat în special în cazul „per-single-micro-flow control” pentru IntServ sau „aggregated traffic” pentru DiffServ peste „backbone”-ul rețelei.

Infrastructura rețelei va fi realizată prin interconectarea mai multor insule eterogene unde componentele dezvoltate în proiect vor funcționa. Aceasta infrastructură va fi prezentată ca un exemplu de rețea de generație următoare capabilă să susțină o calitate a serviciului la nivel IP. Din punct de vedere al sistemului, nu va fi posibilă doar o monitorizare a sistemului doar din punct de vedere managerial, ci se vor putea vedea și funcțiile mai detaliate (policing sau scheduling). Acestea vor fi comparate cu simulările regizate pentru a da răspunsurile la întrebările date de simulări.

Obiectivele proiectului MOICANE

Proiectul MOICANE este organizat în mai multe faze care încep de la analiza utilizatorilor și a cererilor asupra sistemului și se termină cu analiza masurătorilor de rețea efectuate cu ajutorul testelor. Considerând toate aspectele complexe ce pot apărea în ficare fază, se poate face o întreagă cercetare pe acest subiect. Din acest motiv, in speranța de a evita efortul ne-necesar, ținta proiectului este aceea de a atinge câteva obiective, pe care le preyint în continuare.

Obiectivul 1 : Cooperarea pentru experimente la distanță

O cercetare plină de succes în domeniul tehnologiei rețelelor nu se poate realiza decât prin interacțiunea constantă dintre participanții la cercetare: universități, institute de cercetare, producătorii de echipamente de rețea si operatorii de rețea. Această interacțiune va permite tuturor participanților la proiect să cunoasca diferitele contribuții ale celorlalți cum ar fi : analize teoretice, suport pentru simulare, experiența în exploatare, echipamente sofisticate, etc. Lărgind scopul acestei interacțiuni, incluzând actori distribuiți în întreaga lume, în temeiul unui nou „laborator virtual”, va fi o piatră de temelie pentru avansarea comunității științifice .

Sinergia bazată pe conceptul de „ laborator virtual ” și rezultatul de „colaboratori legați in rețea” va adăuga noi necesități pentru rețelele de azi. În primul rând, va fi nevoie puternică de tehnologii de acces variate și flexibile (fixe, mobile, radio) cu scopul de a extinde serviciul către un grup cât mai larg de participanți. În al doilea rând, capabilitățile de trransport ale backbone-ului va trebui modificat pentru a suporta traficul necesar diferitelor servicii.

Aceste necesități sunt cerute de prezența in cadrul proiectului a unor producători industriali și a unor instituții academice care doresc să transmită informație multimedia în timp real și să permită tele-operații pe echipamente de laborator sofisticate și scumpe. Aceasta conduce efectiv la un laborator virtual și va permite efectuarea de teste extrem de reale. Multumită testelor distribuite ce se execută pe echipamente ce suportă garantarea calității, va fi posibil să se dezvolte aplicații și servicii ce cer în mod expres un anumit QoS. Aceste servicii vor include: MPEG-2 video streaming, video-conferință, și laborator virtual. Ultimul va permite operații la distanță și va face posibilă împărțirea echipamentelor între institutele de cercetare implicate în proiect. În particular, testarea rețelei și echipamentele de masură în diferitele insule vor fi făcute accesibile și celorlalți participanți, fie prin intermediul „remote protocols” (ca de exemplu: X protocol), fie prin intermediul unor interfețe. (web based sau stand alone). Acolo unde este posibil, aplicațiile vor exploata deja rezultatele si dezvoltările unor experimente europene mai vechi. În al treilea rând, utilizatorii vor fi invitați să experimenteze și să-și exprime părerea despre calitatea serviciului.

Succesul acesui obiectiv constă în dezvoltarea și extinderea aplicațiilor de tip „network collaborator” precum și testarea lor local (adică în cadrul insulei ) precum și global. Ținta acestui obiectiv este mai degrabă funcționarea aplicațiilor și fiabilitatea serviciilor decât funcționalitatea rețelei.

Obiectivul 2 : Extinderea diferitelor tehnologii de acces (ce suportă QoS) și analiza interacțiunii cu „core”-ul rețelei.

Printre protocoalele de rețea de azi, cele mai întâlnite aparțin familiei de protocoale TCP/IP. Prezența lor în milioane de computere în întreaga lume a condus la folosirea lor în aproape orice echipament de rețea ceea ce mai departe conduce la ideea ca noile rețele vor trebui gândite si proiectate astfel încât noile aplicații si servicii vor rula pe gazde IP fixe sau mobile și vor fi interconectate prin Internet sau secțiuni din el.

Totuși, un viitor scenariu în viitorul apropiat va fi creat din terminale TCP/IP conectate la un backbone IP prin diverse tehnologii de acces oferind servicii bazate pe protocolul IP. Exemple de noi aplicații ce folosesc o lărgime de bandă mare: transfer de fișiere mari (Large File Transfer), distribuție audio sau video, conferințe video sau audio, telefonie IP, sau alte aplicatii interactive sau în timp real. Capacitatea rețelelor de acces sau „core” de a trata bine traficul generat de aceste aplicații (având in vedere cererile asupra resurselor rețelei, ca lărgime de bandă sau întârziere ) înseamnă asigurarea unei calități a serviciului. Fiabilitatea unei rețele „core” capabilă sa asigure QoS cerut este primul pas înspre interconectarea rețelelor de acces și înspre asigurarea serviciilor catre utilizatorii finali.

Proiectul MOICANE va evalua modele arhitecturale, protocoale și mecanisme propuse în Research Networks pentru a crea o rețea „core” flexibilă capabilă să interconecteze excelent rețele de acces QoS-capabile în sensul unei foarte bune combinații între ele.

Integrarea tehnicilor de acces eterogene, testate intr-un mediu cu aplicațiii reale va permite o analiza profundă a interacțiunii între servicii, partea de acces a rețelei si partea centrală (core) a ei. Insulele periferice ale rețelei vor fi bazate pe tehnologii de acces diferite. Tehnologiile de acces fixe vor fi : Ethernet LAN, xDSL și fibră optică. Tehnologiile de acces radio vor fi : Bluetooth, IEEE 802.11b și satelit. Multe dintre problemele de QoS sunt prezente în partea de acces a rețelei: proiectul MOICANE va fi concentrat asupra examinării și propunerii de soluții pentru aceste probleme, pentru fiecare tehnologii implicate și testate. Concluziile acestei activități vor contribui la elaborarea standardelor.

Succesul acestui obiectiv constă în definirea metodologiilor pentru proiectarea și realizarea serviciilor, a rețelei de acces și a centrului rețelei pentru atingerea calității serviciilor pentru fiecare dintre rețelele de acces pe o rețea centrală IP. Rezultatul cheie este integrarea fără probleme a rețelelor de acces si centrală cu obținerea parametrilor de QoS ceruți.

Obiectivul 3 : Setarea insulelor autonome capabile să suporte QoS și interconectarea lor

Proiectul MOICANE este alcătuit din câteva insule, autonome una de cealaltă în ceea ce privește administrarea, localizarea geografică si arhitectura de rețea. Infrastructura rețelei ce suportă QoS trebuie să fie testată într-un mediu local prima dată, cu scopul ulterior de a evalua local modelul ales de QoS. Fiecare insulă va fi constituită din unul sau mai multe domenii DiffServ, iar unele pot include o integrare între un subdomeniu DifServ și un domeniu IntServ. În ceea ce privește domeniiile IntServ, vor fi folosite rezultatele despre acest model din proiectele europene deja dezvoltate.

O data ce insulele au fost setate și operează corect ca entități autonome, ele vor fi interconectate prin linii de înaltă viteză acolo unde este posibil, prin legături cu satelitul sau, altfel, prin Internet. Atunci, interacțiunea lor va fi testată în sensul de a asigura că garanțiile de QoS suportate de fiecare insulă se păstrează la traversarea unui sau mai multor domenii (în cazul mediilor pure DiffServ), sau la traversarea de la o insulă IntServ la o insulă DiffServ în cazul mediilor mixte. Domeniile DiffServ vor constitui backbone-ul rețelei. Deoarece vor exista cazuri în care vor exista insule în care vor co-exista cele două domenii (IntServ și DiffServ), va fi necesar să se dezvolte și sî se integreze echipamente care sa cunoască cele două arhitecuri ce suportă QoS.

În toată dezvoltarea proiectului se vor face activități de măsură detaliate folosind o întreagă suită de probe ale hardware-ului pentru caracterizarea traficului, monitorizarea QoS și managementul rețelei. Caracterizarea traficului este necesară pentru dimensionarea adecvată a serviciilor și a capabilităților de QoS. O atenție specială va fi acordată caracterizării traficului produs de rețelele de acces și injectat în backbone-ul rețelei. După dimensionarea corectă, QoS-ul oferit pentru trafic, care eventual se traduce prin nivelul de caliate oferit utilizatorului final, are nevoie de o monitorizare foarte atentă. Aceasta este o activitate-cheie în procesul final de validare și fixare a rezultatelor atinse. În final, probe detaliate ale status-ului rețelei permit un management flexibil și eficient.

Succesul acestui obiectiv constă în :

dezvoltarea și testarea plină de succes în fiecare insulă a tuturor modulelor pentru asigurarea QoS și dimensionarea eficientă a elementelor de rețea în termenii dimensionării bufferelor, algorimilor de planificare, alocarii bandei, schemelor de control al accesului,etc

verificarea ca garantarea QoS cap-la-cap să se mențină la traversarea diferitelor insule.

Obiectivul 4 : Extensia către utilizatori bussines și rezidențiali

Arhitecura MOICANE este compusă din cîteva insule transparente ce susțin QoS interconectate prin intermediul unei rețea „core”. Ar fi deci foarte posibil de extins către utilizatorii rezidențiali și mai ales către cei bussines.În aceste medii sunt chiar ușor de implementat un număr mare de tehnologii de acces care trebuiesc setate QoS-capable.

Un caz foarte comun este Internetul, unde numeroși utilizatori sunt împrăștiați pe tot globul și sunt conectați la rețeaua centrală prin intermediul a multe tehnologii de acces (de exemplu: xDSL, modem de cablu, radio, satelit). Este foarte profitabil să faci disponibile aceste servicii pentru acest tip de utilizatori. Exploatarea extensiei geografice a rețelei, operarea de la distanță și opțiunile de mediu virtual consituie un foarte relevant „plus” al acestui proiect. De exemplu, serviciul de „tele-working” permite utilizatorilor să fie independenți de locația biroului, iar serviciul de „virtual classroom” ceează un mediu de învățământ distribuit, unde studenții și profesorii pot asculta/ține cursuri fără să fie nevoiți să se deplaseze la universitate.

Desigur, setul serviciilor cerute rețelei pot fi parțial diferite, dar cea mai mare parte a consideraților și rezultatelor despre infrastructura rețelei rămân aplicabile. Mai mult, noi servicii pot fi parțial extinse din cele propuse de proiectul MOICANE.

Calitatea seviciului(Quality of service) – QoS

În acest capitol voi face o scurtă descriere a conceptului de „Calitate a serviciului” prin câteva definiții, specificații, parametri caracteristici relevanți și câteva modele de arhitecturi ce pot asigura această atât de dorită calitate a serviciului. Mai multe tipuri de modele de arhitecturi de QoS pot fi cerute și utilizate întrr-o singură rețea cu scopul de a satisface nevoile unui serviciu cerut de către un utilizator. Din cauza importanței testelor și măsurătorilor actualului nivel de QoS suportate de rețeaua în cauză voi introduce în cele ce urmează și câteva considerații generale legate de teste.

Ce este Calitatea serviciului ?

Deși conceeptul de „calitate a serviciului ” este un concept intuitiv, el a fost definit de către ITU-T în recomandarea E.800 după cum urmează : „efectul colectiv al performanței unui serviciu care determină gradul de satisfacție al unui utilizator al acelui serviciu” sau „măsura a cât de bun este un serviciu, prezentat unui client, se exprimă în limbajul înțeles de client și se manifestă printr-un număr de parametri , toți acești parametri având atât valori obiective cât și subiective ”. Definițiile de mai sus sunt simple și foarte ușor de înțeles, însă uneori este greu de determinat cât de mult reflectă ele ceea ce se vrea cu adevărat de la o rețea. Mai mult, a realiza aplicații conforme unor parametri subiectivi poate fi foarte complicat datorită perceptiilor diferite asupra rezltatului acelor aplicații.

Din aceste motive, organizațiile de standardizare și cercetătorii in domeniul rețelelor au depus un efort considerabil pentru căutarea și schematizarea perspectivei utilizatorilor asupra cererilor pentru o rețea. Rezulatele esențiale oferă o opinie subiectivă despre un set ipotetic de teste pentru utilizatori în ceea ce privește satisfacția unui serviciu (de exemplu vizionarea unui film sau ascultarea unei piese de muzică ) care de fapt depinde de câteva aspecte legate de rețea. S-a definit astfel de către ITU-T în Rec. P 800 o scară numită Mean Opinion Scale (MOS), definită prin asignarea unei opinie subiective a unei note pe o echivalență calitativă.

Necesitățile și parametrii QoS

Cadrul QoS descris de ITU-T în Rec. I 350 oferă un număr de idei de bază pentru specificarea parametrilor QoS relative la aspectele de la nivelul unei rețele. În primul rând, ITU-T Rec I 350 distinge între două tipuri de parametri : primari și secundari.

Un parametru primar al QoS este determinat pe baza directelor observări ale „evenimentelor” în punctul de interacțiune ;

Un parametru secundar al QoS poate fi determinat în funcție de alți parametri, în prealabil definiți ca parametri QoS .

Pentru un serviciu de telecomunicații, parametrii primari ai calității serviciului pot fi clasificați folosind o matrice 3×3. Astfel, o rețea generală este descrisă ca fiind un sistem capabil să ofere 3 funcții generice:

Acces (la serviciile rețelei)

Transferul informației

Deconectarea

Matricea 3×3 introdusă e ITU-T Rec. I 350 mai definește 3 criterii pentru caracterizarea a cum sunt realizate aceste funcții.

Criteriul viteză caracterizează performanțele legate de timp ale atributelor QoS asociate cu o anumită funcție. Parametrii de viteză sunt definiți pe baza statisticii făcute pe seturi de „timpi de durată”.

Acuratețea caracterzează gradul de corectitudine cu care o funcție dată este realizată. Parametrul acuratețe este definit pe baza procentului de realizări incorecte din numărul de incercări totale sau pe baza ratei de realizări incorecte în timpul unei perioade de observație.

Dependența caracterizează gradul de realizare a unei anumite funcții. Parametrul dependență este definit pe baza procentului de erori din numărul total de încercări sau pe baza ratei de erori în timpul unei perioade de observație.

Considerând doar funcția de transfer de informație, parametrii primari fundamentali ai calității serviciului sunt: lărgimea de bandă, rata erorilor, intârzierea și jitter-ul. Lărgimea de bandă reprezintă numărul de biți pe secundă care sunt transmiși cu succes prin rețea. Rata erorilor poate fi împărțită în patru termeni diferiți: transmisii duplicate, recepționare în ordine greșită, eronarea unor biți și pierderea de pachete; considerând un posibil disponibil mecanism de control al fluxului și cererile unei aplicații tipice (de exemplu întârzierea cap-la-cap maximă) rata erorilor poate fi considerată echivalentă cu rata pierderilor de pachete. În general, efectul acestor pierderi de pachete în percepția calității depinde de posibilitatea de aplicare a unui algoritm de compresie și rata de compresie oferită. Întârzierea cap-la-cap este întârzierea pe care o capătă pachetele transmise de o aplicație de la capătul de transmisie la capătul de recepție stăbătând rețeaua; este compusă din trei termeni: întârzierea de transmisie, întârzierea de propagare și întârzierile din cozile de așteptare. În aplicațiile de timp real interactive rata erorilor end-to-end și jitter-ul pot fi reduse prin introducerea unor extra-întârzieri; aceste extra-întârzieri afectează timpul de răspuns în timpul unei sesiuni interactive (care poate include voce și video), așa încât trtebuie să se impună reguli foarte stricte în cea ce privește întârzierea cap-la-cap introdusă de rețea. Jitter-ul reprezintă variația întârzierii cap-la-cap și poate fi introdusă de toate componentele unui sistem cap-la-cap ; oricum, el poate fi parțial redus prin introducerea la recepție a bufferelor. Capacitaea bufferelor la recepție este în general de ordinul a zeci de microsecunde așa încât poate fi compensată doar o mică parte din jitter. Diferite aplicații pot avea cereri diferite penru lărgime de bandă, pierderi de pachete, întârziere sau jitter. De exmplu, aplicațiile de voce au nevoie de întârzieri mici și pot tolera doar o rată minimală de pierderi de pachete. Pe de altă parte, un serviciu de transfer de fișiere (FTP) poate fi insensibil la întârzieri, dar nu și la pierderile de pachete.

1.5.3 QoS calitativ și cantitativ

Calitatea serviciului poate fi suportată la diferite nivele, depinzând atât de nevoile aplicației cât și de capabilitățile QoS ale rețelei de transport.

Prima dintre ele – nevoile aplicației – se referă doar la caracteristicile specifice ale aplicației implicate și tipiul de mediu, de exemplu aplicațiile de timp real au cereri foarte înalte de întârzieri și jitter, în timp ce trtansferul de mari fișiere cer doar o lărgime de bandă mare și puține pierderi de pachete. Cea de-a doua – capabilitățile rețelei de transport – este dată în special de modelul arhitectural ales. Așa cum am mai menționat, arhitectura IntServ poate suporta nivele de calitate foarte detaliate, iar arhitectura DiffServ poate oferi servicii de calitate la un nivel agregat, ceea ce îl face scalabil și deci mai potrivit pentru nevoile rețelei backbone.

Într-un model de QoS, tipuri diferite de calitate a serviciului pot fi adresate: absolut, relativ și proporțional.

Calitatea serviciului absolută poate fi deterministă sau statistică; în primul caz, un set de parametrii ai calității sunt garantați pentru toate pachetele unei aplicații anume, iar în cel de-al doilea caz, același set de parametri este asigurat pentru fluxul aplicației într-um mod statistic (de exemplu pentru 99% din totalul traficului). Acest tip de serviciu cere în general o alocare foarte bună a resurselor pentru traficul aplicației.

Calitatea serviciului relativă presupune că diferite clase de servicii sunt suportate, fiecare dintre ele cu un nivel de calitate care este definit mai curând într-un mod relativ decât absolut. Aceasta înseamnă că serviciul oferit de o aplicație folosind o anumită clasă de servicii nu este strict garantat, însă, statistic, este mai bun decât același serviciu folosind o altă clasă de servicii. Deasemenea, în acest tip de model QoS, o alocare a resurselor pentru diferitele clase de servicii este obligatorie, dar rezervarea este determinată într-un mod relativ, pentru a nu sigura garanții absolute QoS aplicațiilor.

Calitatea serviciului proporțională presupune ca nivelurile de servicii pentru fiecare clasă de servicii sunt definite într-un mod strict proporțional; astfel suma de resurse alocate pentru fiecare clasă este, la o primă vedere, independentă de trafic. Acest model este indicat pentru rețelele care sunt configurate static și nu au nevoie să suporte o calitate a serviciului prea bună.

Într-o infrastructură de rețea reală se pot suporta mai multe modele de QoS, în concordanță cu tipul de QoS cerut de aplicații și cu complexitatea rețelei. Acesta este o alegere relevantă și va fi cercetată și investigată de-a lungul proiectului MOICANE.

1.5.4 Nevoia de a măsura QoS

Funcțiile de acces, de transfer al informației și de deconectare ce trebuiesc a fi suportate de o rețea de telecomunicație se pot caracteriza pe baza unor criterii axate pe viteză, acuratețe și dependență. Toate aceste criterii cer un exact proces de măsurare cu scopul ulterior de dezvoltare a lor.

Procesul de măsurare este obligatoriu pentru a colecta valori cantitative ale unei structuri de rețea operațională cu scopul de a determina parametri secundari QoS relevanți; astfel se poate caracteriza complet funcționalitatea pe criteriile stabilite anterior. Alte considerații și informații pot fi produse și extrase despre rețea, de exemplu prin cercetarea documentației echipamentelor folosite sau prin analiza efectelor combinate a modelului de QoS ales. Rolul testării în mediu real rămâne de fapt principalul mod de a valida experimentul cu privire la cererile proiectului și obiectivele atinse.

În definiția procesului de măsurare, este foarte important de selectat ce statstici se colectează, in care puncte ale rețelei se analizează și când și cât timp se măsoară. O măsurătoare poate fi de două tipuri : intrusivă și neintrusivă; în cel de-al doilea caz, procesul implicat în măsurătoare nu este transparent funcționării rețelei. Oricum, o măsurătoare intrusivă este necesară atunci când trebuiesc create condiții specifice pentru a putea face alte măsuratori posibile sau pentru a corecta puțin parametrii ce nu reies direct din măsurătoare. Un caz ar putea fi de exemplu descoperirea unei probleme introduse de o rețea de acces in ceea ce privește traficul injectat cu un anumit profil.

1.5.5 Ce este un testbed ?

Un testbed este o platformă de mediu utilizată pentru exploatarea, testarea și validarea unui aspect al unei rețele sau a unui model de arhitectură de rețea cu privire la un set de servicii specific. Este foarte important să se definească foarte bine și să se construiască platforma de testbed deoarece de corectitudinea, consistența și fiabilitatea sa depind rezultatele și concluziile despre problemele ce trebuie rezolvate.

Câteva elemente sunt trebuincioase pentru a completa specificațiile unui testbed, cum ar fi echipamentele de rețea ce se folosesc, stiva de protocoale suportate si tehnologiile ce se folosesc.

Selecția măsurătorilor relevante ce trebuiesc adunate și analizate este de asemenea esențială ca și locurile din care se culeg sau condițiile în care se adună aceste valori. Procesul de măsură trebuie să fi definit și executat cu un anumit nivel de detaliere. Tipul măsurătorii poate fi atât intrusive cât și neintrusivă funcție de caz și poate fi colectată împreună cu probe din echipament sau la nivelul de aplicație. Posibilitatea de a utiliza generatoare de trafic configurabile permite o mai mare flexibilitate în realizarea procesului de măsură.

În proiectul MOICANE, realizarea unui testbed în cadrul proiectului pilot este o chestiune fundamentală. Va fi acordată o atenție sporită definirii întregii platforme de teste, procesului de măsură, echipamentelor ce vor fi folosite drept probă, setului de generatoare de trafic si modelelor de trafic pentru aplicațiile implicate.

Nevoia de servicii cu garantare a calității

1.6.1 De ce servicii cu garantare a calității ?

Istoric, serviciul de bază suportat de o rețea cu comutație de pachete a fost serviciul „best-effort”. Acest tip de serviciu nu oferă garanție pentru fluxurile ce circulă prin rețea. Simplu, cel mai bun tratament este aplicat fluxurilor exploatând potențialul resurselor disponibile.

Acest mod de operare este convenabil pentru aplicațiile tradiționale ca Telnet, FTP, și, cu oarece extensii, WWW. Ar fi cu totul de neacceptat pentru noile aplicații ce caracterizează scenariile din rețelele de telecomunicații de astăzi, în care garantarea transmisiei informației este critică. Un număr din ce în ce mai mare de aplicații cu valori adăugate se așteaptă să se dezvolte în viitorul apropiat, făcând o prioritate suportarea calității serviciului de către o rețea. Aceste servicii multimedia exprimă trendul, direcția în care se dezvoltă domeniul telecomunicațiilor.

Integrarea într-o singură aplicație a video-ului sau audio-ului, de exemplu, pe lâangă date reprezintă o realizare cheie în evoluția rețelelor și în globalizarea lor. Serviciile care au nevoie de garantarea unei calități a serviciului înglobează în cele mai multe cazuri transmisii de fluxuri video sau audio. Pentru a menține calitatea cap-la-cap cu care utilizatorii sunt obișnuiți în utilizarea obișnuită, zilnică, trebuie ajuns la puternice condiții impuse rețelei în cea ce privește întârzierea, jitter-ul și pierderea de pachete.

Proiectul MOICANE exploatează potențialul unui subset de aplicații cu valoare adaugată cu scopul de a arăta, de a sublinia interesele din domeniul telecomunicațiilor de astăzi.

1.6.2 De ce o rețea integrată ?

Proprietățile QoS dau posibilitatea managerizării eficiente a traficului peste infrastructura unei rețele. Acum câțiva ani, companiile construiau și operau rețele diferite pentru traficul de voce, video, date secrete și date nesecrete. Vocea și videoul tradițional utilizau infrastructuri de rețea cu comutație de circuite. Traficul de date secrete era suportat de o rețea principală mai „evoluată”, în timp ce traficul non-secret era suportat de rețele locale (LAN) și de rețele de arie largă (WAN) într-un model de tip client-server.

În anii care au urmat, o dată cu nevoia de integrare a acestor noi aplicații din ce în ce mai complexe pe aceeași infrastructură, soluțiile de rețea au migrat din zona comutației de circuite către tehnologia comutației de pachete. Aceasta s-a datorat în principal avansului rapid în domeniul rețelelor de date mai ales în ce privește flexibilitatea, fiabilitatea, performanțele și funcționalitatea. Această alegere a fost avantajată indusă și de avantajul substanțial al îmbunătățirii multiplexării statistice.

Pe scurt, suportarea calității serviciului înseamnă a face posibilă un set de mecanisme care dau administratorilor de rețea abilitatea de a controla lărgimea de bandă, întârzierea, jitterul și pierderile de pachete prin rețea cu scopul de a oferi noi servicii cu valoare adăugată, de a defini diferite niveluri de calitate pentru diferite aplicații si organizații și de a prioritiza pur și simplu traficul printr-o rețea fie ea LAN, MAN sau WAN.

În zilele noastre, conceptul de integrare a rețelelor se poate extinde și către rețelele publice, caracterizate în general de diferite tipuri de tehnologii de acces și tehnologii de transport. O interconectare bună între aceste tipuri diferite de rețele, atât private cât și publice, permite creearea unei platforme de transport comune, care o dată creată, va suporta o calitate normală pentru serviciile cu valoare adăugată.

Având în vedere aceste ambiții, proiectul MOICANE, prin viziunea și obiectivele sale primare descrise mai devreme, țintește spre a da o contribuție considerabilă despre serviciiile suportate și despre experiența în acest domeniu.

1.6.3 De ce servicii bazate pe protocolul IP ?

Protocolul IP este cel mai utilizat protocol de rețea în zilele noastre. Suportând doar comunicația fără conexiune, protocolul este foarte simplu, scalabil, foarte eficient și cere nivelelor inferioare din stiva OSI să-i ofere un set limitat de servicii. Din aceste motive, în ultima decadă, acest protocol a fost adoptat peste tot în lume devenind astfel cel mai comun protocol din rețelele de date, în special în Internet.

Capitolul II – Prezentare generală a VoIP

2.1 Introducere

VoIP reprezintă abilitatea de a face convorbiri telefonice și de a trimite faxuri peste o rețea bazată pe protocolul IP ce reușeșete să asigure o anumită calitate a serviciului (QoS) și cu un raport cost/beneficii superior. Toată lumea vorbește despre VoIP și fiecare dorește o părticică din bucata cea mare :

Producătorii și dezvoltatorii de echipamente văd o oportunitate de a inova și de a concura. Acum sunt ocupați cu dezvoltarea unor echipamente ce suportă VoIP astfel încât să intre pe piață cu ele în timp.

Companiile de servicii de Internet (ISP) văd acum posibilitatea de a concura cu vechile companii de telecomunicații și în domeniul voce.

Utilizatorii sunt interesați de integrarea serviciilor de date și voce cu scopul reducerii cheltuielilor.

Deși pare foarte atractivă, tehnologia VoIP nu s-a dezvoltat în așa măsură încât să poată înlocui cu succes serviciile și calitatea oferite de vechea rețea PSTN. În primul rând trebuie să fie clar că tehnologia VoIP va fi într-adevăr mai eficientă. Pentru a concura cu vechea rețea PSTN , întregul cost al operației de trecere către VoIP trebuie să fie scăzut.VoIP provoacă panică în rândul providerilor actuali de servicii telefonice, care vor reacționa prin scăderea prețurilor și îmbunătățirea propriilor servicii.

O altă aplicație imediată pentru telefonia IP va fi transmisia în timp real de fax-uri. Calitatea transmisiei fax este periclitată în general de întârzierile din rețea, compatibilitatea echipamentelor și calitatea semnalului analogic. Pentru transmisia de fax peste rețelele cu comutație de pachete avem nevoie de o interfață pentru conversia datelor sub formă de pachete, pentru conversia semnalizărilor și a protocoalelor de control și pentru a asigura transmisia datelor scanate în perfectă ordine. Pierderile de pachete și întârzierea cap-la-cap este mai critică decât în cazul aplicațiilor de voce.

Multe alte aplicații au fost gândite pentru a fi implementate de telefonia peste IP. De exemplu, mesajele de voce pot fi făcute folosind un telefon și apoi livrat unei căsuțe integrate voce/date folosind serviciile Internet sau intranet. Documentele de voce, fișierele multimedia pot deveni în scurt timp standarde pentru munca la birou în viitorul apropiat.

Principalele motive pentru dezvoltarea telefoniei peste IP pot fi rezumate astfel :

Reducera costurilor : Asa cum s-a descris, vor apărea reduceri mari de cheltuieli mai ales pentru apelurile la mare distanță ceea ce este foarte important pentru companii, mai ales pentru companiile ce activează pe piețe internaționale.

Simplificarea : O rețea integrată voce/date permite o mai mare standardizare și un necesar mai redus de echipamente.

Aplicații avansate : Beneficiile pe termen lung al telefoniei IP includ suport pentru aplicații multimedia și multiservicii, ceea ce telefonia clasică actuală nu poate oferi.

Creșterea pieței VoIP se așteaptă să fie mare în următorii 5 ani. Estimările dau o creștere de aproximativ 132% pentru echipamente în perioada 1997- 2002 cu o piață de aproximativ 3,16 miliarde dolari în 2002. Beneficiile anuale din partea echipamentelor de fax în 2000 au ajuns la 100 milioane dolari față de 20 milioane în 1996.

2.2 Elementele unei rețele VoIP

Serviciile de telefonie IP trbuie să fie în stare să se conecteze la rețelele tradiționale bazate pe comutația de circuite. ITU-T a realizat această problemă definind H.323, un set de standarde pentru rețelele multimedia bazate pe comutația de pachete. Elementele de bază ale unei rețele H.323 sunt terminalele H.323 ca telefoanele tip PC sau telefoanele existente deja conectate la ISDN, PSTN sau wireless, gateway-uri ca interfață între rețeaua locală la care sunt conectate terminalele și rețeaua cu comutație de circuite, gatekeeper ce are funcții de control al admisiei și MCU (Multipoint Control Unit ) ce oferă conferințe între trei sau mai multe terminale. Aceste entități vor fi discutate în cele ce urmează.

Terminale H.323

Terminalele H.323 sunt terminale de tip LAN pentru transmisia vocii. Exemple comune de astfel de terminale sunt calculatoare personale ce rulează Microsoft NetMeeting și au un microfon de rețea.

Terminalele H.323 implementează funcții de transmitere a vocii și cu siguranță includ cel puțin un CODEC de voce (Compressor/ Decompressor) care trimite și recepționează voce pachetizată. Codecuri mai întâlnite sunt: ITU-T G.711 (PCM), G.723 (MP-MLQ), G.729A (CA-ACELP) și GSM. Codecurile diferă prin cerințele CPU-lui, prin calitatea vocii rezultate și prin inerenta întârziere de procesare.

Terminalele deasemenea trebuie să suporte funcții de semnalizare. Standardele care se aplică aici sunt : semnalizările H.225.0 care sunt un subset al semnalizărilor din ISDN (Q.931) ; H.245 care este utilizat pentru schimbul de informații între terminale ca de exemplu standardele de compresie care pot fi diferite; RAS (Registration, Admission, Status) care conectează un terminal la un gatekeeper. Terminalele mai pot implementa capabilități de comunicații video și de date, însă nu fac obiectul studiului nostru acum.

Iată în continuare diagrama blocurilor unui terminal H.323 :

Microfon

Camera

Interfața de

date

System

Control

Gateways

Gateway-urile servesc ca o interfață între rețelețe H.323 și rețelele non-H323. pe de o parte, se conectează la lumea tradițională a vocii, iar pe cealaltă parte la echipamentele ce funcționează cu comutație de pachete. Ca orice interfață, un gateway trebuie să translateze mesaje de semnalizare între cele două părți ca dealtfel să compreseze sau să decompreseze vocea. Ca un prim exemplu de gateway este gateway-ul PSTN/IP conectând un terminal H.323 la SCN (Switched Circuit Network )

IP/PSTN Gateway :

Există multe tipuri de gateway-uri astăzi în folosință, pornind de la gateway-uri cu câteva zeci de porturi analogice până la super gateway-uri cu mii de linii.

Gatekeeper

Prezența unui gatekeeper nu este obligatorie in arhitectura unei rețele H.323. Oricum, dacă este prezent, el trebuie să îndeplinească un set de funcții. Gatekeeper-ul managerizează porțiuni, zone, colecții logice de echipamente (de exemplu toate terminalele H.323 dintr-o subrețea IP). Mai multe gatekeepere pot fi prezente pentru a balansa încărcarea sau pentru a avea capabilități de hot-swap backup.

Filosofia definirii gatekeeper-elor este aceea de a permite proiectanților de rețele H.323 să separe puterea brută de procesare a gateway-ului de funcțiile inteligente de control a rețelei pe care le poate executa un gatekeeper. Un gatekeeper tipic este implementat pe un PC, pe când un gateway este adesea o platformă hardware de sine stătătoare.

Gatekeeper-ele oferă funcții de rutare pentru echipamentele din zona deservită. Aceasta poate fi, uneori, translația între sistemul de numerotație din interior și cel din exterior. O altă funcție importantă a gatekeeper-ului este controlul admisiei, specificând ce terminale pot apela anumite numere.

Printre funcțiile opționale de control ce se pot oferi de către un gatekeeper există informațiile de management SNMP.

Un gatekeeer poate participa într-o varietate de modele de semnalizare asa cum el singur stabilește. Modelele de semnalizare se referă la ce mesaje de semnalizare trec prin gatekeeper și care trec direct de la un terminal la altul sau de la terminal direct la gateway. Există două modele de semnalizare. Modelul de semnalizare directă permite ca apelurile să nu treacă prin gatekeeper, pe când în modelul de semnalizare prin gatekeeper toate mesajele de semnalizare trec prin gatekeeper și doar convorbirile se fac direct între stații.

Multipoint Control Unit (MCU)

MCU permit funcții de conferință intre trei sau mai multe terminale. Logic, un MCU conține 2 părți :

Multipoint Controller (MC) care se ocupă cu semnalizările și mesajele de control necesare conferințelor

Multipoin Processor (MP) care primește semnalele de la terminale, le multiplică și le trimite apoi către participanții la conferință.

Un MCU poate implementa ambele funcții atât ale MP cât și ale MC, caz în care este denumit MCU centralizat. Alternativ, un MCU descentralizat implementează doar funcțiile MC, lăsând funcția de multipoint processor pentru terminalele participante.

Este important de reținut definirea tuturor părților unei rețele H.323 este pur logică. Nici o specificație nu a fost dată pentru divizarea fizică a unităților. De exemplu, MCU poate fi un echipament de sine stătător sau poate fi integrat într-un terminal, gateway sau gatekeeper.

2.3 Codoare audio ( Audio CODEC)

Canalele de voce ocupă 64 Kbps folosind codarea PCM (Pulse Code Modulation) atunci când se transportă prin liniile E1. De-a lungul anilor, tehnicile de compresie s-au dezvoltat permițând o reducere a lărgimii de bandă în același timp cu păstrarea calității vocii. Aceste tehnici sunt implementate în CODEC-uri.

Deși există mai mulți algoritmi de compresie, cele mai multe echipamente H.323 de astăzi utilizează codecuri ce au fost standardizate de ITU-T pentru o buna interoperabilitate între producătorii de echipamente. Aplicații ca NetMeeting utilizează protocolul H.245 pentru negocierea folosirii unui codec în concordanță cu preferințele utilizatorului și cu codecurile instalate. Diferiții algoritmi de compresie pot fi comparați folosind patru parametri :

Rata de compresie a vocii – codecurile compresează vocea de la 64 Kbps până la o valoare mai scăzută. Unele proiecte de rețea au o mare preferință pentru codecurile cu rată scăzută(low-bit-rate codec). Cele mai multe codecuri pot folosi mai multe rate de compresie cum ar fi 8, 6.4 și chiar 5,3 Kbps. De notat că această rată este doar pentru audio. Când se transmite vocea pachetizată peste rețea, overhead-ul protocoalelor (ca de ex RTP/UDP/IP/ Ethernet) se adaugă la vârful acestei rate rezultând de fapt o rată mai mare.

Complexitatea – cu cât complexitatea implementării în codec crește, cu atât mai multe resurse pentru CPU sunt necesare.

Calitatea vocii – compresia vocii în unele codecuri se face cu bună calitate, în timp ce în altele calitatea vocii suferă.

Întârzierea la digitalizare – fiecarui algoritm îi sunt necesare o sumă de sunete ce trebuiesc memorate înainte de compresie. Această întârziere se adaugă întârzierii cap-la-cap. O rețea cu o întârziere cap-la-cap excesivă adesea face utilizatorii să revină la o conversație half-duplex în loc de o convorbire telefonică full-duplex.

Următorul tabel va compara cele mai des întâlnite codecuri după cei patru parametri

În practică, G.723 și G.729 sunt mai folosite decât G.726 și G.728.

2.4 Stiva de protocoale a H.323

Stiva de protocoale arataă ca în figură :

Mesajele de control ( semnalizarea Q.931, negocierea parametrilor H.245 și protocolul RAS ) se transportă peste nivelul TCP. Aceasta asigură ca mesajele importante să fie cu siguranță transmise. Traficul de media este transportat de către mai puțin sigurul protocol UDP și include 2 protocoale definite de ITU-T în RFC 1889: RTP (Real Time Protocol) care transportă chiar informația și RTCP (Real Time Control Protocol) care transmite mesaje periodice de control și de stare. Informația este transportată de UDP deoarece nu ar avea sens să fie retransmisă (asa cum ar proceda TCP de exemplu) : pierderea unui fragment de sunet dacă ar fi retransmis, el probabil ar ajunge prea târziu și nu ar mai putea fi folosit la reconstruirea vocii. Mesajele RTP sunt transmise pe porturile UDP impare, iar cele RTCP pe cele pare imediat alăturate.

Capitolul III-VoIP în rețeaua MOICANE

3.1 Arhitectura proiectului

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).

3.1.1 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 :

3.1.2 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.

3.1.3 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 :

Checksum – sumă de control standard TCP/UDP

Length Field – lungimea headerului și cea a obiectelor care urmează

Header-ul measjului RSVP

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.

3.1.4 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.)

A. Câmpul DS

B.IP Header

Î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.

Packets

Î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.

3.2 VoIP aplicat de MOICANE

Fiind deja creată infrastructura IP legând mai multe site-uri, se poate ruta trafic de voce pe această rețea IP fără costuri suplimentare, în locul folosirii vechii rețele publice. La aceeași lărgime de bandă, compresia vocii face ca să poată fi transportate 8 convorbiri față de una singură pe rețeaua publică (din cauza overhead-ului, de fapt sunt mai puține). Suprimarea liniștii din timpul unei convorbiri va scădea în medie de 2 ori lărgimea de bandă pe WAN necesară unui canal de voce. Datele sunt transportate pe aceeași legătură ca și vocea.

3.2.1 Configurația locală (stand alone configuration)

Soluția propusă de Alcatel proiectului VoIP MOICANE este OmniPCX4400, care este un sistem structurat ca o centrala PBX tradițională dar la care se adaugă câteva noutăți aduse de diferite interfațe care suportă servicii VoIP, date și multimedia.

Reflex IP sunt telefoane dedicate VoIP conectate la OmniPCX4400 printr-o legătură ethernet. Telefoanele interacționează cu PBX prin semnalizările Universal Alcatel Access. Convorbirile sunt digitalizate, opțional compresate și apoi transmise prin rețeaua IP prin pachete RTP.

În configurația locală, avem un OmniPCX 4400 care conduce 2 zone : o zonă numită zona UAS (Universal Access Signaling) cu telefoanele Reflex IP și o zonă H.323 cu terminale ce funcționează după acest standard (exemplu NetMeeting). Utilizatorul A din zona H.323 apelează utilizatorul B din zona UAS iar OmniPCX 4400, funcționând ca un gateway de semnalizare, translatează mesajele H.323 in mesaje de semnalizare UAS.

3.2.2 Configurația pentru telefonie la distanță (WAN Telephony configuration)

Acesta este un scenariu tipic unde un mic birou este complet dependent de birourile centrale. În birourile centrale se localizează centrala OmniPCX4400 și câteva telefoane IP, iar în biroul distant sunt câteva telefoane IP complet dependente de centrala din biourile centrale.

Utilizatorul A localizat în insula MOICANE C poate conversa cu utilizatorul B aflat în insula A sau B. Fluxurile de semnalizare merg între utilizatori și centrală (faza de stabilire a conexiunii), iar fluxurile de voce merg direct între terminale (faza de convorbire).

3.2.3 Alcatel OmniPCX4400

Centralele de instituție PBX se transformă de la arhitectura centralizată tradițională spre un model client/server folosind sisteme de operare publice, protocoale publice și platforme server standardizate. Este o modalitate mai bună de a oferi integrarea informațiilor de care este nevoie astăzi. Rețeaua de date trebuie să crească și să se schimbe atunci când apar noi oportunități așa încât și aplicațiile vor crește și se vor schimba.

3.2.3.1 Arhitectura sistemului

Succesorul natural al centralelor PBX este PCX (Private Communication Exchange). Modelul Alcatel OmniPCX4400este primul sistem de această natură care este un PCX adevărat :

arhitectură client/server bazat pe UNIX

hardware și software distribuit și scalabil

mobilitate

proiectat la bază cu protocolul IP

integrare standard computer/telefonie

servicii de voce complete

Structura de bază este numită ACT (Alcatel Crystal Technology) și toate unitățile sunt interconectate și controlate de un CPU.

Fiecare legătură între elementele sistemului are o funcție, o tehnică de transmisie, o lărgime de bandă, fiecare dintre ele putând avea o viteză de până la 8 Mbps. Centrala OmniPCX4400 poate fi utilizată în configurație locală sau distribuită.

Interfețele oferite sunt :

UA (Universal Access) – conduce comunicația cu terminalele dedicate

Z – conduce comunicația cu terminale analogice

BRA (Basic Rate Access)

PRA (Primary Rate Access)

LIOE (Link Optimizer board Ethernet) – folosit pentru a crea conexiuni între sisteme H.323

TSC LIOE – similar cu precedentul, însă folosit penru telefoane IP

3.2.3.2 Descriere hardware

VoIP este realizat în centrala OmniPCX4400 de o placă ACT numită LIOE. LIOE este dedicat pentru VoIP și nu poate fi folosită ca extensie pentru alte tipuri de legături (voce compresată peste ISDN, linii închiriate, Frame Relay).

Această placă concentrează traficul de voce venind de la mai multe plăci OmniPCX4400, compresează canalele de voce, pachetizează vocea compresată și transmite pachete Ethernet către o placă LIOE din alt nod.

Pentru a face asta, LIOE este echipată cu 12 canale de compresie (din punct de vedere hardware). Capacitatea LIOE poate fi mărită la 30 de canale prin adăugarea unei plăci fiice care poate aduce încă 18 canale de voce.

Fiecare placă LIOE are o interfață Ethernet care se conectează la rețeaua locală (IP trunk group). O placă CBC1 face conectarea la LIOE printr-o interfață 10baseT (10 Mbps). Pentru o mai eficientă alocare a lărgimii de bandă(deci și a calității vocii), se recomandă ca accesul VoIP să se facă printr-un port al unui LAN Switch.

Alcatel A4400 mai are o legătură Ethernet și pentru CPU. Pentru a nu ocupa prea multe porturi în hub sau în switch, toate porturile IP ale A4400 pot fi grupate într-un singur port. Limita este de 1 sau 2 plăci LIOE plus CPU pe aceeași legătură Ethernet.

3.2.3.3 Procesarea vocii

OmniPCX4400 suportă trafic de voce și fax. Vocea poate fi compresată și faxul demodulat pentru a mai reduce din lărgimea de bandă ocupată într-o rețea IP. Sunt disponibili 3 algoritmi de compresie pentru VoIP :

G.711 (codare PCM la 64 kbps)

G.723.1 (compresie cu rată scăzută la 6,3 kbps)

G.729A (compresie cu rată scăzută la 8 kbps)

Calitatea algoritmilor de codare a vocii este evaluată de ceea ce am numit MOS (Mean Opinion Score). 5 e calitatea maximă, iar G.711 are nota 4.2, G.723.1 are nota 3,9 ca și G.729A. GSM are nota 3,5.

Datorită cererii atât de mai de lărgime de bandă a G.711, codarea PCM ar trebui folosită doar în cadrul mediului de LAN, dar nu este deloc recomandată pe WAN. Aceasta din cauza codării la 64 kbps, care prin adăugarea header-elor pachetelor IP ajunge pe la o lărgime de bandă de circa 100 kbps la nivel Ethernet (pentru fiecar sens de comunicare). Alegerea se va face deci între G.723.1 sau G729A. Acești doi algoritmi oferă cam aceleași performanțe. Implementarea G729A oferă un ușor avantaj , dar nu semnificativ în ceea ce privește întârzierile (pachetele sunt trimise cam cu aceeași rată – 30 ms). Deci G723.1este recomandat, însă G729A poate fi folosit dacă :

Clientul cere

G729A este folosit într-o altă parte a rețelei , de exemplu compresia vocii pe o linie închiriată, pentru o mai bună interoperabilitate.

Anularea ecoului este integrat datorită întârzierilor date de comppresia și transportul pe rețea.

Interpolarea cadrelor pierdute ajută la trecerea peste pierderea unor pachete de voce. Este cazul rețelelor IP unde, în cazul congestiei, cadrele se pot pierde. Dar, desigur, rata de pierdere a pachetelor nu trebuie să fie prea mare.

Pachetele de voce ale aceluiași canal se transmit succesiv prin rețea. Dar aceste pachete nu vor avea aceeași întârziere prin rețea până la atingerea recepției. Acesta este numit jitter sau variația întârzierii. Pentru a fi reasamblate și trimise la intervale regulate ascultătorului, părțile de voce in pachete sunt memorate într-un buffer al plăcii LIOE a recepției. Aceasta va introduce o întârziere suplimentară

Dacă jitterul e mic, ceea ce e un semn că rețeaua merge bine, bufferul e mic și deci și întârzierea e mică. Dacă jitterul e mare, bufferul va fi mai mare, și deci și întârzierea din buffer. Jitterul de mărime variabilă va perimte evitarea introducerii de întârzieri atunci când rețeaua merge bine. Există un buffer pentru jitter pentru fiecare direcție. Aceasta înseamnă că dacă avem pachete recepționate de la A cu jitter mare și pachete recepționate de la B cu jitter mic, întârzierea din cauza bufferului la apelarea de la B nu va suferi din cauza jitterului de la A.

Detecția de voce, suprimarea liniștii și regenerarea liniștii trimite cadre de voce doar atunci cînd părțile vorbesc și nu va trimite nimic atunci când utilizatorii nu vorbesc. Aceasta înseamnă că in jurul a 50 % din timp (ceea ce se traduce în bandă) este salvat si realocat altui trafic, de exemplu date.

Pentru a evita faptul ca cei doi utilizatori să creadă ca linia moartă în timpul liniștii, liniștea e regenerată la celălalt capăt.

Suprimarea liniștii permite limitarea lărgimii de bandă medie cerută de Ethernet pentru un canal de voce. Desigur, dacă un apel nu e satisfăcut, nu va exista cerere de bandă la nivel Ethernet.Aceasta înseamnă că lărgimea de bandă este și mai mică, de obicei 0.7 E la orele de vârf.

Se oferă deasemenea pierderi mici pentru traficul de tranzit, adică se dorește a avea doar o comprimare și o decomprimare a vocii chiar dacă apelul tranzitează mai multe A4400. Normal, acest lucru nu se petrece într-o rețea IP care, spre deosebire de o rețea orientată (Frame Relay sau ATM) este any-to-any și nu trebuie să tranziteze PBX-uri decât în cazul unor foarte mari rețele.

3.2.3 Suportul H.323

A4400 este conformă cu H.323 în ceea ce privește telefonia. OmniPCX4400 este un VoIP gateway în terminologie H.323.

Deoarece A4400 este un gateway , el permite terminalelor ca de exemplu PC-uri să transmită sau să recepționeze apeluri VoIP spre sau de la terminale A4400. PC cu capabilități de VoIP este un PC cu capabilități audio și cu un client H.323, ca de exemplu Microsft NetMeeting sau Netscape Communicator. Pentru apelurile dinspre A4400 către PC, A 4400 are o tabelă care translatează numărul de telefon (E164) al PC-ului către adresa IP a PC-ului. Dacă avem prezent și un gatekeeper în rețea, A4400 poate fi client al gatekeeper-ului. Aceasta înseamnă că tabela E164 către IP nu este folosită : pentru fiecare apel, A4400 cere adresa IP a PC-ului de la gatekeeper. Gatekeeper-ul este cel care menține tabela „E164 către IP”.

Pentru apelurile de la PC către A4400, PC-ul trimite adresa IP a plăcii LIOE, urmat de numărul de telefon la care se vrea apelul.

3.2.4 Calitatea serviciului

Calitatea vocii este unul dintre problemele dintr-o rețea IP. Aceasta datorită faptului că o rețea IP nu este deterministă: spre deosebire de o rețea cu comutație de circuite, întârzierea nu e determinabilă. Calitatea vocii este foarte sensibilă la întârzieri, jitter și pierderi de pachete. Calitatea în rețelele IP depinde mai ales de rețeaua la care e conectat terminalul și nu de echipamentul VoIP propriu-zis.

Vocea cere prioritate față de traficul de date. A4400 este în măsură să eticheteze pachetele VoIP în concordanță cu protocoalele 802.1p și cu DiffServ. Aceasta va permite LAN switch-urilor și ruterelor să identifice pachetele de voce și să le dea prioritate în fața celorlalte pachete.

Pe A4400, pentru a nu deranja alte aplicații în rețea, este posibil de a limita traficul VoIP. Deasemenea, în unele cazuri, rețeaua poate fi saturată, degradând foarte mult calitatea vocii. În acest caz, pentru a asigura apelurile cu calitatea aceeptabilă.A4400 poate face apelurile folosind alte rețele la care este conectat, de exemplu ISDN.

3.2.4.1 Performanțe cerute de la rețeaua IP penru oferirea unei calități bune a vocii.

Performanțele cerute de la rețeaua IP penru oferirea unei calități bune a vocii sunt descrise în cele ce urmează, făcându-se referire la lărgimea de bandă, întârziere, pierderi de pachete.

3.2.4.1.1 Cererile de lărgime de bandă

Tabelul de mai jos arată necesarul de bandă la nivel de Ethernet pentru cele 3 tipuri de algoritmi de compresie.

Rata de transmisie înseamnă că un pachet ce conține voce este transmis la fiecare de exemplu 30 ms pe Ethernet. Cu cât acest timp e mai mare, cu atât overheadul și lărgimea de bandă scad. Cu cât acest timp e mai mic, cu atât crește calitatea vocii.

Lungimea cadrului Ethernet e dat de tabelul de mai jos.

Pentru a se obține cei 78 de bytes se adugă preambulul de 8 bytes și GAP de 12 bytes.

Lărgima de bandă Ethernet este lărgimea de bandă necesară pe interfața Ethernet a lui A4400. Această valoare e necesară pentru dimensionarea rețelei IP. Banda cerută este fără VAD (Voice Activity Detection) și pentru un singur sens (half-duplex). Aceasta înseamnă că VoIP generează un overhead mare, mărind lărgimea de bandă cerută pe interfața Ethernet.

Lărgimea de bandă WAN (cu PPP și compresia headerului) nu este o proprietate a A 4400. Pe un WAN, lărgimea de bandă poat fi redusă prin folosirea tehnicilor de compresie a headerului și PPP pe rutere (exemplu: CRTP (Compressed RTP) pe PPP). Pentru interconectarea ruterelor într-un WAN sunt folosite linii închiriate (sau Frame Relay). Protocolul de nivel 2 este PPP (Point to point protocol care este un IP pe o legătură serială) sau Frame Relay.

3.2.4.1.2 Întârzierea în rețea

Diagrama de mai jos arată percepția degradării calității vocii funcție de întârzierea din rețelele IP. Întârzierea din rețea nu ar trebui să depășească 200 ms pentru a avea o calitate acceptabilă în rețeaua privată.

Întârzierea pentru un apel de voce între 2 A4400 cap-la-cap este de 100 ms (dacă întârzierea în rețea este 0).

Dacă banda WAN este limitată, se recomandă să se limiteze dimensiunea maximă a pachetelor pentru a se evita întârzierea și jitterul.

3.2.4.1.3 Pierderile de pachete

Pierderea de pachete VoIP are un impact negativ asupra calității.

Pentru că pachetele de voce sunt transportate prin UDP (pentru viteză), pachetele pierdute nu mai sunt retransmise ca pentru TCP. Interpolarea pachetelor pierdute poate recrea pachetele pierdute folosindu-se de cele recepționate astfel încât utilizatorul să nu poată fi deranjat.

Dacă pierderile de pachete sunt mai mici decât 5%, calitatea vocii ar trebui să fie acceptabilă pentru rețelele private.

3.2.4.1.4 Prioritățile în rețeaua IP

Pentru a oferi performanțele cerute de suportul vocii, și cum mai multe tipuri de trafic se luptă pentru aceeși lărgime de bandă limitată, rețeaua IP trebuie să implementeze un fel de prioritizare a traficului. Aceasta înseamnă că pachetele de voce vor avea prioritate față de traficul mai puțin sensibil la întârzieri (E-mail, FTP, etc)

Pentru identificarea pachetelor de voce, ruterele și LAN switch-urile trebuie să se uite la header-ele pachetelor sau cadrelor. Unele echipamente foarte sofisticate pot cerceta foarte amănunțit pachetele pentru a identifica aplicația, însă LAN swith-urile cercetează doar Ethernet header-ul iar ruterele doar header-ul IP: ele nu sunt capabile de a descoperi aplicația ce generează pachetele.

Pentru a realiza aceste lucruri, câteva standarde au fost publicate :

La nivelul 2 OSI (Ethernet) 802.1p standard (asociat cu 802.1Q/VLAN)

La nivelul 3 OSI (IP) Type of Service sau DiffServ

Mulțumită acestor standarde, header-ul IP sau cel Ethernet suportă informații adiționale dând astfel prioritate. Câmpul de prioritate este completat de managerul rețelei de date (care asociază prioritate unui port, adresă IP sau echipamentului de date conectat la aplicația respectivă) sau marcat de aplicația respectivă.

Aceste informații sunt utilizate de echipamentele de date penru managementul cozilor de așteptare (Weighted Fair Queuing) și pentru renunțarea la unele pachete în caz de congestie în rețea (Random Early Discard).

Pentru a oferi o calitate superioară în rețeaua IP, A4400 este capabilă de a eticheta pachetele de voce după :

802.1p/q : A4400 adaugă 4 octeți cadrelor Ethernet. A 4400 este capabil de a marca sau nu cadrele, funcție de configurație. Pot fi configurate priorități de utilizator (cu 3 biți – valori de la 0 la 7) sau Virtual LAN (cu 12 biți). 802.1p/q este relevant doar în interiorul aceluiași LAN.

DiffServ (Differentiated Services) : Diffserv marchează câmpurile TOS (Type of Service) ale pachetului IP. Sunt disponibile 64 de valori.

Doar pachetele de voce (RTP/RTCP) și de fax sunt etichetate, nu și pachetele de semnalizare H.323 (H.245, H.225).

3.2.5 Terminalele VoIP

Alcatel IP-Phone Reflex

Familia Alcatel Reflex este o gamă completă de telefoane digitale proiectate pentru accesul Alcatel OmniPCX 4400 :

QoS : monitorizare RTCP, IEEE 802.1p/q, TOS, DiffServ

Codare și autentificare H.323 (H.235)

Telefoanele IP Reflex sunt telefoane dedicate conectate la OmniPCX 4400 prin UA (Universal Access) Interface. Comunicația între OmniPCX 4400 și telefoanele Reflex se bazează pe protocolul numit Universal Alcatel Access. Acest tip de interfață poate avea 16/32 de telefoane.

NetMeeting

NetMeeting este un pachet pentru voce în timp real și comunicații de date. NetMeeting oferă soluții complete de conferință în Internet pentru toți utilizatorii de Windows : conferințe de date multi-punct, chat, transfer de fișiere ca și audio și video punct la punct.

Conferințe audio. Această caracteristică permite realizarea de apeluri audio unu-la-unu în timp real oriunde în lume prin intermediul Internetului sau prin intermediul rețelei locale. Conferințele audio sunt realizate cu ajutorul suportului oferit de H.323. Noutățile aduse conferințelor audio prin NetMeeting 3.01 sunt acelea că se pot face apeluri folosind servere, direct din cartea de telefon sau prin addres bar, în care se scrie adresa de mail, numele calculatorului apelat, adresa IP, număr de telefon sau adresa DNS.

Conferințe video. Se poate folosi NetMeeting și pentru schimbul de imagini în timp real cu alti participanți la conferință. Această caracteristică permite conexiuni multiple folosind servere și gateway-uri H.323.

Capitolul IV – Dimensionarea insulei UPB

Structura sub-insulei UPB este prezentată în Figura 4.1. Sub-insula oferă posibilitatea următoarelor tipuri de acces : ADSL, Ethernet, ATM. Sub-insula este alcătuită în principal din două rețele de acces AN1 și AN2 și dintr-un domeniu central DiffServ (DSD). Aici, am inclus gazdele din AN1 și AN2 pentru simplificarea descrierii.

4.1 Precizări preliminare

Serviciile oferite de sub-insula UPB sunt următoarele : Video Conferință (VC) și telefonie peste Internet (VoIP). Pentru aceste aplicații, traficul este simetric bidirecțional. Dimensionarea preliminară a sub-insulei UPB se bazează pe următoarele considerente.

Rutarea este configurată static, după cum urmează :

Traficul din LAN1 spre LAN2 (bidirecțional) trece prin AN1, DSD și AN2 urmând una dintre căile :

LAN1: ADSL access:

LAN1 Host – MAR1 – AN1 (DSLAM – ATMSW1 – ATMSW2) – DSD – AN2 (L2SW2) – LAN2 Host

LAN1 Host+NIC – AN1 (DSLAM – ATMSW1 – ATMSW2) – DSD – AN2 (L2SW2) – LAN2 Host

LAN1: Ethernet + ADSL access:

LAN1 Host – L2SW1 – MAR2 – AN1 (DSLAM – ATMSW1 – ATMSW2) – DSD – AN2 (L2SW2) – LAN2 Host

LAN1: Ethernet + ATM access:

LAN1 Host – L2SW1 – AN1 (ATMSW1 – ATMSW2) – DSD – AN2 (L2SW2) – LAN2 Host

Traficul din LAN1 spre LAN3 (bidirecțional) trece prin AN1, DSD și AN2 urmănd aceleași căi ca și în a, b, c până la DSD și apoi : ER1 – ER2 – TRS – AR3 – Host.

Traficul de la AN1 spre Romtelecom sub-island (și invers) poate urma căile:

AN1: ADSL access:

LAN1 Host -MAR1- AN1 (DSLAM – ATMSW1 – ATMSW2) – DSD – ER1 – ER2 – TRS – Romtelecom sub-island

LAN1 Host+NIC – AN1 (DSLAM – ATMSW1 – ATMSW2) – DSD – ER1 – ER2 – TRS – Romtelecom sub-island

Ethernet + ADSL access:

LAN1 Host – L2SW1 – MAR2 – AN1 (DSLAM – ATMSW1 – ATMSW2) – DSD – ER1 – ER2 – TRS – Romtelecom sub-island

AN1: Ethernet + ATM access:

LAN1 Host – – L2SW1- AN1 (ATMSW1 – ATMSW2) – DSD – ER1 – ER2 – TRS–Romtelecom sub-island

Figure 4-1: structura sub-insulei UPB/CCSRST

Dimensionarea preliminară se bazează pe vârful de bandă cerut în cel mai defavorabil caz.

Tehnologiile Ethernet și Fast Ethernet vor fi dezvoltate atât în IS access domain cât și în partea “core” a sub-insulei.

Overheadul data-link este estimat brutal la 5% (cel mai rău caz pentru codorul de voce G.711 ) în părțile bazate pe IP ale insulei (din cauza headerului Ethernet)

Overheadul data-link overhead este estimat brutal la 20% pentru partea de acces ADSL ( overheadul celulei ATM )

Pentru dimensionarea rețelei, doar fluxurile aplicațiilor bazate pe UDP sunt luate în considerare.

Este folosit un scenariu particular de rețea. Acest scenariu este descris în următoarea secțiune.

4.1.1 Descrierea traficului aplicațiilor

Traficul generat de diferitele gazde [1], [2], [3], [4], este estimat mai jos:

RSVP host (aplicație de Video Conferință ) – Client sau Server

64Kbps(voce) + (RTP/UDP/IP overhead) 16Kbps (cu 20 ms timpul de pachetizare) + 400Kbps(video) + (RTP/UDP/IP overhead) 5Kbps: Rate1VC = 485 Kbps

DS Host (aplicație de Video Conferință) –Client sau Server

Rate1VC = 485 Kbps, sau

6.3Kbps(voce) (RTP/UDP/IP overhead) 16Kbps (cu 20 ms timpul de pachetizare) + 200Kbps(video): Rate2VC = 222 Kbps (rezoluție mai slabă)

Telefonul ALCATEL IP REFLEX

Codec G.711: 64Kbps + (RTP/UDP/IP overhead) 16Kbps (cu 20 ms timpul de pachetizare): Rate1VoIP = 80 Kbps

H.323 Terminal (aplicație VoIP : de ex. Netmeeting) – peer to peer

Rate1VoIP = 80 Kbps, or

Codec G.729: 8Kbps (RTP/UDP/IP overhead) 16Kbps (cu 20 ms timpul de pachetizare), Rate2VoIP = 24 Kbps or

Codec G.723.1: 6.4Kbps (RTP/UDP/IP overhead) 16Kbps (cu 20 ms timpul de pachetizare) Rate3VoIP = 24 Kbps

Traficul transferat de la generatorii de traffic spre recepționerii de trafic nu este luat în calcul în dimensionare deoarece el este folosit în testele pentru a supraîncărca rețeaua cu trafic de mică prioritate.

4.2 Considerații preliminare în dimensionarea legăturilor

4.2.1 Traficul local

Exemplele de dimensionare a traficuluil local sunt date mai jos considerând ratele pentru diferitele aplicații. Figura 4-2 arată fluxurile locale trecând prin AN1, DSD, AN2, AN3. Traficul este considerat a fi unicast. O linie mai groasă indică fluxurile de VoIP iar cele mai subțiri pe cele de Video Conferință.

Figura 4-2 : Scenariul 1 fluxurile de traffic local din UPB (accesADSL )

Scenariul 1

Scenariul 1 se concentrează pe LAN1 ADSL access. Vom considera 5 fluxuri :

L-VC1, L-VC2, L- VC3 trafic al aplicațiilor de video conferință

L-VoIP1, L-VoIP2 pentru aplicațiile VoIP.

Unele link-uri din configurație nu sunt saturate de aceste fluxuri deoarece ele au suficientă bandă penru transportul fluxuilor. Toate aceste link-uri au o bandă de 100 Mbps, FE:

Host – L2SW1, Host-L2SW2; DSD internal links; IS/DS BR2 – L2SW2

Link-urile ramase pot fi dimensionate pentru a oferi o lațime de bandă mai mare decât cea rezultată în cazul cel mai defavorabil. Tabelul 4-1 prezintă proiectul de dimensionare. Valorile sunt calculate pentru o singură direcție.Din cauza simetriei, valorile în sens invers sunt aceleași.

Tabelul 4-1 Scenariul 1 dimensionarea fluxurilor locale

Partea mai închisă a tabelului arată că unica încărcare critică este pe linia MAR2-DSLAM care este saturată.

Pe liniile ATM se vor crea Permanent Virtual Circuits. Acestea vor fi dimensionate la valoarea critică de 1.6 Mbps.

Scenariul 2

Scenariul 2 se concentrează în principal asupra Ethernet ATM access. Fluxurile sunt arătate în Figura 4-3.

prezintă proiectul de dimensionare.

Tabel 4-1: Scenariul 2 dimensionarea fluxurilor locale

Traficul extern

Definiția utilizatorilor externi pentru sub-insula UPB

Seviciile accesibile din alte insule sunt:

Servicii de E-learning (inclzând video conferință, chat, whiteboard și FTP)

VoIP (communication peer to peer)

Utilizatorii din alte insule pot avea acces la serverele localizate în sub-insula UPB. Pentru videoconferință, ceilalți utilizatori pot fi clienți sau servere UPB.Pentru VoIP ceilalți utilizatori trebuie să aibe un telefon IP comercial (ex:. Alcatel Reflex) sau un terminal H.323 .

Sub-insula UPB este o frunză a arborelui MOICANE. De aceea, unica interfață a sub-insulei este insula Romtelecom. Vom nota această interfață cu I1. Rate interfeței este E1 adică 2 Mbps.

Figura 4-3 : Scenariul 2 fluxurile de traffic local din UPB (acces Ethernet – ATM)

Traficul pe care il poate suporta I1 este generat de următoarele scenarii :

Scenariul 3 (ADSL acces) – Figura 4-4

Trei videoconferințe: 3 x RateVC1 = 3 x 0.485 Mbps = 1.455 Mbps; Două VoIP legături peer-to peer : 2 x 80 Kbps = 160 Kbps; Rata totală = 1.615 Mbps; Rata E1 disponibilă: 1.920 Mbps.

Scenariul 4 (ADSL acces și Ethernet – ATM access) – Figura 4-5

O (ADSL acces) videoconferință: 1 x RateVC1 = 0.485 Mbps; O VoIP legătură peer-to peer (ADSL access): 80 Kbps; Două (FE + ATM access) videoconferințe: 2 x RateVC1 = 0.97 Mbps; O VoIP legătură peer-to peer (ATM access): 80 Kbps; Rata totală = 1.615 Mbps;Rata E1 disponibilă: 1.920 Mbps.

Traficul de control

Sub-insula UPB va avea câteva generatoare de traffic de control folosite pentru a genera / măsura fluxurile. Aceste fluxuri vor încărca liniile într-un mod controlat dând posibilitatea de a experimenta eficiența politicilor de QoS în condițiile unui traffic mărit pe linii. Următoarele căi sunt definite în Figura 4-6:

BTraffic-1: BTG/BTR1 – DSLAM – MAR2 – L2SW2 – BTG/BTR2

BTraffic-2: BTG/BTR1 – ATMSW1 – ATMSW2 – x/DS BR1- DS CR2 – IS/DS BR2 – L2SW2 – BTG/BTR3

BTraffic-3: BTG/BTR2 – L2SW1 – ATMSW2 – x/DS BR1- DS CR1 – IS/DS BR2 – L2SW2 – BTG/BTR3

BTraffic-4: BTG/BTR2 – L2SW1 – ATMSW2 – x/DS BR1- DS CR1 – IS/DS BR2 – L2SW2 – BTG/BTR3

.

Figura 4-4: Traficul extern pentru UPB (ADSL Access)

Figura 4-5: Traficul extern pentru UPB (ADSL or Ethernet / ATM Acces)

Figure 4-2: Traficul background UPB

Descriere generală a rețelei

Întreaga structurăa insulei București este dată în Figura 4-7 și este compusă din două sub-insule:

Sub-insula Romtelecom

Sub-insula Universitatea POLITEHNICA București (UPB/CCSRST) cu rețeaua de transport conectată către insula OTE.

Prin intermediul tehnologiilor de acces, gazdele pot accesa rețeaua de acces a configurației. Rețeaua de acces (Acces Network – AN)conține multiplexoarele și switch-urile ce oferă calea către backbone. Partea centrală (Core Network ) este partea care lucrează ca un domeniu DiffServ.

Figure 4-7: Insula București -vedere generală

Arhitectura generală a celor doua sub-insule este similară, dar fiecare dintre ele are o arhitectură specifică.

În fiecare sub-insulă va fi inclus un domeniu IntServ și o parte centrtală, un domeniu DiffServ. Tehnologia DiffServ poate fi aplicată și în partea de acces a rețelei. Cele 2 sub-insule vor fi interconectate la început prin intermediul unei legături E1 canalizat. Pentru teste adiționale se poate utiliza accesul via Internet din sub-insula UPB/CCSRST prin intermediul rețelelor ROEDUNET și GEANT.

Pentru experimentele de la distanță din cadrul MOICANE , insula București e conectată la backbone-ul MOICANE printrr-o legătură E1 la insula OTE de la Atena.

Bibliografie :

[01] Andrew Tannenbaum – Rețele de calculatoare , ediția a-III-a ;

[02] Grazziela Niculescu, – Tehnici și sisteme de comutație ;

Lucian Ioan

Documentația rețelei MOICANE :

[03] „Network Services and Applications Design”

[04] „User & System requirements”

[05] www.moicane.com

[06] www.ietf.org – RFC 2205, RFC 2750, RFC 2474, RFC 2475,

[07] www.protocols.com

[08] Colecția revistelor „Network Magazine” – 2001