Internet of things

ESEMPIO DI ARCHITETTURA DI DONA

Qui abbiamo un esempio di architettura DONA; ci sono diversi authonomos

systems (AS), ognuno dei quali ha un RS; i diversi RS fanno capo ad un RS che

svolge il ruolo di RS principale e i vari router sono usati per il delivery del dato.

Il publisher annuncia disponibilità del contenuto attraverso un messaggio di tipo

register. Il RS di riferimento dissemina questa in formazione agli RS vicini

(incluso quello di livello superiore). Il subscriber invia al RS più vicino una

richiesta di tipo find e i RS si coordinano tra loro per effettuare il discovery per

trovare il nodo che potrebbe rendere disponibile il dato. A questo punto, definita

la rotta secondo cui il dato può essere reso disponibile, i router dei vari

autonomos systems si occupano di smistare il dato al subscriber. In questo caso il

routing potrebbe essere effettuato avendo informazioni relative agli authonomos

systems che il messaggio di tipo find ha attraversato per richiedere il dato. Nel

caso in cui questa informazione non dovrebbe essere disponibile si fa riferimento

al classico IP.

La struttura dei nodi è costituita da 2 parti (P e L)

 P: è costituita dall’hash della chiave pubblica dell’owner (=principale,

cioè il proprietario, cioè colui che a messo a disposizione il dato)

 L: identificativo associato alla porzione di dato che stiamo richiedendo.

In questo caso per esempio utilizzando algoritmi di tipo asimmetrici, una

volta ricevuto il dato, posso effettuare operazioni simili, come ricalcolare

l’hash della chiave pubblica e vedere se quella del dato ricevuto

corrisponde con quella che ho ricevuto.

Un’altra delle architetture proposte è Pursuit. È una struttura molto simile a

quella vista per DONA ma in questo caso il modello di riferimento è proprio il

Publish Subscribe perché abbiamo una serie di nodi per ogni atonomous system

chiamati Rendezvous Node, ognuno dei quali mappa i router sottostanti per ogni

atonomous system attraverso le Ash table distribuite.

Le Ash table funzionano così: si hanno delle strutture di tipo vettoriali

attraverso le quali possiamo mappare una grande quantità di contenuti in un

dominio ristretto.

Questo è possibile grazie all’inserimento di un contenuto specifico all’interno

della nostra table facendo riferimento all’ash del contenuto (cioè viene

effettuato l’ash del contenuto e inserito nella tabella). In questo modo ad ogni

contenuto viene associate una chiave di accesso all’interno della tabella in

maniera univoca perché appunto identificata dal proprio ash. Questo,

ovviamente, permette un accesso diretto alla risorsa e oltretutto settando le

proprietà delle funzioni di ash possiamo mappare grandi contenuti di dominio

ristretto.

A loro volta queste tabelle d iash vengono distribuite mediante tutti i nodi

ovvero ogni rendez vous node gestisce un certo numero di chiavi della tabella

distribuita e sa esattamente quali nodi si possono raggiungere attraverso se

stesso.

Anche qui la comunicazione è molto simile a quella vista per DONA: avviene la

comunicazione tra consumer e producer con i rispettivi rendez vous node.

Una delle differenze, in questo caso è che ogni volta stabilito dove il dato può

essere reso effettivamente disponibile, abbiamo un nodo aggiuntivo che è il

topology manager che si occupa di mappare il percorso che il dato deve fare

verso il producer.

In questo caso abbiamo la gestione dei nomi a due campi, di cui il primo campo

viene chiamato lo scope ID che serve per fare aggregazioni di tipo gerarchica

anche perché per le operazioni di publish e subscribe può essere effettuato il

machting semplicemente andando a guardare lo scope id di riferimento.

In questo caso il nodo che gestisce la risoluzioni dei nodi è chiamato

NRS , che interagisce con il nodo RS di riferimento.

Il nodo sorgente annuncia la disponibilità del dato e delle rotte attraverso un

protocollo specifico di routing e si hanno due opzioni per richiedere la

disponibilità: o contattando il nodo NRS oppure si può inviare un messaggio di

tipo get, all’interno del quale potrebbe esserci l’informazione dei router

eventualmente da attraversare per arrivare al dato.

Gli scenari di riferimento sono molteplici e quelli per la quale si sta effettuando

maggiore sperimentazione sono essenzialmente video e audio streaming, social

networking e soprattutto mobile e comunicazione tra veicoli proprio perché, in

maniera intrinseca i nodi sono in continua mobilità e in questo caso può risultare

difficile identificare il nodo attraverso il proprio indirizzo ip perché questo

indirizzo ip può cambiare con frequenze molto elevate.

Nell’IOT, le tecnologie di tipo icn possono essere utilizzate come

tecnologie implementate parzialmente a livello applicativo e a livello di

rete parzialmente a supporto di diverse tipologie di protocolli per l’iot.

NAMED DATA NETWORKING (NDN):

Il progetto è partitolo attorno al 2010 al quale

collaborano circa 12 università da ogni parte

del mondo e si può ritenere in qualche modo

che sia una delle applicazioni più complete

del paradigma di CHAIN.

Il focus di NDN (Named Data Networking) è

di richiedere e ottenere dei dati e in un certo

senso il concetto di nodo, di entità viene in un certo senso astratto. Ritroveremo

molte caratteristiche viste in precedenza.

La comunicazione è abilitata secondo due tipologie di pacchetti:

1. INTEREST= attraverso interest si richiede il contenuto, ricevuto

l’interest, il dato, se reso disponibile, è incapsulato in un pacchetto di tipo

date e rispedito al mittente. I nodi sono di tipo gerarchici in un formato

“human readable” con campi separati dallo slash solitamente e facilmente

aggirabili. La caratteristica attraverso cui il percorso secondo il quale il

dato deve essere ritornato al mittente viene effettuato attraverso l’interest

stesso. Questo significa che quando l’interest attraversa un certo numero

di nodi per arrivare al nodo che rende disponibile il dato lascia delle

tracce cosiddetti “breadcrumbs” nei nodi che ha attraversato durante il

percorso. Questo percorso, creato ovviamente sempre in modalità hop by

hop, verrà utilizzato come percorso in maniera inversa per restituire il

dato al consumer.

Ogni nodo nella rete NDN che sia router, consumer o producer mantiene

in memoria 3 strutture principali:

 Content Store (CS), la cache dei contenuti che può

eventualmente rendere disponibili

 Pending Interest Table (PIT) che è una struttura che si occupa di

mappare quali sono gli interest ricevuti dal nodo e le interfacce di

ingresso da cui l’interest è stato ricevuto. Questa struttura

permette di effettuare aggregazione poiché, intanto che l’interest

sta viaggiando nella rete e il dato non è ancora stato ricevuto, la

rispettiva entry all’interno di questa tabella verrà memorizzata.

Intanto che il dato deve essere ancora ricevuto e il tutto viene

anche controllato tramite un time out, intanto che questa entry è

attiva nella tabella e uno stesso interest viene nuovamente

ricevuto per lo stesso dato da un altro nodo, esso non verrà inviato

nella rete ma semplicemente verrà aggiunto un nuovo valore alla

entry che corrisponde al nome del contenuto specificato

nell’interest e interfaccia di arrivo. Se lo stesso interest arriva da

più interfacce, posso pensare di richiedere il dato una sola volta e

di restituirlo una volta arrivato a tutti i consumer interessati a quel

dato

 Forwarding Information Base (FIB) è una struttura che gestisce il

forwarding. Molto simile a quella presente in IP che effettua anche

le stesse operazioni: è a conoscenza di quali sono le interfacce di

uscita verso cui verosimilmente un certo nome è disponibile.

Anche in questo caso per un dato contenuto possiamo

eventualmente avere più interface verso cui è disponibile. Quando

parliamo di interfacce non stiamo parlando di indirizzi ip poiché

potremmo avere più interfacce, sia remote che locali (interfaccia

Ethernet, Bluetooth, interfaccia Wifi ecc…) . Questo mi consente

di scambiare dati tra interfacce diverse. Banalmente si potrebbe

ricevere un interest da un’interfaccia Bluetooth e richiedere il dato

attraverso un’interfaccia ethernet o wifi o viceversa. Questo è

quello che accade oggi attraverso l’Ecdn ovvero il singolo

provider in questo caso YouTube, si iscrive alla Ecdn, offre il suo

servizio di dati attraverso la cdn e attraverso i vari internet service

provider, viene effettuato il delivery del dato a ogni singolo utente

(una singola replica del dato per ogni utente). Questo ovviamente

visto in larga scala si potrebbe creare il cosiddetto collo di

bottiglia.

Quello che, invece, immaginiamo possa accadere brevettando una

tipologia NDN, è una distribuzione del contenuto tra i vari interest

service provider e rendere il dato accessibile localmente ai

consumer, aggregare i consumer, suddividerli. Pensare, ad esempio,

di implementare delle cash e quindi avvicinare in qualche modo il

dato agli utenti senza sovraccaricare il provider principale.

Questo sono le differenze a livello architetturale tra IP e l’architettura

NDN. Notiamo come abbiamo un livello aggiuntivo chiamato Strategy

che si occupa di gestire il routing e le strategie di forwarding del

pacchetto.

Inoltre abbiamo un’altra differenza fondamentale che evidenziamo tra le

due architetture è l’implementazione dell’hedear di security

nativamente: non stiamo aggiungendo la sicurezza come funzionalità in

più come nel protocollo IP ma in questo caso la sicurezza è nativa,

garantita all’interno della rete. Non è qualcosa che dobbiamo inserire

come fosse un plug in. In questo caso il contenuto è reso sicuro, oltre

che la comunicazione è resa sicura.

2. DATA

STRUTTURA DEI PACCHETTI:

La struttura dei pacchetti è molto semplice:

-PACCHETTO INTEREST

 CONTENT NAME= in cui specifichiamo il nome del contenuto

 SELECTOR= possiamo eventualmente filtrare secondo opportune

politiche i contenuti che vogliamo ricevere

 NONCE=è un numero identificativo che identifica appunto l’interest che

sto inviando in maniera univoca. Il campo Nonce viene usato per fare

controlli sulle trasmissioni, sui duplicati dell’interest: guardando a parità

di interest con lo stesso nome, posso capire se uno stesso interest è stato

duplicato nella rete semplicemente confrontando il campo nonce. poiché

a interest diversi da consumers diversi deve corrispondere un n