UNIVERSITA’ DEGLI STUDI DI ROMA “TOR VERGATA”

Facoltà di Ingegneria

Laurea in Ingegneria delle TelecomunicazioniTesi di Laurea Magistrale

DEFINIZIONE, IMPLEMENTAZIONE ED ANALISI PRESTAZIONALE DI PROTOCOLLI DI

TRASPORTO PER RETI CONTENT-CENTRIC

Candidato:

Andrea Fratini

Relatore:

Prof. Stefano Salsano

Co-Relatori:

Prof. Andrea Detti

Ing. Matteo Pomposini28 Aprile 2011

OBIETTIVO DELLA TESIProgettazione 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

EVOLUZIONE NELL’USO DI INTERNET

Accesso tramite indirizzo IP a dispositivi di

memoria e potenza elevata

Accesso tramite Nome aContenuti

(video, foto, file musicali…)

LE ORIGINI OGGI

TRAFFICO NELLA RETE INTERNET

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.

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

Necessità di un nuovo protocollo di trasportoTCP TRASPORTO CONTENT-CENTRIC

FUNZIONALIT

A’

Sender-Driven Receiver-Driven

Comunicazione di natura End-to- End

Nodi intermedi possono effettuare caching di un Contenuto e trasmetterlo

direttamente.

La dimensione della CongestionWindow limita il

numero di Dati non riscontrati nella Rete

La dimensione della finestra limita il numero di Richieste inoltrate

(INTEREST) nella Rete.

Il sender usa la ricezione degli ACK per incrementare la sua

CongestionWindow

Il receiver usa la ricezione dei Dati per incrementare la sua finestra di richieste.

Dati e ACK inviati in sequenza da sender e receiver.

Il receiver comunica quale parti del dato (chunks) vuole.

Necessità di un nuovo protocollo di trasporto

Design

Implementazione

Valutazione prestazioni

Packet Data Units

Algoritmi di controllo di flusso e congestione

CONTENUTO

Chunk=Parte di contenuto che identifica unità di caching della rete

DATA Packet (256, 512 kB)

Carrier-packets (1460 Bytes)

VIDEO (1 GB)

Packet Data Units

DESIGN

Network Identifier

Chunk Number

INTEREST

Segment info(from byte to byte)

Header

(Network-Identifier)(Chunk Number)(Payload Type)

Payload Header(segment info)

Path state

void payload

Carrier-packet

Un INTEREST è l’unità dati usata per formulare la richiesta di un Contenuto.• NID= Nome del contenuto• Chunk Number= Numero del chunk di appartenenza

DESIGN

Header

(Network-Identifier)(Chunk Number)(Payload Type)

Carrier-packet

Payload Header(segment info: da byte a byte)

Path state

Payload

Network Identifier

Chunk Number

DATA

Data Chunk

Security Data(signature, Signed info,…)

Segment

DESIGN

Una DATA unit è la parte di un Contenuto, identificato da:NID= Nome del contenutoChunk Number= Numero del chunk di appartenenzaSecurity Data= Garanzia dell’autenticità e affidabilità del contenuto

CONTENT-CENTRICNETWORK

Under-CONET(L2, IP*, UDP/IP)

Trasporto

Ogni nodo

Proprietà del protocollo content-centric

La comunicazione è iniziata dal ricevitore, inviando un INTEREST contenente il nome di un contenuto di suo interesse.

Dopo aver ricevuto i primi bytes del primo chunk effettuerà una successiva richiesta aumentando la INTEREST WINDOW.

E’ il ricevitore a decidere quando la comunicazione finisce, terminando l’invio degli INTEREST.

Se il DATO richiesto non è ricevuto entro un certo tempo, è compito del ricevitore ritrasmettere il relativo INTEREST

RECEIVER-DRIVEN

CONTROLLO DI CONGESTIONECome in TCP, una finestra limita il numero di pacchetti inviati nella rete,

MA è gestita dal ricevitore

Come in TCP, sono implementate le fasi di slow start e congestion avoidance, MA queste fasi sono regolate dai DATI ricevuti, non sono previsti ACK.

RECUPERO D’ERRORECome in TCP un errore in ricezione è dovuto alla mancata ricezione di un

pacchetto, MA nel nostro caso di un DATO e non di un ACK.

2 casi:1)Nessun dato è più ricevuto fino allo

scadere del TIMEOUT: Scatta algoritmo di controllo: INTEREST WINDOW ridotta e inizio fase di slow-start

2)Ricezione di DATI fuori sequenza:-Il ricevitore accetta i DATI fuori sequenza.-Al terzo si attiva la fase di fast recovery, come per i 3ACK duplicati in TCP

Solo gli End-node

Design

INTEREST (0-100)

DATA (0-100)

End-user

DATI DA 0 A 700 IN CACHE

NODO SERVER

Corriere.it

DATA (101-200)

DATA (201-300)

INTEREST (101-200)

INTEREST (201-300)

INTEREST (701-1500)

DATI RICHIESTI NON IN CACHE

INTEREST (301-700)DATA 301-700

DATA 701-1500

IMPLEMENTAZIONE

NS3 (NETWORK SIMULATOR 3)

Realizzazione di entità e protocolli in C++

WIRESHARK

Dissector in LUA

ANALISI PERFORMANCE

Utilizzo efficiente della banda

Work-conserving

Fairness TCP-friendly

)(

3.1

LossRatepRTT

MTUBandwidth

Benefici del caching

CASO TCP

Link 10 Mb/s

Link 10 Mb/s

Link 10 Mb/s

5 Mb/s

5 Mb/s

Benefici del caching

CASO CONTENT-CENTRIC

Link 10 Mb/s

Link 10 Mb/s

Link 10 Mb/s

Dato in cache

Content-centricRouter

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.

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…