Introduzione ai protocolli tcp/ip ed al Domain Name System
Tesi su ccn
1. UNIVERSITA’ DEGLI STUDI DI ROMA “TOR VERGATA”
Facoltà di Ingegneria
Laurea in Ingegneria delle Telecomunicazioni
Tesi di Laurea Magistrale
DEFINIZIONE, IMPLEMENTAZIONE ED ANALISI
PRESTAZIONALE DI PROTOCOLLI DI
TRASPORTO PER RETI CONTENT-CENTRIC
Candidato: Relatore:
Andrea Fratini Prof. Stefano Salsano
Co-Relatori:
Prof. Andrea Detti
28 Aprile 2011 Ing. Matteo Pomposini
2. OBIETTIVO DELLA TESI
Progettazione ed implementazione di un protocollo di
trasporto per una rete content-centric
Sommario
Introduzione al content-centric networking
Definizione di un nuovo protocollo di trasporto
Implementazione in NS3
Analisi prestazionale
3. EVOLUZIONE NELL’USO DI INTERNET
Accesso tramite Nome a
Accesso tramite indirizzo Contenuti
IP a dispositivi di (video, foto, file musicali…)
memoria e potenza elevata
5. CONTENT-CENTRIC NETWORKING
MOTIVAZIONI
L’utente valuta il servizio in termini di cosa può ottenere,
mentre lo strato IP opera in termini di dove.
La distribuzione dei contenuti può essere migliorata
rendendo la rete content-aware e implementando caching dei
contenuti nei nodi intermedi della rete (le uniche soluzioni
esistenti, come CDN, sono content-aware solo a strato
applicativo e sono proprietarie)
L’utente vuole ricevere contenuti affidabili, ma allo stato
attuale l’utente è costretto a fidarsi di chi fornisce il
contenuto e non del contenuto stesso.
6. CONTENT-CENTRIC NETWORKING
PRINCIPI
Il Contenuto desiderato è richiesto attraverso un nome che lo
caratterizza, tale nome diventa l’indirizzo dello strato di rete
Qualunque nodo intermedio che possiede una replica del
Contenuto nella sua cache può rispondere ad una richiesta e
fornire il dato
La sicurezza è spostata dal canale al Contenuto
7. Necessità di un nuovo protocollo di trasporto
TCP TRASPORTO CONTENT-CENTRIC
Sender-Driven Receiver-Driven
Comunicazione di natura Nodi intermedi possono effettuare
F
End-to- End caching di un Contenuto e trasmetterlo
U
direttamente.
N
Z La dimensione della La dimensione della finestra limita il
I CongestionWindow limita il numero di Richieste inoltrate
O numero di Dati non riscontrati (INTEREST) nella Rete.
N nella Rete
A
L Il sender usa la ricezione degli Il receiver usa la ricezione dei Dati per
I ACK per incrementare la sua incrementare la sua finestra di richieste.
T CongestionWindow
A’ Dati e ACK inviati in sequenza Il receiver comunica quale parti del dato
da sender e receiver. (chunks) vuole.
8. Necessità di un nuovo protocollo di trasporto
Packet Data Units
Design
Algoritmi di controllo di flusso e
congestione
Implementazione
Valutazione prestazioni
9. DESIGN
Packet Data Units
Chunk=Parte di contenuto che identifica unità di caching della rete
CONTENUTO VIDEO (1 GB)
DATA Packet (256, 512 kB)
Carrier-packets (1460 Bytes)
10. DESIGN
INTEREST Carrier-packet
Header
Network Identifier
(Network-Identifier)
Chunk Number (Chunk Number)
(Payload Type)
Segment info
Payload Header
(from byte to byte)
(segment info)
void payload
Path state
Un INTEREST è l’unità dati usata per formulare la richiesta di un Contenuto.
•NID= Nome del contenuto
•Chunk Number= Numero del chunk di appartenenza
11. DESIGN
DATA Carrier-packet
Header
Network Identifier
(Network-Identifier)
Chunk Number (Chunk Number)
(Payload Type)
Security Data
(signature, Signed info,…) Payload Header
Segment (segment info: da byte a byte)
Payload
Data Chunk
Path state
Una DATA unit è la parte di un Contenuto, identificato da:
NID= Nome del contenuto
Chunk Number= Numero del chunk di appartenenza
Security Data= Garanzia dell’autenticità e affidabilità del contenuto
12. Proprietà del protocollo content-centric
RECEIVER-DRIVEN
La comunicazione è iniziata dal ricevitore, inviando un INTEREST
contenente il nome di un contenuto di suo interesse.
CONTROLLO DI CONGESTIONE
Dopo aver ricevuto finestrabytes delnumero di pacchetti inviati nella rete,
Come in TCP, una i primi limita il primo chunk effettuerà una successiva
richiesta aumentando la INTEREST WINDOW.
MA è gestita dal ricevitore
RECUPERO D’ERRORE
Come in TCP undecidere quando la comunicazione finisce, ricezione di un
E’ il ricevitore a errore in ricezione è dovuto alla mancata terminando
pacchetto, MA nel nostro caso di un DATO e non di un ACK.
l’invio degliTCP, sono implementate le fasi di slow start e congestion avoidance,
Come in INTEREST.
2Trasporto
casi:
MA queste fasi sono regolate dai DATI ricevuti, non sono previsti ACK.
Solo gli End-node
1)Nessun dato è richiesto non è ricevuto entro un certo tempo, è compito del
Se il DATO più ricevuto fino allo 2)Ricezione di DATI fuori sequenza:
CONTENT-CENTRIC
ricevitore ritrasmettere il relativo INTEREST ricevitore accetta i DATI fuori
scadere del TIMEOUT: NETWORK -Il
Scatta algoritmo di controllo: sequenza.
Under-CONET Ogni nodo
INTEREST WINDOW -Al terzo si attiva la fase di fast recovery,
(L2, IP*, UDP/IP)
ridotta e inizio fase di slow-start come per i 3ACK duplicati in TCP
13. End-user
Design
NODO SERVER
INTEREST (0-100)
DATA (0-100)
INTEREST (101-200)
DATA (101-200) INTEREST (201-300)
DATA (201-300) DATI RICHIESTI
NON IN CACHE
INTEREST (301-700)
DATA 301-
700 INTEREST (701-1500)
DATA 701-
1500 DATI
DA 0 A 700 IN CACHE
18. Conclusioni
Il nuovo approccio content-centric networking per la Future
Internet permette di migliorare la distribuzione e il
reperimento dei contenuti fornendo indirizzamento attraverso i
nomi, caching nativo e sicurezza nel contenuto.
La definizione di un nuovo protocollo di trasporto per reti
content-centric comporta il trasferimento del potere della
comunicazione al ricevitore, mantenendo i vantaggi derivanti
dagli algoritmi del TCP.
19. Conclusioni
E’ stata effettuata l’implementazione e l’analisi prestazionale
del nuovo protocollo di trasporto ottenendo i seguenti risultati:
Raggiungimento di un utilizzo efficiente della banda
Rispetto dei criteri di fairness
Guardando ad una graduale integrazione col TCP,
il protocollo è TCP-friendly.
Uso in modo vantaggioso del caching nativo di una rete
content-centric.
Grazie per l’attenzione…
