115 lines
6.9 KiB
Markdown
115 lines
6.9 KiB
Markdown
|
# Architettura CCN (continua)
|
||
|
|
|
||
|
|
Punti chiave:
|
||
|
|
* Consumers inviano **interest packets**, i nodi Producers rispondono con **data packets**
|
||
|
|
* Prefissi (nomi dei contenuti) **gerarchici e dipendenti dal contesto**
|
||
|
|
* **Nonce** usati per evitare loops di Interests
|
||
|
|
|
||
|
|
*(slides per architettura CCN)*
|
||
|
|
L'architettura e' pensata per i **router**, quindi adottare la rete CCN significa **cambiare l'architettura dei router** (proposta debole).
|
||
|
|
|
||
|
|
3 strutture dati fondamentali:
|
||
|
|
* Content Store [name/content]: salva i contenuti ricevuti (**cache**)
|
||
|
|
* Pending Interest Table [prefisso/porta]: memorizza gli interessi pendenti (memorizza prefisso e porta di provenienza della richiesta)
|
||
|
|
* Forwarding Information Base [prefisso/porte]: istruzioni di forwarding dei contenuti (memorizza prefisso e porte di ricezione / invio)
|
||
|
|
|
||
|
|
Grazie a quest'architettura, e' possibile ottenere una flessibilita' ottimale per soluzioni come il multicast (che col paradigma punto-punto non sono affrontabili a pieno).
|
||
|
|
|
||
|
|
## Interessi Pendenti e "briciole"
|
||
|
|
|
||
|
|
Se due nodi hanno il contenuto, un nodo puo' decidere di inviare l'Interest a entrambi. Solo il primo data packet torna indietro, quindi si crea uno spreco di banda.
|
||
|
|
|
||
|
|
Questo e' possibile perche' i router, al momento di ritornare il contenuto, seguono lo stesso path definito dalla richiesta (un po' come se avesse lasciato delle briciole di pane). 1 interest packet = 1 data packet ritornato.
|
||
|
|
|
||
|
|
## Name prefix: struttura
|
||
|
|
|
||
|
|
Il nome dei contenuti veicola un gran numero di informazioni, seguendo uno schema **gerarchico**: *(vedi slides per albero)* si definisce il processo di gerarchia del nome come **sequencing**.
|
||
|
|
|
||
|
|
La sequenza e': *(dall'http:// al fondo dell'indirizzo)*
|
||
|
|
* Globally-routable name (dominio)
|
||
|
|
* Organizational name (path del file)
|
||
|
|
* Versioning, segmentation (convenzionale o automatico)
|
||
|
|
|
||
|
|
Comodo per passare tante informazioni in poco spazio, ma:
|
||
|
|
* Complessita' evidente del lookup di un contenuto (in pratica, l'albero e' di dimensione (altezza / profondita') non note). Per questo fare longest prefix match e' costoso
|
||
|
|
|
||
|
|
## Remarks
|
||
|
|
*(vedi slides per remarks)*
|
||
|
|
* I router mantengono **lo stato**.
|
||
|
|
* Interest is routed, not data (briciole)
|
||
|
|
* Possibili sprechi dovuti a pacchetti duplicati scartati
|
||
|
|
* Nonces
|
||
|
|
* Il salvataggio dei contenuti utilizza un replacement scheme arbitrario (favorite)
|
||
|
|
* Pending Interest: le entry della tabella hanno un **timeout**.
|
||
|
|
* CCN permette una distribuzione di dati scalabile (youtube e il video streaming ne sono un esempio)
|
||
|
|
* La realizzazione di reti AD-HOC e' molto piu' semplice: due nodi possono immediatamente comunicare tra di loro (interest packet *local friends* per entrare in comunicazione con i nodi vicini). Questo rende molto efficente lo streaming di dati su dispositivi mobile *on-the-move* (si parla di flusso dati real time), dove non si necessita piu' di handover perche' non si utilizzano piu' gli indirizzi per comunicare. *La mobilita' viene gratis*.
|
||
|
|
|
||
|
|
## TCP-like features
|
||
|
|
|
||
|
|
Il controllo di congestione e' fattibile allo stesso modo, solo che invece di ragionare con i pacchetti TCP, si ragiona con interest/data packets. La congestion window sara' quindi espressa in termini di interest packet e data packet. Simile ai segmenti TCP. Si parla di **receiver-based congestion control**.
|
||
|
|
|
||
|
|
## Other layers
|
||
|
|
|
||
|
|
### Forwarding Table (strategic layer)
|
||
|
|
|
||
|
|
Costruire la forwarding table puo' essere fatto per interfacce multiple o singole, con paradigmi *send to best* (mando al link piu' scarico) o con alternative.
|
||
|
|
Per installare le forwarding table e' necessario
|
||
|
|
|
||
|
|
### Routing (incremental deployability)
|
||
|
|
|
||
|
|
Sono possibili anche situazioni in cui ci sono router *ccn-enabled* mischiati con router IP tradizionali. Questo per facilitare l'utilizzo e l'adozione di CCN.
|
||
|
|
|
||
|
|
**Intra-domain**:
|
||
|
|
* Ip-routers: si occupano di fare forwarding dei Link-state announcements (TLV)
|
||
|
|
* CCN-routers: si occupano di due funzioni: discovery dei nodi vicini e describe di risorse connesse
|
||
|
|
* I publishers fanno advertise dei nomi (prefissi), che sono aggiunti alla FIB
|
||
|
|
|
||
|
|
Vi sono pero' situazioni non ottimali, in quanto i nodi IP **non fanno da cache**, pertando riducendo prestazioni.
|
||
|
|
|
||
|
|
**Inter-domain**:
|
||
|
|
* ISP hanno incentivi per sviluppare il CCN (costi piu' bassi, performance maggiore)
|
||
|
|
* Problema: UDP-tunneling e' necessario per collegare le *isole CCN*, ossia gli ISP che adottano CCN, attraverso l'internet IP (ISP che NON adottano CCN).
|
||
|
|
|
||
|
|
## CCN security model
|
||
|
|
|
||
|
|
Uno degli obbiettivi di CCN e' quello di migliorare la sicurezza di Internet, con l'approccio **self-certified object**.
|
||
|
|
Ciascun data packet si auto-certifica, nel senso che contiene una **signature** e delle informazioni **signed info**, cosi' che il ricevente puo' essere sicuro della sua integrita' e della sua autenticita'.
|
||
|
|
|
||
|
|
* Si associa a ogni nome una chiave, firmando i dati assieme al nome **al momento della creazione**.
|
||
|
|
* Si verifica integrita' dei dati perche' questi contengono la signature.
|
||
|
|
|
||
|
|
### Prevenzione di attacchi Interest Flooding
|
||
|
|
|
||
|
|
Per prevenire attacchi di flooding, i nodi possono monitorare **quanti interest packets dello stesso prefix sono risolti con successo**. Inoltre, i domini possono anche richiedere ai router downstream (lungo il cammino) di rallentare il numero di pacchetti che essi inviano, relativi allo stesso prefisso.
|
||
|
|
|
||
|
|
## Prestazioni
|
||
|
|
*(vedi slides per esempi di performance)*
|
||
|
|
|
||
|
|
Le prestazioni di un sistema CCN sono vantaggiose prettamente per il multicast, essendo che un utilizzo point-to-point non conviene. E' stato misurato che:
|
||
|
|
|
||
|
|
* CCNd vs ttcp (linux): CCN perde un 20% circa della banda permessa **in una connessione point-to-point** dal TCP standard, ma non e' un brutto risultato visti i vantaggi. Questo e' il caso peggiore.
|
||
|
|
|
||
|
|
* Nel caso di un multicast / uno a molti, la performance di CCNd e' decisamente migliore del ttcp, essendo che con ttcp il download time di N ricevitori e' lineare nel numero di ricevitori, mentre con CCN e' **costante**. Questo e' possibile grazie alla cache effettuata dai nodi downstream. Queste ipotesi sono valide assumendo che tutti i nodi effettuino la richiesta contemporaneamente.
|
||
|
|
|
||
|
|
## Note
|
||
|
|
|
||
|
|
* CCN migliora la performance anche nel punto-punto, prettamente per un discorso di caching lungo il percorso.
|
||
|
|
* Le massime prestazioni offerte dal CCN dovrei fare routing to nearest replica. Questo vuol dire fare routing non a casaccio ma verso il punto piu' vicino.
|
||
|
|
* Sembra incrementally deployable, ma con molte limitazioni sulla performance.
|
||
|
|
|
||
|
|
Problemi principali:
|
||
|
|
* L'architettura e' del 2009, in via di sviluppo.
|
||
|
|
* E' davvero implementabile?
|
||
|
|
* Quanto tempo serve per il prefix look up?
|
||
|
|
* I router hanno abbastanza memoria?
|
||
|
|
* Come si regolano le scelte di nomi?
|
||
|
|
|
||
|
|
Inoltre:
|
||
|
|
* Come decido con quale criterio fare caching dei contenuti? (in che nodi, quante volte, se farla o no)
|
||
|
|
* CCN e' un approccio clean-slate (parte da 0).
|
||
|
|
* Basata su successi e lezioni dell'internet di oggi
|
||
|
|
* Built-in: sicurezza, multicast, multipath
|
||
|
|
* Ha suscitato un gran numero di critiche, conferenze e ricerca.
|
||
|
|
|
||
|
|
*(vedi slides per paper SIGCOMM di critiche al CCN)*
|