Arhitectură recursivă a internetului - Recursive Internetwork Architecture

Recursive Internetwork Architecture (RINA) este un nou computer arhitectură de rețea a propus ca alternativă la arhitectura prezent de masă suita de protocoale Internet . Principiile fundamentale ale RINA sunt că rețeaua computerizată este doar comunicare inter-proces sau IPC și că straturile ar trebui făcute pe baza domeniului / scării, cu un singur set recurent de protocoale, mai degrabă decât bazat pe funcții, cu protocoale specializate. Instanțele de protocol într-un singur strat interfață cu instanțele de protocol pe straturile superioare și inferioare prin intermediul noilor concepte și entități care reifică efectiv funcțiile de rețea specifice în prezent protocoalelor precum BGP , OSPF și ARP . În acest fel, RINA susține că acceptă caracteristici precum mobilitatea, multihoming-ul și calitatea serviciilor fără a fi nevoie de protocoale suplimentare specializate precum RTP și UDP , precum și de a permite administrarea simplificată a rețelei fără a fi nevoie de concepte precum sisteme autonome și NAT .

fundal

Principiile din spatele RINA au fost prezentate pentru prima dată de John Day în cartea sa din 2008 Patterns in Network Architecture: A return to Fundamentals . Această lucrare este un nou început, luând în considerare lecțiile învățate în cei 35 de ani de existență a TCP / IP , precum și lecțiile eșecului OSI și lecțiile altor tehnologii de rețea din ultimele decenii, cum ar fi CYCLADES , DECnet și Xerox Network Systems .

Punctul de plecare pentru o arhitectură de rețea radical nouă și diferită, cum ar fi RINA, este o încercare de a rezolva sau de a răspunde la următoarele probleme care nu par să aibă soluții practice sau fără compromisuri cu arhitecturile de rețea actuale, în special suita de protocol Internet și funcționalitatea sa stratificare așa cum este descris în Figura 1:

Image
Figura 1. Stratificarea funcțională a arhitecturii TCP / IP
  • Complexitatea transmisiei: separarea IP și TCP are ca rezultat ineficiența, descoperirea MTU efectuată pentru a preveni fragmentarea IP fiind cel mai clar simptom.
  • Performanță: TCP în sine poartă o cheltuială destul de mare cu strângerea de mână, ceea ce provoacă, de asemenea, vulnerabilități, cum ar fi inundațiile SYN . De asemenea, TCP se bazează pe căderea pachetelor pentru a se controla și a evita congestia, ceea ce înseamnă că controlul congestiei sale este pur reactiv, nu proactiv sau preventiv. Acest lucru interacționează prost cu buffere mari, ducând la bufferbloat .
  • Multihoming : adresa IP și numărul portului sunt prea scăzute pentru a identifica o aplicație în două rețele diferite. DNS nu rezolvă acest lucru, deoarece numele gazdei trebuie să se rezolve la o singură combinație de adresă IP și număr de port, făcându-le aliasuri în loc de identități. Nici LISP , deoarece i) folosește în continuare localizatorul, care este o adresă IP, pentru rutare, și ii) se bazează pe o distincție falsă, în sensul că toate entitățile dintr-un domeniu sunt localizate după identificatorii lor pentru început; în plus, introduce și probleme proprii de scalabilitate.
  • Mobilitate: adresa IP și numărul portului sunt, de asemenea, la un nivel prea scăzut pentru a identifica o aplicație pe măsură ce se deplasează între rețele, rezultând complicații pentru dispozitivele mobile, cum ar fi smartphone-urile. Deși este o soluție, IP-ul mobil în realitate mută problema în întregime la adresa Care-of și introduce un tunel IP, cu complexitate aferentă.
  • Management: aceeași natură de nivel scăzut a adresei IP încurajează adresele multiple sau chiar intervalele de adrese să fie alocate gazdelor unice, punând presiune pe alocare și accelerând epuizarea. NAT întârzie doar epuizarea adreselor și poate introduce și mai multe probleme. În același timp, stratificarea funcțională a arhitecturii suitei de protocol Internet lasă loc doar pentru două domenii, complicând subdiviziunea administrării internetului și necesitând noțiunea artificială de sisteme autonome. OSPF și IS-IS au relativ puține probleme, dar nu escaladează bine, forțând utilizarea BGP pentru rețele mai mari și rutare între domenii.
  • Securitate: natura spațiului de adrese IP are ca rezultat o securitate fragilă, deoarece nu există o politică configurabilă adevărată pentru adăugarea sau eliminarea adreselor IP, altele decât prevenirea fizică a atașamentului. TLS și IPSec oferă soluții, dar cu o complexitate însoțitoare. Firewall-urile și listele negre sunt vulnerabile la copleșitoare, ergo nu scalabile. „[...] experiența a arătat că este dificil să adăugați securitate la o suită de protocol, cu excepția cazului în care este încorporată în arhitectură de la început.”

Deși aceste probleme sunt mult mai vizibile astăzi, au existat precedente și cazuri aproape chiar de la începutul ARPANET , mediul în care a fost proiectată suita de protocol Internet:

1972: Multihoming nu este susținut de ARPANET

În 1972, Tinker Air Force Base dorea conexiuni la două IMP-uri diferite pentru redundanță. Proiectanții ARPANET și-au dat seama că nu pot suporta această caracteristică, deoarece adresele gazdei erau adresele numărului de port IMP la care era conectată gazda (împrumutând de la telefonie). Pentru ARPANET, două interfețe ale aceleiași gazde aveau adrese diferite; cu alte cuvinte, adresa era prea scăzută pentru a identifica o gazdă.

1978: TCP s-a despărțit de IP

Versiunile inițiale TCP au efectuat funcțiile de control al erorilor și fluxului (TCP curent) și funcțiile de releu și multiplexare (IP) în același protocol. În 1978 TCP a fost împărțit de la IP, chiar dacă cele două straturi aveau același domeniu. Până în 1987, comunitatea de rețea era foarte conștientă de problemele fragmentării IP, până la punctul de a o considera dăunătoare. Cu toate acestea, nu a fost înțeles ca un simptom că TCP și IP erau interdependente.

1981: Rezultatele fundamentale ale lui Watson au fost ignorate

Richard Watson în 1981 a furnizat o teorie fundamentală a transportului fiabil, prin care gestionarea conexiunilor necesită numai temporizatoare delimitate de un factor mic al Duratei maxime a pachetului (MPL). Pe baza acestei teorii, Watson și colab. a dezvoltat protocolul Delta-t care permite starea unei conexiuni să fie determinată pur și simplu prin limitarea a trei temporizatoare, fără strângere de mână. Pe de altă parte, TCP folosește atât strângerea de mână explicită, cât și o gestionare mai limitată a stării conexiunii, bazată pe temporizator.

1983: Stratul de Internetwork pierdut

Image
Figura 2. Arhitectura Internetului, văzută de INWG

La începutul anului 1972 a fost creat Grupul de lucru pentru rețele internaționale (INWG) pentru a reuni comunitatea națională de cercetare a rețelei. Una dintre sarcinile timpurii pe care le-a îndeplinit a fost votarea unui protocol internațional de transport în rețea, care a fost aprobat în 1976. În mod remarcabil, opțiunea selectată, precum și toți ceilalți candidați, aveau o arhitectură compusă din trei straturi cu un domeniu de aplicare în creștere: legătură de date (către gestiona diferite tipuri de medii fizice), rețea (pentru a gestiona diferite tipuri de rețele) și internet (pentru a gestiona o rețea de rețele), fiecare strat cu propriul spațiu de adrese. Când TCP / IP a fost introdus, acesta a rulat pe stratul de internetwork din partea superioară a NCP . Dar când NCP a fost închis, TCP / IP a preluat rolul de rețea și s-a pierdut stratul de internetwork. Acest lucru explică nevoia de sisteme autonome și NAT astăzi, de partiționare și reutilizare a gamelor spațiului de adrese IP pentru a facilita administrarea.

1983: Prima ocazie de a remedia adresarea ratată

Nevoia unei adrese de nivel mai înalt decât adresa IP a fost bine înțeleasă de la mijlocul anilor '70. Cu toate acestea, numele aplicațiilor nu au fost introduse, iar DNS a fost proiectat și implementat, continuând să folosească porturi bine cunoscute pentru a identifica aplicațiile. Apariția web și HTTP a creat o nevoie de nume de aplicații, ducând la adrese URL. Adresele URL, totuși, leagă fiecare instanță a aplicației de o interfață fizică a unui computer și de o conexiune de transport specifică, deoarece URL-ul conține numele DNS al unei interfețe IP și numărul portului TCP, răspândind problemele multihoming și de mobilitate la aplicații.

1986: prăbușirea congestiei ia Internetul prin surprindere

Deși problema controlului congestiei în rețelele de datagrame era cunoscută încă din anii 1970 și începutul anilor 80, prăbușirea congestiei în 1986 a surprins Internetul prin surprindere. Ce este mai rău, controlul de congestie adoptat - schema de evitare a congestiei Ethernet , cu câteva modificări - a fost introdus în TCP.

1988: Managementul rețelei face un pas înapoi

În 1988, IAB a recomandat utilizarea SNMP ca protocol inițial de gestionare a rețelei pentru Internet pentru trecerea ulterioară la abordarea orientată obiect a CMIP . SNMP a fost un pas înapoi în gestionarea rețelei, justificat ca o măsură temporară în timp ce abordările necesare mai sofisticate au fost implementate, dar tranziția nu s-a întâmplat niciodată.

1992: A doua ocazie de a remedia adresarea ratată

În 1992, IAB a elaborat o serie de recomandări pentru a rezolva problemele de scalare ale internetului bazat pe IPv4 : consumul de spațiu adresat și explozia informațiilor de rutare. Au fost propuse trei opțiuni: introducerea CIDR pentru a atenua problema; proiectați următoarea versiune de IP (IPv7) bazată pe CLNP ; sau continuați cercetarea privind denumirea, adresarea și rutare. CLNP a fost un protocol bazat pe OSI care se adresează nodurilor în loc de interfețe, rezolvând vechea problemă multihoming care datează din ARPANET și permite o agregare mai bună a informațiilor de rutare. CIDR a fost introdus, dar IETF nu a acceptat un IPv7 bazat pe CLNP. IAB și-a reconsiderat decizia și a început procesul IPng, culminând cu IPv6 . Una dintre regulile pentru IPng a fost să nu se schimbe semantica adresei IP, care continuă să denumească interfața, perpetuând problema multihoming-ului.

Prezentare generală

Image
Figura 3. Procese de aplicații distribuite (DAP) și componentele acestora

RINA este rezultatul unui efort de elaborare a principiilor generale în rețeaua de calculatoare care se aplică în toate situațiile. RINA este arhitectura specifică, implementarea, platforma de testare și, în cele din urmă, implementarea modelului cunoscut informal sub numele de model IPC, deși se ocupă și de concepte și rezultate care se aplică oricărei aplicații distribuite, nu doar rețelei.

Entitatea de bază a RINA este Procesul de aplicații distribuite sau DAP, care corespunde frecvent unui proces pe o gazdă. Două sau mai multe DAP-uri constituie o facilitate de aplicație distribuită sau DAF, așa cum este ilustrat în figura 3. Aceste DAP comunică utilizând protocolul comun de aplicații distribuite sau CDAP, schimbând date structurate sub formă de obiecte. Aceste obiecte sunt structurate într-o bază de informații despre resurse sau RIB, care le oferă o schemă de denumire și o organizare logică. CDAP oferă șase operațiuni de bază pe obiectele unui DAP la distanță: creați, ștergeți, citiți, scrieți, porniți și opriți.

Pentru a face schimb de informații, DAP-urile au nevoie de o facilitate care le oferă servicii de comunicații. Această facilitate este un alt DAF, numit Distribuit IPC Facility sau DIF, a cărui sarcină este de a furniza și gestiona servicii IPC într-un anumit domeniu. DAP-urile unui DIF se numesc Procese IPC sau IPCP-uri. Au aceeași structură DAP generică prezentată în Figura 3, plus câteva sarcini specifice pentru furnizarea și gestionarea IPC. Aceste sarcini, așa cum se arată în Figura 4, pot fi împărțite în trei categorii: transferul de date, controlul transferului de date și gestionarea stratului. Categoriile sunt ordonate prin creșterea complexității și frecvența descrescătoare, transferul de date fiind cel mai simplu și cel mai frecvent, gestionarea stratului fiind cel mai complex și cel mai puțin frecvent, iar controlul transferului de date între ele.

Image
Figura 4. Exemplu de rețele RINA și componente IPCP

DIF-urile, fiind DAF-uri, utilizează la rândul lor alte DIF-uri subiacente, mergând până la nivelul DIF al stratului fizic controlând firele și mufele. De aici vine recursivitatea RINA. Așa cum se arată în Figura 4, rețelele RINA sunt de obicei structurate în DIF-uri cu un domeniu de aplicare în creștere. Figura 5 prezintă un exemplu de modul în care Web-ul ar putea fi structurat cu RINA: cel mai înalt strat este cel mai apropiat de aplicații, corespunzător e-mailurilor sau site-urilor web; straturile cele mai joase agregează și multiplexează traficul straturilor superioare, corespunzător structurilor ISP . DIF-urile multi-furnizor (cum ar fi Internetul public sau altele) plutesc deasupra straturilor ISP. În acest model, se disting trei tipuri de sisteme: gazde, care conțin DAP-uri; routere interioare, interne unui strat; și routerele de frontieră, la marginile unui strat, unde pachetele merg în sus sau în jos un strat.

Image
Figura 5. Mai multe rețele RINA care acceptă mai multe lucrări de internet.

Un DIF permite unui DAP să aloce fluxuri unuia sau mai multor DAP-uri, furnizând doar numele DAP-urilor vizate și parametrii QoS doriți, cum ar fi limitele pierderii și latenței datelor, livrării ordonate sau în afara comenzii, fiabilitatea etc. mai departe. Este posibil ca DAP-urile să nu aibă încredere în DIF-ul pe care îl utilizează și, prin urmare, își pot proteja datele înainte de a le scrie în flux printr-un modul de protecție SDU , de exemplu prin criptarea acestora. Toate straturile RINA au aceeași structură și componente și oferă aceleași funcții; acestea diferă numai în ceea ce privește configurațiile sau politicile lor. Aceasta reflectă separarea mecanismului și a politicii în sistemele de operare.

Pe scurt, RINA păstrează conceptele de PDU și SDU, dar în loc de stratificare după funcție, stratifică după domeniu. În loc să considere că diferite scale au caracteristici și atribute diferite, consideră că toate comunicările au fundamental același comportament, doar cu parametri diferiți. Astfel, RINA este o încercare de conceptualizare și parametrizare a tuturor aspectelor comunicării, eliminând astfel necesitatea unor protocoale și concepte specifice și reutilizând cât mai multă teorie posibilă.

Denumire, adresare, rutare, mobilitate și multihoming

Așa cum s-a explicat mai sus, adresa IP este un identificator de nivel prea scăzut pe care să se bazeze eficient multihoming și mobilitate, precum și necesită ca tabelele de rutare să fie mai mari decât este necesar. Literatura RINA urmează teoria generală a lui Jerry Saltzer privind adresarea și denumirea. Potrivit Saltzer, trebuie identificate patru elemente: aplicații, noduri, puncte de atașare și căi. O aplicație poate rula într-unul sau mai multe noduri și ar trebui să poată trece de la un nod la altul fără a-și pierde identitatea în rețea. Un nod poate fi conectat la o pereche de puncte de atașament și ar trebui să se poată deplasa între ele fără a-și pierde identitatea în rețea. Un director mapează un nume de aplicație la o adresă de nod, iar rutele sunt secvențe de adrese de noduri și puncte de atașament. Aceste puncte sunt ilustrate în Figura 6.

Image
Figura 6. Ilustrația teoriei lui Saltzer privind denumirea și adresarea.

Saltzer și-a luat modelul din sistemele de operare, dar autorii RINA au concluzionat că nu ar putea fi aplicat în mod curat la internetworks, care poate avea mai multe căi între aceeași pereche de noduri (să nu mai vorbim de rețele întregi). Soluția lor este modelarea rutelor ca secvențe de noduri: la fiecare salt, nodul respectiv alege punctul de atașament cel mai potrivit pentru a redirecționa pachetul către următorul nod. Prin urmare, rutele RINA într-un proces în doi pași: mai întâi, se calculează ruta ca o secvență de adrese de nod și apoi, pentru fiecare salt, este selectat un punct de atașare adecvat. Aceștia sunt pașii pentru a genera tabelul de redirecționare: redirecționarea se efectuează în continuare cu o singură căutare. Mai mult, ultimul pas poate fi realizat mai frecvent pentru a exploata multihoming-ul pentru echilibrarea încărcăturii.

Cu această structură de denumire, mobilitatea și multihomingul sunt acceptate în mod inerent dacă numele au proprietăți alese cu atenție:

  1. numele aplicațiilor sunt independente de locație pentru a permite unei aplicații să se deplaseze;
  2. adresele nodurilor sunt dependente de locație, dar independente de rută; și
  3. punctele de atașare sunt, în mod natural, dependente de traseu.

Aplicarea acestei scheme de denumire la RINA cu straturile sale recursive permite concluzia că maparea numelor aplicațiilor la adresele nodurilor este analogă cu maparea adreselor nodurilor la punctele de atașament. Pur și simplu, la orice strat, nodurile din stratul de mai sus pot fi văzute ca aplicații, în timp ce nodurile din stratul de mai jos pot fi văzute ca puncte de atașament.

Proiectarea protocolului

De asemenea, suita de protocol Internet dictează, în general, ca protocoalele să fie proiectate izolat, indiferent dacă aspectele au fost duplicate în alte protocoale și, prin urmare, dacă acestea pot fi transformate într-o politică. RINA încearcă să evite acest lucru prin aplicarea separării mecanismului și politicii în sistemele de operare la proiectarea protocolului. Fiecare DIF utilizează politici diferite pentru a furniza diferite clase de calitate a serviciului și pentru a se adapta la caracteristicile fișierelor media fizice, dacă DIF este de nivel scăzut, sau aplicații, dacă DIF este de nivel înalt.

RINA folosește teoria protocolului Delta-T dezvoltată de Richard Watson în 1981. Cercetările lui Watson sugerează că sunt suficiente condiții pentru un transfer fiabil pentru a lega trei temporizatoare. Delta-T este un exemplu al modului în care ar trebui să funcționeze: nu are o conexiune configurată sau demolată. Aceeași cercetare notează, de asemenea, că TCP folosește deja aceste cronometre în funcționarea sa, făcând Delta-T comparativ mai simplu. Cercetările lui Watson sugerează, de asemenea, că sincronizarea și alocarea porturilor ar trebui să fie funcții distincte, alocarea porturilor făcând parte din gestionarea stratului, iar sincronizarea făcând parte din transferul de date.

Securitate

Image
Figura 7. Organizarea funcțiilor de securitate în RINA.

Pentru a adapta securitatea, RINA solicită fiecărui DIF / DAF să specifice o politică de securitate, ale cărei funcții sunt prezentate în Figura 7. Aceasta permite securizarea nu doar a aplicațiilor, ci a coloanelor vertebrale și schimbarea țesăturilor în sine. O rețea publică este pur și simplu un caz special în care politica de securitate nu face nimic. Acest lucru poate introduce cheltuieli generale pentru rețelele mai mici, dar se adaptează mai bine cu rețelele mai mari, deoarece straturile nu trebuie să își coordoneze mecanismele de securitate: internetul actual este estimat ca necesitând de aproximativ 5 ori mai multe entități de securitate distincte decât RINA. Printre altele, politica de securitate poate specifica și un mecanism de autentificare; acest lucru depășește firewall-urile și listele negre, deoarece un DAP sau IPCP care nu se poate alătura unui DAF sau DIF nu poate transmite sau primi. De asemenea, DIF-urile nu își expun adresele IPCP la straturi superioare, împiedicând o clasă largă de atacuri om-în-mijloc.

Proiectarea protocolului Delta-T în sine, cu accentul său pe simplitate, este, de asemenea, un factor. De exemplu, din moment ce protocolul nu are strângere de mână, nu are mesaje de control corespunzătoare care să poată fi falsificate sau să poată fi utilizate în mod abuziv, ca în cazul unei inundații SYN. Mecanismul de sincronizare face, de asemenea, comportamentul aberant mai corelat cu încercările de intruziune, făcând atacurile mult mai ușor de detectat.

Proiecte de cercetare

De la publicarea cărții PNA în 2008 până în 2014, s-a făcut o mulțime de lucrări de cercetare și dezvoltare RINA. Un grup informal cunoscut sub numele de Societatea Pouzin , numit după Louis Pouzin , coordonează mai multe eforturi internaționale.

Echipa de cercetare BU

Echipa de cercetare RINA de la Universitatea din Boston este condusă de profesorii Abraham Matta, John Day și Lou Chitkushev și a primit o serie de subvenții de la National Science Foundation și CE pentru a continua investigarea fundamentelor RINA, dezvoltarea unui prototip open source implementarea prin UDP / IP pentru Java și experimentarea cu acesta deasupra infrastructurii GENI. BU este, de asemenea, membru al Societății Pouzin și un contribuitor activ la proiectele FP7 IRATI și PRISTINE. În plus, BU a încorporat conceptele și teoria RINA în cursurile lor de rețea de calculatoare.

FP7 IRATI

IRATI este un proiect finanțat prin FP7 cu 5 parteneri: i2CAT, Nextworks, iMinds, Interoute și Universitatea din Boston. A produs o implementare open source RINA pentru sistemul de operare Linux pe Ethernet .

FP7 PRISTINE

PRISTINE este un proiect finanțat de FP7 cu 15 parteneri: WIT-TSSG, i2CAT, Nextworks, Telefónica I + D, Thales, Nexedi, B-ISDN, Atos, Universitatea din Oslo, Juniper Networks, Universitatea Brno, IMT-TSP, CREATE- NET, iMinds și UPC. Scopul său principal este de a explora aspectele de programabilitate ale RINA pentru a implementa politici inovatoare pentru controlul congestiei, alocarea resurselor, rutare, securitate și gestionarea rețelei.

GÉANT3 + Câștigător Open Call IRINA

IRINA a fost finanțat prin apelul GÉANT3 + și este un proiect cu patru parteneri: iMinds, WIT-TSSG, i2CAT și Nextworks. Scopul principal al IRINA este de a studia utilizarea Arhitecturii Recursive InterNetwork (RINA) ca bază a următoarelor generații de arhitecturi de rețea NREN și GÉANT. IRINA se bazează pe prototipul IRATI și va compara RINA cu stadiul actual al tehnologiei de rețea și cu arhitectura relevantă de ardezie curată în curs de cercetare; efectuați un studiu de caz de utilizare a modului în care RINA ar putea fi mai bine utilizată în scenariile NREN; și să prezinte un studiu de laborator al studiului.

Vezi si

Referințe

linkuri externe