UniTO/anno2/YearI/FirstSem/CR/lesson13112017.md

Indirezione (continua)

Indirezione e mobilita'

Problema: nodi mobili in movimento, che si agganciano a reti diverse. Questo si applica alle reti cellulari (location update etc.) ma e' trattato negli RFC di mobile IP.

Terminologia e Approcci

• Correspondent: colui che vuole mandare pacchetti al nodo mobile
• Routing indiretto: flusso dati passa attraverso un home agent (indirezione) prima di raggiungere il nodo mobile
• Routing diretto: il correspondent ottiene il foreign address del nodo mobile, poi gli invia i dati direttamente

Il nodo mobile ha una home network dove e' definito un permanent address che non varia nel tempo, con cui il correspondent puo' attuare il tracciamento del nodo mobile. Inoltre nel home network e' definito un home agent che svolge le funzioni di mobilita' quando il nodo mobile non e' all'interno della home network.

Il nodo mobile si sposta dall'home network a una visited network, in cui ottiene un care-of-address, ossia l'indirizzo nella visited network.

Ogni visited network contiene un foreign agent, che svolge le funzioni di mobilita' (il foreign agent puo' essere all'interno della macchina del nodo mobile).

Ogni nodo che si sposta dal proprio home network deve avviare un processo di registrazione, in cui il nodo mobile contatta il foreign agent della visited network, il quale a sua volta contatta l'home agent. I due agent si comunicano la visited network del nodo mobile, di modo che questo sia rintracciabile dall'home network.

Routing Indiretto

• Il correspondent invia pacchetti usando il permanent address del nodo mobile come destinazione, come se il nodo mobile fosse fisso nell'home network.

• L'home agent intercetta i pacchetti del correspondent (se il nodo mobile non e' nell'home network) e li ridirige verso il foreign agent.

• Il foreing agent inoltra i pacchetti ricevuti al nodo mobile.

• Il nodo mobile puo' rispondere direttamente al correspondent.

Osservazioni

Con questo approccio, si ha un vantaggio di trasparenza per il correspondent, che comunica col permanent address all'insaputa dell'attuale posizione del nodo mobile. Se il nodo mobile si sposta ma l'home agent aggiorna il care-of-address, le connessioni in corso possono essere mantenute.

Si ha pero' uno svantaggio: il routing a triangolo e' inefficiente quando il correspondent e il nodo mobile sono vicini.

Routing Diretto

• Correspondent richiede (e riceve) l'indirizzo foreing address del nodo mobile.

• Il correspondent procede quindi a mandare pacchetti al foreing agent, il quale li inoltra al nodo mobile.

• Il nodo mobile replica direttamente al correspondent.

Osservazioni

Con questo approccio, il routing e' piu' efficiente (no routing a triangolo).

Lo svantaggio e' la perdita di trasparenza da parte del correspondent, che ora si deve occupare di ottenere il care-of-address, aggiornarlo. Di conseguenza, se il nodo mobile si sposta, connessioni in corso non possono essere mantenute.

IP Mobile

RFC 3220, descrive le caratteristiche e le problematiche del routing (indiretto) per nodi mobili. Problematiche:

• impraticita' del routing indiretto, soprattutto nell'implementazione dell'home agent (tunnel / NAT).
• egress filtering: non sempre e' possibile mandare sorgenti da un ip che non appartiene alla propria rete (i router li droppano). Rischio spoofing.

Costruzione di un'infrastruttura di Indirezione in Internet

Internet non e' (nativamente) appropriato per comunicazioni in cui i nodi non sono fissi e definiti (e' unicast, ma non multicast, anycast o mobile). Per ovviare a questo problema, e' stata proposta la III (Indirection Internet Infrastructure), con lo scopo di rendere l'indirezione un servizio di base, o di prima classe.

III (o I3)

Presenta un cambiamento del paradigma di comunicazione: non piu' punto-punto, ma per id del contenuto (che puo' essere numerico, testuale, etc).

• Ogni pacchetto ha un id.
• Per ricevere il pacchetto con identificativo id, il ricevente R installa un trigger (ID, R) nella rete di overlay.
• Il sender usa l'ID per mandare i contenuti (una tuple (ID, data)) al trigger.
• il trigger usa (R, data), dove R e' un secondo ID per indirizzare i dati ricevuti dal sender verso il receiver.

Modello di servizio

API:

1. sendPacket(p);
2. insertTrigger(t);
3. removeTrigger(t); // opzionale

• Si appoggia su una rete IP (best effort).
• Host utilizzano dei timeout per aggiornare periodicamente i trigger. (soft state -> robusto)
• Affidabilita', controllo di flusso e congestione sono implementati dai nodi agli estremi e dagli overlay.

Il modello di servizio e' quindi un publish-subscribe a livello applicativo, che contiene una infrastruttura di overlay. Ogni trigger e' simile a una entry nella tabella di routing, che pero' e' gestita dai nodi terminali.

Funzionamento

Quando il receiver si muove in un'altra rete, aggiorna il suo trigger di modo che il sender, tramite il nodo di overlay, sia in grado di contattarlo in modo trasparente (non deve conoscere la rete dove si trova il receiver). L'anonimita' e' un grande vantaggio di questo approccio.

• L'applicazione e' in grado di passare da unicast a multicast, basta registrare piu' triggers con il medesimo ID e la rete di overlay si occupa di mandare il messaggio a piu' receivers.

Anycast

Comunicazione con un nodo qualunque di un insieme di nodi (ex: piu' server che offrono lo stesso servizio, e l'utente richiede il servizio a uno qualunque di essi).

Per rendere possibile questo meccanismo, il trigger contiene lo stesso ID per ogni receiver interessato, ma anche qualificatori anycast che informano la rete di overlay di scegliere solo uno dei peer interessati.

Servizi Componibili

Si usa uno stack di ID per codificare operazioni successive da svolgere sui dati, senza aver bisogno di configurare percorsi tra i servizi. Questo e' possibile utilizzando piu' di un' ID all'interno del trigger, creando una serie di servizi a cipolla (stack di servizi). Ogni server intermedio riceve il pacchetto con l'id, esegue il servizio, toglie l'id interessato dal servizio e lo manda al server successivo. Cosi' facendo, il pacchetto viene processato e inviato al ricevitore, senza bisogno di configurare manualmente i path dei server che forniscono i servizi.

Questa tecnica permette di processare i dati da entrambe le parti (lato mittente e lato ricevitore), e anche di processare dati in maniera diversa per ricevitori diversi.

Conclusione

L'indirezione presenta molti vantaggi (vedi slides) ma anche molti problemi, soprattutto per quanto riguarda la sicurezza.

Inoltre, nel caso in cui il server volesse conoscere l'identita' dei ricevitori, potrebbe installare un trigger (IDack, S) con il quale i ricevitori possono mandare degli ACK al sender, che ha id S.

Distributed Hash Table (DHT)

L'obbiettivo e' implementare una hash table distribuita su internet, non centralizzata sul singolo nodo. Caratteristica essenziale e' che non sia necessario avere dettagliate informazioni sull'intera rete per gestire la DHT (conoscenza parziale: ogni nodo e' collegato unicamente a pochi nodi vicini, e conosce solo quelli). Questo e' utile nel caso dei trigger, e infatti segue un'interfaccia simile a I3:

• insert (key,value);
• lookup (key);

I nodi di una rete contengono delle parti della hash table, presentando il problema principale:

• Data una chiave, bisogna instradare il messaggio al nodo che contiene la chiave.

Questa procedura deve utilizzare il minor numero possibile di hop, anche senza che ogni nodo conosca l'intera rete. (basso fanout).

(vedi slides per grafico)

Struttura (obbiettivi di progetto)

Rete overlay con mappaggio flessibile di chiavi e nodi fisici, basso fanout, instradamento locale. Esempio: Chord

Chord

• Spazio di identificativi a m bit: 2^m IDs.
• Identificativi ordinati su anello logico (chord ring) modulo 2^m.
• I peer scelgono una chiave (a caso per favorire decentralizzazione) e vengono identificati come gestori di un range di chiavi (di modo da dividere il keyset in piu' parti).
• le chiavi vengono mappate quindi sul primo nodo con ID piu' grande della chiave, chiamato successor della chiave.

Lookup base

Ogni nodo memorizza la posizione del nodo successivo (solo quello). Questo comporta un numero non ottimale di hop, ma e' semplice (instrada in circolo lungo un anello). Il tempo di instradamento e' O(N) (worst case), in quanto se un nodo cerca una chiave molto grande rispetto alla sua, deve circolare gran parte dell'anello. (vedi slides per grafico)

Accelerazione dei lookup

Essendo che il lookup base e' lineare (inefficiente), posso accelerarlo utilizzando delle finger tables: ogni nodo le usa per conoscere (al piu') m entries, dove N = 2^m. (vedi slides per esempi)

Otteniamo quindi che:

finger[i] = successor (n+2^(i-1))

(vedi slides per algoritmo)

• Ogni nodo ha conoscenza piu' accurata della parte di anello seguente a lui piu' vicina, e piu' vaga della parte piu' lontana.

Questa accelerazione permette di avere un numero di hop O(log(N))

Churn

Fenomeno di nodi che entrano ed escono dal sistema. Questo necessita di spostare le chiavi memorizzate altrove, aggiornare le finger table, e limitare il churn. (+ churn = + overhead)

-> Occorre un middleware che gestisca memorizzazione e recupero di valori.

Osservazioni

Le DHT sono usate in bittorrent e altri protocolli per la loro natura decentralizzata e robusta (molto meno vulnerabili di server centralizzato).