4.4.2 Definizione di modelli di valutazione CEFRIEL / Università Roma 3 / Politecnico di Milano Milano 17 novembre 2004 Speaker Giacomo Verticale Politecnico di Milano

Introduzione Routing end-to-end in reti ad-hoc adattative Interazione tra IPv4 e IPv6 nelle connessioni end-to-end QoS nella interconnessione tra reti UMTS e IP DiffServ Conclusioni

Introduzione In una rete multicanale il traffico end-to-end attraversa molte sottoreti con diversi obiettivi e modelli di qualità Un protocollo o algoritmo di routing adattivo deve essere in grado integrare al meglio le possibilità offerte da ogni sottorete In questo task si studia: come le prestazioni dei protocolli di routing ad-hoc dipendono dal modello di mobilità degli utenti come scoprire la presenza di tunnel logici all’interno delle sottoreti come i modelli di QoS delle reti cellulari possano convivere con i modelli di QoS delle reti IP

Introduzione Routing end-to-end in reti ad-hoc adattative Interazione tra IPv4 e IPv6 nelle connessioni end-to-end QoS nella interconnessione tra reti UMTS e IP DiffServ Conclusioni

Motivazione Una MANET è un sistema auto-organizzante di routers mobili Possibilità di muoversi liberamente Rete senza topologia prefissata La mobilità è un fattore significativo per le performances della rete Lo scopo del lavoro è lo stidio dell’impatto dei modelli di mobilità sui risultati simulativi Possibili utilizzi delle MANET Conferenze e Meetings Gruppi di ricerca e salvataggio Disaster Recovery

Modelli di mobilita’ simulati Random Waypoint Model I modelli di mobilità simulati per la valutazione delle prestazioni: Random Waypoint, Gauss-Markov e Manhattan Manhattan Model Gauss-Markov Model

Conclusioni Si può osservare che l’utilizzo di diversi modelli di mobilità può alterare anche significativamente il ranking dei protocolli in termini di throughput Si nota una differenza di anche un ordine di grandezza sia per il throughput che per l’overhead di routing Le nostre osservazioni suggeriscono che i pattern di mobilità sono molto importanti AODV sceglie la route considerando il primo pacchetto RREQ ricevuto  route meno congestionata L’overhead di routing di AODV è piuttosto stabile AODV funziona meglio in situazioni più stressanti Per aumentare ulteriormente le prestazioni è necessario lo sviluppo di un AODV basato sia sui messaggi di hello che su informazioni ricevute del livello di data-link AODV incontra difficoltà a trovare una route con alta mobilità e necessita di routes con una vita media alta  è necessario un buon algoritmo di link prediction

Introduzione Routing end-to-end in reti ad-hoc adattative Interazione tra IPv4 e IPv6 nelle connessioni end-to-end QoS nella interconnessione tra reti UMTS e IP DiffServ Conclusioni

Transizione verso IPv6 IPv6 offre vari vantaggi per la sostenibilità di Internet nel lungo periodo La transizione da IPv4 a IPv6 prevede un periodo di coesistenza delle due tecnologie La rete IPv6 è basata su infrastruttura IPv4 Ampio uso della tecnica del tunneling Tunneling IPv6-in-IPv4 I pacchetti IPv6 vengono incapsulati in pacchetti IPv4 per oltrepassare zone di rete che non supportano IPv6 Il tunnel viene visto da IPv6 come un singolo link di livello 2

Un tunnel è un link di bassa qualità Coinvolge molte apparecchiature Tunneling e QoS Un tunnel è un link di bassa qualità Coinvolge molte apparecchiature Meno affidabilità di un link “nativo” Tempi di latenza che sono la somma dei tempi dei link coinvolti nel tunnel Un tunnel è un normale link per i protocolli di routing e per le applicazioni Servizi offerti tramite tunnel sono quindi meno pregiati

Tunnel discovery e adattatività Esigenza di adattatività end-to-end Ciascuna stazione può scegliere i serventi in base alla qualità del percorso che li congiunge Può preferire collegamenti privi di tunnels Esigenza di discovery dei tunnels

Risultati sul tunnel discovery Sviluppo di tecniche di discovery basate su MTU discovery IP spoofing Hop Limit Manipulation Source routing DNS lookup Studio della applicabilità delle tecniche alle reti 6bone e 6net Sviluppo di una utility di discovery prototipale: “tunneltrace” Dettagli nel rapporto tecnico allegato al deliverable R4.4.2 Lorenzo Colitti, Giuseppe Di Battista, and Maurizio Patrignani, "Discovering IPv6-in-IPv4 Tunnels in the Internet", Technical Report RT-DIA-82-2003, Dipartimento di Informatica e Automazione, Università di Roma Tre, Rome.

Introduzione Routing end-to-end in reti ad-hoc adattative Interazione tra IPv4 e IPv6 nelle connessioni end-to-end QoS nella interconnessione tra reti UMTS e IP DiffServ Conclusioni

Architettura UMTS (Rel 3/4) GSM BSS (Base Station Subsystem) GSM NSS (Network Switch System) BTS VLR PSTN/ISDN BSC MSC GMSC BTS EIR HLR BSC UTRAN Iub Node B Iu IP SGSN GGSN Node B RNC Iur CN (Core Network) Node B RNC GSM (CS): 9.6 kbps / 14.4 kbps HSCSD (CS): 57.6 kbps GPRS (PS): 115 kbps EDGE (CS/PS): 384 kbps UMTS (CS/PS): 2 Mbps Uu SO2

UMTS Bearer Attributes Traffic class Conversational Streaming Interactive Background Maximum bitrate (kbps) <2000 <2000 – overhead Delivery order Yes/No Maximum SDU size (octets) <1500 Delivery of erroneous SDUs Yes/No/- Residual BER 5·10-2, 10-2, 5·10-3 10-3, 10-4, 10-5, 10-6 4·10-3, 10-5, 6·10-8 SDU error ratio 10-2, 10-3, 10-4, 10-5 10-3, 10-4, 10-6 Transfer delay (ms) ≥100 ≥80 in RAB ≥280 ≥250 in RAB N/A Guaranteed bit rate (kbps) Traffic handling priority 1, 2, 3 Allocation/Retention Priority Source statistics descriptor speech/unknown

QoS in IP: i Differentiated Services Il modello DiffServ presenta una architettura semplice e scalabile senza protocolli di segnalazione La scalabilità si ottiene trattando flussi aggregati sulla base delle informazioni trasportate dai pacchetti IP I pacchetti IP sono classificati e colorati (marcati) per ricevere un appropriato trattamento nei nodi attraversati Le operazioni di classificazione, di colorazione, di controllo sono necessarie solo nei router di confine della rete (Border Router)

Caratteristiche principali del modello DiffServ Definizione di un contratto (SLA) tra cliente e fornitore del servizio Classificazione del traffico e aggregazione dei flussi in classi di servizio Trattamento delle classi di servizio secondo un livello di QoS predefinito Vengono definiti opportuni Per-Hop Behavior (PHB) che specificano come devono essere trattati i pacchetti di una certa classe (priorità, modalità di scarto) DiffServ fornisce degli strumenti “hop-by-hop”: il servizio end-to-end deve essere costruito dall’operatore

Scenario di riferimento – interfaccia UMTS - IP Nella Core Network UMTS è modellato solo il GGSN Funzioni della rete IP-DiffServ nel Border Router 1 Tutti le sorgenti inviano pacchetti allo stesso host di destinazione GGSN Core Network UMTS Traffico UMTS best-effort Border Router 1 Backbone IP-Diffserv Border Router 2 Host Hidden terminal

Scenario di riferimento – sorgenti di traffico Traffic Class voce UMTS video UMTS web UMTS best-effort Average Bitrate; Ra 12,2 kbps 27,9 kbps -- Peak Rate; Rp 39,9 kbps Activity factor 1 0,75 Interarrival Time Exponential Packet Length 32 byte Uniforme 133÷333 byte 480 byte 1500 byte Mean call duration 120 [s] Header Length RTP+UDP+IP 40 [byte] TCP+IP

Scenario di riferimento – il Border Router Usiamo al meglio gli strumenti offerti da DiffServ per implementare una QoS compatibile con il modello UMTS Il classificatore aggrega i pacchetti in 4 flussi di traffico La funzione di meter è realizzata con un token bucket É presente una coda per ogni classe di traffico Le code relative al traffico dati sono gestite da una disciplina RED o RIO Viene utilizzato l’algoritmo WFQ come tecnica di schedulazione Web Video BE Voce Classifier Meter Shaper Marker DROPTAIL RIO RED Scheduler

Introduzione Routing end-to-end in reti ad-hoc adattative Interazione tra IPv4 e IPv6 nelle connessioni end-to-end QoS nella interconnessione tra reti UMTS e IP DiffServ Conclusioni

Conclusioni E` possibile interconnettere reti con tecniche di routing e modelli di qualità differenti L’overhead protocollare necessario per l’interconnessione e la perdita di capacità espressiva nella traduzione da un modello ad un altro hanno un impatto negativo sulle prestazioni E’ necessario quantificare questo impatto negativo per caratterizzare opportunamente il percorso end-to-end