# 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)*