Descrierea Algoritmilor Folositi In Protocoalele de Rutare. Implementarea Protocolului Dvmrp

Capitolul I

Introducere

DVMRP a fost sursa tuturor rutărilor multicast inițiale (backbone sau Mbone). Cum tehnologia a evoluat, rolul său a fost redus în multe locuri, dar rămâne încă la baza tuturor rutărilor Mbone. În continuare vom vedea unul dintre cele mai folosite protocoale de rutare și anume, protocolul de rutare multicast distanță-vector (DVMRP). În realitate, DVMRP este un pic mai mult decât un simplu protocol de rutare. Pentru furnizarea suportului necesar, protocolul este alcătuit din două părți principale: un protocol de informare și o strategie pentru expedierile actuale ale transmisiilor multicast. Ca protocol al rutării informației, DVMRP este derivat din mult acceptatul RIP, cu modificările pentru suportarea distribuției traficului multicast. Au existat doi algoritmi principali folosiți pentru mecanismele de furnizare. Originalul DVMRP folosește algoritmul TRPB. Mai recent, a fost introdus un algoritm numit RPB (Reverse Path Broadcasting).

DVMRP a fost sursa rutării Mbone inițiale. Odată cu avansul tehnologic, rolul său a fost micșorat în multe locuri, dar rămâne încă la baza tuturor rutărilor Mbone. Face parte dintr-o clasă a algoritmilor de rutare numiți “dense mode”. În această clasă de algoritmi rutele sunt definite în așa manieră încât participarea multicast este grupată într-o zonă particulară a rețelei.

Similaritățile dintre DVMRP și RIP constau în principal în modul în care cele două protocoale identifică rutele. Amândouă se bazează pe mecanismul vector distanță în care fiecare ruter acumulează și expediază metrica distanțelor unor locații destinație. Principala distincție intre cele două protocoale este aceea că în timp ce RIP este folosit în măsurarea și identificarea rutelor spre adresele destinație, DVMRP este preocupat în principal cu identificarea rutelor spre sursa transmisiilor multicast. Identificarea acestei informații dotează ruterele cu abilitatea de determinare a căilor căutate de expediere care vor fi folosite pentru expedierea traficului multicast.

În timp ce protocolul de informare este cheia numelui protocolului, mecanismele expedierii traficului sunt integrale ale rețelelor bazate pe DVMRP. Cum traficul multicast este primit de rutere în rețea, el este expediat prin unul dintre cei doi algoritmi generali, depinzând de versiunea particulară a protocolului care a fost implementat. Multicast (punct-la-multipunct) este un model de comunicație în care o sursă gazdă trimite un mesaj spre un grup de gazde destinație. Deși aceasta poate fi realizată și prin trimiterea unor diferite mesaje unicast (punct-la-punct) spre fiecare dintre gazdele destinație, există mai multe motive care fac să se dorească capabilitatea multicast. Primul avantaj major în folosirea multicast este reducerea încărcării rețelei. Sunt multe aplicații care cer trimiterea pachetelor spre sute de stații. Pachetele trimise acestor stații împart un grup de linii pe căile lor spre destinații. Din moment ce multicast cere transmiterea unui singur pachet de la sursă și replicările acestui pachet numai dacă este necesar, transmisia multicast poate conserva atât de mult dorita bandă a rețelei. Alt loc unde transmisia multicast poate fi de un mare folos este în “descoperirea resursei”. Sunt multe aplicații în care o gazdă are nevoie să afle dacă un anumit tip de serviciu este disponibil sau nu. Protocoalele Internet, cum ar fi Bootstrap Protocol (BOOTP) și Open Shortest Path First (OSPF), sunt printre aceste aplicații. Folosirea mesajelor multicast și trimiterea întrebărilor spre aceste gazde sunt potențial capabile să furnizeze acest serviciu care ar fi de un mare ajutor. Deși unele aplicații folosesc mesajele multicast în transmiterea unui pachet spre un grup de gazde aflate pe aceeași rețea, nu există nici un motiv pentru impunerea acestei limitări. Pentru descoperirea serverului domeniu-nume local este necesar ca mesajele multicast să fie expediate pe rețele străine dacă există mai puțin de un server pe rețea. Scopul pachetelor multicast poate fi limitat prin folosirea câmpului TTL al acestor pachete. O altă trăsătură importantă pentru multicast este suportul ei pentru aplicațiile “datacasting”. În ultimii ani, transmisia multimedia a devenit din ce în ce mai populară. Semnalele audio și video sunt capturate, compresate și transmise unui grup de stații receptoare. În locul folosirii unui set de conexiuni punct-la-punct între nodurile participante, multicast poate fi folosit pentru distribuirea datelor multimedia receptoarelor. In realitate, stațiile din lume pot să se alăture sau să părăsească o distribuție audio sau video în orice moment. Flexibilitatea în alăturarea și părăsirea unui grup furnizată de multicast poate face mult mai ușor de suportat variabilitatea membrilor.

Noțiunea de grup este esențială pentru conceptul multicast. Prin definiție, un mesaj multicast este trimis de la o sursă spre un grup de gazde destinație. În distribuția multiplă IP, grupurile multicast au un ID numit identificatorul grupului multicast. Oricând un mesaj multicast este transmis în afară, un ID al grupului multicast specifică grupul destinație. Aceste ID-uri sunt de fapt un set de adrese IP ce aparțin clasei D de adrese. De aceea, dacă o gazdă vrea să primească mesaje multicast trimise unui grup particular, trebuie să asculte cumva toate mesajele trimise acelui grup particular.

Dacă sursa și destinația unui pachet multicast împart un “bus” comun, fiecare gazdă trebuie să cunoască doar care grupuri au membrii în procesele acelei gazde. În orice caz, dacă sursa și destinația nu sunt pe același LAN, expedierea mesajelor multicast spre destinații devine mai complicată. Pentru a rezolva problema rutării Internet-wide a mesajelor multicast, gazdele trebuie să se alăture unui grup prin informarea ruterului multicast de pe subrețeaua lor. Internet Group Management Protocol (IGMP) este folosit în acest scop. Părăsirea unui grup este făcută și prin IGMP. În acest fel ruterele multicast ale rețelelor știu membrii grupurilor multicast de pe rețeaua lor și pot decide dacă să expedieze un mesaj multicast pe rețeaua lor sau nu. În orice moment în care un ruter multicast primește un pachet multicast, verifică ID-ul grupului mesajului și expediază pachetul numai dacă există un membru al acelui grup în rețelele conectate la el.

IGMP furnizează informația cerută în ultima parte a expedierii mesajului multicast destinațiilor sale. În orice caz, pentru furnizarea pachetului multicast de la sursă spre nodurile destinație de pe alte rețele, ruterele multicast trebuie să schimbe informațiile pe care le-au adunat de la grupul membrilor gazdelor conectate direct la ele.

Există mai mulți algoritmi diferiți, cum ar fi: “flooding”, “spanning tree”, “reverse path broadcasting” și “reverse path multicasting”, pentru schimbul informației de rutare între rutere. Unii dintre acești algoritmi sunt folosiți în protocoalele de rutare multicast dinamice, cum ar fi Distance-Vector Multicast Routing Protocol (DVMRP), Multicast extension to Open Shortest Path First (MOSPF) și Protocol Independent Multicast (PIM). Bazându-se pe informația de rutare obținută dintr-un asemenea protocol, oricând un pachet multicast este trimis în afară spre un grup multicast, ruterele multicast vor decide dacă să expedieze pachetul rețelelor lor sau nu. În sfârșit, ruterele frunză vor vedea dacă există măcar un membru al acelui grup particular pe rețelele fizice atașate bazându-se pe informația IGMP și decid dacă să expedieze pachetul sau nu.

Capitolul II

Modelul multicast

Prima îmbunătățire funcțională importantă a Internet-ului, care a făcut atractivă video-conferința, a fost introducerea multicast. Pe scurt, multicast reprezintă abilitatea rețelei de a eficientiza furnizarea informației mai multor recipiente. Cea mai bună analogie care se poate face este cu transmisia radio și TV. Spectrul electromagnetic este divizat în două frecvențe care sunt alocate, de anumite autorități, stațiilor TV și radio.

Figura 2.1: Modelul multicast Internet

Modelul de furnizare al pachetului multicast, arătat în figura 2.1, este similar cu broadcast, însă superior. Un computer gazdă, capabil de multicast pe Internet, rulează o aplicație în care primește alăturări simple unicast ale unui set de receptoare de pe rețea, identificate de o adresă a grupului.

Adresele grup sunt extensii ale schemei de adresare Internet, pentru a furniza adrese desemnate dinamic pentru un set de interfețe cu un singur identificator. Efectele alăturării unui computer gazdă la un grup multicast sunt:

Gazda își reprogramează interfața de rețea pentru a primi pachetele adresate grupului adițional care a fost folosit pentru multicast

Gazda informează ruterele apropiate de faptul că există cel puțin o destinație pentru pachete al acelor adrese multicast.

Grupurile sunt deosebite prin adresele multicast separate pe care le au. Alocarea adresei multicast este dinamică în general și sub controlul colecției utilizatorilor. Aceasta este în contrast cu frecvența alocată în spectrul electromagnetic, unde banda (în sensul numărului diferitelor frecvențe posibile) este o resursă săracă în comparație cu numărul adreselor multicast de pe Internet. In domeniul radio și TV, frecvențele sunt alocate sub legile și tratatele naționale și globale. In Internet, există unele mecanisme pentru managementul adreselor multicast. Este instructiv să se compare natura programabilă soft, dinamică, a grupurilor multicast cu mai multe modele de rețele conectate telefonic.

Un computer gazdă nu trebuie să fie într-un grup multicast pentru a fi capabil să îi trimită. Oricine, oriunde, oricând, poate trimite un pachet oricărui grup. Gazdele pot lua parte la mai multe sesiuni multicast.

Dacă un utilizator primește audio de la mai multe surse trimițătoare aceleiași sesiuni, utilizatorul dorește, probabil, să le asculte. Dacă primește mai multe sesiuni video, va vrea să se afișeze întrebări diferite unei capacități a rețelei și altor adrese. Din moment ce adresele internet sunt folosite pentru fiecare pachet, nu sunt circuite virtuale sau asociații pe termen lung. Folosind multicast, un receptor poate prelua mai mult trafic decât dacă s-ar alătura mai multor grupuri.

Ruterele din Internet care sunt capabile de multicast, folosesc locația grupurilor sau a trimițătoarelor pentru a determina arborele furnizor care este folosit pentru a lua pachete de la sursă spre setul de receptoare. Acest arbore este, în mod uzual, chiar optim în termenii numărului de linii pe care le traversează pachetele. Pachetele nu sunt trimise de mai multe ori pe aceeași linie în orice loc, ele sunt numai copiate în punctele cele mai apropiate.

Să ne imaginăm trimiterea unui memo spre un grup de persoane, dar având numai de tipărit o copie la sursă. Atunci, cum sosește acest memo, oficiul de sortare îl pune în copiator și îl furnizează acelor recipiente, salvând un mare număr de copii de la trimițătorul original spre toate oficiile de sortare, dar la același cost, în loc de copierea în lungul drumului. Acest model de furnizare a avut un mare efect pe drumul pe care programatorii aplicației au învățat să construiască programe multicast.

De exemplu, în telefonia audio, receptoarele trebuie să fie ridicate din furcă. Un apelant particular trebuie să îi sune, pe fiecare la rând și să adauge recipientele la un apel conferință. Există două moduri în care oamenii au ajuns să folosească conferințele multicast pe Internet:

Modelul TV broadcast, unde o întâlnire sau un seminar pot fi văzute și auzite de oricine.

Stilul radio CB, unde utilizatorii discută deschis și interactiv, venind din interiorul sau exteriorul unui loc de întâlnire virtual.

Figura 2.2: Creșterea Mbone

Este instructiv să ne gândim la modurile alternative în care comunicația grup poate fi suportată pe într-o rețea. De exemplu, putem pune o listă a adreselor într-un pachet de informație pe care vrem să îl trimitem unei liste a recipientelor. Aceasrimitem unei liste a recipientelor. Aceasta va funcționa atâta timp cât grupul a fost fixat și rezonabil de mic, dar care devine repede de necontrolat pentru grupuri între 100 și 1000, pe care le-am găsit deja folosind Internetul. O alternativă poate fi de a accesa un server de distribuție central unde să trimitem totul. În loc de aceasta, Internet-ul distribuie multicast atât grupul de control cât și distribuția datelor în rețea. Ruterele expediază pachetele cu destinații multicast folosind adresa grupului sau adresa sursei, împreună cu informația nedistribuită, printr-un protocol de management al grupului, pentru a determina unde să expedieze pachetele.

2.1 Istoria arborilor

Rețeaua multicast are două componente:

Tunelele – sunt folosite pentru a uni site-urile Internet care au rutere capabile de multicast, dar sunt separate de ruterele care nu suportă multicast, acestea formând o topologie virtuală la începutul rutării unicast Internet. S-a dovedit a fi nefolositoare aici, în termenii dezvoltării unei noi versiuni a rutării. Aceasta a dat un suport termenului Mbone, prescurtarea de la Multicast Backbone, care este numele unirii virtuale a ruterelor care interconectează insulele multicast via tunele , prin secțiunile incapabile de multicast ale Internetului.

Distance Vector Multicast Reverse Path routing – acesta este protocolul de rutare actual, care este o extensie naturală le vechiul Routing Information Protocol (RIP), folosind căile care sunt calculate pentru a lua de la un set de surse S spre o destinație particulară, D pentru unicast, ca un mod de a lua multicast de la S spre D.

DVMRP folosește o schemă numită “curățare” pentru eliminarea ramurilor de la rețea, care nu conțin membrii ai unui grup când o sursă începe să transmită. Cum Mbone a crescut (la începutul anului 1995 avea 1500 de site-uri, unde un site putea fi un laborator de cercetare sau un Campus universitar, în 22 de țări), au existat multe grupuri care erau mici și împrăștiate. Aceasta însemna că volumul controlului de rutare, suprapusă peste traficul de curățare, au determinat oamenii să regândească schema de rutare.

Au rezultat câteva alternative:

MOSPF (extensia Multicast la OSPF), care permite agrearea traficului și a grupurilor și permite, de asemenea, căile ce vor fi alese, bazându-se pe diferite tipuri de serviciu.

CBT se bazează pe un manager care plasează o “inimă” sau un ruter central, apropiat, în rețea, prin calcularea locului pe unde va trece tot traficul de rutare, dacă se formează un arbore spanning minim de la centru spre toate locurile. Va rezulta o folosire mai mică a liniilor decât la DVMRP și nu necesită curățare, dar poate mări întârzierile în căi între utilizatori, ceea ce poate fi critic pentru unele tipuri de interacțiuni multimedia.

PIM se bazează pe un amestec al ideilor de la CBT și DVMRP și se bazează, în principal, pe rutarea unicast pentru calcularea căilor. Este, de asemenea, capabil de exploatarea regulilor privitoare la rute, incluzând, poțențial, tipul de serviciu al selectării căilor.

2.2 Calcularea rutei multicast

Pentru rețelele de date (IP, Novell sau CLNP), există două abordări de bază pentru calcularea rutelor multicast.

Calcularea unui arbore RPM de la fiecare sursă – aceasta este esențială, doar că arborele este făcut pentru rutele unicast de la destinație spre sursă și poate fi construit la cerere, când pornește sursa și înlăturat, când sursele se opresc, prin extragerea lor din tabelele de rutare unicast.

Se găsește centrul grupului și se construiește un arbore de la el spre ei. Această schemă este folosită de CBT și este o parte a bazei noului protocol de rutare PIM, care comută între modul 1 și modul 2, în funcție de faptul că un grup este împrăștiat sau dens.

In final, un singur arbore este bun pentru minimizarea întârzierilor printre toți participanții, în timp ce un arbore sursă specific poate fi mai bun, în termenii folosirii optime a liniilor și poate rezulta o mai bună întârziere specifică sursei.

2.3 Concepte și terminologia DVMRP

DVMRP furnizează un mecanism, pentru rutare, de propagare a datelor multicast într-o manieră care minimizează numărul de copii în exces trimise oricărei rețele particulare. DVMRP este un protocol multicast dense-mode.

2.3.1 Conexiunile vecine

În mediul DVMRP, vecinii sunt rutere multicast care sunt conectate direct sau printr-un tunel. Vecinii conectați direct sunt rutere care au o interfață la aceeași rețea. Vecinii conectați prin tunel sunt rutere multicast care comunică printr-o rețea unicast, schimbând mesaje DVMRP încapsulate în datele IP. În figura 2.3, de exemplu, ruterul A multicast are doi vecini, ruterul B și ruterul C. Ruterele A și B sunt conectate direct-amândouă au interfețe cu rețeaua 6. Ruterele A și C comunică printr-un tunel care include un ruter unicast.

La start, un ruter multicast DVMRP:

Își inițializează tabelul de rutare cu informarea tuturor interfețelor lui locale.

Află de existența vecinilor prin trimiterea unei probe pentru toate ruterele, pe fiecare interfață multicast.

Primește rapoarte de la vecinii săi, conținând informația de rutare (incluzând costurile rutei).

În figura 2.3, ruterul D devine activ și emite probe de rutare pe patru interfețe multicast. Ruterul D primește rapoarte de la vecinii săi multicast, ruterele B, C și E.

Figura 2.3: Ruterele multicast

2.3.2 Anunțarea rutei sursei

O rețea sursă este orice rețea conținând gazde care au capacitatea de a emite date multicast. DVMRP anunță calea cea mai scurtă la rețelele sursă multicast. Periodic, fiecare ruter multicast emite informația de rutare întreagă sau parțială pe fiecare circuit DVMRP, folosind mesajele raport DVMRP. Informația de rutare reprezintă costul pentru ca ruterul trimițător să ajungă la rețeaua sursă specificată (costul este suma salturilor metrice de-a lungul celei mai scurte căi la rețeaua sursă dată ).

Pe baza recepționării unui raport DVMRP de la un alt ruter, DVMRP reexaminează tabelul său de rutare pentru a determina dacă informația despre cea mai scurtă cale trebuie să fie modificată. DVMRP caută în tabelul de rutare o intrare care descrie o rută la aceeași rețea sursă. Dacă există una, DVMRP compară costul celor două rute. DVMRP păstrează ruta cu costul cel mai mic în tabelul de rutare. Un ruter nu va trimite raporturi ale rutei pe o interfață, până când va ști că are un ruter multicast vecin pe acea interfață. Va continua să trimită, periodic, probe pe o interfață.

2.4 Cum alege DVMRP rutele

Fiecare interfață DVMRP este configurată cu o metrică care furnizează costul saltului. Un ruter care primește multe rapoarte ale rutei pentru aceeași rețea sursă multicast, compară costul specificat în fiecare și păstrează informația de la raport cu cel mai mic cost în tabelul său de rutare. Metrica rutei reprezintă suma tuturor metricilor interfeței de la o rută sursă dată la un ruter dat (în mod curent, mrouted restricționează o rută la o valoare a metricii de 31 sau mai puțin).

În figura 2.3, ruterul D primește două rapoarte pentru rețeaua conectată la ruterul A, una de la ruterul B și una de la ruterul C. folosind metrica conținută în raporturile rutei, ruterul D determină când costul unei rute tunel este mai mare decât costul rutei care folosește direct conexiunile fizice. Ruterul D descarcă ruta primită de la ruterul B.

Ruterul D declară că ruterul B este următorul salt vecin și interfața d1 este interfața următorului salt. Odată ce a fost declarat următorul salt veci pentru o rută, ruta modifică primirile de la acel vecin pentru ruta luată anterior până când, fie expiră ruta, fie alt ruter anunță o metrică mai bună pentru acea rută.

2.5 Tabelul de rutare și cel de expedieri

Principalele noțiuni în intrarea unui tabel de rutare sunt:

Adresa subrețelei sursă și masca – adresa și masca unei subrețele conținând datele multicast ale sursei gazdă.

From-gateway – saltul ruterului, anterior, care duce înapoi la subrețeaua sursă.

TTL – numărul de secunde înainte ca această intrare să fie mutată din tabelul de rutare.

De notat că subrețeaua sursă și saltul ruterului anterior în tabelul de rutare DVMRP sunt în opoziție cu subrețeaua destinație și cu noul salt al ruterului în tabelul de rutare RIP.

Folosind aceste informații, ruterul poate :

Să primească date multicast și să determine dacă datele au sosit pe interfața care este pe calea cea mai scurtă spre rețeaua sursă.

Să arunce datele dacă acestea nu au sosit pe interfața “calea cea mai scurtă”.

Să trimită datele multicast tuturor vecinilor DVMRP activi.

Odată ce DVMRP a recepționat datele multicast de pe o interfață și a trimis datele vecinilor săi, DVMRP creează o intrare pentru date în tabelul de expediere pentru interfață.

Principalele noțiuni într-o intrare a tabelului de expediere sunt:

Subrețeaua sursă – subrețeaua care conține o gazdă ce este sursa datelor multicast adresate grupurilor specificate.

Grupul multicast – adresa destinație a Clasei D care identifică grupul spre care au fost trimise datele.

Interfața Inbound – interfața pe care au sosit datele multicast.

Interfața Outbound – interfața de pe care sunt expediate datele multicast.

2.6 Arborii “calea cea mai scurtă”

Informația de rutare folosită de DVMRP este independentă de orice altă informație de rutare folosită de ruter – de exemplu, rutele furnizate de RIP. Scopul informației de rutare este de a crea o intrare arbore “calea cea mai scurtă” în tabelul de rutare pentru propagarea datelor multicast. Această intrare indică interfața care furnizează calea cea mai scurtă spre rețeaua care este sursa datelor multicast.

În figura 2.3, de exemplu, tabelul de rutare de pe ruterul D include o intrare care descrie ruta cea mai scurtă la rețeaua conectată la ruterul A. Intrarea indică interfața d1 care furnizează calea cea mai scurtă spre rețeaua sursă.

Un arbore “calea cea mai scurtă” indică, de asemenea, acele interfețe care sunt pe calea cea mai scurtă spre acea rețea sursă de la un ruter vecin. Ruterul E consideră rețeaua conectată la ruterul D ca fiind calea cea mai scurtă la rețeaua sursă conectată la ruterul A.

Dacă ruterele vecine au aceeași metrică spre o rețea sursă dată, ruterul cu cea mai mică adresă IP va fi responsabil cu propagarea traficului multicast creat de acea rețea sursă de pe rețeaua sau tunelul care este comun ruterelor vecine. O rețea care nu este pe calea cea mai scurtă la rețeaua sursă de la ruterul multicast, este considerată ca fiind frunză. În figura 2.3, rețeaua conectată la ruterul E – rețeaua 5 este o rețea frunză.

2.7 Folosirea protocolului DVMRP

DVMRP este un protocol de rutare care rulează pe stațiile de lucru UNIX prin comprimarea MBONE. Rezultatul se va numi “mrouted”.

DVMRP permite următoarele:

Folosirea ruterului în Mbone ca o completare la stațiile UNIX.

Substituirea domeniilor MOSPF pentru colectarea tunelelor DVMRP, micșorând solicitarea benzii.

2.7.1 Modurile DVMRP

Se poate rula DVMRP/MOSPF în unul dintre următoarele trei moduri (modurile sunt menționate în ordinea creșterii funcționalității):

Modul 1 – Ruterul funcționează ca un ruter DVMRP obișnuit. Se comportă ca o stație UNIX care rulează programul “mrouted”. Ruterul poate rula DVMRP pe interfețele sale LAN și poate suporta tunele (numai cele încapsulate).

Modul 2 – ruterul se poate alătura unui domeniu MOSPF al Mbone via unul sau mai multe tunele DVMRP (încapsulate). În acest mod, rețelele MOSPF selectate intern sunt anunțate într-un sistem DVMRP al Mbone. Un subset al surselor DVMRP este anunțat în sistemul MOSPF.

Un domeniu MOSPF alăturat lui Mbone în acest fel primește rezultatele curățării MOSPF. De aceea, numai acele date multicast cu grup de membrii activi sunt expediate în domeniul MOSPF.

Modul 3 – ruterul rulează ca un ruter Mbone folosind un domeniu MOSPF ca pe o rețea de tranzit. În acest mod, DVMRP rulează peste MOSPF ca și cum întregul domeniu MOSPF ar fi un singur LAN. Acest mod permite înlocuirea unei colecții de tunele DVMRP cu un domeniu MOSPF. Această acțiune are ca rezultat o micșorare a traficului multicast.

Se poate folosi ruterul pentru a alătura un domeniu MOSPF la Mbone sau pentru a permite domeniului MOSPF să unească părți din Mbone. Ruterul face aceasta prin permiterea unui schimb limitat de informație între DVMRP și MOSPF.

Pentru ca MBone să expedieze datele multicast cu sursele care aparțin domeniului MOSPF, ruterul trebuie să anunțe anumite rețele interne MOSPF prin intermediul DVMRP. Pentru a evita creșterea dimensiunii tabelului de rutare DVMRP prin anunțarea tuturor rețelelor interne, numai acele rețele specificate ca rangurile adresei ariei în OSPF adăugate la comenzile configurării rangului, sunt anunțate. În particular, aceasta permite agrearea surselor înaintea anunțării DVMRP.

Este posibilă anunțarea a două rute în Mbone, o rută fiind un subset al celeilalte. Convertind, pentru ca domeniul MOSPF să expedieze date multicast care au sursa în altă parte a Mbone, informația de rutare DVMRP (care conține o colecție a surselor ce pot fi atinse) trebuie scursă automat în domeniul MOSPF în forma LSAs extern AS OSPF. Cum atât DVMRP, cât și MOSPF sunt activate în ruter, aceasta se produce automat și nu trebuie să fie configurată.

Modul în care setul precis de rutere DVMRP este scurs în OSPF este următorul:

Ruterul vizualizează întreaga colecție de surse DVMRP. Dacă mai mult de jumătate din surse pot fi atinse prin interfețele non-MOSPF sau tunele DVMRP, este importată o “absență” multicast.

Dacă nu, fiecare sursă DVMRP este importată într-un LSA extern AS separat. Dacă ruterul nu va anunța un LSA extern AS pentru sursa DVMRP (nu este cel mai bun ruter care să folosească traficul unicast destinat sursei), el specifică un cost al LS Infinity în LSA extern AS.

2.7.2 Rularea DVMRP peste MOSPF

Când se folosește domeniul MOSPF pentru alăturarea tunelelor DVMRP, acesta din urmă rulează de fapt peste MOSPF. In acest caz, o interfață DVMRP (VIF) numită MOSPF este creată automat iar modificările și probele DVMRP sunt trimise la adresa multicast 239.0.0.1 (un grup în care toate ruterele rulează simultan alăturări DVMRP și MOSPF).

Ruterul expediază 239.0.0.1 prin domeniul MOSPF, dar nu expediază niciodată 239.0.0.1 pe interfețele și tunelele DVMRP. Adresa 239.0.0.1 nu a fost înregistrată cu Network Interface Card (NIC).

CAPITOLUL III

Descrierea algoritmilor folosiți în protocoalele de rutare

Există trei tipuri de adresare IP: unicast, broadcast și multicast. O adresă unicast este proiectată să transmită un pachet spre o singură destinație. O adresă broadcast este folosită pentru a transmite o cantitate de date spre o subrețea. O adresă multicast este proiectată pentru a activa livrarea de date pentru un grup de gazde care au fost configurate ca membrii ai unui grup multicast într-o diversitate de subrețele. Multicast nu este o conexiune orientată. O cantitate de date multicast este oferită unui grup de membrii destinație cu același “best-effort” ca o cantitate de date standard IP unicast. Aceasta înseamnă că o cantitate de date multicast nu este garantată că va ajunge la toți membrii grupului sau va ajunge în aceeași ordine relativă cu transmiterea altor pachete.

3.1 Adresele Multicast

O adresă IP de clasă D este dată unui grup de noduri care definesc un grup multicast. Cei mai importanți 4 biți ai adreselor clasei D sunt setați la “1110”. Numărul celor 28 biți care urmează acestor 4 biți sunt numiți “multicast group ID”. Unele dintre adresele clasei D sunt notate, pentru unele scopuri, cu Internet Assigned Numbers Authority (IANA). Blocul adreselor multicast cuprins între 224.0.0.1 și 224.0.0.255 este rezervat pentru utilizarea protocoalelor de rutare și al unor alte topologii “low-level” descoperite sau pentru întreținerea protocoalelor.

Adresele cuprinse între 239.0.0.0 și 239.255.255.255 sunt rezervate pentru a fi folosite în aplicațiile “scopuri administrative” pentru site-urile locale și nu pentru aplicațiile Internet-wide. Sunt și alte adrese de clasă D deja rezervate pentru grupurile bine cunoscute cum ar fi “toate ruterele de pe această subrețea”, “toate ruterele DVMRP”, “toate ruterele OSPF”. Formatul adreselor IP de clasă D este arătat în figura 3.1:

Figura 3.1: Clasa D – Formatul adreselor

O cantitate de date multicast este furnizată membrilor grupului cu aceeași încredere ca și pachetele IP unicast. Pierderea pachetului, precum și o furnizare defectuoasă , este posibilă. Ca și pachetele IP unicast, aici va fi o adresă MAC pentru pachetele multicast, cuprinsă între 01:00:5E:00:00:00 și 01:00:5E:7F:FF:FF.

O adresă multicast IP poate fi asociată unei adrese IEEE-802 prin plasarea celor mai puțin importanți 23 biți ai adresei multicast IP în cei 23 biți mai puțin importanți ai adresei multicast MAC. Asocierea unei adrese multicast IP cu o adresă MAC IEEE-802 este arătată în figura de mai jos:

Figura 3.2

De notat că, din cauza procedurii de asociere, vor fi 32 adrese multicast diferite alocate pe aceeași adresă IEEE-802.

3.2 Internet Group Management Protocol (IGMP)

Gazdele dispuse să primească mesaje (pachete) multicast, trebuie să informeze ruterele vecine cele mai apropiate că sunt interesate să primească mesaje multicast trimise anumitor grupuri multicast. În acest fel, fiecare nod poate deveni membru al unuia sau mai multor grupuri multicast și poate să primească pachetele multicast trimise acelor grupuri. Protocolul prin care gazdele comunică această informație cu ruterele lor locale este numit Internet Group Management Protocol (IGMP). IGMP este folosit de asemenea de rutere pentru verificarea periodică dacă membrii grupului cunoscut sunt încă activi.

În caz că există mai mult de un ruter multicast pe o subrețea (LAN) dată, unul dintre rutere este ales ca “întrebător” și își asumă responsabilitatea de a urmării starea membrilor grupurilor multicast care au membrii activi pe subrețeaua lor. Bazându-se pe informația obținută de la IGMP, ruterul poate decide dacă să expedieze mesajele multicast recepționate pe subrețeaua lui sau nu. După recepționarea pachetului multicast, ruterul va verifica să vadă dacă există cel puțin un membru al acelui grup particular pe subrețea. În acest caz, ruterul va expedia mesajul acelei subrețele. Altfel, va descărca (elimina) pachetul multicast. Evident că aceasta va fi ultima fază în furnizarea pachetului multicast.

Există trei versiuni ale IGMP și vom vedea în continuare modificările necesare a fi făcute în gazde pentru a putea folosi acest protocol.

Cum am menționat mai devreme, fundamentale pentru multicast sunt conceptele de alăturare și cel de părăsire ale grupurilor multicast. IGMP asigură o metodă prin care o gazdă poate să se alăture sau să părăsească grupul multicast. IGMP, care este considerat o parte a nivelului IP, are mesaje de mărime fixă, fără alte date opționale.

Fiecare gazdă se poate alătura unui grup multicast sau să părăsească un grup multicast la care s-a alăturat anterior. Mesajele IGMP sunt folosite de rutere pentru urmărirea membrilor grupului din subrețeaua imediat conectată.

Se aplică următoarele reguli:

O gazdă trimite un “raport” IGMP pentru alăturarea la grup

O gazdă nu va trimite niciodată un raport când vrea să părăsească grupul

Ruterele multicast trimit periodic întrebări IGMP (tuturor adreselor gazdelor grupului 224.0.0.1) să vadă dacă există un grup de membrii pe subrețelele lor. Dacă nu este primit nici un răspuns pentru un grup particular după un număr de întrebări, ruterul presupune că nu există nici un membru al grupului pe rețea (conectată fizic la o interfață particulară a ruterului). Trebuie notat că câmpul TTL al mesajelor întrebare este setat la 1 așa încât întrebările să nu fie expediate spre alte subrețele.

Bazându-se pe raporturile pe care le primește un ruter de la gazde, acesta poate decide dacă să expedieze pachetul multicast pe interfața particulară sau nu.

Versiunea a doua a IGMP, care este o îmbunătățire a versiunii originale, include câteva extensii cum ar fi: o procedură pentru alegerea “întrebătorului” multicast pentru fiecare LAN, mesaje de părăsire explicite pentru o curățare mai rapidă. Ruterul cu adresa IP cea mai mică este ales “întrebător”. Mesajul explicit de părăsire a grupului este adăugat pentru a micșora latența protocolului.

Versiunea a treia a IGMP, care este în faza de început, face posibilă, pentru o gazdă, alăturarea la un grup și specifică un set al surselor acelui grup de la care dorește să primească mesaje multicast.

Deși IGMP este un vechi standard Internet, software-ul rețelei gazdelor trebuie modificat pentru:

a suporta transmisia spre și dinspre adresele Clasei D

îmbunătățirea UDP astfel încât să poată primi și trimite multicast

suportarea IGMP

3.3 Grupuri multicast

Gazdele individuale sunt libere să se alăture sau să părăsească grupul multicast în orice moment. Nu sunt restricții ale locațiilor fizice sau ale numărului de membrii într-un grup multicast. O gazdă poate fi membru al mai multor grupuri multicast la un moment dat și nu trebuie să aparțină unui anume grup pentru a trimite mesaje membrilor altui grup.

3.4 Protocolul numărului de membri ai unui grup

Un astfel de protocol este folosit de rutere pentru a afla de prezența unui grup de membrii în subrețeaua atașată lor direct. Când o gazdă se alătură unui grup multicast, transmite un protocol al calității de membru al grupului spre grup că acesta dorește să își regleze procesele IP și interfața de rețea pentru a primi cadre adresate grupului multicast. Receptorul, inițializând procesul de alăturare, va putea să localizeze cea mai apropiată conexiune cu arborele de distribuție multicast.

Figura 3.3. Serviciul de transport IP multicast

3.5 Internet Group Management Protocol (IGMP) – versiunea a doua

Acest protocol funcționează între gazde și ruterele multicast vecine. Mecanismele protocolului permit unei gazde să informeze ruterul său local că vrea să primească transmisii adresate unui grup multicast particular. De asemenea, ruterele întreabă periodic LAN-ul dacă grupul de membrii cunoscuți sunt încă activi.

Dacă există în LAN mai mult de un ruter care execută IP multicast, unul dintre rutere este ales “întrebător” și își asumă responsabilitatea de a întreba rețeaua despre membrii grupului. Bazându-se pe informația despre numărul de membrii ai grupului aflată de la IGMP, un ruter este capabil să determine dacă există un trafic multicast care necesită să fie expediat spre toate subrețelele frunză ale lui. Ruterele multicast folosesc această informație, în legătură cu protocolul de rutare multicast, pentru a suporta distribuția multiplă IP pe Internet.

Ruterele multicast transmit periodic spre HMQ (Host Membership Query) mesaje pentru a determina care grupuri gazdă au membrii în rețelele atașate direct.

Figura 3.4: IGMP – Mesaj de interogare

Mesajele de interogare sunt adresate tuturor gazdelor grupului (224.0.0.1) și cu IP TTL=1. Aceasta înseamnă că sursa mesajelor de întrebare e transmisă de un ruter în subrețeaua atașată direct, dar nu mai este expediată de nici un alt ruter.

Când o gazdă primește un mesaj de interogare, va răspunde cu un raport HMR (Host Membership Raport) pentru fiecare grup gazdă de care aparține. Pentru a evita o încurcătură de rapoarte, fiecare gazdă începe cu un timp de întârziere ales aleator de raport pentru fiecare dintre grupul numărului de membrii. Dacă, în timpul perioadei de întârziere, un alt raport este auzit de același grup, gazda locală își resetează timer-ul la o nouă valoare aleatoare. Astfel, gazda trimite raportul la adresele grupului raportat, provocând resetarea timpilor mesajului de raport ai tuturor celorlalți membrii ai grupului. Această procedură garantează că rapoartele vor fi împrăștiate dincolo de o perioadă de timp și traficul de raport este minimalizat pentru fiecare grup cu cel puțin un membru în subrețea.

Trebuie notat că ruterele multicast nu au nevoie să fie adresate direct din moment ce interfețele lor sunt configurate pentru a primi tot traficul multicast IP. De asemenea, un ruter nu trebuie să mențină o listă detaliată cu gazdele care aparțin fiecărui grup multicast; ruterul are nevoie să știe doar că cel puțin un grup membru se află pe o interfață de rețea. Ruterele multicast transmit periodic întrebări (cereri) pentru a-și spori informațiile despre grupul de membrii prezent în fiecare interfață de rețea.

Dacă ruterul nu primește raportul pentru un grup particular după un număr de cereri, ruterul presupune că grupul de membrii nu mai este prezent în interfață și că grupul este mutat de pe lista grupului numărului de membrii pentru subrețeaua atașată direct.

Când o gazdă se alătură grupului pentru prima dată, ea va transmite imediat un raport pentru grup decât să aștepte o întrebare a ruterului. Aceasta garantează că gazda va recepționa traficul adresat grupului dacă este primul membru al acelui grup pe subrețea. În versiunea a doua a IGMP, ruterul cu cea mai mică adresă IP de pe LAN este ales ca “întrebător” multicast. Tot această versiune definește un nou tip de mesaje întrebare: Group Specific Query. Acest nou tip permite unui ruter să transmită o întrebare unui grup multicast specific. IGMP versiunea a doua definește un mesaj de părăsire a grupului celui mai jos (mic) IGMP: “latența de părăsire”. Când ultima gazdă, pentru a răspunde unei întrebări cu un raport, vrea să părăsească acel grup specific, gazda transmite un mesaj de părăsire a grupului tuturor ruterelor (224.0.0.2) cu câmpul grup setat pentru grup în stânga. Ca răspuns la mesajul de părăsire a grupului, ruterul începe trimiterea mesajelor întrebare a grupului specific pe interfața ce primește mesajul de părăsire a grupului. Dacă nu există nici un raport ca răspuns la mesajele întrebare ale grupului specific, grupul este mutat de pe lista grupului numărului de membrii pentru subrețeaua atașată direct.

3.6 Multicast Forwarding Algorithms

IGMP furnizează pasul final în serviciul de eliberare al pachetelor multicast din moment ce este singurul preocupat cu expedierea traficului multicast din ruterul multicast unui grup de membrii de pe subrețeaua atașată direct. IGMP nu este preocupat cu eliberarea pachetelor multicast între ruterele vecine sau pe o inter-rețea.

Pentru a furniza un serviciu de eliberare Internet-wide, este necesar să se definească protocoale de rutare multicast. Un astfel de protocol este responsabil cu construcția unui arbore de eliberare a pachetului multicast și execuția expedierii pachetului multicast.

Există un număr de algoritmi diferiți care pot fi folosiți de protocoalele de rutare multicast:

Flooding

Spanning Tree

Reverse Path Broadcasting (RPB)

Truncated Reverse Path Broadcasting (TRPB)

Reverse Path Multicasting (RPM)

Core-Based Trees

3.7 Descrierea algoritmilor

3.7.1 Flooding

Tehnica cea mai simplă pentru furnizarea datelor tuturor ruterelor într-o rețea internet este de a implementa un astfel de algoritm. Procedura flooding începe când un ruter primește un pachet ce este adresat unui grup multicast. Ruterul folosește un mecanism protocol pentru a determina fie dacă este prima dată când este văzut acest pachet particular fie dacă a fost văzut acest pachet și înainte. Dacă este prima recepție a pachetului, acesta este expediat tuturor interfețelor, exceptând-o pe cea de la care a venit, garantând că pachetul va ajunge la toate ruterele din internetwork. Dacă ruterul a mai văzut acest pachet înainte, pachetul va fi ignorat.

Un algoritm flooding este foarte simplu de implementat din moment ce ruterul nu trebuie să păstreze un tabel de rutare și este nevoie să păstreze doar calea pachetelor văzute cel mai recent. Acest algoritm face ineficientă folosirea resurselor memoriei ruterului din moment ce fiecărui ruter îi este cerut să păstreze un tabel distinct de intrare pentru fiecare pachet nou văzut.

3.7.2 Spanning Tree

O soluție mai eficientă ar fi selectarea unui subset al tipologiei internet care formează un arbore spanning. Arborele spanning definește o structură arbore unde numai o cale activă conectează oricare două rutere la Internet. Figura 3.5 arată o rețea internetwork și un arbore spanning:

Figura 3.5

Odată ce arborele spanning a fost construit, un ruter multicast doar expediază fiecare pachet multicast tuturor interfețelor ce sunt parte a arborelui exceptând-o pe cea de la care a sosit pachetul. Expedierea de-a lungul ramurilor arborelui garantează că pachetul multicast va ajunge la toate ruterele din internetwork.

O soluție spanning tree este puternică și relativ ușor de implementat. Ea poate centraliza traficul pe un număr mic de legături și nu ar putea furniza cea mai eficientă cale între subrețeaua sursă și grupul de membrii.

3.7.3 Reverse Path Broadcasting (RPB)

O soluție mai eficientă decât construirea unui singur arbore pentru întregul Internet ar fi construirea unui grup specific de arbori pentru fiecare potențială subrețea sursă. Acești arbori vor rezulta în rădăcina sursă a arborilor eliberați derivați din subrețeaua conectată direct la stația sursă. Deoarece acolo sunt potențiale surse pentru un grup, un arbore diferit este construit pentru fiecare pereche activă (sursă, grup).

Operare

Algoritmul fundamental pentru construirea acestor arbori rădăcină-sursă se referă la RPB. Algoritmul RPB este chiar simplu. Pentru fiecare pereche (sursă, grup), dacă un pachet sosește pe o linie pe care ruterul local o consideră a fi cea mai scurtă cale înapoi spre sursa pachetului, atunci ruterul expediază pachetul tuturor interfețelor exceptând interfața de sosire. Altfel, pachetul este ignorat.

Figura 3.6: RPB – Algoritmul de înaintare a pachetelor

Interfața de la care ruterul așteaptă să primească pachete multicast de la o sursă particulară se referă ca la o legătură “părinte”. Liniile exterioare pe care ruterul expediază pachetul multicast sunt numite linii “copil”. Algoritmul de bază poate fi sporit pentru a reduce duplicarea pachetelor care nu sunt necesare dacă ruterul face ca decizia de expediere să poată determina fie un ruter vecin pe o potențială linie “copil” fie considerând ruterul local ca fiind pe cea mai scurtă cale înapoi spre sursă. În acest caz, pachetul este expediat spre vecin. Astfel, datele nu sunt expediate pe linia “copil” deoarece ruterul vecin va cere ignorarea pachetului din moment ce acesta sosește pe o linie non-părinte pentru perechea (sursă, grup).

Informația care necesită decizia “downstream” este relativ ușor de obținut dintr-un protocol legătură-stare de rutare din moment ce fiecare ruter menține o bază de date topologice pentru întregul domeniu de rutare. Dacă este folosit DVMRP, un vecin poate fie să anunțe escala anterioară a perechilor (sursă, grup) ca parte a mesajelor de rutare încărcate fie să anuleze ruta.

Figura 3.7: Exemplu al RPB

Figura 3.7 arată un exemplu al operațiilor de bază ale unui algoritm RPB intensificat. De notat că stația sursă (S) este atașată la o subrețea frunză conectată direct la ruterul A. Pentru acest exemplu, vom privi algoritmul RPB din perspectiva ruterului B. Ruterul B primește pachetul multicast de la ruterul A pe linia 1. Din moment ce ruterul B consideră linia 1 ca fiind linia “părinte” a perechii (sursă, grup), expediază pachetul pe linia 4, linia 5 și subrețeaua frunză locală dacă aceasta are un grup de membrii. Ruterul B nu expediază pachetul pe linia 3 deoarece știe din schimbările protocolului de rutare că ruterul C consideră linia 2 ca linie “părinte” a lui pentru pereche (sursă, grup). Dacă ruterul B vrea să trimită pachetul pe linia 3, acesta va fi ignorat de ruterul C deoarece acesta nu a sosit pe o linie “părinte” pentru pereche.

Limitări și avantaje

Cheia avantajelor RPB este aceea că este rezonabil de eficient și ușor de implementat. Nu cere ca ruterul să știe despre întregul arbore și nici nu cere un mecanism special de oprire a procesului de expediere cum cere algoritmul flooding. Mai mult, garantează o livrare (servire) eficientă din moment ce pachetele multicast urmează întotdeauna calea cea mai scurtă dintre stația sursă și grupul destinație. În cele din urmă, pachetele sunt distribuite pe mai multe linii rezultând o utilizare mai bună a rețelei deoarece un arbore diferit este calculat pentru fiecare pereche (sursă, grup).

Una din limitările importante a algoritmului RPB este aceea că nu ia în calcul grupul numărului de membrii multicast când construiește arborele de distribuție pentru o pereche (sursă, grup). Ca rezultat, datele pot fi trimise inutil spre subrețelele care nu au nici un membru în grupul destinație.

3.7.4 Reverse Path Multicasting

RPM este o sporire a RPB. RPM creează un arbore de furnizare cu deschidere numai spre subrețelele cu grup de membrii și rutere și subrețele de-alungul celei mai scurte căi spre subrețelele cu grup de membrii. RPM permite sursei rădăcină a arborelui de furnizare să fie curățată astfel încât datele sunt expediate numai de-a lungul ramificațiilor care conduc la membrii grupului destinație.

Operare

Când un ruter multicast primește un pachet pentru o pereche (sursă, grup), primul pachet este expediat urmând algoritmul TRPB spre toate ruterele din rețeaua Internet. Ruterele care sunt la marginea rețelei și nu au alte rutere sub ele în arborele TRPB sunt numite rutere “frunză”. Algoritmul TRPB garantează că fiecare ruter frunză primește primul pachet multicast. Dacă există acolo un grup membru pe una din subrețelele frunză, ruterul “frunză” expediază pachetul bazându-se pe informațiile IGMP. Dacă nici una din subrețelele conectate la ruterul “frunză” nu au grup de membrii, ruterul “frunză” poate transmite un mesaj de “curățare” pe linia părinte, informând ruterul superior că nu trebuie să expedieze pachete pentru perechea (sursă, grup) particulară pe interfața “copil” recepționând mesajul de curățare. Aceste mesaje sunt trimise o dată sărind înapoi către sursă.

Figura 3.8: Truncated Reverse Path Broadcasting

Figura 3.9: Reverse Path Multicasting

Unui ruter superior, care recepționează mesajul de curățare (prune), îi este cerut să înregistreze informația de curățare în memorie. Dacă ruterul superior nu are nici un receptor local și primește mesajul de curățare pe fiecare din interfețele “copil” care sunt folosite la expedierea primului pachet, ruterul superior nu are nevoie să primească pachete adiționale pentru pereche. Asta înseamnă că ruterul superior poate genera un mesaj de curățare propriu, sărind înapoi către sursă. Această succesiune a mesajelor de curățare creează un arbore de expediere multicast care conține numai ramuri “vii” care conduc la un grup de membrii activ.

Limitări

În ciuda îmbunătățirilor oferite de algoritmul RPM, rămân câteva game de probleme care necesită a fi adresate în așteptarea dezvoltării unui serviciu internet de furnizare întins.

Prima limitare este aceea că pachetele multicast trebuie expediate periodic spre fiecare ruter din rețea. A doua este că fiecărui ruter îi este cerut să păstreze informația oficială pentru toate grupurile și fiecare sursă.

3.7.5 Core-Based Trees (CBT)

Ultima adăugare la setul existent de algoritmi de expediere multicast este CBT. Spre deosebire de algoritmii existenți care construiesc arbori surse-origini cu calea cea mai scurtă pentru fiecare pereche (sursă, grup), CBT construiește un singur arbore de furnizare care este împărțit de toți membrii unui grup. Algoritmul CBT este similar algoritmului spanning tree, exceptând faptul că el permite un arbore CB diferit pentru fiecare grup. Traficul multicast pentru fiecare grup este trimis și primit de-a lungul aceluiași arbore furnizor, indiferent de sursă.

Operare

Un arbore CB poate implica un singur ruter sau un set de rutere care se comportă ca miezul arborelui furnizor multicast. Figura 3.9 ilustrează cum traficul multicast este expediat pe mijlocul arborelui CB tuturor membrilor grupului. De notat că mijlocul CBT poate conține rutere atât de mijloc cât și laterale.

Figura 3.10: Multi-Core CBT Multicast Delivery Trees

Fiecărei stații care dorește să recepționeze traficul care a fost adresat unui grup multicast i se cere să trimită un mesaj de alăturare (join) spre miezul arborelui al grupului multicast particular. Un potențial membru al grupului trebuie să cunoască doar adresa unuia dintre ruterele miezului grupului pentru a transmite o cerere de alăturare unicast. Cererea de alăturare este procesată de toate ruterele intermediare care identifică interfața de pe care a fost primită cererea de alăturare ca aparținând grupului arborelui furnizor. Ruterele intermediare continuă să trimită mesajul de alăturare spre miez și marchează interfețele locale până când cererea ajunge la un ruter de mijloc.

Similar cu alți algoritmi de expediere multicast, CBT nu cere ca sursa pachetului multicast să fie un membru al grupului destinație. Sursele pachetelor unui membru non-grup sunt unicast spre mijloc până când ele ajung la primul ruter care este membru al grupului arborelui furnizor. Când pachetul unicast ajunge la un membru al arborelui furnizor, pachetul este transmis multicast spre toate interfețele de ieșire care sunt părți ale arborelui, exceptând liniile de intrare. Aceasta garantează că pachetul multicast este expediat spre toate ruterele de pe arborele furnizor.

Avantaje

CBT are câteva avantaje față de algoritmul RPM. CBT face eficientă folosirea resurselor ruterului din moment ce cere doar unui ruter să păstreze informația stării pentru fiecare grup și nu pentru fiecare pereche (sursă, grup). De asemenea, CBT conservă dimensiunile rețelei pentru că nu este nevoie ca pachetele multicast să fie expediate periodic spre toate ruterele multicast din internetwork.

Limitări

În ciuda acestor avantaje, există câteva limitări în abordarea CBT. CBT poate rezulta în concentrația traficului din moment ce traficul de la toate sursele traversează același set de linii în apropierea de miez. Mai mult, un singur arbore furnizor împărțit poate crea rute ce nu sunt optime, rezultând o creștere a întârzierii – o problemă critică pentru unele aplicații multimedia. În cele din urmă, noii algoritmi tot au nevoie să fie dezvoltați pentru a suporta managementul miezului care cuprinde toate aspectele ruterului miezului precum și selecția și dinamica strategiilor.

CAPITOLUL IV

Descrierea protocolului

Distance-Vector Multicast Routing Protocol

(DVMRP)

Este un protocol de rutare distanță-vector conceput să suporte expedierea datelor multicast prin internet. DVMRP construiește arbori furnizori multicast sursă–rădăcină utilizând variante ale algoritmului RPB. Unele versiuni ale DVMRP sunt curent dezvoltate în majoritatea ruterelor MBONE. Specificația originală a fost derivată din RIP și folosită de algoritmul TRPB. Diferența majoră dintre RIP și DVMRP e aceea că RIP calculează următorul salt spre o destinație, în timp ce DVMRP calculează următorul salt înapoi spre o sursă. E important de notat că în ultimele versiuni și implementări au extins DVMRP în folosirea algoritmului RPM. Aceasta înseamnă că ultimele implementări ale DVMRP sunt diferite de specificația originală în multe privințe.

4.1 Interfețe tunel și fizice

Porturile unui ruter DVMRP sunt ori interfețe fizice atașate direct subrețelei ori o interfață tunel spre o altă insulă multicast. Toate interfețele sunt configurate cu o metrică ce specifică costul pentru portul dat și un prag TTL care limitează scopul transmisiei multicast. Mai mult, fiecare interfață tunel trebuie să fie configurată explicit cu doi parametrii adiționali: adresa IP a interfeței ruterului local și adresa IP a interfeței ruterului străin.

Tabelul 4.1: Valorile Controlului Scopului

Un ruter multicast va expedia numai date multicast de-a lungul unei interfețe dacă intrarea TTL în capul IP este mai mare decât intrarea TTL dată interfeței. Tabelul 4.1 arată valorile TTL convenționale care sunt folosite pentru a limita scopul unei distribuții multiple IP. De exemplu, datele multicast cu un TTL mai mic decât 32 sunt restricționate la același site și nu ar trebui să fie expediate pe o interfață spre alte site-uri din aceeași regiune.

4.2 Operații de bază

DVMRP implementează algoritmul Reverse Path Multicasting (RPM). Potrivit acestuia, primele date pentru orice pereche (sursă, grup) sunt expediate de-a lungul întregii rețele, furnizând pachetelor TTL și interfeței ruterului praguri de autorizație. Datele inițiale sunt livrate tuturor ruterelor frunză, care transmit mesajele de curățare înapoi spre sursă dacă nu există nici un grup de membrii în subrețelele frunză atașate direct. Mesajele de curățare rezultate în urma mutării ramurilor din arbore, care nu vor conduce la membrii grupului, creează o sursă specifică arborelui cu calea cea mai scurtă, cu toate plecările având grup de membrii. După o perioadă de timp, ramurile curățate se dezvoltă din nou și următoarele date pentru pereche (sursă, grup) sunt expediate în toată rețeaua, rezultând un nou set de mesaje de curățare. DVMRP implementează un mecanism pentru o rapidă grefă înapoi a unei ramuri curățate anterior a grupurilor arborelui furnizor. Dacă un ruter care a trimis anterior un mesaj de curățare pentru o pereche, descoperă un nou grup de membrii pe o subrețea frunză, el trimite un mesaj grefă grupului ruterului sărit anterior. Când un ruter superior primește un mesaj grefă, el va anula mesajul de curățare primit anterior. Mesajele grefă pot reveni spre sursă, împreună cu ramurile curățate anterior pentru a fi restaurate ca parte a arborelui furnizor multicast.

4.3 Funcțiile ruterului DVMRP

Când există mai multe rutere DVMRP pe o subrețea, ruterul principal este responsabil cu transmisia periodică a mesajelor IGMP “problema numărului de membrii gazdă”. După inițializare, un ruter DVMRP se consideră a fi ruter principal pentru subrețea până când primește mesajul “problema numărului de membrii gazdă” de la un ruter vecin cu o adresă IP mai mică. Figura de mai jos ilustrează cum ruterul cu cea mai mică adresă IP funcționează ca Ruter Indicat pentru subrețea:

Figura 4.1: DVMRP – Ruter Indicat

Pentru a evita duplicarea datelor multicast când există mai mult de un ruter pe subrețea, un ruter este ales ruter principal pentru subrețeaua sursă particulară.

În figura 4.1, ruterul C este inferior și ar putea primi date de la subrețeaua sursă prin ruterul A sau ruterul B. Dacă metrica ruterului A spre subrețeaua sursă este mai mică decât cea a ruterului B, ruterul A este principal spre ruterul B pentru această sursă. Asta înseamnă că ruterul A expediază trafic de la subrețeaua sursă și ruterul B ignoră traficul de la subrețeaua sursă. Oricum, dacă metrica ruterului A este egală cu cea a ruterului B, ruterul cu adresa IP cea mai mică pe interfața inferioară (linia copil) devine ruter principal.

4.4 Tabelul de rutare DVMRP

Din moment ce DVMRP a fost dezvoltat pentru rute multicast și nu pentru trafic unicast, unui ruter i se poate cere să ruleze procese de rutare multiple: unul pentru furnizarea traficului unicast și altul pentru furnizarea traficului multicast.

Procesul DVMRP schimbă periodic tabelul de rutare al mesajelor încărcate cu vecini capabili de multicast. Aceste încărcări sunt independente de acelea generate de orice IGP care asigură suportul pentru rutarea unicast.

DVMRP se bazează pe primirea încărcărilor “poisson reverse” pentru detecția ruterului frunză. Această tehnică cere ca vecinul inferior să anunțe “infinity” pentru o subrețea sursă spre un ruter sărit anterior pe calea sa cea mai scurtă înapoi spre acea subrețea sursă. Dacă un ruter superior nu primește o “poisson reverse” încărcată pentru o subrețea sursă pe o interfață inferioară, ruterul superior presupune că subrețeaua inferioară este o frunză și mută portul inferior de pe lista sa de porturi expediate.

Un tabel simplu de rutare pentru un ruter DVMRP este arătat mai jos. Spre deosebire de tabelul tipic creat de un protocol de rutare unicast cum ar fi RIP, tabelul de rutare DVMRP conține “source/subnets” și “from-gateways” în loc de “destinations” și “next-hop gateways”. Tabelul de rutare reprezintă cea mai scurtă cale sursă-rădăcină a arborelui spanning spre fiecare subrețea participantă în internet-arborele RPB.

Tabelul 4.2: Tabelul de rutare DVMRP

În tabelul de rutare DVMRP sunt specificate următoarele informații:

Source Subnet – o subrețea conținând o sursă a gazdei datelor multicast;

Subnet Mask – subrețeaua mască repartizată pentru “Source Subnet”.

De notat că DVMRP furnizează o subrețea mască pentru fiecare subrețea sursă.

From-Gateway – principalul ruter sărit anterior înapoi spre “Source Subnet”;

TTL – aces timp este folosit pentru managementul tabelului și indică

numărul de secunde înainte ca o intrare să fie ștearsă din tabelul de rutare.

4.5 Tabelul de expediere DVMRP

Din moment ce tabelul de rutare DVMRP nu este conștient de grupul numărului de membrii, procesul DVMRP construiește un tabel de expediere bazat pe o combinare a informației conținută în tabelul de rutare multicast, grupurilor cunoscute și primirea mesajelor de curățare. Tabelul de expediere reprezintă cunoașterea ruterului local, a căii sursă-rădăcină cea mai scurtă a arborelui furnizor pentru fiecare pereche (sursă, grup) – arborele RPM.

Tabelul 4.3: Tabelul de expediere DVMRP

Tabelul de expediere pentru un ruter DVMRP tipic este arătat în tabelul 4.3.

Elementele din tabel reprezintă:

Source Subnet – subrețeaua conținând o gazdă sursă a datelor multicast adresate unor grupuri specifice;

Multicast Group – clasa D a adreselor IP pentru care datele multicast sunt adresate. De notat că o subrețea sursă dată poate conține surse pentru multe și diferite grupuri multicast;

InPort – portul “părinte” pentru perechea (sursă, grup). Un “Pr” în această coloană indică faptul că mesajul de curățare a fost trimis spre ruterul superior;

OutPorts – porturile “copil” pe care datele multicast pentru perechea (sursă, grup) sunt expediate. În această coloană “p” indică faptul că ruterul a recepționat un mesaj de curățare de la un ruter inferior.

4.6 Ierarhia DVMRP

Dezvoltarea rapidă a MBONE este începută cu plasarea crescută a cererilor pe ruter. Versiunea curentă a DVMRP tratează MBONE ca un singur, întins domeniu de rutare, unde fiecărui ruter i se cere să mențină informații de rutare detaliate pentru fiecare subrețea din MBONE. Cum numărul de subrețele crește continuu, mărimea tabelelor de rutare și mesajele încărcate periodic vor continua să crească. Dacă nu este nimic de făcut în privința acestor probleme, procesarea și capacitatea memoriei ruterelor MBONE vor fi eventual golite și rutarea MBONE va eșua.

4.6.1 Avantaje ale rutării ierarhice multicast

Pentru a depăși aceste potențiale amenințări este dezvoltată o versiune ierarhică a DVMRP. În rutările ierarhice, MBONE este divizat într-un număr de domenii individuale de rutare. Fiecare domeniu de rutare execută propriul său caz al protocolului de rutare multicast. Alt protocol, sau alt caz al aceluiași protocol, este folosit pentru rutarea între domenii individuale. Rutarea ierarhică reduce cererea pentru resursele ruterului deoarece fiecare ruter trebuie să știe doar detaliile explicite despre pachetele rutate spre destinații în interiorul propriului domeniu, dar nu știe nimic despre detaliile structurii topologice ale celorlalte domenii.

Protocolul rulat între domenii individuale menține informația despre interconexiunile domeniilor, dar nu despre topologia internă a fiecărui domeniu. În completare, pentru reducerea amănuntelor informației rutate, sunt alte câteva avantaje obținute din dezvoltarea unei versiuni ierarhice a DVMRP:

Protocoale de rutare diferite pot fi dezvoltate în fiecare regiune a MBONE. Aceasta permite testarea și desfășurarea unor noi protocoale în baza domeniu-în-domeniu.

Efectele unei linii individuale sau a eșuării ruterului sunt limitate la acele rutere care operează într-un singur domeniu. De asemenea, efectele oricărei schimbări a topologiei interconectării regiunilor sunt limitate numai la ruterele inter-domeniu. Aceste dezvoltări sunt importante în special când dezvoltarea unui protocol de rutare distanță-vector poate avea ca rezultat un timp de concentrare (convergență) relativ mare.

Problema numărare-spre-infinit asociată cu un protocol de rutare distanță-vector plasează limitările la maxim diametrul topologiei MBONE. Rutarea ierarhică limitează aceste diametre la un singur domeniu și nu la întregul MBONE.

Figura 4.2: Internet Multicast Backbone (MBONE)

4.6.2 Protocolul ierarhic DVMRP

Această ierarhie propune crearea unor regiuni neintersectate unde fiecare regiune are o identificare unică (un ID-Region unic). Ruterele interne ale unei regiuni, execută multe protocoale de rutare multicast, cum ar fi DVMRP, MOSPF, PIM sau CBT, ca un protocol ”Nivel 1” (L1). Fiecărei regiuni i se cere să aibă cel puțin un “ruter limită” care este responsabil cu stabilirea conexiunilor inter-regiuni. Ruterele graniță execută DVMRP ca un protocol “Nivel 2” (L2) pentru a expedia traficul între regiuni.

Figura 4.3: Protocolul ierarhic DVMRP

Ruterele (L2) schimbă informația de rutare în forma Region-Ids în loc de adresele subrețelei individuale conținute în interiorul fiecărei regiuni. Cu DVMRP ca protocol L2, arborele furnizor multicast inter-regional este construit pe baza perechii (region-ID, grup) și nu pe perechea standard (sursă, grup).

Când un pachet multicast este generat într-o regiune, este expediat potrivit protocolului L1 spre toate subrețelele care conțin grup de membrii. Mai mult, datele sunt expediate spre fiecare dintre ruterele graniță (L2) configurate pentru regiunea sursă. Ruterele L2 etichetează pachetul cu Region-Id și îl plasează în zona header pentru expedierea spre alte regiuni. Când pachetul sosește într-o regiune îndepărtată, zona header este mutată înainte de expedierea spre membrii grupului de către ruterele L1.

4.7 Abordarea rutării IP multicast

Traficul IP multicast pentru o pereche (sursă, destinație, grup) particulară este transmis de la sursă spre receptoare via un arbore spanning (deschis) care conectează toate gazdele din grup. Protocoale diferite de rutare IP multicast folosesc tehnici diferite pentru construcția acestor arbori multicast. Odată ce arborele este construit, tot traficul multicast este distribuit pe el.

Protocoalele de rutare IP multicast urmează în general una dintre cele două abordări, depinzând de distribuția așteptată a membrilor grupului multicast în rețea. Prima abordare este bazată pe presupunerea că membrii grupului multicast sunt distribuiți dens prin rețea (multe subrețele conțin cel puțin un membru în grup) și că acea bandă este suficientă. A doua abordare a rutării multicast presupune că membrii grupului multicast sunt distribuiți rar în rețea și banda nu trebuie să fie larg disponibilă, de exemplu, peste multe regiuni de pe Internet sau dacă user-ii sunt conectați la linii ISDN. Modul rar (sparse-mode) nu sugerează că grupul are puțini membrii, ci că ei sunt mult dispersați. În acest caz, revărsarea va ocupa inutil banda rețelei și deci poate cauza serioase probleme performanței. Deci, protocoalele de rutare multicast sparce-mode, trebuie să se bazeze pe tehnici mult mai selective pentru stabilirea și menținerea arborilor multicast.

4.8 Rutarea DVMRP

Este un protocol dezvoltat pentru suportarea rutărilor multicast. DVMRP construiește câte un arbore de distribuție pentru fiecare sursă și câte o rădăcină a arborelui pentru toate receptoarele multicast ca plecări ale arborelui. Arborele de distribuție furnizează calea cea mai scurtă între sursă și fiecare receptor multicast din grup, bazându-se pe numărul de salturi în cale, care reprezintă metrica DVMRP. Un arbore este construit la cerere, folosind o tehnică “broadcast and prune”, când o sursă începe să transmită mesaje unui grup multicast.

Pentru a simplifica descrierea DVMRP, presupunem că toate ruterele din rețea suportă DVMRP. Abordarea folosită de DVMRP este de a presupune, inițial, că fiecare gazdă din rețea este o parte a unui grup multicast. Ruterul atribuie sursei subrețelei inițializarea prin transmiterea unui mesaj multicast tuturor ruterelor adiacente. Fiecare dintre aceste rutere vor expedia, selectiv, mesajul ruterelor inferioare până când mesajul este recepționat de toți membrii unui grup multicast.

Expedierea selectivă, în timpul formării arborelui spanning, funcționează în modul următor. Când un ruter primește un mesaj multicast, își verifică tabelul de rutare unicast pentru a determina interfața care furnizează calea cea mai scurtă înapoi spre sursă. Dacă aceasta a fost interfața pe care a sosit mesajul multicast, atunci ruterul va introduce câteva informații de stare pentru a identifica grupul multicast în tabelul intern de mesaje multicast (specificând interfețele pe care mesajele pentru acel grup vor fi expediate) și expediază mesajul multicast tuturor ruterelor adiacente, altele decât cel care a trimis mesajul. Altfel, mesajul este ignorat. Acest mecanism, numit Reverse Path Forwarding, asigură că nu vor exista inele în arbore și că arborele va include calea cea mai scurtă de la sursă spre toate recipientele. Aceasta este de fapt partea de broadcast a protocolului.

DVMRP folosește în prezent un proces de expediere care este mai selectiv decât procesul descris mai sus, prin încrederea pe informația specifică care este furnizată de protocolul de rutare unicast (aceasta implică faptul că DVMRP trebuie să conțină integrat propriul său protocol de rutare unicast).

Un ruter DVMRP, să spunem MR1, conține informația în tabelul său de rutare unicast, ceea ce face posibil să determine dacă un ruter DVMRP adiacent, să spunem MR2, va recunoaște MR1 ca fiind calea cea mai scurtă înapoi spre sursa multicast. Aceasta dă posibilitatea ruterului MR1 de a expedia mesajul multicast spre MR2 numai dacă MR2 va fi capabil să îl folosească pentru continuarea construcției arborelui multicast. Aceasta intensifică potențialele rezultate printr-o reducere considerabilă al fluxului mesajelor care sunt cerute pentru construirea arborelui de distribuție.

Partea de curățare a protocolului elimină rădăcinile arborelui care nu conduc la nici un membru al grupului multicast. IGMP, care rulează între gazde și ruterele multicast vecine imediat lor, este folosit pentru a menține datele grupului numărului de membrii în rutere. Când un ruter determină că nici o gazdă de dincolo nu aparține grupului multicast, el trimite un mesaj de curățare spre ruterul superior. Bineînțeles că ruterele trebuie să încarce informația stării (sursei, destinației, grupului) în tabelele lor pentru a reflecta care rădăcină a fost curățată de pe arbore. Acest proces continuă până când rădăcinile inutile sunt eliminate din arbore, rezultând un arbore spanning minim.

Figura 4.4: Construcția unui arbore spanning DVMRP

Construcția unui arbore spanning DVMRP este ilustrată in figura 4.4. Odată ce arborele este construit, este folosit pentru trimiterea mesajelor multicast de la sursă spre membrii multicast. Fiecare ruter din cale expediază mesajele numai pe acele interfețe care duc la membrii grupului. Din moment ce noi membrii se pot alătura grupului în orice moment și din moment ce acești noi membrii pot depinde de una dintre rădăcinile curățate pentru a primi transmisia multicast, DVMRP reinițiază periodic construcția arborelui spanning.

DVMRP funcționează foarte bine pentru un grup multicast care este reprezentat dens într-o subrețea. În orice caz, pentru grupurile multicast care sunt reprezentate împrăștiat pe o arie întinsă a subrețelei, comportamentul periodic broadcast poate provoca serioase probleme performanței. Altă problemă a DVMRP este cantitatea de informații de stare multicast care trebuie păstrată în ruterele multicast. Toate ruterele multicast trebuie să conțină informația de stare pentru fiecare pereche (sursă, grup), altfel informația este desemnată de interfață pentru a fi folosită pentru expedierea mesajelor multicast sau pentru curățare. Din aceste motive, DVMRP nu sortează pentru suportul grupurilor multicast care sunt distribuite împrăștiat pe o rețea întinsă.

Progresia mesajelor este indicată de o unitate salt/timp:

În primul salt, mesajul ajunge la ruterul 1.

În al doilea salt, mesajul ajunge la ruterele 2, 3 și 4.

În al treilea salt, ruterele 3 și 4 schimbă mesaje. Fiecare doar lasă mesajul, deoarece acesta nu a sosit pe o interfață care dă calea cea mai scurtă înapoi spre sursă.

În al patrulea salt, mesajul ajunge la ruterul 7. Acesta realizează că este un ruter frunză și nu are nici un grup de membrii pe subrețeaua lui, așa că trimite un mesaj de curățare înapoi la ruterul 6, ruterul superior. Ruterul 6, în schimb, trimite un mesaj de curățare ruterului 4. Ruterul 3 trimite de asemenea un mesaj de curățare ruterului 1.

Arborele care va rezulta este arătat în figura 4.5.

Figura 4.5: Arborele rezultat

4.9 Tunelarea ca strategie de tranziție pentru rutarea multicast IP

Tunelarea, în contextul multicast, se referă la îndrumarea datelor pachetelor multicast spre rute, prin părți ale rețelei care nu suportă rute multicast. Cea mai binecunoscută demonstrație a unei tunelări multicast este folosită în Mbone, cu DVMRP.

Tunelele sunt folosite ca strategii de tranziție pentru a atinge întreaga desfășurare locală IP multicast.

4.10 Concluzii

IP multicast face posibile multe noi tipuri de aplicații și reduce congestia rețelei și încărcarea server-ului. Am descris conceptele și mecanismele din spatele câtorva protocoale de rutare folosite cu IP Multicast și unele din avantajele și dezavantajele lor. Selectarea protocoalelor de rutare este un pas important în dezvoltarea rețelelor.

CAPITOLUL V

Implementarea protocolului DVMRP

DVMRP poate fi rezumat ca un protocol de rutare multicast “emite-curăță”. El construiește arbori broadcast pentru fiecare sursă. Pe baza schimburilor de rutare, el creează, dinamic, pe fiecare sursă-grup, arbori de furnizare multicast prin curățarea surselor arborelui broadcast trunchiat. El execută verificări RPF pentru a determina când traficul multicast trebuie expediat spre interfețele inferioare. În acest fel, cea mai scurtă cale sursă-rădăcină a arborelui poate fi formată să ajungă la grupul membrilor de la fiecare subrețea sursă a traficului multicast.

5.1 Descoperirea vecinilor

Ruterele DVMRP vecine sunt descoperite dinamic prin trimiterea de mesaje de sondare a vecinilor pe interfețele rețelei de multicast local și pseudo-interfețele tunel. Aceste mesaje sunt trimise periodic tuturor ruterelor DVMRP. Câmpul TTL al acestor mesaje trebuie setat la 1. Fiecare mesaj de sondare a vecinului conține lista ruterelor DVMRP pentru care mesajul de sondare a fost primit pe acea interfață. În acest fel, ruterele DVMRP vecine se asigură că vor fi văzute de oricare alt ruter. Dacă s-a primit o sondare de la un vecin care conține adresa ta în lista vecinilor, se pot stabili două căi adiacente vecinului cu acest ruter.

5.2 Localizarea sursei

Când o cantitate de date IP multicast este primită de un ruter care rulează DVMRP, se caută în primul rând rețeaua sursă în tabelul de rutare DVMRP. Interfața pe care a fost primită cea mai bună rută spre sursa datelor, este apelată de interfața superioară. Dacă datele sosesc pe interfața superioară corectă, atunci ea este un candidat pentru expediere spre una sau mai multe interfețe inferioare. Dacă datele nu au sosit pe interfața superioară anticipată, sunt ignorate. Această verificare este cunoscută ca verificare RPF și trebuie făcută de toate ruterele DVMRP.

Pentru a fi sigur că toate ruterele DVMRP au o imagine corectă a căii înapoi spre sursă, un tabel de rutare este trimis tuturor ruterelor DVMRP ca parte integrală a protocolului. Fiecare ruter anunță numărul rețelei și masca interfețelor ce sunt direct conectate, ca și schimbările de rute recepționate de ruterele vecine. DVMRP cere ca o interfață metrică să fie configurată pe toate interfețele tunel și fizice. Când este primită o rută, metrica interfeței de pe care au fost primite datele trebuie adăugată metricii rutei care a fost anunțată în mesajul raport rută. Această metrică ajustată trebuie folosită când se compară metricile pentru a determina cel mai bun vecin superior. Deși aici este cert un “overhead” adițional asociat cu propagarea unui tabel de rutare DVMRP separat, se vor furniza două trăsături importante.

Prima, dacă toate ruterele DVMRP schimbă aceleași rute înseamnă că nu există nepotriviri între rutere când se determină interfața superioară. Prin plasarea încărcărilor sincronizărilor pe protocol ca o compensare pentru rețeaua manager, DVMRP reduce riscul creării unor inele de rutare (sau găuri negre) în timpul neînțelegerilor dintre ruterele vecine de pe interfața superioară.

A doua, prin propagarea propriului tabel de rutare, DVMRP face convenabilă existența căilor separate pentru datele unicast și cele multicast. Deși, ideal, mulți manageri de rețea ar prefera să păstreze traficul unicast separat de cel multicast, topologiile tunelării multicast pot prevenii problema divergenței căilor unicast și multicast. În plus, serviciul furnizărilor poate prefera să păstreze traficul unicast separat de cel multicast din motive tactice de rutare.

5.3 Ruterele inferioare dependente

În completare, pentru furnizarea unei imagini corecte a subrețelei sursă, schimburile de rute în DVMRP furnizează o altă trăsătură importantă. DVMRP folosește schimbul de rute ca un mecanism pentru a determina dacă există rutere inferiore care depind de ele pentru expedierea de la subrețelele sursă.

DVMRP realizează aceasta prin folosirea unei tehnici numită “Poisson Reverse”. Dacă un ruter inferior selectează un ruter superior ca cel mai bun salt spre o subrețea sursă, aceasta este indicată de repetarea înapoi a rutei pe interfața superioară cu o metrică egală cu cea originală plus infinit. Când ruterul superior primește raportul și vede o metrică care se întinde între infinit și dublu infinit, atunci poate să adauge ruterul inferior de la care a primit raportul la o listă cu ruterele dependente de această sursă.

Această listă a ruterelor dependente de pe subrețeaua sursă construită de tehnica “Poisson Reverse” va furniza baza necesară pentru a determina când se aproprie curățarea înapoi a sursei specifică arborilor multicast.

5.4 Expedierea indicată

Când două sau mai multe rutere multicast sunt conectate la o rețea multi-acces, poate posibilă duplicarea pachetelor care vor fi expediate pe rețea (o copie de la fiecare ruter). DVMRP previne această posibilitate prin selectarea unei expedieri pentru fiecare sursă ca un efect al schimbării rutei. Când două rutere de pe o rețea multi-acces schimbă subrețelele sursă, fiecare dintre rutere va cunoaște metrica celorlalte înapoi spre fiecare rețea sursă. De aceea, dintre toate ruterele DVMRP de pe o rețea comună, ruterul cu cea mai mică metrică spre o rețea sursă este responsabil cu expedierea datelor pe o rețea comună. Dacă două sau mai multe rutere au o metrică scăzută și egală în același timp, ruterul cu cea mai mică adresă IP devine expeditorul desemnat pentru rețea. În acest fel, DVMRP realizează o selectare implicită a expedierii indicate pentru fiecare sursă rețea de pe interfața inferioară.

5.5 Construcția arborilor multicast

Cum am menționat anterior, când sosesc datele multicast IP, interfața superioară este determinată să caute interfața pe care a fost primită cea mai bună rută spre sursă. Dacă interfața superioară este corectă, atunci ruterul DVMRP va expedia datele spre o listă a interfețelor inferioare.

Baza de date a grupului local IGMP este păstrată de toate ruterele multicast. Dacă adresa grupului destinație există în baza de date a grupului local și ruterul este expeditorul desemnat pentru sursă, atunci interfața este inclusă în lista interfețelor inferioare. Dacă nu este nici un grup de membrii pe interfață, atunci interfața este mutată pe lista interfeței de plecare.

Inițial, toate interfețele cu vecini inferiori dependenți vor fi incluse în lista interfeței inferioare când este creată o intrare depozit. Aceasta permite ruterelor inferioare să se ferească de traficul destinat unei perechi (sursă, grup) particulare. Ruterele inferioare vor avea atunci opțiunea de a trimite curățări și subsecvențe grefe pentru această pereche, ca cereri de schimbare de la ruterele inferioare respective și membrii grupului local.

5.6 Curățarea arborilor multicast

Cum am menționat anterior, ruterele și granițele își vor muta interfețele care nu au grup de membrii asociați cu datele multicast. Dacă un ruter își mută toate interfețele inferioare, el anunță ruterul superior că nu mai dorește traficul destinat unei perechi (sursă, grup) particulare. Aceasta este însoțită de trimiterea unui mesaj de curățare DVMRP în sus spre ruterul care așteaptă să expedieze datele de la o sursă particulară. Pentru aceasta, un ruter inferior va informa ruterul superior că depinde de el pentru a primi datele de la rețelele sursă particulare prin folosirea tehnicii “poisson reverse” în timpul schimbării rutelor DVMRP. Această metodă permite ruterului superior să construiască o listă a ruterelor inferioare pe fiecare interfață care depinde de datele sale primite de la o rețea sursă particulară.

Dacă ruterul superior primește mesaje de curățare de la fiecare din ruterele inferioare dependente de pe o interfață, atunci ruterul superior poate, în schimb, să mute această interfață de pe lista interfețelor inferioare. Dacă ruterul superior este capabil să își mute toate interfețele inferioare în acest fel, atunci poate să trimită un mesaj DVMRP de curățare spre ruterul său superior. Se continuă așa până când ramurile inutile sunt mutate de pe arborele furnizor.

Pentru îndepărtarea vechii informații de stare a curățării pentru perechile (rețea sursă, grup) care nu mai sunt active, este necesar să se limiteze viața unei curățări și reluarea periodică a procedurii broadcast. Mesajul de curățare conține durata de viață a curățării, indicându-se lungimea timpului pentru care curățarea rămâne activă. Când expiră timpul de viață al curățării, interfața se alătură înapoi arborelui furnizor multicast. Dacă date multicast nedorite continuă să sosească, mecanismul de curățare va fi reinițiat și ciclul va continua. Dacă toate interfețele inferioare sunt înlăturate de pe arborele multicast furnizor cauzând un mesaj DVMRP de curățare care va fi trimis în sus, timpul de viață al curățării trimise trebuie să fie egal cu minimul timpilor de viață rămași ai curățărilor primite.

5.7 Grefarea arborilor multicast

Odată ce o ramură a arborelui a fost curățată de pe arborele furnizor multicast, pachetele din perechile (rețea sursă, grup) corespunzătoare nu vor mai fi expediate. Dacă distribuția multiplă suportă un grup de membrii dinamic, gazdele se pot alătura unui grup multicast în orice moment. În acest caz, ruterele DVMRP folosesc grefe pentru anularea curățărilor prezente de la gazdă înapoi spre arborele furnizor multicast.

Un ruter va trimite un mesaj “Graft” vecinului superior dacă o alăturare grup se va produce pentru un grup pentru care ruterul a trimis anterior o curățare. Mesajele “Graft” separate trebuie trimise celui mai apropiat vecin superior pentru fiecare rețea sursă care a fost curățată. Va fi imposibil de spus dacă un mesaj “Graft” trimis în sus a fost pierdut sau sursa renunță la trimiterea traficului, de aceea este necesară confirmarea fiecărui mesaj “Graft” cu un mesaj “Graft” DVMRP. Dacă o confirmare nu este în perioada expirării timpului grefei, mesajul “Graft” va fi retransmis folosind întoarcerea exponențială binară între retransmisii. Mesajele “Graft” duplicate vor fi ignorate.

Scopul mesajulul Graft Ack este confirmarea receptării unui mesaj Graft. Aceasta nu înseamnă că fiecare acțiune a fost luată ca un rezultat al recepționării mesajului “Graft”. De aceea, toate mesajele “Graft” primite de la un vecin cu care s-a realizat o relație two-way cu un vecin, vor fi confirmate chiar dacă provoacă o acțiune pe ruterul receptor.

5.8 Protocolul header

Pachetele DVMRP sunt cuprinse în datele IP, cu un număr al protocolului IP de 2. Toate câmpurile sunt transmise în Network Byte Order. Pachetele DVMRP folosesc un protocol header comun, specific tipului pachetului IGMP ca hexazecimal 0x13 (DVMRP). Pachetele DVMRP vor fi trimise cu câmpul precedent în capul IP setat de Internetwork Control (hexazecimal) 0xc0 pentru tipul serviciului octetului.

Diagrama protocolului header comun:

0 7 15 23 31

Tabelul 5.1: Protocolul header comun

O versiune importantă de 3 și o versiune minoră de 0xFF vor fi folosite pentru indicarea conformării cu această specificație. Valoarea câmpului Cod determină tipul pachetului DVMRP. În mod obișnuit, sunt coduri pentru tipurile mesajului protocol DVMRP ca și pentru analiza protocolului și pachetelor cu dificultăți. Codurile mesajelor protocolului sunt:

Tabelul 5.2: Tipurile mesajului protocol standard

Există coduri adiționale folosite pentru analiza protocolului și a dificultăților. Totalul este de 16 – complementul primului bit al complementului primului total al mesajului DVMRP. Totalul trebuie calculat pe transmisie și trebuie validat la recepția unui pachet. Totalul unui mesaj DVMRP este calculat cu câmpul total setat la zero.

5.9 Mesajele Probă

Când un ruter DVMRP este configurat să ruleze pe o interfață (fizică sau tunel), el face distribuții multiple ale pachetelor probă DVMRP pentru informarea altor rutere DVMRP că este operațional. Probele servesc trei scopuri:

1. Probele furnizează un mecanism pentru ruterele DVMRP de localizare a fiecăreia. DVMRP trimite pe fiecare interfață un mesaj probă conținând lista vecinilor detectați pentru acea interfață anume. Dacă nu sunt găsiți vecini DVMRP, rețeaua este considerată ca fiind o rețea frunză.

2. Probele furnizează o cale pentru ruterele DVMRP de determinare a capacității celorlalte. Aceasta se poate deduce din numerele versiunii majore și minore din pachetul probă sau direct din capacitatea fanioanelor. Aceste fanioane au fost introduse inițial pentru a permite trăsături opționale ale protocolului. Această specificație mandatează acum folosirea identificării generației și curățării și, de aceea, nu furnizează capabilități opționale.

3. Probele furnizează o funcție “păstrare în viață“ în ordine pentru detectarea rapidă a vecinului pierdut. Probele trimise pe fiecare interfață capabilă multicast cofigurată pentru DVMRP ar trebui să folosească un interval de 10 secunde, iar intervalul de pauză vecin ar trebui setat la 35 secunde. Aceasta permite detecția din timp și corectă a unui vecin pierdut și asigură, în același timp, toleranță pentru ruterele multicast ocupate. Astfel de valori trebuie coordonate între toate ruterele DVMRP pe un segment fizic de rețea.

5.9.1 Capabilitățile ruterului

În trecut, au existat mai multe versiuni ale DVMRP în funcțiune, cu un mare spectru de capabilități. Considerațiile practice solicită o implementare curentă pentru inter-operarea cu aceste implementări mai vechi, care nu își specefică formal capabilitățile și nu sunt conforme cu această specificație. De exemplu, pentru versiunile majore mai mici de trei, se poate presupune că vecinul nu suportă curățarea. Capabilitatea formală a fanioanelor a fost introdusă, inițial, într-o bine cunoscută implementare, în tentativa de a lua munca de presupunere ale cărei caracteristici sunt suportate de vecin. Multe dintre aceste fanioane nu mai sunt necesare din moment ce ele sunt acum o parte a protocolului, dar sunt necesare considerații speciale pentru a nu confunda implementările mai vechi care așteaptă ca aceste fanioane să fie setate.

Au existat două versiuni majore anterioare ale DVMRP cu implementări încă în circulație. Dacă recepția unui mesaj probă dezvăluie o versiune majoră de 1 sau 2. Atunci se poate presupune că acest vecin nu suportă curățarea sau folosirea identificării generației în mesajul probă. Oricum, din moment ce aceste implementări mai vechi sunt cunoscute pentru ignorarea sigură a identificării generației și informarea vecinului în pachetul probă, nu este necesar să se trimită pachete probă formate special acestor vecini. Au existat trei versiuni minore (0, 1, 2) ale versiunii majore 3, care suportă curățarea, dar nu suportă identificarea generației sau capabilitatea fanioanelor. Orice alte versiuni minore ale versiunii majore 3 se compară destul de bine cu această specificație. În plus, sistemul CISCO este cunoscut pentru folosirea softului major și eliberarea minoră a numărului, ca și versiunea numerică majoră și cea minoră a DVMRP. Acestea vor fi 10 sau 11 pentru versiunea numerică majoră. Curățarea a fost introdusă în versiunea 11.

Implementările anterioare acestei specificații s-ar putea să nu aștepte pentru a trimite raporturi de rută până când mesajele probă nu au fost primite cu lista adreselor ruterelor. Raporturile ar trebui să fie trimise acestor vecini, fără să ceară înainte să primească o probă cu adresa ruterelor în ea, ca și raporturile de la acei vecini care ar trebui să fie acceptate. Cu toate acestea se permite producerea relațiilor vecine “one-way” și se va menține compatibilitatea în spate. Poate fi necesară formarea relațiilor vecine bazate numai pe mesajele “Raport Rută”. Este necesar să se configureze valoarea pauzei vecinului, pentru o valoare mai mare decât intervalul raport rută, pentru acești vecini.

Implementările care nu monitorizează schimbările identificării generației, pot creea găuri negre importante când folosesc timpi de viață mari a curățării, ca de exemplu 2 ore. Acestea se întâmplă când o curățare mare este trimisă în sus și ruterul care a trimis curățarea lungă restartează. Dacă ruterul superior ignoră noua identificare a generației, curățarea primită de ruterul superior nu va fi cunoscută și ruterul inferior nu va lua la cunoștință despre curățarea superioară. Din acest motiv, curățările trimise în sus spre rutere care știu să ignore schimbările identificărilor generației, vor avea un timp de viață scurt.

Dacă ruterul trebuie să ruleze IGMP versiunea 1 pe o interfață pentru compatibilitatea în spate, DVMRP trebuie să aleagă ruterul DVMRP cu cea mai mare adresă IP față de “întrebătorul” IGMP.

Unele implementări de instrumente, care trimit cereri DVMRP “Ask Neighbors” și primesc mesaje răspuns “Neighbors2” cer o adresă vecină de 0.0.0.0 când nici un vecin nu este listat în pachetul răspuns. Când pachetele răspuns DVMRP sunt trimise spre punctele finale ale tunelului, unele implementări nu acceptă pachete adresate tuturor adreselor ruterelor DVMRP și apoi urmează încapsularea cu adresa punctului final al tunelului.

Trei dintre fanioane au fost folosite pentru operarea actualului protocol. Celelalte două fanioane repartizate au fost folosite în scopul problemelor care ar putea apărea, dar care ar trebui documentate separat. Toți biții marcați cu “U” în figura de mai jos, sunt acum nefolosiți. Ei pot fi definiți în viitor și trebuie setați la 0 în transmisie și ignorați la recepție. Poziția 0 a bitului reprezintă bitul “frunză”, care este o topică de cercetare curentă. El trebuie setat la 0 și ignorat la recepție. Pozițiile 1, 2 și 3 a bitului trebuie setate la 1 pentru compatibilitatea în spate. Au fost folosiți pentru specificarea biților PRUNE, GENID și MTRACE. Primii doi sunt acum trăsături cerute. Bitul MTRACE trebuie setat astfel încât implementările existente să nu își asume acest vecin care nu suportă distribuția multiplă “traceroute”. În orice caz, din moment ce acest bit este acum rezervat și setat la 1, implementările niciodată nu ar trebui să folosească acest bit în mesajul probă pentru determinarea suportării distribuției multiple “traceroute” de către un vecin. Bitul M ar trebui folosit numai în mesajul “Nieghbors2”. Bitul marcat cu S reprezintă capabilitatea SNMP. Acest bit este folosit de aplicațiile cu probleme și ar trebui testat numai în mesajul “Neighbors2”. Bitul N (care reprezintă netmask) este definit de această specificație. Este folosit pentru a indica faptul că vecinul va accepta măștile rețelei adăugate mesajelor “Prune”, “Graft”, “Graft Ack”. Acest bit indică numai că vecinul înțelege masca. Nu înseamnă că mesajele “Prune”, “Graft”, “Graft Ack”, trimise acelui vecin, trebuie să includă “netmask”. De fiecare dată când un mesaj probă este primit de la un vecin, capabilitățile biților vor fi comparate cu versiunea anterioară pentru acel vecin, în ordine pentru detectarea schimbărilor în capabilitățile vecinului.

Tabelul 5.3: Fanioane pentru capabilitățile biților

5.9.2 Identificarea generației

Dacă un ruter DVMRP este restartat nu va ști de nici o curățare anterioară care a fost trimisă sau primită. Pentru vecin, la detectarea restartării ruterului, un număr nedescrescător este plasat în mesajul probă periodic, numit identificatorul generației. Când este detectată o schimbare în identificarea generației, orice informație de curățare primită de la un ruter nu mai este validă și va fi ștearsă. Dacă această stare a curățării a provocat trimiterea în sus a informației de curățare, este nevoie ca o grefă să fie trimisă în sus la fel de mult ca un nou membru alăturat dedesubt.

Odată ce începe furnizarea datelor în jos, dacă ruterul inferior decide din nou să fie curățat de pe arborele furnizor, o nouă curățare poate fi trimisă în sus în acel moment. În plus, efectele unei restartări pot fi minimalizate dacă ruterul poate învăța toate rutele știute de vecinii săi, fără să aștepte un întreg interval de raport pentru a fi aprobat. Când un ruter detectează o schimbare în identificarea generației unui vecin, va trimite o copie unicast a întregului său tabel de rutare vecinului.

În plus de restartare, un ruter poate, de asemenea, să piardă informația de curățare, în timp ce o interfață a avut o tranziție spre o stare inferioară. De aceea, o schimbare în identificarea generației este necesară când o interfață tranzitează spre o stare superioară. Pentru a preveni toate stările curățării de la începerea scurgerii pe un ruter, când o singură interfață tranzitează, un ruter DVMRP ar trebui să păstreze numerele de identificare ale generației, separate pe o interfață.

5.9.3 Adresele vecinilor

Cum un ruter DVMRP vede mesajele probă de la vecinii săi DVMRP, el înregistrează adresele vecine pe fiecare interfață și le plasează în mesajul probă trimis pe o interfață particulară. Aceasta permite ruterului vecin să știe că probele sale au fost primite de ruterul care a primit. Pentru a minimaliza relațiile vecine “one-way”, un ruter trebuie să șteargă raporturile de rută “poisson” trimise ca răspuns la rutele anunțate de un vecin, până când vecinul include adresele ruterelor în mesajele probă ale lui. Pe interfețele punct-la-punct și pseudo-interfețele tunel, nici un pachet nu trebuie expediat peste aceste interfețe până când relațiile vecine “two-way” s-au format.

5.9.4 Expirarea vecinului

Când un vecin expiră, trebuie parcurși următorii pași:

Toate rutele învățate de la acest vecin trebuie plasate imediat în “hold-down”. Toate căile inferioare care depind de acest vecin vor trebui îndepărtate.

Dacă acest vecin, este considerat ca fiind expeditorul indicat pentru orice rute, este anunțat, va trebui selectat, pentru fiecare rețea sursă, un nou expeditor desemnat (indicat).

Orice expediere intrare-depozit bazată pe acest vecin superior, va trebui să fie ștearsă.

Orice grefe exterioare, care așteaptă înștiințări de la acest ruter, vor trebui umplute.

Toate dependențele inferioare primite de la acest vecin, vor trebui îndepărtate.

Expedierea intrărilor depozit va trebui să fie verificată, pentru a vedea dacă acesta este ultimul vecin dependent inferior de pe interfață. Dacă este așa și acest ruter nu este expeditorul desemnat (cu grup local de membrii prezent), interfața va fi mutată.

Este posibil ca o optimizare să trimită o curățare în sus, dacă aceasta provoacă mutarea ultimei interfețe inferioare. Oricum, această curățare poate fi inutilă dacă nu mai sosește trafic. Este, de asemenea, acceptabilă așteptarea sosirii traficului înaintea trimiterii curățării în sus.

5.9.5 Formatul pachetului probă

Pachetul probă este variabil ca lungime, depinzând de numărul adreselor IP vecine incluse. Lungimea pachetului IP poate fi folosită pentru determinarea numărului vecinilor în mesajul probă.

Versiunea majoră curentă este 3.

0 7 15 23 31

Tabelul 5.4: Formatul pachetului probă

Identificatorul generației – acest câmp conține un număr folosit pentru detectarea unei schimbări în starea vecinului.

Adresa IP a vecinului N – aceasta este o listă a adreselor IP ale vecinului, de la care ruterul trimițător a primit mesaje probă.

5.9.6 Selectarea “întrebătorului” desemnat de IGMP

Din moment ce este o pierdere în a avea mai mult de un ruter care trimite întrebări membrilor gazdă IGMP pe o rețea fizică dată, un singur ruter de pe fiecare rețea fizică este ales ca și “întrebător” desemnat. Această alegere a fost o parte din DVMRP. Oricum, aceasta este specificată acum ca o parte a protocolului IGMP versiunea 2. Un singur ruter se va comporta chiar mai mult decât un “întrebător” desemnat IGMP. Toate ruterele DVMRP trebuie să folosească IGMP pentru învățarea membrilor grupului local.

5.10 Expedierea multicast

DVMRP poate expedia pachetele multicast prin construirea listei interfeței inferioare pentru fiecare pachet care a sosit. Pentru reducerea timpului de procesare pentru fiecare pachet rezultatul primei cercetări poate fi depozitat într-un tabel de expediere. Atunci, ca și rute, depozitul intrărilor tabelului de expediere trebuie să fie încărcat pentru reflectarea acestor schimbări.

5.10.1 Expeditorul desemnat

Inițial, un ruter DVMRP ar trebui să presupună că este expeditorul desemnat pentru toate rețelele sursă de pe toate interfețele inferioarre. Ca și primirea rapoartelor rutei, poate determina dacă alte rutere de pe rețelele multiacces au rute mai bune înapoi spre o rețea sursă particulară. O rută este considerată mai bună dacă metrica ajustată primită este mai mică decât metrica care se va anunța pentru rețeaua sursă de pe interfața receptoare sau dacă metricile sunt egale dar adresa IP a vecinului este mai mică.

Dacă acest vecin devine de neatins sau pornește anunțarea unei metrici greșite, atunci ruterul va deveni expeditorul desemnat pentru această rețea sursă de pe interfața inferioară, până când va afla de un candidat mai bun. Dacă se schimbă interfața superioară RPF, ruterul va deveni expeditorul desemnat de pe interfața superioară anterioară.

5.10.2 Determinarea interfeței superioare

Când sosește un pachet multicast, un ruter DVMRP va folosi tabelul de rutare DVMRP pentru a determina care interfață duce înapoi spre sursă. Dacă pachetul nu sosește pe acea interfață, va trebui să fie descărcat fără alte procesări. Fiecare intrare multicast de expediere ar trebui să depoziteze interfața superioară pentru o gazdă sursă particulară sau rețea sursă, după căutarea acesteia în tabelul de rutare DVMRP.

5.10.3 Determinarea listei interfeței inferioare

Lista interfeței inferioare este construită prin începerea (startul) cu lista interfețelor non-frunză. Interfața superioară trebuie ștearsă din această listă. Atunci, orice interfețe de pe lista unde toate dependențele inferioare au trimis curățări în sus, trebuie șterse. În continuare, orice interfețe pentru care ruterul este expeditorul desemnat și este prezent grupul membrilor locali, trebuie adăugate listei.

5.11 Schimbarea rutei

Informația de rutare, propagată de DVMRP, este folosită pentru determinarea căii întoarse, vecine, înapoi spre sursă a traficului multicast. Interfața folosită pentru ajungerea la acest vecin este numită interfața superioară. Tunelul pseudo-interfețelor este considerat ca fiind distinct de interfața fizică pe care este transmis, de fapt, în scopul determinării interfețelor superioare și inferioare.

Informația de rutare care este propagată de DVMRP, conține o listă a rețelelor sursă și o metrică potrivită. Metrica folosită este un salt calculat care este incrementat cu costul metricii interfeței de sosire.

Tradițional, interfețele fizice folosesc o metrică de 1, în timp ce metrica interfeței unui tunel variază cu distanța și lărgimea benzii de cale între punctele finale ale celor două interfețe. Utilizatorii sunt stimulați să configureze tunelele cu aceeași metrică în fiecare direcție, pentru crearea unei rutări simetrice și să asigure determinarea ușoară a problemei, deși protocolul nu forțează aceasta.

5.11.1 Agrearea (acceptarea) rețelei sursă

Implementările pot cere furnizarea unui mecanism de acceptare a rețelelor sursă pentru reducerea mărimii tabelului de rutare. Toate implementările trebuie să fie capabile să accepte rapoarte pentru rețelele sursă acceptate în conformitate cu CIDR (Classes Inter-Domain Routing). Există două locuri unde acceptarea este folositoare:

La organizarea granițelor, pentru limitarea numărului de rețele sursă avertizate cu eliminarea din organizație.

Înăuntrul organizației, pentru a rezuma informația de rutare nelocală, prin folosirea unei rute (0/0) lipsă.

Dacă o implementare vrea să suporte acceptarea sursei, trebuie să transmită mesaje Prune și Graft, potrivit regulilor următoare:

Dacă o curățare este primită pe o interfață inferioară, pentru care rețeaua sursă anunță vecinul că este acceptat, atunci dacă o curățare este trimisă în sus, trebuie trimisă numai pentru ruta care contribuie, bazându-se pe adresa sursei, în curățarea primită. Dacă sunt primite date adiționale pentru surse, înăuntrul rangului acceptării, atunci acestea vor trimite curățări adiționale pentru a fi trimise în sus pentru aceste surse. Acolo pot fi intrări depozit, expediate activ pentru alte rute, care contribuie la acceptare. Curățările nu trebuie trimise în sus spre ruterele care nu au starea expedierii.

Dacă o grefă este primită pe o interfață inferioară, pentru care rețeaua sursă anunță că acel vecin este acceptat, generat de ruterul receptor, atunci mesajele “Graft” trebuie trimise în sus (dacă este necesar), pentru fiecare rută care contribuie la acceptare, care a fost curățată anterior.

5.11.2 Ordonarea și împachetarea rutei

Din moment ce raporturile rutei DVMRP pot avea nevoie de reîmprospătarea câtorva mii de rute pentru fiecare interval de raport, ruterele trebuie să aștepte să împrăștie rutele raportate de-a lungul întregului interval încărcat al rutei. Aceasta reduce șansa sincronizării raporturilor rutei, provocând ruterelor o supraîncărcare, pentru câteva secunde, a fiecărui interval de raport. Din moment ce intervalul raportului rutei este de 60 de secunde, se sugerează ca numărul total al rutelor care au fost încărcate să fie împărțit de-a lungul multiplelor raporturi ale rutei trimise la intervale regulate. O cerință anterioară prevedea că raporturile rutei trebuie să conțină perechi (rețea, mască) sursă, sortate inițial prin mărirea măștii rețelei și apoi prin mărirea rețelei sursă. Această restricție a fost abandonată.

Implementările conforme cu această specificație trebuie să fie capabile să primească raporturile rutei, conținând orice amestec al măștilor rețelei și al rețelelor sursă.

Pentru împachetarea mai multor rețele sursă într-un raport de rută, rețelele sursă sunt adesea reprezentate pe mai puțin de 4 octeți. Numărul de biți diferiți de 0 în valoarea măștii, este folosit pentru determinarea numărului de octeți folosit pentru reprezentarea fiecărei rețele sursă, înăuntrul valorii particulare a măștii. De exemplu, dacă valoarea măștii de 255.255.0.0 este raportată, rețelele sursă vor conține fiecare 2 octeți. DVMRP presupune că acele rețele sursă nu vor fi acceptate în rețelele ale căror lungime a prefixului este mai mică de 8. De aceea nu contează primul octet al măștii în raportul rutei, din moment ce, datorită acestei presupuneri, primul octet va fi întotdeauna 0xFF. Aceasta înseamnă că valoarea măștii rețelei va fi întotdeauna reprezentată pe 3 octeți.

Această metodă de specificare a măștilor rețelei sursă este compatibilă cu tehnicile pentru grupul tradițional de rețele de clasă C în super-rețele și pentru a permite subrețelelor diferite ale aceleiași rețea de clasă A să fie discontinue. Nu se permite gruparea rețelelor de clasă A înăuntrul super-rețelelor pentru că primul octet al măștii rețelei este considerat întotdeauna 255.

5.11.3 Metrica rutei

Pentru fiecare rețea sursă raportată, metrica unei rute este asociată cu ruta care a fost raportată. Metrica reprezintă suma metricelor interfeței între ruterul generator al raportului și rețeaua sursă. Pentru scopurile DVMRP-ului, metrica infinită este definită să fie 32. Ultimul bit este definit ca bitul de ordine cel mai mare al octetului următor adresei rețelei. Acest bit semnalizează când ultima rută a fost raportată pentru o valoare particulară a măștii. Când ultimul bit este setat și sfârșitul mesajului nu a fost atins, următoarea valoare va fi o mască nouă care va fi aplicată subsecvenței listei ruterelor.

5.11.4 Dependențele rutei

Pentru funcționarea corectă a curățarii, fiecare ruter DVMRP trebuie să știe care rutere inferioare depind de el pentru recepționarea datelor de la rețelele sursă particulare. Inițial, când noi date sosesc de la o pereche (sursă, grup) particulară, sunt distribuite broadcast tuturor interfețelor inferioare care au vecini DVMRP care au arătat dependența de ruterul receptor DVMRP pentru acea sursă particulară.

O interfață inferioară poate fi mutată numai când ruterul a primit mesaje de curățare de la fiecare din ruterele dependente de pe acea interfață. Fiecare ruter inferior folosește “Poison Reverse” la indicarea pentru care rețele sursă sunt dependente de ruterul superior. Ruterul inferior indică aceasta printr-un ecou (trimis înapoi) al rețelelor sursă pe care așteaptă să primească de la ruterul superior, cu infinit adăugat la metrica anunțată. Aceasta înseamnă valori legale pentru metrica devenită acum între 1 și (2 x infinit – 1) sau 1 și 63. Valorile între 1 și 31 indică rețelele sursă la care se poate ajunge. Valoarea infinit (32) indică rețeaua sursă la care nu poate ajunge. Valorile între 33 și 63 indică ce ruter inferior, generator al raportului, depinde de ruterul superior pentru furnizarea datelor multicast de la rețeaua sursă corespondentă.

5.11.5 Trimiterea raporturilor de rută

Toate ruterele active trebuie anunțate peste toate interfețele cu vecini prezenți la fiecare interval de raport rută. În plus, încărcările intermitente pot fi trimise după nevoie, dar ele nu trebuie să aibă loc mai des decât intervalul minim de încărcare intermitentă (5 secunde). Aceste încărcări reduc șansele rutării în cerc și al găurilor negre apărute când rețelele sursă devin de neatins pe o cale particulară. Ele au nevoie să conțină doar rețelele sursă care sunt schimbate.

Când un ruter își vede propria adresă în pachetul probă vecin pentru prima dată, va trimite o copie unicast a întregului său tabel de rutare vecinului, pentru a reduce timpul de start. Raporturile nu vor fi trimise unui vecin până când un ruter nu și-a văzut propria adresă în lista ruterului probă a vecinilor.

5.11.6 Primirea raporturilor rutei

După primirea unui raport al rutei, trebuie făcută o verificare pentru a vedea dacă este de la un vecin cunoscut. Legăturile “two-way” vecine sunt esențiale pentru operarea corectă a DVMRP. De aceea, raporturile rutei de la vecinii necunoscuți trebuie descărcate. În continuare, “Metrica” se referă la metrica rutei, cum este primită în raportul rutei. “Metrica Ajustată” se referă la metrica rutei după ce metrica interfeței de sosire a fost adăugată.

Dacă metrica primită este mai mică decât infinit, dar metrica ajustată este mai mare sau egală cu infinit, atunci metrica ajustată va fi setată ca infinit.

Dacă metrica este mai mare sau egală cu infinit, atunci nici o ajustare a metricii nu trebuie făcută.

Fiecare rută din raport este analizată gramatical și procesată conform următoarelor reguli :

Dacă ruta este nouă iar metrica ajustată este mai mică decât infinit, ruta va fi adunată.

Dacă o rută există deja, trebuie făcute câteva verificări:

Metrica primită < infinit

Dacă un vecin a fost considerat vecin dependent inferior, dependența este anulată.

În cazurile următoare, expeditorul desemnat pe una dintre interfețele inferioare va fi încărcat :

dacă metrica primită va provoca ruterul să anunțe o metrică mai bună pe o interfață inferioară, atunci expeditorul desemnat există pentru rețeaua sursă de pe acea interfață (sau metrica anunțată va fi aceeași, dar adresa IP a ruterului este mai mică decât a expeditorului desemnat existent pe acea interfață). Atunci ruterul receptor devine noul expeditor desemnat pentru acea rețea sursă de pe interfață. Dacă acest ruter a trimis o curățare în sus care este activă încă, va fi nevoit să trimită și o grefă.

dacă metrica ce a fost anunțată de expeditorul desemnat existent este mai rea decât metrica ruterelor recepționate, care a fost anunțată pe interfața receptoare (prin învățarea aceleiași rute de la un vecin de pe altă interfață) sau metrica este aceeași, dar ruterul receptor are o adresă IP mai mică, atunci ruterul receptor devine noul expeditor desemnat pe acea interfață. Acesta poate încărca o grefă pentru a fi trimisă în sus.

dacă metrica primită pentru rețeaua sursă este mai bună decât metrica expeditorului desemnat existent, se scalează noul expediator desemnat și metrica ce va fi anunțată. Este necesar să se păstreze cunoștințele despre expeditorul desemnat curent, pentru fiecare rețea sursă, în cazul în care valoarea pauzei pentru acest vecin este atinsă. Dacă pauza este atinsă, atunci expeditorul desemnat își va asuma responsabilitatea pentru rețeaua sursă. O rută este considerată mai bună când, fie metrica primită este aceeași, fie adresa IP anunțată a ruterului este mai mică.

Metrica Ajustată > metrica existentă. Dacă metrica ajustată este mai mare decât metrica existentă, se verifică dacă același vecin a raportat ruta. Dacă este așa, se încarcă metrica rutei și se programează o încărcare intermitentă care conține ruta. Altfel, se sare până la următoarea rută din raport.

Metrica Ajustată < metrica existentă. Se încarcă metrica pentru rută și dacă vecinul care raportează ruta este diferit, se încarcă vecinul superior în tabelul de rutare. Se programează o încărcare intermitentă, care conține ruta spre vecinii inferiori și o ”poison” tot intermitentă se va încărca și va conține ruta ce va trebui trimisă în sus, indicând o schimbare în dependența în jos (chiar dacă este pe aceeași interfață superioară).

Metrica Ajustată = metrica existentă. Dacă un vecin raportează că ruta este aceeași cu a vecinului superior existent, atunci se reface ruta. Dacă vecinul este același și ruta este în stare de repaus, este permis să se ia, prematur, ruta din repaus și începerea anunțării ei cu o metrică non-infinită. Dacă ruta este scoasă din repaus, se încarcă o intermitență care conține ruta ce va fi stabilită pe toate interfețele DVMRP, cu excepția celei de pe care s-a primit. Dacă un vecin care raportează ruta are o adresă IP mai mică decât vecinul superior existent, atunci se comută pe acest vecin ca fiind ruta cea mai bună. Se programează o încărcare intermitentă, care conține ruta spre vecinii inferiori și se încarcă o otravă (poison) intermitentă, care conține ruta ce va fi trimisă în sus, indicând o schimbare în dependența în jos (inferioară) mult mai mică, deși este pe aceeași interfață superioară mult mai mare.

Metrica primită = infinit

Dacă un vecin a fost considerat ca fiind expeditorul desemnat, ruterul receptor va deveni acum expeditorul desemnat pentru rețeaua sursă de pe acestă interfață. Dacă metrica existentă a fost mai mică decăt infinit, ruta este imposibil de atins acum. Se va șterge ruta și se programează o încărcare intermitentă, care conține ruta spre toate interfețele pentru care stația este expeditorul desemnat sau are dependențe în jos. Ruta poate fi ignorată din moment ce saltul următor existent are o metrică mai bună decât acest salt sau egală. Dacă vecinul a fost considerat vecin dependent în jos, aceasta va fi anulată.

Infinit < Metrica primită < 2 x Infinit

Vecinul consideră ruterul receptor ca fiind superior pentru rută și indică dependența sa de ruterul receptor. Dacă vecinul a fost considerat ca fiind expeditorul desemnat, ruterul receptor va deveni acum expeditorul desemnat pentru rețeaua sursă pe această interfață.

Vecinul de pe interfața inferioară.

Dacă un vecin care trimite este considerat ca fiind pe o interfață inferioară pentru acea rută, atunci acesta va fi înregistrat ca ruter dependent inferior pentru acea rută. Dacă aceasta este prima dată când vecinul a indicat dependența inferioară pentru acea sursă și una sau mai multe curățări au fost trimise în sus, care conțineau acea rețea sursă, atunci mesajul “Graft” trebuie trimis în sus, în direcția rețelei sursă, pentru fiecare grup cu o stare de curățare existentă.

Vecinul de pe interfața superioară.

Dacă ruterul receptor crede că vecinul este pe interfața superioară, ruta va fi tratată ca și cum o metrică infinită ar fi fost recepționată.

2 x Infinit <= Metrica recepționată.

Dacă Metrica recepționată este mai mare sau egală cu 2 x Infinit, metrica este greșită și ruta va fi ignorată.

5.11.7 Expirarea rutei

O rută expiră dacă nu a fost înnoită într-un interval “Expirare rută”. Acest interval va fi setat astfel: 2 x Interval Raport Rută + 20 (say 140) secunde.

În timpul încărcărilor intermitente, tipica rutei nu va expira, dar va fi îndepărtată ca răspuns la recepționarea unei metrici infinite pentru rută. În orice caz, din moment ce nu toate implementările existente implică încărcările intermitente, expirarea rutei este necesară.

5.12 Curățarea

Cum ruterele de la ieșirile arborelui încep să primească trafic multicast nedorit, ele trimit mesaje de curățare în sus spre sursă. Această acțiune are ca rezultat un arbore multicast pentru o rețea sursă dată și un set dat de receptoare.

5.12.1 Rețelele frunză

Detecția rețelelor frunză este foarte importantă pentru procesul de curățare. Ruterele de la sfârșitul unui arbore furnizor specific multicast, trebuie să detecteze dacă nu mai sunt alte rutere dependente inferior. Dacă nu este prezent nici un grup de membrii pentru datele multicast recepționate, ruterele frunză vor începe procesul de curățare prin îndepărtarea interfețelor lor inferioare și trimiterea unei curățări spre ruterul superior al acelei surse.

5.12.2 Rețelele sursă

Curățările se aplică unui grup și rețea sursă. Este posibil să se includă o mască rețea în mesajul de curățare, pentru alterarea acestui comportament. Dacă nu este inclusă nici o mască, o curățare trimisă în sus de traficul recepționat de la o sursă particulară este aplicată tuturor surselor de pe acea rețea. Dacă o mască este inclusă, aceasta trebuie, în primul rând, validată. Dacă este o mască a unei gazde, numai acea adresă sursă va fi curățată. Altfel, masca trebuie să se potrivească cu masca trimisă ruterului inferior pentru acea sursă. Dacă nu se potrivește cu masca așteptată de la ruterul superior, acesta trebuie să ignore curățarea și să anunțe o eroare.

Când o rețea sursă agreată este anunțată în jos, masca din curățare se va potrivi cu masca ruterului agreat care a fost anunțat. Dacă mesajul de curățare conține numai adresa gazdei sursei, rețeaua sursă poate fi determinată ușor de către o căutare a celei mai bune potriviri, folosind tabelul de rutare distribuit ca parte a DVMRP.

5.12.3 Recepționarea unei curățări

Când este recepționată o curățare, vor trebui urmați următorii pași:

Dacă nu este cunoscut vecinul, curățarea primită este descărcată.

Se asigură că mesajul de curățare conține cel puțin cantitatea de date corectă.

Se copiază adresa sursei, adresa grupului și valoarea pauzei curățării. Dacă este disponibilă în pachet, se copiază valoarea măștii. Se determină ruta căreia i se aplică curățarea.

Dacă nu există nici o informație despre sursa activă pentru perechea (rețea sursă, grup), atunci curățarea se ignoră.

Se verifică dacă a fost primită curățarea de la un vecin dependent pentru rețeaua sursă. Dacă nu, curățarea este descărcată.

Se determină dacă o curățare este, încă activă, de la același vecin dependent pentru acea pereche (rețea sursă, grup).

Dacă este așa, se resetează timer-ul la o nouă valoare time-out. Altfel, se crează o stare pentru o nouă curățare și se setează timer-ul pentru durata de viață a curățării.

Se determină dacă toate ruterele inferioare dependente de pe interfața de la care a fost primită curățarea, au trimis acum curățări.

Dacă este așa, atunci se determină dacă sunt membrii de grup activi pe interfață și dacă acest ruter este expeditorul desemnat pentru rețea.

Dacă nu, se înlătură interfața de la toate intrările depozit expeditoare pentru acest grup, în loc să se folosească ruta pentru care este aplicată curățarea.

5.12.4 Trimiterea unei curățări

Când un depozit expeditor este folosit, există un schimb care trebuie luat în considerare când se decide momentul în care mesajele de curățare vor fi trimise în sus. În toate cazurile, când sosește un pachet de date și lista interfeței inferioare este goală, o curățare este trimisă în sus. Oricum, când o intrare depozit expeditoare tranzitează spre o listă a interfeței inferioare goale, este posibil, ca o optimizare, să se trimită o curățare în acel moment. Este posibil ca această curățare să oprească traficul nedorit mai repede decât durata trimiterii unui extra-trafic de curățare pentru sursele care nu mai trimit.

Când se trimite o curățare în sus, vor trebui urmați pașii:

Se decide dacă un vecin superior este capabil să recepționeze curățări.

Dacă nu, nu se mai continuă.

Se opresc orice grefe pe timpul așteptării informațiilor.

Se determină durata de viață a unei curățări. Această valoare va fi minimul absenței duratei de viață a curățării a vecinilor inferiori.

Se stabilesc forma și trimiterea pachetului spre vecinul superior, pentru sursă.

5.12.5 Retransmiterea unei curățări

Prin mărirea duratei de viață a curățării la aproximativ 2 ore, efectul pierderii mesajului de curățare devine mai evident. De aceea, o implementare va retransmite mesajele de curățare, pe durata timpului de viață al curățării, dacă traficul sosește încă pe interfața superioară.

O cale de implementare va fi trimitrea unei curățări, instalarea unei intrări depozit negative pentru 3 secunde, timp în care se așteaptă ca acea curățare să își facă efectul. Apoi se înlătură intrarea depozit negativă. Dacă traficul continuă să sosească, o nouă cerere depozit expeditoare va fi generată. Curățarea nu poate fi suportată cu timpul de viață al curățării rămas și o intrare depozit negativă poate fi instalată pentru 6 secunde. După aceasta, intrarea depozit negativă este înlăturată.

Această procedură se repetă până când, de fiecare dată a dublării lungimii timpului, intrarea depozit negativă este instalată. Intervalul între retransmisiile subsecvențiale va fi făcut aleatoriu, pentru prevenirea sincronizării. Pe rețelele multi-acces, chiar dacă o curățare este primită de către ruterul superior, datele pot fi recepționate încă prin alte receptoare de pe rețea.

5.12.6 Formatul pachetului de curățare

Un pachet de curățare conține trei câmpuri esențiale: adresa IP a gazdei sursă, adresa IP a grupului destinație și timpul de viață al curățării (în secunde). O mască opțională o rețelei sursă poate fi, de asemenea, adăugată mesajului de curățare. Această mască aplicată adresei gazdei sursă va indica ruta căreia i se aplică curățarea. Un câmp al măștii rețelei sursă va fi trimis numai în mesajul de curățare spre un vecin, dacă acesta a fost anunțat de abilitatea de procesare a acestuia, prin setarea bitului capacităților măștii rețelei.

Lungimea mesajului de curățare va indica dacă masca rețelei sursă a fost inclusă sau nu. Timpul de viață este o valoare derivată, calculată ca minimul absenței timpului de viață al curățării (2 ore) și timpul de viață rămas al oricăror curățări în jos pentru acea rețea sursă și pentru acel grup. Un ruter fără nici un vecin dependent inferior, va folosi absența timpului de viață al curățării (aleatorizat, pentru a preveni sincronizarea).

0 7 15 23 31

Tabelul 5.4: Formatul pachetului “Prune”

Adresa gazdei sursă – adresa IP a gazdei sursă a datelor, care a declanșat curățarea.

Adresa grupului – adresa IP a grupului destinație a datelor, care a declanșat curățarea.

Timpul de viață al curățării – numărul de secunde pentru care vecinul superior va păstra activă această curățare.

Masca rețelei sursă – masca (opțională) rutei căreia i se aplică această curățare.

5.13 Grefarea (alipirea)

Odată ce un arbore furnizor multicast a fost curățat înapoi, mesajele “Graft” DVMRP sunt necesare pentru alăturarea noilor receptoare de-a lungul arboreloi multicast.

Mesajele “Graft” sunt trimise în sus salt-cu-salt de la un nou prim-pas al ruterului recepționat până când este atins un punct de pe arborele multicast. Din acel moment, nu mai este posibil să se spună dacă sau un mesaj “Graft” a fost pierdut sau sursa a stopat trimiterea, dar fiecare mesaj “Graft” este cunoscut pas-cu-pas. Aceasta asigură că mesajul “Graft” nu este pierdut undeva de-a lungul căii între primul pas recepționat al ruterului și cel mai apropiat punct de pe arborele furnizor multicast.

Unul sau mai multe mesaje “Graft” vor fi trimise în următoarele condiții:

Un nou membru local se alătură unui grup care a fost curățat în sus și acest ruter este expeditorul desemnat pentru sursă.

Un nou ruter inferior dependent apare pe o ramură curățată.

Un ruter inferior dependent de pe ramura curățată repornește (noua generație ID).

Un timer de retransmisie al grefei expiră înainte ca un “Graft-Ack” să fie primit.

5.13.1 Trimiterea unei grefe

Curățările sunt specifice rețelei sursă și sunt trimise în sus unor arbori diferiți pentru fiecare rețea sursă. Grefele sunt trimise ca răspuns unor condiții variate care nu sunt specifice neapărat sursei. De aceea, poate fi necesară trimiterea unor mesaje “Graft” separate spre ruterele superioare apropiate, pentru contracararea fiecărei curățări, specifice rețelei sursă, care a fost trimisă anterior.

Cum am menționat mai sus, un mesaj “Graft” trimis unui ruter DVMRP superior va fi cunoscut pas cu pas, garantând furnizarea “end-to-end”.

Pentru a trimite mesaje “Graft”, vor fi urmați următorii pași:

Se verifică dacă există o curățare pentru rețeaua sursă și pentru grup.

Se verifică dacă ruterul superior este capabil să recepționeze curățări.

Se adaugă o grefă retransmisiei listei timer-ului, așteptând o înștiințare.

Formularea și transmiterea pachetului “Graft”.

Dacă înștiințarea grefei nu este primită într-o perioadă a pauzei retransmisiei grefei, aceasta va fi trimisă spre ruterul superior. Perioada inițială de retransmisie este de 5 secunde.

5.13.2 Recepționarea unei grefe

Dacă vecinul nu este cunoscut, grefa recepționată este descărcată.

Se asigură că mesajul “Graft” conține cel puțin cantitatea de date corectă.

Se trimite înapoi, spre sursă, pachetul “Graft-Ack”.

Dacă trimițătorul a fost un vecin dependent inferior, de la care s-a primit anterior o curățare, atunci se înlătură starea curățării pentru acest vecin. Dacă este necesar, orice intrări depozit expeditoare, bazate pe această pereche (sursă, grup), va fi încărcată pentru a include interfața inferioară.

Dacă o curățare a fost trimisă în sus, aceasta poate declanșa grefa pentru a fi trimisă acum ruterului superior.

5.13.3 Formatul pachetului “Graft”

Formatul unui astfel de pachet este arătat în figura de mai jos:

0 7 15 23 31

Tabelul 5.5: Formatul Pachetului “Graft”

Adresa gazdei sursă – adresă IP care indică gazda sursă sau rețeaua sursă ce va fi grefă.

Adresa grupului – adresa IP a grupului destinație care va fi grefat.

Masca rețelei sursă – masca (opțională) rutei căreia i se aplică grefa.

5.13.4 Trimiterea unei înștiințări a grefei

Un pachet “Graft Acknowledgment” este trimis unui vecin inferior ca răspuns la recepționarea mesajului “Graft”. Toate mesajele “Graft” trebuie înștiințate. Aceasta este adevărată chiar dacă nici o altă acțiune nu este luată ca răspuns la recepționarea grefei, pentru împiedicarea sursei de a retransmite continuu mesajul “Graft”. Pachetul “Graft Ack” este identic cu pachetul ““Graft”” exceptând codul DVMRP, în header-ul comun care este setat după “Graft Ack”. Aceasta permite receptorului mesajului “Graft Ack” să identifice corect care grefă a fost înștiințată și să oprească timer-ul retransmisiei următoare.

5.13.5 Recepția “Graft Acknowledgment”

Când este recepționat “Graft Ack”, se asigură că mesajul conține cel puțin cantitatea de date corectă. Perechea (rețea sursă, grup) din pachet, ce poate fi folosită la determinarea faptului că o grefă a fost trimisă sau nu pentru acest ruter superior particular. Dacă nu a fost trimisă nici o grefă, “Graft Ack” va fi pur și simplu ignorat. Dacă grefa a fost trimisă și înștiințarea a sosit de la ruterul superior corect, atunci a fost bine recepționată și timer-ul de retransmisie pentru grefă poate fi oprit.

5.13.6 Formatul pachetului “Graft Ack”

Formatul acestui pachet (care este identic cu cel al pachetului “Graft”) este arătat în figura de mai jos:

0 7 15 23 31

Tabelul 5.6: Formatul pachetului “Graft Ack”

Adresa gazdei sursă – adresa IP a gazdei sursă care a fost recepționată în mesajul “Graft”.

Adresa grupului – adresa IP a grupului destinație care a fost primit în mesajul “Graft”.

Masca rețelei sursă – masca (opțională) a rutei căreia i se aplică mesajul “Graft Ack”.

5.14 Interfețe

Interfețele care rulează DVMRP vor fi fie interfețe capabile fizic multicast fie pseudo-interfețe tunel încapsulate. Interfețele fizice pot fi, fie rețele multi-acces, fie rețele punct-la-punct. Interfețele tunel sunt folosite când există rutere incapabile de multicast între vecinii DVMRP. Mesajele de protocol și traficul de date multicast sunt trimise între capetele tunelului, folosind o metodă de încapsulare standard [Perk 96, Han 94a, Han 94b]. Adresele IP unicast ale capetelor tunelului sunt folosite ca adrese IP sursă și destinație în afara header-ului IP. Header-ul IP interior rămâne neschimbat față de pachetul original. Mesajele protocol de pe legăturile punct-la-punct vor folosi întotdeauna o adresă IP destinație a tuturor ruterelor DVMRP pentru toate tipurile de mesaje. În timp ce mesajele “Prune”, “Graft” și “Graft Ack” sunt adresate numai unui singur recipient, folosirea adresei destinație multicast este necesară pentru un număr mare de legături și interfețe încapsulate. Când o adresare multiplă este configurată pe o singură interfață, este necesar ca toate ruterele de pe interfață să cunoască același set de adrese al rețelei. În acest fel, fiecare ruter va face aceeași alegere pentru expeditorul desemnat pentru fiecare sursă. În plus, un ruter configurat cu adrese multiple pe o interfață, va folosi, în mod consistent, aceeași adresă când trimite mesaje de control DVMRP.

Lungimea maximă a pachetului oricărui mesaj DVMRP va fi mărimea maximă a pachetului, cerută pentru a fi expediată fără fragmentare. În absența căii MTU, cerințele pentru gazdele Internet specifică acest număr ca fiind 576 octeți.

5.15 Tranzițiile interfeței

Când o interfață tranzitează spre o stare superioară, generația ID a acelei interfețe va fi încărcată așa încât vecinii DVMRP să știe să respingă informația de curățare. Când o interfață tranzitează spre starea inferioară, toți vecinii de pe acea interfață vor expira. Toate acțiunile asociate cu un vecin expirat vor fi luate cum este specificat în secțiunea “Expirarea vecinului”.

Internet Assigned Numbers Authority (IANA) este coordonatorul principal pentru desemnarea valorilor unice ale parametrilor pentru protocoalele Internet. DVMRP folosește mesajele protocol IP IGMP pentru comunicarea între rutere. Câmpul tip IGMP este hexazecimal 0x13. Pe rețelele capabile de multicast, DVMRP folosește toate ruterele DVMRP ale grupului multicast local a cărui adresă este 224.0.0.4.