Routing Information Protocol -RIP-

Proiect Managementul Mobilitii Grupa MSR

1.

Motivarea RIP

Odata cu aparitia protocoalelor OSPF si IS-IS, exista specialisti care cred ca RIP este invechit. Desi este adevarat ca protocoalele de rutare IGP (protocoale interioare de rutare) mai noi sunt de departe superioare, RIP, acesta are unele avantaje. In primul rand, intr-o retea mica, RIP prezinta o utilizare foarte eficienta in termeni de latime de banda utilizata precum si configurarea si managementul timpului. RIP este de asemenea foarte usor de pus in aplicare, in special in comparatie cu protocoalele IGP noi. In plus, exista multe implementari, mult mai multe implementari RIP in domeniu decat OSPF si IS-IS combinate. Este posibil sa ramana in acest fel pentru inca cativa ani. Avand in vedere ca protocolul RIP va fi util in multe medii si situatii pentru o perioada de timp indelungata, este rezonabil sa se incerce perfectionarea lui. Acest lucru este valabil mai ales deoarece castigul este mult mai mare decat cheltuiala necesara pentru schimbare.

2.

Versiunea RIP-v1

Versiune RIP-1 foloseste mesaje ce contin o cantitate minima de informatii necesare ruterelor pentru a ruta mesajele printr-o retea. Mesajele contin, de asemenea, o cantitate mare de spatiu nefolosit, din cauza originilor sale. Protocolul RIP-v1 nu lua in considerare sistemele autonome si interactiunile IGP/EGP, subnetarea [11], si autentificarea deoarece implementarile acestora sunt ulterioare RIP-v1. Lipsa mastilor de subretea este o problema deosebit de grava pentru rutere, deoarece au nevoie de o masca de subretea pentru a sti cum sa determine un traseu. In cazul in care o ruta RIP este o ruta din retea (totii bitii non-retea 0), masca de subretea este egala cu masca de retea. Cu toate acestea, daca o parte din bitii non-retea sunt stabiliti, ruter-ul nu poate determina masca de subretea. Mai rau inca, ruter-ul nu poate determina daca o ruta RIP este o ruta catre o subretea sau o ruta catre host. In prezent, unele rutere aleg pur si simplu masca de subretea a interfetei peste care ruta a fost invatata si determina tipul de ruta din aceasta informatie.

3.

Protocolul de baza

3.1 Introducere RIP este un protocol de rutare bazat pe algoritmul Bellman-Ford (sau vector distanta). Acest algoritm a fost folosit pentru calcule de rutare in retele de calculatoare inca din primele zile ale ARPANET. Formatul pachetelor si protocolul descris aici se bazeaza pe programul "routed", care este inclus in distributia Berkeley a Unix. Intr-o retea internationala, cum ar fi Internet-ul, este foarte putin probabil ca un singur protocol de rutare va fi folosit pentru intreaga retea. Mai degraba, reteaua va fi organizata ca o

colectie de sisteme autonome (AS), fiecare dintre acestea va fi, in general, administrat de catre o singura entitate. Fiecare AS va avea propria tehnologie de rutare, care poate fi diferita de tehnologia implementata in restul sistemelor. Protocolul de rutare utilizat intr-un AS este denumit Interior Gateway Protocol (IGP). Un protocol separat, numit Exterior Gateway Protocol (EGP), este utilizat pentru transferul de informatii de rutare intre sistemele automone. RIP a fost conceput pentru a lucra ca protocol IGP in AS de dimensiuni moderate. Acesta nu este destinat utilizarii in medii mai complexe. Pentru informatii cu privire la contextul in care RIP-v1 este indicat sa fie utilizat, se poate consulta Braden si Postel [6]. RIP foloseste un algoritm dintr-o clasa de algoritmi de rutare cunoscuta sub numele de algoritmi vector-distanta. Cea mai veche descriere a acestei clase de algoritmi este facuta de catre autorii Ford si Fulkerson [8]. Din aceasta cauza, acesti algoritmi sunt uneori cunoscuti ca algoritmi Ford-Fulkerson. Termenul Bellman-Ford este de asemenea utilizat, si deriva din faptul ca formularea se bazeaza pe ecuatia lui Bellman [4]. Prezentarea din acest document se bazeaza pe principiile descrise de Bertsekas, D. P., si Gallaher, R. G., in lucrarea "Data Networks" [5]. Pentru o introducere in matematica algoritmilor de rutare, a se vedea [1]. Algoritmii de baza folositi de catre acest protocol au fost utilizati in domeniul rutarii, inca din 1969 in ARPANET. Cu toate acestea, stramosul specific al acestui protocol se regaseste in protocoalele de retea Xerox. Protocoalele PUP [7] utilizau protocolul de rutare Gateway Information Protocol pentru a face schimb de informatii. O versiune oarecum actualizata a acestui protocol a fost adoptata pentru arhitectura Xerox Network Systems (XNS), cu numele de Routing Information Protocol [9]. Forma regasita in Berkeley este in mare parte aceeasi ca RIP, cu observatia ca adresele XNS sunt inlocuite cu un format de adresa mai general, capabile de manipularea adreselor IPv4 si a altor tipuri de adrese, si cu mesaje de actualizari la fiecare 30 de secunde. Din cauza acestei similitudini, termenul Routing Information Protocol (sau doar RIP) este folosit pentru a desemna atat protocolul XNS si protocolul utilizat de Berkeley. RIP este destinat utilizarii in cadrul retelei Internet bazate pe IP. Internetul este organizat intr-un numar de retele conectate prin gateway-uri cu rol special, cunoscute sub numele de routere. Retelele pot fi legaturi punct-la-punct sau retele mai complexe, cum ar fi Ethernet sau de tip token ring. Echipamentele gazda si routerele primesc datagrame IP adresate anumitor echipamente gazda. Rutarea este metoda prin care echipamentele gazda sau routerele decid unde sa trimita datagrama. Acestea pot fi in masura sa trimita datagrama direct la destinatie, in cazul in care destinatia este, intr-una din retelele conectate direct la echipamentul gazda sau la router. Cu toate acestea, un caz interesant este atunci cand destinatia nu este direct accesibila. In acest caz, gazda sau routerul incearca sa trimita datagrama la un router care este mai aproape de destinatie. Scopul unui protocol de rutare este foarte simplu: de a furniza informatiile care sunt necesare pentru a calcula si a gasi trasee potrivite (pentru a ruta).

3.2 Limitari ale protocolului

Acest protocol nu rezolva toate problemele posibile de rutare. Dupa cum s-a mentionat mai sus, RIP este in primul rand destinat utilizarii ca protocol de interior IGP in retele de dimensiuni moderate. In plus, exista si urmatoarele limitari specifice: - protocolul este limitat la retele ale caror dimensiuni cu conduc la rute mai lungi de 15 hop-uri (diametrul retelei). Designerii cred ca protocolul de baza este nepotrivit pentru retele mai mari. De retinut este faptul ca aceasta afirmatie presupune ca un cost de 1 este utilizat pentru fiecare link din retea. Acesta este modul in care RIP este configurat in mod normal. In cazul in care administratorul de sistem alege sa utilizeze costuri mai mari, limita superioara de 15 poate deveni cu usurinta o problema. - protocol depinde de "numararea la infinit" pentru a rezolva anumite situatii neobisnuite. (Acest lucru va fi explicat in sectiunea urmatoare.) Daca sistemul de retele este compus din cateva sute de retele, si o bucla de rutare care sa implice toate acestea retele se formeaza, rezolvarea buclei ar necesita fie mult timp (daca frecventa actualizarilor de rutare ar fi limitata) fie largime de banda marita (daca actualizarile au fost trimise ori de cate ori au fost detectate modificari). O astfel de bucla va consuma latimea de banda a retelei inainte ca bucla sa fie corectata. De obicei, in cazurile reale, acest lucru nu reprezinta o problema, cu exceptia liniilor lente. Chiar si atunci, problema se poate rezolva, deoarece sunt luate diferite masuri de precautie care ar trebui sa impiedice aparitia acestor probleme in cele mai multe cazuri. - acest protocol foloseste "metrici" fixe pentru a compara rutele alternative. Nu este adecvat sa se utilizeze RIP in situatiile in care rutele trebuie sa fie alese pe baza parametrilor de timp real, cum ar fi intarzierea, fiabilitatea, sau incarcarea. Extensiile evidente pentru a permite utilizarea metricilor de acest tip sunt susceptibile de a introduce instabilitati pe care protocolul nu a fost proiectat sa le manipuleze.

3.3. Organizarea lucrarii Partea principala a acestei lucrari este organizata in doua parti:
a) O dezvoltare conceptuala si justificarea algoritmilor vector distanta in general.

b) Descrierea protocolului. Sectiunea 3.4 incearca sa ofere o prezentare informala a bazelor matematice ale algoritmului. Initial un algoritm, destul de simplu este descris. Apoi, perfectionari ale acestuia se adauga in sectiunile succesive. Sectiunea 3.5 reprezinta descrierea protocolul actual. Cu exceptia cazurilor specificate la punctul 3.4, ar trebui sa fie posibil sa se puna in aplicare protocolul RIP folosind specificatiile prevazute la punctul 3.5.

3.4 Algoritmi vector distanta

Rutarea reprezinta sarcina de a gasi o cale de la un expeditor catre o destinatie dorita. In modelul Internet (bazat pe IP) aceasta se reduce in primul rand la o chestiune de a gasi o serie de rutere aflate intre sursa si retelele de destinatie. Atat timp cat un mesaj sau o datagrama ramane pe o singura retea sau subretea, orice probleme de expediere sunt responsabilitatea tehnologiei pe care este bazata reteaua. De exemplu, Ethernet si ARPANET, fiecare definesc un mod in care orice expeditor poate vorbi cu orice destinatie din cadrul aceleiasi retele. Rutarea IP este necesara in primul rand, atunci cand mesajele trebuie sa mearga de la un expeditor dintr-o retea catre o destinatie aflata in alta retea. In acest caz, mesajul trebuie sa treaca prin unul sau mai multe rutere ce conecteaza retelele. In cazul in care retelele nu sunt adiacente, mesajul poate trece prin mai multe retele care intervin, si ruterele care realizeaza conectarea acestora. Odata ce mesajul ajunge la un router care este in aceeasi retea ca destinatie, tehnologia din reteaua proprie este folosita pentru a ajunge la destinatie. In aceasta sectiune, termenul de "retea" este folosit generic pentru a desemna o retea de difuzare (broadcast) (de exemplu, Ethernet), o linie punct la punct, sau reteaua ARPANET. Punctul critic este faptul ca o retea este tratata ca o singura entitate de catre IP. Astfel, fie nici o decizie de rutare nu este necesara (ca in cazul legaturilor punct la punct), fie transmiterea se face intr-un mod care este transparent pentru IP, permitand astfel IP-ului sa trateze intreaga retea ca un singur sistem complet conectat (ca in cazul Ethernet sau ARPANET). Termenul de "retea" este utilizat intr-un mod oarecum diferit atunci cand este vorba de adresare IP. Sunt posibile mai multe abordari diferite pentru a gasi rute intre retele. O modalitate utila de a imparti aceste abordari este pe baza informatiilor de care ruterele au nevoie sa faca schimb, in scopul de a fi capabile sa gaseasca rute. Algoritmii vector distanta se bazeaza pe schimbul de informatii in cantitati mici. Fiecare entitate (ruter sau gazda), care participa la protocolul de rutare se presupune ca pastreaza informatiile despre toate destinatiile din cadrul sistemului (retelei). In general, informatiile despre toate entitatile conectate la o retea sunt sintetizate de o singura intrare, care descrie drumul spre toate destinatiile din acea retea. Aceasta sumarizare este posibila deoarece rutarea in cadrul unei retele este invizibila pentru IP. Fiecare intrare in aceasta baza de date de rutare include urmatorul ruter spre care datagramele destinate pentru entitatea specificata ar trebui sa fie trimise. In plus, aceasta include o "metrica" ce masoara distanta totala pana la destinatie. Distanta este un concept destul de generalizat, care poate acoperi intervalul de timp necesar pentru transmiterea mesajelor la entitatea destinatie, costul din punct de vedere financiar pentru a trimite mesaje la aceasta, etc. Denumirea de algoritmii vector distanta provine de la faptul ca rutele optime se pot determina atunci cand singurele informatiile schimbate sunt reprezentate de o lista a acestor distante. In plus, informatiile sunt schimbate doar intre entitatile care sunt adiacente, adica, entitatile care impartasesc o retea comuna. Desi rutarea este cel mai frecvent bazata pe informatiile despre retele, uneori este necesar sa se cunoasca rutele catre gazde/entitati destinatie individuale. Protocolul RIP nu face nicio distinctie formala intre retele si gazde. Acesta descrie pur si simplu schimbul de informatii cu privire la destinatii, care pot fi retele sau gazde. De fapt, evolutiile matematice sunt cel mai adesea gandite in termeni de rute de la o gazda (sau de la un ruter) catre alta.

Atunci cand se discuta despre algoritm in termen abstract, cel mai bine este ca o ruta pentru o retea sa fie privita ca o abreviere catre toate rutele pentru toate entitatile conectate la reteaua respectiva. Acest tip de simplificare are sens doar atunci cand se vorbeste de retelele care nu prezinta nici o structura interna, care sa fie vizibila la nivelul IP. Astfel, in general, este atribuita aceeasi distanta catre orice entitate dintr-o retea data. Am spus mai sus ca fiecare entitate pastreaza o baza de date de rutare cu o intrare pentru fiecare destinatie posibila in sistem. O implementarea efectiva este posibil sa aiba nevoie de urmatoarele informatii despre fiecare destinatie: - adresa: in implementari IP a acestor algoritmi, aceasta va fi adresa IP a entitatii destinatie sau a retelei. - ruter: primul ruter de-a lungul traseului pana la destinatie. - interfata: reteaua care trebuie utilizata pentru a ajunge la primul ruter. - metrica: un numar, care indica distanta pana la destinatie. - timer: intervalul de timp de la ultima actualizare. In plus, flaguri si alte diverse informatii interne, vor fi probabil incluse. Aceasta baza de date este initializata cu o descriere a echipamentelor care sunt conectate direct la sistem. Aceasta este actualizata in functie de informatiile primite in mesajele de la ruterele vecine. Cele mai importante informatii schimbate de catre gazde si rutere se regasesc in mesajele de actualizare. Fiecare entitate care participa la procesul de rutare trimite mesaje de actualizare care descriu baza de date de rutare asa cum exista la acel moment in entitatile respective. Este posibil sa se mentina rutele optime pentru intregul sistem doar prin utilizarea informatiilor obtinute de la entitatile vecine. Algoritmul utilizat pentru acest lucru va fi descris in sectiunea urmatoare. Asa cum s-a mentionat mai sus, scopul rutarii este de a gasi o modalitate pentru a trimite datagrame la destinatiile lor finale. Algoritmii vector distanta se bazeaza pe un tabel in fiecare ruter listeaza cea mai buna cale pentru a ajunge la orice destinatie din sistem. Desigur, pentru a defini traseul cel mai bun, trebuie sa existe un mod de masurare a optimului. Acest lucru este reprezentat de metrica. In cazul retelelor simple, este util sa se foloseasca ca unitate de masura numarul ruterelor prin care un mesaj trebuie sa treaca pentru a ajunge la destinatie. In cazul retelelor mai complexe, se alege ca unitate de masura un parametru care reprezinta intarzierea pe care o sufera mesajul, costul pentru a trimite mesajul, sau o alta cantitate care poate fi minimizata. Cerinta principala este ca metrica sa poata fi reprezentata ca o suma de costuri pentru fiecare hop. Formal, daca este posibil sa se ajunga de la entitatea i la entitate j direct (de exemplu, fara a trece printr-un alt ruter), atunci costul, d(i, j), este asociat cu hop-ul dintre i si j. In cazul normal, in care toate entitatile dintr-o anumita retea sunt considerate a fi la fel, d(i, j) este

acelasi pentru toate destinatiile, si reprezinta costul de utilizare a retelei respective. Pentru a obtine metrica unei rute complete, trebuie doar sa se adune costurile individuale care alcatuiesc ruta. In sensul acesa, se va presupune in continuare ca toate costurile sunt numere intregi pozitive. Vom presupune costurile ca fiind numere ntregi pozitive. Fie D(i,j), care reprezint metrica celei mai bune rute de la entitatea i la entitatea j. Ar trebui definit pentru fiecare pereche de entiti. d(i,j) reprezint costul pailor individuali. Formal, d(i,j) reprezint costul de a trece direct de la entitatea i la entitatea j. Este infinit dac i i j nu sunt vecini imediai. (De reinut c d(i,i) este infinit. Astfel nu considerm c exist o legtur direct de la nod la el nsui.) Din moment ce costurile sun aditive este uor de artat c cea mai bun metric trebuie descris de D(i,i) = 0, pentru toi i D(i,j) = min [d(i,k)+D(k,j)], altfel i c cele mai bune rute ncep mergnd de la i la acei vecini k pentru care d(i,k) + D(k,j) are valoare minim. (Acest lucru poate fi artat prin inducie pe numrul de pai din rute.) Reinem c putem limita a doua ecuaie la k care sunt vecini imediai ai lui i. Pentru ceilali, d(i,k) este infinit, astfel termenul care l implic nu poate fi niciodat minim. Astfel ne dm seama c putem calcula metrica printr-un simplu algoritm bazat pe acest lucru. Entitatea i face ca vecinii k s trimit estimrile lor asupra distanei ctre destinaia j. Cnd i primete estimrile de la k, adaug d(i,k) la fiecare numr. Acesta este costul traversrii reelei ntre i i k. Din cnd n cnd i compar valorile de la toi vecinii i alege cea mai mic valoare. Ni se d o dovad n [2] c acest algoritm va converge la estimrile corecte ale D(i,j) ntr-un timp finit n absena schimbrilor de topologie. Autorii fac foarte puine presupuneri privind ordinea n care entitile i trimit reciproc informaiile sau cnd minimul este recalculat. Practic, entitile nu se pot opri din a trimite actualizri sau din a recalcula metrici i reelele nu pot ntrzia mesajul la infinit. (Cderea unei entiti de routare reprezint o schimbare de topologie.) n plus, dovada lor nu face din o presupunere asupra estimrilor iniiale ale lui D(i,j), n afara faptului c trebuie s fie ne-negative. Ideea c aceste presupuneri destul de slabe sunt suficiente este important. Deoarece nu trebuie s facem presupuneri legat de cnd se trimit actualizri, putem rula algoritmul asincron. Adic fiecare entitate poate trimite actualizri dup propriul ceas. Actualizrile pot fi aruncate din reea atta timp ct nu sunt aruncate toate. Deoarece nu trebuie s facem presupuneri asupra condiiilor de start, algoritmul poate suporta schimbri. Cnd sistemul se schimb, algoritmul de routare ncepe s se mite ctre un nou echilibru, folosind vechiul echilibru ca punct de plecare. Este important ca algoritmul s convearg n timp finit indiferent de punctul de pornire. Altfel, anumite tipuri de schimbri vor duce la un comportament neconvergent. Enunul algoritmul dat mai sus (i demonstraia) presupune c fiecare entitate pstreaz copii ale estimatelor care vin de la fiecare vecin, i din cnd n cnd se face un minim al tuturor vecinilor. De fapt, implementrile reale nu fac neaprat acest lucru. Ele in pur i simplu minte cea mai bun metric vzut pn n prezent i identitatea vecinului care a trimis-o. nlocuie aceast informaie de fiecare dat cnd gsesc o metric mai bun. Acest

lucru le permite s calculeze minimul incremental, fr a fi nevoie s stocheze date de la toi vecinii. Mai exist o diferen ntre algoritmul descris n teorie i cel folosit n protocoale reale cum ar fi RIP: descrierea de mai sus ar face ca fiecare entitate s includ o nregistrare pentru ea nsi, artnd o distan zero. De fapt acest lucru nu se face n general. S ne amintim c toate entitile dintr-o reea sunt sumarizate in mod normal de o singur nregistrare pentru reea. S considerm situaia de un host sau router G care este conectat la reeaua A. C reprezint costul de a folosi reeaua A (de obicei o metric de 1). (Amintim c presupunem c structura intern a unei reele nu este vizibil IP-ului i astfel costul de merge ntre oricare dou entiti este acelai.) n principiu, G ar trebui s primeasc un mesaj de la fiecare alt entitate H din reeaua A, artnd un cost 0 de a ajunge de la acea entitate la sine. G ar calcula apoi C + 0 ca distana pn la H. Dect s facem ca G s se uite la toate aceste mesaje identice, ncepe pur i simplu prin a face o nregistrare pentru reeaua A n tabelul lui i i asigneaz o metric C. Aceast nregistrare pentru reeaua A trebuie gndit ca o sumarizare a intrrilor pentru toate celelalte intrri din reeaua A. Singura entitate din A care nu poate fi sumarizat de acea nregistrare comun este chiar G, din moment ce costul de merge de la G la G este 0 i nu C. Dar din moment ce nu vom avea nevoie niciodat de nregistrrile de 0, ne putem descurca cu singura nregistrare pentru reeaua A. Se observ o alt implicaie a acestei strategi: deoarece nu trebuie s folosim nregistrrile de 0 la nimic, hosturile care nu funcioneaz ca routere nu trebuie s trimit mesaje de actualizare. Clar hosturile care nu funcioneaz ca routere (adic hosturi care sunt conectate la o singur reea) nu pot avea informaia util cu care s contribuie. Din moment ce au o singur interfa, este uor de observat c o rut la oricare alta reea prin ele va trece prin acea interfa i se va ntoarce tot prin ea. Astfel costul unei asemenea rute va fi mai mare dect cel mai bun cost cu cel puin C. Din moment ce nu avem nevoie de intrrile de 0, non-routerele nu trebuie s participe deloc la protocolul de routare. S sumarizm ce face un host sau un router G. Pentru fiecare destinaie din sistem, G va ine o estimare a metricii pentru acea destinaie i identitatea routerului vecin pe ale crui date se bazeaz aceast metric. Dac destinaia este pe o reea care este direct conectat la G, atunci G folosete o nregistrare care arat costul folosirii reelei i faptul ca nu e nevoie de nici un router pentru a ajunge la destinaie. Este uor de artat c odat ce calcul a convers la metricile corecte, vecinul care este nregistrat de aceast tehnic este de fapt primul router pe calea ctre destinaie. (Dac exist cteva rute la fel de bune, este primul router de pe una dintre ele.) Aceast combinaie de destinaie, metric i router este tipic referit ca o rut la destinaie cu acea metric, folosind acel router. Metoda pn acum are doar o metod de a micora metrica, din moment ce metrica existent este pstrat pn cnd apare una mai mic. Este posibil ca estimata iniial s fie prea mic. Astfel, trebuie s existe o modalitate pentru a mri metrica. Este suficient s folosim urmtoarea regul: presupunem c ruta curent la o destinaie are metrica D i folosete routerul G. Dac un nou set de informaii a ajuns de la o alt surs dect G, actualizeaz ruta numai dac metrica este mai bun dect D. Dar dac un nou set de informaii ajunge de la G, ntotdeauna se actualizeaz D la noua valoare. Este uor de artat c cu aceast regul, procesul de actualizare incremental produce aceleai rute ca un calcul care ine minte ultimele informaii de la toi vecinii i face un minim explicit. (Reinem c

discuiile de pn acum presupun c configuraia reelei este static. Nu permite posibilitatea c un sistem poate cdea.) Pentru a sumariza, aici este algoritmul de baz de tip distance vector care a fost folosit pn acum. (Reinem c acesta nu este un enun al protocolului RIP. Mai exist cteva lucruri ce trebuie adugate.) Urmtoarea procedur este ndeplinit de fiecare entitate care particip la protocolul de routare. Acesta trebuie s includ toate routerele din sistem. Hosturile care nu sunt routere pot participa. - Pstrm un tabel cu o nregistrare pentru fiecare destinaie posibil din sistem. nregistrarea conine distana D la destinaie i primul router G de pe ruta la acea reea. Conceptual, ar trebui s fie o nregistrare pentru entitatea nsi, cu metrica 0, dar acest lucru nu este de fapt inclus. - Periodic, se trimite o actualizare de routare la fiecare vecin. Actualizarea reprezint un set de mesaje care conine toate informaiile de la tabelul de routare. Conine o intrare pentru fiecare destinaie, avnd i distana pentru acea destinaie. - Cnd o actualizare de routare ajunge de la un vecin G, adun costul asociat reelei care este partajat cu G. (Aceasta ar trebui s fie reeaua pe care a venit actualizarea.) Reine distanta rezultat D. Compar distanele rezultate cu nregistrrile curente din tabelul de routare. Dac noua distan D este mai mic dect D, se adopt noua rut. Astfel, schimb nregistrarea n tabel pentru N la a avea metrica D i routerul G. Dac G este routerul de la care a venit ruta existent, adic G = G, atunci se folosete noua metric chiar dac este mai mare dect cea veche. 3.4.1 Cu se ocup de schimbri de topologie Discuia de mai sus presupune c topologia reelei este fix. n practic, routerele i legturile cad i i revin destul de des. Pentru a ne descurca cu aceasta posibilitate, trebuie s modificm puin algoritmul. Versiunea teoretic a algoritmului implic un minim asupra tuturor vecinilor imediai. Dac topologia se schimb, vecinii se schimb. Astfel, urmtoarea dat cnd se vor face calculele, schimbarea se va reflecta. Cu toate acestea, implementrile reale folosesc o versiune incremental a minimizrii. Numai cea mai bun rut la orice destinaie dat este reinut. Dac routerul implicat n acea ruta ar cdea, sau conexiunea de reea la el s-ar ntrerupe, calculul nu va reflecta niciodat schimbarea. Algoritmul aa cum s-a artat pn acum depinde de un router care i atenioneaz vecinii dac se schimb metricile. Dac routerul cade, nu va mai avea cum s-i anune vecinii de o schimbare. Pentru a rezolva problemele de acest fel, protocoalele distance vector trebuie s fac unele dispoziii pentru rutele care urmeaz s expire. Detalii depind de ce protocol se folosete. Ca exemplu, n RIP fiecare router care particip la routare trimite un mesaj de actualizare ctre toi vecinii la fiecare 30 de secunde. S presupunem c ruta curent pentru reeaua N folosete routerul G. Dac nu primim nimic de la G timp de 180 de secunde, putem presupune fie c routerul a czut sau c reeaua ce ne leag de el a devenit nefolosibil. Astfel, marcm ruta ca invalid. Cnd primim anunuri de la un alt vecin care are o rut valid la N, ruta valid o va nlocui pe cea invalid. Reinem c ateptm 180 de secunde pn cnd declarm o rut invalid chiar dac ne ateptm sa auzim de la fiecare vecin la cte 30 de

secunde. Din pcate, mesajele sunt pierdute ocazional de reele. Astfel, nu este probabil o bun idee s invalidm o rut bazndu-ne pe singur mesaj care nu a ajuns. Dup cum putem vedea mai jos, este folositor s avem un mod de a notifica vecinii c momentan nu exist o rut valid la o anumit reea. RIP, mpreun cu alte cteva protocoale din aceast clas, face acest lucru printr-un mesaj normal de actualizare, marcnd reeaua ca nu se poate comunica cu ea. Se alege o valoare specific a metricii pentru a indica destinaiile imposibile de gsit; aceast metric fiind mai mare dect toate celelalte metrici pe care le putem gsi. n implementarea existent a RIP-ului valoarea este 16. Aceast valoare este referit i ca infinit, din moment ce este mai mare dect cea mai mare metric valid. 16 poate prea un numr foarte mic. Este ales aa de mic din cauza unor motive pe care le vom vedea n curnd. n cele mai multe implementri, aceeai convenie este folosit intern pentru a semnaliza o rut ca fiind invalid. 3.4.2 Prevenirea instabilitii Algoritmul prezentat pn n acest punct va permite ntotdeauna unui host sau unui router s calculeze un tabel de routare corect. Cu toate acestea, acest lucru nu este suficient pentru a-l face util n practic. Dovezile referite mai sus arat numai c tabelele de routare vor converge la valori corecte n timp finit. Nu garanteaz c acest timp va fi destul de mic ca s fie util, nici nu spun ce se va ntmpla cu metricile pentru reelele ce devin inaccesibile. Este destul de uor s extindem matematica pentru a se ocupa de rutele ce devin inaccesibile. Convenia sugerat mai sus va face acest lucru. Alegeam o valoare mare a metricii care s reprezinte infinit. Aceast valoare trebuie s destul de mare ca nici o alt metric real sa nu aib niciodat aceast valoare. Pentru scopurile acestui exemplu, vom folosi valoarea 16. Sa presupunem c o reea devine inaccesibil. Toi vecinii imediai ateapt s treac cele 180 de secunde apoi pun metrica acelei reele la 16. Din motive de analiz, putem presupune c toate routerele vecine au obinut o nou pies hardware care le conecteaz direct la reeaua disprut, cu un cost de 16. Din moment ce aceea este singura conexiune la reeaua disprut, toate celelalte routere din sistem vor converge la noile rute care trec prin unul din acele routere. Este uor de observat c odat ce s-a ajuns la convergen, toate routerele vor avea metrici de cel puin 16 ctre reeaua disprut. Routerele la un hop de routerele originale vor avea metrici de cel puin 17, etc. Din moment ce metricile sunt mai mari dect valoarea maxim a metricii, toate sunt setate la 16. Acum este evident c sistemul va converge la o metric de 16 pentru reeaua disprut pentru toate routerele. Din pcate, ntrebarea legat de ct dureaz convergena nu este aa de uor de rspuns. nainte de a merge mai departe, va fii util s privim un exemplu (luat de la [2]). Reinem c ceea ce urmeaz s artm nu se va ntmpla cu o implementare corect a RIPului. ncercm s artm de ce unele trsturi sunt necesare. n exemplul urmtor literele corespund routerelor iar liniile corespund reelelor.

Fiecare router va avea un tabel care va arta o rut la fiecare reea. Cu toate acestea, vom arta numai rutele de la fiecare router la reeaua marcat n partea de jos a diagramei - D: direct conectat, metrica 1 - B: rut via D, metric 2 - C: rut via B, metric 3 - A: rut via B, metric 3 Acum s presupunem c legtura de la B la D pic. Rutele ar trebui s se ajusteze ca s foloseasc legtura de la C la D. Din pcate, va fii nevoie de ceva timp ca acest lucru s se ntmple. Schimbrile de routare ncep cnd B observ c ruta la D nu mai este utilizabil. Pentru simplitate, tabelul de mai jos presupune c toate routerele trimit actualizri n acelai timp. Ta arat metrica pentru reeaua destinaie, dup cum apare n tabela de routare a fiecrui router. Timp -------- D: dir, 1 dir, 1 dir, 1 dir, 1 dir, 1 dir, 1 B: de neajuns C, 4 C, 5 C, 6 C, 11 C, 12 C: B, 3 A, 4 A, 5 A, 6 A, 11 D, 11 A: B, 3 C, 4 C, 5 C, 6 C, 11 C, 12 Dir= conectat direct Uite i problema: B reuete s scape de ruta czut folosind un mecanism de timeout, dar vestigii ale acelei rute persist n sistem pentru mult timp. Iniial, A i C nc cred c pot ajunge la D via B. Astfel, continu s trimit actualizri cu metrica 3 La urmatorul pas, B va sutine ca poate ajunge la D prin A sau C. Desigur, nu se poate. Rutele sustinute de A si C nu mai sunt, dar nu au cum sa stie asta inca.Chiar si cand descopera ca rutele prin B nu mai sunt, considera fiecare ca exista o ruta disponibila prin celalalt ruter.Cel mai rau caz este cand o retea devine inaccesibila complet dintr-o parte a sistemului.In acest caz, metrica poate creste incet intr-un model ca cel de mai sus pana cand in final ajung la infinit. Din acest motiv, problema este numita " numarare la infinit". Ar trebui acum sa intelegem de ce " infinit" este ales sa fie cat se poate de mic. Daca o retea devine inaccesibila complet, ne dorim ca numararea la infinit sa fie oprita cat se poate de repede.

"Infinit" trebuie sa fie suficient de mare astfel incat nici o ruta reala sa nu fie atat de mare. Dar nu ar trebui sa fie mai mare decat este cerut. Astfel alegerea " infinitului" este un compromis intre dimensiunea retelei si viteza de convergenta in cazul in care apare numararea la infinit. Realizatorii RIP au considerat ca protocolul nu este practic pentru retelele cu un diamentru mai mare de 15. Sunt cateva lucruri carepto fi facute pentru a preveni astfel de probleme. Cele folosite de RIP sunt numite: impartirea orizontului cu intoarcere otravita ( "split horizon with poisoned reverse") si actualizari declansate (" triggered updates").

Impartirea orizontului (split horizon)

Este de notat ca unele din problemele precedente sunt cauzate de faptul ca A si C sunt angajate intr-un model de inselatorie reciproca.Ambele sustin ca subt capabile sa acceseze D prin celalalt.Acest lucru poate fi prevenit fiind putin mai atenti unde informatiile sunt trimise.In particular, nu este niciodata folositor sa soliciti accesibilitate la o destinatie din retea de la vecinul (sau vecinii) de la care s-a invatat calea. Impartirea orizontului este o metoda de a evita problemele cauzate de includerea rutelor in update-urile trimise catre ruterul de la care s-au invatat acestea. Schema " simple split horizon" omite rutele invatate de la un vecin in actualizarile trimise acelui vecin. "Split horizon with poisoned reverse" include aceste rute in update-uri, dar seteaza metrica lor cu valoarea infinit. Daca A crede ca poate ajunge la D prin C, mesajele sale prin C ar trebui sa indice ca D nu este accesibil.Daca ruta prin C este reala, atunci C ori are o conectare directa la D, ori o conexiune printr-un alt ruter. Ruta lui C nu se poate intoarce prin A, pentru ca ar forma o bucla. Spunandu-i lui C ca D nu este accesibil, A doar se asigura ca C nu se inseala considerand ca exista o ruta prin A. Asta este evident pentru o linie punct la punct.Dar sa consideram posibilitatea ca A si C sunt conectate printr-o retea de difuzare ( broadcast network) ca si Ethernet-ul , si mai sunt si alte rutere in acea retea. Daca A are o cale prin C, ar trebuis sa indice ca D este neaccesibil cand se incearca legatura cu orice alt ruter din acea retea.Celelalte rutere din retea pot ajunge singure la C.Nu ar avea niciodata nevoie sa acceseze C prin A.Daca ruta cea mai buna a lui A este intr-adevar prin C, nici un alt ruter din acea retea nu trebuie sa stie ca A poate accesa D. Asta este favorabil, pentru ca inseamna ca acelasi mesaj de actualizare care este folosit pentru C poate fi folosit pentru toate celelalte rutere din aceeasi retea.Astfel, mesajele de actualizare pot fi trimise prin difuzare. In general, split horizon with poisoned reverse este mai sigura decat varianta simpla. Daca doua rutere au rute ce indica unul catre altul, anuntand rute inverse cu o metrica de 16 va rupe bucla imediat.Daca rutele inverse nu sunt anuntate, rutele eronate va trebui sa fie eliminate asteptand un timeout. Oricum, poisoned reverse are un dezavantaj: creste marimea mesajelor de rutare. Sa consideram cazul unui unui backbone al unui campus ce conecteaza un numar de cladiri diferite. In fiecare cladire,exista un router ce conecteza backbone cu

reteaua locala. Sa luam in cosiderare ce actualizari de rutare trebuie sa difuzeze acele routere in reteaua backbone. Toate celelalte retele au nevoie sa stie in ce retea locala e conectat fiecare router. Folosind metoda simpla, doar acele rute vor aparea in mesajele de actualizare trimise de router catre reteaua backbone. Daca se foloseste varianta cu poisoned reverse, routerul trebuie sa mentioneze toate rutele care sunt invatate de la backbone, cu metrica 16. Daca sistemul e mare , acest lucru poate duce la un mesaj de actualizare mare, majoritatea intrarilor indicand retele neaccesibile. Intr-un sens static, anunatarea rutelor inverse cu o metrica de 16 nu ofera infomatii aditionale. Daca sunt multe routere intr-o retea de difuzare, aceste intrari in plus pot folosi o largime de banda semnificativa. Motivul existentei lor este de a imbunatatii comportamentul dinamic. Cand topologia se schimba, se mentioneaza rute care nu ar trebui sa treaca prin router, precum si cele care ar trebui sa grabeasca convergenta.Oricum, in unele situatii, administratorii de retea prefera sa accepte o convergenta mai lenta pentru a minimiza rutarea over-head. Astfel se pot implementa split horizon simplu in favoarea variantei cu posison reverse sau pot folosi o optiune de configurare care le permite administaratorilor de retea sa aleaga ce comportament sa foloseasca. Este de asemenea posibil sa se implementeze scheme hibride care anunta unele rute inverse cu metrica 16 si le omit pe celelate. In RFC [11] se specifica implementarea RIP trebuie sa foloseasca split horizon si de asemenea split horizon with poison reverse,dei poate exista un buton pentru a dezactiva poisoned reverse.

Actualizari declansate (triggered updates)

Split horizon with poisoned reverse va preveni orice bucla de rutare care implica doar doua routere. Oricum, este in continuare posibil sa se sfarseasca cu un model in care trei routere sunt angajate intr-o inselaciune reciproca.De exemplu, A poate considera ca are o ruta prin B, B prin C, si C prin A. Split horizon nu poate sa opresca o astfel de bucla. Aceasta bucla poate fi rezolvata doar cand metrica ajunge la infinit si reteaua implicata este declarata neaccesibila. Acualizarile declansate sunt o incercare de a grabi convergenta. Pentru a primi actualizari declansate , doar adaugam o regula prin care daca un router isi schimba metrica pentru o ruta , trebuie sa trimita mesaje de actualizare aproape imediat, chiar daca nu este inca momentul pentru a trimite un mesaj de actualizare obisnuit. (Detaliile legate de timp difera de la protocol la protocol. Unele protocoale de vectori distanta , inclusiv RIP, specifica un timp mic de intarziere,pentru a evita generarea de actualizari declansate excesive.) Sa presupunem calea unui router catre destinatia N trece prin routerul G. Daca o actualizare soseste de la G, routerul ce o primeste trebuie sa creada noua informatie ,chiar daca noua metrica este mai mare sau mai mica decat cea veche. Daca rezultatul este o schimbare in metrica , atunci routerul receptor va trimite actualizari declansate la toate

dispozitivele garza si routerele direct conectate. La randul lor pot trimite aceste actualizari vecinilor lor. Rezultatul este o cascada de actualizari declansate. Este usor sa observi ce routere si hosturi sunt implicate in acea cascada. Sa consideram ca un router G sterge o ruta la destinatia N. G va trimite actualizari declansate catre toti vecinii sai. Oricum, singurii vecini care vor " crede" noua informatie sunt cei ale caror rute catre N trec prin G. Celelalte routere si gazde vor vedea asta ca o informatie despre o noua ruta care este mai dezavantajoasa decat ruta pe care ele o folosesc deja , si o ignora. Vecinii ale caror rute trec prin G isi vor actualiza metrica si vor trimite actualizari declansate catre toti vecinii lor. Din nou, doar acei vecini ale caror rute trec prin ele le vor lua in seama. Astfel, actualizarile declansate se vor propaga inapoi de-a lungul tuturor cailor ce duc la routerul G, actualizand metrica la infinit. Aceasta propagare se va opri in momentul in care se ajunge la o portiune de retea a carei ruta catre destinatia N foloseste o alta cale. Daca sistemul poate fi realizat astfel incat sa astepte pana cand cascada de actualizari declansate se sfarseste, ar fi posibil sa demonstram ca numararea la infinit nu ar aparea niciodata. Routerele cu probleme vor fi intotdeauna indepartate imediat, astfel nu se va forma nici o bucla de rutare. Din pacate, lucrurile nu sunt atat de usoare. Cat timp actualizarile declansate sunt trimise, actualizari normale pot fi generate in acelasi timp. Routerele care inca nu au primit actualizarile declansate vor trimite in continuare informatii bazate pe o ruta care nu mai exista. Este posibil ca dupa ce actualizarile declansate au fost trimise printr-un router, poate primi o actualizarare normala de la unul din aceste routere care nu au primit inca mesajul. Acest lucru ar putea restabili o ramasita a traseului defect. Daca actualizarile se declanseaza suficient de repede, acest lucru nu se mai intampla. Oricum, numararea la infinit este in continuare posibila. RFC [11] spune ca toate implementarile RIP trebuie sa folosesca actualizari declansate pentru rutele sterse si poate implementa actualizari declansate pentru noile rute sau pentru schimbarile rutelor.Implementarile RIP trebuie de asemenea sa limiteze viteza cu care actualizarile declansate trebuie sa fie transmise. 3.5 Specificarea protocolului

RIP este destinat sa permita routerelor sa schimbe informatie pentru a calcula rute printr-o retea IPv4. Orice router care foloseste RIP este presupus ca are interfata la una sau mai multe retele, altfel nu este cu adevarat router. Acestea sunt retelele direct conectate. Protocolul se bazeaza pe accesul la o anumita informatie despre fiecare din aceste retele, cea mai importanta fiind metrica sa. Metrica RIP a unei retele este un intreg intre 1 si 15 ,inclusiv. Este setata intr-un anumit mod, nespecificat in acest protocol; oricum, fiind data limita maxima de 15,este de obicei folosita valoarea 1. Implementarile ar trebui sa permita administratorilor de sistem sa seteze metrica fiecarei retele. In plus fata de metrica, fiecare retea va avea o adresa destinatie IPv4 si o

masca asociata acesteia. Acestea se seteaza de catre administratorul sistemului intr-un mod nespecificat in acest protocol. Orice gazda care foloseste RIP se presupune ca are interfata la una sau mai multe retele. Acestea se numesc retele "direct-conectate". Protocolul se bazeaza pe accesul la o anumita informatie despre fiecare din aceste retele.Cea mai importanta informatie este metrica sau "costul". Metrica RIP a unei retele este un intreg intre 1 si 15 ,inclusiv. Este setata intr-un anumit mod, nespecificat in acest protocol. Cele mai multe dintre implementarile existente folosesc metrica 1. Implementarile noi ar trebui sa permita administratorilor de sistem sa seteze metrica fiecarei retele. In plus fata de metrica, fiecare retea va avea o un adresa (numar) de retea IPv4 si o masca asociata acesteia. Acestea se seteaza de catre administratorul sistemului intr-un mod nespecificat in acest protocol. Avem in vedere ca regulile specificate presupun ca este o singura masca aplicata la fiecare retea IPv4, si ca sunt cunoscute mastile de retea numai pentru retelele direct-conectate. Pot exista sisteme care folosesc diferite masti de retea pentru diferite subretele intr-o singura retea. Pot fi de asemena situatii in care este preferabil pentru un sistem sa cunoasca mastile subretelelor ale retelelor la distanta. Distribuirea informatiei de rutare in retea, care contine diferite masti de retele este permisa daca toate routerele din retea functioneaza cum a fost prezentat in acest document. Oricum, daca toate routerele din retea nu functioneaza precum a fost descris, continand diferite masti trebuie limitate pentru a putea evita probleme de interoperabiliatate.

Fiecare router care implementeaza RIP este presupus ca are o tabela de rutare.Aceasta tabela are o singura intrare pentru fiecare destinatie care este accesibila prin sistemul RIP. Fiecare intrare contine cel putin urmatoarele informatii: -adresa de destinatie IPv4 -metrica, ce reprezinta costul total de a obtine un mesaj de la router la destinatie.Aceasta metrica este suma tuturor costurilor asociate retelelor care au fost traversate panala destinatie. -adresa IPv4 a urmatorului router de-a lungul caii catre destinatie (next hop).Daca destinatia este spre o retea direct conectata , aceasta nu este necesara. -un steag care sa indice ca informatia despre ruta s-a modificat recent. Acest steag se numeste "route change flag" -diverse cronometre asociate rutei. Intrarile pentru retelele direct-conectate sunt setate de router folosind informatia stransa prin cai nespecificate in acest protocol. Metrica pentru o retea direct-conectata este setata la costul acelei retele. Cum am mentionat, 1 reprezinta costul uzual. In acest caz,

metrica RIP se reduce la o simpla numarare de hop-uri. Metrici mai complexe pot fi folosite cand este necesar sa se arate preferintele unor retele fata de celelalte. Pentru a sustine extensiile detaliate in acest document, fiecare intrare trebuie sa contina aditional o masca de retea. Masca permite routerului sa identifice diferite subretele intr-o singura retea la fel ca si mastile retelelor la distanta. Implementatorii pot de asemenea alege sa permita administratorului de sistem sa introduca rute aditionale. Acestea vor fi mai mult ca sigur rute cate gazde sau retele din afara scopului sistemului de rutare. Se numesc "rute statice" .Intrarile pentru alte destinatii in afara acestora initiale sunt adaugate si actualizate prin algoritmi descrisi in sectiunile urmatoare. Pentru ca acest protocol sa ofere informatie completa la rutare,fiecare router din sistemul autonom (AS) trebuie sa participe la protocol. In cazul in care avem multiple IGP folosite, trebuie sa fie macar un router care sa "scurga" informatia de rutare dintre protocoale.

3.6 Formatul mesajului

Rip este un protocol bazat pe UDP. Fiecare router care foloseste RIP are un proces de rutare care trimite si primeste datagrame pe portul UDP cu numarul 520, portul RIP-1/RIP-2. Toate comunicatiile destinate pentru alte procese RIP ale altor routere sunt trimise prin portul RIP. Toate mesajele de actualizare a rutelor sunt trimise din portul RIP. Actualizarile nesolicitate au atat portul de sursa cat si de destinatie portul RIP. Mesajele de actualizare trimise ca raspuns la o solicitare sunt trimise pe portul de la care a sosit solicitarea.Interogari specifice pot fi trimise de pe porturin deiferite data de portul RIP, insa ele trebuie sa fie dirijate catre portul RIP pe masina tinta. Formatul pachetului RIP este:

Pot fi intre 1 si 25(inclusiv) intrari RIP. O intrare RIP-1 are urmatorul format:

Dimensiunea campurilor este data in octeti. Doar in cazul in care altceva este specificat, campurile pot contine numere intregi binare, reprezentate utilizand regula bigendian cu MSB ul pe primul octet. Fiecare mesaj contine un antet RIP, un header, care specifica numarul versiunii si o comanda. Aceasta sectiune a documentului descrie prima versiune a protocolului, iar sectiunea 4 extensiile specifice versiunii 2. Campul, care se refera la comanda, este utilizat pentru a specifica scopul mesajului. Comenzile implementate pe versiunea 1 si 2 sunt: 1) Request - Se trimite un mesaj catre sistemul partener (remote), catre vecin, prin care se cere o parte sau toata tabela de sa rutare. 2) Response - Reprezinta un mesaj care contine toata sau o parte din tabela de rutare a expeditorului. Acest tip de mesaj poate fi trimis ca raspuns la un request sau in mod nesolicitat in cazul in care se face o actualizare, un update, la tabela de rutare a expeditorului. Pentru toate aceste tipuri de mesaje, in versiunea 1, restul pachetului utilizat la nivel3 contine o lista cu Route Entries (RTEs). Fiecare intrare(RTE) din lista contine un Address Family Identifier (AFI), o adresa destinatie IPv4, si costul aferent destinatiei denumit metrica. Campul AFI contine tipul adresei. Pentru RIPv1, doar AF_INET(2) este in general disponibil. Metrica reprezinta o valoare cuprinsa intre 0 si 15 (inclusiv) si este asociata cu o destinatie IPv4; valoarea 16(infinitatea) indica faptul ca destinatia nu este inaccesibila. 3.7 Consideratii de adresare Rutarea de tip distance-vector este utilizata in descrierea rutelor catre retele sau statii individuale in internet. Protocolul RIP are la baza algoritmul Bellman-Ford utilizat in 1967 in cadrul proiectului ARPANET. Destinatiile apar in mesajele de tip request si response si pot fi retele, statii sau coduri speciale utilizate pentru a indica o adresa default (0.0.0.0). In general, tipurile de rute vor depinde de strategia de rutare utilizata pentru o retea in particulara. Sunt utilizate, in majoritatea cazurilor, retelele astfel informatia de rutare pentru o statie individuala nu este intotdeauna necesara. Daca fiecare nod intr-o retea sau subretea este accesibil prin

aceleasi rutere, nu este nevoie sa fie mentionate statiile individuale in tabela de rutare. Totusi, retelele care includ linii punct la punct necesita, cateodata, ca ruterele sa tine o evidenta a rutelor catre un nod anume. Daca aceasta caracteristica este necesara depinde doar de politica de adresare si rutare utilizata in sistem. In alte implementari rutele pentru statii nu sunt disponibile, ele fiind sterse in cazul in care apar intr-un mesaj de tip response. Formatul pachetului de RIPv1 nu face distinctie intre tipuri variate de adrese. Campurile care sunt etichetate cu address pot contine urmatoarele : adresa de gazda(host), subnet mask(masca retelei) , ruta default- reteaua 0. Entitatile care utilizeaza RIPv1 trebuie sa utilizeze partea specifica a informatiei de rutare disponibila. Cand un pachet de nivel3 ajunge sa fie rutat, adresa destinatie este verificata la inceput cu lista de adrese a nodurilor, daca se potriveste cu o subretea sau retea cunoscuta. Daca nu este gasita o corespondenta este preferata ruta default, daca exista. Daca nu, pachetul este aruncat. Cand un nod evalueaza informatia care este primita via RIPv1, interpretarea adresei depinde de faptul daca este cunoscuta masca care trebuie aplicata la retea. Daca da, este posibil sa fie determinat intelesul adresei. De exemplu, daca consideram reteaua 128.6.0.0 cu masca 255.255.255.0 , ip-ul 128.6.0.0 este reteaua, 128.6.4.0 este subreteaua, iar 128.6.4.1 este adresa nodului. Prin urmare daca nu este cunoscuta subreteaua, evaluarea adresei va fi ambigua. Daca exista o parte non-zero, atunci nu va fi clar sa determinam daca reprezinta o subreteau sau adresa unui nod. Utilizarea subretelelor nu va fi disponibila fara cunoasterea mascii adreselor, ele fiind obligatorii in reprezentarea nodurilor in astfel de situatii. Pentru a evita astfel de ambiguitati, cand se utilizeaza RIPv1, nodurile nu trebuie sa trimita rute catre alte noduri care nu pot cunoaste/citi masca asociata. In mod normal, statiile cunosc masca numai pentru retelele conectate direct. Astfel, doar daca este facuta o provizionare speciala, rutele ar trebui sa fie trimise in afara retelei de care apartin. RIPv2 (sectiunea 4) elimina aceasta problema incluzand masca subretelei in RTE. Filtrarea de subretele este realizata de catre rutere la marginea retelei subnetizate. Acestea sunt echipamente care interconecteaza retele. In cadrul retelei subnetizate, fiecare subretea este tratata ca retea individuala. Intrarile in tabela de rutare sunt manageriate de RIP. Totusi, ruterele de margine vor trimite doar o singura intrare cu intreaga retea pentru celalalte noduri. Acest lucru inseamna ca un astfel de ruter va trimite informatii de rutare diferite catre vecini diferiti. Pentru vecini conectati la retele subnetizate, genereaza o lista cu toate subretelele la care este direct conectat. Pentru vecini conectati la alte retele, va genera o singura intrare cu intreaga retea, impreuna cu metrica asociata. In mod normal aceasta va fi cea mai mica pentru subretelele direct conectate la ruter. In principiu, toate implementarile de RIP trebuie sa suporte rute de host, in caz contrar, vor trebui sa le ignore. Adresa speciala 0.0.0.0 este utilizata pentru a descrie ruta default. O asfel de ruta este generata in cazul in care nu este convenabil sa listezi toate retele posibile in update-urile RIP, si cand unul sau mai multe rutere conectate la sistem sunt pregatite sa proceseze tot traficul catre retele care nu sunt listate explicit. Aceste rutere vor crea intrari pentru adresa 0.0.0.0, ca si cum aceasta retea este direct conectata la ele. Decizia de creare a acestei rute apartine

implementatorului. Ca in cele mai multe cazuri, administratorul de retea va gasi o cale sa specifice care rutere sa creeze intrari pentru 0.0.0.0. De exemplu un implementator poate decide ca orice ruter care cunoaste BGP sa fie declarat ruter default. Poate fi util sa permita administratorului de retea sa aleaga metrica pentru astfel de rute. Daca exista mai mult de un ruter default, acest lucru va exprima preferinta catre unul sau altul. Intrarile pentru 0.0.0.0 sunt gestionate in exact aceeasi maniera ca si cum ar exista o retea cu aceasta adresa. Administratorul ar trebui sa se asigure ca rutele catre 0.0.0.0 sa nu se propage mai departe decat este cazul. In general, fiecare sistem autonom are ruterul default preferat. Rutele care sunt propagate utilizand 0.0.0.0 nu ar trebui sa paraseasca marginea sistemului autonom. 3.8 Timeri Aceasta sectiune descrie toate evenimentele care sunt declansate de timeri. La fiecare 30 de secunde, procesul RIP este activat pentru a trimite un mesaj de tip Response, nesolicitat, continand tabela completa de rutare(urmareste 3.9 Split Horizon) la fiecare ruter vecin. Cand exista mai multe rutere in aceeasi retea, exista tendinta ca acestea sa se sincronizeze intre ele in momentul in care vor trimite update-uri. Astfel ca la fiecare 30 de secunde este posibil ca toate sa trimita mesaje in acelasi timp. Acest lucru este indezirabil deoarece pot aparea coliziuni in domeniul de broadcast. Totusi se pot lua urmatoarele precautii: Update-urile la 30 de secunde sunt declansate de un ceas care nu este afectat de incarcarea sistemului sau de timpul necesar pentru a servi celalt update. Timerul de 30 de secunde este decalat de un mic offset de timp ales random (+/- 0 la 5 secunde) de fiecare data cand este setat.

Exista 2 timere asociate la fiecare ruta, un timp de timeout si unul garbagecollection. Dupa expirarea timeout-ului, ruta nu mai este valida; totusi, este retinuta in tabela de rutare pentru o scurta perioada de timp cat timp vecinii sunt notificati ca aceasta nu mai exista. Dupa expirarea ultimului timer, ruta este scoasa definitiv din tabela. Timerul de timeout este initializat cand o ruta este stabilita, sau de cate ori se primeste un mesaj update pentru ruta respectiva. Daca se scurg 180 de secunde de la initializarea acestuia, ruta se considera expirata, iar procesul de stergere este descris mai jos. Stergerea poate surveni din unul sau mai multe motive: timeout-ul expira, sau metrica este setata la 16 din cauza unui update venit de la ruterul current. In acest caz, se produc urmatoarele evenimente: Timerul garbage-collection este setat la 120 de secunde. Metrica pentru ruta este setata la 16. Acest lucru determina indepartarea rutei din serviciu. Bitul de schimbare ruta este setat pentru a indica ca intrarea a fost schimbata. Procesul este activat pentru a declansa un raspuns.

Pana cand timer-ul garbage-collection expira, ruta este inclusa in toate update-urile trimise de acest ruter. Cand acest timer expira, ruta este stearsa din tabela de rutare. Va trebui stabilita o noua ruta pentru acea retea , timp in care timerului se decrementeaza , noua ruta o va inlocui pe cea care trebuie stearsa. In acest caz timerul va fi sters. Update-urile declansate (triggered updates) folosesc un timer, care va fi descris in sectiunea 3.9.1. 3.9.1 Mesaje de tip Request Un Request este utilizat pentru a cere o parte sau toata tabela de rutare a ruterului vecin. In mod normal sunt trimise ca broadcast sau multicast (RIPv2 utilizeaza multicast la 224.0.0.9), de pe portul de RIP, de catre ruterele care tocmai au fost introduse in topologie si doresc sa isi umple tabela de rutare cat mai repede posibil. Totusi, exista situatii in care tabela de rutare a unui singur ruter este necesara. In acest caz Request-ul trebuie trimis direct catre acel router pe un port UDP. Astfel dupa ce mesajul este primit, raspunsul vine direct la adresa si portul solicitant. Cererea este procesata intrare cu intrare. Daca nu exista intrari, nici un raspuns nu este dat. Avem totusi un caz special. Daca exista exact o singura intrare in Request, si contine un AFI egal cu 0 si metrica 16, inseamna ca se cere intreaga tabela de rutare. In acest caz incepe procesul de trimitere a intregii tabele de rutare la adresa/portul solicitant. In afara de acest caz special, procesarea este chiar simpla. Examinarea listei de intrari RTE din Request se face una cate una. Pentru fiecare , se urmareste destinatia in baza de date a ruterului, iar daca exista o ruta se pune metrica in campul corespondent a RTE-ului. Daca nu exista rute la destinatia specificata, se trece infinit. Dupa ce toate intrarile au fost completate, se schimba comanda din Request in Response, si se trimite pachetul catre solicitant. Exista o diferenta intre manipularea metricii pentru request-uri cu intreaga tabela sau individuale(specifice). Daca cererea este cu intreaga tabela, procesarea se face incluzand Split Horizon (3.9). Daca requestul este pentru o intrare specifica, aceasta este cautata in tabela de rutare si apoi daca este gasita este returnata informatia necesara; in acest caz Split Horizon nu intervine in procesare. Motivul pentru aceasta distinctie il reprezinta perspectiva ca aceste cereri sa fie utilizate pentru alte scopuri. Cand un ruter intervine in topologie, trimite multicast-uri la fiecare retea conectata intreband de tabele de rutare complete. Se insuseste faptul ca aceste tabele sunt utilizate pentru a updata tabela de rutare a solicitantului. Pentru acest motiv, Split Horizon trebuie sa intervina. Se insuseste faptul ca un Request pentru o retea specifica este facut doar de catre software-ul de diagnostic, si nu este utilzat in ruting. In acest caz, solicitantul, va dori sa cunoasca exact continutul tabelei de rutare si nu va ascunde sau altera informatia. 3.9.2 Mesajele Response Un astfel de mesaj poate sa fie receptionat din urmatoarele motive: Respuns la o interogare specifica,

Update regulat(response nesolicat) Update declansat - generat de o schimbare de ruta.

Procesarea se face la fel, nu conteaza de ce acest tip de mesaj a fost generat. Fiindca procesarea unui Response poate duce la schimbarea tabelei de rutare, acesta trebuie verificat atent daca este valid. Acesta poate fi ignorant daca nu vine de la un port RIP. In pachetul de nivel3 IPv4 adresa sursa trebuie verificata pentru a vedea daca vine de la un vecin valid; sursa trebuie sa fie dintr-o retea direct conectata. De asemenea merita verificat daca raspunsul este de la propria adresa. Interfetele din retele de tip broadcast pot primi copii ale propriilor mesaje broadcast/multicast imediat. Deindata ce tot pachetul a fost validat, se realizeaza procesarea RTE-urile din Response una cate una. Iarasi, se porneste de la validare. Metrici incorecte sau erori de format indica probleme cu echipamentul vecin si cel mai probabil va fi nevoie de atentia administratorului. De exemplu, daca metrica este mai mare decat infinit, se ignora intrarea si se inregistreaza evenimentul. Testele de validare sunt : Adresa destinatie sa fie valida. Metrica sa fie valida.

Daca aceste verificari nu trec, se ignora acea intrare si se trece la urmatoarea. Inca o data, se poate inregistra evenimentul(logging). O data ce intrarea a fost validata, se face update la metrica prin adaugarea unui costului retelei de unde mesajul a venit. Daca rezultatul este mai mare decat infinit , se utilizeaza infinit. metric = MIN(metric + cost, infinity) Se verifica daca deja exista o ruta explicita pentru adresa destinatie. Daca nu, se adauga aceasta ruta in tabela, daca metrica este diferita de infinit. Adaugarea unei rute consta in : Setarea adresei destinatie la adresa destinatie din RTE Setarea metricii nou calculate in campul asociat Se completeaza adresa echipamentului vecin de la care a venit pachetul ca nexthop Se seteaza bitul de schimbare. Se declanseaza procesul de actualizare (3.8.1)

Daca exista deja o ruta calculata, se compara adresa vecinului (next-hop) cu adresa ruterului de unde a venit pachetul. Daca este la fel, se reinitializeaza timer-ul timeout. Se compara apoi metricile. Daca pachetul provine de la acelasi ruter, si noua metrica este diferita de cea veche, sau daca noua metrica este mai mica decat cea veche se executa:

Se adopta noua ruta din pachet (seteaza noua metrica si se ajusteaza adresa IPv4 a vecinului daca este necesar) Se seteaza bitul de schimbare si se declanseaza actualizarea Daca noua metrica este infinit, se porneste procesul de stergere, altfel se reinitializeaza timeoutul.

Daca noua metrica este infinit, procesul de stergere incepe pentru ruta respectiva, care nu va mai fi folosita in rutarea pachetelor. Procesul de stergere incepe numai dupa ce metrica este setata la infinit. Daca metrica este deja 16, atunci noul proces de stergere nu va mai incepe. Daca noua metrica este identica cu cea veche, cel mai simplu ar fi sa nu se actioneze(doar se reinitializeaza timerul). In mod normal, nu are sens sa inlocuiesti o ruta, daca cea noua are aceeasi metrica cu cea veche; asta ar cauza ca ruta sa fie introdusa si apoi scoasa din tabela, fapt ce ar genera un numar intolerabil de mare de update-uri. Totusi daca ruta existenta da semne de timeout, ar fi ideal sa o schimbi cu o alta alternativa la fel de eficienta, fara sa mai astepti timer-ul de timeout. Totusi, daca noua metrica este la fel cu cea veche, se examineaza timer-ul pentru ruta existenta.

3.10 Output Processing Aceasta sectiune descrie procesarea efectuata pentru crearea mesajelor de raspuns care contin fie toata fie o parte din tabela de rutare. Aceasta procesare poate fi realizata prin urmatoarele modalitati: - Prin prelucrarea intrarilor, atunci cand o Cerere (Request) este primita ( raspunsul aferent este trimis unicast catre solcitant; vezi pct.3.7.1) -Prin informatile de rutare trimise in mod regulat de routere (broadcast/ multicast la fiecare 30 de secunde). - Prin declasarea update-urilor (broadcast / multicast atunci cand se produce schimbarea unei rute); Atunci cand un raspuns(Response) trebuie sa fie trimis catre toti vecinii (de exemplu, un update periodic sau declansat) un mesaj de raspuns este directionat spre router la capatul fiecarui link conectat punct-la-punct si este trimis sub forma de broadcast (multicast pentru RIP-2) in toate retelele conectate care suporta mesaje de acest tip. Astfel, este pregatit cate un raspuns pentru fiecare retea direct conectata si este trimis la adresa corespunzatoare (direct sau sub forma de broadcast / multicast). In majoritatea cazurilor, aceasta ajunge la toate routerele vecine. Cu toate acestea, exista unele cazuri in care acest lucru nu este suficient de

exemplu o retea care nu suporta broadcast ( ARPANET) sau o situatie care implica routere mai putin performante. In astfel de cazuri, poate fi necesara precizarea unei liste propriu-zise de routere vecine si trimiterea unei datagrame pentru fiecare in mod explicit. Administratorul poate stabili daca un astfel de mecanism este necesar si poate defini ce specificatii trebuie sa conina aceasta lista. 3.10.1 Triggered Updates Update-urile declansate necesita un tratament special din doua motive. In primul rand, experienta arata ca update-urile declansate pot provoca sarcina excesiva capacitate limitata sau in retele care contin mai multe routere. Drept urmare, protocolul prevede ca administratorul sa stabileasca dispozitii care sa limiteze frecventa acestor update-uri declansate. Dupa ce o actualizare declansata este trimisa, un timer ar trebui sa fie setat pentru un interval aleator intre1 si 5 secunde. In cazul in care alte modificari care ar putea declansa actualizari apar inainte de expirarea timpului acordat, o singura actualizare este trimisa atunci cand timpul expira.Timer-ul este apoi resetat la o alta valoare aleatoare intre 1 si 5 secunde.Un update spontan trebuie sa fie suprimat in cazul in care un update periodic este trimis in acelasi moment. In al doilea rand, update-urile spontane sau declansate nu trebuie sa includa toata tabela de rutare. In principiu, numai rutele care s-au schimbat trebuie sa fie incluse. Prin urmare, mesajele generate ca parte a unui update declansat trebuie sa includa cel putin acele rute care s-au schimbat. Acestea pot include rute suplimentare dupa decizia administratorului, cu toate acestea, trimiterea unor actualizari de rutare complete este puternic descurajata. Atunci cand un update declaat este procesat, mesajele trebuiesc generate pentru fiecare reea direct conectata. Procesarea Split Horizon se face atunci cand se genereaza update-uri declansate precum si update-uri normale (vezi pct. 3.9). In cazul in care, dupa prelucrarea Split Horizon pentru o anumita retea, un traseu modificat va aparea neschimbat (de exemplu, apare cu o metrica infinita), ruta nu trebuie sa fie trimisa. Daca nici o alta ruta nu trebuie trimisa in aceasta retea, update-ul poate fi omis. Odata ce toate update-urile declanate au fost generate,fanioanele de schimbare a rutei trebuie eliminate.Daca procesarea intrarilor este permisa in timp ce ieirile sunt generate, trebuie facuta o centralizare corespunzatoare. Fanioanele de schimbare a rutei nu trebuie modificate in urma prelucrarii intrarilor in acelasi timp ce este declansat un update. Singura diferenta dintre un update declansat si alte mesaje de actualizare este posibila in retelele cu

omitere a rutelor care nu s-au schimbat. Mecanismele ramase, descrise in sectiunea urmatoare, trebuie sa se aplice in cazul tuturor actualizarilor. 3.10.2 Generarea mesajelor de tip Raspuns (Response) Aceasta sectiune descrie modul in care un mesaj de raspuns este generat pentru o anumita retea direct conectata : Setati numarul de versiune la 1 sau 2. Mecanismul pentru a decide ce versiune trebuie folosita pentru trimiterea mesajelor este specific fiecarui administrator; cu toate acestea, daca acest mesaj este un raspuns(Response) la o cerere(Request), versiunea cu care este trimis raspunsul trebuie sa se potriveasca cu versiunea folosita pentru trimiterea cererii. Setati comanda drept raspuns. Setati biti etichetati "Must Be Zero" la zero. Incepeti completarea RTE.Trebuie reamintit faptul ca exista o limita de 25 RTE-uri la un raspuns, daca sunt mai multe, este necesara trimiterea actualului raspuns si inceperea unui nou Raspuns. Nu exista nici o limita definita cu privire la numarul datagramelor care alcatuiesc un Raspuns. Pentru a umple RTE-urile, trebuie examinata fiecare ruta din tabela de rutare. Daca un update declansat este generat,numai intrarile ale caror fanioane de schimbare a rutei sunt setate trebuie sa fie incluse. In cazul in care, dupa prelucrarea Split Horizon, ruta nu ar trebui sa fie inclusa,trebuie omisa. In cazul in care ruta trebuie sa fie inclusa, atunci adresa destinatie si metrica sunt adaugate in RTE. Rutele trebuie sa fie incluse in datagrama, chiar daca metrica lor este infnita.

4. Extensii ale protocolului

Aceasta sectiune descrie extensii ale formatului mesajului care permite routerelor sa imparta informatii suplimentare importante.Atat pentru mesajele RIP-1 cat si pentru cele RIPV2 formatul antetului utilizat este acelasi (vezi pct. 3.4). Formatul pentru RIP-2 care contine 20 octei este urmatorul:

Identificatorul adresei surse (Adrees Family Identifier), adresa IP si metrica sunt definite in sectiunea 3.4. Campul pentru verisune va specifica numarul versiunii 2 pentru mesajele RIP care utilizeaza autentificare sau transporta informatii in oricare dintre campurile noi definite. 4.1 Autentificare Din moment ce autentificarea este o functie pentru mesaje exista doar un singur camp de 2 octeti disponibil in antetul mesajului si dat fiind faptul ca orice sistem de autentificare rezonabil necesita mai mult de doi octeti, sistemul de autentificare pentru versiunea RIP-V2 va utiliza intregul spatiu. Daca campul Address Family Identifer al primei intrari in mesaj este 0xFFFF, restul mesajului este pentru autentificare. Acest lucru inseamna ca pot fi cel mult 24 de intrari RIP in restul mesajului.Daca autentificarea nu este folosita atunci nici o intrare din mesaj nu ar trebui sa aiba Address Family Identifer setat la valoarea 0xFFFF. Un mesaj RIP care contine o intrare de autentificare ar incepe cu urmatorul format:

In prezent, singurul tip de autentificare este parola simpla si este de tip 2. Restul de 16 octeti contin parola text simplu. In cazul in care parola este sub 16 octeti, aceasta trebuie completata la dreapta cu 0 (0x00). 4.2 Route Tag Campul Route Tag(RT) este un atribut stabilit pentru un traseu care trebuie sa fie conservat. Utilizarea preconizata a Route Tag este de a oferi o metoda de separare "interna" a rutelor RIP (rute pentru retelele din cadrul domeniului de rutare RIP) din rute "externe" RIP, care ar fi fost importate dintr-un EGP sau un alt IGP. Routerele care suporta alte protocoale in afara de RIP ar trebui sa fie setate sa permita ca Route Tag sa fie configurat la randul sau pentru rutele importate din diferite surse. De exemplu, rutele importate din EGP sau BGP ar

trebui aiba Route Tag setat la o valoare arbitrara sau cel putin la numarul sistemului autonom din care rutele au fost invatate. Alte utilizari pentru Route Tag sunt valabile atat timp cat toate routerele din domeniul RIP il foloseasc in mod consecvent. Acest lucru permite posibilitatea interactiunii protocoalelor BGP-RIP care ar descrie metode pentru sincronizarea rutarii intr-o retea de tranzit. 4.3 Subnet mask Campul Subnet Mask contine masca de retea care se aplica la adresa IP sa cedeze partea de non-gazda a adresei. Daca acest camp este zero, atunci nu a fost inclusa nici o masca de retea pentru aceasta intrare. Pe o interfata in care un router RIP-1 poate opera informatia unei intrari RIP V2 se aplica urmatoarele reguli: 1) informatiile interne unei retele nu trebuie sa fie anuntate intr-o alta retea 2) informatiile specifice despre o anumita retea nu pot fi anutate in cazul in care routerele RIP-1 ar considera o ruta gazda in aceasta retea 3) rutele supernet (trasee cu o masca de retea mai putin specifca decat masca normala de retea) nu trebuie sa fie anuntate in cazul in care acestea ar putea fi interpretate gresit de routerele RIP-1. 4.4 Next Hop Reprezinta Adresa IP a urmatorului punct in retea la care pachetele trebuiesc trimise sa ajunga la destinatie. Specificarea unei valoari de 0.0.0.0 in acest camp indica faptul ca rutarea ar trebui sa se realizeze prin intermediul initiatorului advertismentului RIP. O adresa care serveste drept next hop trebuie sa fie accesibila direct in subreteaua in care a fost trimis un advertisment. Scopul campului Next Hop este de a elimina dirijarea pachetelor prin puncte suplimentare in retea catre destinatie. Este deosebit de util atunci cand protocolul RIP nu este rulat pe toate routerele dintr-o retea. 4.5 Multicasting In scopul de a reduce aglomerarea inutila a retelei pe aceele hosturi care nu folosesc mesaje RIP V2, o adresa IP multicast va fi folosita pentru mesajele de tip broadcast periodice. Adresa IP multicast este 224.0.0.9. Trebuie retinut faptul ca IGMP nu este necesar deoarece aceste mesaje sunt de tip inter-router si nu sunt transmise mai departe. In retelele

NBMA, adresarea de tip unicast poate fi utilizata. Cu toate acestea, in cazul in care un raspuns cu adresa multicast RIP-2 asignata este primit acesta ar trebui sa fie acceptat. Pentru a mentine compatibilitatea, utilizarea adresei multicast va fi configurata asa cum este descris la pct. 5.1.Daca se folosesc mesajele de tip multicast acestea ar trebui sa fie trimise doar pe interfete care suporta acest tip de adresare. 4.6 Queries Daca un router RIP-2 primeste o cerere RIP-1 Request, ar trebui trimita un raspuns de tip RIP_1 Response. In cazul in care routerul este configurat pentru a trimite numai mesaje RIP-2, aceasta nu ar trebui sa raspunda la cereri de tip RIP-1 Request .

5. Compatibilitate
Este important sa se tina cont de versiunile folosite pentru compatibilitate. Trebuie specificat ca mesajele RIP versiunea 0 si mesajele RIP versiunea 1 trebuie sa fie eliminate in cazul in care campul Must Be Zero (MBZ) nu este zero si ca mesajele RIP de orice versiune mai mare de 1 nu ar trebui sa fie aruncate pur si simplu pentru ca un camp MBZ contine o valoare diferita de zero. Aceasta inseamna ca noua versiune de RIP este total compatibila cu implementarile existente RIP. 5.1 Compatibilitate Switch O compatibilitatea switch este necesara din 2 motive.In primul rand, exista implementari ale RIP-1 in domeniu care nu urmaresc RFC[1] asa cum este descries mai sus.In al doilea rand , folosirea multicasting-ului va preveni sistemele RIP-1 de la primirea updateuriloe RIP-2 (actiune dorita in unele cazuri).Acest switch ar trebui configurat per- interfata. Switch-ul are 4 moduri de functionare: RIP-1, mod in cacre sunt transmire doar mesajele RIP-1, compatibilitate cu RIP-1, mod in care mesajele RIP-2 sunt mesaje broadcast; RIP-2, mod in care mesajele RIP-2 sunt mesaje multicast si modul none, mod se dezactiveaza trimiterea mesajelor RIP-1. Este recomandabil ca setarea default sa fie RIP-1 ori RIP-2, nu RIP-1 compatibility. Acest lucru este datorat unor probleme de potential cauzate de anumite topologii.Modul RIP-1 compatibility ar trebuit folosit doar atunci cand administratorul de retea intelege toate urmarile folositrii acestui mod de functionare.

Pentru conectivitate, routerele ar trebui de asemenea sa imlementeze un switch de control ce ar determina acceptarea RIP-1, RIP-2, ambele ori nici unul.Acesta ar fi de asemenea configurabil per-interfata.Este recomandabil ca modul default de compatibilitate sa fie ales si pentru update. 5.2 Autentificare Urmatorul algoritm ar trebui folosit la identificarea mesajelor RIP. Daca routerul nu este configurat sa autentifice mesajele RIP-2, atunci mesajele RIP-1 si RIP-2 neautentificate for fi acceptate; mesajele autentificate RIP-2 for fi aruncate.Daca router-ul este configurat sa autentifice mesajele RIP-2, atunci mesajele RIP-1 si RIP-2 care vor trece de testul de autentificare for fi acceptate; mesajele RIP-2 neautentificare ori cele care nun au reusit autentificarea for fi aruncate.Pentru o mai buna securitate, mesajele RIP-1 ar trebui ignorate cand autentificarea este folosita (4.1); altfel, informatia de rutare de la mesajele autentificate va fi propagate intr-o maniera neautentificata de catre routerele RIP-1. Din moment ce autentificarea este marcata de un numar in hexa 0xFFFF numit Adress Family Identifier, un system RIP-1 va ignora acest numar din moment ce acesta face parte din adresa unui familii de IP diferite.Trebuie retinut faptul ca folosirea autentificarii nu va opri sistemele RIP-1 de la primirea mesajelor RIP-2.Daca este dorit acest lucru poate fi indeplinit folosind multicasting asa cu este descries in sectiunile 4.5 si 5.1. 5.3 Compatibilitate sporita. In ceea ce priveste compatibilitatea , se doreste un singur lucru si anume compatibilitatea totala. Primul motiv pentru care acest lucru nu este posibil este acela ca ar strica compatibilitatea in sens invers.O plaja mai mare in ceea ce priveste compatibilitatea evident va duce la dezorientarea versiunilor RIP vechi.In cel mai bun caz acestea vor ignora ruta asa cum vor ignora o metrica de 16.A existat de asemenea o sugestie de a face metrica un singur octet dar acest lucru ar fi stricat orice implementare care trata metrica fiind o entitate pe 4 octeti. 5.4 Link-uri adresabile Ca si in RIP-1, link-urile adresabile nu vor fi suportate de RIP-2

6. Interactiuni intre veriunea 1 si versiunea 1

Deoarece pechetele din versiunea 1 nu contin informatii despre subnet, semantica folosita de routere in retele ce contin atat versiunea 1 cat si versiunea 2 ar trebui limitata la versiunea 1. Altfel exista posibilitatea de a crea routere pentru retele care nu exista ori de a crea informatii de rutare excessive intr-un mediu de versiune 1. Unele implementari tind sa sumarizeze automat grupuri de rute adiacente in cadrul unor intrari simple, scopul fiind acela de a reduce numarul total al intrarilor.Acest process este numit auto-sumarizare.In special, atunci cand este folosita atat versiunea 1 cat si versiunea 2 in cadrul unei retele, o singura masca de subretea ar trebui folosita.Ca o completare, mecanismul de auto-sumarizare ar trebui dezactivat pentru astfel de retele, iar implementarea ar trebui sa vina cu soutii pentru dezactivarea mecanismului de auto-sumarizare.

7. Considerente de securitate
Protocolul de baza RIP nu este un protocol solid.Pentru a adduce in fata RIP-2, avand protocoale de rutare modern, a fost creat si integrat un mechanism extensibil de autentificare in cadrul protocolului.Acest mechanism este descries in 4.1 si 5.2.Securitatea este sporita de mecanismul descris in [3].

Anexa A
Acesta este un exemplu simplu de folosire a campului urmatorului hop intr-o intrare rip:

Sa presupunem ca IR1,IR2 si IR3 sunt toare routere interne care sunt sub o singura administrare (de exemplu un campus) care a decis folosirea RIP-2 , iar IGP.XR1,XR2 si XR3 pe de alta parte sunt administrate separate si folosesc alte protocoale de rutare .XR1,.XR2 si .XR3 schimba informatii de rutare intre ele astfel incat stiu ca cele mai bune rute catre retelele N1 si N2 sunt prin XR1, catre N3,N4 si N5 sunt prin XR2 si catre N6 si N7 sunt prin XR3.Prin setarea corecta a campului NEXT HOP(XR2 pentru N3/N4/N5, XR3 pentru

N6/N7), doar XR1 trebuie sa schimbe rute RIP-2 cu IR1/IR2/IR3 pentru ca rutarea sa aiba loc fata hopuri aditionale prin XR1.Fara Next Hop(de exemplu daca a fi fost folosit RIP-1)ar fi fost necesar ca XR2 si XR3 sa participle de asemenea in cadrul protocolului RIP-2 pentru a elimina hopurile extra. Referinte: [1] Hedrick, C., "Routing Information Protocol", STD 34, RFC 1058, Rutgers University, June 1988. [2] Malkin, G., and F. Baker, "RIP Version 2 MIB Extension", RFC 1389, January 1993. [3] Baker, F., and R. Atkinson, "RIP-II MD5 Authentication", RFC 2082, January 1997. [4] Bellman, R. E., "Dynamic Programming", Princeton University Press, Princeton, N.J., 1957. [5] Bertsekas, D. P., and Gallaher, R. G., "Data Networks", Prentice-Hall, Englewood Cliffs, N.J., 1987. [6] Braden, R., and Postel, J., "Requirements for Internet Gateways", STD 4, RFC 1009, June 1987. [7] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M., "Pup: An Internetwork Architecture", IEEE Transactions on Communications, April 1980. [8] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks", Princeton University Press, Princeton, N.J., 1962. [9] Xerox Corp., "Internet Transport Protocols", Xerox System Integration Standard XSIS 028112, December 1981. [10] Floyd, S., and V. Jacobson, "The synchronization of Periodic Routing Messages," ACM Sigcom '93 symposium, September 1993. [11] Baker, F., "Requirements for IP Version 4 Routers." RFC 1812, June 1995.