Tudor Mihai BLAGA DOMOTIC: CLDIRI INTELIGENTE Curs

5.2. Soluii de distribuie multicast pentru aplicaii multimedia

Transmisia IP multicast este un mecanism de strat reea n care datele sunt transmise de la o surs la mai muli destinatari. Aplicaii de acest gen sunt transmisiile audio-video, aplicaiile de teleconferin sau aplicaiile de descoperire a resurselor disponibile. n cazul transmisiei unicast (punct-la-punct) datele sunt trimise ctre o singur staie, iar n cazul broadcast, datele sunt trimise ctre toate staiile dintr-o arie dat, de exemplu dintr-o reea local. n cazul multicast datele sunt transmise unui set de staii care au indicat c doresc s recepioneze datele, set numit grup multicast [Deering 89]. Pentru a putea realiza transmisia multicast sunt necesare o serie de protocoale i mecanisme specifice la stratul reea. n primul rnd avem nevoie de adrese speciale, numite adrese multicast, care desemneaz grupul multicast drept destinatar al datagramei. n al doilea rnd este necesar un mecanism care sa permit unei staii s se nscrie sau s prseasc grupul multicast, numite protocoale de management a grupului. n final sunt necesare protocoale de rutare multicast care trebuie s creeze arbori de distribuie de la surs la membrii grupului. Grupurile multicast sunt dinamice i deschise, n sensul c orice staie poate s se nscrie i s prseasc orice grup. Dimensiunea unui grup multicast nu este limitat la un anumit numr de membri. O staie poate s se nscrie simultan la mai multe grupuri i pe fiecare staie pot exista mai multe aplicaii care primesc pachete transmise la o adresa IP multicast. Un pachet multicast este o datagram IP care are drept adres destinaie o adres IP multicast. Acest pachet este distribuit la toate staiile care sunt membre ale grupului desemnate de adresa multicast. O staie poate s trimit pachete multicast ctre orice grup, staia care transmite ne trebuind s fie membr a acestuia. De asemenea, mai multe staii pot s transmit simultan ctre acelai grup multicast. O diferen important ntre transmisia unicast i cea multicast este c aplicaiile multicast pot folosi ca protocol de transport doar UDP, deoarece nu exist o versiune pentru multicast a protocolului TCP. Semnificaia acestui lucru este c la nivelul transport nu avem un serviciu de distribuie fiabil.

5.2.1 Adrese multicast IPv4 i IPv6

Adresele multicast IPv4 au o structur diferit de cea a adreselor unicast. Acestea au tot 32 de bii, aparinnd clasei D, clas identificat de primi patru bii ai adresei cu valoarea 1110 (fig. 5.42). Cei 28 de bii rmai constituie identificatorul grupului multicast [Deering 89].

1110 Identificator grup multicast 4 bii 28 bii Fig. 5.42 Formatul adresei multicast IPv4 Adresele multicast IPv6 au 128 de bii i sunt mprite n patru cmpuri (fig. 5.43). Primul cmp pe 8 bii identific adresa ca fiind o adresa multicast. Acesta este urmat de un cmp pe 4 bii care conine 4 bistabili de condiie, doar semnificaia celui mai puin semnificativ bit fiind definit. Valoarea 0000 indic o adres binecunoscut (permanent), iar valoarea 0001 indic o adres de tranziie (temporar). 11111111 8 bii Flgs Scop Identificator grup multicast 4 bii 4 bii 112 bii Fig. 5.43 Formatul adresei multicast IPv6

Cmpul scop pe 4 bii (tab. 5.6) indic dac grupul multicast poate include numai noduri din aceeai reea local, acelai site, aceeai organizaie, sau pot fi adrese IPv6 cu semnificaie global [Dobrot 03b]. Tab. 5.6 Semnificaia valorilor definite pentru cmpul scop
Valoare n hexa 1 2 5 8 E Semnificaie Scop local la nivel de nod Scop local la nivel de legtur Scop local la nivel de site Scop local la nivel de organizaie Scop global

Identificatorul grupului multicast este pe 112 bii, mai multe grupuri putnd avea acelai identificator dac difer valoarea cmpului flgs sau a cmpului scop.

Copyright Tudor Mihai BLAGA 2010-2011, All rights reserved

Tudor Mihai BLAGA DOMOTIC: CLDIRI INTELIGENTE Curs

5.2.2 Managementul grupului multicast

O staie care dorete s recepioneze traficul destinat unui grup multicast trebuie s fie membr a acelui grup. Aceasta poate s se nscrie sau s prseasc grupul oricnd dorete, ea putnd s fie membr a mai multor grupuri. Apartenena staiilor la diferitele grupuri multicast este gestionat folosind protocoale de management a grupului multicast. Funciile specifice ale unui astfel de protocol sunt: nscriere (Join): staia se poate nscrie la un grup multicast. prsire (Leave): staia poate informa routerul c a prsit un anumit grup. ntrebare (Querying): routerul poate ntreba dac exist membri ai unor grupuri multicast pe acea legtur, ntrebri ce pot fi generice sau specifice unui grup. raportare (Reporting): staia poate informa routerul c aparine unui anumit grup multicast. Protocolul care realizeaz aceste funcii pentru IPv4 este IGMP (Internet Group Management Protocol) [Fenner 97], iar pentru IPv6 este MLD (Multicast Listener Discovery) [Vida 04]. Protocolul IGMP are trei versiuni,iar MLD are doar dou versiuni, ultima versiune a fiecrui protocol permind staiei s specifice n mod explicit sursa de la care dorete s primeasc date multicast.

5.2.3 Principiile rutrii multicast

Pentru a distribui datele multicast la toi receptorii routerele multicast creeaz arbori de distribuie care definesc calea pe care pachetele o urmeaz prin reea. Exista dou tipuri de arbori de distribuie multicast, arbori surs (source tree) i arbori partajai (shared tree). Cel mai simplu arbore de distribuie multicast este arborele surs SBT (Source Based Tree). Acesta are rdcina la surs iar ramurile formeaz un arbore care se rspndete prin reea pn la receptori, acest tip de arbore folosind calea cea mai scurt prin reea. Se folosete notaia (S, G) pentru a desemna un arbore surs, unde S este adresa IP a staie surs, iar G este adresa multicast a grupului. Aceast notaie ne arat c exist un SBT diferit pentru fiecare surs care transmite ctre acelai grup multicast [Parkhurst 99]. Spre deosebire de arborii surs care au rdcina la staia surs, arborii partajai SDT (Shared Distribution Tree) folosesc o singur rdcin comun, care este plasat ntr-un punct ales din reea. Aceast rdcina comun se numete Rendezvous Point (RP) n cazul protocolului PIM (Protocol Independent Multicast). Arborele partajat este unidirecional, traficul de la surs fiind trimis spre RP folosind un arbore surs. Traficul este apoi transmis mai departe pe arborele partajat de la RP ctre fiecare receptor. O situaie interesant poate aprea dac ntre surs i RP exist receptori, n acest caz receptorul primind traficul direct de la surs. Arborii surs prezint avantajul de a construi calea optim ntre surs i receptori, avantaj ce garanteaz ntrzierea cea mai mic la transmisia traficului multicast. Totui aceast optimizare are un pre, routerele trebuind s menin informaii referitoare la calea ctre fiecare surs. ntr-o reea care are mii de surse i mii de grupuri traficul de rutare suplimentar poate suprasolicita reeaua, iar tabelele de rutare multicast vor ocupa memoria routerelor. Arborii partajai au avantajul c necesit resurse minime n fiecare router, astfel necesarul de memorie pentru tabelele de rutare este mic. Dezavantajul arborilor partajai este c n anumite situaii calea ntre surs i destinaie poate fi suboptimal. n rutarea unicast traficul este transmis prin reea de la surs la destinaie, n funcie de adresa destinaie. Routerul caut n tabela de rutare adresa reelei destinaie i transmite o singur copie a pachetului pe interfaa corespunztoare acesteia. n transmisia multicast traficul trebuie distribuit la mai multe destinaii, reprezentate de grupul multicast. Routerul multicast trebuie s determine care este sensul ctre surs i care este sensul ctre receptori, iar dac exist mai multe direcii ctre receptori, routerul va multiplica pachetele si le va trimite pe interfeele corespunztoare. Putem spune c traficul multicast este transmis dinspre surs, nu nspre receptori, acest mecanism numindu-se transmisie pe cale invers RPF (Reverse Path Forwarding). Mecanismul RPF permite routerului s transmit corect traficul multicast n jos pe arborele de distribuie, acesta folosind tabela de rutare unicast existent pentru a determina sensul spre surs i cel spre receptori. Un router transmite pachete multicast numai dac ele au fost recepionate pe interfaa corespunztoare sensului spre surs, acest mecanism garantnd c arborii de distribuie nu conin bucle de rutare. Cnd routerul primete un pachet multicast i caut adresa surs a pachetului n tabela de rutare unicast pentru a determina dac pachetul a fost recepionat pe interfaa care se gsete pe calea cea mai scurt spre surs i doar n acest caz va distribui pachetul mai departe, n caz contrar pachetul fiind eliminat. Acest mecanism se numete verificare RPF (RPF check).

5.2.4 DVMRP
DVMRP (Distance Vector Multicast Routing Protocol) este un protocol de rutare multicast inspirat de RIP care creeaz arbori SBT, fiind standardizat prin documentul RFC1075. Diferena este c RIP transmite pachetele pe baza informaiei referitoare la nodul urmtor spre destinaie, n timp ce DVMRP creeaz arbori de distribuie pe baza informaiei referitoare la nodul precedent spre surs. Datorit nrudirii cu RIP, DVMRP se

Copyright Tudor Mihai BLAGA 2010-2011, All rights reserved

Tudor Mihai BLAGA DOMOTIC: CLDIRI INTELIGENTE Curs confrunt cu limitri similare cum ar fi: convergena lent, problema numrri la infinit, metrica fiind numrul de hopuri cu un diametru limitat al reelei [Rodriguez 01]. DVMRP trebuie s interopereze cu IGMP pentru a afla dac pachetele multicast trebuie transmise mai departe. Acest protocol poate ataa sau terge n mod dinamic, n tabela de rutare, reelele care doresc s primeasc trafic multicast pentru un anumit grup. Funcionarea DVMRP se realizeaz prin patru procese distincte [Rodriguez 01]: descoperirea vecinilor schimbul de rute procesul Prune procesul Graft n momentul n care DVMRP este activat pe un router vor fi cutate routerele DVMRP nvecinate. Scopul descoperirii vecinilor este de a localiza alte routere DVMRP direct conectate, i de a afla proprietile acestora. Procesul de schimbare a rutelor este similar cu cel al protocolului RIP, la nceput DVMRP anunnd numai reelele direct conectate. Pe msur ce sunt nvate alte reele rutele corespunztoare sunt introduse n tabela local de rutare DVMRP, fiind anunate routerelor nvecinate. Celelalte dou procese ale DVMRP, Prune i Graft, sunt folosite pentru a realiza operaiile de ataare sau tergere n mod dinamic a reelelor care doresc s recepioneze trafic multicast. Reele sunt incluse n lista de distribuie a traficului multicast cu ajutorul mesajelor de tip Graft, n timp ce cu ajutorul mesajelor de tip Prune reelele sunt terse din aceast list.Mesajele DVMRP sunt transmise folosind protocolul IP cu valoarea doi n cmpul protocol (fig. 5.44), ceea ce identific pachetele drept pachete IGMP.

Fig. 5.44 ncapsularea DVMRP n IP Valoarea cmpului tip este 19, 0x13 n hexa, pentru a identifica pachetul IGMP drept un mesaj DVMRP, iar cmpul cod difereniaz diferitele tipuri de mesaje DVMRP (tab. 5.7).

Tab. 5.7 Tipul mesajelor DVMRP Cod Tip pachet 1 Probe 2 Route Report 5 Ask-Neighbors2 6 Neighbors2 7 Prune 8 Graft 9 Graft-ACK

5.2.5 MOSPF
Protocolul MOSPF (Multicast Extensions to OSPF) ofer performane mai bune dect DVMRP deoarece este un protocol cu starea legturii, avnd o convergen mai rapid, mecanisme pentru evitarea buclelor de rutare i nu exist trafic de control periodic. n al doilea rnd este mai scalabil n medii dense, n parte datorit algoritmului cu starea legturii, dar i datorit faptului c MOSPF folosete un mecanism de nscriere explicit [Doyle 01].

Copyright Tudor Mihai BLAGA 2010-2011, All rights reserved

Tudor Mihai BLAGA DOMOTIC: CLDIRI INTELIGENTE Curs OSPF pentru multicast, adic MOSPF, nu este un protocol separat de OSPF, fiind o extensie a acestuia standardizat n RFC 1584. A fost definit un nou mesaj LSA (Link State Advertisment) de apartenen la grup (Group Membership LSA). Cmpul opiuni a fost extins s includ un bit, MC, care indic prezena suportului pentru multicast. Cmpul opiuni se gsete n mesajele Hello, n pachetele de descriere a bazelor de date i n toate mesajele LSA. Rezultatul folosiri acestui bit este c routere OSPF i MOSPF pot funciona n aceeai reea. Routerele cu valori deferite ale bitului MC pot crea adiacene, totui doar vecinii a cror bit MC este setat pot schimba mesaje LSA de apartenen la grup, doar acestea putnd fi folosite la calcularea rutelor. Ultima extensie a protocolului OSPF se refer la cmpul rtype din mesajele LSA Router ce include un bit W. Acest bit indic dac routerul care a transmis mesajul este un router receptor wildcard. MOSPF folosete tot algoritmul lui Dijkstra pentru a construi arborii de distribuie a pachetelor multicast de la surs la receptori. Att arborii unicast ct i cei multicast sunt calculai folosind informaiile din aceeai baz de date cu starea legturii. Operarea MOSPF implic alegerea unui router desemnat DR (Designated Router) i a unui router desemnat de rezerv BDR (Backup DR). Toate routerele MOSPF trebuie s ruleze IGMP pe legtura local pentru a descoperi receptori multicast, dar numai routerul DR poate trimite interogri IGMP. Se folosete un mecanism cu nscriere explicit, astfel cnd o staie trimite un mesaj IGMP de nscriere la un grup, routerul MOSPF DR creeaz o nregistrare n baza de date local cu grupuri (local group database). Aceast nregistrare conine adresa grupului i reeaua ataat care are receptori pentru acel grup (fig. 5.45). Dac dou staii din reele diferite sunt membre ale aceluiai grup, routerul trebuie s tie numai grupul i reelele n care fiecare grup are membrii. El nu trebuie s tie fiecare membrul al grupului.

Fig. 5.45 Baza de date local de grupuri Routerul DR transmite, n continuare, un mesaj LSA de apartenen la grup pentru fiecare grup ataat. Mesajul LSA specific adresa grupului i identificatorul routerului RID (Router ID), totodat listnd toate reelele ataate care conin membrii ai acelui grup. n unele situaii routerul poate rula aplicaii care sa l fac membru al unui grup multicast, n acest caz mesajul LSA incluznd un cmp n care routerul specific dac el este membru al grupului. Mesajele LSA sunt apoi inundate n toat aria routerului. Mesajul LSA de apartenen la grup este similar cu mesajul LSA reea, folosit n OSPF, din dou puncte de vedere [Moy 94]: numai un router DR poate transmite mesaje LSA de apartenen la grup. acest mesaj LSA are scop local n aria OSPF, nefiind distribuit dincolo de scopul ariei routerului care a trimis mesajul. Motivul inundrii acestor mesaje LSA n aria OSPF este ca toate routerele MOSPF s dein o copie a tuturor mesajelor LSA de apartenen la grup care i au originea n acea arie. La fel ca la OSPF, toate routerele MOSPF din arie trebuie s dein baze de date cu starea legturi identice, singura diferen ntre aceste baze de date fiind includerea mesajelor LSA de apartenen la grup. Avnd bazele de date sincronizate, orice router MOSPF din domeniu poate calcula acelai arbore de distribuie, cu rdcina n reeaua surs iar ramurile extinzndu-se pn la fiecare reea cu receptori. Totui arborele nu este calculat imediat, el fiind calculat la cerere atunci cnd primul pachet multicast pentru un anumit grup este primit. Acest lucru se ntmpl deoarece dei toate routerele tiu unde se gsesc receptorii, ele s-ar putea s nu tie unde este sursa. Pentru calcularea arborelui de distribuie informaia referitoare la receptori este luat din mesajele LSA de apartenena la grup, iar informaia referitoare la surs este extras din primul pachet multicast recepionat. Pentru a calcula calea cea mai scurt de la surs la fiecare destinaie se folosesc mesajele LSA unicast reea i LSA router al cror bit MC este setat [Moy 94]. Avantajul folosiri mecanismului cu nscriere explicit bazat pe mesaje LSA de apartenen la grup combinat cu calcularea ci la cerere, este c routerul tie deja locaia receptorilor nainte de a realiza calculul. Spre deosebire de

Copyright Tudor Mihai BLAGA 2010-2011, All rights reserved

Tudor Mihai BLAGA DOMOTIC: CLDIRI INTELIGENTE Curs protocoalele care folosesc un mecanism broadcast and prune cum este DVMRP-ul, pachetele multicast nu vor fi transmise n toat reeaua. Pe baza rezultatelor obinute n urma calculului se vor introduce nregistrri n tabela de rutare multicast. Calea obinut este lipsit de bucle de rutare i fiecare router tie care este interfaa spre surs i care sunt interfeele ctre receptori, mecanismul RPF ne mai fiind necesar. nregistrarea din tabela de rutare pentru o anumit pereche (S,G) indic care este routerul de la care va fi recepionat pachetul multicast i ctre ce routere trebuie trimis pachetul mai departe. Baza de date local de grupuri este folosit pentru a crea nregistrri n tabela de rutare pentru reelele direct conectate care au receptori multicast. MOSPF are o serie de limitri, una dintre acestea fiind c dei protocolul OSPF suport ci multiple de cost egal MOSPF nu permite folosirea lor. Arborele creat de MOSPF descrie o singur cale ntre surs i toate reelele care conin receptori. Alt problem se poate ivi n situaia n care routere OSPF i MOSPF coexist n reele multiacces, n acest caz trebuind s ne asigurm c routerul MOSPF va fi ales router DR. Dac un router OSPF devine DR nu se vor mai transmite mesajele LSA de apartenen la grup i n consecin nici un pachet multicast nu va mai fi rutat. Cea mai important limitare a protocolului MOSPF apare n situaia n care topologia se modific toat tabela de rutare trebuind tears i recalculat. Din acest motiv este foarte important ca domeniul s fie ct mai stabil.

5.2.6 PIM
PIM (Protocol Independent Multicast) are dou moduri de operare, dens i rsfirat, constnd astfel n dou protocoale de rutare PIM-DM (PIM Dense Mode) i PIM-SM (PIM Sparse Mode). Are n denumire expresia independent deoarece se folosete de protocoalele de rutare unicast existente pentru a determina cile multicast. Versiunea nti a celor dou moduri de lucru PIM, DM i SM, nu a fost standardizat de IETF, totui echipamentele produse de Cisco i Juniper le implementeaz, acesta fiind motivul pentru care ele sunt prezentate n aceast seciune. Versiunea a doua a modului PIM-DM a fost standardizat prin RFC 3973, iar PIM-SMv2 a fost standardizat prin RFC 4601, ce revizuiete documentul RFC 2362. Mesajele versiunii a doua, PIMv2, sunt ncapsulate n datagrame IP avnd numrul de protocol 103, iar prima versiune folosete mesaje de tip IGMP pentru transportul informaiei de rutare. Mesajele PIM pot fi transmise folosind att unicast ct i multicast, n cazul folosirii transmisiei multicast fiind utilizat adresa 224.0.0.13 pentru IPv4 i adresa ff02::13 pentru IPv6, cu semnificaia toate routerele PIM (ALL-PIMRouters). PIM-DM PIM-DM este foarte asemntor cu DVMRP din mai multe puncte de vedere. Amndou sunt considerate protocoale pentru medii dense, opernd n medii unde att sursele multicast ct i receptorii multicast sunt localizai n aceeai arie. Protocoalele care lucreaz n mod dens nu in cont de debitul ocupat, folosind mecanismul broadcast and prune. Astfel routerele multicast presupun c toat lumea vrea s primeasc trafic multicast, n acest model traficul de la sursa multicast fiind transmis pe toate interfeele pn cnd interfaa este tears din arborele de distribuie. Fiecare interfa are un timer care monitorizeaz timpul pentru care acea interfa este tears din arborele de distribuie, la expirarea acestui contor interfaa fiind adugat din nou la arborele de distribuie i traficul multicast fiind din nou transmis n reea. Att PIM-DM ct i DVMRP creeaz arbori SBT care conecteaz fiecare surs cu receptorii corespunztori. Arborii sunt creai n mod dinamic pentru fiecare surs folosind mecanismul RPF, diferena major ntre cele dou protocoale fiind c PIM-DM se bazeaz pe alte protocoale de rutare unicast pentru a construi arborele de distribuie. Putem folosi orice protocol de rutare unicast: RIP, IGRP, EIGRP sau OSPF, mpreun cu PIM-DM [Parkhurst 99]. PIM-DM este independent de protocolul de rutare IP unicast folosit, iar ca urmare a acestui fapt se poate ntmpla ca n aceeai reea PIM-DM i DVMRP s construiasc arbori de distribuie diferii, aa cum se poate observa n fig. 5.46, fig. 5.47 i fig. 5.48. n reeaua din fig. 5.46 se folosete DVMRP ce construiete arborii pe baza numrului de hopuri, acesta folosind legturile la 56kbps.

Fig. 5.46 Rut DVMRP n reeaua din fig. 5.47 se utilizeaz PIM cu OSPF, metrica folosit fiind debitul legturii, n acest caz cea mai scurt cale folosete legturile la 100Mbps.

Copyright Tudor Mihai BLAGA 2010-2011, All rights reserved

Tudor Mihai BLAGA DOMOTIC: CLDIRI INTELIGENTE Curs

Fig. 5.47Rut PIM-DM i OSPF Fig. 5.48 prezint o reea PIM cu RIP arborele rezultat fiind similar cu cel de la DVMRP.

Fig. 5.48 Rut PIM-DM i RIP Aceast serie de figuri ne arat c PIM-DM este independent de protocolul de rutare unicast n sensul c el poate opera indiferent de protocolul unicast folosit, dar arborele de distribuie rezultat depinde de protocolul unicast. Fig. 5.49 prezint modul de creare al arborilor SBT de ctre protocolul PIM-DM. Routerul A din figura primete un pachet multicast i verific adresa surs pentru a determina dac pachetul a fost recepionat pe interfaa aflat pe calea cea mai scurt ctre surs (RPF check). Deoarece sursa este direct legat pe interfaa routerului A, pachetul va fi transmis mai departe pe toate interfeele, mai puin cea pe care el a fost recepionat.

Fig. 5.49 Crearea arborelui de distribiie PIM-DM Routerul B primete pachetul de la routerul A i determin dac a fost primit pe interfaa RPF pentru acea surs. Deoarece pachetul a fost primit pe interfaa corect, routerul B l va trimite mai departe ctre receptorul 1 i routerul C. n acelai timp i routerul C primete pachetul de la routerul A i determin c a fost primit pe interfaa RPF pentru acea surs. n continuare routerul C l va trimite mai departe ctre receptorul 2 i routerul B. Pachetul multicast primit de routerul B de la routerul C i cel primit de C de la B vor fi eliminate deoarece ele nu au fost recepionate pe interfaa aflat pe calea cea mai scurt ctre surs. n acest moment arborele de distribuie a fost construit. PIM-SM PIM-SM este foarte asemntor cu PIM-DM deoarece amndou folosesc un protocol de rutare unicast pentru a determina interfeele RPF. Un protocol de mod rsfirat funcioneaz ntr-un mediu n care sursele multicast i receptorii nu sunt localizai n apropriere, acest lucru nu nseamn c PIM-SM nu poate fi folosit ntr-o reea locala (LAN), dar protocoalele de acest tip funcioneaz mai eficient n reele WAN (Wide Area Network). Protocoalele de mod rsfirat folosesc un model cu nscriere explicit n care traficul multicast este transmis pe o interfaa doar dac acest lucru a fost solicitat. PIM-SM folosete arbori partajai pentru distribuirea traficului multicast, ce conin un punct central care colecteaz traficul de la toate sursele pentru un grup multicast dat (fig. 5.50). Fiecare surs ruteaz traficul pe calea cea mai scurt ctre punctul central, de unde traficul este distribuit ctre receptori, din nou, pe calea cea mai scurt. Acest punct central se numete la PIM-SM Rendezvous Point, adic RP. ntr-o reea pot exista mai multe routere RP, dar pentru un anumit grup trebuie s existe doar un singur RP.

Copyright Tudor Mihai BLAGA 2010-2011, All rights reserved

Tudor Mihai BLAGA DOMOTIC: CLDIRI INTELIGENTE Curs

Fig. 5.50Arborele partajat PIM-SM Protocolul PIM-SM permite trecerea de la arborele de distribuie partajat la un arbore de distribuie surs, la depirea unui prag specificat pe routerele de tip frunz [Estrin 98]. Avantajul comutrii la arborele surs este c traficul este recepionat pe calea cea mai scurt, aceasta avnd n general o ntrziere mai mic dect calea prin arborele partajat. Dezavantajul comutrii l constituie faptul c routerul trebuie s menin mai mult informaie de stare de tipul (S,G) [Parkhurst 99]. Mesajele PIM-SM sunt ncapsulate n pachete IGMP (fig. 5.51), avnd un antet comun care identific tipul mesajului i modul de operare dens sau rsfirat.

Fig. 5.51 ncapsularea PIM-SM n IGMP Tab. 5.8 prezint tipul mesajelor PIM-SM conform [Estrin 98]. Tab. 5.8 Codul mesajelor PIM-SM Cod Tip pachet 0 Router Query 1 Register (Sparse Mode) 2 Register-Stop (Sparse Mode) 3 Join/Prune 4 RP Reachability 5 Assert Mesajele de interogare PIM-SM sunt folosite pentru a descoperi routerele PIM-SM nvecinate, acestea ne coninnd o list cu routerele nvecinate. Dac un vecin recepioneaz mesajul de interogare el va nregistra adresa IP a vecinului, dar nu exist nici un mecanism explicit de a anuna vecinul c mesajul a fost primit. Routerul care a primit mesajul va trimite la rndul su un mesaj de interogare care are ca rol informarea routerelor PIM-SM de existena sa. n cazul protocolului PIM-DM la recepia unui mesaj de interogare pe o interfa, aceast interfa era introdusa n oilist. Acest lucru nu se ntmpl n cazul PIM-SM, deoarece acesta folosete un mecanism de nscriere explicit. Routerul trebuie s se nscrie la grup nainte ca traficul s fie transmis pe interfaa corespunztoare. n cazul unei reele multiacces, cum ar fi o reea de ce folosete FastEthernet, mesajele de interogare sunt trimise la adresa 224.0.0.2 ce desemneaz grupul tuturor routerelor, mecanism folosit la alegerea routerului desemnat DR. Parametrul Holdtime din mesajul de interogare indic timpul care trebuie s se scurg pn cnd vecinul va fi declarat nefuncional. Intervalul de transmitere a mesajelor de interogare trebuie sa fie mai mic dect cel din parametrul Holdtime. Mesajele de interogare asigur un mecanism de meninere n viaa a legturii ntre routere. Dac

Copyright Tudor Mihai BLAGA 2010-2011, All rights reserved

Tudor Mihai BLAGA DOMOTIC: CLDIRI INTELIGENTE Curs timpul specificat de parametrul Holdtime expir i vecinul respectiv era routerul DR pentru acea legtura, va fi ales un nou DR.

5.2.7 Parametrii de performan multicast

Modul de operare i performanele protocoalelor de rutare multicast au fost studiate ntr-o serie de lucrri tiinifice i teze de doctorat [Billhartz 97; Ueno 00; Li 05; Blaga 05; Blaga 07]. Parametri determinai difer de la caz la caz, n continuare fiind prezentai parametrii cei mai des utilizai: ntrzierea de transfer (end-to-end delay): timpul scurs ntre generarea unui pachet la surs i recepia acestuia de un membru al grupului. Este timpul n care un pachet de date este rutat prin reea de la surs la destinaie. bfseries utilizarea de resurse n reea (network resource usage): numrul total de hopuri prin care trec copii ale unui pachet pentru a ajunge la toi membri grupului. Se calculeaz mprind numrul total de hopuri determinat pe parcursul simulri cu numrul total de pachete recepionate. procentul de trafic de control (overhead traffic percentage): procentul de bii de control din numrul total de bii transmii. concentrarea traficului (traffic concentration): este msura distribuiei traficului pe toate legturile reelei, fiind definit de raportul ntre debitul maxim pe o legtur i debitul mediu pe toate legturile. ntrzierea de nscriere (join latency): timpul scurs de la trimiterea unei cereri de nscriere la grup pn la recepia primului mesaj multicast. ntrzierea de nscriere la grup (join latency) se manifest n dou cazuri: apariia unui nou receptor. n modul dens, routerul DR asociat receptorului va trimite un mesaj Graft ctre sursele existente. Atunci cnd acest mesaj ajunge la un router care face parte din arborele de distribuie multicast a grupului, numit punct de ataare, pachetele de date vor putea ajunge la noul receptor. Acest proces ar trebui s dureze echivalentul ntrzierii de transfer dus-ntors (RTT) ntre receptor i punctul de ataare. n modul de lucru rsfirat nscrierea la grup se face prin trimiterea unui mesaj Join ctre routerul RP. Atunci cnd acest mesaj ajunge la un router care face parte din arborele de distribuie RP al grupului pachetele de date vor putea ajunge la noul receptor. Se estimeaz durata procesului de nscriere ca fiind aproximativ egal cu RTT ntre receptor i punctul de ataare la arborele RP. apariia unei surse noi. n modul dens, pachetele de date sunt transmise prin inundare la toate routerele. Astfel un receptor va primi datele dup un timp echivalent cu ntrzierea de transfer de la surs la receptor. n mod rsfirat, datele de la sursa nou ajung la RP ncapsulate n mesaje Register. Acesta le decapsuleaz i distribuie datele ctre receptori. ntrzierea de transfer de la surs la receptor pe calea dat de arborele RP reprezint timpul scurs pn la primirea datelor de ctre receptor.

5.2.8 Servicii alternative de comunicare n grup

n condiiile n care tehnologia multicast nativ nu este disponibil la scal larg n Internet, au aprut o serie de tehnologii alternative. Serviciile alternative de comunicare n grup, numite AGCS (Alternative Group Communication Service), grupeaz ntr-un singur termen toate mecanismele care au abilitatea de a transmite informaie simultan la mai muli receptori n mod asemntor cu rutarea multicast [El-Sayed 03]. Aceste tehnologii pot fi folosite pentru a depi limitrile rutrii multicast native. Pot fi folosite pentru a interconecta regiunile care suport multicast, sau n medii n care rutarea nativ multicast nu este potrivit, cum ar fi reelele ad-hoc, reele mobile, care nu au o infrastructur fix. Rutarea multicast a fost gndit pentru o infrastructur fix, ierarhic n care routerele multicast sunt clar definite. Alt situaie ce poat fi rezolvat prin folosirea AGCS este cazul n care avem un numr mare de grupuri multicast cu un numr mic i foarte dinamic de receptori. Pentru acest exemplu ncrcarea cauzat de schimbul de semnalizri, datorat protocoalelor multicast native pentru fiecare grup n parte, va limita scalabilitatea sistemului. Clasificarea acestor tehnologii este nsoit de prezentarea caracteristicilor i a modului de operare a patru propuneri AGCS: CastGate, XCast/XCast+, ESM (End System Multicast) i HyperCast. Clasificarea AGCS n funcie de modul n care se realizeaz distribuia datelor, avem urmtoarea clasificare: reflector unicast/multicast, exemple: UMTP (UDP Multicast Tunneling Protocol), CastGate. tunelare permanent, exemple: DVMRP, AMT (Automatic Multicast Tunnels). multicast cu topologie suprapus (overlay), exemple: ESM, HyperCast. servicii de rutare specifice, exemple: XCast/XCast+, DCM (Distributed Core Multicast). Reflector unicast/multicast Soluiile din aceast categorie sunt folosite pentru staiile care au acces numai la rutare unicast i care folosesc un reflector. Acesta este o poart ntre lumea multicast i staiile din regiunea unicast,

Copyright Tudor Mihai BLAGA 2010-2011, All rights reserved

Tudor Mihai BLAGA DOMOTIC: CLDIRI INTELIGENTE Curs transmind fiecare pachet din regiunea multicast ctre staiile unicast. Aceste soluii se mai numesc tunelare punctual deoarece ele creeaz un tunel ntre reflector i receptor, acestea diferind de soluiile cu tunelare permanent. Un aspect important pentru aceste AGCS este c reprezint o soluie de strat aplicaie, datele putnd ajunge de la reflector la receptor fie ncapsulate n datagrame unicast, fie prin deschiderea unui socket UDP i transmiterea numai a informaiei utile din partea de date (payload), fr antetele iniiale. n ultimul caz adresa surs i portul se vor pierde, dar protocoalele de strat superior pot recupera identitatea sursei. Acest tip de serviciu funcioneaz o perioad de timp limitat i pentru un numr limitat de grupuri, n mod uzual existnd cte un reflector pentru fiecare grup. Din aceast categorie fac parte UMTP, CastGate i Mtunnel (Multicast Tunneling). Aceast abordare nu este cea mai eficient deoarece se creeaz puncte de concentrare a traficului (hot spot) n aproprierea reflectorilor. Totui aceste soluii sunt uor de implementat, iar reflectorul permite un control total asupra parametrilor serviciului: durat, grupul multicast, receptorii autorizai. Tunelare permanent Aceast abordare difer de soluia precedent deoarece tunelarea se realizeaz la stratul reea, prin rutare i folosete ncapsularea IP n IP. Crearea acestor tunele necesit diferite privilegii i ele nu sunt create de receptor. n al doilea rnd, dac un reflector rezolv necesitile unui anumit grup, soluia tunelrii permanent ofer conectivitate ntregului site. Aceste tunele sunt integrate n protocoalele de rutare multicast i pot fi folosite indiferent de grupul multicast, implementarea mrouted a protocolului DVMRP oferind o astfel de soluie. Aceast categorie a fost ndelung folosit n MBone pentru a interconecta regiuni multicast izolate, dar deoarece aceste tunele au performane reduse ele nu mai sunt folosite n prezent. Multicast cu topologie suprapus Aceast clas de propuneri transfer suportul multicast din routere la nivelul receptorilor, de la stratul reea la stratul aplicaie. Receptorii trebuie s implementeze toate funciile necesare comunicrii de grup, cum ar fi managementul apartenenei la grup, replicarea i distribuia pachetelor. Membrii grupului comunic printr-o topologie suprapus peste cile unicast, topologie care poate fi independent de topologia fizic. Acest tip de AGCS difer din multe puncte de vedere de rutarea nativ multicast: un nod care distribuie pachete n topologia suprapus poate s fie un receptor, un server dedicat, sau un router de grani, arborii de distribuie multicast incluznd numai routere. prin folosirea unei topologii multicast suprapuse, topologia fizic a reelei este complet ascuns, un arbore virtual de distribuie fiind creat ntre toate nodurile. n cazul transmisiei multicast native informaia referitoare la apartenena la grup este distribuit ntre routerele multicast, iar n cazul topologiei overlay aceast informaie poate fi deinut de RP, surs sau chiar de toate nodurile. Avantajul major al acestei abordri este c nu necesit suport special din partea routerelor, astfel ea putnd fi folosit n orice situaie. Performanele acestei abordri sunt mult influenate de nivelul de congruen dintre topologia fizic i cea suprapus, cile din topologia suprapus putnd fi suboptimale din punctul de vedere al ntrzierii, iar datele pot fi replicate de mai multe ori pe aceeai legtur fizic. Servicii de rutare specifice Aceast categorie se bazeaz pe servicii de rutare dedicate, ele ne putnd fi implementate i folosite la cerere de receptori. Acestea ncearc se rezolve o parte din limitrile rutrii multicast native referitoare la scalabilitatea redus n cazul unui numr mare de grupuri multicast cu receptori puini i dinamici. Propunerea XCast introduce o list explicit de destinaii unicast n fiecare pachet folosind un antet nou XCast pentru IPv4 i o nou extensie de rutare pentru IPv6 [Boivie 05]]. Fiecare router de-a lungul ci proceseaz antetul IP i n cazul unei ramificri n arborele de distribuie, creeaz i trimite noul pachet cu un subset potrivit de destinaii pe interfeele corespunztoare. Cnd n noul antet mai rmne o singur destinaie pachetul este transformat ntr-un pachet unicast normal. Gradul ridicat de scalabilitatea al abordri XCast este dat de faptul c nu este necesar meninerea de informaie de stare n routerele din reea. CastGate Tehnologia CastGate a fost dezvoltat de un grup de cercettori ai departamentului ETRO de la Vrije Universiteit Brussel (VUB). Aceasta asigur acces la coninut multicast prin auto-tunelare, fiind gndit ca o tehnologie de tranziie care va produce creterea numrului de utilizatori multicast, determinnd astfel furnizorii de servicii s implementeze multicast nativ [Liefooghe 04a]. Datele multicast sunt transmise printr-un tunel unicast de la serverul tunel localizat n Internet ntr-o zon unde exist acces multicast, i clientul tunel care se gsete la utilizator. Pentru a realiza acest lucru se folosete versiunea extins a protocolului UMTP. Sunt disponibile dou moduri de tunelare, tunelarea per canal i tunelarea neprelucrat (raw tunneling). n primul mod de lucru doar datele multicast destinate unui grup multicast precizat de adres i port vor fi tunelate. Al doilea mod de lucru permite tunelarea ntregului trafic multicast. Deoarece unele echipamente filtreaz traficul UDP este posibil transportarea datelor prin tunelare HTTP ce nu va fi filtrat. Arhitectura de baz CastGate are trei elemente componente: client tunel CastGate (TC - Tunnel Client), server tunel CastGate (TS - Tunnel Server) i server tunel baz de date CastGate (TDS - Tunnel Database Server) (fig. 5.52). Baza de date conine informaii despre locaia serverelor tunel disponibile, fiind posibil utilizarea unui sistem ierarhic de baze de date, asemntor cu cel folosit pentru DNS (Domain Name System).

Copyright Tudor Mihai BLAGA 2010-2011, All rights reserved

Tudor Mihai BLAGA DOMOTIC: CLDIRI INTELIGENTE Curs

Fig. 5.52 Arhitectura CastGate Un client tunel care dorete s recepioneze date multicast va cere serverului baz de date o list cu serverele tunel disponibile, list din care va alege unul. n continuare clientul anun serverul de ce grup multicast este interesat, urmnd ca apoi serverul tunel s trimit datele clientului. Clientul poate fi integrat n orice aplicaie multicast, sau poate funciona n forma de applet Java care ruleaz ntr-un browser de web. Din punct de vedere al utilizatorului operarea acestuia este transparent, fr ca utilizatorul s stie c nu dispune de acces multicast nativ. Ca urmare a dezvoltrii continue a tehnologiei a aprut routerul CastGate [Liefooghe 04b]. Acesta integreaz protocolul IGMP cu clientul tunel (fig. 5.53). n acest fel se poate asigura acces multicast pentru toate staiile conectate la acelai segment de reea, evidena tuturor staiilor care se nscriu la grupul multicast fiind inut de routerul CastGate prin protocolul IGMP. Routerul CastGate a fost extins prin introducerea protocolului de rutare nativ multicast PIM-SM [Blaga 05; Blaga 06; Blaga 07]. Aceast soluie folosete tunelarea pentru a aduce datele multicast n domeniul local, de unde ele sunt distribuite prin multicast. A fost ales protocolul PIM-SM deoarece acesta construiete arbori partajai cu o rdcin comun, numit Redezvous Point. Toat informaia despre activitatea multicast (surse active i receptori) din domeniu este centralizat n routerul RP. Rezultatele experimentale ce au vizat determinarea stresului, a utilizrii resurselor i a ntiderii, prezentate n [Blaga 07], arat c folosirea routerului CastGate cu PIM-SM este de 5 ori mai eficient dect clientul CastGate i de 2 ori mai eficient dect routerul CastGate.

Fig. 5.53 Routerul CastGate Tehnologia CastGate permite rezolvarea unor probleme care nu sunt adresate de modelul multicast nativ, cum este lipsa suportului AAA (Authentication, Authorization, Accounting), problem rezolvat prin folosirea unei versiuni modificate de UMTP. Serverul tunel poate fi integrat cu un server RADIUS (Remote Authenticastion Dial-In User Service) pentru a permite autentificarea utilizatorilor, autorizarea sesiunilor i pentru a realiza tarifarea serviciului multicast. CastGuide i CastContent au fost dezvoltate tot n cadrul proiectului [Liefooghe 04b]. CastGuide permite obinerea unei liste cu sesiunile multicast n desfurare sau care urmeaz s fie difuzate, fiind echivalentul unui ghid TV pentru coninut multicast. CastContent este gndit pentru furnizorii de coninut, fiind n curs de dezvoltare dou versiuni: CastLive care permite distribuia n timp real a coninutului multicast i CastCOD pentru distribuia coninutului multicast la cerere (Content-On-Demand). XCast, XCast+ i XCast++ XCast a fost proiectat pentru a depi problemele legate de scalabilatea i lipsa implementrii multicast-ului nativ. Crearea i meninerea arborilor de distribuie multicast n cazul grupurilor cu numr redus de membrii implic costuri nejustificat de mari, folosirea XCast pentru acest tip de grup eliminnd semnalizrile dintre routerele multicast i informaia de stare memorat de acestea [Bag-Mohammadi 05]. Serviciul multicast explicit se bazeaz numai pe rutarea unicast, sursa multicast incluznd o list cu adresele IP a tuturor destinaiilor ntr-un antet special (antet XCast), antet prezent n toate pachetele de date. Routerele intermediare determin hopul urmtor pentru fiecare destinaie din list folosind tabela de rutare

10

Copyright Tudor Mihai BLAGA 2010-2011, All rights reserved

Tudor Mihai BLAGA DOMOTIC: CLDIRI INTELIGENTE Curs unicast, iar n funcie de interfaa de ieire din router lista cu destinatari este mprit n mai multe seturi. Pentru fiecare set routerul multiplic pachetul i l trimite pe interfaa corespunztoare. Dac n list mai exist doar o singur destinaie pachetul va fi trimis mai departe fr antetul XCast, ca orice pachet unicast, procedeu ce se numete X2U (Xcast to Unicast) [Boivie 05]. n fig. 5.54 sursa XCast dorete s trimit date urmtoarelor cinci destinaii: c1, c2, c5, c9 i c17. Pachetul pleac de la surs avnd n antetul XCast o list cu aceste destinaii. Routerul R1 va realiza X2U pentru staia c17, destinaie ce va fi eliminat din list. Procedeul X2U este folosit de R2 pentru c9 pe o interfa, iar pe cealalt interfa lista va conine doar trei destinatari. n ultimul nod, routerul R3, se folosete din nou X2U pentru a trimite datele ctre staiile corespunztoare. Aa cum se poate observa din figur n fiecare nod lista este parsat i scurtat.

Fig. 5.54 Distribuia datelor folosind XCast Antetul XCast n IPv4 este transportat ntre antetul IP i antetul de strat transport, cmpul numr protocol din antetul IP avnd valoarea PROTO_XCast. Adresa surs este adresa sursei XCast, iar adresa destinaie este adresa All_XCast_Nodes. n IPv6, antetul XCast este transmis folosind un antet de rutare extins. n comparaie cu modelul multicast nativ XCast prezint mai multe avantaje. Astfel routerele nu mai memoreaz informaie de stare, XCast fiind mai scalabil. Nu este necesar alocarea unei adrese multicast, iar rspuns la modificare rutelor unicast este automat. Protocoalele de rutare multicast se bazeaz pe informaie referitoare la rutele unicast, iar n momentul n care acestea se modific arborele de distribuie trebuie refcut. Deoarece sursa cunoate toi destinatarii XCast ofer suport pentru AAA. Ca dezavantaje ale tehnologiei XCast trebuie s menionm prezena unui antet suplimentar, ce conine lista destinaiilor, n fiecare pachet de date. Prezena acestui antet implic procesri suplimentare n nodurile din reea astfel aprnd ntrzieri. Alt dezavantaj este c numrul membrilor grupului multicast este limitat de dimensiunea antetului XCast. Succesul XCast depinde de larga sa rspndire, existnd mai multe modaliti de a implementa XCast ntr-o reea n care nu toate nodurile au suport pentru acesta. Prima modalitate implic configurarea de tunele ntre routerele XCast, iar folosirea procedeului X2U n mod prematur este o modalitate prin care un router ce descoper c nu mai are vecini capabili XCast poate trimite datele ctre receptori. n acest caz pentru fiecare destinatar din antetul XCast se va trimite un pachet unicast, dezavantajul acestei metode fiind c duplicarea datelor se realizeaz mai devreme dect ar fi necesar conform topologiei reelei. Ultima modalitate, tunelarea semipermeabil, folosete tot tunelarea dar nu necesit configurare manual, adresa uneia dintre destinaiile din list fiind folosit drept adres destinaie a pachetului IP. Routerele intermediare care nu suport XCast, vor trata aceste pachet ca pachete unicast obinuit. Dezavantajul acestei metode este calea suboptimal urmat de pachete, n cazul cel mai defavorabil, destinaia a crei adres IP a fost folosit, trebuie s trimit datele mai departe ctre destinaiile rmase n list [Boivie 05]. XCast a fost gndit pentru a permite operarea unui numr mare de grupuri cu un numr redus de receptori, iar XCast+ reprezint o extindere a funcionalitii acestuia n sensul creterii numrului de receptori pentru un grup multicast. Introducerea suportului pentru IGMP/MLD (la fel ca la routerul CastGate) n routerele XCast ofer acces multicast tuturor nodurilor conectate la acel segment de reea [Shin 01b]. Analiznd modul de distribuie a datelor, observm c acestea sunt trimise routerelor XCast+ nu direct receptorilor (fig. 5.55). Este sarcina routerului XCast+ de a expedia datele ctre utilizatori prin multicast nativ, folosind procedeul X2M (XCast to Multicast) [Shin 01a].

Copyright Tudor Mihai BLAGA 2010-2011, All rights reserved

11

Tudor Mihai BLAGA DOMOTIC: CLDIRI INTELIGENTE Curs

Fig. 5.55 Distribuia datelor folosind XCast+ Propunerea XCast++ extinde funcionalitatea XCast+ prin introducerea de faciliti PIM-SM [Blaga 07]. XCast++ poate fi utilizat fr a fi necesare routere specializate, suport un numr crescut de receptori, obinnd performane apropriate de transmisia multicast. Rezultatele experimentale arat c performanele XCast++ sunt doar cu 15% inferioare transmisiei multicast native [Blaga 07]. ESM End System Multicast este o tehnologie n care toate funciile multicast: managementul grupului, rutarea datelor i replicarea pachetelor sunt implementate de staia final (end system) folosind doar transmisii unicast [ESM 06]. Mutarea de pe stratul reea pe stratul aplicaie a suportului pentru multicast rezolv unele dintre problemele transmisiei multicast native. Deoarece toate datele sunt transmise folosind unicast se depete problema rspndirii reduse a accesului multicast, iar toat informaia de stare este stocat de staiile finale nu n reea. Aceast abordare permite soluionarea simplificat a unor probleme inerente transmisiei multicast: corecia erorilor, controlul fluxului i al congestiei. n ciuda numeroaselor avantaje ESM exist cteva aspecte ce trebuie soluionate pentru ca aceast tehnologie s devin o alternativ practic. Folosirea unei topologii overlay nu poate oferi performane similare IP multicast din punctul de vedere al debitului i al ntrzierii. Protocolul Narada a fost dezvoltat pentru a implementa conceptul ESM, acesta permind autoorganizarea clienilor ntr-o structur overlay n mod distribuit, lund n cosiderare obinerea unei structuri ct mai eficiente. Protocolul a fost dezvoltat innd seama de urmtoarele aspecte [ESM 06]: auto-organizare: construcia topologiei overlay trebuie s se fac total distribuit, iar procesul trebuie s fie robust la schimbarea dinamic a membrilor grupului. eficiena topologiei overlay: arborele de distribuie obinut trebuie s fie eficient din punctul de vedere al aplicaiei dar i al reelei. Din perspectiva reelei trebuie s minimizm redundana transmisiei i ntrzierea. Aplicaiile pot avea cerine diferite, astfel o aplicaie interactiv de genul audioconferin necesitnd o ntrziere redus, iar o aplicaie de distribuie video avnd nevoie de un debit mare i de ntrzieri reduse. auto-mbuntire: construcia topologiei suprapuse trebuie s includ un mecanism prin care s se poate culege informaii despre reea, oferind astfel posibilitatea de mbuntire a topologie pe msur ce este disponibil informaie suplimentar. adaptare la dinamica reelei: topologia trebuie s se adapteze continuu la schimbrile dese din Internet. Crearea arborelui de distribuie folosind Narada se face n doi pai. Prima oar se construiete unui graf virtual complet ntre toate nodurile, care s respecte aspectele menionate anterior, iar n pasul al doilea se construiete arborele de distribuie folosind algoritmi de rutare cunoscui. Fig. 5.56 prezint procesul de creare a plasei (mesh) i a arborelui de cale minim cu sursa n nodul A.

Fig. 5.56 Etapele principale n construcia ESM

12

Copyright Tudor Mihai BLAGA 2010-2011, All rights reserved

Tudor Mihai BLAGA DOMOTIC: CLDIRI INTELIGENTE Curs n proiectarea protocolului s-a luat n considerare ca ntrzierea cii ntre oricare membru din plas s fie minim i cel mult de K ori mai mare dect ntrzierea cii unicast, unde K este o constant. Fiecare membru are un numr limitat de vecini, pe cei care nu depesc pragul. Pragul este dat de debitul conexiunii fiecrui membru la Internet. Protocolul Narada construiete peste plasa care leag toi membrii un arbore de distribuie a datelor printr-un protocol cu algoritm vector distan. Pentru evitarea numrrii pn la infinit Narada folosete o strategie similar BGP [Rekhter 95b]. Fiecare membru din grup pstreaz informaii despre costul ctre ceilali membri dar i calea care ne permite obinerea acelui cost. Informaiile despre costul i calea legturii ntre vecini sunt incluse n mesajele de rutare schimbate, arborele de distribuie a datelor fiind construit din calea invers cea mai scurt ntre fiecare membru i surs, la fel ca la protocolul DVMRP Rodriguez 01]. Un membrul M primete pachete de date de la sursa S printr-un vecin N doar dac N este urmtorul hop pe calea cea mai scurt de la M la S. Membrul M trimite pachetele pentru toi vecinii care au ca urmtor hop pe membrul M, pentru a ajunge la sursa S. Metrica folosit pentru alegerea cilor este ntrzierea legturii ntre vecini, fiecare nod estimnd independent ntrzierea legturilor, iar arborele astfel obinut se adapteaz la dinamica reelei. Pierderile de pachete apar din cauza strilor de tranziie care se datoreaz ne convergenelor tabelelor de rutare. Pierderi de pachete pot aprea i la prsirea grupului de un membru sau prin eliminarea unei ci. Pentru evitarea acestora se pot transmite datele pe vechea rut pn la momentul convergenei tabelelor de rutare. Acest lucru a fost realizat prin introducerea unei funcii care msoar costul rutrii, valoarea unei rute obinut cu aceast funciei fiind mai mare dect a unei ci valide i mai mic dect infinit. Un membru care prsete arborele anun tuturor membrilor cu care a avut cale direct un cost obinut folosind funcia precedent. Operaiile cu vectori distan i oblig pe membrii care au avut cale direct prin M s-i aleag alt rut valid, iar membrul care prsete grupul continu s transmit pachete pn n momentul n care nu mai este folosit de nici un alt membru. HyperCast Protocolul HyperCast permite crearea i meninerea topologiilor logice overlay ntre aplicaiile, oferind astfel posibilitatea transferului de date ntre acestea. Aplicaiile se auto-organizeaz formnd o reea logic suprapus, datele fiind transmise pe cile acestei reele cu ajutorul mecanismelor unicast. Fiecare aplicaie comunic doar cu vecini din reeaua overlay, nu cu toate nodurile. O reea overlay este o reea virtual creat peste reeaua fizic ce include routerele i legturile dintre acestea. Fiecare legtur logic din aceast reea virtual const ntr-o cale unicast ntre dou aplicaii/noduri [HyperCast 06]. HyperCast ofer dou metode pentru crearea de topologii overlay, folosind hipercuburi logice i folosind triangulaia Delaunay. Caracteristica principal a topologiilor HyperCast este c datele sunt transmise imediat dup formarea topologiei, fr a fi necesar un protocol de rutare. Criteriile pentru evaluarea unei topologii overlay sunt [HyperCast 06]: necesitatea informaiilor globale: scalabilitatea unei topologii overlay este limitat deoarece informaia de stare dintr-un nod crete puternic odat cu creterea numrului nodurilor din topologie. Ambele metode de creare a topologiei overlay limiteaz informaia de stare dintr-un nod. efortul de a construi i menine o topologie overlay: ntr-un caz ideal, numrul calculelor fcute odat cu aderarea sau prsirea topologiei de ctre un membru trebuie s fie constant. Topologia hipercub respect aceast condiie doar la adugarea unui nod nu i la prsire, iar triangulaia Delaunay respect acest criteriu doar n medie. necesitatea unui protocol de rutare: transmisia datelor ntr-o topologie overlay necesit meninerea unei tabele de rutare care determin urmtorul hop. n alte tehnologii overlay fiecare nod este nevoit s ruleze un algoritm de rutare cu cale minimal pentru stabilirea tabelelor de rutare. Folosirea HyperCast cu triangulaie Delaunay sau cu hipercuburi implic utilizarea unor adrese logice pentru noduri, adrese care determin urmtorul hop, eliminnd astfel necesitatea unui protocol de rutare. potrivirea ntre topologia overlay i cea fizic: n reelele overlay transferul de date se face la stratul aplicaie, astfel pachetul poate traversa Internetul de mai multe ori nainte de a ajunge la destinaie. n consecin resursele disponibile nu sunt folosite n mod eficient i pot aprea ntrzieri nedorite n comparaie cu transmisia la stratul reea. Aceste dezavantaje apar la majoritatea reelelor overlay, deci i la tehnologia HyperCast, deoarece topologia este creat fr a lua n considerare topologia fizic. Reele overlay folosind triangulaia Delaunay n aceast seciune se prezint triangulaia Delaunay (Delaunay Triangulation DT), folosit pentru a construi reele overlay cu mii de noduri. Triangulaia Delaunay pentru o mulime de vrfuri A nsemn c pentru fiecare cerc circumscris unui triunghi format din trei vrfuri care aparin mulimii A nu exist alt vrf n interiorul cercului respectiv (fig. 5.57). Fiecare vrf n DT are coordonate de tipul (x, y) care sunt puncte din plan. Trinagulaia Delaunay a fost studiat n geometria computaional [de Berg 97] i aplicat n multe domenii ale tiinei i ingineriei, inclusiv a reelelor de telecomunicaii [Baccelli 99].

Copyright Tudor Mihai BLAGA 2010-2011, All rights reserved

13

Tudor Mihai BLAGA DOMOTIC: CLDIRI INTELIGENTE Curs

Fig. 5.57 Triangulaia Delaunay Pentru a putea forma o reea overlay DT fiecare aplicaie, numit n continuare nod, este asociat cu un vrf n plan cu coordonatele (x, y). Coordonatele sunt definite printr-un mecanism extern i ar trebui s reflecte locaia geografic a nodului. Dou noduri au o legtur logic dac vrfurile corespunztoare sunt conectate de o latur n triangulaia Delaunay asociat tuturor nodurilor. Avantajul topologiilor overlay DT este c pot fi construite n mod distribuit i rapid. n reelele DT fiecare nod are n medie ase vecini, iar n cazul cel mai defavorabil N-1, unde N este numrul nodurilor. Dac coordonatele unui nod din DT reflect localizarea geografic atunci nodurile apropiate din reeaua overlay sunt apropiate i din punct de vedere geografic, totui acest mecanism nu ine cont de infrastructura stratului reea. Proprietile triangulaiei Delaunay sunt [Liebeherr 01]: ntre orice pereche de vrfuri DT exist un set de ci alternative distincte, existena acestor ci putnd fi exploatat de aplicaii n cazul n care un nod se defecteaz sau nu mai rspunde. numrul legturilor unui vrf este n medie mai mic dect ase, iar n cea mai dezavantajoas situaie el este N-1, unde N este numrul tuturor vrfurilor. odat cu realizarea topologiei dispunem de informaie de rutare care este coninut n coordonate, astfel nu mai este nevoie de un protocol de rutare topologiile DT se realizeaz i se ntrein n mod distribuit. Reele overlay folosind hipercuburi Un hipercub (HyperCube - HC) n-dimensional este un graf cu N=2n noduri, n care fiecare nod este etichetat cu un ir de caractere de forma kn......k1, unde ki = {0,1}. Nodurile din hipercub sunt conectate de o latur dac i numai dac etichetele lor difer doar printr-un bit. Un hipercub de dimensiunea n=3 este prezentat n fig. 5.58.

Fig. 5.58 Hipercub tridimensional Deoarece numrul membrilor unui grup multicast este rareori o putere a lui doi va trebui s lucrm cu hipercuburi n care anumite poziii nu sunt ocupate. Numim un hipercub incomplet, dac are N noduri cu N<2n. n cazul hipercuburilor incomplete trebuie respectate urmtoarele condiii: compact: dimensiunea hipercubului va fi ct mai redus posibil n=log2N. includerea integral a arborilor: asigur prezena fiecrui nod din hipercubul incomplet n arborele de distribuie, aa cum se poate vedea n fig. 5.59.

14

Copyright Tudor Mihai BLAGA 2010-2011, All rights reserved

Tudor Mihai BLAGA DOMOTIC: CLDIRI INTELIGENTE Curs

Fig. 5.59 Arbore de distribuie ncoporat n hipercub incomplet Prima condiie poate fi ndeplinit prin reetichetarea nodurilor atunci cnd un nod prsete hipercubul. Garantarea includerii integrale a arborilor se realizeaz prin folosirea codul Gray pentru a ordona sau a aduga noduri n hipercub. Codul Gray este folosit pentru construcia arborilor de distribuie din hipercuburi incomplete, un nod cu eticheta G(i) calculnd eticheta nodului printe din arborele de distribuie cu nodul rdcin avnd eticheta G(r). Algoritmul const n schimbarea unui singur bit. Arborele construit astfel are urmtoarele proprieti: lungimea cii ntre un nod i rdcin este dat de distana Hamming ntre etichete. dac N=2n, arborele este binomial (N numrul nodurilor). pentru un hipercub incomplet i compact arborii obinui din algoritm sunt inclui integral. Protocolul HyperCast poate ordona i menine membrii unui grup multicast ntr-o structur logic de tip hipercub, astfel nct s se poat implementa servicii fiabile multicast, protocolul ne fiind folosit pentru transmisia datelor. Acesta folosete avantajele oferite de serviciile IP multicast, un membru al grupului multicast putnd deveni membru al unei structuri hipercub prin nscrierea la un canal de control. Fiecare nod poate primi sau trimite mesaje pe acest canal de control. Nodurile din hipercub au adrese logice i fizice. Adresa fizic este adresa IP a nodului i portul UDP folosit pentru transmiterea unicast a mesajelor, fiecare nod avnd o adres fizic unic. Adresa logic este eticheta format dintr-un ir de bii care determin poziia nodului n hipercub. Pentru un hipercub mdimensional sunt necesari m bii pentru adresa logic a nodului. Protocolul HyperCast reprezint adresele logice pe 32 de bii cu un bit rezervat pentru a desemna adresele logice invalide, teoretic protocolul permind 231 noduri. Se spune c hipercubul este ntr-o stare stabil dac are urmtoarele caracteristici: consistent: nu exist noduri cu aceeai adres logic. compact: ntr-un grup multicast cu N noduri, nodurile sunt etichetate de la G(0) pn la G(N-1) conectat: fiecare nod cunoate adresa fizic a vecinilor din hipercub. Ataarea sau detaarea nodurilor din hipercub i defectele aprute n reea, pot conduce la instabilitatea hipercubului i astfel la nendeplinirea condiiilor anterior menionate. Sarcina protocolului HyperCast este de a menine stabilitatea hipercubului ntr-un mod eficient i sigur.

5.2.9 Parametrii de performan AGCS

Mai muli parametri au fost folosii pentru a evalua performanele i implicaiile asupra reelei a sistemelor AGCS n [El-Sayed 03; Blaga 07], parametrii fiind mprii n dou clase. Prima clas se refer la calea pe care se realizeaz transmisia datelor: stres (stress): definete ncrcarea unei legturi ca fiind numrul de pachete identice transportat, valoarea optim 1 obinndu-se folosind rutarea multicast. utilizarea resurselor (resource usage): se definete drept suma produsului ntre ntrziere i stres pe toate legturile l care particip la distribuia datelor). Acest parametru evalueaz efectul asupra ntregii reele, presupunnd c legturile cu ntrzieri mari sunt mai costisitoare.

R = d i * si
i =1

ntindere (stretch): este raportul ntre ntrzierea dintre noduri folosind topologia de distribuie suprapus i ntrzierea de-a lungul ci directe unicast ntre acestea. Acest parametru se mai numete ntrziere relativ ntre surs i un receptor (relative delay penalty). A doua clas de parametri se refer la performanele staiei finale: pierderi n caz de defeciune (losses after failures): ne d numrul mediu de pachetele pierdute ca urmare a defectrii unui singur nod.

Copyright Tudor Mihai BLAGA 2010-2011, All rights reserved

15

Tudor Mihai BLAGA DOMOTIC: CLDIRI INTELIGENTE Curs timpul pn la primul pachet (time to first packet): definete timpul dup care un nou membru care s-a nscris la grup ncepe s recepioneze date. traficul de control (control overhead): meninerea topologiei AGCS are un cost din punctul de vedere al informaiei de control schimbate, adic numrul de mesaje procesate i debitul transmis.

5.4 Referine
[Baccelli 99] F. Baccelli, D. Kofman & J.-L. Rougier. Self organizing hierarchical multicast trees and their optimization. In IEEE INFOCOM, 1999. [Bag-Mohammadi 05] M. Bag-Mohammadi, N. Yazdani & S. Samadian-Barzoki. On the Efficiency of Explicit Multicast Routing Protocols. In 10th IEEE Symposium on Computers and Communications (ISCC2005), 2005. [Billhartz 97] Tom Billhartz, J. Bibb Cain, Ellen Farrey-Goudreau, Doug Fieg & Stephen Gordon Batsell. Performance and Resource Cost Comparisons for the CBT and PIM Multicast Routing Protocols. IEEE Journal on Selected Areas in Communications, vol. 15, no. 3, pages 304315, 1997. [Blaga 05] Tudor Mihai Blaga, Virgil Dobrota, Kris Steenhaut, Ionut Trestian & Gabriel Lazar. Steps Towards Native IPv6 Multicast: CastGate Router with PIM-SM Support. In Proceedings of the 14th IEEE Workshop on Local and Metropolitan Area Networks LANMAN 2005, September 2005. [Blaga 06] Tudor Mihai Blaga & Virgil Dobrota. Evaluating and Improving Alternative Multicast Solutions, CastGate and CastGate with PIM-SM. In COST290, 5th Management Committee Meeting, February 2006. [Blaga 07] Tudor Mihai Blaga, Contribuii la mbuntirea rutrii multicast, tez de doctorat, Universitatea Tehnic din Cluj-Napoca, 2007. [Boivie 05] R. Boivie, N. Feldman, Y. Imai, W. Livens, D. Ooms & O. Paridaens. Explicit Multicast (Xcast) Basic Specification. draft-ooms-xcast-basicspec-09.txt, December 2005.

16

Copyright Tudor Mihai BLAGA 2010-2011, All rights reserved

Tudor Mihai BLAGA DOMOTIC: CLDIRI INTELIGENTE Curs [Buzila 07] A. Buzila, G. Lazar, T. Blaga, V. Dobrota, Evaluation of QoS Parameters for IPTV, The Scientific Bulletin "Acta Technica Napocensis" Electronics And Telecommunications, Technical University of ClujNapoca, Cluj-Napoca, Romania, vol. 48, nr. 3, 2007, pp.9-14. [Deering 89] S.E. Deering. Host extensions for IP multicasting. RFC 1112 (Standard), August 1989. Updated by RFC 2236. [Dobrot 03b] Virgil Dobrot. Reele digitale n telecomunicaii. Volumul III: Osi si TXP/IP. Editura Mediamira, Cluj-Napoca, 2003. [Doyle 01] Jeff Doyle. Routing tcp/ip, volume ii. Cisco Press, 2001. [El-Sayed 03] Ayman El-Sayed, V. Roca & L. Mathy. A Survey of Proposals for an Alternative Group Communication Service. IEEE Network, no. January-February, pages pp. 4651, 2003. [ESM 06] ESM. End System Multicast. http://esm.cs.cmu.edu/, 2006. [Estrin 98] D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma & L. Wei. Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification. RFC 2362 (Experimental), June 1998. [Fenner 97] W. Fenner. Internet Group Management Protocol, Version 2. RFC 2236 (Proposed Standard), November 1997. Obsoleted by RFC 3376. [HyperCast 06] HyperCast. HyperCast General Information. http://www.cs.virginia.edu/mngroup/hypercast/general.html, 2006. [Li 05] Dan Li, Jianping Wu, Ke Xu, Yong Cui, Ying Liu & Xiaoping Zhang. Performance Analysis of Multicast Routing Protocol PIM-SM. In Proceedings of the Advanced Industrial Conference on Telecommunications Service Assurance with Partial and Intermittent Resources Conference/E-Learnig on Telecommunications Workshop, July 2005. [Liebeherr 01] J. Liebeherr & M. Nahas. Application-layer Multicast with Delaunay Triangulations. In Global Internet Symposium, IEEE Globecom, 2001. [Liefooghe 02] Pieter Liefooghe. An Architecture for Seamless Access to Multicast Content. Phd thesis, Vrije Universiteit Brussel, 2002. [Liefooghe 04a] Pieter Liefooghe. CastGate: An Auto-Tunneling Architecture for IP Multicast. Draft-liefooghecastgate-02.txt, October 2004. [Liefooghe 04b] Pieter Liefooghe, M. Goossens, A. Swinnen & B. Haagdorens. The VUB Internet Multicast "CastGate" Project. Technical Report 10/2004 v1.8, Vrije Universiteit Brussel, 2004. [Moy 94] J. Moy. Multicast Extensions to OSPF. RFC 1584 (Proposed Standard), March 1994. [Parkhurst 99] William Parkhurst. Cisco multicast routing & switching. McGraw-Hill, 1999. [Rekhter 95b] Y. Rekhter & T. Li. A Border Gateway Protocol 4 (BGP-4). RFC 1771 (Draft Standard), March 1995. Obsoleted by RFC 4271. [Rodriguez 01] Adolfo Rodriguez, J. Gatrell, J. Karas & R. Peschke. Tcp/ip tutorial and technical overview. IBM, 2001. [Shin 01a] M.K. Shin, Y.J. Kim, J. Lee & S.H. Kim. Explicit Multicast Extension (Xcast+) Supporting Receiver Initiated Join. draft-shin-xcast-receiverjoin-01.txt, 2001. [Shin 01b] M.K. Shin, Y.J. Kim, K.S. Park & S.H. Kim. Explicit Multicast Extension (Xcast+) for Efficient Multicast Packet Delivery. ETRI Journal, vol. Volume 23, no. Number 4, 2001. [Ueno 00] Seiji Ueno, Toshihiko Kato & Kenji Suzuki. Analysis of Internet Multicast Traffic Performance Considering Multicast Routing Protocol. In Proceedings of the 2000 International Conference on Network Protocols, November 2000. [Vida 04] R. Vida & L. Costa. Multicast Listener Discovery Version 2 (MLDv2) for IPv6. RFC 3810 (Proposed Standard), June 2004. Updated by RFC4604. [Waitzman 88] D. Waitzman, C. Partridge & S.E. Deering. Distance Vector Multicast Routing Protocol. RFC 1075 (Experimental), November 1988.

Copyright Tudor Mihai BLAGA 2010-2011, All rights reserved

17