Content Delivery Network

RETI INTERNET MULTIMEDIALI
Content Delivery Networks
Esigenza
La diffusione di contenuti con l’architettura Web ha avuto uno sviluppo notevole
grazie al suo paradigma semplice e di grande efficacia
L’erogazione efficiente di contenuti via Web è stata indirizzata con diverse
strategie di azione che affrontano l’esigenza di fronteggiare in modo scalabile i
carichi crescenti, di diffondere contenuti con esigenze differenti (dinamica,
volume, località spaziale e temporale dei fruitori rispetto alle origini, …), di
assicurare latenze di accesso accettabili, di occupare le risorse di rete in modo
efficiente, di fronteggiare eterogeneità di terminali, di assicurare alta
disponibilità, …
Molti client che accedono alla medesima informazione generano un carico su
server e rete che può essere evitato o ridimensionato
Server
Backbone ISP
ISP-1
Clients
ISP-2
Impiego di proxy
L’introduzione di sistemi che replicano i contenuti e si frappongono tra
client e server (detti proxy o proxy applicativi) è una pratica che tende a
migliorare il sistema Web di distribuzione dei contenuti
Reverse proxy utilizzati come front-end del server dai fornitori di
contenuti per ridurre il carico del server per la diffusione di contenuti
statici
Server
Reverse proxies
Backbone ISP
ISP-1
Clients
ISP-2
Impiego di proxy
I forward proxy sono sistemi intermedi con funzioni di replica dei
contenuti posizionati in prossimità dei client e dispiegati nella rete
aziendale o dall’ISP
Questa posizione consente di ridurre la latenza di accesso e contenere il
carico di rete per contenuti di interesse per una moltitudine di client che
puntano ad un stesso sistema di forward proxy
Server
Reverse proxies
Backbone ISP
ISP-1
Forward proxies
Clients
ISP-2
Replica dei contenuti
La replica dei contenuti tende ad avvicinare i contenuti ai richiedenti ed è
efficace se i contenuti sono consistenti e validi e sono richiesti da una
pluralità di utenti (località spaziale e temporale)
Si può ottenere la replica in modo incidentale e trasparente rispetto ai
sistemi terminali (sistema pull)
 La copia viene generata opportunisticamente nel sistema proxy al momento in
cui vi è un accesso al contenuto da parte di un client che punta al proxy
 Nel Transparent Caching le cache sono trasparenti ai client (intercettano il
traffico in transito), mentre nel Proxy Caching Esplicito i client sono configurati
per puntare ad un sistema intermedio che fa caching
Le repliche dei contenuti possono essere sistematicamente programmate
(sistema push)
 La copia può essere generata attraverso un sistema esplicito di diffusione che
propaga copie dei contenuti che verosimilmente beneficeranno dell’uso di
proxy
 Sistema di content delivery esplicito sviluppato in maniera sofisticata da
operatori specializzati nel servizio di Content Delivery Networks
Principio del caching
Le risorse veloci sono scarse, es. capacità di storage vicina
ai client (link veloci e bassa latenza)
Si mira a posizionare gli oggetti usati comunemente nelle
risorse veloci ed a lasciare gli altri oggetti nelle risorse più
lente
E’ importante determinare gli oggetti usati comunemente
Gli accessi sono spesso correlati fra loro e si dice che
hanno “locality” o località
 Località temporale: l’informazione che viene consultata in un
certo istante verosimilmente sarà consultata nuovamente in
tempi brevi
 Località spaziale: l’informazione consultata da un punto
verosimilmente sarà consultata da punti adiacenti
Consistenza
Consistenza: assicura che molti oggetti (repliche) sono
coerenti ed allineati
 Oggetti nell’Origin Server e nelle Cache
 Molteplici oggetti che descrivono la stessa cosa
Detta “semantic transparency” nel RFC2616 su web
caching
Se un oggetto cambia nell’Origin Server quando viene
allineata la copia nelle Cache?
 Validation: la copia nella Cache si usa solo dopo un controllo
 Invalidation: Origin Server può indicare l’expected expiry time
Diversi gradi di consistenza:
 Forte: evitare consegna di oggetti non consistenti
 Debole: consegnare oggetti non consistenti con bassa
probabilità
Caching cooperativo
Quando la cache non
contiene un oggetto,
anziché chiederlo all’Origin
Server lo si richiede ad altre
cache sulla base di una
procedura organizzata:
 Flat o piatto: tutte le cache
sono paritetiche
 Gerarchico: le cache sono
strutturate in livelli gerarchici
e la diffusione degli oggetti è
organizzata ad albero
Direttive HTML e HTTP
Le direttive HTML e HTTP consentono a client e server di
impostare e condizionare le modalità di caching di un oggetto
Direttive HTML:
 Es. <meta http-equiv="pragma" content="no-cache">
 HTML più vicino all’utente e all’autore della pagina Web
 Facile da controllare da parte degli autori
 Limitato agli oggetti HTML
Direttive HTTP:
 Es. Cache-control:, Expires:, if-modified-since:,





Campi dell’intestazione HTTP
HTTP è a livello più basso
Più facile da gestire e da rispettare da parte delle cache
Più diffuse
Web server determina le direttive HTTP utilizzate (es. nei file
httpd.conf e .htaccess)
Direttive HTTP imperative
Le “Gross directive” hanno la prevalenza su altri controlli
della cache, es. se si tratta di impedire o specificare l’uso
delle cache
Nelle richieste e nelle rispose:
 no-store: impedisce il caching degli oggetti e può essere
associato a richieste o risposte (usato anche per scongiurare la
inavvertita propagazione di informazione riservata)
 no-transform: impedisce alla cache di operare trasformazioni
(es. Trascodifiche) dei dati
Solamente nelle richieste:
 only-if-cached: richiede l’uso della cache e si usa quando l’Origin
Server è indisponibile e il client non vuole attendere la
validazione
Ciclo di vita di un oggetto
Age
Last-modified
Date
Inviato da
Origin Server
Tempo di accesso
dalla cache
Expires
Last-modified: quando l’oggetto è stato modificato dall’Origin
Server
 < Date della copia del client => OK utilizzo della copia
 Date – Last-modified indica la frequenza dei cambiamenti
Date: Indica l’istante in cui l’oggetto fu inviato dall’Origin Server
 + Age = Riferimento per verificare l’expiry
Expires: predizione del server di quando le copie devono essere
sostituite
Age: tempo passato dall’oggetto nella cache
Direttive di tempistica
Reference
Max-age
Date
Min-fresh
Now
Max-stale
Expires
I client possono richiedere oggetti che hanno una certa esigenza di
tempistica:
 Max-age: il client può non gradire informazioni con una certa obsolescenza
(riferito a Date e non a Last-modified, quindi misura il tempo in cache e non
dall’ultima modifica); può essere anche trasportato nelle risposte limitando
l’età in termini relativi rispetto alla Expiry date
 Min-fresh: Il client può cercare di riusare un oggetto per qualche tempo e si
assicura che non raggiunga prima lo stato di Expiry
 Max-stale: Il client potrebbe accettare informazione un po’ obsoleta (di
default le cache non restituiscono informazione obsoleta)
«Expiry» predetta dal server
Il server può limitare il tempo di vita degli oggetti che
invia:
 Expires: quando un oggetto diventa obsoleto in termini assoluti
• Il client e la cache possono determinare il tempo relativo attraverso la
Expires- Date
• Utile per oggetti il cui contenuto è influenzato dal calendario, es. Date
di copyright aggiornate ogni anno
 Cache-control: max-age: Specifica direttamente la longevità della
cache (tempo relativo)
• Utile per specificare un intervallo (es. 1 giorno), senza calcolare la data
assoluta (es. Max-age elevato per il logo aziendale e basso per la
pagina delle news)
Se il server non modifica l’oggetto prima del suo expiry
time, il client può essere sicuro della consistenza forte
Tuttavia expiry è una predizione del server e può essere
sbagliata: per questo si ricorre alla validation
Versioni di un oggetto
Le versioni di un oggetto possono essere
determinate da:
 Last-modified time:
• Richiede che l’Origin Server impieghi un clock di riferimento
• Risoluzione di un secondo
• Non differenzia tra cambiamenti minori o maggiori (es.
Presentazione o contenuto)
“Entity tags” (Etag:):
 Stringhe che distinguono diverse versioni di una entità
 Es. Create calcolando l’hash del contenuto di un’entità
 Es. ETag: "28002d-730-45105ae9"
Validazione da parte del client
Validation = Verificare se una copia è ancora
utilizzabile (quando expire è scaduto,
trattandosi di un previsione del server)
Solitamente un client cerca una copia
valida, se la sua non lo è più
 “Conditional GET”:
•
•
•
•
1. Il Client invia una GET request con
“if-modified-since: data della copia in cache , o
“if-none-match: Etag della copia in cache”
2. Il Server risponde con:
– L’oggetto (se modificato), o
– response code “HTTP/1.0 304 Not Modified”
La validazione richiede tempo e il client
deve scegliere tra ritardo e grado di
consistenza
Esempio di validazione
GET /img/ietf.png HTTP/1.1
Host: irtf.org
Referer: http://irtf.org/
If-Modified-Since: Fri, 06 May 2011 10:01:43 GMT
If-None-Match: "aa0b06-754-4a29893aa8fc0“
Cache-Control: max-age=0
HTTP/1.1 304 Not Modified
Date: Tue, 24 May 2011 05:21:29 GMT
ETag: "aa0b06-754-4a29893aa8fc0“
Expires: Tue, 31 May 2011 05:21:29 GMT
Cache-Control: max-age=604800
Eterogeneità dei contenuti
Risorse statiche
 Contenuto relativamente stabile nel tempo (es., HTML, immagini,
archivi, …)
Risorse volatili
 Contenuto viene modificato di frequente: periodicamente o da eventi
in corso (news, eventi sportivi, titoli di borsa, …)
Risorse dinamiche
 Contenuto creato dinamicamente (on-the-fly) sulla base della richiesta
del client (motori di ricerca, e-commerce, …)
Risorse multimediali
 Contenuti audio/video aventi dimensioni tipicamente maggiori
rispetto ad altri tipi di risorse (video clip, mp3, animazioni Flash, …) e
con requisiti di tempistica di consegna specifici del caso d’uso (realtime interattivo, …)
Risorse sicure
 Contenuti trasferiti su un canale cifrato (HTTPS)
Contenuti trattabili in cache
Una porzione significativa degli oggetti HTTP (>50%?) sono
“uncacheable”
Fonti di dinamismo?
 Dati dinamici: prezzi delle azioni, punteggio di una gara, webcam
 CGI scripts: risultati dovuti all’elaborazione su parametri passati al
server
 Cookie: risultati che possono essere influenzati dai dati passati
 SSL: I dati cifrati non sono trattabili in cache
 Advertising / analytics: il proprietario di un sito/banner vuole
misurare il # hits
• Stringhe random nel contenuto per assicurare conteggi univoci
Tuttavia la maggior parte dei contenuti dinamici ha una
dimensione modesta, mentre i contenuti statici sono
voluminosi (immagini, video, .js, .css, ecc.)
Tecnologia ESI
Edge Side Includes (ESI): linguaggio di markup basato su XML per definire
componenti di pagine Web in termini di frammenti
Si separano le funzionalità di consegna e generazione del contenuto per
aumentare la scalabilità e ridurre l’impegno di risorse
Ogni frammento ha caratteristiche proprie

Standard, «cacheabili», TTL proprio
I frammenti vengono assemblati e distribuiti dall’edge della rete
Open-standard al cui sviluppo hanno contribuito le maggiori compagnie nel
campo del content delivery: Akamai, BEA Systems, Digital Island, IBM, Oracle, …
Cosa è una CDN
Una CDN è un’infrastruttura creata per distribuire
efficacemente i contenuti dei server Web più popolari
agli utenti di Internet
La CDN si basa sulla distribuzione programmata di
repliche dei contenuti del server principale del
Content Provider (Origin Server) ad una molteplicità di
server disposti sulla rete da un CDN Provider
Il servizio di CDN è offerto dai CDN Operator ai gestori
dei siti Web che hanno contenuti popolari che
richiedono una diffusione vasta e capillare
Il servizio CDN punta a migliorare le prestazioni, ad
accrescere la scalabilità e la disponibilità
Componenti dell’architettura di
una CDN
Componenti di content delivery
 Origin Server ed un insieme di Edge
Server per replicare il contenuto
Componente di request routing
 Indirizza le richieste degli utenti verso
gli Edge Server
 Interagisce con il componente di
distribuzione per mantenere una copia
aggiornata del contenuto
Componente di distribuzione del
contenuto
 Replica il contenuto dall’Origin Server
agli Edge Server e mantiene la
consistenza
Componente di accounting
 Mantiene i log degli accessi degli
utenti e registra l’uso degli Edge Server
 Coadiuva l’analisi del traffico e la
tariffazione basata sull’uso
Origin
Server
Request
Routing
System
Replica
Server 1
Distribution
System
CDN
Accounting
System
Replica
Server N
Billing
Organization
Architettura di Akamai
Peering di Akamai ad un IXP
Peer Network
[...]
Peer Network
IXP
Content
Transit
Origin Server
 La CDN usa il
transito per
copiare i contenuti
nei server
distribuiti
 I contenuti sono
serviti agli ISP in
peering attraverso
gli IXP
 Akamai non ha un
backbone proprio
a differenza di altre
CDN (es. Limelight)
Meccanismi di routing
Come si indirizza la richiesta al server
“migliore” di una CDN?
Uso del Domain Name System:
 DNS redirection
 Riscrittura URL con hostname simbolici: URL
rewriting
DNS redirection
Il DNS autoritativo del sito Web:
 delega la risoluzione dell’hostname in un indirizzo IP a un name server
controllato dalla CDN
 o effettua direttamente la risoluzione di un indirizzo ad un cache
server della CDN (se la CDN effettua l’hosting del sito e
conseguentemente gestisce anche il DNS autoritativo)
In entrambe i casi:
 La scelta di un determinato cache server della CDN è effettuata con la
traduzione da hostname a indirizzo IP
 la scelta è fatta dal DNS della CDN che, visto il traffico da gestire, non è
costituito da un solo server ma da un network di name server
strutturati in modo gerarchico
Il valore del Time-To-Live (TTL) assegnato dal DNS autoritativo è
prossimo a 0 (circa 20 secondi), in modo tale che la CDN possa
modificare spesso il mapping tra hostname e indirizzo IP
URL rewriting
L’Origin Server riscrive le URL presenti nella pagina
HTML (container) in modo da far apparire che gli
embedded object siano localizzati su un altro server
Così ci sarà bisogno di una nuova risoluzione
dell’hostname, il cui name server autoritativo è sotto
il controllo della CDN
Nella risoluzione del nuovo hostname, i DNS della
CDN selezioneranno il cache server opportuno e le
richieste dei client per gli embedded object verranno
indirizzate verso il “miglior” cache server della CDN
Possibile usare più di un cache server per gli
embedded object di una pagina, ma coi dovuti limiti
Routing indiretto
Un sito Web che vuole avere una parte delle
proprie risorse distribuite da Akamai deve
rinominare le URL ad esse relative con un
prefisso specifico
 Es. a1025o.g.akamaitech.net
La risoluzione dell’hostname in un indirizzo IP di
un cache server di Akamai è eseguita dal server
DNS di Akamai
Il cache server prescelto è “vicino” al DNS server
locale del client e non deve essere sovraccarico
Mappare richieste su server CDN
Obiettivo: trovare il server CDN «più vicino» al client
 Stabilire sessioni di peering BGP con i router di bordo di
Internet -> mappa grezza dei sistemi autonomi (AS) di
Internet
 Combinare con traceroute effettuati contestualmente e
misura della perdita di dati tra CDN Server
 Si ottiene una mappa di Internet
Trovare un server CDN disponibile
 Stato di grazia del server, servizi richiesti, bilanciamento
del carico (CPU, dischi, rete) e condizione della rete
 Agenti simulano il comportamento degli utenti, scaricano
oggetti e riportano tasso di fallimento e tempi di servizio
Akamai caching services
ARL: Akamai Resource Locator
http://a620.g.akamai.net/7/620/16/259fdbf4ed29de/www.cnn.com/i/22.gif
Host Part
Akamai Control Part
Content URL
/7/620/16/259fdbf4ed29de/
a620.g.akamai.net/
/www.cnn.com/i/22.gif
ARL: Akamai Resource Locator
http://a620.g.akamai.net/7/620/16/259fdbf4ed29de/www.cnn.com/i/22.gif
Il Content Provider (CP) seleziona il contenuto che sarà ospitato da Akamai
Akamai fornisce uno strumento che trasforma questa CP URL in questa ARL
Questo fa si che il client acceda al server
di Akamai e non all’Origin Server
a620.g.akamai.net/
Se il server Akamai non ha il
contenuto in cache il contenuto
viene richiesto all’Origin Server
/www.cnn.com/i/22.gif
ARL host part
Punta a ~8 akamai.net
DNS server (ordine casuale,
TTL = ore - giorni)
.net gTLD
Tenta di selezionare ~8 g.akamai.net
DNS server vicini al client
(BGP - TTL = 30 minuti - 1 ora)
akamai.net
g.akamai.net
a620.g.akamai.net
CS
CS
Decisione molto granulare di
load-balancing tra i content
server locali
(TTL = 30 secondi – 1 minuto)
Ridirezione DNS a due livelli
Akamai prevede due livelli di
indirezione DNS
 1. Akamai Top-Level Name Server
(TLNS)
• Localizzati: 4 in US, 3 in EU e 1 in Asia
• TLNS rispondono con 8 LLNS in tre
regioni differenti
– Selezione per vicinanza al client
richiedente (sulla mappa)
– Gestione completa del fail di due regioni
qualsiasi
 2. Akamai Low-Level Name Server
(LLNS)
• Puntano verso gli Akamai Edge Server
che consegnano i contenuti
• Sviluppano la gran parte della
funzione di bilanciamento di carico
Ridirezione DNS a due livelli
Determinazione del server che
contiene un oggetto
Per determinare il server che consegna un
oggetto si usano algoritmi che si basano
sull’applicazione di funzioni hashing
La hash function h mappa l’oggetto
identificato da x sul server id
 Es. h(x) = [ax + b ( mod p)] (mod |S|), in cui
• p è un intero primo e p > |S|
• a e b sono interi costanti scelti uniformemente tra
[0, p-1)
• X è il numero seriale di un oggetto
Consistent hashing
Si mappino sia i server che gli oggetti su un cerchio unitario utilizzando le funzioni
di hash
Un oggetto è assegnato al server più vicino percorrendo il cerchio in senso orario
Minimizza l’impatto in caso di cambiamento: se si inserisce un nuovo server sono
impattati solo gli oggetti nel segmento precedente, se si toglie un server, si
impatta solo il server successivo
[Karger et al., 99]
4
0
A
C
1
3
B
2
Object
Cache
1
B
2
C
3
C
4
A
Peer-to-Peer
Sistemi distribuiti di condivisione di file
Tipicamente ogni partecipante detiene contenuti che
rende accessibili ed accede a sua volta ai contenuti
memorizzati da altri partecipanti
Si tratta fondamentalmente di un sistema distribuito di
memorizzazione di file
 Tradeoff tra le localizzazioni possibili dei file e la difficoltà di
ricercarli
 Peer-to-peer consente ai file di essere memorizzati in memorie
di massa distribuite: la sfida è la ricerca dei file
 La dinamicità dei partecipanti rende il problema ancor più
difficile da risolvere
Altri sistemi Internet hanno comportamenti analoghi:
Routing e DNS
Problema della ricerca P2P
N1
Chiave=“TITOLO”
Valore= file MP3…
N2
Internet
N3
?
Publisher
N4
N6
Client
Ricerca(“TITOLO”)
Problema della ricerca P2P
Napster: DB centrale
Gnutella: flooded query
Chord: routed queries
Il caso Youtube: modalità base
2. HTTP reply containing html
to construct the web page and
a link to stream the FLV file
4. HTTP reply
FLV stream
Video-servers
(front end)
Front end
web-servers
Internet
1. HTTP GET request for
video URL
3. HTTP GET request
for FLV stream
User
Il caso Youtube: nuova modalità
Struttura di cache a tre livelli: primaria,
secondaria e terziaria
Bilanciamento del carico dei server sulla
base anche dell’informazione di
localizzazione
I contenuti video sono replicati solo nelle
cache del terzo livello
Organizzazione stratificata dello spazio
dei nomi che indicano i video server
«logici»
 5 spazi di nomi “anycast”
 2 spazi di nomi «unicast»
Il caso Youtube: nuova modalità
~ 50 cache
 ~ 40 primarie (incluse ~ 10 presso ISP)
 8 località secondarie
 5 località terziarie
Gestione dei cache miss secondo due modalità:
 Pre-caricamento in background
 Ri-direzione dinamica HTTP
Architettura Netflix
Netflix ha un proprio Datacenter per le funzioni particolari (es. registrazione e
tariffazione), per il resto si basa su Cloud AWS di Amazon per i video streaming
server
Utilizza tre CDN per la consegna del traffico codificato multilivello (richiede l’uso
di Microsoft Silverlight per lo streaming basato su DASH)
Content Centric Networking
Progressivamente si assiste ad un cambio di paradigma dell’uso
preminente della rete Internet
 Da sistema di condivisione di risorse e di conversazione tra host a sistema di
distribuzione di contenuti in varie forme e con volumi crescenti
La consapevolezza di queste tendenze ha sollecitato lo studio di un nuovo
paradigma per Internet che sposta il fuoco dell’attenzione sul
trattamento dei contenuti: il Content Centric Networking detto anche
Information-Centric Networking
Resource Sharing
Conversation
Content Centric Networking
Si attribuisce la paternità dell’avviamento
della nuova linea di ricerca sul paradigma a
Van Jacobson (uno dei padri del paradigma
originale, insieme a Vinton Cerf)
 “Networking Named Content” – Van Jacobson
e al., CoNext 2009
Gli utenti attribuiscono valore ad Internet per
i contenuti messi a disposizione
La comunicazione deve risolvere il problema
di rendere accessibile il contenuto
gestendone la localizzazione per mezzo di
identificativi adeguati
L’astrazione di “named data” (ossia dati
identificati da un nome) è più adeguata per i
moderni sistemi di comunicazione su
Internet dell’astrazione “named host” (ossia
host identificato da un nome)
Content Centric Networking
Si propone una nuova pila di riferimento per il
paradigma di rete: lo strato centrale IP è sostituito
dallo strato dei contenuti («content chunks»: spezzoni
di contenuti)
Lo “strategy layer” introduce funzioni di gestione
granulare fine e dinamica per sfruttare le migliori
condizioni di connettività disponibili
Il “security layer” si occupa della protezione intrinseca
dei contenuti
Email WWW phone
SMPT HPPT RTP…
TCP UDP
IP
Ethernet PPP…
CSMA async sonet…
Copper fiber radio
browser chat….
Apps
Nodes
Links
File stream…
Security
Content chunks
Strategy
IP UDP P2P Bcast…
Copper fiber radio
Content Centric Networking
Tipo di pacchetti
Un Interest packet corrisponde a un Data packet
Data
Interest
Naming
Nomi aggregabili e gerarchici
per localizzare e condividere dati
Parzialmente leggibili dagli utenti
con principi di versioning/segmentazione
In-network caching
Ogni router ha uno storage per memorizzare contenuti
Ogni router può essere fornitore di contenuti
con logica punto-multipunto
Modi d’uso delle CCN
• Contents (data) download
Content server
or CCN routers
Signaling
• Voice chat
(real-time, interactive)
Invite
Response
• Multicasting (video streaming)
<PIT>
Interest | Face1
Interest | Face2
Interest | Face3
Conversation
Want to say
OK
Tell me
Say something
Proposte allo studio
Aspetti comuni
CCN: Content-Centric Networking (Xerox); PSIRP: Publish-Subscribe Internet Routing Paradigm (EU);
DONA: Data-Oriented Networking (Berkley);
CURLING: Content-Ubiquitous Resolution and Delivery Infrastructure for Next Generation Services« (EU COMET)
ICN proposals
Basic Primitives
(publish/subscribe)
CCN
REGISTER/INTEREST
PSIRP
PUBLISH/SUBSCRIBE
DONA
REGISTER/FIND
Curling
REGISTER/PUBLISH
Universal
Caching
Content-Oriented
Security
All ICN nodes
implement the
caching
All ICN designs
secure the content
rather than the
path
* “Information-Centric Networking: Seeing the Forest
for the Trees” – A. Ghodsi et. al., HotNet 2011
Differenze
ICN proposals
CCN
PSIRP
DONA
Curling
Naming
1) Hierarchical
human-readable
names
2) Self-certifying
(flat) names
Inter-domain
Routing
Narrow
Waist
Based on BGP
Content Routers
Rendezvous Nodes
Their own interdomain routing
paradigm
Resolution Handlers
Content-aware Routers
TCP/IP vs CCN
TCP / IP
CCN
Indirizzamento su base interfaccia
•Problemi di mobilità
•NAT/proxy per la sicurezza
Non si usano gli indirizzi per accedere ai
contenuti
• separazione di identificativo e indirizzo
per localizzare il dato
• Mobilità agevolata
• Non servono NAT/proxy
Richiesto DNS
Built-in naming
• Esigenza possibile di mappatura di nomi a
diversi livelli
Aggiunte per trattare caching
•Mirroring, CDNs
In-network caching
•No mirroring o CDN
Autenticazione su base connessione
Autocertificazione e autenticazione su base
contenuto
Cammini evolutivi verso CCN
①
②
CCN over
IP
IP and
CCN
Evolutionary
IPv4/IPv6
with CDN
③
Clean Slate
CCN
① CCN overlay – Dispiegabile e pragmatico (short-term)
② IP/CCN – Coesistenza con meccanismi di virtualizzazione di rete o con Software-defined network
(middle-term)
③ All CCN – Sostituzione dell’IP (long-term & the final stage)