RINA

Wikipediasta
Siirry navigaatioon Siirry hakuun
Tulostettavaa versiota ei enää tueta ja siinä voi olla renderöintivirheitä. Päivitä selaimesi kirjanmerkit ja käytä selaimen tavallista tulostustoimintoa sen sijaan.

RINA (lyhenne sanoista Recursive InterNetwork Architecture eli rekursiivinen internet-arkkitehtuuri) on kehitteillä oleva uusi tietoverkkojen arkkitehtuuri. Se on radikaalisti erilainen kuin Internetin tiedonsiirrossa nykyisin käytettävä TCP/IP-arkkitehtuuri. RINA pohjautuu ajatusmalliin, että kaikki tiedonsiirto tietoverkoissa on pohjimmiltaan ohjelmaprosessien välistä kommunikaatiota (Inter-Process Communication, IPC).

Perinteisestä, eri tehtäviin erikoistuneisiin kerroksiin (siirtokerros, verkkokerros, kuljetuskerros jne.) pohjautuvasta verkkomallista poiketen RINA lähtee ajatuksesta, että tarvitaan vain yksi toiminnallinen kerros, joka sisältää kaikki verkossa tarvittavat protokollat. Tätä yhtä "rakennuspalikkaa", josta käytetään nimitystä DIF (Distributed IPC Facility), päällekkäin pinoamalla rakennetaan verkkoon niin monta kerrosta, kuin ylläpidollisesti katsotaan tarpeelliseksi. Kaikki kerrokset sisältävät periaatteessa saman toiminnallisuuden, vain niiden näkyvyysalue (scope) on erilainen. Alimpana oleva kerros voi hoitaa esimerkiksi kahden reitittimen välistä fyysistä linkkiä, kun taas ylin kerros voi olla vaikka maailmanlaajuinen ("Public Internet DIF"). Kutakin kerrosta voidaan säätää erikseen erilaisten käytäntöjen (policy) avulla. Käytännöillä säädellään esimerkiksi käytettävää tiedon salausta, laatuasetuksia (QoS) ja kerroksen käyttöön vaadittavaa autentikointia.

Historia ja motivaatio

RINA-arkkitehtuurin idean kehitti alun perin Bostonin yliopistolla työskentelevä John Day[1], joka on toiminut tietoliikenneprotokollien kehityksessä 1970-luvulta lähtien ja oli mukana mm. ARPANETin ja OSI-viitemallin kehitystyössä[2]. Dayn mukaan tarve täysin uudelle verkkoarkkitehtuurille johtuu TCP/IP-arkkitehtuurin perustavanlaatuisista vioista ja puutteista, joiden korjaaminen lisäominaisuuksien ja uusien protokollien avulla on vaikeaa tai jopa mahdotonta. Näitä ovat esimerkiksi:

  • Sovellusohjelmilla ei ole mahdollisuutta kertoa verkolle toivomaansa palvelun laatutasoa, ne voivat ainoastaan valita luotettavan (TCP) tai epäluotettavan (UDP) siirtotien välillä. Verkon kannalta kaikki ohjelmat ovat tiedonsiirtotarpeidensa osalta samanlaisia, kun oikeasti esim. VoIP-puheluyhteydellä on tiedonsiirrolle hyvin erilaiset laatuvaatimukset kuin vaikkapa www-sivun siirrolla HTTP-protokollan avulla[3].
  • Verkolla ei ole mitään tietoa kommunikoivien sovellusten nimistä, vaan se käyttää verkkoliitynnän osoitteen (IP-osoite) ja kuljetuskerroksen porttinumeron muodostamaa paria tunnistamaan tiedon kulkutien päissä olevat sovellukset. Verkko käyttää siis tietoa missä tunnistamaan sen mikä kommunikoi. Joka kerran, kun sovellus vaihtaa liityntäpistettään verkkoon, se näyttää verkon kannalta eri sovellukselta. Tämä vaikeuttaa suuresti useamman verkkoliitynnän käyttöä sekä laitteen liikkuvuutta verkossa.[3]
  • Internet-verkko ei ole luonteeltaan hierarkkinen useiden verkkojen muodostama kokonaisuus, vaan yksi maailmanlaajuinen "litteä" verkko jossa eri toimijoiden aliverkot on liitetty yhteen peräkkäin ilman hierarkiaa, ja jossa on yksi yhteinen osoiteavaruus[4]. Tämän seurauksena verkon reititys tapahtuu monimutkaisella järjestelmällä, jossa sekä toimijan oman verkon sisäinen reititys, että sen ulkopuolelle menevän liikenteen reititys tapahtuu samassa kerroksessa, tai jossa joudutaan käyttämään verkko-osoitteen muunnosta (NAT) mahdollistamaan muusta verkosta riippumattoman osoiteavaruuden käyttö.

Alun perin 1970-luvulla kehitettyä TCP/IP-arkkitehtuuria on kuluneiden vuosikymmenten aikana paranneltu ja korjailtu eri tavoin, kehittämällä uusia protokollia ja uudistamalla vanhoja sen verran kuin on ollut mahdollista. Se käsittää nykyään useita kymmeniä protokollia (vaikka sovelluskerroksen protokollia ei lasketa mukaan), joista kaikki eivät asetu kunnolla mihinkään tiettyyn TCP/IP-mallin kerrokseen (kuten esim. ARP tai MPLS). Täysin "puhtaalta pöydältä" kehitetty RINA taas lupaa suoriutua kaikista nykyisen TCP/IP-arkkitehtuurin tehtävistä, sekä myös tulevaisuuden tarpeista, käyttäen ainoastaan kahta protokollaa.

Käsitteitä

Seuraavassa esitellään joitakin RINA-arkkitehtuurin keskeisiä käsitteitä.[5]

  • Distributed Application Process (DAP). Hajautettu ohjelmaprosessi, prosessi joka kommunikoi toisen vastaavan prosessin kanssa IPCn avulla.
  • Distributed Application Facility (DAF). Kahden tai useamman ohjelmaprosessin (DAP) muodostama kokonaisuus, joka kommunikoi IPCn avulla ja ylläpitää jaettua tilakuvaa. Prosessit voivat sijaita samassa laitteessa, tai useammassa RINA-verkkoon kytketyssä laitteessa. DAFeiksi lasketaan niin RINAn avulla kommunikoivat käyttäjäsovellukset, kuin myös pelkästään IPC-palveluja tarjoamaan erikoistuneet DIFit.
  • Distributed IPC Facility (DIF). Pelkästään IPC-palvelujen tarjoamiseen erikoistunut DAF, koostuu kahdesta tai useammasta IPC-prosessista (IPCP). Sovellukset käyttävät DIFin palveluja kommunikoidakseen toisen sovellusprosessin kanssa. DIF on RINA-arkkitehtuurin kerros, joita päällekkäin pinoamalla verkon rakenne muodostetaan.
  • IPC Process (IPCP). Ohjelmaprosessi joka hoitaa IPC-kommunikaatiota. IPCP on jäsenenä yhdessä ja vain yhdessä DIFissä.
  • Error and Flow Control Protocol (EFCP). Protokolla jota käytetään tiedonsiirtoon DIFin jäseninä toimivien IPC-prosessien välillä. EFCP huolehtii siirrettävän tiedon luotettavuudesta, oikeasta järjestyksestä ja vuonvalvonnasta tarpeen mukaan. Se on jaettu kahteen aliprotokollaan (DTP ja DTCP).
  • Data Transfer Protocol (DTP). EFCPn varsinainen tiedonsiirtoprotokolla, joka huolehtii tiedon paketoimisesta ja välittämisestä oikealle vastaanottajalle. Yksinään käytettynä tarjoaa vain epäluotettavan siirtotien, vastaten toiminnallisuudeltaan suunnilleen IP- ja UDP-protokollien yhdistelmää.
  • Data Transfer Control Protocol (DTCP). EFCPn valinnainen osa, jota voidaan käyttää vain yhdessä DTP-protokollan kanssa. Huolehtii tiedonsiirron takaisinkytkentämekanismeista, kuten uudelleenlähetyksestä ja vuonvalvonnasta. DTP- ja DTCP-protokollien käyttäminen yhdessä tarjoaa luotettavan siirtotien, vastaten suunnilleen TCP-protokollan tarjoamaa toiminnallisuutta.
  • Common Distributed Application Protocol (CDAP). Protokolla, joka tarjoaa oliopohjaisen IPC-kommunikaation sitä käyttävien sovellusten välille, vähän samaan tapaan kuin vaikkapa CORBA tai DCOM. Käyttää EFCP-protokollaa tiedon siirtämiseen. RINA-verkon hallinta tapahtuu CDAP-protokollan avulla, hallintaan käytettävät prosessit siirtävät sen avulla erilaista verkon hallinnassa tarvittavaa tietoa (esim. reititystauluja) toistensa välillä. Myös käyttäjäsovellukset voivat kommunikoida keskenään CDAPin avulla, jolloin niiden ei tarvitse itse huolehtia tiedon sarjallistamisesta tai I/O-operaatioista. CDAPin käyttö ei kuitenkaan ole pakollista, vaan sovellukset voivat valintansa mukaan käyttää myös suoraan EFCP-protokollaa, mikä mahdollistaa kaikkien olemassa olevien sovellusprotokollien (HTTP, FTP, SMTP jne.) käyttämisen myös RINA-arkkitehtuurissa.[3]
  • Connection. Kahden EFCP-protokollalla kommunikoivan tehtävän (EFCP-instanssin) välinen yhteys. Yhteys on aina kahden saman DIFin jäsenen välinen jaettu tilakuva. Eri DIFien (kerrosten) välillä tietoa ei välitetä protokollien avulla, vaan ohjelmallisten rajapintojen avulla yhden laitteen sisällä. Yhteyden avaaminen ja sulkeminen ei perustu kättelyihin (vrt. TCP-protokollan kolmoiskättelyt SYN- ja FIN-lippuineen) vaan ajastimiin. Yhteys avataan kun liikenne alkaa kulkea ja suljetaan (eli tilakuvan ylläpitämiseen varatut resurssit vapautetaan) taas määrätyn ajan kuluttua liikenteen loppumisesta. Yhteyden olemassaolo tai puuttuminen ei näy sovellukselle.
  • Flow. Palvelu jonka EFCP-protokollan instanssi tarjoaa sitä käyttävälle sovellukselle, "tietovirta". Tietovirran tarjoavan EFCP-instanssin ja sitä käyttävän sovelluksen välistä sidosta kutsutaan portiksi. Vastaa periaatteessa TCP- tai UDP-protokollan tarjoamaa palvelua sovellukselle. Tietovirta aloitetaan ja päätetään sovelluksen niin pyytäessä, ja sen olemassaolo on erotettu itse yhteyden (ks. Connection edellä) olemassaolosta.

Toimintaperiaate

kuva 1: Hajautettu ohjelmapalvelu (DAF)

RINA pohjautuu periaatteeseen, että kaikki tietokoneiden tiedonsiirto on pohjimmiltaan aina ohjelmaprosessien välistä kommunikointia. Tämän IPC-mallin perusrakenne on hajautettu ohjelmapalvelu (Distributed Application Facility eli DAF), jonka rakenne esitetään kuvassa 1. Se koostuu kahdesta tai useammasta ohjelmaprosessista (Distributed Application Process, DAP) jotka yhteistyössä suorittavat jotakin tehtävää. Nämä prosessit kommunikoivat käyttäen sovellusprotokollaa (Common Distributed Application Protocol, CDAP), joka mahdollistaa kahden prosessin vaihtaa keskenään rakenteellista tietoa olioiden muodossa. CDAP tarjoaa prosesseille kuusi eri toimintoa etäprosessin olioiden käsittelemiseen (create, delete, read, write, start ja stop)[3].

Voidakseen kommunikoida, DAF tarvitsee alleen kommunikaatiopalvelua tarjoavan ohjelmiston. Tämän palvelun tarjoaa toinen DAF, joka on erikoistunut IPC-palvelujen tarjoamiseen; siksi tätä erikoistunutta DAFiä kutsutaan nimellä DIF (Distributed IPC Facility, hajautettu IPC-palvelu). DIFin avulla DAP voi avata tietovirran (flow) toiseen DAPiin.

kuva 2: Esimerkki RINA-verkon kerrosrakenteesta

DIF voi kommunikoida suoraan laitteiston kautta, tai se voi käyttää siirtotienä toista, alemman tason DIFiä. Koska jokainen DIF sisältää saman toiminnallisuuden, ei arkkitehtuuri sanele sitä, montako kerrosta verkossa on. Kerrosten määrän valitsee verkon rakentaja, joka voi pinota päällekkäin niin monta kerrosta kuin tarvitsee. Tästä saman kerroksen käyttämisestä useampaan kertaan johtuu termi "rekursiivinen arkkitehtuuri". Alimman kerroksen DIFit kommunikoivat suoraan fyysisen laitteiston kautta, kaikki niiden yläpuolella olevat kerrokset käyttävät siirtotienä allaan olevia DIFejä. Yksi mahdollinen esimerkki RINA-verkon kerrosrakenteesta esitetään kuvassa 2, jossa näkyvät myös IPC-prosessin eri toiminnallisuudet.

Koska jokainen kerros liittyy ylä- ja alapuolellaan oleviin kerroksiin identtisten rajapintojen kautta, ei minkään kerroksen tarvitse olla tietoinen verkon koko rakenteesta. Yksi kerros näkee vain suoraan ylä- ja alapuolellaan olevat kerrokset. RINA-arkkitehtuurissa käytetään kolmenlaisia osoitteita: sovellusnimiä (Application Name), solmuosoitteita (Node Address) ja liityntäosoitteita (Point of Attachment Address)[6]. Kukin kerros osoittaa yläpuolellaan olevaa kerrosta sovellusnimellä, toisia saman kerroksen jäseniä solmuosoitteella ja alapuolella olevaa kerrosta liityntäosoitteella. Tietylle kerrokselle sen yläpuolella oleva kerros on siis aina sovellus, riippumatta siitä onko kyseessä käyttäjäsovellus vai toinen DIF. Alapuolella oleva kerros taas on aina liityntäpiste verkkoon, oli kyseessä sitten fyysinen liityntä tai alemman kerroksen DIF.

Käyttäjäsovelluksen pyytäessä tietovirtaa toiseen sovellukseen, kohde valitaan käyttämällä halutun kohdeprosessin sovellusnimeä, ei osoitetta kuten TCP/IP-verkossa. Osoitteet ja portit ovat DIFin sisäistä tietoa, jotka eivät näy sovellusohjelmalle. Uuden IPC-prosessin liittyessä DIFin jäseneksi, sille allokoidaan yleensä dynaaminen osoite. Myös staattisten osoitteiden käyttäminen on mahdollista, mutta se ei ole välttämätöntä edes palvelinkoneiden kohdalla. Portit puolestaan allokoidaan dynaamisesti tietovirran alustuksen yhteydessä. RINA-arkkitehtuurissa ei siis ole globaaleja osoitteita, eikä niin kutsuttuja "hyvin tunnettuja portteja". Ainoa tarvittava tieto yhteyden saamiseen on sovellusnimi, eikä senkään tarvitse olla globaali. Sovellusnimi voidaan julkaista rajoitetulla näkyvyysalueella, jos sovellus ei ole tarkoitettu kaikkien verkon käyttäjien käyttöön.

Voidakseen kommunikoida keskenään, sovellusten on oltava liittyneenä samaan DIFiin. Tietovirran avaavan sovelluksen on joko liityttävä johonkin DIFiin jossa kohdesovellus on rekisteröityneenä, tai muodostettava uusi DIF johon kohdesovellus myös suostuu liittymään.

Hyötyjä

RINA lupaa monia etuja verrattuna TCP/IP-arkkitehtuuriin. Näitä ovat muun muassa:

  • Reititys tapahtuu kussakin kerroksessa erikseen, mikä tarkoittaa merkittävästi pienempiä reititystauluja "litteään" verkkoarkkitehtuuriin verrattuna.[7] Yksi Internetin suurimmista ongelmista nykyään on runkoverkkojen reitittimien reititystaulujen räjähdysmäinen kasvu etenkin useisiin aliverkkoihin liittyvien laitteiden takia.
  • Verkon tukkeutumisen estoon RINA tarjoaa tehokkaamman lähestymistavan kuin TCP/IP. Internetin tukkeutumisen esto nojaa nykyään ns. end-to-end -periaatteeseen, eli yhteyden päissä olevat laitteet huolehtivat tukkeutumisen estosta. Tukkeutumisen esto on kuitenkin sitä tehokkaampaa, mitä nopeammin toiselle osapuolella saadaan tieto liikenteen tukkeutumisesta. Hoitamalla tukkeumisen eston alemman kerroksen DIFeissä, RINA sekä tehostaa tukkeutumisen estoa, että rajaa tukkeutumisen vaikutuksen pienemmälle osalle verkkoa.[7]
  • Rekursiivinen arkkitehtuuri ei aseta mitään rajoituksia verkon koolle.[7] Fyysisiä rajoitteita voi tulla vastaan, mutta arkkitehtuuri itsessään ei rajoita resurssien (esim. osoitteiden) määrää.
  • Koska paketit reititetään solmuosoitteiden perusteella, ei liityntäosoitteiden kuten IP-protokollassa, verkko tukee luontaisesti useamman verkkoliitynnän käyttöä. Pakettien reitittämiseen toista reittiä pitkin alkuperäisen reitin katketessa ei tarvita erillisratkaisuja, kuten IP-verkoissa.[7]
  • Verkko tukee luontaisesti myös mobiilia käyttöä, eli laitteen siirtymistä aliverkosta toiseen kommunikaation ollessa käynnissä. Itse asiassa mobiilisuus on oikeastaan sama asia kuin usean liitynnän käyttö (multihoming), ainoastaan reitti muuttuu nopeammin kuin satunnaisissa verkkokatkoksissa. TCP/IP-verkoissa käytettyä monimutkaista tunnelointia koti- ja vierasagentteineen ei tarvita.[7]
  • Koska verkossa ei ole globaalia osoitteistoa eikä hyvin tunnettuja portteja, porttiskannaus on paljon vaikeampaa kuin TCP/IP-verkoissa.[8] Yhteys kohdelaitteeseen on mahdollinen vain sovellusnimellä, ja silloinkin vain jos yhteydenottaja on saman DIFin jäsen; jäsenyyttä taas voidaan rajata autentikointivaatimuksen avulla.
  • Koska DIF voidaan suojata autentikoinnilla ja liikenteen salauksella, RINA tekee tarpeettomaksi erilliset tietoturvaratkaisut kuten VPN-yhteydet ja palomuurit.[9]
  • Palvelut voidaan julkaista eri verkoissa (DIFeissä), kaikkien sovellusten ei tarvitse olla kaikkien käytettävissä[10]. Esimerkiksi rekisteröitymistä vaativat palvelut voidaan julkaista DIFissä, johon on pääsy vain tunnistautumisen kautta, rekisteröitymisen tapahtuessa globaalin verkon ("Public Internet DIF") kautta. Näin palvelut ovat paremmin suojassa murtautumisyrityksiä vastaan, kun niihin pääsevät verkon kautta käsiksi vain rekisteröityneet käyttäjät.
  • RINA tukee palvelun laatuasetuksia, joita voivat olla esim. kaistanleveys, latenssi, hävikkiprosentti ja latenssin vaihtelu (jitter)[3]. Palveluille, joilla on erilaiset vaatimukset tiedonsiirron laadulle, voidaan tarjota tiedonsiirtopalveluita niille parhaiten sopivilla laatuasetuksilla omissa DIFeissään. Samassakin DIFissä julkaistut palvelut voivat käyttää siirtotienä eri DIFejä, kunkin palvelun liikenteen reitittyessä sille parhaiten sopivien alemman kerroksen DIFen kautta.
  • Arkkitehtuuri on verrattain yksinkertainen, koostuen vain kahdesta protokollasta (EFCP ja CDAP) sekä pienestä joukosta näitä tukevia erilaisia mekanismeja. Yksinkertaisuus tuo mukanaan tehokkuutta ja tietoturvaa.[9]

Käyttöönotto

Vaikka RINA on hyvin erilainen arkkitehtuuri nykyisin käytettyyn TCP/IP-arkkitehtuuriin verrattuna, sen käyttöönotto voidaan suorittaa pala palalta vähän kerrallaan. Niin sanotut shim-DIFit[11] tarjoavat mahdollisuuden olemassa olevien verkkotekniikoiden (esim. Ethernet, TCP, UDP, WiFi) käyttöön siirtotienä EFCP-liikenteelle. Näiden avulla RINA-verkkoja on mahdollista rakentaa jo ennen kuin RINA-tekniikkaa tukevia laitteita (kytkimiä, reitittimiä yms.) on saatavilla. Toisaalta myös muita verkkoprotokollia on mahdollista tunneloida RINA-verkon läpi. Lopullisessa muodossaan RINA voisi korvata kaikki muut verkkoprotokollat, eli koko protokollapinon linkkikerroksesta aina sovellusprotokolliin asti.

Kehitystyö

RINA-arkkitehtuurin kehitys voidaan katsoa alkaneeksi vuonna 2008, jolloin julkaistussa kirjassaan Patterns in Network Architecture: A return to Fundamentals John Day esitti RINAn perusajatukset. Nykyään RINAn kehitystyötä koordinoi epävirallinen ryhmä nimeltä Pouzin Society (PSOC), joka on nimetty datagrammin keksijän ja CYCLADES-verkon kehittäjän Louis Pouzinin mukaan.

Bostonin yliopiston RINA-kehitystiimi

Bostonin yliopistolla[12] RINA-arkkitehtuurin kehitystä johtavat John Dayn lisäksi professorit Ibrahim Matta ja Lou Chitkushev. Tiimi on saanut rahoitusta tutkimukseen Yhdysvaltain kansalliselta tiedesäätiöltä.

FP7 IRATI ja PRISTINE

Euroopan komission Tutkimuksen puiteohjelma FP7 on rahoittanut IRATI[13]-nimeä kantavaa projektia, jonka päätarkoitus oli kehittää avoimen lähdekoodin RINA-toteutus Ethernet-alustalle Linux-ympäristöön. Projektissa partnereina toimivat i2CAT Foundation, Nextworks, iMinds, Interoute ja Bostonin yliopisto.

IRATI-projektin jatko-ohjelmassa nimeltä PRISTINE[14] on jatkokehitetty IRATI-projektin tuottamaa RINA-toteutusta. Tarkoituksena on ollut kehittää käytäntöjä mm. verkon tukkeutumisen estoon, resurssien varaukseen, reititykseen, tietoturvaan ja verkonhallintaan. Partnereina projektissa ovat toimineet WIT-TSSG, i2CAT, Telefónica I+D, Ericsson, Nextworks, Thales, Nexedi, BISDN, Atos, Juniper Networks, Oslon ja Brnon yliopistot, Telecom SudParis, CREATE-NET, iMinds sekä PNSol.

GÉANT3+ IRINA

Yleiseurooppalainen kansallisten tutkimusverkkojen kattojärjestö GÉANT rahoitti IRINA-projektia[15], jossa tutkittiin RINA-arkkitehtuurin soveltuvuutta tutkimus- ja opetusverkkojen käyttöön. Projektin loppuraportin mukaan ainakin virtuaaliverkoissa RINA tarjoaa selkeästi paremman suorituskyvyn kuin TCP/IP.[16]

UiO OCARINA

Oslon yliopiston OCARINA[17]-projektin tarkoituksena on optimoida RINA-arkkitehtuuria kehittämällä siihen uusia käytäntöjä tukkeutumisen estoon ja reititykseen. Reititystä on tarkoitus kehittää dynaamisempaan suuntaan, kun nykyisin Internetin reititys on hyvin staattista.

H2020 ARCFIRE

Euroopan komission Horisontti 2020-ohjelman rahoittamassa ARCFIRE-projektissa[18] RINA-arkkitehtuuria testataan suuremmassa mittakaavassa, ja optimoidaan IRATI-projektin RINA-toteutusta niin, että verkko-operaattorit voivat alkaa testata sitä omissa verkoissaan. Projektissa tutkitaan myös mm. miten hyvin RINA-verkko kestää erilaisia palvelunestohyökkäyksiä nykyisin käytössä oleviin tekniikoihin verrattuna.

Toteutukset

RINA-arkkitehtuurin toteutuksia on olemassa useita erilaisille alustoille. Näitä ovat ainakin:

  • IRATI, Euroopan komission projektissa kehitetty toteutus Linux-ympäristöön
  • protoRINA, Bostonin yliopiston kehittämä prototyyppitoteutus Java-ympäristöön
  • rlite, RINA-toteutus Linux-ympäristöön jossa siirtoteinä Ethernet, TCP ja UDP
  • RinaSIM, OMNeT++ simulaatioalustalle rakennettu RINA-simulaattori

Linkit yllä olevien toteutuksien lähdekoodeihin löytyvät Pouzin Societyn www-sivuilta.

Lähteet

  1. ↑ Day, John D., 1947-: Patterns in network architecture : a return to fundamentals. Upper Saddle River, N.J.: Pearson Education, 2008. 174134020 Virhe: Virheellinen ISBN-tunniste Teoksen verkkoversio.
  2. ↑ John Day Curriculum Vitae www.historyofcomputercommunications.info. Arkistoitu 8.5.2018. Viitattu 4.5.2018.
  3. ↑ a b c d e Eleni Trouva et al.: Is the Internet an Unfinished Demo? 6.10.2010. Pouzin Society. Arkistoitu 14.2.2019. Viitattu 4.5.2018.
  4. ↑ John Day: How in the Heck do you lose a layer!? 2014. Pouzin Society. Arkistoitu 28.8.2019. Viitattu 4.5.2018.
  5. ↑ RINA Education » Terminology Pouzin Society. Viitattu 4.5.2018.
  6. ↑ John Day: We Got Trouble! 2013. Pouzin Society. Arkistoitu 14.10.2016. Viitattu 4.5.2018.
  7. ↑ a b c d e John Day et al.: [http://csr.bu.edu/rina/papers/Bounding-the-router-table-size-in-ISPs-using-RINA.pdf Bounding the router table size in an ISP network using RINA] csr.bu.edu. 2011. Viitattu 6.5.2018.
  8. ↑ [http://www.etsi.org/deliver/etsi_gr/NGP/001_099/003/01.01.01_60/gr_NGP003v010101p.pdf ETSI Group Report NGP 003: Next Generation Protocol; Packet Routing Technologies] 3/2017. European Telecommunications Standards Institute. Viitattu 6.5.2018.
  9. ↑ a b John Nolan: The Last Waltz and Moving Beyond TCP/IP The Journal of the Institute of Telecommunications Professionals. 2011. Arkistoitu 14.2.2019. Viitattu 6.5.2018.
  10. ↑ John Day: Welcome to the RINAissance! - An Introduction to the RINA Architecture (Part II) 2013. Pouzin Society. Arkistoitu 14.10.2016. Viitattu 6.5.2018.
  11. ↑ The concept of the shim DIF over Ethernet IRATI-projektin www-sivusto. 2014. Arkistoitu 8.5.2018. Viitattu 8.5.2018.
  12. ↑ Bostonin yliopiston RINA-aiheinen sivusto csr.bu.edu.
  13. ↑ IRATI-projektin www-sivusto irati.eu. Arkistoitu 8.5.2018.
  14. ↑ PRISTINE-projektin www-sivusto ict-pristine.eu. Arkistoitu 23.3.2018.
  15. ↑ IRINA-projekti GÉANTin www-sivustolla geant3plus.archive.geant.net. Arkistoitu 9.5.2018.
  16. ↑ IRINA-projektin loppuraportti geant3plus.archive.geant.net. Arkistoitu 9.5.2018.
  17. ↑ OCARINA Oslon yliopiston sivuilla mn.uio.no.
  18. ↑ ARCFIRE-projektin www-sivusto ict-arcfire.eu. Arkistoitu 8.5.2018.

Aiheesta muualla

Noudettu kohteesta ”https://fi.wikipedia.org/w/index.php?title=RINA&oldid=22613571”