6.9 KiB
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)