Gestione della Qualità del Servizio su Reti IP Wired e Wireless per

Transcript

UNIVERSITÀ DEGLI STUDI DI PARMA
FACOLTÀ DI INGEGNERIA
Corso di Laurea in Ingegneria Informatica
Gestione della Qualità del Servizio su Reti IP Wired e
Wireless per Applicazioni Multimediali
Relatore:
Chiar.mo Prof. F RANCESCO Z ANICHELLI
Tesi di laurea di:
A NDREA D ONETTI
Anno Accademico 2002-2003
Indice
1
Introduzione
1.1 Contributi della tesi . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Organizzazione della tesi . . . . . . . . . . . . . . . . . . . . . . .
2
Qualità del servizio su reti IP
2.1 QoS nelle reti di calcolatori . . . . . . . . . . . . . . . .
2.1.1 Le reti IP . . . . . . . . . . . . . . . . . . . . .
2.1.2 Qualità del servizio . . . . . . . . . . . . . . . .
2.2 Meccanismi per offrire QoS . . . . . . . . . . . . . . .
2.2.1 Control Plane . . . . . . . . . . . . . . . . . . .
2.2.2 Data Plane . . . . . . . . . . . . . . . . . . . .
2.2.3 Management Plane . . . . . . . . . . . . . . . .
2.3 Differentiated Services . . . . . . . . . . . . . . . . . .
2.3.1 QoS end-to-end basata su domini amministrativi
2.3.2 Controllo del flusso all’interno di un dominio . .
2.4 Bandwidth Broker . . . . . . . . . . . . . . . . . . . . .
2.4.1 Base di dati . . . . . . . . . . . . . . . . . . . .
2.4.2 Protocolli di comunicazione . . . . . . . . . . .
2.5 QoS per applicazioni multimediali in reti eterogenee . .
2.5.1 Caratteristiche delle applicazioni multimediali .
2.5.2 Gestione dell’infrastruttura di rete . . . . . . . .
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
3
5
5
5
8
10
10
11
17
17
18
20
23
25
26
27
27
29
Qualità del servizio su reti wireless
32
3.1 Il protocollo IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 QoS su reti wireless 802.11 . . . . . . . . . . . . . . . . . . . . . . 34
i
INDICE
3.3
4
5
6
INDICE
3.2.1 802.11 . . . . . . . . . . . . . . . . .
3.2.2 802.11e draft . . . . . . . . . . . . . .
3.2.3 Cisco Aironet 350 Series Access Point .
QoS end-to-end tra Diffserv e 802.11e WLAN .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Realizzazione di una architettura DiffServ
4.1 Supporto DiffServ in Linux . . . . . . . . . . . . . . . .
4.1.1 Traffic Control . . . . . . . . . . . . . . . . . .
4.1.2 Code, classi, filtri e policing . . . . . . . . . . .
4.1.3 Configurazione del kernel . . . . . . . . . . . .
4.2 Architettura per il controllo d’accesso . . . . . . . . . .
4.2.1 Modelli di interazione con il BB . . . . . . . . .
4.2.2 Prototipo realizzato . . . . . . . . . . . . . . . .
4.2.3 Componenti del sistema . . . . . . . . . . . . .
4.3 QoS tra rete Wired e rete Wireless . . . . . . . . . . . .
4.3.1 Filtraggio del traffico destinato alla rete wireless
4.3.2 Domini DiffServ . . . . . . . . . . . . . . . . .
Risultati sperimentali
5.1 Configurazione della rete . . . . . . . . . . . . . . . . .
5.2 Utilizzo di schede wireless su computer Linux . . . . . .
5.3 Testbed . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Risultati . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1 Assenza di QoS . . . . . . . . . . . . . . . . . .
5.4.2 Presenza di QoS . . . . . . . . . . . . . . . . .
5.4.3 Presenza di QoS e banda in downstream variabile
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
36
38
40
.
.
.
.
.
.
.
.
.
.
.
42
43
43
45
55
56
57
60
61
74
74
81
.
.
.
.
.
.
.
84
84
85
87
89
90
92
96
Conclusioni
99
6.1 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Bibliografia
101
ii
Capitolo 1
Introduzione
Negli ultimi anni sono aumentate enormemente sia la diffusione che la larghezza
di banda delle reti IP. Questa disponibilità di risorse ha favorito l’incremento della
richiesta di applicazioni distribuite multimediali in diversi ambiti, come ad esempio
l’intrattenimento, l’istruzione e il telelavoro. Anche strumenti di uso comune come
il telefono stanno migrando verso reti IP a commutazione di pacchetto.
La trasmissione di segnali vocali e video che devono essere riprodotti immediatamente dall’applicazione ricevente è molto sensibile alla perdita di pacchetti e
richiede che vengano rispettati precisi vincoli temporali. Nella maggior parte delle
reti IP attualmente utilizzate non viene fatta distinzione tra i dati in transito e non c’è
modo di garantire la consegna secondo i vincoli richiesti dal traffico multimediale.
In letteratura [1, 2, 3, 4, 5, 6] sono documentati alcuni meccanismi per differenziare il trattamento dei dati, dando maggiore priorità al traffico più sensibile
alla qualità del servizio offerto dalla rete. In particolare l’Internet Engineering Task Force (IETF) ha ideato alcuni modelli per soddisfare le richieste di qualità del
servizio.
Tra questi ha suscitato particolare interesse l’approccio Differentiated Services
(DiffServ) [4, 5], che garantisce maggiore scalabilità e miglior adattamento all’architettura delle reti IP esistenti rispetto alle altre soluzioni proposte. Al contrario del
modello Integrated Services (IntServ) [3], che prevede il mantenimento di uno stato
per ogni flusso in ciascun router attraversato, il modello DiffServ definisce un insieme limitato di classi utilizzate per differenziare il trattamento dei dati in transito.
1
Capitolo 1. Introduzione
In ingresso ad ogni dominio caratterizzato da un’unica amministrazione, i pacchetti
vengono marcati con il codice di una delle classi previste, in base alla priorità delle
informazioni contenute. Questa marcatura viene utilizzata nei nodi centrali per decidere l’ordine di inserimento nelle interfacce di uscita dei router e la probabilità di
eliminazione in caso di congestione.
Per le funzioni di negoziazione del livello di servizio, di controllo di accesso e
di configurazione dinamica della rete può essere utilizzato un componente chiamato Bandwidth Broker [7]. Alcuni centri di ricerca hanno realizzato dei prototipi di
Bandwidth Broker secondo le proprie necessità, ma gli studi in questo campo non
hanno ancora portato alla definizione di un sistema completo e soddisfacente.
Tra le varie tecnologie per la connessione di dispositivi elettronici, quella “senza filo” (wireless) ha ultimamente avuto un grande sviluppo. La tecnologia wireless
permette di connettere comodamente ad Internet dispositivi mobili (computer portatili, telefoni cellulari, PDA) negli ambienti più disparati. Sono stati definiti alcuni
standard per la comunicazione wireless mentre altri sono attualmente in via di sviluppo. In particolare l’Institute of Electrical and Electronics Engineers (IEEE) ha
proposto il protocollo 802.11 utilizzato dalla maggior parte dei dispositivi. Il gruppo
di lavoro 802.11e, che non ha ancora concluso il suo lavoro, definirà prossimamente
uno standard per offrire qualità del servizio su reti wireless [8, 9, 10].
Il canale wireless presenta caratteristiche differenti rispetto alle reti fisse; ad
esempio la perdita di pacchetti, praticamente assente su reti locali (LAN), è sperimentata frequentemente durante comunicazioni wireless. Ad oggi non sono ancora
disponibili meccanismi robusti per offrire un servizio end-to-end di qualità ad utenti
wireless.
1.1
Contributi della tesi
Questa tesi si colloca nel progetto, in corso presso il Dipartimento di Ingegneria
dell’Informazione dell’Università degli Studi di Parma, per la realizzazione di una
infrastruttura di rete che permetta a professori, ricercatori e studenti di utilizzare
in modo soddisfacente servizi di E-Learning, videoconferenza, streaming video e
tutte le applicazioni multimediali che possano essere utili per attività didattiche e di
ricerca. Lo scopo di questa tesi è stato quello di dotare l’infrastruttura di rete ete2
rogenea (wired e wireless) esistente di strumenti per il trattamento differenziato del
traffico secondo il modello DiffServ e realizzare un sistema software per garantire
un utilizzo semplice, equo e controllato delle risorse disponibili.
Per realizzare i nodi di rete DiffServ sono stati utilizzati personal computer dotati di software GNU/Linux. È stata predisposta una rete locale comprendente i router
(edge e core) previsti dal modello DiffServ.
Per le funzioni di controllo d’accesso, allocazione delle risorse e configurazione
dinamica del sistema sono stati studiati diversi modelli di interazione tra i componenti di un dominio. È stato inoltre realizzato un prototipo che comprende un
bandwidth broker basato sul codire sviluppato presso l’Università del Kansas ed un
proxy che si occupa di configurare per l’utente la qualità del servizio. Questa soluzione permette l’utilizzo sia dal lato client che dal lato server di programmi che
ignorano la qualità del servizio, consentendo di servirsi di qualsiasi prodotto disponibile. L’allocazione delle risorse, richiesta da un componente integrato nel sistema,
viene effettuata secondo le politiche specificate dai gestori del sistema stesso.
Sono state studiate e sperimentate le caratteristiche di qualità del servizio offerte dai dispositivi di connettività wireless disponibili in dipartimento, che realizzano
alcune funzionalità di differenziazione del traffico basate sulle bozze del protocollo
802.11e. Per migliorare le prestazioni non soddisfacenti ed offrire un sistema maggiormente configurabile è stato progettato e realizzato un meccanismo che integra
la parte wireless nell’architettura DiffServ predisposta per la rete wired. In particolare è stato introdotto un core router tra il resto della rete fissa e l’access point per
adattare il traffico diretto ai dispositivi mobili secondo una politica di qualità del
servizio.
1.2
Organizzazione della tesi
Il secondo capitolo introduce i concetti fondamentali relativi alla qualità del servizio
sulle tradizionali reti IP, con particolare attenzione al modello DiffServ. Successivamente viene descritto a livello teorico il funzionamento di un bandwidth broker.
Infine viene proposto un esempio di utilizzo della qualità del servizio nel contesto
di un campus universitario.
Il terzo capitolo presenta lo stato dell’arte della qualità del servizio su reti wi3
reless; in particolare sono presentate le caratteristiche degli access point disponibili
presso il dipartimento.
Il quarto capitolo è dedicato alla descrizione dei meccanismi per la qualità del
servizio utilizzati e del prototipo di architettura DiffServ realizzato. Viene inoltre
presentato il sistema proposto per migliorare la qualità del servizio per il traffico
diretto alla rete wireless.
Il quinto capitolo mostra i risultati degli esperimenti compiuti per valutare le
prestazioni offerte dai meccanismi di qualità del servizio realizzati.
Il sesto capitolo infine riassume i risultati ottenuti e indica alcune possibili
evoluzioni del progetto.
4
Capitolo 2
Qualità del servizio su reti IP
2.1
QoS nelle reti di calcolatori
In questo capitolo vengono introdotti i concetti fondamentali di funzionamento delle reti IP e della qualità del servizio. Vengono inoltre indicati alcuni dei meccanismi
proposti in letteratura per realizzare la qualità del servizio. In particolare viene descritta l’architettura Differentiated Services, utilizzata in questo lavoro di tesi. Per
una trattazione più dettagliata si rimanda al testo [1].
2.1.1
Le reti IP
La maggior parte delle reti di calcolatori attualmente utilizzate in tutto il mondo
si basa sulla suite di protocolli TCP/IP, ideata più di vent’anni orsono e affermatasi largamente con lo sviluppo di Internet. Il protocollo di livello rete IP (Internet
Protocol) è di tipo best effort, cioè non garantisce nulla riguardo l’effettiva ricezione, l’ordinamento e la prioritizzazione dei pacchetti. Il protocollo IP ha le seguenti
caratteristiche:
• è connectionless: il trasferimento dei dati non avviene attraverso un unico
percorso stabilito per tutta la durata della connessione.
• scelte di instradamento prese hop-by-hop
• nessun meccanismo di identificazione e correzione degli errori
5
Capitolo 2. Qualità del servizio su reti IP
• supporto per diverse tecnologie al livello 2 del modello OSI (data link)
Alcune funzionalità quali la numerazione dei pacchetti e la ritrasmissione in caso
di smarrimento possono essere gestite al livello superiore di trasporto utilizzando il
protocollo TCP.
Negli ultimi anni è aumentato enormemente il numero di computer connessi
a Internet, oltre alla disponibilità di risorse hardware, software e di connettività.
In particolare c’è stato un incremento della richiesta di applicazioni multimediali
(video on demand, videoconferenza, voice over IP, e-learning, ecc.) che necessitano
di banda larga ma soprattutto costante. Nella tabella 2.1 sono riportati alcuni valori
indicativi sull’utilizzo di banda da parte di alcune delle più comuni applicazioni di
rete.
Applicazione
Voice
Whiteboard
Web Application
File Transfer
Video (streaming)
Video-conferencing
Video MPEG
Medical images
Banda tipica
6 Kbps to 64 Kbps
10 Kbps to 100 Kbps
10 Kbps to 500 Kbps
10 Kbps to 1 Mbps
100 Kbps to 1 Mbps
128 Kbps to 1 Mbps
1 Mbps to 100 Mbps
10 Mbps to 100 Mbps
Tabella 2.1: Banda tipicamente utilizzata da alcune applicazioni
Nel caso di un flusso di dati in streaming, ossia utilizzati in tempo reale dall’applicazione che li riceve, è necessario che i pacchetti rispettino dei vincoli temporali
abbastanza precisi al fine di evitare che il risultato finale risulti degradato. Esistono
degli accorgimenti per ridurre l’effetto di eventuali ritardi nella ricezione dei dati, come ad esempio l’utilizzo di un buffer, ma queste soluzioni non garantiscono
comunque un servizio del tutto soddisfacente all’utente. Queste applicazioni avrebbero bisogno di una tipologia di servizio migliore rispetto al best effort messo a
disposizione dal protocollo IP.
La versione 4 del protocollo IP impone la presenza, nell’header dei pacchetti, di
un byte che specifica il tipo di servizio (Type of Service): i primi tre bit (“PRECEDENCE”, da 0 a 2) sono utilizzati per indicare la precedenza mentre i successivi 4
(“TOS”, da 3 a 6) contengono informazioni relative all’instradamento (figura 2.1).
6
0
1
2
3
4
PRECEDENCE
5
6
TOS
IPv4 RFC 1349
7
MBZ
MBZ = Must Be Zero
Figura 2.1: TOS nell’header IP
L’ultimo bit (7) deve essere 0. I bit “PRECEDENCE” indicano priorità crescente
con l’aumentare del valore, mentre i bit “TOS” significano (scrivendo per primo il
bit numero 3 e per ultimo il numero 6):
• 0000 = normal service
• 1000 = minimize delay
• 0100 = maximize throughput
• 0010 = maximize reliability
• 0001 = minimize monetary cost
L’utilizzo di queste informazioni comporta però overhead nei router, in particolare
in quelli ad alte prestazioni che elaborano grandi quantità di pacchetti. Nella pratica tali informazioni sono di fatto ignorate dai router, per evitare un degrado della
qualità del servizio offerta dalla la rete.
La versione 6 cerca di migliorare il supporto alla qualità del servizio, oltre a
risolvere altri problemi che non sono però oggetto di questo lavoro. IPv6 definisce
nell’header i campi flow label e traffic class:
• flow label ha lo scopo di consentire la manipolazione dei pacchetti a seconda del flusso di appartenenza. Un pacchetto con la flow label specificata può
essere inoltrato in modo efficiente, utilizzando quella informazione indipendentemente dal resto dell’header. L’identificazione basata sulla label viene
utilizzata da sistemi di gestione della QOS quali IntServ [3] e Multi-Protocol
Label Switching (MPLS) [6].
7
• traffic class permette di specificare una priorità associata ad ogni pacchetto
introducendo il concetto di classe di servizio; in una classe sono raggruppati pacchetti appartenenti a flussi differenti, che formano quindi degli aggregati. Questo concetto sta alla base dell’architettura Differentiated Service
(DiffServ) [4] [5].
2.1.2
Qualità del servizio
La Quality of Service (QoS) è definita come la misura delle prestazioni di un sistema di comunicazione, che si riflette nella qualità della trasmissione e nella disponibilità del servizio. Dal punto di vista dell’utente la QoS è percepibile, in modo
meno rigoroso, attraverso il funzionamento più o meno corretto e soddisfacente
dell’applicazione utilizzata. La qualità della trasmissione è espressa dai seguenti
parametri:
• perdita di pacchetti (loss): è il rapporto tra la quantità di pacchetti ricevuti
rispetto a quanti ne sono stati trasmessi. I pacchetti possono andare perduti
perchè scartati dai router in caso di congestione (queue overflow per lentezza
di trasmissione o per picchi di dati in input), perchè male indirizzati oppure
per colpa di errori di trasmissione.
• latenza (delay): rappresenta tutti i vari tipi di ritardi che i pacchetti subiscono
attraversando la rete. La latenza può essere espressa in vari modi, ad esempio
come latenza end-to-end, come tempo di risposta, come ritardi introdotti dalle applicazioni e come ritardi introdotti dai componenti di rete (router, hub,
switch, firewall).
• variazione di latenza (jitter): è la variazione dei ritardi che subiscono i vari
pacchetti. Per esempio, se un pacchetto impiega 100ms per attraversare la rete
da sorgente a destinazione e il successivo impiega 125ms per percorrere lo
stesso tragitto, il jitter calcolato è 25ms. Valori elevati di jitter possono causare
rimescolamento dei pacchetti ed errori di temporizzazione. Questo fenomeno
può essere causato da congestioni della rete, o da altri fattori legati alla rete
e ai tempi di risposta dei suoi componenti. Per diminuire l’influenza del jitter
sulla qualità di applicazioni che trasmettono audio o video in tempo reale
8
viene spesso utilizzato un buffer in ricezione. Questo comporta un aumento
del ritardo percepito dall’utente ed è efficace, a seconda della dimensione,
solo entro un certo range di jitter.
• affidabilità: percentuale di tempo in cui il sistema funziona senza malfunzionamenti, particolarmente importante per applicazioni mission-critical.
Solitamente viene stipulato un accordo tra utente e provider di servizi di rete sul livello di servizio, detto Service Level Agreement (SLA). In questo accordo vengono
specificati i valori che possono assumere i parametri di QoS, con l’aggiunta di altre
informazioni quali ad esempio la banda massima utilizzabile, il prezzo del servizio
e il comportamento da realizzare se i vincoli concordati non possono essere soddisfatti. Ad esempio, se le condizioni di traffico non consentono di fornire il servizio
concordato, un utente può scegliere tra diverse opzioni:
• proseguire l’applicazione in corso utilizzando la rete con prestazioni inferiori
• richiedere un servizio peggiore a livello applicativo che funzioni correttamente con le condizioni di rete (ad esempio richiedere un filmato con bitrate
minore)
• attendere che vengano rispettate le condizioni indicate nel SLA
Il livello di servizio concordato deve essere realizzato dalla rete lungo tutto il percorso, in modo da garantire un comportamento adeguato dell’applicazione che sia
soddisfacente per l’utente. Il servizio di tipo best effort offerto dalle reti IP funziona sufficientemente bene per molte applicazioni comunemente utilizzate; queste
applicazioni possono essere classificate come:
• applicazioni asincrone: per esempio l’email o il traffico HTTP, in entrambi i
casi la rete riesce solitamente a garantire prestazioni accettabili per l’utente.
• applicazioni burst: applicazioni che producono picchi istantanei nel bitrate
che variano sensibilmente rispetto al valore medio.
• applicazioni bulk: applicazioni che trasferiscono grandi quantità di dati ad una
velocità abbastanza costante, nel caso che i dati non debbano essere utilizzati
con precisi limiti temporali (ad esempio FTP).
9
Le applicazioni che invece necessitano di una specifica qualità del servizio sono
dette real time e si differenziano in soft real time e hard real time: le prime richiedono garanzie su determinati vincoli temporali ma possono anche accettare alcune
fluttuazioni delle caratteristiche di servizio senza compromettere il risultato percepito dall’utente. Le applicazioni hard real time, invece, non accettano variazioni nei
parametri della QoS.
Una descrizione più approfondita sui vincoli richiesti dai vari tipi di applicazioni
multimediali si trova nel sottoparagrafo 2.5.1.
2.2
Meccanismi per offrire QoS
Un primo elementare metodo per garantire la qualità del servizio consiste nel sovradimensionare le strutture di rete in modo da riuscire a soddisfare ogni richiesta
degli utenti; chiaramente questa è una soluzione effettivamente utilizzabile solo in
piccole reti locali a causa dei costi e del continuo sviluppo delle applicazioni e del
numero degli utenti.
Di fatto per regolare i parametri della QoS si utilizza un insieme di meccanismi
studiati per controllare a vari livelli il traffico di rete. Questi componenti base di
una architettura per la QoS si possono suddividere in tre aree: Control Plane, Data
Plane e Management Plane [2].
2.2.1
Control Plane
Riguarda i meccanismi che gestiscono il percorso attraverso il quale viaggia il
traffico degli utenti. Quest’area comprende:
• Admission control: controlla il traffico che può transitare all’interno della rete,
in modo che un nuovo flusso accettato non causi perdita di qualità al traffico
esistente. Normalmente l’admission control è guidato da un insieme di regole
concordate dal service provider con gli utenti della rete.
• QoS routing: si occupa di scegliere un percorso che soddisfi le richieste di
QoS dei flussi di traffico. Spesso si utilizzano algoritmi differenti dal tradizionale shortest path, basati su metriche che utilizzano i parametri di QoS
10
(banda, latenza, ecc.). Per realizzare questi meccanismi è necessaria la conoscenza delle richieste di QoS del flusso e delle caratteristiche di rete che
variano frequentemente. Questa conoscenza si ottiene tipicamente grazie a
protocolli di segnalazione, come Resource ReserVation Protocol (RSVP) o
estensioni di Open Shortest Path First (OSPF).
• Resource reservation: questo meccanismo prenota le risorse di rete richieste da una applicazione per garantire le prestazioni concordate. La capacità
di garantire le risorse è legata alle funzioni di admission control. Una condizione necessaria per soddisfare una richiesta di prenotazione è che ci siano sufficienti risorse di rete. Le caratteristiche del resource reservation dipendono dalle performance di rete richieste e dallo specifico approccio per
realizzare la QoS. Un esempio di protocollo per riservare risorse è il RSVP,
particolarmente usato nella architettura Integrated Service (IntServ).
2.2.2
Data Plane
Contiene i meccanismi che intervengono direttamente sul traffico degli utenti, ad
esempio modificando il modo in cui i router elaborano e inoltrano i pacchetti in
transito. Le operazioni effettuate dai router, descritte in modo molto semplice, sono le seguenti: i pacchetti ricevuti in modo sincrono o asincrono vengono messi
nelle code di input, successivamente sono elaborati secondo le operazioni di base
del protocollo IP (controllo del TTL, gestione degli indirizzi, ecc.) ed infine sono
indirizzati nella giusta coda di output per essere trasmessi. Questi processi a seconda della capacità di elaborazione, della dimensione della memoria, della velocità
di trasmissione del router introducono latenza e sono una delle principali fonti di
perdita dei pacchetti. Inoltre non c’è nessuna garanzia che i pacchetti provenienti
da una stessa sorgente vengano gestiti allo stesso modo, perciò la latenza dei vari
pacchetti tende ad essere variabile producendo jitter.
Le principali operazioni che fanno parte del Data Plane sono packet conditioning, queue scheduling e congestion control.
Per quanto riguarda il packet conditioning si usano le seguenti tecniche:
• packet classification and marking: i pacchetti vengono classificati in base ai
11
...
...
SHAPING
CLASSIFICATION
+ MARKING
POLICING
OUTPUT INTERFACE
SCHEDULING
INPUT QUEUES
OUTPUT QUEUES
CONGESTION CONTROL
Figura 2.2: Data plane all’interno di un router
parametri degli header a seconda della politica da realizzare e marcati per
essere rapidamente riconosciuti nelle successive elaborazioni. La classificazione può essere fatta esaminando i parametri a diversi livelli:
– Layer 2 (802.1Q Class of Service CoS, MAC address, MPLS experimental values)
– Layer 3 (IP precedence, DSCP, indirizzo IP sorgente/destinazione)
– Layer 4 (porte TCP o UDP)
– Layer 7 (application signatures)
I pacchetti vengono marcati in modo differente a seconda dell’architettura
utilizzata (Diffsev, Intserv, ecc.). Ogni architettura definisce infatti un campo
o un significato specifico ad un campo esistente in un header. I nodi interni di
rete classificano i pacchetti analizzando solamente questo campo.
• packet prioritization: i pacchetti vengono serviti con più o meno priorità a
seconda del “marchio” che hanno ricevuto. Per esempio gli algoritmi di scheduling nei router possono decidere il successivo pacchetto da analizzare in
base alla priorità assegnata.
• traffic shaping: i flussi di dati vengono modellati in modo da filtrare eventuali
picchi limitando la banda disponibile per i vari profili. Il traffico out-of-profile
(che eccede i limiti fissati) viene gestito a seconda del sistema e della politica utilizzata. Per effettuare questa operazione solitamente i sistemi di QoS
utilizzano uno schema token-bucket. Lo schema token-bucket viene utilizzato per controllare le caratteristiche principali dei flussi di pacchetti come la
12
velocità media, i picchi istantanei di velocià ed i burst (numero di pacchetti che temporaneamente possono essere inviati nonostante venga superato il
limite massimo di banda utilizzabile). Il funzionamento di un semplice filtro
token-bucket (TBF) è il seguente (figura 2.3):
– i token che rappresentano i “crediti” sono generati ad una velocità predefinita “r”
– i token sono accumulati in un bucket (cestino) fino ad un limite fissato
“b” che rappresenta la dimensione del bucket
– i pacchetti che arrivano alla velocità media “p” hanno accesso alla rete
grazie ai crediti disponibili nel cestino
– i pacchetti subiscono un comportamento definito dall’amministratore se
non sono disponibili crediti nel cestino (out-of-band). Ad esempio questi pacchetti possono essere eliminati oppure indirizzati in un’apposita
coda di output.
Token generation
rate (r)
Bucket
size (b)
Bucket
Packet
Network
Packet size (m)
out−of−band packet
Figura 2.3: Filtro Token Bucket
Il valore “r” rappresenta quindi la velocità media prevista per il flusso. La
dimensione del cestino rappresenta la variazione possibile rispetto alla velo13
cità media, ossia il numero massimo di pacchetti che possono essere inoltrati
istantaneamente al di sopra del rate fissato. I pacchetti consumano un numero
differente di crediti in proporzione alla loro dimensione.
• policing: applicazione di un insieme di regole che devono essere rispettate
relativamente al servizio. In base a queste regole (ad esempio gli accordi definiti in un SLA) vengono decise le azioni da compiere sui pacchetti come, ad
esempio, scartare quelli che sono oltre il limite di banda fissato.
Per migliorare le prestazioni per quanto riguarda latenza e jitter si è possibile intervenire sulla dimensione dei pacchetti in modo da evitare che pacchetti di grosse
dimensioni e bassa priorità siano causa ritardi eccessivi al traffico prioritario.
Il queue scheduling rappresenta un insieme di algoritmi e meccanismi usati per
controllare il trasferimento dei pacchetti dalle code di input a quelle di output nei
router. Gli obiettivi sono quelli di condividere la banda in modo equo evitando la
starvation di alcuni utenti, garantire i parametri di QoS come banda e latenza se
specificati e ridurre i jitter. Gli algoritmi usati più frequentemente per realizzare
questi obiettivi sono:
• First-In First-Out (FIFO): la coda più semplice, il primo arrivato è il primo ad
uscire. Tutti i pacchetti ricevono lo stesso trattamento. Funziona bene grazie
alla sua semplicità in assenza di congestioni.
• Priority Queuing (PQ): ci sono “n” code alle quali è associata una priorità
relativa. I pacchetti con priorità maggiore vengono serviti prima. I pacchetti
in una coda vengono serviti solo se le code a priorità maggiore sono vuote.
Causa problemi di starvation.
• Round Robin (RR) e Weighted Round Robin (WRR): sono presenti varie code.
L’algoritmo base serve in ordine tutte le code, un pacchetto per volta. Nella
versione weighted è possibile specificare il numero di pacchetti serviti per
le singole code ad ogni turno. Garantisce priorità e non provoca starvation.
Non viene considerata la dimensione dei pacchetti, quindi possono verificarsi
lunghe attese per pacchetti di piccole dimensioni. Non può quindi garantire
limiti di banda o latenza.
14
• Weighted-Fair Queuing (WFQ): è un algoritmo complesso pensato per fornire
imparzialità e per evitare la starvation, offrendo una priorità prefissata ai vari
flussi.
• Class-Based Queuing (CBQ): consente di suddividere il traffico in varie classi, ognuna delle quali può gestire il traffico in modo autonomo tramite code
interne.
Esistono anche altri metodi di gestione delle code, ad esempio variazioni agli algoritmi indicati, realizzazioni proprietarie di soluzioni generiche e nuove soluzioni
che non sono generalmente presenti nei router.
Il congestion control è l’insieme dei meccanismi usati per prevenire ed eliminare
le congestioni nelle reti. Vi sono tecniche reattive che tendono a diminuire l’intensità del traffico che attraversa la rete, e tecniche proattive che cercano di evitare il
formarsi di congestioni. I principali approcci al problema sono:
• Tail Drop: vengono eliminati i pacchetti ricevuti se la coda di output è piena.
• Random Early Detection (RED): i pacchetti vengono scartati con una data
probabilità in modo da evitare la formazione di congestioni. Quando le code
sono lontane dalla saturazione e si è quindi in condizioni di traffico sostenibile dalla rete nessun pacchetto viene scartato. Se il numero di pacchetti in
coda supera una soglia specificata il meccanismo RED comincia a scartare
alcuni pacchetti in modo casuale; la probabilità che hanno i pacchetti di essere scartati aumenta con la percentuale di riempimento della coda, arrivando a
scartare tutti i pacchetti in arrivo quando il buffer è pieno.
• Explicit Congestion Notification (ECN): i router notificano la congestione
esplicitamente ad un ECN-capable end-system invece di segnalarla scartando
semplicemente dei pacchetti.
Per realizzare soluzioni che garantiscano la qualità del servizio sono state proposte varie architetture. In particolare l’Internet Engineering Task Force (IETF) ha
ideato le proposte che più hanno influito nell’evoluzione delle reti IP. I due principali
approcci di gestione dei pacchetti sono i seguenti:
15
• flow-based packet processing: per flusso (flow) si intende in genere una trasmissione unidirezionale di dati fra due applicazioni identificata tipicamente
dagli indirizzi IP e porte (sorgente/destinazione) oppure da un identificatore
di flusso; questo identificatore è utilizzato, ad esempio, nella soluzione proposta da IPv6 e nel RSVP nell’architettura IntServ.
Utilizzando il concetto di flusso si riescono a suddividere in modo capillare
i vari pacchetti che attraversano una rete. Secondo questo approccio i pacchetti vengono elaborati per ottenere la QoS in modo diverso in base al flusso
di appartenenza. Questa capillarità porta a problemi di scalabilità nel caso di
grosse reti con molti utenti, sia a causa dell’aumento dell’elaborazione richiesta, sia per il numero delle informazioni che bisogna memorizzare per ogni
flusso. Il concetto di flusso, che ricorda il concetto di “chiamata” nelle linee
telefoniche, si scontra con la natura connectionless del protocollo IP.
• class-based packet processing: i flussi possono essere raggruppati insieme utilizzando in modo incrociato differenti caratteristiche come ad esempio la rete
di origine e qualsiasi altra informazione contenuta nell’intestazione IP. Grazie
a questi classificatori si possono ottenere aggregati di traffico che raggruppano in una classe flussi differenti ma che hanno in comune qualche attributo
identificativo. “Aggregato” e “classe” sono i termini che identificano questa
soluzione. I pacchetti vengono elaborati nei nodi di rete a seconda della classe
di apparteneza, non più in modo individuale come avviene nel caso precedentemente illustrato.
Il metodo Class-based scala bene con l’aumetare dei nodi e degli utenti e richiede la memorizzazione di poche informazioni. Considerando flussi aggregati si riduce l’analisi dell’header dei pacchetti diminuendo quindi l’overhead
introdotto dai router. Un altro vantaggio è quello di semplificare la gestione
e la realizzazione delle politiche da parte dell’amministratore, dovendo considerare solamente poche classi di servizio. Il principale inconveniente è invece la scarsa personalizzazione del servizio possibile. Questo approccio è
realizzato dalla architettura Differentiated Service (DiffServ).
16
2.2.3
Management Plane
Fanno parte di quest’area i meccanismi che riguardano gli aspetti di gestione e di
amministrazione degli traffico. Appartengono a questo insieme:
• Metering: monitorare le caratteristiche variabili di un flusso di dati (ad esempio la velocità di traferimento) in modo che rientrino nel profilo concordato. Uno strumento che esegue questa funzione può richiedere un trattamento
particolare per il traffico monitorato (ad esempio shaping o dropping).
• Service Level Agreement (SLA): un SLA è l’accordo tra un cliente ed il suo
fornitore di servizi, nel quale sono indicati il livello di affidabilità, di prestazioni e altri attributi del servizio. Può includere anche aspetti di natura economica come le tariffe. Nella parte tecnica vengono specificati i parametri di
traffico specifici utilizzati dall’architettura che gestisce la QoS nel dominio.
• Traffic Restoration: è la capacità della rete di funzionare in condizioni di
guasti ed errori. Gli errori possono verificarsi a livello di nodi di rete o di
connessione fra due nodi.
2.3
Differentiated Services
In questo tesi è stato scelto il modello DiffServ per fornire qualità del servizio,
preferendolo a quello IntServ perchè maggiormente scalabile, come spiegato precedentemente. L’idea fondamentale di questa modello è di ridurre la complessità nei
nodi centrali della rete che devono trattare un numero enorme di dati. Un piccolo
insieme di primitive per l’invio differenziato dei pacchetti può essere composto per
creare un vasto insieme di caratteristiche di QoS. I nodi centrali della rete devono
gestire solamente questo piccolo insieme di primitive.
Il modello DiffServ evidenzia come sia possibile offrire un servizio di QoS attraverso la configurazione statica dei nodi centrali della rete. Vengono tenute separate
le funzionalità di elaborazione dei pacchetti e di configurazione dei parametri di
QoS nei router centrali: la classificazione dei pacchetti avviene alla velocità con
cui viaggiano nella rete, mentre la configurazione delle primitive utilizzate dai core
17
router avviene su una scala temporale molto più lunga. Solitamente la riconfigurazione dei router centrali viene effettuata solamente nel caso di cambiamento delle
politiche generali del dominio oppure quando viene modificata la struttura della rete
(cambiamento della topologia o dell’hardware utilizzato). La riconfigurazione degli edge router deve avvenire, invece, quando viene concesso ad un utente di far
transitare i suoi dati all’interno del dominio.
Un altro grande vantaggio dell’approccio DiffServ è che si applica bene all’architettura di internet e può essere realizzato in modo minimalista, aggiungendo
complessità solo quando serve. All’interno di una rete è possibile utilizzare i Differentiated Services solo nei punti critici, dove il canale di comunicazione presenta
un collo di bottiglia.
2.3.1
QoS end-to-end basata su domini amministrativi
Nel modello DiffServ l’entità di base che garantisce il livello di servizio è il dominio
amministrativo di un unico operatore di rete.
Un dominio amministrativo può essere individuato sia in una rete aziendale o in un
singolo ISP (Internet Service Provider). Il modello è orientato verso un servizio di
tipo edge-to-edge attraverso ogni singolo dominio, in accordo con quanto definito
negli Service Level Agreement (SLA) stipulati con i propri clienti.
I clienti di un dominio possono essere ad esempio gli utenti serviti da un ISP
oppure i gestori dei domini adiacenti. Stipulando accordi tra domini adiacenti è
possibile creare una struttura complessa in grado di garantire la QOS attraverso una
rete non omogenea nella gestione amministrativa.
Nella versione più semplice l’architettura DiffServ prevede l’allocazione statica
delle risorse. Quando viene stipulato un SLA tra cliente e fornitore, vengono staticamente assegnate le risorse al cliente nel periodo indicato nell’accordo. Il cliente
avrà a disposizione le risorse senza bisogno di effettuare ulteriori richieste. In questo modo devono essere riconfigurate le risorse solo quando scadono i termini del
contratto o quando ne viene accordato uno nuovo. La configurazione statica pone
dei limiti sul numero di clienti che possono utilizzare le risorse e sull’efficienza del
loro utilizzo. L’allocazione statica delle risorse può essere vista come uno spreco di
risorse (pagare per delle risorse che non vengono usate) oppure come il privilegio
18
di poter utilizzare un servizio che è sempre disponibile, in qualunque momento lo si
voglia utilizzare. Nel caso in cui la somma delle risorse assegnate ai clienti tramite
gli SLA ecceda la capacità del sistema è necessario un protocollo di segnalazione
per richiedere l’allocazione effettiva della QoS concordata. In questo caso l’allocazione delle risorse è detta dinamica. Nella allocazione dinamica un meccanismo di
control plane deve effettuare un controllo sulla possibilità di soddisfare o meno la
richiesta. Per far questo è necessaria una segnalazione dei parametri di QoS, che
può essere effettuata in due modalità:
• in band: la segnalazione è codificata all’interno del flusso interessato, tipicamente all’interno di particolari campi nell’header IP (TOS). In questo modo
non viene introdotto ulteriore traffico e non vengono aggiunti ritardi per la
messa a punto.
• out of band: la segnalazione è trasportata da appositi pacchetti separatamente
dal traffico interessato dalla QoS. Viene introdotto perciò del traffico extra in
rete. In questo modo è possibile richiedere la prenotazione di risorse.
Se viene negata la QoS, l’utente può decidere di riprovare successivamente, di riprovare subito chiedendo meno risorse oppure di utilizzare subito la rete con servizio
best effort.
In ambiente multidominio, nel caso di configurazione dinamica, per poter soddisfare una richiesta di allocazione è necessario che tutti i domini interessati abbiano
sufficiente disponibilità di risorse. Per fare questo serve un protocolo di comunicazione tra i gestori dei vari domini. Il cliente chiede l’allocazione di risorse in accordo
con l’SLA al dominio di accesso ai servizi, il quale dovrà conoscere il successivo
dominio nel percorso verso l’altro end point e inoltrare la richiesta in accordo con
l’SLA stipulato tra i due amministratori. Per poter comunicare al cliente l’accettazione della sua richiesta il gestore del dominio deve attendere la risposta alla richiesta che ha effettuato al successivo. Il nuovo dominio contattato dovrà effettuare la
stessa cosa fino a che non viene raggiunto l’altro interlocutore della comunicazione
oppure quando un dominio nega l’allocazione. Per poter realizzare questo meccanismo è necessario che la catena di domini interessati da una comunicazione sia nota
e fissata. Al contrario il percorso che i dati effettueranno all’interno di un singolo
dominio non deve essere né noto né fissato.
19
L’architettura DiffServ offre la possibilità ai gestori di fornire ad ogni cliente una
gamma di servizi di rete con prestazioni (e costi) differenti associati ai vari aggregati
di traffico (TA). Il trattamento che un TA (o un insieme di TA) deve ricevere da un
bordo all’altro di un domino Diffserv è detto Per Domain Behaviour (PDB) [11].
Componendo i vari PDB che intervengono tra sorgente e destinazione si riesce a
stimare la QoS end-to-end che sarà applicata al traffico di dati.
2.3.2
Controllo del flusso all’interno di un dominio
I router che compongono un dominio vengono suddivisi in
• edge router: nodi di confine che separano due domini distinti
• leaf router: nodi che collegano un cliente al dominio
• core router: nodi centrali della rete che sono connessi esclusivamente ad altri
nodi appartenenti allo stesso dominio
Quando i pacchetti entrano in un dominio DiffDerv vengono collocati nelle varie
classi di servizio marcando il diffserv code point (DSCP), che corrisponde ai primi
sei bit del campo TOS nell’header IPv4 [12] (figura 2.4).
Layer 3 IPV4
Version
Length
ToS
1 Byte
7
6
LEN
5
ID
4
Offset
3
TTL
2
IP precedence
Proto
1
FCS
IP−SA
IP−DA
Data
0
bit non usati
DSCP
Figura 2.4: DSCP nell’header IPv4
La marcatura del DSCP può essere operata da vari componenti:
• dall’host (può essere un problema lasciare all’utente la scelta della classe di
servizio da associare al proprio traffico);
20
• dal primo router incontrato dopo l’host;
• da particolari componenti, ad esempio un VoIP gateway.
Alcuni software impostano direttamente il TOS, ad esempio il traffico generato dall’ssh è marcato con il valore 0x10. Il DSCP viene utilizzato per determinare il trattamento dei pacchetti nei nodi interni della rete. In questo modo i router centrali
non hanno problemi di scalabilità dovendo gestire solamente un piccolo insieme di
comportamenti diversi, uno per ogni classe di servizio.
Gli edge router (sia di ingresso che di uscita) ed i leaf router svolgono le seguenti funzioni: classifying, monitoring, marking, shaping/dropping (figura 2.5). I
core router invece effettuano behaviour classification e scheduling (figura 2.6) in
modo class-based.
Le operazioni più costose che implicano elaborazione flow-based vengono quindi eseguite nei router ai margini della rete; i leaf e gli edge router sono in grado di
gestire questa complessità visto che devono elaborare solamente una porzione del
traffico totale che attraversa il dominio. Una descrizione dettagliata del modello di
gestione dei router DiffServ si può trovare in [13].
METER
CLASSIFIER
MARKER
SHAPER/DROPPER
Forward
Figura 2.5: Schema logico di un Edge Router
Ad ogni valore del DSCP corrisponde un trattamento specifico da parte dei nodi
centrali, detto Per-Hop Behaviour (PHB). I vari nodi di rete cooperano attraverso
i propri PHB per realizzare il PDB osservabile dall’esterno. All’interno dell’IETF
esiste un gruppo di lavoro dedicato al modello DiffServ che ha deciso di standardizzare pochi fondamentali PHB. Questi PHB possono essere realizzati utilizzando
una grande varietà di meccanismi. I PHB standard sono:
21
Core Router
Per Hop Behaviour
(Behaviour classification
Scheduling)
Border Router (Ingress)
Classifying
Marking
Monitoring
Shaping/Dropping
Border Router (Egress)
Classifying
Marking
Monitoring
Shaping/Dropping
CR
BR
Traffico
Dati
vengono combinati
i flussi appartenenti allo stesso
TA che attraversano il dominio
BR
Figura 2.6: Schema di un dominio Diffserv
• Default behaviour: il DSCP è zero, viene fornito un servizio comparabile all’attuale servizio Internet di tipo best effort (congestioni e perdita di pacchetti
completamente fuori controllo).
• Class selector behaviours: si hanno sette possibili valori del DSCP, che vanno
da 00100 a 111000, per specificare sette possibili comportamenti con crescente probabilità di essere inoltrati prima rispetto alle classi precedenti. Si può
notare che l’utilizzo di queste classi in aggiunta al Default behaviour rispecchia esattamente il meccanismo realizzato dall’IP Precedence (illustrato nel
paragrafo 2.1.1).
• Expedited Forwarding Behaviour (EF) [14]: viene raccomandato il DSCP di
valore 101110 e come comportamento è previsto un bitrate minimo garantito
configurabile in uscita dal dispositivo. L’EF è pensato per i servizi che necessitano di un servizio di rete con caratteristiche minime garantite, come ad
esempio servizi real-time con un throughput configurabile.
Dal punto di vista dell’utente, l’EF assicura una banda minima con bassa latenza, basso jitter e poca perdita. In altre parole questo modello di servizio
emula una linea dedicata. È consigliato di allocare per questo servizio solo
una piccola percentuale della capacità totale della rete.
• Assured Forwarding Behaviours (AF) [15]: questo PHB è suggerito per applicazioni che richiedono una affidabilità maggiore rispetto al servizio best
22
effort, senza però stretti vincoli sui parametri della QoS. Una classe AF è
composta da quattro sotto-classi chiamate AF1, AF2, AF3 e AF4. Queste
classi sono indipendenti, ossia ognuna ha la proprie risorse di rete nei nodi
Diffserv.
Le classi hanno priorità crescente da AF1 a AF4. All’interno di ogni classe si
trova una ulteriore suddivisione data da tre Drop Precedence, che indicano la
probabilità per un pacchetto di essere scartato in caso di congestione. In questo modo si ottengono 12 differenti classi AF indicate con la notazione AFIJ
che rappresenta un PHB di tipo AF classe “I” con Drop Precedence “J”.
In un dominio DiffServ tutti i nodi centrali devono offrire lo stesso insieme di PHB.
I router ai margini devono classificare il traffico nelle classi disponibili a seconda
degli SLA stipulati col cliente, eventualmente scartando o riclassificando i pacchetti
che non rientrano nei parametri concordati. Ad esempio, se un flusso arriva all’ingresso della rete con una banda superiore a quella consentita, la parte che eccede
tale limite può venire inserita in una classe di servizio peggiore [16] [17]. In altri
casi, invece, la politica adottata prevede di scartare il traffico in eccesso.
In [18] è proposto un Policy Information Base per un dispositivo Diffserv, ovvero un insieme di dati che devono essere memorizzati e scambiati tra le varie entità di
una architettura Diffserv. Nel modello sono previste alcune entità che si occupano
di operare le decisioni sulle politiche detti Policy Decision Point (PDP) ed altre che
mettono in pratica quanto deliberato chiamate Policy Enforcement Point (PEP).
2.4
Bandwidth Broker
I meccanismi di gestione della QoS forniti dal modello DiffServ consentono di proteggere le classi di servizio più importanti da quelle che hanno meno priorità. Il controllo d’accesso è utilizzato per garantire che una comunicazione non sia in conflitto
con altre appartenenti allo stesso aggregato di traffico, impedendo l’inserimento in
una classe di servizio di una quantità di traffico superiore a quella sostenibile da
parte della rete.
In un contesto di allocazione dinamica delle risorse, le funzioni di admission
control, di resource reservation e di configurazione del sistema sono realizzate da
23
agenti software. In particolare è stata studiata, per svolgere queste funzioni, una
entità detta Bandwidth Broker (BB) [7]. I BB possono essere considerati dei PDP,
mentre i router sono dei PEP.
BB 2
BB 1
BB 3
Edge
Router
Edge
Router
Edge
Router
Edge
Router
Leaf
Router
Edge
Router
Leaf
Router
Dominio
Diffserv #2
Edge
Router
Host
Dominio
Diffserv #1
Host
COMUNICAZIONE CON L’UTENTE
Dominio
Diffserv #3
COMUNICAZIONE INTRA−DOMINIO
COMUNICAZIONE INTER−DOMINIO
Figura 2.7: BB in uno schema multidominio
L’interazione tra il BB e gli altri componenti nell’architettura Diffserv è la
seguente:
1. quando un flusso deve entrare in un dominio Diffserv o un utente locale vuole
inviare dei dati, deve essere segnalata al BB la richiesta di allocazione, detta
Resource Allocation Request (RAR), contenente il riferimento ad un SLA
2. il BB deve controllare l’autenticità dell’SLA e, in base alle specifiche indicate, verificare la disponibilità di risorse (deve avere una conoscenza precisa e
aggiornata sulla topologia e sulle condizioni di rete)
3. se il flusso di dati, per raggiungere il secondo end-point della comunicazione,
attraversa altri domini, il BB deve negoziare l’allocazione di risorse con il
24
dominio vicino. Questo meccanismo deve essere ripetuto fino a raggiungere
il dominio a cui è collegato l’interlocutore della comunicazione
4. il BB deve decidere se la richiesta può essere soddisfatta in base alle informazioni ottenute nei punti precedenti e comunicare la decisione al richiedente
5. se la richiesta è stata accettata il BB deve riconfigurare opportunamente l’edge
router o il leaf router che fornisce la connessione tra l’utente e il dominio.
Un BB è composto da alcuni componenti fondamentali classificati nel seguente
modo:
• Base di dati
– Tabelle di routing
– Deposito di dati (SLA, politiche, allocazione corrente, ecc.)
• Protocolli di comunicazione
– Interfaccia utente/applicazione
– Protocollo di comunicazione inter domain
– Protocollo di comunicazione intra domain
2.4.1
Base di dati
Il BB deve mantenere una base di dati contenente tutti gli elementi relativi alla gestione del dominio. È necessario memorizzare le tabelle di routing per avere una mappa topologica completa del dominio gestito. Le informazioni che deve
conoscere sono:
• il router di ingresso e di uscita per ogni flusso che attraversa il dominio;
• il dominio successivo nel percorso del flusso verso la destinazione, se questa
si trova in un altro dominio;
• il primo leaf router nel caso in cui la richiesta è generata da un cliente all’interno del dominio.
25
Il modo migliore per ottenere informazioni aggiornate è fornire al BB un protocollo intra-dominio che gli permetta di comunicare con gli altri componenti di
rete.
Oltre alle informazioni relative alla topologia della rete, il BB deve mantenere
i dati che riguardano le politiche, gli accordi SLA, la gestione della rete e l’allocazione corrente delle risorse. Devono inoltre essere memorizzare le informazioni
relative alla configurazione dei router e dei componenti propri del BB per poter intervenire in caso di errori. Un Policy Information Base (PIB) può essere utilizzato
per la gestione delle informazioni relative alle politiche. La descrizione di un PIB
per una architettura DiffServ si può trovare in [18].
2.4.2
Protocolli di comunicazione
Per eseguire le sue complesse funzioni il BB necessita di un insieme di protocolli
di comunicazione per interagire con i diversi componenti del dominio DiffServ. Per
prima cosa c’è bisogno di un protocollo o di una interfaccia per comunicare con
l’operatore di rete e con gli utenti (o le applicazioni degli utenti). L’amministratore
di rete interagisce con il BB per controllarne o aggiornarne la caratteristiche di
funzionamento. Gli utenti invece necessitano di comunicare con il BB per richiedere
l’allocazione delle risorse e per conoscere la risposta a tale richiesta.
Il protocollo di comunicazione intra-dominio è utilizzato per la gestione dei
nodi di rete. In generale il protocollo intra dominio deve poter trasferire i parametri di configurazione dal BB ai PEP (gli edge router). Ogni router possiede un
meccanismo di configurazione predisposto dal costruttore; in particolare i meccanismi più diffusi sono Common Open Policy Services (COPS) [19], Simple Network Management Protocol (SNMP) [20] e Telnet, anche se non tutti i dispositivi li
supportano.
La comunicazione inter-dominio serve per far interagire due BB di domini adiacenti. I BB devono comunicare tra loro per realizzare la QoS end-to-end a partire
dalle prestazioni edge-to-edge offerte dai singoli domini. Non è stato ancora definito
un singolo protocollo che possieda tutte le caratteristiche necessarie per il livello di
comunicazione inter-dominio. L’Internet2 QBone BB Advisory Council ha proposto
in [21] il Simple Inter domain Bandwidth Broker Signalling (SIBBS).
26
2.5
QoS per applicazioni multimediali in reti eterogenee
Solo recentemente è stata superata la convinzione diffusa che la QoS non è fondamentale in una rete dove la banda è abbondante, come ad esempio nel caso di un
campus universitario. Realizzando applicazioni come IP Telephony, video conferenza e applicazioni mission-critical è diventato evidente che anche la gestione dei
buffer di comunicazione necessita di particolare attenzione.
2.5.1 Caratteristiche delle applicazioni multimediali
I vari tipi di applicazioni multimediali necessitano di prestazioni di rete differenti.
Ad ogni applicazione che richiede QoS deve essere assegnata una classe di servizio
che definisce la priorità relativa rispetto alle altre applicazioni. Il criterio di ordinamento si deve basare in parte sulle caratteristiche intrinseche del tipo di trasmissione
e in parte sulle politiche dell’organizzazione che utilizza il servizio. Ad esempio il
servizio Voice over IP (VoIP) ha delle necessità di QoS oggettivamente superiori allo streaming video, mentre per quanto rigurda i dati trasferiti da applicazioni
varie l’ordinamento deve essere scelto in modo soggettivo a seconda dell’organizzazione. Le caratteristiche intrinseche del traffico che devono essere considerate per
effettuare la classificazione delle applicazioni sono:
• perdita di pacchetti tollerata;
• latenza tollerata;
• variazione di latenza tollerata;
• pattern di traffico (variabilità della banda, dimensione dei pacchetti, ecc.).
È controproducente utilizzare troppe classi distinte per il traffico dei dati, perchè
rende meno evidente la distinzione del livello di servizio tra le classi. La suddivisione in classi offerta dai PHB standard del modello DiffServ consente di avere una
servizio “premium” identificato dalla classe EF, un servizio normale BE e quattro
classi intermedie AF. L’efficienza della QoS viene compromessa anche assegnando
27
ad un unica classe troppe applicazioni. Nel caso estremo in cui tutte le applicazioni utilizzano il servizio migliore si ottiene lo stesso risultato ottenibile senza QoS
(tutto il traffico viene trattato allo stesso modo secondo lo schema FIFO).
Un esempio di classificazione delle applicazioni, indicato in ordine di priorità
decrescente, è il seguente:
• Mission-Critical: applicazioni per l’Enterprise Resource Planning (ERP), transazionali, ecc.
• Banda Garantita: streaming video, messaging, Intranet
• Best-Effort (default): Internet browsing, E-Mail
• Traffico in Background (priorità minima, massima probabilità di drop): FTP,
backup, applicazioni Peer-to-Peer (P2P)
Vengono di seguito presentate le caratteristiche di traffico delle principali applicazioni multimediali e la loro classificazione suggerita in letteratura [22].
Voice over IP
Il traffico che trasporta un segnale vocale necessita di:
• perdita di pacchetti inferiore al 1%;
• latenza inferiore a 150-200 ms;
• jitter medio inferiore a 30 ms;
• banda prioritaria tra 21 kbps e 100 kbps a seconda della codifica e del campionamento;
• 150 bps di banda garantita per i segnali di controllo.
Per il traffico VoIP è raccomandato il PHB EF (DSCP 46), corrispondente al valore
5 di IP Precedence e CoS per mantenere la retrocompatibilità con i vecchi sistemi
di QoS. Per i segnali di controllo del traffico vocale è raccomandato il PHB AF31
(DSCP 26, IP Precedence 3, CoS 3).
28
Videoconferenza
Il traffico generato da applicazioni di videoconferenza richiede le stesse prestazioni
del VoIP per quanto riguarda la perdita di pacchetti, la latenza e la variazione di
latenza, ma ha un pattern di traffico completamente differente. Il traffico di videoconferenza ha infatti dimensione e rate dei pacchetti molto variabile. La banda prioritaria da allocare per questo tipo di traffico deve essere superiore del 20% rispetto
al bitrate nominale della sessione. Ad esempio una sessione di videoconferenza da
384 kbps richiede l’allocazione di 460 kbps di banda garantita e un parametro di
burst impostato a 30000 byte. È consigliato l’utilizzo del PHB AF41 (DSCP 34, IP
Precedence 4, CoS 4).
Video streaming
Le applicazioni di streaming video hanno richieste di QoS meno rigide, infatti la
latenza non comporta grossi problemi visto che può essere tollerato un tempo di
attesa iniziale di alcuni secondi e il jitter può essere compensato tramite buffering.
Il range accettabile per i parametri di QoS è il seguente:
• perdita di pacchetti inferiore al 2%;
• latenza inferiore a 4-5 secondi;
• il valore del jitter non è particolarmente significante.
Lo streaming video può essere utilizzato per applicazioni di intrattenimento oppure
per contenuti più importanti come nel caso dell’E-Learnig. Per questo tipo di applicazioni è consigliato l’utilizzo di una classe di servizio di priorità medio-bassa,
come ad esempio il PHB AF13 (DSCP 14, IP Precedence 1, CoS 1).
2.5.2
Gestione dell’infrastruttura di rete
In figura 2.8 sono illustrate le aree nelle quali sono richiesti meccanismi di QoS.
I punti di accesso della rete devono classificare il traffico prodotto o inoltrato secondo i meccanismi previsti per il livello 2 o 3. Possono essere presenti molteplici
code. L’amministrazione del dominio deve potersi fidare di questi nodi di confine
29
Edificio 1
Edificio 2
Accesso
Accesso
WAN
Distribuzione
Collegamento
WAN
Collegamento
WAN
Accesso
Accesso
Accesso
Figura 2.8: Componenti di QoS nella rete di un campus
visto che la gestione interna del traffico si basa sulla loro classificazione. Può essere
effettuato in questi nodi anche il controllo d’accesso.
I nodi centrali di distribuzione hanno diverse code per le varie classi di traffico e utilizzano la classificazione effettuata ai margini della rete per l’inserimento
nelle code. Possono essere utilizzate tabelle di conversione tra i vari meccanismi di
marcamento. Nelle reti locali la latenza dovuta all’inserimento in modo seriale da
parte delle interfacce LAN sul mezzo fisico è trascurabile, ossia non incide in modo
significativo sul comportamento delle applicazioni sensibili ai ritardi. Nella realizzazione dei sistemi di accesso e distribuzione si deve fare più attenzione al jitter,
che può effettivamente peggiorare la qualità di voce e video. Il problema principale è comunque rappresentato dalle congestioni nei buffer di trasmissione. Questo
problema viene generalmente affrontato separando in varie code gli aggregati di
traffico.
I nodi che collegano le reti locali alle Wide Area Network (WAN) devono avere
code a bassa latenza e devono offrire servizi di controllo d’accesso, modellazione
30
del traffico secondo profili prestabiliti e frammentazione dei pachetti. La frammentazione dei pacchetti può servire per ridurre la latenza e il jitter dei pacchetti ad alta
priorità, in presenza di pacchetti di grandi dimensioni e bassa priorità.
Ogni edificio può essere visto come un dominio DiffServ, nel quale i nodi di
distribuzione rappresentano i core router mentre i punti d’accesso e i nodi di collegamento WAN possono essere identificati come edge router con differenti caratteristiche.
In alcuni casi ci si trova nella condizione di utilizzare nodi di rete di terze parti
che non supportano meccanismi di QoS. In queste situazioni si può solamente elaborare il traffico a monte del dispositivo in questione, limitando la banda secondo le
caratteristiche di trasmissione garantite dal tratto seguente ed eseguendo frammentazione, interleaving e ordinamento per salvaguardare i dati prioritari. È importante
che il dispositivo di terze parti riesca ad inoltrare tutto il traffico ricevuto, per evitare che vengano scartati pacchetti senza distinzione di classe. Il meccanismo FIFO
presente in un dispositivo che non supporta la QoS preserva il corretto ordinamento
assegnato dal nodo appositamente inserito.
31
Capitolo 3
Qualità del servizio su reti wireless
Le tecnologie per la comunicazione “senza fili” (Wireless) si stanno diffondendo rapidamente in tutto il mondo. Esse sono utilizzate sia per realizzare reti locali (LAN)
di computer mobili, sia per la comunicazione tra dispositivi di uso comune come
telefoni, macchine fotografiche, ecc.
Le reti locali senza fili sono dette Wireless Local Area Network (WLAN) e vengono
utilizzate per fornire connetivitá ad utenti mobili con prestazioni paragonabili alle
soluzioni broadband via cavo che si trovano sul mercato. Le principali tecnologie
wireless si basano sulle specifiche del protocollo IEEE 802.11.
3.1
Il protocollo IEEE 802.11
Nel 1990 venne costituito il primo gruppo di lavoro 802.11 dedicato allo sviluppo di
uno standard per reti wireless, che venne approvato dall’IEEE sette anni dopo. Parallelamente l’IEEE costituì diversi gruppi di lavoro dedicati allo sviluppo di nuove
funzionalità da aggiungere allo standard di base.
802.11a È lo standard di trasmissione ad alta velocità (54 Mbit al secondo) sulla frequenza 5 GHz. I problemi legati a questa specifica non sono pochi, ad
esempio non è prevista alcuna compatibilità con 802.11b, che era già molto diffuso al momento dell’approvazione di 802.11a. Alcuni produttori hanno sviluppato tecnologie per rendere interoperabili i due standard, anche se
questa linea di prodotti non ha coinvolto i consumatori. Questo contrasto ha
32
Capitolo 3. Qualità del servizio su reti wireless
sicuramente influenzato negativamente lo standard 802.11a, che, lavorando
sulla frequenza 5 GHz, eviterebbe eventuali interferenze con forni microonde
o dispositivi Bluetooth e permetterebbe una trasmissione con meno disturbi.
802.11b È attualmente lo standard piú diffuso, consente trasmissioni a 11 Mbit al
secondo sulla frequenza di 2,4 GHz. Dal momento che è ormai diffuso con
una certa capillarità sul territorio mondiale (soprattutto USA, Europa e Giappone) il WECA e l’ IEEE stanno rivolgendo i loro sforzi principalmente sulla
realizzazione di standard ad esso compatibili, come 802.11g, ormai pronto ad
arrivare sul mercato. Alcuni produttori hanno sviluppato una tecnologia proprietaria chiamata 802.11b+, che comunque non è certificata dall’IEEE e che
permette di trasmettere fino a 22 Mbps.
802.11c/d Sono stati raccolti questi due gruppi di lavoro perché il primo è stato
sospeso e si è poi unito al secondo; i lavori sono ancora in corso e mirano alla
definizione di un livello fisico utilizzabile in qualsiasi paese.
802.11e Anche questo gruppo di lavoro, che si occupa della QoS, non ha completato le proprie attività. Sta lavorando sul livello MAC per aggiungere funzionalità multimediali alla tecnologia 802.11. Una volta approvato questo standard
riguarderà tutte le specifiche di trasmissione (802.11a/b/g) e permetterà di
sfruttare il wireless anche all’interno di apparecchi multimediali.
802.11f È stato già completamente implementato ed è solo in attesa dell’approvazione dell’IEEE, definisce le specifiche, a livello MAC, per la realizzazione
di sistemi wireless distribuiti e, piú in generale, per le attività di roaming.
La realizzazione del protocollo IAPP (Inter Access Point Protocol), su cui la
specifica si basa, è stata sostenuta da diversi produttori tra cui Lucent e Cisco.
802.11g È l’ultimo gruppo costituito per la definizione di nuovi parametri di trasmissione sulla frequenza 2,4 GHz. Attualmente si stanno svolgendo i test e
prodotti compatibili a questa specifica dovrebbero essere presto sul mercato
(anche se alcuni produttori hanno deciso di lanciare dispositivi basandosi su
una draft della specifica). Questo standard, che sarà totalmente compatibile
con 802.11b, è capace di trasmettere fino a 54 Mbps utilizzando la stessa tecnica di modulazione di 802.11a. Come già detto le trasmissioni su 2,4 GHz
33
sono ad alto rischio di interferenza, per questo si pensa che 802.11g sia uno
standard di transito verso una futura specifica che permetterà di migrare sulla
piú sicura e versatile frequenza dei 5 GHz.
802.11h Sta tuttora lavorando per la ridefinizione della frequenza di trasmissione
sui 5 GHz, per diminuire le emissioni di onde radio da parte dei dispositivi.
802.11i Questo gruppo di lavoro sta lavorando all’implementazione di sistemi di
sicurezza per 802.11, che si affida attualmente al semplice Wired Equivalent
Privacy (WEP). Il WEP prevede la possibilità di poteggere i dati trasmessi
criptandoli tramite chiavi. Alcuni miglioramenti sono stati già implementati e in alcuni casi già disponibili sul mercato (per esempio il Wi-Fi Protected Access WPA), le pressanti richieste del mercato porteranno a breve alla
realizzazione di altri sistemi di sicurezza piú solidi.
802.11j Questo gruppo, non più attivo, si è occupato della progettazione di una
specifica unica, a livello nazionale, per LAN wireless alla frequenza di 5 GHz.
3.2
QoS su reti wireless 802.11
Le reti WLAN 802.11 sono considerate come un “Ethernet senza fili” per il tipo di
servizio best effort fornito dal livello Medium Access Control (MAC), simile a quello di Ethernet. Ad oggi non sono stati ancora definiti standard per supportare a livello MAC la QoS; sono solamente disponibili alcune bozze del protocollo 802.11e
che dovrà fornire questa funzionalità. Basandosi su queste bozze alcuni produttori
hanno già messo in commercio dispositivi che hanno caratteristiche di QoS. Verranno ora analizzate le caratteristiche principali dei protocolli MAC presenti nello
standard originale 802.11 e nelle bozze 802.11e [8] [9].
3.2.1
802.11
Il protocollo MAC 802.11 consiste di due funzioni di coordinamento, una obbligatoria detta Distributed Coordination Function (DCF) basata sul Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) e una opzionale chiamata Point
34
Coordination Function (PCF) basata su un protocollo di tipo poll-and-response. La
maggior parte dei dispositivi disponibili sul mercato utilizza solamente la modalità DCF. Il controllo del traffico realizzato dal DCF si basa su un servizio nonpreemptive (ad esempio una coda FIFO). Il meccanismo del controllo di accesso
del canale è chematizzato in figura 3.1. Quando un pacchetto MAC esce dalla coda deve attendere finchè non si libera il canale e successivamente aspettare per un
intervallo di tempo fissato per evitare potenziali collisioni con altri nodi di rete.
Questo tempo di attesa fissato è detto DCF InterFrame Space (DIFS). Quando il
canale rimane libero per il tempo DIFS, viene iniziato un conto alla rovescia di durata casuale detto backoff (BO), al termine del quale viene trasmesso il pacchetto.
Se il canale diventa occupato viene sospeso temporaneamente il BO, che riprende
dall’ultimo valore calcolato quando il canale ritorna libero per un tempo maggiore
di DIFS. Ogni dispositivo che utilizza il canale wireless possiede un valore chiamato Contention Window (CW), utilizzato per la scelta del BO. Il valore iniziale del
BO è assegnato scegliendo in modo pseudo-casuale un numero intero nell’intervallo
[0,CW]. Se il pacchetto non viene trasmesso con successo viene calcolato un nuovo
BO utilizzando il valore di CW raddoppiato, per diminuire la probabilità di collisione con altre stazioni. Il valore iniziale del CW è indicato come CWmin, mentre
limite massimo che può assumere in caso di insuccessi è definito da CWmax. Nel
caso in cui un pacchetto arriva in una coda vuota e il canale è libero da un tempo
maggiore di DIFS, il pacchetto viene inviato immediatamente.
DIFS
DIFS
PIFS
SIFS
Contention Window
Canale Occupato
Accesso Rinviato
Trasmissione del
pacchetto successivo
Backoff
slot
(t)
mentre il canale e’ libero
viene decrementato il backoff
Figura 3.1: Accesso al canale 802.11 DCF
Per offrire un supporto alla QoS, seppur in modo limitato, è stato definito il Point
35
Coordination Function (PCF). Il PCF permette alle stazioni mobili di avere accesso
al canale wireless con diversa piorità, grazie ad una stazione Point Coordinator (PC)
che svolge la funzione di coordinamento. Il PCF ha una priorità maggiore rispetto
al DCF, visto che può trasmettere dopo un intervallo di tempo più breve rispetto alla
durata del DIFS; nel caso di PCF il tempo di attesa viene chiamato PCF InterFrame
Space (PIFS). Il PIFS è sempre minore del Simple InterFrame Space (SIFS). Per
una spiegazione più dettagliata riguardo al PCF si rimanda al testo [8].
3.2.2
802.11e draft
Il gruppo di lavoro 802.11e ha proposto uno sviluppo del protocollo MAC precedentemente descritto, definendo una unica funzione di coordinamento Hybrid Coordination Function (HCF). L’HCF combina le funzioni di DCF e PCF con l’aggiunta
di alcune proprietà specifiche per la QoS. L’HCF utilizza per il controllo d’accesso al canale l’Enhanced Distributed Coordination Function (EDCF). Le stazioni
che operano con il protocollo 802.11e sono chiamate Enhanced Station e in modo opzionale possono operare come controllore centralizzato per le altre stazioni
associate nello stesso gruppo. Generalmente questa funzione denominata Hybrid
Coordinator (HC) viene svolta dall’Access Point (AP). Un AP insieme al gruppo di
stazioni a lui associate forma un Basic Service Set (BSS), mentre se questi componenti sono compatibili con le specifiche del 802.11e l’insieme viene chiamato QoS
Basic Service Set (QBSS).
L’EDCF realizza la QoS introducendo delle categorie di traffico, in modo da
gestire otto differenti priorità. Il valore della priorità, detto Traffic Category Identification (TCID), è memorizzato all’interno dell’header del pacchetto MAC. Una
stazione 802.11e deve avere almeno quattro categorie d’accesso (AC) (al massimo
otto, una per ogni priorità). Ogni categoria d’accesso corrisponde ad una variante
estesa della coda FIFO presente nel DCF (figura 3.2).
Ogni pacchetto che arriva al livello MAC viene indirizzato in una categoria di
accesso in base alla priorità. È da notare come la priorità di valore 0 riceve una priorità relativa tra il livello 2 e il livello 3 (in accordo con le specifiche IEEE 802.1D).
I parametri che influenzano il tempo di attesa prima della trasmissione sono assegnati in funzione della categoria d’accesso del pacchetto elaborato. I parametri
36
priorita’ crescente
AC 7
AC 6
AC 5
AC 4
AC 3
AC 0
AC 2
AC 1
Backoff
AIFS[7]
CWmin[7]
CWmax[7]
Backoff
AIFS[6]
CWmin[6]
CWmax[6]
Backoff
AIFS[5]
CWmin[5]
CWmax[5]
Backoff
AIFS[4]
CWmin[4]
CWmax[4]
Backoff
AIFS[3]
CWmin[3]
CWmax[3]
Backoff
AIFS[0]
CWmin[0]
CWmax[0]
Backoff
AIFS[2]
CWmin[2]
CWmax[2]
Backoff
AIFS[1]
CWmin[1]
CWmax[1]
Virtual Collision Handler
Tentativo di
trasmissione
Figura 3.2: Categorie d’accesso nel EDCF
utilizzati sono CWmin[AC], CWmax[AC] e AIFSD[AC], quest’ultimo utilizzato in
sostituzione del DISF presente nel DCF. L’AIFSD è calcolato in questo modo:
AIF SD[AC] = SIF S + AIF S[AC] · SlotT ime
I valori di AIFS[AC], CWmin[AC] e CWmax[AC] sono determinati e comunicati
dall’AP attraverso dei beacon frame trasmessi periodicamente (generalmente ogni
100 msec). L’AP può adattare questi parametri alle condizioni della rete. Questi parametri sono utilizzati per differenziare la priorità d’accesso alle diverse categorie
di traffico. Ogni coda associata ad un AC possiede un proprio valore di AIFS e un
proprio contatore di BO. Se più code finiscono il proprio BO contemporaneamente, la collisione viene gestita in modo virtuale trasmettendo il pacchetto a più alta
priorità e riassegnando un BO agli altri con CW aumentato.
In [10] sono riportati i risultati di alcune simulazioni effettuate sul meccanismo
EDCF.
37
3.2.3
Cisco Aironet 350 Series Access Point
In questo lavoro di tesi è stato utilizzato un access point Cisco Aironet 350 Series
dotato del firmware 12.01T1 [23] [24]. Questo access point aderisce allo standard
802.11b, con l’aggiunta di alcune funzionalità di QoS basate sulla bozze delle specifiche dello standard 802.11e fino al novembre 2002. Il traffico gestito dall’access
point può essere distinto in quattro flussi indicati in figura 3.3:
• Radio Downstream si riferisce al traffico inviato dall’access point e ricevuto dall’utente wireless. La gestione della QoS da parte dell’access point si
occupa di questo flusso di dati.
• Radio Upstream si riferisce al traffico dall’utente wireless all’access point.
La gestione della QoS su questo tratto è definita nelle bozze dello standard
802.11e ma non è stata ancora realizzata nei dispositivi disponibili.
• Ethernet Downstream si riferisce al traffico inviato dal router (o switch) collegato alla rete fissa e che arriva all’access point. È possibile applicare QoS
in questo tratto, ma ciò non fa parte delle funzionalità della rete wireless.
• Ethernet Upstream si riferisce al traffico che viaggia dall’access point al
router/switch. L’access point può classificare il traffico che passa in questo
tratto.
Radio Downstream
Ethernet Downstream
Network
Radio Upstream
Access Point
Ethernet Upstream
Utente
Router
o Switch
Figura 3.3: Definizione dei flussi Upstream e Downstream
Le funzionalità di QoS descritte di seguito in questo paragrafo si riferiscono al
tratto Radio Downstream. L’access point aggiunge al DCF, come previsto dal EDCF,
38
la possibilità di variare i valori dei parametri CWmin e CWmax in funzione della
classe di traffico. In figura 3.4 è riportata la pagina di configurazione dell’access
point che consente di impostare i valori di CWmin e CWmax per le otto categorie
di traffico supportate. I valori indicati sono quelli di default impostati dal produttore.
Figura 3.4: Valori di default per CWmin e CWmax
È difficile mettere in evidenza l’impatto di valori differenti di CWmin e CWmax
in un diagramma temporale degli eventi, considerato che questi parametri influiscono solamente in modo statistico sulla durata del backoff. Bisogna fare attenzione
quando si fissano questi parametri. Ad esempio, se il valore CWmax di una classe è
minore di CWmin di un’altra classe, quest’ultima rischia di non accedere mai al canale. Nella documentazione disponibile non è indicato il numero di code utilizzate
39
dall’access point e nemmeno il meccanismo di gestione dei conflitti virtuali fra le
varie code.
Per classificare i pacchetti in ingresso nelle varie classi di traffico sono disponibili diversi metodi [23] [24]. Questi metodi vengono applicati con un ordine ben
preciso: quelli che hanno meno priorità vengono presi in considerazione solamente
se i metodi che li precedono nella gerarchia non sono attivati. In ordine di priorità,
i metodi sono:
1. Class of Service (CoS): i pacchetti possono essere marcati prima di arrivare
all’access point nel campo CoS definito nello standard IEEE 802.1p;
2. in base al dispositivo: il dispositivo può identificarsi con uno specifico valore
CoS, ad esempio questo meccanismo è utilizzato dai dispositivi Symbol Voice
Over IP (VoIP);
3. filtri: possono essere utilizzati gruppi di filtri (di livello ISO/OSI 2, 3 e 4)
definiti per Virtual LAN (VLAN) o sulle interfacce in modo da assegnare i
pacchetti alle varie classi di servizio;
4. DSCP: se i pacchetti sono marcati attraverso il DSCP, possono essere classificati grazie ad una tabella di conversione DSCP-to-Cos;
5. classe di default per VLAN: può essere impostato un valore CoS di default
per ogni VLAN impostata nell’access point.
3.3
QoS end-to-end tra Diffserv e 802.11e WLAN
Se si vuole ottenere una architettura di QoS end-to-end tra rete fissa DiffServ e
rete wireless 802.11e è necessario coordinare la qualità del servizio dei due sistemi.
Per il traffico proveniente dal tratto Ethernet Downstream, è possibile associare
ad ogni classe di servizio Diffserv, indicata dal DSCP, una classe CoS utilizzata
dallo standard 802.11e. Questa funzione è svolta, nell’access point precedentemente
descritto, dalla funzione DSCP-to-CoS. In [9] vengono proposti due meccanismi
differenti per passare dal DSCP alla classe di traffico dell’access point:
40
• Associazione diretta: semplice traduzione diretta tra DSCP e TCID (nel caso
specifico CoS). In questo schema ogni pacchetto IP è posto in una coda a livello MAC 802.11e senza preemption, visto che viene inviato al livello MAC
dell’access point in accordo con l’istante di arrivo, senza tener conto della
priorità. Dato che la dimensione del campo TCIP è di 3 bit mentre quella del
DSCP è di 6 bit, un singolo valore TCID può rappresentare molteplici valori DSCP; per questo motivo possono accedere ad una stessa coda pacchetti
con priorità differenti e in particolare può capitare che un pacchetto venga
accodato ad uno meno importante. A causa della dimensione differente della
dimensione del campo contentente la priorità, il controllo del traffico viene
effettuato con la granularità prevista dal livello MAC 802.11e.
• QoS gerarchica: questo meccanismo prevede di inserire un Traffic Conditioner (TC) equivalente ad un core router DiffServ nella procedura di elaborazione appena prima di incapsulare i pacchetti IP all’interno dei frame MAC
802.11e. In questo modo si ottiene un controllo del traffico la precisione DiffServ prima di inserire i pacchetti, convertiti in frame MAC 802.11e, nelle
code interne dell’access point. Questo permette di gestire la QoS in modo più
accurato e configurabile.
41
Capitolo 4
Realizzazione di una architettura
DiffServ
L’obiettivo finale del progetto di ricerca in cui si colloca questo lavoro è quello
di realizzare, all’interno del campus, una rete che garantisca una fruizione soddisfacente di servizi multimediali a studenti e docenti. Dopo aver analizzato i meccanismi di QoS descritti in letteratura ed aver individuato nell’architettura DiffServ lo strumento migliore per realizzare il sistema desiderato, è stato realizzato un
prototipo per la gestione di un dominio DiffServ.
Inizialmente è stato sperimentato il supporto ai Servizi Differenziati presente in
Linux, in modo da poter utilizzare come router DiffServ i computer a disposizione
in laboratorio. Sono state studiate e sperimentate le funzionalità necessarie a creare
sia i nodi ai margini del dominio (border router), sia i nodi centrali della rete (core
router).
Successivamente è stato realizzato un Bandwidth Broker per il controllo d’accesso e altri componenti software per l’allocazione dinamica delle risorse. È stato
inoltre ideato un meccanismo che, ponedosi come intermediario tra i due estremi di
una comunicazione multimediale, consente l’utilizzo delle risorse di rete da parte
dei software di trasmissione e ricezione più diffusi. Tra le varie categorie di traffico
multimediale è stato preso in esame in modo particolare il video streaming.
Infine è stato ideato e realizzato un sistema per fornire QoS nella rete wireless e
per includerla nell’architettura DiffServ realizzata.
42
Capitolo 4. Realizzazione di una architettura DiffServ
4.1
Supporto DiffServ in Linux
Il kernel Linux, se aggiornato e configurato opportunamente (paragrafo 4.1.3), prevede un insieme di funzioni per la gestione del traffico. Queste funzioni possono
operare utilizzando il campo DSCP dell’header IP per differenziare il trattamento dei dati. Queste proprietà consentono di realizzare un nodo DiffServ con un
computer Linux, utilizzando solamente software open source.
4.1.1
Traffic Control
Il Traffic Control (TC) nel kernel Linux offre un insieme di funzioni per classificare
ed elaborare il traffico di rete. In figura 4.1 sono specificati i punti in cui interviene
il TC nel percorso che i pacchetti attraversano all’interno del kernel.
...
Interface
Interface
Interface
Egress
Egress
Egress
Forwarding
Demultiplexing
Ingress
Ingress
Ingress
Interface
TCP/UDP
Traffic Control
Figura 4.1: Elaborazione dei pacchetti nel kernel Linux
Nell’ingress può essere effettuato un insieme limitato di funzioni (eliminare pacchetti indesiderati, classificazione preliminare, ecc.), mentre nell’egress vengono
svolte le principali funzioni di controllo. Le funzioni di ingress vengono applicate
ai pacchetti in ingresso dopo la catena di prerouting di iptables, prima che vengano
43
distinti quelli destinati alla macchina stessa da quelli da inoltrare ad un’altra macchina. L’egress si pone dopo la catena iptables di postrouting, come ultimo passaggio
per i pacchetti prima di arrivare all’interfaccia di rete.
Il controllo del traffico effettuato sul flusso in ingresso è chiamato policing,
mentre quello sul traffico inoltrato è detto shaping. Generalmente con i terminini
policing e shaping si intende l’eliminazione o il rallentamento dei paccheti in modo
da limitare la banda utilizzata da un flusso di dati in ingresso ad un router. Nel
caso di router Linux non è prevista la possibilità di ritardare i pacchetti in ingresso,
quindi il policing sull’ingress è limitato all’eliminazione dei dati che eccedono il
limite fissato.
I moderni kernel Linux, oltre al TC, offrono molte funzioni avanzate per la gestione della rete (protezione mediante firewall, routing basato su vari attributi dei
pacchetti, load balancing tra diversi server, ecc.). Queste funzionalità, TC compreso, possono essere utilizzate mediante delle Application Programming Interface
(API). Tuttavia l’utilizzo di queste API risulta molto complicato, sia per il grande
numero di funzioni realizzate, sia perchè si tratta di funzioni di basso livello. La
descrizione della struttura a basso livello del TC si trova in [25] e [26].
Iproute2 è un pacchetto software che permette di accedere alle funzioni avanzate
di networking da linea di comando. Questi comandi permettono anche di creare
script di configurazione della rete con sintassi relativamente semplice. Maggiori
informazioni si possono trovare nel sito Linux Advanced Routing & Traffic Control
(LARTC) [27], che contiene in particolare il manuale Linux Advanced Routing &
Traffic Control HOWTO [28].
Tra i vari comandi disponibili in Iproute2, ha un particolare interesse per questa
tesi il comando tc, che permette di impostare le funzioni di Traffic Control. Per
configurare tc in modo che sia supportato il meccanismo di marcatura DiffServ dei
pacchetti si deve ricompilare il pacchetto dopo aver abilitato l’opzione nel file di
configurazione. I componenti principali del tc sono le code, le classi interne alle
code, i filtri e il policing.
44
4.1.2
Code, classi, filtri e policing
Ad ogni interfaccia di rete è associata una coda. Le code possono essere di vari tipi,
in base alla politica di gestione che definisce il modo in cui i pacchetti sono inviati.
Gli algoritmi di gestione delle code sono detti Queuing Discipline (qdisc). Esistono
due categorie di qdisc: classless qdisc e classful qdisc. In questo paragrafo viene
brevemente descritto il funzionamento delle code, delle classi, e dei filtri disponibili in Linux. Per una descrizione più approfondita dei parametri utilizzati dai vari
componenti di controllo del traffico si rimanda all’HOWTO [28].
Classless qdisc
Le qdisc classless sono gli algoritmi più semplici, che non prevedono suddivisioni
interne configurabili delle code. Queste qdisc hanno il compito di riordinare, ritardare o eliminare i dati. Possono essere usate per modellare l’intero traffico di una
interfaccia, senza la possibilità di operare suddivisioni. Le code classless disponibili
sono:
• pfifo_fast: è una coda di tipo First-In-First-Out. È formata da tre “bande”,
ognuna delle quali dispone di una FIFO. Fino a quando sono presenti dati
nella banda 0 non viene servita la banda 1 e lo stesso vale per le bande 1 e
2. Il kernel supporta la piorità specificata dal flag Type of Service (ToS) dei
pacchetti, inserendo i dati minimum delay nella banda 0. Nonostante questa
differenziazione del traffico, la coda pfifo_fast non è da confondere con una
coda classful. In tabella 4.1 è indicata la banda associata ad ogni valore del
ToS.
• Token Bucket Filter (TBF): è una semplice qdisc che inoltra i pacchetti con
una frequenza che non supera un valore fissato, ad eccezione di burst limitati.
La descrizione dettagliata del funzionamento di un filtro TBF si trova al paragrafo 2.2.2. Il TBF è la scelta migliore se si vuole semplicemente rallentare il
traffico che attraversa una interfaccia. Un esempio di utilizzo di questo filtro
mediante il comando tc è il seguente:
# tc qdisc add dev ppp0 root tbf rate 220kbit\
latency 50ms burst 1540
45
TOS
0x0
0x2
0x4
0x6
0x8
0xa
0xc
0xe
0x10
0x12
0x14
0x16
0x18
0x1a
0x1c
0x1e
Bits
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Significato
Normal Service
Minimize Monetary Cost
Maximize Reliability
mmc+mr
Maximize Throughput
mmc+mt
mr+mt
mmc+mr+mt
Minimize Delay
mmc+md
mr+md
mmc+mr+md
mt+md
mmc+mt+md
mr+mt+md
mmc+mr+mt+md
Priorità Linux
0 Best Effort
1 Filler
0 Best Effort
0 Best Effort
2 Bulk
2 Bulk
2 Bulk
2 Bulk
6 Interactive
6 Interactive
6 Interactive
6 Interactive
4 Int. Bulk
4 Int. Bulk
4 Int. Bulk
4 Int. Bulk
Banda
1
2
1
1
2
2
2
2
0
0
0
0
1
1
1
1
Tabella 4.1: Banda pfifo_fast associata ad ogni Type of Service
Questo comando associa all’interfaccia una coda TBF limitando la banda a
220kbit al secondo, con un tempo di attesa massimo di 50ms per ogni pacchetto e bucket che contiene 1540 byte. È inoltre possibile specificare altri
parametri, ad esempio il numero minimo di gettoni utilizzati da un pacchetto o il rate massimo ottenibile nel caso in cui sono presenti dei gettoni nel
bucket.
• Stochastic Fairness Queueing (SFQ): è la semplice realizzazione di un algoritmo della famiglia fair queuing. È meno accurata rispetto ad altri tipi di
code, ma ha il vantaggio di richiedere meno risorse computazionali pur realizzando una equità ottima tra i vari flussi. SFQ è definita Stochastic perchè
non viene realmente allocata una coda per ogni sessione, ma è presente un
algoritmo di hashing per dividere il traffico in un numero limitato di code
L’algoritmo di hashing viene modificato frequentemente (nell’ordine di pochi secondi) in modo che la contesa di piú sessioni su di una stessa coda non
generi un comportamento osservabile da parte dell’utente. Questa qdisc è utile solamente nel caso in cui l’interfaccia di output presenta una congestione,
46
altrimenti non si nota alcun effetto. I parametri configurabili sono:
– perturb: indica ogni quanti secondi viene riconfigurato l’hashing; è consigliato il valore di 10 secondi.
– quantum: numero di byte che una coda può inviare prima di cedere
il turno alla successiva. Questo valore non deve essere minore della
dimensione dei pacchetti.
– limit: numero di pacchetti che possono essere accodati in questo SFQ,
superato il quale cominciano ad essere eliminati.
• Random Early Detection (RED): serve per evitare il formarsi di congestioni,
eliminando in modo casuale pacchetti prima di saturare le risorse disponibili.
Le code normali funzionano in modo tail-drop, accodando tutti i pacchetti
fino a raggiungere il limite massimo di capienza ed eliminando il traffico che
non riesce ad entrare. Il tail-drop non agisce in modo equo tra le varie sessioni, con il rischio di causare la perdita dei dati di sincronizzazione causandone la ritrasmissione, riempiendo nuovamente il router già sovraccaricato. Il
meccanismo RED è utile in particolare per i backbone, dove non è possibile gestire la complessità dell’elaborazione per sessione altrimenti necessaria
per offrire un coda equa. Per utilizzarla attraverso il comando tc è necessario
specificare, tra i vari parametri, la dimensione in byte della coda (limit), la soglia minima (min) superata la quale si inizia ad eliminare i pacchetti, la soglia
massima (max) e la probabilità per i pacchetti di essere scartati quando viene
raggiunto il limite (probability).
• Generic Random Early Detection (GRED): è una qdisc RED con l’aggiunta di
varie code interne scelte dai pacchetti in base al campo DiffServ tcindex. Per
realizzare il PHB Assured Forwarding, oltre alle quattro priorità di latenza che
possono essere ottenute con componenti già esistenti, serve un meccanismo
che consenta di mettere in pratica le tre precedenze di drop. Per questo motivo
è stata creata la qdisc GRED, che utilizza i bit meno significativi del DSCP,
memorizzato temporaneamente nel campo skb->tc_index, per selezionare la
classe di drop e quindi il corrispondente insieme di parametri RED [25].
47
Classful qdisc
Le qdisc classful contengono varie classi, che a loro volta possono contenere qdisc
sia classless che classful. A differenza della classe pfifo_fast che contiene “bande”
non configurabili, le classi che appartengono ad una qdisc classful possono essere
configurate attraverso il comando tc. Le qdisc classful sono utili quando si hanno
diversi tipi di traffico che devono ricevere un trattamento diversificato. Ogni interfaccia ha una root qdisc di uscita (egress), di default è impostata una pfifo_fast. Ad
ogni qdisc e ad ogni classe è assegnato un identificatore detto handler. Oltre alla
egress qdisc può essere impostata anche una ingress qdisc per effettuare il policing
sul traffico in ingresso.
L’identificatore delle qdisc e delle classi è composto da due parti, uno principale
ed uno secondario, espressi nella forma: <principale>:<secondario>. Normalmente
la root qdisc viene chiamata “1:”, che equivale al valore “1:0” visto che l’identificatore secondario delle qdisc è sempre uguale a 0. Le classi hanno l’identificatore
principale uguale a quello della qdisc a cui appartengono (parent), mentre il secondario serve per distinguerle all’interno della qdisc. Per indirizzare i pacchetti nelle
classi opportune sono utilizzati dei filtri associati alle qdisc classful. I filtri possono
essere configurati per distinguere i pacchetti in base ai vari campi degli header di
livello 3 e 4.
Quando un pacchetto deve raggiungere una interfaccia di uscita, viene indirizzato dalla catena di filtri a partire dalla root qdisc verso la classe opportuna, nella
quale viene messo in coda. Quando il kernel decide di inviare un pacchetto ad una
interfaccia manda la richiesta alla root qdisc “1:”, la quale passa la richiesta di
prelevare il pacchetto alle classi derivate. Questo meccanismo continua finchè non
viene raggiunta una coda contenente il pacchetto. Ogni classe comunica le risposte
solamente alla propria parent qdisc. Le classi non possono ricevere le richieste di
prelevare pacchetti dalla coda ad una frequenza maggiore di quella prevista dalla
propria parent qdisc. È ad esempio possibile limitare il traffico su una qdisc ed utilizzare una classe interna per garantire un comportamento equo ai vari flussi. Le
classful qdisc in Linux sono:
• PRIO: questa qdisc permette semplicemente di suddividere il traffico in classi configurando opportunamente un filtro. L’elaborazione effettiva del flusso
48
deve essere realizzata dalle classi e dalle qdisc che discendono da questa. I
parametri del comando tc che si possono configurare sono:
– bands: numero di classi da creare, se non specificato ne vengono create
tre di default;
– priomap: se non viene fornito un filtro per classificare il traffico viene
utilizzata la priorità TC_PRIO.
Un semplice esempio per creare una PRIO qdisc con tre sottoclassi è il seguente:
# tc qdisc add dev eth0 root handle 1: prio
# tc qdisc add dev eth0 parent 1:1 handle 10: sfq
# tc qdisc add dev eth0 parent 1:2 handle 20: \
tbf rate 20kbit buffer 1600 limit 3000
# tc qdisc add dev eth0 parent 1:3 handle 30: sfq
Il primo comando crea la qdisc root direttamente collegata con l’interfaccia
egress del device eth0. La qdisc creata è di tipo prio. I tre comandi seguenti
associano alle tre classi di default (1:1, 1:2 e 1:3) della qdisc prio altrettante
qdisc interne.
• Class Based Queueing (CBQ): è la qdisc più complessa e più importante.
Permette di creare diverse classi, che a loro volta possono essere suddivise
in ulteriori classi, a cui assegnare caratteristiche differenti (larghezza di banda, priorità, tipo di coda, ecc.). Queste classi possono essere isolate tra loro,
oppure possono prendere in prestito la banda non utilizzata dalle classi che
discendono dallo stesso parent (classi “gemelle”). L’utilizzo di questa coda è
molto complesso visto che presenta molti paramentri di configurazione e che
l’algoritmo non è molto preciso nel suddividere le risorse. Questa mancanza
di precisione nello shaping è dovuta alla difficoltà che ha l’algoritmo di approssimare la banda in funzione della percentuale di utilizzo dell’hardware di
rete. Molte variabili possono influenzare la precisione della stima della banda, come ad esempio il malfunzionamento di un driver che non permette al
49
dispositivo di raggiungere le prestazioni nominali. I parametri da specificare
per configurare una qdisc CBQ possono essere suddivisi in tre categorie:
– parametri per lo la limitazione della banda: ad esempio la banda fisica del dispositivo (bandwidth), quella desiderata per la classe (rate), la dimensione dei burst tollerata (maxburst) e altri parametri per
la correzione dell’algoritmo di shaping.
– parametri per il comportamento differenziato delle classi: la qdisc CBQ
utilizza un meccanismo di tipo Weighted Round Robin per assegnare differenti priorità alle diverse classi. Le classi con valore prio minore ottengono una maggiore priorità. È possibile assegnare un peso alle classi
tramite i parametri weight e allot per impostare il numero di pacchetti
da inviare ad ogni turno.
– parametri per la condivisione del canale e del prestito di banda: isolated
o sharing specifica la disponibilità di una classe a cedere o meno ad altre
la propria capacità momentaneamente inutilizzata. bounded o borrow
specifica se la classe può tentare o meno di prendere in prestito le risorse
inutilizzate dalle classi “gemelle”.
– parametri per creare filtri: oltre all’utilizzo dei normali filtri per determinare in quale classe accodare i pacchetti è possibile, attraverso i parametri split e defmap, creare filtri veloci che operano tramite maschere
di bit da applicare al campo ToS dei pacchetti. Questi parametri devono
essere impostati nelle classi “figlie”. Se il campo ToS rimane invariato
dopo che gli è stato applicato un AND bit a bit con la maschera specificata da defmap, il pacchetto viene accodato alla classe che definisce la
maschera. Il valore assegnato a split indica in quale qdisc o classe deve
essere applicato il filtro.
• Hierarchical Token Bucket (HTB): questa qdisc è stata pensata per ovviare ai
problemi di complessità e scarsa precisione della CBQ. È ideale se si intende
suddividere la banda a disposizione in varie classi (link sharing), fornendo a
queste una banda garantita. È inoltre possibile specificare la quantità massima
di banda che una classe può prendere in prestito dalla classe parent se restano
50
delle risorse inutilizzate. La configurazione della qdisc HTB è abbastanza
semplice anche per creare una struttura complessa. La qdisc HTB è presente
nel kernel Linux se si utilizza una delle ultime versioni rilasciate (a partire
dalla 2.4.20-pre1 e 2.5.31 in avanti), altrimenti è necessario applicare una
patch disponibile nel sito Internet di riferimento per l’HTB [29]. In ogni caso
è necessario avere una versione di tc modificata per gestire questa qdisc. Per
indicare la banda da riservare alla classe si utilizza il parametro rate, mentre
con il ceil si specifica la banda massima che può essere usata prendendone in
prestito. Per ogni classe deve essere indicato anche il burst consentito, mentre
è opzionale il paramentro prio che specifica la priorità della classe rispetto alle
“gemelle”. Nella root qdisc si può indicare, attraverso il parametro default, la
classe in cui accodare i pacchetti non classificati in altro modo.
• Diffserv field marker (dsmark): permette di realizzare i Differentiated Services con diversi PHB. I pacchetti sono distinti e accodati nelle sottoclassi
attraverso il campo DSCP presente nell’intestazione IP. Con il parametro indices si specifica la dimensione della tabella delle coppie (mask, value). Un
esempio tipico di creazione di una qdisc dsmark è il seguente:
#tc qdisc add dev eth0 handle 1:0 root dsmark \
indices 64 set_tc_index
La tabella viene utilizzata per modificare, in uscita dalla qdisc in base alla
classe di appartenenza, il DSCP dei pacchetti attraverso la funzione
New_Ds_field = ( Old_DS_field & mask ) | value
Per impostare con i valori desiderati una istanza nella tabella mask-value si
deve modificare una classe creata di default dalla qdisc:
#tc class change dev eth0 classid 1:1 dsmark \
mask 0x3 value 0xb8
Questo comando assegna ai pacchetti che transitano nella classe 1:1 il DSCP
corrispondente al PHB satndard EF. La maschera 0x3 azzera i bit del DSCP
51
preesistente conservando i due meno significativi del ToS non utilizzati, mentre il “value” che viene applicato attraverso l’operazione di OR imposta il
DSCP con il valore 0xb8 che rappresenta il traffico EF.
skb−>iph−>tos
AND
classe
filtro
tc index
qdisc
interna
OR
mask value
...
...
qdisc dsmark (sch_dsmark)
skb−>tc_index
Figura 4.2: Schema di funzionamento della qdisc dsmark
Se nel comando di creazione di una qdisc dsmark si specifica “set_tc_index”,
viene copiato temporaneamente il valore DSCP nella variabile skb->tc_index.
Questo valore, che può mutare durante il percorso, viene utilizzato in uscita
dalla qdisc come indice all’interno della tabella mask-value per calcolare il
nuovo DSCP da assegnare al pacchetto.
Filtri
Ogni volta che deve essere presa la decisione per un pacchetto su quale sia la classe che lo deve elaborare viene interrogata la catena di classificatori. Questa catena è composta da filtri collegati alle qdisc classful o alle classi che necessitano di
prendere la decisione.
Quando viene accodato un pacchetto, ogni ramo della catena di filtri viene consultata per ottenere le istruzioni. La configurazione tipo nel caso in figura 4.3 prevede di avere un filtro in 1:1 per dirigere i pacchetti ad esempio verso 12: e un filtro
in 12: per mandare i pacchetti verso le foglie (es. 12:2). Il secondo filtro di questo
esempio può anche essere posto in 1:1, ma si ottiene una configurazione più effi52
1:
Legenda:
1:1
qdisc
class
10:
10:1
11:
10:2
12:
12:1
filter
12:2
Figura 4.3: Esempio di utilizzo della catena di filtri
ciente posizionando i test specifici in fondo alla catena. Si possono usare diversi
filtri che si basano su differenti metodi di classificazione:
• route: si basa sull’identificatore dell’instradamento
• firewall (fw): marchio di Netfilter/iptables
• U32: header (IP, TCP, ecc.) dei pacchetti
• RSVP o RSVP IPv6
• policing filters: filtri che selezionano il flusso fino ad un certo limite di banda.
È di particolare interesse il filtro u32 che classifica in base ai valori presenti nelle
intestazioni dei pacchetti, ad esempio l’indirizzo source/destination, la porta source/destination, il protocollo IP, il marchio di ipchains o iptables (fwmark) o il ToS
(che include il DSCP). Oltre a questi è presente anche un filtro chiamato tcindex
apposito per l’architettura DiffServ che identifica i pacchetti in base al DSCP.
In figura 4.4 è rappresentato lo schema di funzionamento di un filtro tcindex.
La prima parte del filtro, creata con il comando riportato di seguito, si occupa di
prelevare il valore DSCP dal ToS del pacchetto.
53
mask=0xfc
shift=2
classe
filtro
tcindex
filter
handle
0x2e
classful qdisc
dsmark 1:0
Figura 4.4: Schema del filtro tcindex
#tc filter add dev eth0 parent 1:0 protocol ip prio 1 \
tcindex mask 0xfc shift 2 pass_on
Questo filtro applica al ToS una maschera di valore 0xfc che filtra i due bit meno
significativi non utilizzati dal DSCP e successivamente esegue uno shift prelevando solamente i sei bit di interesse. A questo punto possono essere creati filtri che
indirizzano i pacchetti nelle classi interne a seconda del DSCP:
#tc filter add dev eth0 parent 2:0 protocol ip prio 1 \
handle 0x2e tcindex classid 2:1 pass_on
Il filtro creato con questo comando indirizza i pacchetti marcati con DSCP 0x2e,
corrispondente al PHB EF, nella classe 2:1.
Policing
L’obiettivo del policing è di accertarsi che il traffico non ecceda certi limiti, eliminando la parte in eccesso. Per semplicità si considera il policing come il meccanismo di controllo del volume di traffico. Esistono quattro differenti meccanismi di
policing [26]:
• decisioni prese dai filtri;
• rifiuto di accodare un pachetto;
• eliminazione di pacchetti da una qdisc interna;
• eliminazione di un pacchetto per fare posto ad uno nuovo che si accoda.
54
4.1.3
Configurazione del kernel
Il materiale che riguarda il supporto al Diffserv in Linux si può trovare in una pagina
internet dedicata [30]. Il supporto per i servizi differenziati è gia integrato nei kernel
2.4 presenti nelle macchine a disposizione nel laboratorio ParMa2, ma per abilitarlo
è necessario ricompilare i kernel interessati configurandoli opportunamente. Accedendo al menù di configurazione del kernel, sotto la voce Networking options, si
devono attivare i seguenti valori:
• Kernel/User netlink socket (CONFIG_NETLINK)
• Network packet filtering (CONFIG_NETFILTER)
• QoS and/or fair queuing (CONFIG_NET_SCHED)
Nella sottosezione QoS and/or fair queuing:
• CBQ packet scheduler (CONFIG_NET_SCH_CBQ)
• HTB packet scheduler (CONFIG_NET_SCH_HTB)
• The simplest PRIO pseudoscheduler (CONFIG_NET_SCH_PRIO)
• SFQ queue (CONFIG_NET_SCH_SFQ)
• RED queue (CONFIG_NET_SCH_RED)
• GRED queue (CONFIG_NET_SCH_GRED)
• DiffServ field marker (CONFIG_NET_SCH_DSMARKER)
• Ingress Qdisc (CONFIG_NET_SCH_INGRESS)
• QoS support (CONFIG_NET_QOS)
• Packet classifier API (CONFIG_NET_CLS)
• TC index classifier (CONFIG_NET_CLS_TCINDEX)
• Firewall based classifier (CONFIG_NET_CLS_FW)
55
• U32 classifier (CONFIG_NET_CLS_U32)
• Traffic policing (CONFIG_NET_CLS_POLICE)
Maggiori informazioni sul kernel di linux e su come compilarlo si trovano nel Linux
Kernel HOWTO [31].
4.2
Architettura per il controllo d’accesso
Dopo aver abilitato su alcuni computer le funzionalità che permettono di realizzare
nodi DiffServ è sorto il problema della gestione dinamica del sistema. Si è pensato
di realizzare un sistema con controllo d’accesso e allocazione dinamica delle risorse che permetta l’utilizzo delle risorse di rete a un vasto numero di persone, come
ad esempio gli studenti e i docenti dell’ateneo. La banda a disposizione, seppur abbondante, non può sostenere l’utilizzo contemporaneo di applicazioni multimediali
da parte di tutti gli utenti abilitati. Per questo è necessario limitare, a seconda della banda utilizzata, il numero di utenti che usufruiscono di un servizio di qualità.
Il controllo d’accesso permette, infatti, di evitare la congestione della porzione di
banda riservata al traffico prioritario limitando il numero e la dimensione dei flussi
accolti. In particolare il controllo d’accesso è importante per la gestione dei colli di
bottiglia della rete, come ad esempio le reti wireless.
Se si vuole fornire un servizio multimediale con QoS agli studenti e ai professori
all’interno della rete del campus ogni utente deve possedere un account. Presumibilmente gli account hanno caratteristiche differenti, ad esempio il servizio massimo a
cui si ha diritto, a seconda del gruppo di appartenenza.
Il controllo d’accesso non preclude comunque la possibilità di limitare gli account in modo che le risorse siano sempre disponibili per gli utenti autorizzati.
Questo caso può essere visto sia come spreco di risorse, visto che nella maggior
parte del tempo il sistema è sottoutilizzato, sia come servizio di ottima qualità verso i clienti che possono disporre in qualsiasi momento delle risorse contrattate. Il
controllo d’accesso implica la necessità di configurazione dinamica del sistema in
modo da permettere solo ai servizi autorizzati di accedere alle risorse condivise.
Lo studio dello stato dell’arte [7] ha evidenziato che il Bandwidth Broker sviluppato dall’Università del Kansas (KUBB) [32] poteva essere la base per lo sviluppo
56
degli strumenti necessari a questo progetto. L’Università del Kansas ha realizzato,
oltre al BB, un pacchetto per la configurazione dinamica di router DiffServ basati
su Linux. Questi strumenti sono stati modificati e configurati opportunamente per
funzionare sui sistemi presenti in laboratorio. È stato necessario aggiornare il software che presentava errori sia di compilazione che di utilizzo errato delle funzioni
di controllo del traffico. Successivamente sono state aggiunte alcune parti mancanti,
come ad esempio la scelta automatica dell’edge router e della giusta interfaccia di
rete da configurare nel router stesso. Infine sono state apportate le modifiche necessarie per poter utilizzare il servizio nel modo voluto. In particolare è stato ripensato
il client che effettua la richiesta di allocazione delle risorse e i parametri contenuti
nella richiesta stessa, per poterlo utilizzare nei progetti in via di sviluppo presso il
dipartimento. Il BB realizzato non gestisce un protocollo interdominio.
4.2.1
Modelli di interazione con il BB
L’obiettivo del sistema è di consentire agli utenti autorizzati di un particolare servizio, ad esempio lo streaming di filmati, di usufruire della QoS nel tratto di rete
attraversato del flusso di dati. Sono stati analizzati differenti meccanismi per la configurazione della QoS. In particolare, il compito di contattare il BB tramite una
Resourse Allocation Request (RAR) può essere svolto da varie entità:
1. utente attraverso software dedicato
Ogni utente può utilizzare direttamente un software appositamente creato per
inviare le richieste RAR al BB. La richiesta di RAR deve essere formulata prima di utilizzare il servizio desiderato. Questo è il meccanismo più semplice
dal punto di vista dell’architettura visto che non comporta la realizzazione di
componenti aggiuntivi. È indispensabile, da parte degli utenti, la conoscenza
approfondita delle caratteristiche tecniche della sessione per cui si richiede
QoS ed il rigoroso rispetto delle politiche fissate dall’organizzazione che gestisce il sistema. Permette lo scambio di tutte le informazioni necessarie tra
utente e sistema. L’utente, infatti, può ricevere direttamente la risposta del BB
alla RAR ed è quindi in grado di decidere in modo autonomo cosa fare nel
caso di mancata allocazione.
57
2. utente attraverso un client multimediale consapevole della QoS
L’utente utilizza un client appositamente realizzato o un client generico opportunamente modificato per gestire la comunicazione con il BB. I client possono essere dotati di interfaccia con il BB solamente se si possiede il codice sorgente o se è possibile aggiungere plug-in. Alcune delle informazioni
necessarie possono essere impostate autonomamente dal software in modo
trasparente all’utente, garantendo maggior sicurezza e semplicità di utilizzo.
Parte della complessità viene portata sul client, obbligando gli utenti a dotarsi
di un software apposito. Permette una comunicazione continua e completa tra
utente e sistema.
3. server consapevole della QoS
Il server, prima di svolgere i suoi normali compiti, configura la QoS per conto
dell’utente. Questo meccanismo è chiaramente utilizzabile solo nel caso di
servizio di tipo client/server. Permette l’utilizzo lato client di strumenti di uso
comune, non consentendo però di comunicare all’utente informazioni relative
alla QoS. Non è possibile modificare server commerciali distribuiti solamente
in forma binaria. I server che forniscono contenuti multimediali potrebbero
inoltre venire dotati di strumenti per classificare in modo differente le varie
tipologie di dati inviati; ad esempio uno streaming server potrebbe assegnare
una priorità maggiore ai frame che incidono maggiormente sulla qualità della
riproduzione.
4. intermediario che intercetta le richieste dei client
Un programma viene posto tra client e server (oppure tra due peer nel modello peer-to-peer) per configurare la QoS intercettando le richieste di setup del servizio. I client e i server possono essere inconsapevoli della QoS.
L’intermediario può essere ad esempio un proxy per il servizio richiesto. Le
informazioni necessarie per chiedere una RAR al BB devono essere ricavate dinamicamente dal proxy in base ad informazioni presenti nel protocollo
di comunicazione tra client e server, nel profilo utente precedentemente specificato ed eventualmente ottenute dialogando con altre entità presenti nel
sistema.
58
5. servizio di allocazione delle risorse integrato nel sistema
Il servizio di allocazione delle risorse viene offerto in modo user friendly,
direttamente integrato con altri moduli del sistema come il servizio di autenticazione o di ricerca di contenuti. Questo modello può essere realizzato
attraverso un sistema basato su Web Services come ad esempio una architettura GRID. Questo servizio può essere offerto tramite pagine web in modo
da richiedere solamente la presenza di un browser sul dispositivo dell’utente. Grazie all’interazione con gli altri componenti del sistema è relativamente
semplice ricavare le informazioni necessarie per effettuare le RAR. Questo
meccanismo permette l’utilizzo di client e server commerciali, consente di
automatizzare la procedura di richiesta delle RAR e rende infine disponibile
un completo canale di comunicazione tra utente e sistema.
Nei modelli 3 e 4 l’utente non specifica nessun parametro di QoS durante la richiesta del servizio e non genera direttamente segnalazione out-of-band. Gli utenti
che hanno preventivamente contrattato un livello di servizio con il sistema vengono
serviti, compatibilmente con le risorse disponibili a tempo di esecuzione, secondo
gli accordi fissati. Non è possibile comunicare all’utente il livello di servizio assegnato, visto che le uniche informazioni significative per il client sono quelle previste
nel protocollo utilizzato che non prevede parametri di QoS. Per questo è importante la possibilità di specificare un profilo utente dove indicare il comportamento da
tenere in caso di mancata allocazione della banda richiesta. In alternativa, potrebbe
essere inviato all’utente, prima del contenuto richiesto, un messaggio preconfezionato (audio o video) contentente le informazioni sulla QoS disponibile, in modo che
l’utente possa agire di conseguenza. Senza questi meccanismi le uniche informazioni a disposizione dell’utente sono quelle qualitative legate al resa della riproduzione
multimediale.
Nei modelli 3 e 4 è inoltre possibile effettuare adattamento dei contenuti a seconda delle risorse di banda disponibili e delle caratteristiche del dispositivo utilizzato dall’utente, come ad esempio la risoluzione dello schermo (capabilities). Una
soluzione alternativa che può essere utilizzata in tutti i modelli proposti è quella di
codificare preventivamente uno stesso contenuto in più formati con differente risoluzione e livello di compressione. Questo sistema consente il risparmio delle risorse
computazionali necessarie ad effettuare la trancodifica on demand ma fornisce una
59
minore personalizzazione. La minore personalizzazione garantisce d’altro canto una
maggiore probabilità di riutilizzo del medesimo file, migliorando le prestazioni di
un sistema dotato di caching proxy.
4.2.2
Prototipo realizzato
È stato realizzato un prototipo nel quale si è preferito non lasciare all’utente la
possibilità di richiedere direttamente la configurazione della QoS, per ragioni di sicurezza e di utilizzo corretto delle risorse. È stato sperimentato un sistema basato
sulla presenza di un intermediario tra client e server per un servizio di video streaming. Il sistema è in grado di ottenere autonomamente le informazioni necessarie
al setup della QoS, come ad esempio la banda e la durata del filmato e gli indirizzi
IP di sorgente e destinazione.
Nel prototipo messo a punto in questo lavoro è stato utilizzato un Caching Proxy
per il protocollo Real Time Streaming Protocol (RTSP). In particolare è stata usata
la versione 2.3 del RTSP proxy di RealNetworks, estesa da Matteo Merli che ha
introdotto la funzionalità di caching [33]. In questo schema il proxy ha il compito
di recuperare tutte le informazioni necessarie per formulare una richiesta di allocazione delle risorse, di contrattare con il BB la QoS in nome dell’utente ed infine di
fornire il filmato richiesto. Il proxy è stato dotato delle funzionalità necessarie ad
operare nel modo appena descritto.
Gli utenti, per poter usufruire di QoS, devono per prima cosa ottenere un SLA
dall’amministratore del dominio DiffServ che lo collega al server. Quando l’utente
desidera vedere un filmato con QoS deve configurare nel player l’utilizzo del proxy.
Lo schema di comunicazione tra i componenti del sistema è il seguente (figure 4.5
e 4.6 ):
1. l’utente richiede un filmato eseguendo una RTSP SETUP al server di streaming attraverso il proxy
2. il proxy ottiene l’identità dell’utente in base all’indirizzo IP da un apposito
servizio (ad esempio il servizio di autenticazione dei clienti wireless)
3. se l’utente è autorizzato il proxy manda una RAR al BB per garantire la QoS
nel tratto proxy-utente
60
4. il BB risponde indicando se la RAR è stata accettata o meno e configura
opportunamente gli edge/leaf router
5. se la cache del proxy contiene il filmato richiesto si passa al punto 9, altrimenti
il proxy manda una RAR al BB per garantire la QoS nel tratto server-proxy
6. il BB risponde e configura gli edge/leaf router
7. il proxy inoltra il la richiesta RTSP SETUP al server
8. il server risponde OK al proxy
9. il proxy risponde OK all’utente
10. l’utente può mandare il comando PLAY al proxy
11. se il proxy possiede la copia del filmato si passa al punto 13, altrimenti inoltra
il comando PLAY al server
12. il server invia il flusso al player
13. il proxy invia il flusso all’utente
Il player non è in grado di interpretare comunicazioni che riguardano l’effettiva
configurazione della QoS. Non è possibile fare in modo che l’utente possa scegliere
a tempo di esecuzione il comportamento da tenere in caso di mancata configurazione della QoS, a meno di interrompere il playback. L’utente si potrebbe accorgere
della mancata QoS solamente attraverso la scarsa qualità dell’immagine ricevuta.
Rimangono aperti alcuni problemi di sicurezza, che non sono stati oggetto di
questa tesi. Ad esempio il servizio di autorizzazione e autenticazione è stato previsto, per completezza, ma non è stato realizzato.
4.2.3
Componenti del sistema
Strumenti di amministrazione
Gli SLA basati sulle richiestre dei clienti sono generalmete aggiunti al BB dall’amministratore del dominio attraverso la apposita pagina web (figura 4.7). Il cliente che
61
EDGE
ROUTER
UTENTE
RTSP
PROXY
AAA
SERVER
BB
EDGE
ROUTER
STREAMING
SERVER
1. RTSP SETUP
2a. WHOIS(IP)?
2b. USERID
3. RAR(src PROXY, dst UTENTE)
4a. CONFIGURA
4b. RAR ACCETTATA
5. RAR(src SERVER, dst PROXY)
6a. CONFIGURA
6b. RAR ACCETTATA
7. RTSP SETUP
8. OK
9. OK
10. PLAY
11. PLAY
12. STREAMING
13. STREAMING
Figura 4.5: Schema di comunicazione tra i componenti del sistema
richiede un SLA all’amministratore può essere un singolo utente interno al dominio
o l’amministratore di un dominio vicino. Il BB effettua un controllo sulla banda
disponibile prima di ammettere un nuovo SLA. Se non può essere soddisfatto viene ritornata la banda disponibile in quell’intervallo di tempo invece di un semplice
messaggio di errore. La pagina web di amministrazione offre inoltre la possibilità
di vedere e modificare gli SLA già presenti e di osservare le Resource Allocation
Request attive. Questi servizi sono realizzati mediante programmi in linguaggio C
e script in Perl che si occupano comunicare sia con il processo principale del BB
sia con la base di dati ed infine formattano la risposta in linguaggio html, in modo
da poterla visualizzare attraverso il browser. Per utilizzare questi strumenti è necessario un web server (ad esempio Apache). Il web server, il processo principale del
BB ed il server SQL che gestisce la base di dati possono essere in esecuzione su
computer differenti.
Le informazioni contenute negli SLA sono:
62
Proxy
Database
2. Controllo Utenti
3. e 5. RAR
BB
AAA
Server
6. config
4. config
Database
7. RTSP request
Edge Router
12. flusso dati
1. RTSP request
13. flusso dati
Edge Router
Core Router
Dominio DiffServ
Edge Router
Server Multimediale
Utente
Figura 4.6: Schema di collaborazione tra i componenti del sistema
• Customer ID: identificatore dell’utente (di tipo stringa)
• Type of Service: tipo di servizio richiesto (EF, AFxx)
• Maximum Rate: Banda massima allocabile per questo utente
• Burst Size: dimensione del busrt consentito
• Start Date of the SLA: data di inizio della validita dell’SLA
• Expiry Date of the SLA: data di scadenza dell’SLA
Bandwidth Broker
Il BB utilizza un database per tenere traccia delle RAR attive, degli SLA, del ruolo di ogni router nel dominio e dei codici DSCP asseganti ai PHB. È disponibile
uno script di configurazione per creare le tabelle necessarie in un database Mysql. Alcune tabelle relative alla topologia della rete devono essere riempite manual63
Figura 4.7: Pagina web di amministrazione
mente dall’amministratore. Ad esempio la tabella RTINFO deve essere compilata
con le informazioni relative a tutti gli edge router del dominio (router Linux o Cisco, indirizzo di rete, indirizzo e interfaccia da utilizzare per la configurazione).
La tabella LEAFINFO serve individuare quale edge router deve essere configurato
per accogliere il traffico proveniente da un indirizzo IP. L’intervallo degli indirizzi
dei computer connessi tramite un edge router viene indicato dalla coppia di valori
indirizzo-netmask.
Tramite un file di configurazione è possibile specificare la quantità di banda
allocabile nel dominio per le classi EF, AF4, AF3, AF2 e AF1. Questi valori sono
utilizzati per valutare se ci sono sufficienti risorse per accogliere o meno un nuovo
SLA.
Il BB interagisce con gli altri componenti del sistema attraverso dei protocolli
binari non standard. Sono presenti tre tipi di interfacce:
64
• Interfaccia con gli script di amministrazione della pagina web: serve per aggiungere e modificare gli SLA e per fornire l’elenco di SLA e RAR conservati
nel DB. Sulle richieste per aggiungere o modificare un SLA, il BB controlla che la quantità di risorse assegnate a tutti gli utenti non superi un limite
fissato.
• Interfaccia con il client che richiede le RAR: fornisce la possibilità di allocare
e disallocare la banda. In risposta alle richieste RAR accettate viene ritornato
il codice assegnato alla allocazione mentre a quelle negate viene risposto un
codice di errore.
• Interfaccia con i border router: il BB riceve dai router le informazioni di routing e invia i comandi di configurazione per classificare il traffico in ingresso
al dominio.
In seguito ad una richiesta di allocazione il BB effettua le seguenti operazioni:
1. controllo dell’identificativo dell’utente e dell’autorizzazione ad utilizzare la
banda richiesta nella classe di servizio specificata (verifica sugli SLA dell’utente e sulla banda residua di cui dispone);
2. verifica della disponibilità di banda nel periodo di tempo richiesto per poter
accettare o meno la RAR;
3. se la RAR è accettata, scelta del border router da configurare in base all’indirizzo del computer sorgente;
4. richiesta della tabella di routing per poter individuare l’interfaccia da configurare in base all’indirizzo IP di destinazione;
5. configurazione opportuna del router scelto;
6. invio al client RAR del codice di identificazione della RAR accettata oppure
di un codice di errore che indica il problema riscontrato.
È presente nel BB un sistema di controllo di SLA e RAR che provvede ad eliminare
le istanze scadute.
65
Edge Router
Ogni border router viene configurato attraverso un demone che applica i comandi
ricevuti via socket dal BB. I dati che entrano nel dominio attraverso un edge router
devono essere marcati con il DSCP e regolati tramite le funzioni di policing. I flussi
vengono identificati tramite un filtro u32 utilizzando gli indirizzi IP di sorgente e
destinazione, le porte (almeno quella di destinazione) e il protocollo. Per ogni flusso
è specificata la categoria di traffico a cui deve essere aggregato, il limite massimo di
banda, il burst e il comportamento per i pacchetti fuori limite (drop o continue che
riclassifica a BE). Solitamente viene utilizzata la politica drop nel caso EF, mentre
per le classi AF effettua la riclassificazione del traffico in eccesso.
drop
meter
meter
u32
riclassificazione
class 1:1
class 1:2
class 1:3
class 1:14
FIFO
DSCP 0x2e (EF)
DSCP 0x26 (AF43)
DSCP 0x24 (AF42)
DSCP 0x00 (BE)
dsmark 1:0
Figura 4.8: Architettura dell’edge router
L’architettura del controllo del traffico nell’edge router è mostrata in figura 4.8.
La qdisc principale è una dsmark direttamente associata all’interfaccia di output.
Questa qdisc imposta il DSCP con il valore richiesto in base alla coda in cui sono
posti i pacchetti. Questa architettura, comprendente la root qdisc e le classi che
definiscono i DSCP, è creata per ogni interfaccia di uscita in fase di inizializzazione
del demone. I filtri sono creati ed eliminati dinamicamente secondo i comandi del
BB.
66
Core Router
I core router non devono essere configurati dinamicamente ogni volta che viene ammesso un flusso. La configurazione deve essere fatta dall’amministratore solamente
quando cambia la struttura o le caratteristiche della rete. Per questo si è pensato di
configurare i core router attraverso script per shell che creano la struttura del traffic control associato alle interfacce di rete. Gli script utilizzano il comando tc per
creare gli elementi del traffic control.
skb−>iph−>tos
handle 5
rate 20Mb
ceil 20Mb
class 2:50
handle 4
rate 100Mb rate 15Mb
ceil 100Mb ceil 100Mb
class 2:1
class 2:40
handle 3
rate 15Mb
ceil 100Mb
class 2:30
handle 2
rate 15Mb
ceil 100Mb
class 2:20
handle 1
rate 15Mb
ceil 100Mb
class 2:10
handle 0
rate 20Mb
ceil 100Mb
class 2:5
0x28
mask 0xfc
shift 2
tcindex
handle 0
−> 0x001
handle 10
−> 0x111
mask 0xf0
shift 4
tcindex
handle 12
−> 0x112
handle 14
−> 0x113
pacchetto
marcato
AF11
handle 18
−> 0x121
0x111
handle 26
−> 0x131
handle 34
−> 0x141
handle 46
−> 0x160
0x28
SFQ
DP 1
DP 2
DP 3
GRED
DP 1
DP 2
DP 3
GRED
DP 1
DP 2
DP 3
GRED
DP 1
DP 2
DP 3
GRED
RED
htb 2:0
0x111
dsmark 1:0
0x28
0x111
skb−>tc_index
Figura 4.9: Architettura del core router
In figura 4.9 è rappresentata l’architettura proposta che permette la coesistenza
di traffico di tipo EF, AF e BE. Questa è la configurazione più completa e complessa
realizzata durante il lavoro di tesi; nella fase di realizzazione di una rete è necessario
tenere conto delle esigenze particolari del caso in esame, scegliendo solamente gli
strumenti adatti per ottentere una soluzione semplice ed efficente. In particolare, se
il dominio deve gestire pochi tipi differenti di applicazioni che necessitano di QoS,
è consigliato l’utilizzo di un insieme ridotto di classi di servizio rispetto a quello
proposto.
Il traffico EF riceve la massima priorità e viene filtrato in modo da non superare
67
il limite di banda fissato dall’amministratore. Il traffico AF viene differenziato nelle
quattro classi con diversa priorità, su ogni delle quali è applicato un policer che
limita la banda ad un valore fissato. All’interno delle classi viene utilizzata la drop
precedence per discriminare i pacchetti in caso di congestione. Anche il traffico BE
viene limitato nella banda per proteggere le categorie di traffico più importanti. Al
traffico delle classi AF e BE è concesso di utilizzare la banda non utilizzata dalle
classi che ne hanno diritto fino al raggiungimento del limite di traffico specificato,
che deve coincidere con la capacità della rete in uscita. I limiti delle varie classi
possono essere specificati in modo semplice tramite le variabili dichiarate all’inizio
dello script di configurazione.
La coda principale è una qdisc dsmark direttamente associata all’interfaccia di
output. Questa qdisc estrae il byte ToS da pacchetti in arrivo e lo passa al classificatore tcindex. Viene successivamente applicato un filtro tcindex che estrae il DSCP
dal byte ToS mascherandolo con il valore 0xfc ed eseguendo successivamente uno
shift a destra di due posizioni. Ad esempio, se il pacchetto è marcato con valore ToS
0x28 (00101000) si ottengono le seguenti operazioni:
00101000 & 11111100 = 00101000
00101000 >> 2 = 00001010
Il valore DSCP 00001010 (0x0a in notazione esadecimale, 10 in decimale) corrisponde al codepoint standard del PHB AF11.
Il valore del DSCP estratto in questo modo viene utilizzato per selezionare il
PHB corretto per ogni pacchetto. Per questo sono presenti dei filtri, uno per ogni
PHB, che in base al valore del DSCP marcano un codice nel campo skb->tc_index
del pacchetto. Ad esempio i pacchetti della classe con DSCP uguale a 10 vengono
marcati con il valore 0x111 grazie al filtro:
tc filter add dev eth0 parent 1:0 protocol ip prio 1 \
handle 10 tcindex classid 1:111
In tabella 4.2 sono indicati i valori assegnati alle varie classi di servizio.
Alla root qdisc è attaccata la qdisc 2:0 di tipo HTB, che presenta al suo interno
la classe 2:1 utilizzata per limitare la banda totale in uscita verso il dispositivo (nel68
dec
0
40
48
56
72
80
88
104
112
120
136
144
152
184
TOS
hex
bin
0x00 00000000
0x28 00101000
0x30 00110000
0x38 00111000
0x48 01001000
0x50 01010000
0x58 01011000
0x68 01101000
0x70 01110000
0x78 01111000
0x88 10001000
0x90 10010000
0x98 10011000
0xb8 10111000
dec
0
10
12
14
18
20
22
26
28
30
34
36
38
46
DSCP
hex
bin
0x00 00000000
0x0a 00001010
0x0c 00001100
0x0e 00001110
0x12 00010010
0x14 00010100
0x16 00010110
0x1a 00011010
0x1c 00011100
0x1e 00011110
0x22 00100010
0x24 00100100
0x26 00100110
0x2e 00101110
Classid
PHB
1:1
1:111
1:112
1:113
1:121
1:122
1:123
1:131
1:132
1:133
1:141
1:142
1:143
1:150
BE
AF11
AF12
AF13
AF21
AF22
AF23
AF31
AF32
AF33
AF41
AF42
AF43
EF
Tabella 4.2: Valori utilizzati per marcare i pacchetti
l’esempio 100Mbit al secondo). La classe 2:1 è a sua volta suddivisa, in ordine di
priorità, nelle classi:
2:50 È la classe dedicata al traffico EF. Questa classe ha 20 Mbit al secondo di banda garantita. Questo valore rappresenta anche la banda massima utilizzabile.
2:40 È la classe dedicata al traffico AF4x. Il traffico di questa classe ha 15 Mbit al
secondo di banda garantita, ma può ereditare fino a 100 Mbit al secondo dalla
classe parent 2:1.
2:30 È la classe dedicata al traffico AF3x. Come la 2:40 ha rate uguale a 15 Mbit e
ceil pari a 100Mbit.
2:20 È la classe dedicata al traffico AF2x. Ha la stessa disponibilità di banda delle
altre classi AF.
2:10 È la classe dedicata al traffico AF1x. Ha la stessa disponibilità di banda delle
altre classi AF.
69
2:5 È la classe dedicata al traffico BE. Ha 20 Mbit di banda garantita e può arrivare
ad utilizzare fino a 100 Mbit.
I valori assegnati a rate e ceil nelle varie classi servono solamente come esempio;
devono essere scelti durante la realizzazione di una rete in base alle politica generale di amministrazione. Se si effettua un controllo d’accesso rigoroso sul traffico
AF che entra nel dominio non è necessario impostare il valore di ceil, visto che
questo traffico non potrà mai superare il limite impostato. Per il traffico BE, invece,
è sempre consigliato l’utilizzo del parametro ceil per evitare lo spreco delle risorse
inutilizzate dal traffico prioritario. Questo meccanismo si è rivelato molto preciso
nel garantire la banda riservata al traffico principale, al contrario dei neccanismi di
condivisione della banda offerti dalla qdisc CBQ.
Per inserire i pacchetti nella sottoclasse corretta viene usato un insieme di filtri.
Per prima cosa viene applicata al valore skb->tcindex la maschera 0xf0 e il risultato
viene fatto ruotare a destra di quattro bit. Questo meccanismo consente di estrarre la
penultima cifra del codice, utilizzata per distinguere la classe di servizio all’interno
del PHB AF. Ad esempio, applicando queste operazioni ad un pacchetto marcato
con il valore 0x132 si ottiene:
000100110010 & 000011110000 = 000000110000
000000110000 >> 4 = 000000000011 = 0x3
Il valore 3 ottenuto nell’esempio indica che il pacchetto appartiene alla classe AF3,
trascurando per il momento la drop precedence. I sei filtri successivi si occupano di
accodare i pacchetti in base al valore calcolato:
• 0: il pacchetto viene inserito nella classe 2:5 corrispondente al PHB BE.
Questa classe gestisce i pacchetti accodati con una qdisc di tipo RED.
• 1: il pacchetto viene inserito nella classe 2:10 corrispondente al PHB AF1.
Questo PHB è realizzato con una qdisc GRED, che utilizza gli ultimi tre bit
del campo skb->tc_index per suddividere il traffico nelle tre drop precedence.
Anche in questo caso viene utilizzata una qdisc GRED.
70
• 5: il pacchetto viene inserito nella classe 2:50 corrispondente al PHB EF.
Questa classe è gestita internamente con una qdisc SFQ.
Per osservare la configurazione creata e per misurare il traffico che transita nelle
varie classi è stato utilizzato lo script in linguaggio Perl monitor_tc.pl, reperibile nel
sito Internet http://www.docum.org.
Client RAR
È stato realizzato un programma che si interfaccia con il BB per chiedere l’allocazione e la deallocazione delle risorse (RAR). Il programma, chiamato makerar,
riceve in ingresso i parametri da inviare al BB tramite un protocollo binario ad hoc.
I parametri da specificare nel caso di richiesta di allocazione sono i seguenti:
• indirizzo IP del BB;
• username;
• indirizzo IP dell’host sorgente;
• indirizzo IP dell’host destinazione;
• porta di destinazione;
• protocollo (tcp/udp);
• classe di servizio DiffServ;
• banda da allocare;
• durata prevista della comunicazione.
71
Il primo valore serve per stabilire la connessione con il BB nella porta di default, i
seguenti valori sono invece utilizzati riempire la struttura della RAR. La coppia di
valori assegnati a “username” (di tipo stringa) ed a “classe di servizio” sono utilizzati per identificare in modo univoco l’SLA a cui la RAR fa riferimento. La somma
della banda allocata grazie ad un SLA non può mai superare il valore indicato nell’SLA stesso. La banda deve essere espressa in kbit al secondo, menter la durata
prevista deve essere espressa in secondi.
Se il BB riesce a soddisfare la richiesta di allocazione il makerar restituisce il
codice della nuova RAR, altrimenti il valore restituito indica il motivo del fallimento. Nel caso di richiesta di deallocazione si deve specificare l’indirizzo IP del BB e
il codice assegnato alla RAR da eliminare.
Proxy
Il proxy, oltre alle funzioni proprie che comprendono anche la possibilità di memorizzare i filmati e servire in modo autonomo i clienti, è stato dotato della capacità
di interagire con il BB attraverso il makerar. Il proxy è in grado di ottenere tutti i
parametri necessari per eseguire in modo corretto la richiesta di allocazione:
• indirizzo IP del BB: il BB (o i BB, se sono attraversati più domini, visto che
non è realizzato il protocollo di comunicazione interdominio) viene specificato nella fase di configurazione del proxy.
• username: viene ottenuto interrogando un apposito servizio che identifica l’utente in base all’indirizzo IP. Può causare problemi se più di un utente utilizzano lo stesso IP, ad esempio grazie ad un Network Address Translator
(NAT).
• indirizzio IP dell’host sorgente: nel caso del flusso server->proxy è l’indirizzo
IP dello streaming server specificato dall’utente nella richiesta di setup RTSP.
Per il flusso proxy->utente è l’indirizzo del proxy stesso.
• indirizzo IP dell’host destinazione: per il flusso server->proxy è l’indirizzo
del proxy. Per il flusso proxy->utente è l’indirizzo del cliente che ha effettuato
la richiesta di streaming.
72
• porta di destinazione: è comunicata dal client durante il setup.
• protocollo (tcp/udp): i dati in streaming vengono trasmessi con il protocollo
RTP che si basa su UDP.
• classe di servizio DiffServ: per ogni tipo di comunicazione viene definito il
tipo di servizio da assegnare dall’aministratore di sistema. In letteratura [22]
è consigliato per applicazioni di streaming video la classe di servizio AF13.
• banda da allocare: la bitrate del filmato dovrebbe essere noto al proxy. Purtroppo non tutti gli streaming server comunicano il bitrate del filmato in quanto non è obbligatorio inserire questa informazione nell’header del protocollo
RTSP. Per questo prototipo è stato previsto un valore di default per il bitrate
da utilizzare nel caso in cui non sia noto quello reale.
• durata della comunicazione: la durata del filmato è nota al proxy. L’amministratore del sistema potrebbe voler concedere agli utenti una durata di allocazione delle banda superiore a quella strettamente necessari alla visione, per
consentire all’utente di utilizzare senza problemi le funzioni di pausa, seek,
eccetera. Per questo può essere utile sommare alla durata del filmato un tempo
bonus proporzionale alla durata stessa.
È da notare che per ogni filmato RTSP vengono creati due flussi RTP, uno per l’audio e uno per il video, su due porte diverse del ricevitore. Il proxy deve perciò mandare al BB due RAR differenti con parametri di bitrate e di porta di destinazione
diversi.
In questo prototipo viene ignorato l’eventuale fallimento dell’allocazione di
banda visto che non si è in grado di inoltrare questa informazione all’utente.
Player e Server
Tutto il sistema è pensato per funzionare in modo corretto con i player e i server di
uso comune. L’unica condizione è che il player RTSP supoprti l’uso di un proxy.
Il sistema è stato testato con i player RealOne, QuickTime, OpenRTSP e Mplayer
compilato con le librerie LIVE per lo streaming e modificato per utilizzare un proxy.
73
Dal lato server è stato utilizzato il Darwin Streaming Server, che purtroppo non
riporta le informazioni relative al bitrate dei filmati inviati.
4.3
QoS tra rete Wired e rete Wireless
È stato studiato il modo di offrire QoS per gli utenti wireless di una rete WLAN che
opera in modalità infrastructure, ossia nel caso in cui le stazioni mobili comunicano
esclusivamente tramite un access point. Questa modalità si contrappone alla rete
ad hoc, nella quale le stazioni mobili comunicano direttamente tra loro. La rete
wireless utilizzata è composta da un access point Cisco Aironet 350 series e da
portatili Linux che utilizzano schede PCMCIA Cisco Aironet 350 series wireless
LAN adapter. Questi dispositivi comunicano tramite il protocollo IEEE 802.11b ad
una velocità nominale di 11 Mbps.
Il livello MAC dell’access point offre alcune funzionalità di QoS nel tratto Radio Downstream come descritto nel sottoparagrafo 3.2.3. Le prove effettuate hanno
dimostrato che è possibile differenziare il traffico nelle varie classi di servizio dell’access point attraverso filtri su VLAN, porte e protocolli. Questa sperimentazione
ha anche messo in evidenza che la conversione da DSCP a CoS, fondamentale per
utilizzare l’access point all’interno di una architettura DiffServ, non funziona. Infatti inviando dati marcati con valore DSCP diverso da 0, in quantità superiore alla
capacità di trasmissione dell’acces point, non è stato notato alcun incremento tra i
pacchetti scartati nelle categorie di traffico differenti dalla numero 0 (best effort). Il
numero dei pacchetti scartati per le varie classi di traffico è indicato nella pagina di
controllo della interfaccia radio dell’access point (figura 4.10). Queste prove sono
state ripetute utilizzando diverse configurazioni della tabella DSCP-to-CoS senza
dare esito positivo, mentre utilizzando gli altri meccanismi per impostare la CoS si
riscontrano pacchetti persi nella classe corretta.
4.3.1
Filtraggio del traffico destinato alla rete wireless
I meccanismi offerti dall’access point non consentono un gestione della QoS completamente configurabile secondo le esigenze del sistema. Per poter usufruire di un
insieme ampio e configurabile di meccanismi di QoS è possibile inserire tra la rete
74
Figura 4.10: Statistiche della porta radio dell’access point
fissa e l’access point un core router con lo scopo di configurare opportunamente il
traffico destinato agli utenti wireless (figura 4.11). Le funzionalità del core router
si aggiungono a quelle eventualmente offerte dall’access point. Filtrando il flusso
sul core router si è in grado di garantire le risorse dedicate al traffico prioritario.
Al contrario, se un access point senza supporto per la QoS riceve una quantità di
dati superiore a quella che riesce a trasmettere, i pacchetti vengono scartati in modo indiscriminato. Questa soluzione riprende inoltre il concetto di QoS gerarchica
introdotto nel paragrafo 3.3.
75
Filtro sull’AP
(senza QoS)
Filtro sul CR
(con QoS)
Edge Router (ER)
traffico
prioritario
100 Mbit/s
100 Mbit/s
Ethernet
traffico
best effort
Core Router (CR)
Ethernet
Access Point (AP)
~7.5 Mbit/s
~7.5 Mbit/s
Utente
Utente
Utente
Figura 4.11: Filtraggio effettuato dal Core Router a monte dell’Access Point
A questo punto si pone il problema di modellare il flusso in modo che sia compatibile con la capacità di trasmissione dell’access point. La banda disponibile nel
canale radio è molto variabile e le cause di tale variazione sono molteplici: numero
di stazioni connesse, condizioni ambientali, collisione con traffico di altri dispositivi, dimensione dei pacchetti trasmessi, eccetera. In letteratura si trovano diversi
studi che riguardano l’andamento del throughput su reti locali wireless (WLAN)
al variare delle condizioni [34] [35] [36]. È tuttavia difficile stimare il throughput
disponibile visto l’alto numero di paramentri che incidono sulla banda e la difficoltà
76
nell’ottenere una funzione che modelli bene il sistema.
Sperimentalmente è stata rilevata una velocità massima di trasmissione effettiva
di circa 7.5 Mbit/s in presenza di una sola stazione mobile associata all’access point.
Se la stazione mobile effettua sia download che upload la somma del bitrate nelle
due direzioni risulta essere ancora di circa 7.5 Mbit/s. L’access point ha una priorità
di trasmissione nel canale maggiore rispetto alle stazioni mobili; questo perchè dall’access point passa tutto il traffico destinato alle varie stazioni associate e quindi
deve utilizzare normalmente più banda rispetto alla trasmissione in upstream delle
singole stazioni.
Le soluzioni di QoS da utilizzare dipendono anche dal pattern di traffico delle
applicazioni che generano il traffico da proteggere. Ad esempio il traffico generato
da uno straming multimediale è principalmente monodirezionale verso l’utente wireless, che corrisponde alla direzione su cui è possibile intervenire per offrire QoS.
Applicazioni che richiedono garanzie in entrambe le direzioni, come videoconferenza o VoIP, non possono essere soddisfatte dal sistema studiato. Se fosse nota la
banda disponibile nel canale wireless si potrebbe utilizzare un core router strutturato
in queso modo:
• banda garantita per il traffico prioritario;
• traffico BE limitato per occupare la parte di banda non utilizzata dal traffico
prioritario fino a raggiungere il limite fissato dall’access point.
Per configurare in modo dinamico il core router sono stati realizzati due script che
riceveno come parametri di ingresso l’interfaccia di rete da configurare, la banda
totale disponibile e la banda da garantire al traffico prioritario.
Il primo dei due script crea la struttura di controllo del traffico costituito da
una qdisc principale di tipo DSMARK seguita da una qdisc HTB suddivisa in due
classi, una per il traffico prioritario (EF) e l’altra per quello BE. La qdisc HTB limita
il traffico totale al valore impostato, che non deve superare il throughput dell’access
point.
La porzione di banda riservata al traffico prioritario viene fissata grazie alla prima delle due sottoclassi HTB. Per consentire l’utilizzo di un sistema di controllo
d’accesso e allocazione della banda, il valore massimo consentito di traffico prioritario non deve essere modificato dinamicamente. La quantità di banda garantita al
77
traffico prioritario dovrebbe quindi essere fissata dall’amministratore del sistema in
modo che sia sempre supportata dalla capacità di trasmissione dei dispositivi. Dato
che non esiste un limite inferiore di throughput garantito dall’access point in downstream, deve essere deciso un valore basandosi sulle statistiche delle prestazioni
del sistema in questione. Se il valore fissato è grande, possono essere accolti nella
classe privilegiata un numero maggiore di flussi; in questo modo però aumenta la
probabilità che l’access point non riesca a soddisfare tutto il traffico prioritario.
La sottoclasse HTB che realizza il PHB BE limita il traffico in transito con rate
definito dal valore della banda totale meno quella riservata al traffico prioritario e
ceil uguale alla banda totale disponibile.
Il secondo script si occupa di aggiornare i parametri rate e ceil della qdisc HTB
e delle due sottoclassi precedentemente create. L’operazione di aggiornamento della
configurazione del traffic control non causa problemi al traffico in transito.
Il traffico proveniente dalla rete wireless e destinato alla rete wired che attraversa
il core router viene invece gestito una apposita qdisc per renderlo indipendente da
quello destinato agli utenti mobili. Questo accorgimento è dovuto al fatto che nel
testbed utilizzato (descritto nella sezione 5.1) tutti i dispositivi utilizzati, sia router
che access point, sono collegati tra loro attraverso uno switch; per questo ogni router
è dotato di un’unica interfaccia di rete che viene attraversata da tutto il traffico in
uscita, indipendentemente dalla destinazione.
Le soluzioni proposte per stimare il valore di banda da utilizzare nel core router
sono:
• Stimare le condizioni di traffico peggiori e dimensionare a questo valore la
banda in uscita dal core router. Finchè la capacità di trasmissione dell’access
point è maggiore del valore stimato è possibile garantire il traffico prioritario, provocando però spreco di banda in un punto già povero rispetto alla rete
“wired” ethernet. Per far questo si deve valutare il bitrate disponible con molti utenti associati e fissare la percentuale di banda utilizzabile in upload. Per
limitare il traffico in upload si può intervenire solamente nel core router, confidando nei meccanismi propri dei protocolli di trasporto (ad esempio il TCP)
per rallentare il traffico alla sorgente.
• Monitorare i parametri che più influenzano l’ampiezza del canale in down78
stream e utilizzare una funzione empirica per stimare la banda disponibile e
configurare in modo dinamico i parametri del core router. Questa soluzione
sembra difficile da realizzare per la difficoltà sia nel reperire i parametri di
interesse, sia nel creare una funzione empirica che simuli con precisione il
comportamento del sistema.
• Analizzare periodicamente il throughput dell’access point e regolare di conseguenza il filtro del core router. Per poter realizzare un controllo corretto si
deve conoscere anche la quantità di traffico che arriva all’access point dalla
rete fissa per essere trasmesso. Deve essere infatti valutato se viene trasmesso
nel canale radio tutto il traffico ricevuto o solo una parte. Nel primo caso è
possibile aumentare la banda in uscita dal core router, altrimenti deve essere
diminuita al valore supportato dall’access point.
Quest’ultima soluzione è sembrata la più interessante ed è stata studiata in dettaglio. Per calcolare il throughput in ingresso (interfaccia ethernet) e in uscita (interfaccia radio) dall’access point è stato realizzato uno script per shell bash che
controlla periodicamente (ogni secondo) il numero di byte che attraversa le due
interfacce in questione.
Inizialmente questi valori venivano estratti attraverso l’interfaccia HTTP dell’access point, analizzando la pagina network ottenuta grazie al comando wget. Purtroppo l’interrogazione di questo servizio dell’access point comporta un rallentamento della trasmissione sul canale radio. Questo comportamento causa perdita di
pacchetti, in contrasto con gli obiettivi fissati.
È stata quindi utilizzata l’interfaccia SNMP disponibile nell’access point; non
sono stati riscontrati problemi sul traffico in transito dovuti all’utilizzo di questo
servizio. Il comando snmpget consente di comunicare con un dispositivo di rete
utilizzando una richiesta di tipo SNMP GET per ottenere informazioni relative ad
uno o più object identifier (OID) definiti nei Management Information Base (MIB)
gestiti dal dispositivo. L’access point supporta diversi MIB, tra cui il RFC1213-MIB
che contiente le informazioni ifTable.ifEntry.ifOutOctets e ifTable.ifEntry.ifInOctets
relative alle varie interfacce di rete. Il codice OID corrispondente al numero di byte
inviati dalla porta radio è “2.2.1.16.2”, mentre per quelli ricevuti dall’interfaccia
79
ethernet è “2.2.1.10.1”. Analizzando questi valori ogni secondo è possibile ottenere
una stima dei throughput cercati.
I due valori così ottenuti vengono utilizzati per decidere il rate da impostare
nel core router attraverso lo script descritto in precedenza. Il rate deve essere sempre compreso tra il valore fissato per il traffico prioritario ed il calore massimo
sperimentato per il dispositivo (7.5 Mbit al secondo).
La qualità del servizio realizzata con il sistema descritto permette di garantire
l’invio ad un rate fissato dei pacchetti prioritari destinati alla rete wireless. Molte delle applicazioni multimediali che presentano un traffico prevalentemente monodirezionale inviano alcuni pacchetti anche nella direzione opposta. Ad esempio,
visualizzando con QuickTime un filmato codificato a circa 300kbit/s servito dal Darwin Streaming Server, è stato sperimentato un traffico in upstream nell’ordine di 3
kbit/s. Questo serve ad esempio per regolare il rate di invio dei pacchetti da parte
del server. In situazione di congestione del canale radio, le stazioni wireless possono
avere problemi ad inviare rapidamente questi pacchetti, in particolare se le stazioni
stesse che non utilizzano meccanismi di QoS stanno inviando altro traffico. Il ritardo o la perdita di questi pacchetti può causare problemi nella fruizione del servizio,
nonostante le garanzie per il traffico in downstream.
Per limitare i problemi dovuti alla variazione del throughput totale in downstream potrebbe essere utilizzato un meccanismo di controllo dei clienti associati;
in particolare, se il throughput scende sotto una soglia fissata, il sistema potrebbe dissociare alcuni utenti di servizi BE per rientrare nei limiti di funzionamento
previsti. In presenza di più access point le connessioni interrotte potrebbero essere
ripristinate grazie alla associazione ad un altro (Q)BSS meno carico, ottenendo un
meccanismo di load balancing.
Di seguito è riportato un esempio di utilizzo dei meccanismi proposti. Viene
fissato al valore di 4 Mbit/s la quantità massima di banda utilizzabile per il traffico
EF. Questo valore viene utilizzato dal BB per fissare il limite di risorse allocabili
e dall’amministrazione per fissare la banda massima che può essere assegnata ad
un singolo utente. I dati riportati in [34] indicano che il throughput scende sotto
i 4 Mbit/s in presenza di sette o più stazioni associte. In questo scenario possono essere assegnati ad esempio 500 Kbit/s di traffico prioritario a sette differenti
utenti, mentre non è possibile assegnare 250 Kbit/s a quattordici utenti. Probabil80
mente i dati citati, acquisiti utilizzando traffico in upload verso l’access point, sono
peggiori rispetto al caso di utilizzo ipotizzato in questo lavoro di tesi che prevede
la prevalenza di traffico monodirezionale verso le stazioni mobili. Per questo sono
necessari esperimenti che verifichino il comportamento del sistema nello scenario
descritto. Non è stato possibile realizzare tali prove per mancanza di un numero significativo di dispositivi wireless. Questo sistema può consentire l’associazione di
un numero non predefinito di utenti, visto che alcuni potrebbero utilizzare solo una
piccola parte delle risorse disponibili. Il meccanismo di revoca della associazione
ad alcuni clienti deve essere utilizzato solamente quando il throughput segnalato
dall’access point non garantisce l’invio sul canale radio dei 4 Mbit/s garantiti al
traffico prioritario.
4.3.2
Domini DiffServ
In questa sezione viene proposto un metodo per inserire la rete wireless all’interno
della architettura DiffServ realizzata.
Un dominio DiffServ è un insieme di router che realizzano un’unica politica di
qualità del servizio e ogni nodo appartenente ad un dominio deve avere lo stesso
insieme di PHB. In un sistema eterogeneo, come ad esempio una rete mista wired
e wireless, diventa difficile gestire i nodi differenti come appartenenti ad un unico
dominio. Nella parte ”wired” i nodi sono collegati da rete ethernet a 100Mbit/s ed
il traffico è gestito da router linux, mentre i dispositivi wireless comunicano tramite
il protocollo 802.11b con banda nominale di 11Mbit/s (reale meno di 7.5Mbit/s)
e il nodo centrale è rappresentato dall’access point. Se si considera l’insieme delle due parti come un solo dominio e’ necessario elaborare i vari flussi in modo
differente a seconda dei percorsi che dovranno compiere, con il problema di memorizzare le caratteristiche delle varie tratte della rete. Questo implica un aumento
della complessità del BB. È più semplice modellare il sistema come composto da
due domini:
• un dominio per la parte wired, realizzando i PHB che servono al sistema e con
la possibilità di allocare la banda fino a saturare il canale ethernet (ad esempio
con la configurazione del core router proposta nel sottoparagrafo 4.2.3).
81
• una dominio per la parte wireless, con QoS solo nella direzione downstream.
È possibile utilizzare un insieme di PHB differente rispetto al dominio wired.
La banda allocabile in questo dominio è sicuramente minore rispetto alla parte
wired. Come detto in precedenza può essere utile introdurre un core router a
monte dell’access point per garantire la QoS all’interno del dominio.
BB
RAR
Proxy
Core Router
Edge Router
Dominio Wired
RAR
Edge Router
Server Multimediale
BB
Core Router
Dominio Wireless
Access Point
Stazioni mobili
Figura 4.12: Configurazione del sistema con due domini
Ogni dominio necessita di un BB per le funzioni di allocazione delle risorse
e configurazione dinamica dei border router. Per ottentere un sistema completo in
ambiente multidominio è necessario un protocollo di comunicazione interdominio.
Il prototipo realizzato non dispone di questa funzionalità; per questo è stato affidato
al proxy il compito di comunicare con i BB dei due domini per allocare la banda
necessaria al traffico multimediale.
82
In figura 4.12 è rappresentato lo schema proposto. Quando il proxy riceve la
richiesta di un filmato da un utente, dopo aver recuperato le informazioni necessarie
per compilare la RAR, contatta il BB del dominio wireless per allocare la banda
necessaria. Se possiede nella cache il filmato richiesto può servire subito l’utente,
mentre se deve ricevere i dati dal server deve chiedere la configurazione della QoS
anche al BB del dominio wired.
83
Capitolo 5
Risultati sperimentali
In questo capitolo sono presentati i risultati delle prove effetutate per sperimentare
il funzionamento del sistema di gestione della QoS realizzato per la rete wireless.
Questi esperimenti dimostrano inoltre il funzionamento dei meccanismi di QoS abilitati sui computer dotati di software GNU/Linux, utilizzati nel sistema proposto per
elaborare il traffico destinato alle stazioni mobili. Dopo una breve descrizione dei
metodi utilizzati per realizzare la configurazione di rete necessaria e per attivare su
computer portatili le schede wireless PCMCIA a disposizione, vengono illustrati i
test effettuati.
5.1
Configurazione della rete
I computer utilizzati come router DiffServ appartengono ad un’unica rete e sono
connessi fra loro tramite uno switch. Ogni computer dispone infatti di un’unica interfaccia di rete ethernet collegata direttamente allo switch. La comunicazione tra
qualsiasi computer avviene in modo diretto senza attraversare altri computer. Per
ottenere una configurazione di rete che comprende edge router e core router connessi in modo seriale tra loro sono state aggiunte su ogni macchina due interfacce
di rete virtuali (ad esempio eth0:1 e eth0:2). A queste interfacce virtuali sono stati
assegnati indirizzi privati nella classe di indirizzi riservata per le reti Internet private (ad esempio 192.168.0.0/24 [37]), in modo da ottenere sottoreti di classe C
composte da coppie di macchine. Ogni computer risulta in questo modo connesso
84
Capitolo 5. Risultati sperimentali
a due reti private distinte che gli permettono di comunicare direttamente con due
macchine. È stata successivamente modificata la tabella di routing per impostare le
macchine direttamente connesse come gateway per raggiungere le altre reti private.
Utilizzando questa configurazione, in ciascun router il controllo del traffico deve
essere impostato su di un’unica interfaccia di rete, qualunque sia la destinazione del
traffico elaborato.
5.2
Utilizzo di schede wireless su computer Linux
Nelle stazioni mobili sono state utilizzate schede wireless PCMCIA Cisco Aironet
350 Series dotate di firmware 4.25.30, mentre schede con versioni del firmware più
recenti sono state provate senza successo. Per poter utilizzare le schede wireless su
pc linux con kernel 2.4.x sono necessari i seguenti moduli:
• pcmcia_core e ds: servono per poter utilizzare schede PCMCIA;
• airo e airo_cs: driver per le schede Cisco Aironet 34X/35X/4500/4800.
Il caricamento di questi moduli permette il funzionamento corretto della scheda.
Per potersi associare ad un access point può essere necessario impostare la chiave
WEP. Per questo scopo sono disponibili vari strumenti di configurazione presenti
nelle distribuzioni Linux, oppure può essere utilizzato il software Aironet Client
Utility (ACU) reperibile nel sito Internet di Cisco Systems. Questi programmi si
occupano di scrivere il valore della chiave fisicamente nel firmware del dispositivo
che conserva i dati finchè non vengono sovrascritti. In questo modo è possibile
collegare la scheda a vari computer senza dover specificare nuovamente la chiave. Il
valore può essere anche impostato attraverso le interfacce disponibili nel filesystem
virtuale /proc nel seguente modo:
# echo 0 hh:hh:hh:hh:hh:hh:hh:hh:hh:hh:hh:hh:hh > \
/proc/driver/aironet/ethX/WepKey
Il primo numero (nell’esempio 0) indica quale delle cinque chiavi disponibili viene
scritta (numerate da 0 a 4). È successivamente necessario specificare quale delle
cinque chiavi memorizzate deve essere utilizzata (TxKey):
85
# echo 0 > /proc/driver/aironet/ethX/WepKey
Nell’esempio riportato viene scelta la chiave numero 0. Per specificare che si vuole
utilizzare la modalità criptata si utilizza questo comando:
# echo ‘‘WEP: encrypt’’ > \
/proc/driver/aironet/ethX/Config
Per potersi associare ad un access point non resta che attivare l’interfaccia di rete
assegnata alla scheda wireless ed eventualmente richiedere un indirizzo tramite un
client DHCP.
Un computer portatile è stato utilizzato anche per analizzare il traffico in transito sul canale wireless in modalità promiscua, ossia considerando tutti i pacchetti e
non solo quelli destinati al computer stesso. Lo scopo è quello di monitorare continuamente la quantità di dati che viene trasmessa attraverso il wireless per avere informazioni utili durante lo svolgimento dei test. Per abilitare la modalità promiscua
sulle schede PCMCIA utilizzate sono stati utilizzati i comandi seguenti:
# echo ’Mode: r’ > /proc/driver/aironet/ethX/Config
# echo ’Mode: y’ > /proc/driver/aironet/ethX/Config
Per tornare nella modalità normale di funzionamento è sufficiente riscrivere il medesimo file virtuale indicando “Mode: ESS”. Successivamente è necessario abilitare
l’interfaccia wifi (ad esempio “wifi0”) e analizzare il traffico in transito su tale interfacci con tcpdump. Per analizzare il traffico ottenuto in questo modo è consigliata
la versione 0.7.0 di libpcap o una successiva. Può inoltre essere utile l’utilizzo del
software Ethereal per l’analisi dei dati raccolti.
Per far comunicare il computer portatile con la rete wired configurata grazie
al sistema descritto nel paragrafo 5.1, è sufficiente assegnare all’interfaccia di rete
associata alla scheda wireless un indirizzo appartenente alla stessa sottorete del core router direttamente collegato all’access point. L’access point agisce infatti come
bridge, passando i pacchetti tra i segmenti di rete wired e wireless. Per poter comunicare con gli altri nodi della rete wired deve essere specificato nel portatile come
default gateway l’indirizzo del core router collegato all’access point.
86
5.3
Testbed
Il testbed utilizzato è schematizzato in figura 5.1.
Edge Router
Iperf Client port 5000
Iperf Server port 5002
PP4
192.168.1.2
192.168.1.1
Core Router
SNMPget
P6
192.168.3.2
192.168.3.1
192.168.10.2
Parma01
Darwin Streaming Server
Access Point
Sniffer
SNMP
192.168.10.1
QuickTime Player
Armada
Eleonora
Figura 5.1: Schema del testbed utilizzato
L’obiettivo dei test effettuati è stato quello di verificare la QoS sperimentata dal
traffico multimediale RTP per la visione in streaming di un filmato, in condizioni di
congestione della rete wireless. Per far questo sono stati utilizzati:
• un computer (Parma01) per svolgere il compito di Streaming Server;
• un computer (PP4) con funzione di edge router per marcare i pacchetti destinati alla rete mobile e per generare traffico sintetico grazie al software Iperf
[38];
• un computer (P6) utilizzato come core router DiffServ e dotato delle funzionalità descritte nella sezione 4.3.1;
• un access point Cisco Aironet 350 Series;
87
• un computer portatile (“Eleonora”) equipaggiato con una scheda wireless
PCMCIA Cisco Aironet 350 Series, dotato di sistema operativo MS Windows
2000, di un player RTSP QuickTime e del software Iperf ;
• un computer portatile (“Armada”) equipaggiato con una scheda wireless PCMCIA Cisco Aironet 350 Series, su cui è installata la distribuzione Linux Red
Hat 9.0, utilizzato per analizzare in modalità promiscua il traffico sul canale
wireless.
L’edge router marca il traffico RTP che trasporta i dati multimediali secondo il
codice del PHB EF, limitando il segnale video ad un rate di 400 Kbit/s ed il segnale
audio a 128 Kbit/s. Con il codice EF viene marcato anche il traffico generato dal
client Iperf in esecuzione su “PP4” e destinato al server Iperf in ascolto sulla porta
5000 del computer portatile “Eleonora”. A questo flusso viene concessa una banda
di 1 Mbit/s. Il resto del traffico viene marcato con il codice “0” che identifica traffico
best effort.
Il portatile “Armada” è stato utilizzato per ottenere l’andamento temporale dei
seguenti valori:
• throughput totale sul canale wireless;
• throughput del traffico video diretto ad “Eleonora”;
• throughput del traffico audio diretto ad “Eleonora”.
Per far questo è stato utilizzato uno script in linguaggio Perl che riceve in ingresso
l’output di tcpdump, calcola il throughput medio registrato nell’ultimo secondo.
Utilizzando i parametri di ingresso di tcpdump è possibile selezionare solamente i
pacchetti destinati ad una specifica porta, ottenendo il throughput desiderato.
Le prove effettuate sono state realizzate utilizzando un filmato codificato a circa
300 Kbit/s, di cui 128 Kbit/s per il segnale audio, che dura 66 secondi. Il traffico
Iperf diretto sulla porta 5000 di “Eleonora” è di tipo UDP ed ha rate uguale a 1
Mbit/s. Questo flusso serve per ottenere statistiche più accurate rispetto a quelle ottenibili grazie a player multimediali e può rappresentare il traffico di una applicazione multimediale con bitrate costante che non necessita di feedback di informazioni
verso il server. Per simulare la situazione di congestione della banda in downstream
88
verso le stazioni mobili è stato utilizzato traffico Iperf con rate di 8 Mbit/s destinato
alla porta 5001 di “Eleonora”.
I due computer “Armada” ed “Eleonora” sono stati gli unici due dispositivi portatili dotati di scheda wireless disponibili per l’esecuzione delle prove. Per simulare
la variabilità del throughput in downstream è stato utilizzato nell’ultima prova effettuata traffico sintetico in upstream generato da Iperf su “Eleonora” e destinato a
“PP4” (porta 5002).
Durante lo svolgimento delle prove non è stato registrata alcuna associazione di
dispositivi wireless oltre a quelli utilizzati.
5.4
Risultati
Per prima cosa è stato sperimentato il comportamento del sistema in condizioni
di basso carico, trasferendo solamente il traffico multimediale tra “Parma01” ed
“Eleonora”. Successivamente sono stati analizzati i dati relativi alla situazione di
traffico intenso in downstream in tre casi:
1. nessun meccanismo di QoS;
2. con filtraggio del traffico sul core router, basato sui valori di throughput dell’access point;
3. con filtraggio del traffico sul core router, basato sui valori di throughput dell’access point in condizioni di banda in downstream variabile.
In figura 5.2 sono riportate le statistiche fornite dal player QuickTime al termine
della visione del filmato trasmesso nelle condizioni ideali, senza altro traffico sul
canale wireless utilizzato.
Le statistiche riportate indicano che è stata persa una piccola percentuale dei
pacchetti inviati; questa perdita non ha comportato problemi alla riproduzione del
filmato e non ha compromesso il risultato finale. La perdita di pacchetti è dovuta al
filtro impostato sull’edge router, che limita la banda per il flusso video a 400Kbit/s
con burst di 40k e per il flusso audio a 128 Kbit/s con burst di 12k. Questi limiti
sono stati inseriti per evitare che, nella fase di riempimento del buffer, il traffico
utilizzato da una singola sessione possa aumentare a dismisura interferendo con il
89
Figura 5.2: Statistiche della ricezione del filmato in condizioni di basso carico della
rete
resto dei dati in transito. Il buffer è rimasto sempre pieno a parte gli istanti iniziali
e per questo il trasferimento dei dati è stato completato alcuni secondi prima della
fine della riproduzione audio/video.
5.4.1
Assenza di QoS
Durante questa prova non è stato applicata alcuna elaborazione sul core router. L’istante iniziale del test coincide con la richiesta PLAY effettuata dal player su “Eleonora”. Dopo 10 secondi è iniziato il trasferimento di pacchetti UDP, alla velocità
costante di 8 Mbit/s, da “PP4” a “Eleonora” utilizzando Iperf, per la durata di 60
secondi. Dopo altri 10 secondi (al ventesimo secondo dopo l’inizio del test) è iniziato il trasferimento, durato 50 secondi, di pacchetti UDP alla velocità costante di
1 Mbit/s da “PP4” a “Eleonora”, utilizzando ancora Iperf.
In figura 5.3 è riportata la finestra di QuickTime dedicata alle statistiche di riproduzione del filmato. In figura 5.4 sono riportati i valori relativi al throughput
totale sul wireless e al traffico audio/video, campionati grazie allo sniffer, e i valori di throughput, registrati grazie ai server Iperf, riguardanti i due flussi di traffico
sintetico.
90
Figura 5.3: Statistiche della ricezione del filmato in condizioni di congestione senza
QoS
La visione del filmato è risultata quasi totalmente compromessa non appena è
iniziato il traffico di disturbo a 8 Mbit/s. Le statistiche finali hanno infatti segnalato una perdita di pacchetti del 32.57 percento, sicuramente troppo elevata per una
corretta riproduzione. La presenza del traffico generato da Iperf non ha consentito
l’arrivo di dati alla velocità necessaria.
Si può notare che il throughput totale ottenuto sul canale wireless si è assestato intorno al valore di 7.5 Mbit/s non appena è iniziata la trasmissione di dati
da parte di iperf. L’inizio del secondo trasferimento di dati Iperf non ha modificato sostanzialmente la situazione, causando solamente la diminuzione della banda a
disposizione del primo flusso Iperf.
Alla fine della prova è stato registrato per il flusso Iperf trasmesso a 8 Mbit/s
una banda media in ricezione di 6.59 Mbits/s, con la perdita del 17% dei pacchetti
trasmessi. Il traffico trasmesso a 1 Mbit/s è stato ricevuto alla media di 817 Kbits/s,.perdendo il 18% dei pacchetti inviati. Si può quindi affermare che il trattamento
riservato a questi due flussi è stato equo; i pacchetti sono stati infatti scartati nelle
code FIFO interne dell’access point, il quale non ha effettuato distinzioni tra i dati
in transito. La causa della maggiore perdita di dati subita dal traffico multimediale
91
8000
7000
Throughput [kbit/s]
6000
5000
4000
iperf 1 Mbit/s
iperf 8 Mbit/s
traffico sul canale radio
traffico in streaming
3000
2000
1000
0
0
10
20
30
40
50
60
70
Istante di campionamento [s]
Figura 5.4: Throughput per i vari flussi in condizioni di congestione senza QoS
deve essere invece ricercata nel protocollo di comunicazione che risente dei errori
precedentemente riscontrati e necessita di feedback inviati in upstream. Il traffico
sintetico inviato tramite Iperf non risente, al contrario, delle condizioni di traffico sperimentate in precedenza, cercando di spedire in ogni istante la quantità di
dati prefissata. Probabilmente l’utilizzo di traffico di disturbo di tipo TCP, grazie
al meccanismo della contention window, ha un impatto meno dannoso sul traffico
multimediale concorrente.
5.4.2 Presenza di QoS
Questo test è stato realizzato utilizzando la stessa sequenza temporale e gli stessi
flussi della prova precedente, introducendo però le funzionalità di elaborazione del
traffico su core router. Il core router è stato configurato per riservare fino a 2 Mbit/s
di banda al traffico EF, mentre al traffico BE è stato riservato la porzione restante di
92
risorse fino saturare il limite fissato dal meccanismo di stima del throughput disponibile in downstream. Il core router si occupa di prelevare periodicamente tramite
il protocollo SNMP i valori istantanei di throughput “ETH” in ingresso all’access
point sul’interfaccia ethernet e “RADIO” in uscita dalla porta radio. Se “ETH” è
maggiore di oltre 200 Kbit/s rispetto a “RADIO”, si suppone che l’access point non
riesca ad inviare tutto il traffico che riceve attualmente; in questo caso il core router
limita al valore “RADIO” la banda totale del traffico destinato alla rete wireless.
In caso contrario, se l’access point riesce ad inviare tutto il traffico ricevuto, viene
aumentato il valore precedentemente impostato di 200 Kbit/s fino ad un massimo di
7.5 Mbit/s. In questo modo la banda concessa in uscita dal core router può diventare
maggiore di quella utilizzata, garantendo spazio per nuovi flussi e per aumentare la
banda utilizzata dal traffico TCP già attivo. In tabella 5.1 è riportato un esempio di
Ingresso
[Kbit/s]
482
532
3987
3000
2945
3095
3270
3424
3662
3811
3970
4138
4353
4492
4654
4904
5045
5282
5542
3647
Uscita
[Kbit/s]
416
651
3195
3580
2936
3095
3259
3480
3620
3807
3998
4179
4376
4495
4716
4856
5042
5254
4076
3563
Filtro
[Kbit/s]
7680
7680
3195
3395
3595
3795
3995
4195
4395
4595
4795
4995
5195
5395
5595
5795
5995
6195
4076
4276
Tabella 5.1: Esempio di calcolo del valore utilizzato per limitare il traffico in uscita
dal Core Router
93
funzionamento del sistema che calcola il valore utilizzato per limitare il traffico in
uscita dal core router. Nella prima colonna è indicato il throughput stimato in ingresso all’access point, nella seconda quello stimato in uscita e nella terza il valore
calcolato per il core router.
In figura 5.3 sono riportate le statistiche di riproduzione del filmato elaborate da
QuickTime. In figura 5.4 sono riportati i valori relativi al throughput totale sul wireless e al traffico audio/video, campionati grazie allo sniffer, e i valori di throughput,
registrati grazie ai server Iperf, riguardanti i due flussi di traffico sintetico. È inoltre
riportato l’andamento temporale del valore utilizzato per limitare il traffico in uscita
dal core router diretto alla rete wireless.
Figura 5.5: Statistiche della ricezione del filmato in condizioni di congestione con
QoS
Il risultato visivo ottenuto è decisamente migliore rispetto al caso precedente,
anche se alcuni frame risultano danneggiati. La perdita di pacchetti multimediali
registrata è del 4.40%, diminuendo notevolmente rispetto al 32.57% ottenuto senza
QoS. Questo valore non è però sufficiente per offrire un servizio totalmente soddisfacente agli utenti wireless. Come si vede dal grafico relativo al riempimento del
buffer, si sono verificati due brevi periodi di buffer underrun che hanno causato
problemi di riproduzione audio/video.
94
Il rate medio è stato lievemente inferiore a quello registrato senza traffico di
disturbo, ma rispetto a quel caso la trasmissione di dati si è protratta per più tempo,
fino alla fine della visualizzazione.
8000
filtro sul CR
iperf EF 1 Mbit/s
iperf BE 8 Mbit/s
7000
Throughput [kbit/s]
6000
5000
4000
3000
2000
1000
0
0
10
20
30
40
50
60
70
Figura 5.6: Throughput per i vari flussi in condizioni di congestione con QoS
Finchè è stato presente sul wireless solamente il traffico multimediale, l’access
point è riuscito ad inviare senza problemi tutti i dati ricevuti; per questo motivo
il valore di banda totale impostato sul core router si è mantenuto durante i 10 secondi iniziali al massimo previsto, ossia 7.5 Mbit/s. Dopo l’inizio del trasferimento
di dati Iperf marcati BE è stato registrata una differenza di throughput in ingresso e in uscita dall’access point maggiore di 200 Kbit/s, che ha causato un brusco
abbassamento del valore di banda impostato sul core router. Questo abbassamento
ha causato un netto rallentamento al traffico BE, preservando però il traffico multimediale marcato EF. Successivamente le condizioni di traffico hanno consentito il
graduale aumento del traffico inviato dal core router verso l’access point. Solamente
intorno al cinquantesimo secondo dall’inizio del test si è nuovamente verificata una
95
differenza di throughput tra ingresso e uscita dell’access point sufficiente per causare una diminuzione del valore di banda utilizzato nel filtro. Questa diminuzione
ha portato il filtro ad assumere temporaneamente il valore di circa 4 Mbit/s. L’inizio
della trasmissione di dati Iperf marcati EF alla velocità di 1 Mbit/s non ha inciso sul
traffico multimediale, causando invece la diminuzione della banda disponibile per
il traffico best effort. Il traffico Iperf marcato EF si è mantenuto per tutta la durata
della trasmissione intorno al valore nominale di 1 Mbit/s, facendo registrare alla fine
un valore medio pari a 983 Kbit/s con la perdita dell’1.7% dei pacchetti. La media
totale per quanto riguarda il traffico BE è stata di 3.71 Mbit/s. Il traffico totale sul
wireless ha seguito l’andamento del filtro applicato sul core router senza particolari
oscillazioni. Le oscillazioni del rate con cui sono stati inviati i dati multimediali
hanno invece causato l’oscillazione della velocità di trasferimento del traffico di
tipo BE, che si deve adattare alla banda lasciata libera dal traffico prioritario.
L’introduzione del core router ha migliorato notevolmente le prestazioni offerte
al traffico prioritario, con risultati lievemente migliori per il traffico generato da
Iperf rispetto a quello multimediale. La precisione del campionamento dei valori
di throughput dell’access point e del meccanismo di retroazione che consente di
regolare il core router può essere migliorata per diminuire la probabilità di riduzione
ingiustificata della banda concessa.
5.4.3 Presenza di QoS e banda in downstream variabile
Questa prova è stata condotta utilizzando lo stesso sistema di gestione della QoS del
test precedente. L’unica differenza rispetto all’esecuzione precedente consiste nell’aggiunta, tra il trentesimo ed il cinquantesimo secondo, di un flusso in upstream
generato con Iperf tra il laptop “Eleonora” ed il computer “PP4”. Il client Iperf in
esecuzione sul portatile è stato impostato per trasmettere traffico UDP alla velocità
di 5 Mbit/s. Questo traffico è stato utilizzato per alterare durante la prova la banda
disponibile in downstream verso gli utenti wireless, in modo da verificare il comportamento dinamico del sistema retroazionato che regola il traffico in uscita dal
core router. Questa condizione simula la variazione di troughput dovuta al traffico
generato da altre eventuali stazioni associate. Il traffico così generato compete per
l’invio attraverso la scheda wireless in dotazione ad “Eleonora” con i dati genera96
ti dal player QuickTime e destinati allo straming server. Su questo dispositivo non
è presente alcun meccanismo di differenziazione del traffico e quindi i pacchetti
vengono elaborati secondo lo schema FIFO.
In figura 5.7 sono riportate le statistiche di riproduzione del filmato elaborate da
QuickTime. In figura 5.8 sono riportati i valori relativi al throughput totale sul wireless e al traffico audio/video, campionati grazie allo sniffer, e i valori di throughput,
registrati grazie ai server Iperf, riguardanti i tre flussi di traffico sintetico. È inoltre
riportato l’andamento temporale del valore utilizzato per limitare il traffico in uscita
dal core router diretto alla rete wireless.
Figura 5.7: Statistiche della ricezione del filmato in condizioni di congestione e
variazione del throughput con QoS
Per quanto riguarda le statistiche del filmato multimediale restano valide le considerazioni fatte per il test precedente. La percentuale di pacchetti persi è pari a
4.70, lievemente superiore al 4.40% del caso precedente. Anche l’andamento nel
tempo del rate, della percentuale di pacchetti persi e del riempimento del buffer
non si discosta in modo rilevante rispetto alla prova effettuata senza traffico in upstream. Questo dimostra che la variazione improvvisa della banda disponibile in
downstream non ha inciso significativamente sulla trasmissione e sulla riproduzione
del filmato.
97
8000
filtro sul CR
iperf EF 1 Mbit/s
iperf BE 8Mbit/s
iperf upstream 5 Mbit/s
7000
Throughput [kbit/s]
6000
5000
4000
3000
2000
1000
0
0
10
20
30
40
50
60
70
Figura 5.8: Throughput per i vari flussi in condizioni di congestione e variazione
del throughput con QoS
La figura 5.8 mette in evidenza il brusco calo della banda utilizzata sul core
router in corrispondenza dell’istante in cui è iniziato il traffico in upstream. Per
tutta la durata di tale traffico, il valore di banda impostato sul core router è rimasto
intorno a 4 Mbit/s, che corrisponde all’incirca alla banda massima disponibile meno
il throughput realmente utilizzato in upstream. Il traffico in upstream si è infatti
mantenuto intorno ai 3 Mbit/s, facendo registrare un valore medio di 2.89 Mbit/s.
Durante questa prova il traffico Iperf prioritario, nonostante alcune oscillazioni
rispetto al valore nominale di 1 Mbit/s, non ha fatto registrare la perdita di alcun pacchetto. Queste oscillazioni sono potenzialmente dannose per un flusso multimediale
sprovvisto di un adeguato meccanismo di buffering.
98
Capitolo 6
Conclusioni
In questo lavoro di tesi è stato realizzato un prototipo di dominio DiffServ su rete
eterogenea wired e wireless che comprende un sistema software per garantire un
utilizzo semplice, equo e controllato delle risorse disponibili. Le funzionalità di base necessarie alla realizzazione dei nodi di rete DiffServ sono presenti nei computer
dotati di sistema operativo GNU/Linux. In particolare sono presenti discipline di
gestione delle code che offrono buone prestazioni per quanto riguarda il link sharing, cioè la suddivisione della banda disponibile, per garantire l’invio secondo un
rate fissato ai vari aggregati di traffico. Non sono invece disponibili meccanismi per
regolare in modo preciso i valori di ritardo e jitter sperimentati dai vari aggregati di
traffico.
Il bandwidth broker realizzato è dotato delle funzionalità previste per quanto
riguarda l’interfacciamento con l’utente, con l’amministrazione del dominio e con
gli edge router. Sono stati studiati differenti sistemi di interfacciamento tra utenti
e bandwidth broker per semplificare l’interazione e migliorare il controllo da parte
dell’ammistrazione. In particolare è stato realizzato un prototipo che comprende un
proxy che si occupa di richiedere l’allocazione delle risorse intercettando le semplici
richieste di servizio degli utenti (nel caso specifico richieste di video streaming
RTSP). Questa soluzione permette l’utilizzo sia dal lato client che dal lato server di
programmi che ignorano la qualità del servizio, consentendo di servirsi di qualsiasi
prodotto disponibile. Questo modello è applicabile anche in casi differenti dallo
streaming video.
99
Capitolo 6. Conclusioni
È stato studiato il modo per offrire QoS sulla rete wireless utilizzata in modalità
Infrastructure per il traffico proveniente dall’access point e destinato ai dispositivi
mobili. Non è stato possibile utilizzare i meccanismi di QoS descritti nella Deployment Guide [23] che descrive il funzionamento dell’access point utilizzato in questo
lavoro. La sperimentazione ha infatti dimostrato che la conversione tra DSCP e classe di servizio interna all’access point, necessaria per includere il dispositivo in una
architettura DiffServ, non funziona. Per migliorare le prestazioni non soddisfacenti ed offrire un sistema maggiormente configurabile è stato progettato e realizzato
un meccanismo che integra la parte wireless nell’architettura DiffServ predisposta
per la rete wired. In particolare è stato introdotto un core router tra il resto della
rete fissa e l’access point per adattare il traffico diretto ai dispositivi mobili secondo una politica di qualità del servizio. È stato realizzato un sistema in retroazione
che consente di regolare periodicamente i parametri che influenzano l’elaborazione effettuata dal core router in base ai valori di traffico registrati dall’access point.
Questo consente al sistema di adattarsi alla variazione del throughput disponibile
in uscita dall’access point. La sperimentazione effettuata ha dimostrato che questo
sistema riduce sensibilmente la perdita di pacchetti prioritari in caso di congestione, con risultati particolarmente apprezzabili per applicazioni che utilizzano traffico
prevalentemente monodirezionale.
6.1
Sviluppi futuri
Il bandwidth broker necessita di una interfaccia interdominio per poter gestire la
QoS in un ambiente complesso, come ad esempio l’intera rete del campus universitario. Resta inoltre ancora aperto il problema della autenticazione degli utenti,
particolarmente delicato per quelli collegati tramite wireless.
Per quanto riguarda l’interfacciamento tra utente, gestore dei servizi e gestore
della QoS, possono essere sviluppate in futuro le altre soluzioni proposte (modello
Grid-based, gestione della QoS da parte del server, ecc.). La soluzione realizzata
necessita invece di essere completata nella parte relativa alla autenticazione.
Un ulteriore sviluppo potrebbe essere l’introduzione di meccanismi di QoS Routing per impostare l’attraversamento di specifici domini che dispongono delle risorse necessarie per soddisfare le richieste degli utenti.
100
Capitolo 6. Conclusioni
Durante questo lavoro non è stato possibile testare il comportamento del canale di comunicazione wireless in presenza di molti dispositivi associati all’access
point. Sarebbe interessante verificare l’andamento del throughput in downstream
con l’aumentare degli utenti associati, in particolare nel caso di utilizzo di applicazioni multimediali come lo streaming video. In questo scenario potrebbe essere
studiato un meccanismo di controllo delle associazioni e di bilanciamento del carico di differenti access point. Altri elementi utili per questo scopo potrebbero essere
gli Information Element che gli enhanced access point inviano alle stazioni mobili in fase di associazione. Queste informazioni, previste nelle bozze del protocollo
802.11e e supportate dagli access point presenti in dipartimento, indicano lo stato
di carico del dispositivo, consentendo alle stazioni mobili di scegliere l’access point
migliore a cui associarsi.
Restano inoltre da studiare le problematiche relative alla mobilità degli utenti,
che implica la necessità di spostare la configurazione della QoS tra le varie celle
interessate.
101
Bibliografia
[1] J.S.B. Martins. Quality of Service in IP Networks. In Managing IP Networks, chapter 3. P.
Levine, J. Martins, B. Stiller, M.H. Sherif, A. Fumagalli, J. Aracil and L. Valcarenghi, 2003.
[2] Hui-Lan Lu and I. Faynberg. An architectural framework for support of quality of service in
packet networks. IEEE Communications Magazine, 2003.
[3] R. Braden, D. Clark, , and S. Shenker. Integrated Services in the Internet architecture: an
overview - RFC 1633, 1994.
[4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. An Architecture for
Differentiated Services - RFC 2475, 1998.
[5] B.E. Carpenter and K. Nichols. Differentiated services in the Internet. IEEE Proceedings,
90(9), 2002.
[6] Y. Bernet, S. Blake, D. Grossman, and A. Smith. Multiprotocol Label Switching Architecture
- RFC 3031, 2001.
[7] Shaleeza Sohail and Sanjay Jha. The Survey of Bandwidth Broker.
[8] Stefan Mangold, Sunghyun Choi, Peter May, Ole Klein, Guido Hiertz, and Lothar Stibor.
IEEE 802.11e Wireless LAN for Quality of Service.
[9] S. Park, D. Kim, K. Kim, S. Choi, and S. Hong. Collaborative QoS Architecture between
DiffServ and 802.11e Wireless LAN. In IEEE VTC’03-Spring, 2003.
[10] D. Gu and J. Zhang. QoS Enhancement in IEEE802.11 Wireless Local Area Networks. IEEE
Communications Magazine, 2003.
[11] K. Nichols and B. Carpenter. Definition of differentiated services per-domain behaviors and
rules for thek specification - RFC 3086, 2001.
[12] K. Nichols, S. Blake, D. Black, and S. Backer. Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers - RFC 2474, 1998.
[13] Y. Bernet, S. Blake, D. Grossman, and A. Smith. An Informal Management Model for
Diffserv Routers - RFC 3290, 2002.
[14] V. Jacobson, K. Nichols, and K. Poduri. An Expedited Forwarding PHB - RFC 2598, 1999.
[15] J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski. Assured Forwarding PHB Group - RFC
2597, 1999.
[16] J. Heinanen and R. Guerin. A single rate three color marker - RFC 2697, 1999.
[17] J. Heinanen and R. Guerin. A two rate three color marker - RFC 2698, 1999.
102
BIBLIOGRAFIA
BIBLIOGRAFIA
[18] K. Chan, R. Sahita, S. Hahn, and K. McCloghrie. Differentiated Services Quality of service
policy information base - RFC 3317, 2003.
[19] D. Durham er al. The COPS (common open policy service) protocol - RFC 2748, 2000.
[20] J. Case, M. Fedor, M. Schoffstall, and J. Davin. A Simple Network Management Protocol
(SNMP) - RFC 2748, 1990.
[21] B. Teitelbaum and P. Chimento. QBone Bandwidth Broker Architecture. work in progress.
http://qbone.internet2.edu/bb/bboutline2.html.
[22] Cisco AVVID Network Infrastructure Enterprise Quality of Service Design. Cisco Systems,
2002.
[23] Cisco Systems. Wireless Quality-of-Service Deployment Guide.
http://www.cisco.com/en/US/products/hw/wireless/ps430/prod_
technical_reference09186a0080144498.html.
[24] Cisco Aironet Access Point Software Configuration Guide for VxWorks.
http://www.cisco.com/en/US/products/hw/wireless/ps458/
products_configuration_guide_book09186a0080104916.html.
[25] W. Almesberger, J. Salim, A. Kuznetsov, and D. Knuth. Differentiated Services on Linux,
1999.
[26] W. Almesberger. Linux network traffic control — implementation overview.
[27] Linux Advanced Routing & Traffic Control. http://lartc.org/.
[28] B. Hubert. Linux Advanced Routing & Traffic Control HOWTO.
http://lartc.org/howto/.
[29] Hierarchical Token Bucket queueing discipline.
http://luxik.cdi.cz/~devik/qos/htb/.
[30] Differentiated Services on Linux. http://diffserv.sourceforge.net/.
[31] The Linux Kernel HOWTO.
http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html.
[32] Kansas University Bandwidth Broker. http://www.ittc.ku.edu/~kdrao/BB/.
[33] Matteo Merli. RTSP Caching Proxy. http://www.ce.unipr.it/~mmerli/.
[34] Arunchandar Vasan and A. Udaya Shankar. An Empirical Characterization of Instantaneous
Throughput in 802.11b WLANs.
[35] A. Banchs and X. Perez. Providing throughput guarantees in IEEE 802.11 wireless LAN. In
WCNC2002, 2002.
[36] Jangeun Jun, Pushkin Peddabachagari, and Mihail L. Sichitiu. Theoretical Maximum
Throughput of IEEE 802.11 and its Applications.
[37] Y. Rekhter, R.G. Moskowitz, G.J. de Groot, D. Karrenberg, and E. Lear. Address allocation
for private internets - RFC 1918, 1996.
[38] A. Tirumala, F. Qin, J. Dugan, J. Ferguson, and K. Gibbs. Iperf home page.
http://dast.nlanr.net/Projects/Iperf/.
103
BIBLIOGRAFIA
BIBLIOGRAFIA
[39] A. Sundaresan and G. Dhandapani. Diffspec - A Differentiated Services tool. University of
Kansas, 12 1999.
[40] Imad Aad and Claude Castelluccia. Differentiation Mechanisms for IEEE 802.11. In
INFOCOM, pages 209–218, 2001.
[41] Indu Mahadevan and Krishna M. Sivalingam. Architecture and Experimental Framework for
Supporting QoS in Wireless Networks Using Differentiated services. Mobile Networks and
Applications, 6(4):385–395, 2001.
[42] J. Chen, A. Caro, A. McAuley, S. Baba, Y. Ohba, and P. Ramanathan. A QoS Architecture for
Future Wireless IP Networks.
[43] K. Nichols, V. Jacobson, and L. Zhang. A Two-bit Differentiated Services Architecture for
the Internet - RFC 2638, 1997.
[44] J.C. Oliveira, T. Anjali, B. King, and C. Scoglio. Building an IP Differentiated Services
Testbed. In ICT 2001, 2001.
[45] D. Black. Differentiated Services and Tunnels - RFC 2983, 2000.
[46] G. Apostolopoulos, R. Guerin, S. Kamat, A. Orda, T. Przygienda, and D. Williams. QoS
Routing Mechanisms and OSPF Extensions - RFC 2676, 1999.
[47] E. Crawley, R. Nair, B. Rajagopalan, and H. Sandick. A Framework for QoS-based Routing
in the Internet - RFC 2386, 1998.
[48] J. Drake. Linux Networking HOWTO.
http://www.linuxports.com/howto/networking/.
[49] N. Christin and J. Liebeherr. A QoS Architecture for Quantitative Service Differentiation.
IEEE Communications Magazine, 2003.
104

Gestione della Qualità del Servizio su Reti IP Wired e Wireless per

Transcript

Documenti analoghi

Il computer nella vita quotidiana La comunicazione in Rete

QoS e Traffic Shaping - MC-link

Furore Inn dagli americani agli Irollo di Castellammare di Stabia dell

Specifiche tecniche

Lugano, Centro Commerciale Lugano Sud Spazio

NetRisk

Predisposizione Collegamento Internet via Radio nel Condominio

call for posters - Università Cattolica del Sacro Cuore

IP Telephony - MediaNet Comunicazioni

Configurazione Router Sitecom WL 118 e WL 119