Configurazione di nodi wireless con supporto della qualità del servizio

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria delle Telecomunicazioni tesi di laurea Configurazione di nodi wireless con supporto della qualità del servizio Anno Accademico 2003/2004 Relatore Ch.mo Prof. G. Ventre correlatori Ing. M. D Arienzo Ing. M. Ficco candidato Domenico Beneduce matr. 39/1963

2 Indice Introduzione 6 Capitolo 1. Obiettivo della tesi: progetto iniziale L idea iniziale La realizzazione Il Sequence Diagram 14 Capitolo 2. Qualità del Servizio su Internet: IntServ e DiffServ La qualità del servizio Il Modello Integrated Services Il Protocollo RSVP Il modulo Admission Control Il modulo Packet Classifier Il modulo Packet Scheduler L architettura di un Router nel modello Integrated Services Le classi di servizio Controlled Load Service (CLS) Guaranteed Service (GS) Tipologie di applicazioni Applicazioni real time Applicazioni Elastiche Il modello Differentiated Services Il condizionamento del traffico Classificazione dei pacchetti Profilo del Traffico: Meter Marker Sheduler 38 2

3 2.6.6 Policing Policy Shaper Dropper Per Hop Behavior (PHB) Expedited Forwarding (EF) Assured Forwarding (AF) Best Effort (BE) Il protocollo RTP 45 Capitolo 3. La QoS negli end-system La qualità de servizio sulle reti IP L influenza del sistema operativo 53 Capitolo 4. Reti wireless Il protocollo IEEE QoS su reti wireless Il MAC Il MAC e Procedure di handoff Strategie di attivazione dell handoff Schemi di controllo dell handoff Mobile Controlled Handoff (MCHO) Network Controlled Handoff (NCHO) Mobile Assisted Handoff (MAHO) Network Assisted Handoff (MAHO) Schemi di attivazione della connessione Schemi di trasferimento della connessione L handoff a livello Rete Il protocollo IP e gli handoff Il protocollo Mobile IP Il funzionamento di Mobile IP Meccanismi di Agent Discovery Cambiamento di rete Procedura di registrazione presso l Home Agent L IP Mobility ed i messaggi ARP Cellular IP: un approccio all Host Mobility Introduzione a Cellular IP Approccio alternativo alla gestione degli utenti mobili 104 3

4 4.4.3 Modello di rete ad accesso wireless Cellular IP Meccanismi di mapping: Paging Caches e Routing Caches Paging di Cellular IP Routing di Cellular IP Handoff di Cellular IP Problemi relativi al disegno del protocollo Indirizzamento e Migrazione Pacchetti di controllo Configurazione dei nodi Algoritmi dei nodi Realizzazione del protocollo Realizzazione della temporizzazione Realizzazione delle Caches Realizzazione del Paging Conclusioni su Cellular IP 137 Capitolo 5. Access Point con supporto della qualità del servizio: HostAP e HostQs HostAP HostQs: Differenziazione del traffico in WLAN Introduzione a HostQs QoS dell IEEE e: la funzione EDCA Differenziazione del traffico a livello LLC L implementazione di HostQs Risultati del test Conclusioni e sviluppi futuri 159 Capitolo 6. Sviluppo software e misurazioni Modifica del codice di Queue Manager Misurazioni Studio dei parametri statistici Calcolo della varianza approssimata 172 Appendice A. Codici dei programmi 176 A.1 Codice del programma Server 176 A.2 Codice del programma Client 179 A.3 Codice della libreria di servizio 180 A.4 Il Makefile 180 4

5 Appendice B. How-to di installazione 182 B.1 Installazione del sistema di base 182 B.2 Compilazione del kernel 183 B.3 Installazione di HostAP e HostQs 186 B.4 Configurazione delle interfacce 187 B.5 Impostazione del DHCP 189 B.6 Impostazione del NAT 190 Bibliografia 192 5

6 Introduzione In uno scenario in cui la dimensione dei computer portatili diventa sempre più ridotta e la loro presenza sempre più diffusa grazie anche ad un accessibilità dei costi quasi totale, si rende necessaria la possibilità di collegarsi ad una rete - nel più classico dei casi ad Internet - in maniera semplice, veloce e con pochi click e soprattutto senza l impiego di fili. Una possibilità di collegamento senza fili è già offerta in alcuni luoghi - ancora pochi in realtà - come aeroporti o grandi alberghi dove sono presenti zone fornite di un servizio di copertura wireless chiamate hot spot; tale servizio è offerto dai principali gestori di telefonia mobile e per lo più a scopo pubblicitario. In verità l accesso alla rete è efficiente ma abbastanza macchinoso perché c è bisogno dell impostazione di alcuni parametri iniziali che per semplicità di accesso o solamente per comodità, sarebbe bene che fosse eseguita in maniera trasparente all utente. In altre parole, la sola presenza di un determinato computer portatile in una rete dovrebbe essere quasi sufficiente a far partire automaticamente un processo di configurazione di parametri base per la connessione alla rete locale più vicina e, attraverso questa, a Internet. In questa tesi vengono proposti alcuni sistemi per effettuare la connessione wireless in poco tempo e se possibile senza impostazione manuale dei 6

7 parametri; ovviamente un minimo di configurazione sarà comunque necessaria e inoltre si immagina che la presenza di alcuni sistemi hardware e software venga diffusa in aree più estese di quelle classicamente associate alle LAN. Ma il cuore del presente studio è basato sulla configurazione di un Access Point mobile che implementi la gestione della qualità del servizio: attraverso elementi hardware particolari e soprattutto con l aiuto di prodotti software studiati e modificati ad hoc laddove necessario, è possibile fare in modo che un normale computer portatile (un laptop o un palmare) possa essere configurato per funzionare come un nodo di rete, dando la possibilità a qualunque altro nodo all interno di un certo raggio e fornito di una normale scheda di rete wireless, di collegarsi alla LAN più vicina - volendo a Internet - proprio come se a gestire la comunicazione fosse un normale Access Point. Il nodo viene configurato prevedendo un supporto della qualità del servizio, ossia la possibilità di creare classi di utenti, ognuna delle quali associata ad un livello di priorità. La differenziazione tra le classi, ovvero la decisione del livello di precedenza, è stabilita attraverso l analisi di un determinato campo dell header IP; ora, sebbene il campo ToS (Type of Service) sia un byte dedicato proprio a scopi di questo tipo, è sembrato molto più utile distinguere un utente attraverso il suo identificativo più univoco: l indirizzo IP. Una volta che un pacchetto sia giunto al portatile-access Point, invece di essere immediatamente servito, viene inviato ad un blocco studiato apposta che si occupa di leggere l indirizzo IP, decidere quale priorità assegnarvi, quindi riporre il pacchetto nella coda relativa a quel livello di precedenza. A questo punto entra in gioco uno schedulatore che dà al pacchetto un ritardo 7

8 proporzionale alla dimensione della sua coda e a quelle delle code con priorità più alta; solo dopo che il pacchetto avrà risalito tutta la fila, verrà rimandato al punto da cui era stato prelevato e sarà quindi pronto per essere inoltrato. Il blocco dei pacchetti (in altre parole la gestione della qualità del servizio) avviene quindi all interno del nostro nodo in un modo semplice quanto efficace. L efficienza del funzionamento del sistema viene testato con l aiuto di piccoli programmi pensati per questo scopo: una serie di programmi client generano flussi di dati, gli assegnano una priorità e li inviano all indirizzo di un programma server che raccoglie informazioni statistiche sui tempi di consegna e sui ritardi subiti dai dati. Vengono inoltre proposti dei sistemi alternativi per la gestione della qualità del servizio basati su idee innovative che tendono a sfruttare a pieno tutte le potenzialità della rete. Dato il crescente interesse verso le tecnologie senza filo, gli studi e le idee esposte in questa tesi rappresentano un buon punto di partenza per sviluppi futuri: in una visione più generale in cui la presenza di computer portatili configurati come Access Point sia molto diffusa, lo scenario globale cambia completamente. Infatti l accesso wireless può essere fornito non più da un singolo hot spot fissato in un punto ben definito dello spazio ma potrebbe essere affidato ad utenti mobili, dando la possibilità di estendere la zona di copertura wireless su un area tanto estesa quanto il numero degli Access Point permetta. In altre parole, non si può dire a priori quanto sia estesa una LAN wireless perché in ogni punto può esserci copertura fornita da un Access Point che a sua volta si trova nella zona di copertura di un altro Access Point. 8

9 Figura 0.1: Scenario attuale Figura 0.2: Possibile scenario futuro Il disegno generale nel quale si inquadra questo studio è interessante quanto complesso e nel seguito sarà illustrato nei dettagli. In effetti, un computer portatile con queste caratteristiche sbiadisce la distinzione fra terminali e nodi di rete e può essere impiegato nelle situazioni più disparate, cosa che la fantasia e la capacità di degli esperti del mondo dell informatica non tarderà a notare. 9

10 Capitolo 1 Obiettivo della tesi: progetto iniziale L idea che porta alla realizzazione di questo studio di tesi si presenta ambiziosa ed allo stesso tempo di notevole interesse, soprattutto in un epoca come quella attuale, dominata dalla presenza sempre più assidua - e qualche volta anche asfissiante - di apparecchi elettronici delle più svariate forme e dimensioni, che vanno dai personal computer nel classico formato monitor-case-tastiera, ai moderni laptop, ai palmari, ai telefoni cellulari di ultima generazione. Qualunque sia la natura del sistema elettronico, non mancherà mai una caratteristica fondamentale: la possibilità di un collegamento senza fili verso uno o più sistemi dotati della stessa tecnologia o verso una rete locale LAN e verso la rete globale Internet. La capacità di collegamento senza fili a un entità esterna che fino a poco fa restava prerogativa esclusiva dei telefoni cellulari, è ormai una caratteristica richiesta a qualunque computer anche non portatile. Così diventa corredo standard per uffici, aeroporti, hotel e altre strutture concepite per ospitare risorse umane, l offerta di un servizio di accesso wireless per tutti coloro che lo richiedano. Da qui nascono tante altre problematiche di realizzazione basate soprattutto 10

11 sulla gestione delle politiche di alcuni sistemi (nel caso più comune Internet) che erano stati pensati per la comunicazione di utenti inquadrati in uno scenario ben determinato e che si trovano oggi a dover essere convertiti per fornire servizi in scenari del tutto diversi, come le reti wireless. Nasce tra gli altri il problema della differenziazione degli utenti, comunemente identificato con la realizzazione del supporto della qualità del servizio (QoS). Proprio in questa direzione nasce il presente progetto che anche se non realizzato in ogni suo punto, dà un idea di una buona politica di gestione della QoS e fornisce un sistema funzionante di differenziazione degli utenti che può essere utilizzato da solo o può rappresentare un buon punto di partenza per studi futuri. 1.1 L idea iniziale Lo scenario complessivo nel quale si inquadra questa tesi comprende una serie di elementi, a volte anche indipendenti gli uni dagli altri, ma che messi insieme danno una visione generale assolutamente sensata. Si parta immaginando un dispositivo hardware wireless, che può essere governato da qualsivoglia tecnologia; per fissare le idee si pensi ad un elemento Bluetooth capace di gestire una scheda di rete: tale dispositivo sarà l elemento fondamentale per il riconoscimento di un utente. Il dispositivo fornisce una chiave, ovvero un elemento univocamente associato al possessore e leggendo dati dalla scheda di rete, invia ad un Access Point una serie di dati, tra i quali: 11

12 l indirizzo MAC della scheda di rete che gestisce; un ID, cioè la chiave che identifica univocamente un utente. Quest ultimo dato può essere impostato dall esterno fornendo così un duplice vantaggio: il possessore del dispositivo può accedere alla rete con la stessa QoS utilizzando anche terminali diversi; lo stesso dispositivo può essere usato da utenti diversi, ognuno dei quali può usufruire di una propria qualità del servizio. Figura 1.1: Collegamento tra client e Access Point Nel caso in cui l Access Point sia già a conoscenza della ID, potrebbe assegnare a quell utente un livello di priorità alta, cioè dare al traffico generato da quell utente la precedenza rispetto al traffico generato da un cliente con una ID sconosciuta. Si verrà quindi a creare una tabella che associa ad ogni indirizzo MAC un certo livello di priorità: 12

13 ID Già conosciuta Indirizzo MAC Priorità ID1212 Sì Alta ID3434 Sì AA-BB Media ID5656 No 00-DD-EE-FF Bassa ID7878 No Bassa Tabella 1.1: Associazione ID/priorità C è bisogno adesso della scelta di un criterio di associazione della ID/priorità con un parametro caratteristico dello standard di comunicazione IEEE per poter rendere la gestione della qualità del servizio effettivamente implementabile. Benché questa scelta possa essere indirizzata verso tante direzioni, si è scelto di associare la ID/priorità al parametro che negli standard di comunicazione rappresenta l identificativo univoco per antonomasia: l indirizzo IP. 1.2 La realizzazione Per associare una ID/priorità all indirizzo IP, si richiede un servizio speciale al DHCP (Dynamic Host Configuration Protocol): quando richiesto, questo protocollo non fornirà semplicemente il primo indirizzo IP disponibile ma effettuerà una scelta: in base alla ID/priorità rilevata, darà all utente un indirizzo che sarà associato ad una casse di servizio. Supponendo per fissare le idee che le classi di servizio siano 3, all utente verrà dato: 13

14 un indirizzo IP tra X.X.X.1 e X.X.X.10 per una classe a priorità alta; un indirizzo IP tra X.X.X.11 e X.X.X.30 per una classe a priorità media; un indirizzo IP tra X.X.X.11 e X.X.X.30 per una classe a priorità bassa. Le tre classi contengono un numero di possibili clienti che è proporzionale al proprio livello di priorità: la prima classe avrà 10 possibili utenti, la seconda classe 20 e infine la classe a priorità più bassa avrà possibili 30 utenti. Tale ripartizione del numero di possibili utenti risulta lecita se si immagina che gli utenti con priorità alta siano minori in numero rispetto a quelli con priorità bassa. Se una classe risulta saturata mentre le altre possono ancora accettare connessioni, si potrà scegliere di assegnare un indirizzo di classe superiore o inferiore. ID/priorità IP associato utenti possibili Alta IP X.X.X.1 - X.X.X Media IP X.X.X.11 - X.X.X Bassa IP X.X.X.31 - X.X.X Tabella 1.2: utenti per ogni classe di servizio 1.3 Il Sequence Diagram Il Sequenze Diagram graficizza brevemente i passi per realizzare l obiettivo proposto. Le ultime fasi del Server relative a HostAP e Queue Manager verranno 14

15 analizzate nei dettagli nei relativi capitoli quando si esporranno tutte le caratteristiche di questi prodotti software. Figura 1.2: il Sequence Diagram 15

16 Capitolo 2 Qualità del servizio su Internet: IntServ e DiffServ La rete Internet attuale offre un solo servizio di trasporto dei dati che viene chiamato best effort. Questo tipo di servizio non fornisce nessuna garanzia sul comportamento end-to-end della rete, dato che non è possibile fare alcun tipo di ipotesi sulla banda disponibile, sul ritardo di transito o sulla corretta consegna dei singoli pacchetti, se non su base statistica. L utilizzo di applicazioni con esigenze real time rimane quindi confinato nell ambito delle reti locali fino a che la rete Internet non sarà in grado di garantire qualche forma di qualità di servizio. Le alternative principali per fornire servizi di trasporto garantiti sono essenzialmente due: sovradimensionare la rete Internet in modo che anche nelle condizioni di traffico elevato vi siano sempre risorse a sufficienza per soddisfare tutte le richieste; introdurre nella rete nuovi meccanismi per garantire, controllare e tariffare la qualità richiesta, quindi suddividere i servizi disponibili per il trasporto, differenziandoli in base alla qualità che possono fornire e consentire l utilizzo di tutta una nuova serie di servizi commerciali che non possono prescindere da opportune politiche di tariffazione e garanzia di qualità. 16

17 Con riferimento agli standard IETF (Internet Engineering Task Force) sono state proposte una serie di modifiche necessarie per far evolvere rete Internet attuale verso una rete in grado di fornire un supporto di QoS. 2.1 La qualità del servizio Il compito principale di una rete di telecomunicazioni è il trasporto dell informazione da un punto all altro della rete stessa. Le informazioni trasportate sono soggette ad una notevole variabilità; quindi per uno sfruttamento ottimale delle risorse di rete, nasce l esigenza di una diversificazione nel trattamento riservato ai singoli flussi di dati. È evidente che applicazioni di video-conferenza che comportano la generazione di traffico dati audio e video con vincoli di real time, hanno esigenze molto diverse da applicazioni come il trasferimento di file o il servizio di posta elettronica che possono invece accettare un ritardo nella consegna dei dati ma assolutamente non tollerano perdite. Si introduce il termine Qualità del Servizio (QoS) per individuare una corrispondenza tra le esigenze di una data applicazione e il servizio di trasporto che può essere fornito dalla rete di telecomunicazioni. Nel seguito ci si riferirà al termine Qualità del Servizio intendendo la capacità della rete nel fornire e garantire una serie di servizi di trasporto diversificati in termini di banda utilizzabile, ritardo end-to-end, jitter e tasso di errore. Nella rete Internet attuale l unico servizio disponibile è quello di best effort, il cui paradigma si basa sul trasporto dei datagrammi IP quando c è banda disponibile, sull accodamento quando ci sono buffer liberi e sullo scarto quando le risorse di rete sono esaurite. 17

18 2.2 Il Modello Integrated Services Le risorse messe a disposizione dalla rete Internet sono essenzialmente i router e la banda trasmissiva dei link di interconnessione tra le entità costituenti la rete stessa. I router sono caratterizzati da una determinata capacità elaborativa e da buffer che consentono di conservare i dati tutte le volte che non è possibile eseguire un loro reinstradamento immediato. Nel documento Integrated Service in the Internet Architecture [1], redatto in ambito IETF, si propone un estensione dell architettura di Internet e dei protocolli utilizzati per realizzare l integrazione di servizi differenziati per il trasporto di flussi. Questo modello, a cui ci si riferirà in seguito con il nome IntServ, si poggia su due concetti fondamentali: la scelta del ritardo come il parametro privilegiato per definire la QoS: si è dimostrato che un limite più o meno rigido sul ritardo massimo sperimentatile dai singoli pacchetti di dati consente effettivamente di fornire servizi di trasporto garantiti in termini di banda utilizzabile, ritardo end-to-end, jitter e tasso di errore; la scelta del dominio a cui applicare il concetto di classe di servizio: nell Internet attuale, i router che si occupano di instradare i datagrammi dalla sorgente alla destinazione, forniscono un trattamento 18

19 indifferenziato secondo una disciplina di accodamento di tipo FIFO (first in, first out), rendendo di fatto impossibile una qualunque previsione non statistica sul ritardo o sulle perdite end-to-end. Dato che nell insieme di datagrammi trasportati è possibile individuare diversi livelli di correlazione, il modello IntServ introduce il concetto di flusso, inteso come l insieme dei datagrammi scambiati in seguito alla stessa attività d utente, individuabili in modo univoco e caratterizzati dalla stessa Qualità del Servizio. Si osservi che il flusso rappresenta la granularità minima del modello IntServ, dato che è l insieme minimo identificabile di datagrammi IP per i quali è possibile fornire una desiderata QoS. In aggiunta, per modellare le trasmissioni multicast si introduce anche il concetto di sessione, definita come l insieme di uno o più flussi aventi una particolare destinazione ed un dato protocollo. Per una caratterizzazione del flusso si usa il Filter Specificator formato da: l indirizzo IP Sorgente e Destinazione, il tipo di protocollo di trasporto (TCP, UDP, etc.) i porti Sorgente e Destinazione (nel caso di IPv6 è stato previsto nell header un campo apposito di 24 bit chiamato flow-label). Si definisce un modulo, il Packet Classifier, che si occupa di discriminare i flussi provenienti da applicazioni distinte; esso opera senza imporre variazioni ai protocolli utilizzati per il trasporto, dato che le informazioni necessarie sono contenute nell header del datagramma IP. 19

20 Figura 2.1: il Filter Specificator Il modello IntServ prevede di associare ad ogni flusso un oggetto chiamato Flow Descriptor [2] che è formato dalla coppia Flow Specificator (Flow Spec) e Filter Specificator. Il FlowSpec è composto da, due insiemi distinti di parametri che permettono di caratterizzare il flusso in termini di qualità del servizio richiesta e profilo di traffico: TSpec - Traffic Specification [3]: descrive le caratteristiche del flusso dati generato dal nodo trasmettitore, fornendo i parametri di un modello di occupazione di banda noto come token bucket [3]; nel caso del ricevitore (fruitore del servizio) il TSpec definisce il livello di traffico per cui si vuole veder garantita una certa QoS; RSpec - Service Request Specification [3]: specifica la qualità del servizio che l applicazione ricevente il flusso dati vorrebbe veder garantita; l host fruitore del servizio specifica la banda minima di cui ha bisogno, il ritardo e la perdita massima tollerabile per i pacchetti dati. 20

21 Figura 2.2: il Flow Descriptor Una volta stabilite le basi logiche su cui poggia il modello Integrated Services (flusso e massimo ritardo end-to-end) restano da definire i componenti da aggiungere alla struttura di lnternet per ottenere la Qualità del Servizio. Si individuano perciò quattro blocchi fondamentali: un protocollo di segnalazione per la prenotazione delle risorse (attivo su Host e Router); un modulo per la verifica delle richieste fatte alla rete: Admission Control Routine (Router); un modulo per suddividere il traffico in flussi distinti secondo la QoS, il cosiddetto Packet Classifier (Router); un modulo per gestire la QoS richiesta ai vari flussi: il Packet Scheduler (Router); Il Protocollo RSVP Il protocollo RSVP (Resource ReSerVation Protocol) [2] è un protocollo di segnalazione a livello IP utilizzato per comunicare in modo dinamico all interno di una rete la richiesta di servizi di trasporto differenziati per trasmissioni unicast o multicast: tramite una serie di messaggi è possibile dichiarare le 21

22 esigenze in termini di risorse di rete richieste da un singolo flusso, esplicitare alla rete la volontà di riservare queste risorse e comunicare quando le risorse non sono più necessarie. Sarà poi compito del modulo di controllo del traffico rendere operative queste richieste. Quando un applicazione ha intenzione di trasmettere dei dati a cui attribuire una certa QoS è necessario comunicare ai ricevitori ed alla rete questa intenzione: viene inviato un messaggio chiamato PATH che definisce un percorso tra trasmettitore e ricevitore, comunicando al ricevitore e a tutti i router attraversati le esigenze del flusso dati generato dall applicazione. Il ricevitore potrà a questo punto richiedere di riservare delle risorse inviando a ritroso un messaggio di RESV, rendendo esplicita la richiesta di risorse, che affinché diventi operativa deve essere accolta da tutti i router che collegano il trasmettitore al ricevitore. Si intuisce l importanza di fissare una connessione virtuale identificata univocamente dal percorso effettuato dal messaggio di PATH: in questo modo viene meno il paradigma classico delle comunicazioni IP di tipo connectionless, perché per garantire la qualità del servizio si deve fissare un percorso ed allocare nei router attraversati le risorse necessarie. I router RSVP conservano le informazioni riguardanti la qualità del servizio assegnata ad ogni flusso con una tecnica di soft-state, quindi se ricevitore e trasmettitore non inviano periodicamente i messaggi di RESV e di PATH le risorse vengono liberate automaticamente allo scadere di un timeout. Questa tecnica rende il protocollo RSVP estremamente robusto nei riguardi di eventuali perdite di messaggi di servizio e flessibile nella gestione dinamica di variazioni di percorso o qualità del servizio. 22

23 Le caratteristiche principali di RSVP possono essere riassunte nei seguenti punti: protocollo receiver initiated; indipendente dai meccanismi di routing: i messaggi di controllo di RSVP sono incapsulati in pacchetti IP (Type 46) ed instradati come normali pacchetti dati in modo che ci sia una completa indipendenza dai meccanismi di routine) utilizzo di stati soft; disponibilità di diversi stili di prenotazione; Compatibile sia con IPv4 che con IPv Il modulo Admission Control Questo modulo si occupa di verificare se la richiesta di QoS per un dato flusso si può accettare senza che vengano meno le risorse precedentemente allocate. In pratica ogni volta che ad un nodo arriva una richiesta di prenotazione di risorse viene presa una decisione per accettare o rifiutare la richiesta. Questa funzione è particolarmente delicata perché scelte troppo conservative porteranno ad uno sottosfruttamento delle risorse disponibili, mentre una scelta poco conservativa potrebbe far venir meno la qualità del servizio precedentemente garantita Il modulo Packet Classifier Il compito di questo modulo è di suddividere i pacchetti IP che arrivano alle 23

24 interfacce di ingresso in classi opportune in base a criteri locali. Un router di backbone cercherà di suddividere i flussi in poche classi per favorire l aggregazione e ridurre il numero di entità distinte da trattare, mentre router più vicini alla periferia potranno adottare criteri diversi permettendo una maggior differenziazione delle classi Il modulo Packet Scheduler Questo modulo rappresenta la parte più critica di tutto il processo di allocazione delle risorse perché dalla sua realizzazione dipende l efficienza dell intero meccanismo di controllo del traffico: la funzione principale consiste nell instradare i vari flussi di pacchetti utilizzando degli opportuni sistemi di code (Simple Priority Queuing, Class Based Queuing, Weigheted Fair Queuing [4]) in modo da garantire un trattamento differenziato ai singoli flussi. Lo Scheduler può anche svolgere la funzione di policing, cioè esercitare un controllo per impedire che un host immetta in rete un traffico non conforme a quello dichiarato. 2.3 L architettura di un Router nel Modello Integrated Services In figura 2.3, dove viene mostrata l architettura di riferimento di un Router in grado di supportare il modello Integrated Services; sono individuabili due sezioni distinte: il Background Code ed il Forwarding Path posti rispettivamente sopra e sotto la riga orizzontale. 24

25 Figura 2.3 Architettura di un Router nel Modello ISI Il Forwarding Path opera su ogni pacchetto IP e rappresenta la parte operativa del processo di routing. Il blocco di Internet Forwarding analizza l header di tutti i pacchetti IP eseguendo una loro classificazione utilizzata dal successivo modulo di Packet Scheduler. Il Background Code è un insieme di routine che si occupano di gestire le strutture dati necessarie al corretto funzionamento del Forwarding Path. Si possono individuare le seguenti funzioni: Routing Agent: implementa i protocolli di routing gestendo gli opportuni database; Reservation Setup Agent: implementa il protocollo per la gestione della prenotazione delle risorse; il modulo di Admission Control verifica se le richieste di QoS possono essere soddisfatte e successivamente vengono configurati il Packet Classifier ed il Packet Scheduler; 25

26 Management Agent: si occupa del network management: admission control policies, controlled link sharing, etc. Il router risulta quindi l elemento fondamentale per garantire il controllo del traffico a livello di rete. Nello svolgere questa funzione deve poter identificare i singoli flussi per riservare ad ognuno di essi un trattamento ben determinato per garantire il rispetto degli impegni presi nei confronti degli altri elementi della rete. Si definisce stato del router la sua conoscenza sul trattamento da riservare ai singoli flussi dati che lo interessano. 2.4 Le classi di servizio Il gruppo di lavoro IntServ dell IETF ha definito tre classi di servizio [1] che permettono di identificare tre diversi scenari di comportamento end-to-end. Di queste classi solo due implementano un servizio vero e proprio, in quanto la classe tradizionale Best Effort, che può comportare ritardi e perdite impredicibili di pacchetti, rappresenta il servizio che si riceve in assenza di richieste specifiche Controlled Load Service (CLS) La classe di servizio Controlled Load Service [5] fornisce ad un applicazione un comportamento end-to-end che approssima quello ottenibile da una rete non congestionata con servizio best effort. Facendo l ipotesi di assenza di malfunzionamenti della rete, l applicazione può ritenere che: la rete con servizio CLS garantisce una percentuale di perdita di pacchetti 26

27 molto vicina al tasso di errore del mezzo trasmissivo, dato che non si verificano più perdite dovute alla congestione; il ritardo medio dei pacchetti non si scosterà molto dal ritardo minimo che consiste nel ritardo dovuto alla propagazione del segnale nel mezzo trasmissivo più il tempo di processamento delle informazioni nei dispositivi di rete attraversati. Per gestire il servizio CLS è necessario che l applicazione fornisca alla rete le informazioni sul traffico che intende generare (Tspec), in modo che lungo il percorso fatto dai dati siano allocate risorse sufficienti a soddisfare la QoS richiesta. Il servizio CLS è stato introdotto per essere di supporto a tutta una serie di applicazioni che subiscono un degrado notevole delle prestazioni in condizione di overload ma che non richiedono vincoli stringenti sul ritardo massimo sperimentabile dai dati Guaranteed Service (GS) Il servizio Guaranteed Service [6] assicura un ritardo massimo di consegna dei pacchetti IP (ritardo tra sorgente e destinazione) non superiore al guaranteed delivery time, garantendo allo stesso tempo l assenza di perdite di pacchetti dovute ad overflow dei buffer dei router. Per ottenere questo risultato è necessario fissare il percorso che verrà fatto dai dati ed avere dei dispositivi di rete in grado di supportare il Guaranteed Service lungo tutta la tratta interessata. 27

28 Il ritardo sperimentato da un pacchetto che viaggia lungo una rete è composto da due parti: un ritardo fisso (transmission delay), dovuto alla distanza ed ai tempi fissi di elaborazione dei dispositivi di rete, ed un ritardo dovuto all attesa per la presenza di buffer nei router (queuing delay). Il transmission delay dipende dal percorso che viene scelto tra sorgente e destinazione, mentre il queuing delay dipende dal Guaranteed Service, che permette di impostare un valore massimo per il tempo di attesa in coda una volta che si conoscono le caratteristiche del traffico. Questo tipo di servizio è stato pensato per tutte quelle applicazioni che sono intolleranti ad un ritardo eccessivo dei pacchetti: si pensi alle applicazioni di video e audio playback che usano codifiche per le quali i datagrammi arrivati oltre un certo ritardo non sono più utilizzabili per la riproduzione real time. 2.5 Tipologie di applicazioni Per meglio caratterizzare la qualità del servizio è necessario focalizzarsi sulle esigenze delle singole applicazioni. In linea di principio la quantità che più pregiudica le prestazioni di una applicazione è il ritardo che ogni pacchetto dati subisce nel transitare attraverso la rete. Le applicazioni a seconda dell effetto del ritardo dei pacchetti possono essere suddivise in Applicazioni real time ed Applicazioni Elastiche Applicazioni real time Si definiscono applicazioni real time tutte le applicazioni che impongono un 28

29 limite massimo al ritardo subito da ogni pacchetto dati: se un pacchetto arriva con eccessivo ritardo non è più utilizzabile dall applicazione e quindi viene scartato perché privo di valore. Un classico esempio di applicazioni real time sono le applicazioni di signal playback che svolgono la funzione di riprodurre un segnale generato da una sorgente e trasportato dalla rete fino alla destinazione; il segnale trasformato in forma numerica e successivamente segmentato in pacchetti dati, viene trasportato dalla rete che introduce un ritardo aleatorio tra pacchetto e pacchetto. Nel ricostruire il segnale originale, il ricevitore deve rispettare dei vincoli temporali e quindi deve conoscere il ritardo massimo accumulabile da ogni pacchetto per ritardare la riproduzione del segnale della stessa quantità (Offset Delay). Il ritardo massimo può essere dichiarato a priori se è disponibile una conoscenza della rete, oppure ricavato dall analisi dei ritardi dei singoli pacchetti in modo da poter variare l offset delay in modo dinamico. Va precisato che le applicazioni di playback si possono suddividere in tolleranti se accettano una variazione del ritardo massimo o intolleranti se il ritardo massimo deve essere fissato perché non è consentita nessuna forma di distorsione del segnale originale. Tabella 2.1: Esempi di applicazioni con esigenze real time 29

30 Per caratterizzare le applicazioni real time si usano i concetti di latenza e fedeltà. Per latenza si intende il periodo di permanenza di un pacchetto dati nella rete, cioè il ritardo che subisce nella tratta trasmettitore-ricevitore, mentre per fedeltà ci si riferisce alla qualità del segnale riprodotto dall applicazione. La sensibilità alla latenza è tanto maggiore quanto più si richiede l interazione tra i due estremi della connessione: la latenza è più dannosa per una telefonata o una videoconferenza piuttosto che per la riproduzione audio o video, che è invece più sensibile alla variazione della fedeltà. Si può quindi riformulare la definizione di applicazione intollerante come un applicazione che deve riprodurre esattamente il segnale trasmesso, a meno di un inevitabile ritardo temporale, senza alcuna perdita di fedeltà. Quindi un applicazione real time intollerante deve appoggiarsi ad un servizio di trasporto dati che garantisca un ritardo massimo per i pacchetti ed una assoluta mancanza di perdite. Le applicazioni real time di tipo tollerante sono in grado di accettare una variazione dell offset delay, anzi in genere cercano di ricavare questa quantità dall analisi dei ritardi dei singoli pacchetti per ridurre il ritardo con cui viene riprodotto il segnale, nel qual caso si parla di Adaptive Playback. Ne segue che le esigenze di questo tipo di applicazioni sono meno pesanti di quelle viste per le applicazioni intolleranti: rilassando i vincoli sul ritardo viene incrementato il livello di utilizzazione della rete, senza che l applicazione ne risenta in modo pesante. Per questo motivo per applicazione Adaptive Playback si propone un servizio di trasporto analogo al classico Best Effort riferito però ad una rete scarica. 30

31 2.5.2 Applicazioni Elastiche Nelle applicazioni elastiche, al contrario delle applicazioni real time, i dati vengono elaborati a mano a mano che arrivano; quindi l applicazione è in grado di svolgere le sue funzioni anche se alcuni dati arrivano in ritardo. Il ritardo riduce le prestazioni globali dell applicazione, ma non al punto da renderla inutilizzabile: il calo di prestazioni è dovuto al ritardo medio piuttosto che alle code della distribuzione statistica dei ritardi, quindi alcuni pacchetti possono arrivare con un ritardo notevole, ma il valore medio del ritardo deve essere contenuto entro certi limiti. Per questo motivo il servizio più adatto a soddisfare i requisiti delle applicazioni elastiche è sicuramente il Best Effort, con una eventuale differenziazione a seconda della diversa sensibilità alla latenza delle singole applicazioni. Tabella 2.2: Sensibilità alla latenza di alcune applicazioni tipiche 31

32 2.6 Il Modello Differentiated Services L architettura Differentiated Services detta anche DiffServ o DS, viene definita nell RFC2475 dell IETF dove sono descritte tutte le regole che si devono rispettare per garantire l interoperabilità tra i sistemi DS. La caratteristica di questa architettura è rappresentata dal traffico che non è più considerato come un insieme generico di pacchetti che costituiscono un unico flusso che viene trattato in modo best effort, ma la banda complessiva disponibile nei vari collegamenti viene suddivisa in un insieme di flussi caratterizzati da alcuni comportamenti comuni. Al loro interno sono costituiti dei microflussi che rappresentano aggregati di differenti connessioni aventi caratteristiche comportamentali analoghe (stesso BA - Behavior Aggregate). La gestione di un flusso prescinde quindi dalla sua composizione, ossia da come sono organizzati dentro di sé i vari microflussi, in questo modo da un lato si opera trattando analogamente tutti i microflussi appartenenti ad un unico Behavior Aggregate, ma dall altro è necessario che questo flusso aggregato rispetti i livelli di servizio concordati con l utente. Una caratteristica importante per la soluzione DS è la scalabilità, ossia la possibilità di interfacciare tra loro differenti rete DS in sequenza o l una dentro 32

33 l altra, anche senza conoscere nel dettaglio i meccanismi gestionali di ciascuna rete; questo meccanismo è importante nel caso in cui due AS (Autonomus System), che supportano entrambi DS, si interfaccino tra di loro. La rete DiffServ quindi non prevede controlli sul singolo microflusso, ma solo sugli aggregati, pertanto è necessario che verso i nodi più esterni della rete venga previsto un controllo del rispetto dei requisiti che si vogliono mantenere mediante delle policy opportune per evitare in seguito comportamenti imprevedibili. Poiché la rete DiffServ è asimmetrica, ogni connessione è vista come un flusso monodirezionale. I pacchetti vengono quindi classificati e marcati in modo tale da poter essere trattati in modo diverso: chiaramente la differenza di trattamento è imposta dal particolare comportamento di inoltro (PHB - Per Hop Behavior) sui nodi lungo il percorso. C è quindi una sequenza di operazioni che devono essere svolte per garantire un corretto funzionamento di una rete DS. La rete DiffServ è divisa in domini (figura 2.4) e a loro volta i domini si possono suddividere in due insiemi significativi: i domini centrali (CORE); i domini di confine (EDGE). I domini di confine (Edge Router) sono i più delicati per lo svolgimento delle politiche di qualità e di differenziazione dei servizi, in quanto è lì che è necessario classificare i pacchetti, e svolgere altre importanti operazioni come shaping, policing, dropping e remarking. 33

34 Figura 2.4: Architettura di un dominio di rete DiffServ Il condizionamento del traffico Un condizionatore di traffico può contener i seguenti elementi: classifier meter marker shaker dropper Quando i pacchetti escono dal dispositivo di condizionamento del traffico di un edge router, deve essere impostata ad un valore appropriato, un etichetta DS (DiffServ Code Point) per ogni pacchetto. I condizionatori di traffico, che rappresentano la parte più complessa della rete DS, sono normalmente situati sulla frontiera della rete ma non è escluso che possano anche essere posizionati nei nodi interni di un dominio DS o talvolta dentro un dominio non compatibile con DS. La figura 2.5 mostra un diagramma a blocchi di un classificatore e condizionatore di traffico. Questo dispositivo può non essere necessariamente costituito da tutti e quattro gli elementi. Per 34

35 esempio nel caso in cui nessun profilo di traffico sua configurato, i pacchetti passano soltanto attraverso un classificatore e un marker. Figura 2.5: Condizionamento e classificazione del traffico Classificazione dei pacchetti Prima che il traffico di rete riceva un trattamento differenziato è necessario classificarlo, ossia suddividerlo in classi differenziate in base ai comportamenti di inoltro (PHB) che si vogliono garantire, quindi associarlo ad opportune code specifiche per i vari tipi di traffico, per poi effettuare l operazione di marking inserendo un etichetta (DSCP) presente nell intestazione del pacchetto IP che viene riconosciuta in tutta la rete DiffServ, in modo da garantire un trattamento diverso dagli altri pacchetti. Pertanto queste funzioni avvengono ai nodi di ingresso della rete DS. I classificatori selezionano i pacchetti in un flusso di traffico basandosi sul contenuto di una parte dell intestazione del pacchetto. Esistono due tipi di classificatori: il classificatore Behavior Aggregate classifica i pacchetti basandosi solo sull etichetta DSCP; il classificatore Multifield seleziona i pacchetti sulla base di uno o più 35

36 campi dell intestazione, come per esempio l indirizzo IP sorgente e/o destinatario, il campo DS, il protocollo (protocol ID), i numeri dei porti sorgente o destinazione ed altre informazioni. Figura 2.6 : Esempio di un elemento classifier Sarà chiaro che un Classifier considera un flusso di traffico come input e lo dirige al corretto output Profilo del Traffico: Meter Se le proprietà di un flusso di pacchetti non superano certi parametri predefiniti, i pacchetti sono chiamati in-profile; in caso contrario saranno detti out-profile. I profili di traffico specificano le proprietà temporali (rate, burst) di un certo livello di servizio e così forniscono le regole per la determinazione se un pacchetto è in-profile oppure no. Un esempio di profilo di traffico, può essere: max bit rate = 1Mbit/s burst di 2Mbit/s con massima durata di 20 secondi, se non sono entro 1 minuto l uno dall altro 36

37 Figura 2.7: Esempio di un elemento meter La figura 2.7 mostra un elemento meter molto generico: esso considera un flusso di dati come input e decide se quel flusso è conforme o non conforme ad un certo profilo di traffico. È facile capire che l operazione di marking è fortemente influenzata dal metering, infatti subito dopo la misurazione del traffico verranno prese decisioni di dropper o shaping Marker Sulla frontiera (EDGE) di ingresso della rete DiffServ, i pacchetti subiscono il marking: vengono prima selezionati da un classificatore e successivamente marcati opportunamente scrivendo una sequenza di codice sempre all interno dell header, chiamata DS-byte (si utilizza la porzione di campo riservata al ToS/CoS del pacchetto Ipv4/Ipv6). Si tratta di 8 bit, di cui 6 costituiscono il cosiddetto DiffServ Code Point (DSCP), i restanti 2 bit (i meno significativi) sono riservati. Il marking di un pacchetto quindi fa in modo di aggiungerlo ad un particolare flusso aggregato. 37

38 Figura 2.8: DSCP nell header IP Il marker può essere configurato per fare il marking di tutti i pacchetti che gli arrivano ad una stessa etichetta, o può essere configurato per fare marking di un pacchetto ad una o un insieme di etichette utilizzate per selezionare un aggregato in un gruppo, in accordo con lo stato del misuratore. Quando il marker cambia un precedente DSCP presente in un pacchetto in uno nuovo si dice che esso ha subito un remarking Scheduler Lo scheduler attua al suo interno vari algoritmi di selezione che descrivono il modo con cui i pacchetti possono venire trattati dopo essere stati classificati ed opportunamente accodati, determinando in quale ordine ed in che momento i pacchetti che arrivano al suo ingresso sono inviati alla rete. Tali algoritmi sono chiamati discipline di servizio. Sono inoltre inclusi parametri che influiscono sull operazione di uno scheduler: parametri statici come la priorità relativa associata ai vari canali di input, e parametri dinamici come il valore DSCP dei pacchetti presenti all ingresso di uno 38

39 scheduler. Sono possibili quindi diverse discipline di servizio, come: FCFS: first come, first served RB: rated based WFBS: weighted fair bandwidth sharing Policing Il Policing è il processo di eliminazione dei pacchetti (per mezzo di un dropper) appartenenti ad un determinato flusso di traffico in funzione dello stato di un misuratore (meter). Esso è quindi costituito da un insieme di regole che devono essere rispettate per mantenere la proporzione voluta fra i volumi di traffico che devono occupare l intera banda disponibile di un collegamento ed è pertanto uno dei metodi che si utilizzano per realizzare il condizionamento del traffico. Per mantenere all interno la semplicità della rete DS, è fortemente consigliabile effettuare l operazione di policing solo nei nodi di ingresso Policy Può succedere che i pacchetti che sono in eccesso ad un certo profilo di traffico possano subire diversi trattamenti. Con l impostazione delle policy è possibile stabilire i limiti per i vari profili di traffico e le azioni da intraprendere tra le seguenti: scarto (dropping) remarking trasmissione come Best Effort 39

40 Quando vengono intraprese azioni diverse dall eliminazione dei pacchetti, come il remarking dei pacchetti in eccesso, è consigliabile utilizzare un nuovo DSCP che ha un comportamento associato differente, magari meno privilegiato rispetto al precedente; solitamente inoltre si utilizza come nuovo comportamento quello standard che identifica il traffico di default, chiamato Best Effort. In questi casi nasce un pericolo: è possibile che venga sovvertito l ordine con cui arrivano i pacchetti e questo infatti può mettere in crisi il meccanismo di gestione della congestione. Infatti alcuni pacchetti che andrebbero eliminati, nel caso in cui vengano rimarcati come Best Effort, possono subire dei ritardi troppo elevati dovuti ai diversi comportamenti di inoltro (PHB) che subiscono e rischiano quindi di arrivare anche con ritardi consistenti rispetto agli altri, introducendo meccanismi di ritrasmissione che non creano alcun beneficio. Per risolvere questo problema quindi è necessaria un accurata gestione delle policy e un continuo monitoraggio della rete. Le operazioni di policy solitamente sono svolte nei nodi di confine ed in particolare nei cosiddetti ingress nodes, per garantire un equa ripartizione delle risorse disponibili tra i diversi domini che generano del traffico Shaper Lo shaper ha il compito di ritardare qualcuno o tutti i pacchetti in un flusso di traffico cercando di mantenere l ordine all interno dello stesso microflusso in modo tale da fornire un profilo di traffico compatibile con il tipo di servizio che si vuole offrire. 40

41 Uno shaper normalmente ha un buffer a lunghezza finita ed i pacchetti possono essere limitati se in esso non c è spazio sufficiente per mantenere tutti quelli che devono essere ritardati. In ogni caso viene suggerito di evitare per quanto possibile l eliminazione dei pacchetti in quanto lo shaper serve per evitare che le policy successive eliminino i pacchetti poco distribuiti, che si presentano cioè sotto forma di burst. Essenzialmente ci sono tre tecniche per implementare il traffic shaping: Leaky bucket Token bucket Flow specification Dropper Il dropper elimina qualcuno o tutti i pacchetti in un flusso di traffico senza però cambiare l ordine di arrivo per mantenere il flusso con un profilo di traffico compatibile. Da notare che un dropper può essere implementato come un caso particolare di uno shaper attraverso la regolazione della lunghezza del buffer dello shaper a zero o a pochi pacchetti Per Hop Behaviors (PHB) Quando un pacchetto viene classificato all interno di un router, viene differenziato rispetto agli altri in base all etichetta, ovvero dal valore del campo DS. Questa può essere vista come divisa in due parti: la prima parte viene utilizzata per scegliere la coda di appartenenza del pacchetto; la seconda per 41

42 eseguire una differenziazione tra i pacchetti appartenenti alla stessa coda, nel caso si verifichi una congestione. Ognuna delle code presenti in un router è collegata ad una particolare classe di servizio, quindi ad un Per Hop Behaviors (PHB), e le proprietà di queste code, come l ampiezza di banda o il ritardo medio, dipendono dal meccanismo di scheduling adottato. Il PHB non è altro che una descrizione della regole di smistamento del traffico assegnate a tutti i pacchetti aventi stesso valore DSCP. Si descrive nel dettaglio tre differenti tipologie di PHB: Expedited Forwarding (EF) Assured Forwarding (AF) Best Effort (BE) Expedited Forwarding (EF) L Expedited Forwarding PHB (EF) è un servizio che fornisce all utente una percentuale minima garantita per l utilizzo del collegamento. L EF si presenta quindi come la forma di traffico privilegiato a cui si fornisce quindi un minimo ritardo, un jitter e una minima perdita di pacchetti. Per poter garantire al traffico EF i requisiti minimi di basso delay e bassa delay variation, bisogna fare in modo che la permanenza all interno della coda sia minima; pertanto il compito del manager della rete deve essere quello di determinare un valore limite alla lunghezza delle code, fino al punto in cui si abbia perdita di pacchetti molto bassa. Infatti è preferibile perdere un pacchetto fra tanti, piuttosto che rallentarlo in una coda lunga. 42

43 E importante notare che la dimensione della coda dipende dal tipo di traffico EF che si intende trasportare, cioè dalla composizione dei microflussi che compongono l aggregato EF; per cui è necessario monitorare i pacchetti trasmessi da questa classe di servizio, in maniera da mantenere mediamente la velocità dei pacchetti del flusso EF in arrivo sempre minore di quella con cui vengono smaltiti Assured Forwarding (AF) L Assured Forwarding PHB (AF) è un servizio piuttosto complesso nella cui specifica può essere osservato che la classe delle azioni standard è stata ripartita nel seguente modo: 4 classi indipendenti ciascuna classe in tre livelli di precedenza Questa specifica indica quattro classi di traffico, per ognuna delle quali è garantita una minima quantità di banda e di buffer; si tratta quindi di requisiti non stringenti come invece si era osservato nell EF, ma comunque migliori rispetto al Best Effort. Tabella 2.3: Schema di assegnazione delle classi secondo il PHB Assurded Forwarding 43

44 La tabella che mette in relazione il DSCP della classe con il corrispettivo valore di precedenza di scarto. La suddivisione viene fatta chiamando ciascun comportamento con il simbolo Afij con 0<i<4 e 0<j<3; quindi il pedice i indica la classe e il pedice j il livello di precedenza. Le quattro classi definibili sono indipendenti tra loro, quindi un flusso che viene assegnato ad una classe non può essere rimarcato su una classe diversa. Per rispettare le specifiche sul DSCP, una classe Afi è caratterizzata da comportamenti associati a caratteristiche di inoltro superiori rispetto ad una classe Afj quando i>j. La precedenza di eliminazione invece è una caratteristica specifica di ogni classe e può essere più alta o più bassa. Essa serve soprattutto per permettere all interno di una stessa classe ed in caso di congestione, diversi comportamenti con caratteristiche di inoltro differenziate. Normalmente all interno della classe AF è consigliabile l uso di due precedenze in caso di rare situazioni di congestione, e tre nel caso di forti e prolungate situazioni di blocco del corretto funzionamento della rete. All interno di una stessa classe la precedenza di eliminazione serve per stabilire parametri di accodamento e di scarto dei pacchetti differenziati Best Effort (BE) Il Best Effort (BE) rappresenta il comportamento associato al traffico non privilegiato, cioè che non viene trattato per soddisfare requisiti particolari, ma a cui possiamo comunque associare una banda minima garantita con opportune policy per garantirne l inoltro. 44

45 Quando all ingresso di un edge router si presenta del traffico che non rispetta le condizioni imposte dai filtri (ossia nessun campo dell intestazione del pacchetto è configurato per la rete DS), viene automaticamente assegnato ad un profilo di traffico di tipo Best Effort. 2.7 Il protocollo RTP Per rendere più agevoli le operazioni svolte dalle applicazioni real time è stato introdotto il protocollo di trasporto RTP (Real-Time Protocol) che si appoggia al protocollo UDP ma aggiunge una serie di nuovi servizi: numerazione sequenziale dei pacchetti trasmessi; gestione del timestamping per ricavare la temporizzazione corretta dei dati; identificazione del traffico trasportato (audio, video) e della codifica usata (MPEG, H.261, ecc.); controllo della qualità del servizio resa disponibile dalla rete. Si osservi che il protocollo RTP non assicura nessuna qualità del servizio ma pone in parte rimedio ai problemi dovuti al ritardo aleatorio dei pacchetti dati perché fornisce all applicazione una serie di informazioni che consentono di migliorare la riproduzione del segnale. Alcuni applicativi si appoggiano per il trasporto dei dati proprio al protocollo RTP, permettendo di snellire la struttura dell applicazione, a discapito di un aumento in termini di banda occupata a causa dell overhead dovuto ai protocolli di trasporto. 45

46 Capitolo 3 La QoS negli end-system In questo capitolo si cercherà di spiegare come può essere gestita la qualità del servizio sui nodi terminali di una rete; verranno presentate le principali soluzioni oggi presenti negli scenari classici evidenziandone i vantaggi e i limiti e le idee proposte per un miglioramento delle prestazioni. 3.1 La qualità del servizio sulle reti IP IP (Internet Protocol) è un protocollo di tipo connectionless, cioè senza connessione. Questo protocollo non richiede che tutti i pacchetti attraversino lo stesso percorso, bensì la decisione d instradamento viene presa in maniera indipendente dai pacchetti stessi, tipicamente in funzione delle condizioni di traffico presenti nella rete. Questo garantisce una robustezza maggiore alla rete nei confronti d eventuali crash di nodi intermedi di un percorso. Contemporaneamente però il protocollo IP non fa alcun riferimento al trattamento esplicito del traffico. L unica modalità di trasmissione di dati prevista da tale protocollo è quella best effort. Tale modalità di trasmissione, 46

47 pur prestando un elevato grado di robustezza, mal si adatta ad applicazioni di tipo real time. La nascita di questo tipo di applicazioni - in particolare delle applicazioni multimediali - ha fatto sentire sempre di più la necessità di trovare delle soluzioni capaci di garantire comunicazioni interattive caratterizzate da una certa Quality of Service. Le esigenze legate alle applicazioni multimediali hanno spinto il gruppo di lavoro IETF a realizzare un modello che cercasse di superare i limiti di quello corrente senza però sconvolgere la struttura stessa di Internet [1]. Quello che si è proposto il gruppo di lavoro IntServ, è di modificare l odierna infrastruttura di Internet al fine di poter fornire garanzie di Quality of Service. Il modello proposto cerca di offrire tre servizi di base: servizi best effort servizi real time servizi di controllo della banda disponibile L assunzione di base del modello Integrated Service è la limitata capacità di trasmissione dei link: una conseguenza di ciò è che il numero di flussi real time che un link può sopportare è limitato. Da queste prime assunzioni si può intuire che il modello IntServ fornisce ai router la capacità di riservare risorse in modo da fornire una ben determinata qualità del servizio per specifici flussi. Un altra assunzione del modello IntServ è che sia il traffico real time che quello differito debbano usare le stesse infrastrutture di rete; in tal caso si dovrebbe progettare un unico stack di protocolli che usi un singolo Internet layer per entrambi i tipi di traffico. 47

48 Una possibile infrastruttura che realizzi le ipotesi poste dal modello IntServ è costituita da quattro nuovi componenti: un packet scheduler un packet classifier un insieme di admission control un protocollo per la prenotazione delle risorse. Di questi quattro componenti i primi tre costituiscono il modulo di Controllo del Traffico (Traffic Control) ossia il componente del router che si occupa di garantire le differenti qualità del servizio ai flussi che lo attraversano. Figura 3.1: Architettura RSVP negli host e nei router L unico componente a non essere incluso nel Traffic Control è il protocollo di prenotazione delle risorse; la presenza di questo protocollo è legata alla necessità di memorizzare uno stato nei nodi della rete per ogni flusso 48

49 prenotato. Il protocollo funziona inviando una serie di messaggi sulla rete, che informano i nodi intermedi della presenza di un nuovo flusso prenotato, permettendo al packet scheduler di trattare i pacchetti appartenenti a questo flusso in maniera da garantire la qualità del servizio. Nel modello non è specificato come effettivamente è fatto questo protocollo, anche se di fatto quello che sembra essere destinato ad essere utilizzato è il protocollo RSVP (Resource reservation Protocol) [7]. Il modello IntServ prevede una serie di classi di servizio che fanno riferimento fondamentalmente al ritardo di trasmissione: Guaranteed Service [8]: impone al flusso di dati generato da un applicazione, un limite superiore sul ritardo di trasmissione end-to-end cui un generico pacchetto può essere soggetto a causa delle attese nelle code degli elementi di rete; in più fornisce garanzie sulla banda passante assegnata al flusso; non agisce né sullo jitter né sul valore medio di tale ritardo; Controlled Load [5]: offre alle applicazioni un sevizio che approssima le caratteristiche di un flusso best effort in condizioni di rete scarica. Si assume in particolare che: o un alta percentuale dei pacchetti raggiungerà la destinazione; o il ritardo di trasmissione di questi pacchetti non eccederà il ritardo minimo sperimentato dai pacchetti consegnati con successo. Bandwidth Recovery [9]: ha come principio base quello di recuperare la banda assegnata in eccesso ai flussi appartenenti alla classe Guaranteed Service. Il modello a servizi integrati [10][11] si presta all impiego in una serie di 49

50 interessanti scenari applicativi. Esso tuttavia sfruttando in maniera intensiva le informazioni di stato, presenta problemi di scalabilità, il che contrasta nettamente con l elevato tasso di crescita della rete Internet. Diventa dunque necessario concepire un modello alternativo che non memorizzi nei nodi della rete informazioni sullo stato dei singoli flussi ma gestisca il traffico in maniera aggregata. Su questo paradigma è fondato il modello elaborato dal gruppo di lavoro Differentiated Services [10], nel quale l aggregazione è ottenuta sfruttando un apposito campo DS inserito all interno del pacchetto IP. Il modello di riferimento DiffServ è basato su un modello costituito da domini: un flusso dati proveniente da una certa sorgente entra in un dominio DS (DiffServ) e una volta classificato come appartenente ad una certa classe di traffico e sottoposto ad un processo di condizionamento, viene aggregato a tutti i flussi appartenenti alla stessa classe di traffico. All interno del dominio, viene identificato mediante il campo DS e viene trattato secondo il per-hop-behavior (PHB) associato al codice DS. Quando un entità richiede un servizio ad un fornitore di servizi DiffServ, tra i due viene stabilito un contratto in termini di livello del servizio offerto detto Service Level Agreement o SLA. Questo contratto specifica inoltre quale deve essere il profilo del traffico generato da chi usufruisce del servizio e come deve essere trattato se esso non coincide con il profilo stipulato. I servizi offerti hanno due caratteristiche fondamentali: si riferiscono al traffico in una sola direzione e fanno riferimento ad aggregati di traffico. Una parte importante dell SLA è il Traffic Condition Agreement (TCA): esso 50

51 specifica in dettaglio i parametri che caratterizzano il livello di servizio e tali parametri comprendono: valori indicanti caratteristiche del servizio in termini di performance, come throughput, probabilità di perdita dei pacchetti, latenza; i profili di traffico a cui si deve aderire affinché il servizio possa essere fornito in maniera corretta; la disposizione sul traffico così detto out-of-profile, ossia quando la banda utilizzata supera quella prenotata; la parte di traffico in più è proprio quella detta fuori dal profilo ; caratteristiche di marking: i pacchetti da trasmettere vengono preventivamente marcati allo scopo di distinguerli nel tragitto tra i due end-point; caratteristiche di shaping: ossia si cerca di rendere il traffico uniforme e quindi senza fenomeni di burst. Il Service Level Agreement specifica inoltre altri parametri più generali quali: affidabilità di condizioni critiche, legate per esempio al re-routing dovuto a danneggiamenti di nodi intermedi; servizi di crittografia; vincoli di instradamento; meccanismi d autenticazione; meccanismi di monitoraggio del traffico offerto; tariffazione. Le architetture IntServ e DiffServ sembrano rappresentare due soluzioni completamente opposte al problema dell offerta di servizi di comunicazione caratterizzati da QoS. 51

52 Ognuna delle due presenta però una serie di problematiche: sostanzialmente il problema del modello IntServ/RSVP è la scalabilità, dovuta alla memorizzazione di uno stato per ogni flusso; il problema del modello DiffServ è che l aggregato non è adatto ad offrire servizi di tipo quantitativo, dove servizi qualitativi sono servizi del tipo: il 90% del traffico in-profile subirà al massimo 50ms di latenza. Il DiffServ sembra tuttavia essere la soluzione più adatta ad essere realizzata in tempi ragionevoli, anche se è importante assicurare che i meccanismi di host e router già esistenti basati sul modello IntServ, possano interoperare con i meccanismi di reti basate sul modello DiffServ. Un possibile modello che prevede la coesistenza di rete IntServ e DiffServ è costituito da una rete di transito (Transit Network) basata sul modello DiffServ e da un certo numero di rete periferiche (Stub Networks) basate sul modello IntServ. In un modello del genere gli host utilizzano RSVP per effettuare le richieste di QoS; tali richieste, oltre a generare messaggi RSVP, invocano il modello di controllo del traffico locale. Gli edge router, ovvero i router terminali, fanno invece da punti di connessione tra le reti periferiche e le reti di transito. Tuttavia è spesso conveniente separare questi elementi in due parti: una parte di tipo RSVP-capable, che si affaccia sulla rete periferica e una parte DiffServ-capable, che si affaccia sulla rete di transito. 52

53 Figura 3.2: Coesistenza tra IntServ e DiffServ 3.2 L influenza del sistema operativo Sebbene i due modelli standard IntServ e DiffServ propongano una soluzione al problema della qualità del servizio relativa alla gestione delle risorse di rete nei nodi intermedi (router), non è trattato in maniera altrettanto efficace la gestione delle risorse sull end-system (host). In sostanza l end-system è considerato come un semplice punto nel modello della rete e non come un sistema a sua volta complesso che necessita di gestire un numero notevole di risorse. Recenti ricerche [12] hanno evidenziato come, al fine di fornire concrete garanzie di QoS per applicazioni distribuite di tipo delay-sensitive, risulti fondamentale considerare un modello di QoS che includa al suo interno sia le caratteristiche della rete che del sistema operativo usato. Ad esempio, per alcune applicazioni real time che richiedono servizi audio/video, risulta fondamentale non solo domandare delle risorse alla rete, come l allocazione di una certa banda, ma è anche necessario configurare in 53

54 maniera opportuna il sistema operativo degli host, come la schedulazione dei processi, l assegnazione della priorità dei pacchetti, in modo tale da garantire una corretta tempificazione della trasmissione e della ricezione dei pacchetti delle applicazioni che sono eseguite sull end-system. Il sistema operativo ha dunque il compito di gestire (coordinare ed allocare) le risorse del sistema (memoria, accesso alle periferiche, tempo di CPU). Tale gestione si rende necessaria per due ragioni fondamentali: in primo luogo perché il numero di risorse presenti nel sistema, essendo questo limitato, rende necessario un controllo sulle richieste multiple di una stessa risorsa, ad esempio un disco, un interfaccia seriale, un interfaccia di rete, ecc; in secondo luogo perché è necessario controllare l accesso, richiesto da parte di uno o più processi utente, a risorse critiche o condivise come ad esempio le memorie condivise, le code di messaggi, le strutture dati di un processo, ecc. Di seguito sono descritti i compiti del sistema operativo ed inoltre sono elencate le attività di cui il sistema operativo è responsabile per la loro gestione: la gestione dei processi: o creare e deallocare i processi di utente e di sistema; o schedulare i processi; o fornire i meccanismi per la sincronizzazione dei processi; o fornire i meccanismi per la comunicazione tra processi; o fornire i meccanismi per la gestione dei deadlock; la gestione della memoria centrale: o tenere traccia di quali parti della memoria sono attualmente utilizzate e da chi; 54

55 o decidere quali processi debbono essere caricati in memoria quando vi sia spazio disponibile; la gestione della memoria secondaria: o gestire ed allocare lo spazio libero; o scheduling del disco; la gestione dei file: o creare e cancellare i file e le directory; o fornire le primitive per la manipolazione di file e directory; o mapping dei file sulla memoria secondaria; o backup dei file su dispositivi di memoria stabili. Inoltre il sistema operativo deve: fornire un meccanismo di protezione che controlla l accesso da parte dei programmi, dei processi e degli utenti alle risorse del sistema; fornire un interprete dei comandi, il quale costituisce l interfaccia tra l utente ed il sistema operativo; gestire il sistema di I/O che ha il compito di nascondere all utente le caratteristiche dei dispositivi hardware. Nella figura 3.3 viene riportato uno schema a blocchi semplificato dell architettura di un generico sistema operativo. Un importanza fondamentale va data allo scheduling dei processi ed al meccanismo di I/O relativamente alla condivisione delle risorse nei sistemi operativi: si ritiene che questi meccanismi siano le principali cause di ritardi nella comunicazione all interno degli end-system. 55

56 Figura 3.3: Struttura a blocchi di un kernel Molti dispositivi hardware (dispositivi di memoria di massa, disk driver, interfaccia di rete, ecc.) sono nascosti all utente grazie meccanismi offerti dal SO, come l interfaccia socket ed il sottosistema di I/O. Per capire la complessità di un end-system si può pensare ad esempio allo scheduling dei processi che dipende dal tipo di programma da eseguire e dagli obiettivi della politica di scheduling. Il tempo d esecuzione di un programma è generalmente composto da una parte dovuta al tempo d elaborazione di CPU e da un altra dovuta al tempo di elaborazione per eseguire le istruzioni di I/O. La politica di scheduling 56

57 tipicamente ha il compito di bilanciare l utilizzazione delle risorse in base al tempo richiesto da un applicazione al fine di completare il proprio task. La priorità di un processo è periodicamente ricalcolata in base a vari parametri, come l intervallo di tempo in cui esso occupa la CPU, la quantità di memoria che esso occupa o richiede per l esecuzione, e così via. Un esempio è il real time scheduling, il quale deve assicurare che il processo finisca entro uno specifico deadline o in un particolare ordine. Il sistema operativo 4.4BSD ad esempio non implementa il real time scheduling. La politica di scheduling del 4.4BSD [13] assegna inizialmente ad ogni processo la massima priorità e permette ad un processo di essere eseguito per un fissato time slice. Durante l esecuzione del processo la sua priorità viene abbassata, cosicché il processo che utilizza più a lungo la CPU avrà un priorità che si abbassa rapidamente mentre i processi che rimangono inattivi hanno una priorità che aumenta. Quando questi ultimi sono pronti per essere eseguiti possono prelazionare le risorse al processo in esecuzione ammesso che questo abbia una priorità più bassa. La priorità del processo dipende da due valori p_estcpu e p_vice. Il valore p_estcpu fornisce una stima della recente utilizzazione della CPU da parte del processo; il valore p_nice è modificabile a livello d utente e varia tra -20 e 20 (il valore normale è 0). La priorità complessiva del processo viene ricalcolata periodicamente in base a questi valori. Solaris 2.x [14] è un sistema multithreaded e multiprocesso e quindi il suo scheduler di processo deve supportare tali caratteristiche. Il risultato è uno scheduler molto efficiente per l esecuzione di processi real time. Lo scheduling 57

58 dei thread è basato sulla priorità e su classi di scheduling. Il sistema organizza e classifica i thread in quattro classi: interattivi (IA), timesharing (TS), real time (RT) e thread di sistema (SYS). All interno d ogni classe è assegnata una priorità al thread. I thread TS sono eseguiti per un periodo di tempo al termine del quale, se non hanno completato il loro task, vengono schedulati a favore di un altro thread. Ad ognuno di essi è assegnato un time slice la cui lunghezza varia in base alla priorità del thread. Comunque la priorità del thread è modificata ad ogni cambio di contesto per evitare fenomeni di starvation in cui un thread monopolizza l uso di una risorsa del sistema. La classe SYS è usata per eseguire processi di sistema; i thread in questa classe hanno una priorità fissata e non posseggono un time slice. Essi sono eseguiti finché non sono completati, oppure finché gli viene prelazionata la CPU da un thread (a priorità maggiore) della stessa classe. I thread d utente non possono essere schedulati o assegnati alla classe SYS. I thread della classe RT posseggono una priorità fissata e un time slice. Essi sono schedulati in base alla priorità. Anche Linux [15] è un sistema operativo multithreaded e multitask. La politica di scheduling può assumere uno dei seguenti valori SCHED_OTHER (la politica di default); SCHED_FIFO; SCHED_RR; le ultime due individuano delle politiche speciali per applicazioni time critical. Queste politiche consentono di sospendere i processi di tipo SCHED_OTHER. Un 58

59 processo SCHED_FIFO può essere sospeso solo da un processo con priorità più alta, ma un processo SCHED_RR, se necessario, sarà sospeso per condividere il tempo di esecuzione con altri processi che hanno la stessa priorità. Linux assegna inizialmente ad ogni processo una priorità intermedia, a meno che non venga richiesta dall utente una specifica priorità. Durante l esecuzione la priorità viene modificata dinamicamente. Come in 4.4BSD e Solaris 2.x esiste un valore di priorità detto nice che è modificabile a livello d utente e varia tra -19 e 19. Anche in Linux il valore nominale di nice è 0. Maggiore è la priorità nice associata ad un processo e più il sistema operativo tenterà di abbassare la priorità interna associata allo stesso. Ciò e dovuto alla politica alla base dello scheduling di Linux: tutti i processi devono essere trattati in modo quanto più equo possibile. Il problema di garantire parametri di qualità del servizio nella comunicazione end-to-end richiede una diversità di risorse; tra queste le risorse di rete rappresentano solo una piccola parte. Le altre risorse, come la capacità d elaborazione (CPU), I/O caching, I/O devices, memoria paginata, memorie ausiliarie (buffer e memoria video), periferiche (videocamera, microfono) ecc., devono essere gestite in accordo con la rete al fine di garantire il comportamento desiderato. Nella figura 3.4 viene mostrato come le esigenze di QoS delle applicazioni non riguardano solo i parametri di QoS della rete (throughput, latency, jitter, lost rate) ma anche quelli del sistema operativo come la priorità assegnata ad un processo, il time slice (quanto di tempo in cui la CPU è assegnata ad un dato processo), la priorità dei pacchetti trasmessi, ecc. Di conseguenza, i parametri di QoS forniti a livello di applicazione vengono in parte tradotti in parametri di QoS per il sistema operativo e parte in parametri di QoS per la rete. 59

60 Figura 3.4: Parametri di QoS delle applicazioni Si potrebbe pensare di migliorare la comunicazione tra processi remoti ottimizzando la gestione delle risorse dell end-system locale e in particolare i meccanismi di I/O offerti dal sistema operativo. La schedulazione dei pacchetti all interno dello stream rappresenta la reale difficoltà per garantire pienamente alcuni parametri di QoS nei sistemi host, più della schedulazione dei processi. Risulta quindi necessario estendere il processo di Quality of Service Management anche all interno dell end-system. Il compito di tale processo è quello di ottimizzare, in base al livello di servizio richiesto dall applicazione, l utilizzo delle risorse dell end-system e i meccanismi offerti dal sistema operativo in accordo con la rete. Il QoS Management deve essere in grado, attraverso dei processi di Admission Subsystem e di Resource Scheduler, di fornire garanzie alle richieste di risorse. Attraverso il processo di prenotazione delle risorse un applicazione può 60

61 richiedere risorse ed ottenere una risposta dal sistema da parte dell Admission Subsystem il quale determina quante e quali risorse servono per soddisfare la richiesta. Sarà poi compito del Resource Scheduler ottenere una corretta suddivisione delle risorse tra le applicazioni ed in particolare offrire una sufficiente garanzia della loro disponibilità. Esso effettua un processo di scheduling che consiste nella determinazione della disponibilità di risorse in un particolare istante di tempo. Se ci sono sufficienti risorse disponibili, il Resource Scheduler restituisce una conferma all Admission Subsystem il quale accetta la richiesta dell applicazione. Nella figura 3.5 è rappresentato un modello di QoS Management che comprende l end-system. Tale modello prevede anche un processo di prenotazione delle risorse coordinato e controllato delle risorse stesse non solo della rete, ma anche di quelle offerte dal sistema operativo. Figura 3.5: End-System QoS Management 61

62 Capitolo 4 Reti wireless Le tecnologie per la comunicazione senza fili 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 connettivitá 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 Il protocollo IEEE Nel 1990 venne costituito il primo gruppo di lavoro 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: a : è lo standard di trasmissione ad alta velocità (54 Mbit al 62

63 secondo) sulla frequenza 5 GHz. I problemi legati a questa specifica non sono pochi, ad esempio non è prevista alcuna compatibilità con b, che era già molto diffuso al momento dell approvazione di a. 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 sicuramente influenzato negativamente lo standard a, che lavorando sulla frequenza 5 GHz, eviterebbe eventuali interferenze con forni microonde o dispositivi Bluetooth e permetterebbe una trasmissione con meno disturbi b: è attualmente lo standard piú diffuso; consente trasmissioni a 11 Mbps sulla frequenza di 2,4 GHz. Dal momento che è ormai diffuso con una certa capillarità sul territorio mondiale (soprattutto USA, Europa e Giappone) l IEEE sta rivolgendo i propri sforzi principalmente sulla realizzazione di standard ad esso compatibili, come l g, ormai pronto ad arrivare sul mercato. Alcuni produttori hanno sviluppato una tecnologia proprietaria chiamata b+, che comunque non è certificata dall IEEE e che permette di trasmettere fino a 22 Mbps c/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 e: anche questo gruppo di lavoro, che si occupa della QoS, non ha completato le proprie attività. Si lavora sul livello MAC per aggiungere funzionalità multimediali alla tecnologia Una volta approvato questo standard riguarderà tutte le specifiche di trasmissione 63

64 (802.11a/b/g) e permetterà di sfruttare il wireless anche all interno di apparecchi multimediali f: è 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 g: è l ultimo gruppo costituito per la definizione di nuovi parametri di trasmissione sulla frequenza 2,4 GHz. Questo standard, totalmente compatibile con b, è capace di trasmettere fino a 54 Mbps utilizzando la stessa tecnica di modulazione di a. Come già detto le trasmissioni su 2,4 GHz sono ad alto rischio di interferenza, per questo si pensa che g sia uno standard di transito verso una futura specifica che permetterà di migrare sulla piú sicura e versatile frequenza dei 5 GHz h: si sta tuttora lavorando per la ridefinizione della frequenza di trasmissione sui 5 GHz, per diminuire le emissioni di onde radio da parte dei dispositivi i: questo gruppo di lavoro sta lavorando all implementazione di sistemi di sicurezza per che si affida attualmente al semplice Wired Equivalent Privacy (WEP), un meccanismo che prevede la possibilità di proteggere i dati trasmessi criptandoli tramite chiavi. Alcuni miglioramenti sono stati già implementati e in alcuni casi già disponibili 64

65 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 j: questo gruppo, non più attivo, si è occupato della progettazione di una specifica unica, a livello nazionale, per LAN wireless alla frequenza di 5 GHz QoS su reti wireless Le reti WLAN sono considerate come un Ethernet senza filo 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 e 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 e nelle bozze e [16][17] Il MAC Il protocollo MAC 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 Coordination Function (PCF) basata su un protocollo di tipo poll- 65

66 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 non-preemptive (ad esempio con una coda FIFO). Il meccanismo del controllo di accesso del canale è schematizzato in figura 4.1. Figura 4.1: Accesso al canale DCF Quando un pacchetto MAC esce dalla coda, deve attendere finché non si liberi 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 66

67 è 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 CW min, mentre limite massimo che può assumere in caso di insuccessi è definito da CW max. Nel caso in cui un pacchetto arrivi in una coda vuota e il canale è libero da un tempo maggiore di DIFS, il pacchetto viene inviato immediatamente. Per offrire un supporto alla QoS, seppur in modo limitato, è stato definito il Point Coordination Function (PCF). Il PCF permette alle stazioni mobili di avere accesso al canale wireless con diversa priorità, grazie ad una stazione Point Coordinator (PC) che svolge la funzione di coordinamento. Il PCF ha una priorità maggiore rispetto al DIFS, 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 [16] Il MAC e Il gruppo di lavoro e 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 67

68 l Enhanced Distributed Coordination Function (EDCF). Le stazioni che operano con il protocollo e 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 ad esso associate forma un Basic Service Set (BSS), mentre se questi componenti sono compatibili con le specifiche del e l insieme viene chiamato QoS Basic Service Set (QBSS). Figura 4.2: Categorie di accesso della EDCF 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. 68

69 Una stazione e deve avere almeno quattro categorie d accesso (AC) e al massimo otto, una per ogni priorità. Ogni categoria d accesso corrisponde ad una variante estesa della coda FIFO presente nel DCF (figura 4.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 utilizzati sono CW min [AC], CW max [AC] e AIFSD[AC], quest ultimo utilizzato in sostituzione del DISF presente nel DCF. L AIFSD è calcolato in questo modo: AIFSD[AC] = SIFS + AIFS[AC] SlotTime I valori di CW min [AC], CW max [AC] e AIFSD[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 e utilizzarli 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 [18] sono riportati i risultati di alcune simulazioni effettuate sul meccanismo EDCF. 69

70 4.2 Procedure di handoff Quando un utente mobile si sposta, tipicamente si trova nella condizione di dover lasciare l area di copertura radio del suo fornitore di servizi per entrare nell area servita da un altro provider. Occorre quindi gestire questo tipo di transizione denominata handoff o handover. Per poter capire meglio cosa si intende per handoff, è opportuno distinguere tra due tipologie principali [19],[20]: si verifica un Intra-Segment Handoff quando il terminale si sposta in un area servita da più celle della stessa natura di rete; questo tipo di handoff avviene molto spesso spostandosi con un terminale GSM e passando da una zona di copertura di una stazione base ad una zona servita da un altra. In questo caso vengono attivate delle procedure di Intra-Segment Handoff che permettono al terminale mobile di spostare il suo punto di accesso alla rete e che venga garantita la qualità del servizio prevista nel passaggio da una stazione base all altra; si verifica un Inter-Segment Handoff quando il terminale si sposta in un area servita da più stazioni base, ad esempio quando si muove in un area coperta dal servizio GPRS verso un altra area coperta da servizi WLAN e ci si troverà nelle condizioni di eseguire un handoff tra elementi di reti differenti. Il terminale in tal caso dovrà prevedere un sistema 70

71 d accesso multi-segmento. Quando il terminale si sposta dalla zona servita dal GPRS a quella servita dalla WLAN dovrà attivare delle procedure di Inter-Segment Handoff per assicurare che le comunicazioni attivi rimangano tali. Quindi l Intra-Segment Handoff è applicato correntemente nelle reti cellulari commerciali mentre l Inter-Segment Handoff, che sarà oggetto di discussione in seguito, non è attualmente molto utilizzato. Per essere eseguito, il processo di handoff richiede innanzitutto la conoscenza dello stato dei link radio ed eventualmente la possibilità di prevedere come evolveranno in futuro. La conoscenza dello stato delle connessioni può permettere di effettuare delle scelte e quindi di eseguire il passaggio della connessione da un link ad un altro reputato più conveniente. Da ciò si evince che il processo si può pensare divisibile in tre fasi: una fase di Information Gathering, nella quale vengono raccolte informazioni sulla qualità radio dei segmenti d accesso; una fase di Decision, in cui sulla base delle misure raccolte si decide se è necessario eseguire l handoff, cioè spostare la comunicazione dal segmento corrente ad un altro dei segmenti disponibili; una fase di Execution: una volta presa la decisione viene stabilita una nuova connessione sul segmento scelto e la vecchia connessione viene rilasciata. La qualità del processo di handoff dipende molto da come e con che cura vengono eseguite queste fasi: in particolare la fase di Information Gathering presuppone una scelta attenta dei parametri radio da considerare ed altrettanta 71

72 importanza è data all interpretazione di tali parametri Strategie di attivazione dell handoff L attivazione del processo di handoff può avvenire per varie ragioni: la prima è il mero spostamento di un utente da una zona di copertura ad un altra ma può essere anche generato a causa della degradazione del segnale radio e può essere attivato da procedure di gestione della rete. Di seguito si riportano le diverse condizioni che possono attivare il processo di handoff: le variazioni dei link radio percepiti possono determinare la necessità di eseguire l handoff; ad esempio se il livello del segnale radio ricevuto in una certa zona diminuisce troppo, significa che verosimilmente stiamo uscendo da questa zona di copertura e quindi si rende necessario il trasferimento delle connessioni su un altro link più affidabile; la necessità di eseguire un cambio di segmento può nascere anche da condizioni della rete fissa; ad esempio se la rete attuale è congestionata può essere conveniente spostare le connessioni su un segmento più scarico; non tutti i segmenti wireless sono in grado di assicurare la stessa qualità del servizio e quindi possono essere adatti o meno ad essere usati per determinate applicazioni per cui anche l utente, richiedendo un servizio particolare, può determinare la necessità di spostare le sue connessioni su un segmento piuttosto che su un altro; un altra motivazione per eseguire un handoff è quella di prevedere degli eventi; ad esempio, conoscendo l attuale direzione e posizione dati 72

73 facilmente ottenibili utilizzando un sistema GPS (Global Positioning System) - e conoscendo l ambiente si può sapere in anticipo se il terminale mobile sta uscendo dalla zona di copertura del segmento nel quale si trova in un determinato momento e quindi attivare la procedura di handoff Schemi di controllo dell handoff Esistono diverse modalità di controllo dell handoff che si differenziano le une dalle altre per la quantità di segnalazione, per le prestazioni e per la complessità richiesta agli apparati della rete o del terminale mobile. Di seguito si riporta uno schema delle differenti strategie. Handoff Schema Controllo Handoff Schema Attivazione Connessione Schema Trasferiment o Handoff Controllato Da Rete Handoff Controllato Da Mobile Handoff Assistito Da Rete Handoff Assistito Da Mobile Handoff Verso Dietro Handoff Verso Avanti Soft Handoff Hard Handoff Signalling Diversity Switched Diversity Combined Diversity Schema 4.1: Strategie di handoff Si vede che esistono diverse metodologie di controllo dell handoff che si basano su chi esegue il controllo del link radio e su chi esegue la decisione. 73

74 Si possono distinguere quattro schemi di controllo dell handoff Mobile Controlled Handoff (MCHO) Lo schema di controllo MCHO prevede che il terminale mobile esegua tutte le azioni; ossia è il terminale mobile ad effettuare le misure sui diversi segmenti wireless ed in base a queste è sempre il terminale mobile a prendere la decisione di effettuare l handoff; in questo modo otteniamo che la segnalazione tra la rete e il terminale mobile relativa all handoff è praticamente nulla. Il lato negativo di questo schema è che le decisioni sono prese considerando lo stato di un solo link radio, ovvero quello detto downlink, e non viene considerato l altro capo della connessione, il cosiddetto uplink, che potrebbe essere influenzato da fenomeni di shadowing e di fading. Inoltre, questo schema comporta una maggiore complessità del terminale mobile. Utilizzando questo schema si ottiene un handoff molto veloce; questo metodo è utilizzato dal Digital Enhanced Cordless Telecommunications (DECT) che presenta tempi di handoff compresi trai 100 e i 500 ms Network Controlled Handoff (NCHO) Questo schema di controllo prevede che la rete si occupi sia di acquisire le informazioni relative ai segnali radio, sia di prendere la decisione di effettuare un handoff. Questo metodo permette di avere un basso signalling tra rete e il terminale e permette di semplificare notevolmente i terminali mobili dato che il carico elaborativo per quanto riguarda l handoff, è tutto 74

75 concentrato sulla rete fissa. Un limite è nel fatto che basando le decisioni sulle sole misure di segnale in uplink non si riesce ad un quadro completo dei link radio e quindi si possono prendere decisioni poco affidabili. Altro problema è la lentezza dell algoritmo: infatti la rete corrente non ha la capacità di misurare le risorse radio delle altre reti d accesso e quindi le procedure di handoff richiedono un notevole volume di segnalazione tra la rete corrente e le altre reti Mobile Assisted Handoff (MAHO) In questo schema la decisione è presa solo dalla rete ma le misure sui link radio sono effettuate da entrambe le entità: la rete effettua misure sull uplink e il terminale mobile sul downlink; queste vengono mandate al nodo di rete per essere processate. La frequenza con cui il terminale mobile effettua le misure sul link è molto importante perché una frequenza troppo bassa può fornire dati obsoleti, mentre una frequenza troppo alta può creare un traffico di segnalazione troppo elevato rispetto al traffico dati utente e quindi ridurre le prestazioni della rete. Questo schema è affidabile anche se non molto veloce e presenta una complessità modesta per il terminale mobile ma alta per il nodo di rete. Una rete che utilizza questo schema è la GSM 75

76 Network Assisted Handoff (NAHO) In questo schema la decisione è presa solo dal terminale mobile ma le misure sui link radio sono effettuate da entrambe le entità: la rete effettua misure sull uplink e il terminale mobile sul downlink; le misure effettuate dalla rete devono essere trasmesse al terminale mobile con opportuni messaggi di segnalazione. Lo schema proposto è molto affidabile e veloce dato che le decisioni sono prese solo dal terminale mobile; ma come nel caso MAHO, si genera un traffico di signalling abbastanza pesante ed una elevata complessità del terminale mobile. La tabella seguente riassume le principali caratteristiche degli schemi di controllo visti. Schema MCHO NCHO MAHO NAHO Processo di handoff Centralizzato Centralizzato Decentralizzato Decentralizzato Complessità del terminale Alta Bassa Moderata Alta Velocità dell handoff Veloce Lento Lento Veloce Dimensione del signalling Contenuta Contenuta Alta Alta Affidabilità Moderata Moderata Alta Alta Tabella 4.1: Confronto tra gli schemi di handoff 76

77 4.2.3 Schemi di attivazione della connessione Per avviare o trasferire una connessione è necessario uno scambio di segnalazione tra il terminale mobile e la rete. Nel caso di un trasferimento di connessione la segnalazione può essere instradata sul nuovo canale oppure sul vecchio canale che dovrà in seguito essere rilasciato. Otteniamo quindi due metodi: il metodo Backward Handoff che utilizza il vecchio canale di comunicazione per scambiare la segnalazione con la rete; questo metodo non è molto affidabile perché se il vecchio link deve essere abbandonato a causa di instabilità, non vi è assicurazione che la procedura di signalling vada a buon fine prima della caduta del link provocando in tal caso la perdita delle connessioni aperte; il metodo Forward Handoff prevede di utilizzare il nuovo link per scambiare la segnalazione con la rete; in tal caso anche la caduta improvvisa del vecchio link non influenza il completamento della procedura e quindi il trasferimento delle connessioni sul nuovo segmento Schemi di trasferimento della connessione Il trasferimento di una connessione da un link ad un altro può essere eseguito in diversi modi; la classificazione tiene conto di come vengono gestite le risorse radio e del modo in cui si instrada la segnalazione. Si individuano tre categorie principali: un primo metodo, il Soft Handoff, si presenta quando in corrispondenza dell handoff, le risorse radio relative al vecchio link vengono rilasciate 77

78 solo quando il nuovo link è attivo; questo metodo permette di eseguire un handoff completamente trasparente all utente. In relazione a come viene trasferito il signalling, nel Soft Handoff si distinguono due casi: o se la segnalazione passa su uno solo dei link attivi si parla di Switched Diversity o se la segnalazione passa su entrambi i link contemporaneamente si parla di Combined Diversity; La realizzazione del Soft Handoff presenta molti problemi legati alla sincronizzazione della segnalazione nel caso di handoff tra link eterogenei. Una soluzione è data dalla metodologia Signalling Diversity: con questo sistema per la segnalazione viene creato un canale apposta che fa coesistere insieme il vecchio ed il nuovo link; su questo canale viaggia la segnalazione necessaria ad istaurare una nuova connessione e a trasferire i flussi dati utente, in modo che tutto sia trasparente all utente stesso, e quella necessaria al rilascio della connessione abbandonata; un altro metodo è l Hard Handoff: si verifica quando il vecchio link viene rilasciato prima che il nuovo venga attivato; in questo caso lo spostamento del punto di accesso, da una rete all altra provoca l interruzione del servizio. La rete GPRS adotta algoritmi di Hard handoff L handoff a livello Rete Fino ad ora si è discusso dell handoff dal punto di vista metodologico ed 78

79 architetturale e si è parlato di connessioni e di segmenti wireless eterogenei; ora analizzeremo come si instaura una connessione e come si può trasferire una connessione attiva da un segmento wireless ad un altro Il Protocollo IP e gli handoff Il protocollo di rete più diffuso è senza dubbio l IP (Internet Protocol); esso è il protocollo principale del livello 3 dell architettura TCP/IP [21]. È un protocollo semplice, non connesso e non affidabile cioè non garantisce che l informazione spedita arrivi a destinazione; il suo compito principale è instradare i messaggi sulla rete. La comunicazione tra due host attraverso una rete generica formata da host e router, è eseguita tramite lo scambio di pacchetti; questi pacchetti contengono l indirizzo IP della sorgente e l indirizzo IP del destinatario. Il singolo pacchetto si trova ad attraversare durante il suo percorso molti router che devono essere in grado di sapere come instradare il pacchetto. Questa decisione è presa in relazione alla tabella di routing che ogni router possiede e che contiene le associazioni tra rete di destinazione e di interfaccia a cui devono essere inviati pacchetti. Partendo dall host sorgente, ogni nodo della rete sa a quale nodo vicino deve essere instradato il pacchetto per raggiungere la destinazione. Questo metodo, prevede che ogni router mantenga una completa tipologia della rete in modo da conoscere la destinazione di ogni singola sottorete; questo può andare bene per reti limitate, ma quando si considerano reti di decine di migliaia di nodi, diventa indispensabile ricorrere ad un architettura di tipo gerarchico; si pensa così di dividere la rete in varie Regioni. Quindi un utente comunica con tutti gli altri della rete attraverso il suo indirizzo 79

80 IP. Se questo host vuole muoversi deve utilizzare una connessione wireless con la rete e se questa connessione non è grado di servirlo in tutti i suoi movimenti deve dotarsi di più connessioni senza filo di tipo eterogeneo. Un terminale del genere dovrà perciò avere un interfaccia per ogni rete wireless a cui collegato. Ogni interfaccia ha caratteristiche dipendenti dal link radio considerato ma queste differenze sono limitate dal livello fisico e da quello Data Link; esse sono trasparenti rispetto al livello rete: ad ogni interfaccia è quindi assegnato un indirizzo IP compatibile con la sottorete del relativo segmento wireless. Un terminale siffatto sarebbe quindi raggiungibile da una rete differente utilizzando ogni volta un indirizzo IP differente e questo di fatto lo renderebbe inutilizzabile! La soluzione a questo problema semplice ed è ottenibile utilizzando il protocollo Mobile IP di cui si parlerà ampiamente in seguito. Il problema dell handoff, limitatamente all esecuzione dello stesso, può essere risolto impiegando il protocollo Mobile IP e modificando le tabelle di routing del terminale. 80

81 4.3 Il protocollo Mobile IP L importanza della mobilità nelle reti informatiche cresce di pari passo allo sviluppo delle tecnologie di comunicazione wireless ed alla diffusione dei mezzi di comunicazione portatili quali laptop, telefoni cellulari, computer palmari. Questa richiesta di mobilità di comunicazione ovunque e comunque e di interconnessione globale si basa su reti terrestri preesistenti, collegate tra loro con mezzi diversi e gestite con politiche diverse. Internet invece utilizza come protocollo di rete il protocollo IP. Quando l IP fu implementato, non si prese in considerazione il problema della mobilità dei terminali poiché date le dimensioni dei computer dell epoca, essi erano necessariamente fissi. Quando un terminale di rete si sposta da un luogo ad un altro, vale a dire se non si trova più connesso al link corrispondente al prefisso di rete del suo indirizzo IP, il protocollo IP prevede che il nodo sia considerato come non più raggiungibile; vale a dire che i pacchetti spediti a quel nodo non saranno più giudicati consegnabili e saranno scartati. Per fare in modo che il nodo possa riprendere a comunicare dalla sua nuova locazione, è necessario modificare le tabelle di routing di quei nodi che si occupano dell instradamento dei pacchetti indirizzati verso quel determinato nodo mobile. 81

82 Questa soluzione presenta notevoli problemi di scalabilità: ogni qualvolta un terminale mobile si sposta, bisogna modificare la configurazione di tutti i router attraversati dal flusso di pacchetti diretti quel terminale e ciò deve avvenire per ogni singolo utente mobile che si sposta. Un altra soluzione al problema sarebbe quella di cambiare l indirizzo IP del nodo mobile e renderlo compatibile con la rete corrente. Anche questa soluzione presenta dei problemi: cambiare l indirizzo IP significa chiudere tutte le connessioni attive nel momento del passaggio da una rete all altra; e poi cambiando l indirizzo IP al nodo mobile, bisognerà aggiornare tutti gli altri nodi che vogliono comunicare con lui. Una soluzione efficiente e semplice al problema è data dall introduzione di un nuovo protocollo basato su IP: il Mobile IP. Il Mobile IP (Mobile Internet Protocol) [22] è stato sviluppato nel 1996 per assicurare la mobilità di un utente: rappresenta un estensione del protocollo di rete IP pensata per permettere proprio la mobilità di un utente; è una soluzione scalabile, robusta e sicura e permette ai nodi mobili, anche durante lo spostamento da un link all altro, di mantenere attive tutte le comunicazioni in corso. In seguito si vedrà che l utilizzo di tale questo protocollo è sconsigliato nei casi in cui la rete da gestire sia molto estesa e verrà proposta una soluzione per aggirare il problema utilizzando un altro protocollo, il Cellular IP, che sarà di supporto al Mobile IP. L utilizzo del protocollo Mobile IP è trasparente ai protocolli di livello superiore ed è altrettanto trasparente nodi e ai router attraversati dai flussi dati. Il Mobile IP è un protocollo semplice, che richiede pochi messaggi di signalling, 82

83 riservando in tal modo poca banda al protocollo stesso: questo è utile quando si utilizza, come accade spesso per i sistemi mobili, un link di connessione wireless caratterizzato da una banda limitata Il funzionamento di Mobile IP Il problema discusso prima che ha richiesto l ampliamento del protocollo IP è che un nodo, quando si sposta, non può utilizzare il suo vecchio IP Address in quanto questo, collegato ad una nuova rete, diventa irraggiungibile. Con il protocollo Mobile IP si è pensato di associare ad ogni utente mobile due indirizzi IP, uno della rete originaria detta home network ed uno della rete correntemente utilizzata, chiamata foreign network. I due indirizzi IP assegnati al modo mobile sono: home-address: rappresenta l indirizzo assegnato al nodo mobile dalla rete di origine, quella che è stata chiamata la home network; questo indirizzo è stabilmente attribuito al terminale mobile; care-of-address: rappresenta l indirizzo temporaneo assegnato al nodo mobile dalla rete che lo ospita, ovvero dalla foreign network. Il protocollo Mobile IP introduce delle entità con ben precise funzionalità e caratteristiche: il Mobile node rappresenta il terminale che si muove; questo terminale deve quindi poter cambiare il punto di connessione alla rete pur mantenendo il suo il suo indirizzo IP - cioè l home address - e l accesso alle risorse; esso deve anche continuare ad essere raggiungibile; l Home Agent rappresenta un nodo ben determinato della home network dell utente mobile: le sue funzionalità sono essenzialmente di routing e di 83

84 instradamento dei pacchetti al terminale mobile quando questi è lontano dalla sua home network. La Home Agent mantiene quindi le giuste informazioni sulla posizione corrente del nodo mobile; il Foreign Agent rappresenta un router della rete ospite, cioè della foreign network, e la sua funzione è assegnare il care-of-address e consegnare i pacchetti al nodo mobile spediti dalla Home Agent. Il protocollo Mobile IP risolve il problema della mobilità introducendo un entità router, l Home Agent, che tiene traccia della posizione dell utente mobile ed è quindi in grado, tramite un Tunnelling di recapitare i pacchetti a questi destinati. L applicazione del protocollo Mobile IP prevede una serie di messaggi scambiati tra le diverse entità: Foreign Agent e Home Agent (chiamati anche Mobility Agent) pubblicizzano la loro presenza attraverso messaggi di Agent Advertisement; un nodo mobile può sollecitare l emissione di tali informazioni attraverso messaggi di Agent Solicitation; il nodo mobile ricevendo un messaggio di Agent Advertisement determina se si trova nella sua home network o in una foreign network; se il nodo mobile si ricollega alla sua home network, ossia abbandona una foreign network e torna nella sua rete primaria, allora si deregistra con il suo Home Agent attraverso i messaggi di Registration Request e Registration Reply; 84

85 se il nodo mobile si collega ad una nuova foreign network, gli viene assegnato un nuovo care-of-address; l assegnazione può essere ottenuta mediante un advertisement spedito da un Foreign Agent (che verrà chiamato Foreign Agent care-of-address) oppure tramite protocolli tipo DHCP (co-located care-of-address). 85

86 quando il nodo mobile ha ottenuto un nuovo care-of-address deve comunicarlo all Home Agent. La registrazione avviene attraverso messaggi di Registration Request e Registration Reply scambiati direttamente con l Home Agent oppure tramite il Foreign Agent: l Home Agent, una volta registrato il care-of-address di un nodo mobile, è in grado di intercettare i pacchetti ad esso destinati, cioè destinati all home address del nodo mobile, e mediante un tunnelling può reinstradarli da questo verso l indirizzo care-of-address del nodo mobile. Il punto di uscita del tunnel può essere il nodo mobile o il Foreign Agent; 86

87 i pacchetti spediti dal nodo mobile sono consegnati alla destinazione (il cosiddetto correspondent node) usando i meccanismi standard di routing; 87

88 Quindi il traffico diretto all utente mobile e proveniente da un nodo qualsiasi della rete, cioè dal correspondent node, raggiunge la Home Network, viene intercettato dall Home Agent che lo incapsula e lo instrada verso il care-ofaddress attuale del nodo mobile. I pacchetti spediti dal nodo mobile sono direttamente inviati al correspondent node. Tutto il meccanismo anzidetto si basa sulla capacità del nodo mobile di determinare, tramite processi di Agent Discovery, il passaggio della sua connessione da una rete ad una altra; questo permette al nodo mobile di ottenere il care-of-address e di registrarlo presso il suo Home Agent. 88

89 4.3.2 Meccanismi di Agent Discovery Il modo con cui il nodo mobile riesce a capire se è connesso alla sua home network oppure è collegato ad una foreign network o se si è spostato su un altra foreign network, è l Agent Discovery [23]. Il protocollo Mobile IP per realizzare il meccanismo di Agent Discovery utilizza i messaggi ICMP di Router Discovery ed amplia questi messaggi con delle estensioni. Queste estensioni sono formate da tre campi: il tipo di estensione, la lunghezza ed un campo contenente l informazione vera e propria. I messaggi utilizzati sono: Agent Advertisement ed Agent Solicitation. Gli Agent Advertisement sono messaggi emessi dai Mobility Agent, sia da Home Agent che da Foreign Agent, per informare i terminali mobili della loro presenza. Un Agent Advertisement è un ICMP Router Advertisement esteso con l estensione Mobility Agent Advertisement. L estensione Mobility Agent Advertisement segue i campi dell ICMP Router Advertisement e contiene: il Type di messaggio, che in questo caso vale 16; il Registration Lifetime che rappresenta il massimo tempo (espresso in secondi) che questo agent può accettare nei messaggi di Registration Request; il nodo mobile utilizza questo valore per la richiesta di registrazione; i campi che indicano che tipo di Agent, Foreign o Home, che ha emesso il messaggio ed il tipo di compressione ed encapsulation; il care-of-address che fornisce l agent. Quando il nodo mobile si sposta in una foreign network riceve un messaggio di Agent Advertisement da un Foreign Agent, se questo è presente: 89

90 Il messaggio di Agent Advertisement ha nell header IP come indirizzo sorgente l indirizzo del Foreign Agent, come indirizzo di destinazione un indirizzo broadcast o multicast e il campo Protocol impostato a 1 (che corrisponde al messaggio ICMP). L ICMP Router Advertisement che segue l header IP, ha il campo Type posto a 9 per identificare il messaggio ICMP come un advertisement ed il campo lifetime impostato ad un valore che indica con quale frequenza il Foreign Agent spedisce gli advertisement. Infine l estensione Mobility Agent Advertisement, che segue l ICMP Router Advertisement, contiene il care-of-address che il nodo mobile dovrà utilizzare. Gli Agent Solicitation sono messaggi emessi dai nodi mobili per sollecitare gli Agent Advertisement; sono identici ai messaggi ICMP Router Solicitation (con la sola restrizione che il campo Time To Live del pacchetto IP deve essere posto a 1). Il valore 10 per il campo Type dell ICMP Router Solicitation distingue il messaggio di sollecitazione dagli altri tipi di messaggi ICMP Cambiamento di rete Quando un nodo mobile spostandosi cambia rete di accesso, deve riuscire a 90

91 ottenere al più presto le informazioni indirizzate ad esso. La sollecitudine con cui si riesce ad attivare le operazioni opportune, rappresenta uno dei parametri per quantizzare il livello di prestazioni della rete. Ci sono due meccanismi attraverso i quali un nodo mobile può capire se ha cambiato rete di acceso: il primo è basato sul campo lifetime dell ICMP Router Advertisement: un nodo mobile monitorizza i messaggi di Agent Advertisement che riceve da un Agent e controlla se sono cadenzati di un tempo lifetime; se non riceve alcun Advertisement dallo stesso Agent entro il lifetime specificato allora può presumere di aver cambiato collegamento, quindi deve cercare un altro Mobile Agent a cui registrarsi. Il secondo metodo consiste nell analizzare tutti gli Agent Advertisement e confrontare l indirizzo di rete del mittente con il corrente care-of-address che è utilizzato dal nodo mobile: se questi indirizzi sono differenti significa che i due Agent Advertisement sono stati ricevuti su differenti link e quindi che il nodo mobile ha cambiato posizione Procedura di registrazione presso l Home Agent Una volta ottenuto il care-of-address da un foreign agent o da un DHCP, se un nodo mobile connesso ad una foreign network vuole essere raggiungibile deve registrarsi presso il suo Home Agent o meglio registrare il nuovo care-ofaddress. Il nodo mobile deve anche rinnovare la registrazione prima dello scadere del lifetime altrimenti la Home Agent lo elimina dalla lista dei terminali mobili attivi rendendolo irraggiungibile. Il nodo mobile si registra attraverso l invio un messaggio di Registration Request, direttamente presso il suo Home Agent se ha ottenuto il care-ofaddress da un DHCP oppure invia la richiesta al Foreign Agent che gli 91

92 ha fornito l indirizzo IP. Il Foreign Agent analizza la richiesta e la invia al corrispondente Home Agent. In presenza di una Registration Request, l Home Agent controlla la richiesta e risponde con Registration Reply. Il messaggio Registration Request è contenuto in un pacchetto UDP ed include: il Type del messaggio, che in questo caso vale 1; un campo che specifica il Simultaneous Bindings: il nodo mobile richiede all Home Agent di mantenere la precedente (o le precedenti) binding table; in questo modo restano validi tutti i care-of-address precedentemente utilizzati: questa funzionalità è molto utile per implementare meccanismi di Soft Handoff; il lifetime che rappresenta il numero dei secondi rimanenti prima che la registrazione sia considerata scaduta; il care-of-address, cioè l indirizzo IP del punto di uscita del tunnel; nel caso particolare in cui il nodo mobile torni nella sua home network e cioè desideri deregistrare tutti i suoi care-of-address, questo campo deve essere riempito con l home address che fornisce l Agent; l Home Address, cioè l indirizzo IP del nodo mobile; l Home Agent, cioè l indirizzo IP dell Home Agent del nodo mobile; l Identification che è un parametro costruito dal nodo mobile per il matching tra Registration Request e Registration Reply e per salvaguardarsi dagli attacchi esterni. Il messaggio di Registration Reply contiene tutte le informazioni necessarie per informare il nodo mobile sullo stato della sua richiesta di registrazione. Il messaggio di Registration Reply segue l header UDP e contiene: il Type di messaggio, in questo caso vale 3; un Code che indica il risultato della Registration Request; 92

93 l Home Agent, cioè indirizzo IP dell Home Agent del nodo mobile; l Identification che è un parametro usato per il matching tra Registration Request e Registration Reply, e per salvaguardarsi dagli attacchi esterni. Il campo Identification presente sia nel messaggio di Registration Request sia in quello di Registration Reply è legato alla gestione di meccanismi di sicurezza. Nella registrazione gli scenari possibili sono tre: il nodo mobile si registra usando un foreign care-of-address; il nodo mobile si registra usando un co-located care-of-address; il nodo mobile si deregistra perché è di ritorno sulla sua home network. In ogni caso il nodo mobile spedisce un messaggio di Registration Request che è formato da un header IP, da un header UDP, dalla vera e propria Registration Request e dalla Mobile Home Authentication. L Home Agent, una volta ricevuto una Registration Request, spedisce un messaggio di Registration Reply composto da un header IP, un header UDP, dal messaggio Registration Reply e dalla Mobile-Home Authentication. Il nodo mobile invia la Registration Request al Foreign Agent: questa richiesta di registrazione ha come Source Address dell header IP l home address del nodo mobile e come Destination Address, l indirizzo del Foreign Agent; nella Registration Request che segue l header UDP, i campi lifetime e care-of-address includono gli stessi valori contenuti nel messaggio di Agent Advertisement spedito dal Foreign Agent e diretto al nodo mobile. 93

94 Il Foreign Agent ricevuta la richiesta di registrazione spedisce un pacchetto all Home Agent. Questa Registration Request ha come Source Address dell header IP l indirizzo del Foreign Agent, mentre il Destination Address è l indirizzo dell Home Agent. Il resto del messaggio è identico a quello prodotto dal nodo mobile. Questo messaggio raggiunge l Home Agent, viene controllato e quindi avviene l aggiornamento della binding table con una riga contenente la tripla Home Address, care-of-address, lifetime. A questo punto l Home Agent genera un messaggio di Registration Reply diretto al Foreign Agent e quest ultimo lo rigira al nodo mobile. 94

95 Se la Foreign Network non possiede un Foreign Agent, lo scambio di messaggi è direttamente tra il nodo mobile e Home Agent. Il nodo mobile ottiene il colocated care-of-address da un DHCP. La registrazione, analogamente al caso precedente, inizia con un messaggio di Registration Request dal nodo mobile che contiene l header IP il cui Source Address è riempito con il care-of-address assegnato al nodo e il Destination Address è l indirizzo dell Home Agent. Inoltre nella Registration Request il campo lifetime è impostato arbitrariamente dal nodo mobile 95

96 La Registration Request ha come Home Source Address l home address del nodo mobile e come Destination Address l indirizzo IP dell Home Agent. II campo lifetime è impostato a 0 indicando in tal modo all Home Agent il desiderio del nodo mobile di deregistrarsi. Il campo care-of-address è riempito con l home address del nodo mobile. Quando l Home Agent riceve la Registration Request, aggiorna la binding table e risponde al nodo mobile con un messaggio di Registration Reply inserendo nel campo Lifetime il valore L IP Mobility ed i messaggi ARP Nelle reti IP per conoscere gli indirizzi di livello Data Link di un host della stessa sottorete, conoscendo l indirizzo IP, si utilizza il protocollo ARP (Address Resolution Protocol) [24]. Nel caso dell IP Mobility il nodo mobile è connesso ad un altra network e quindi non è in grado di rispondere ai messaggi ARP, quindi è l Home Agent a farsi carico di rispondere con il proprio indirizzo MAC a tali richieste. Quindi l Home Agent a tutti gli effetti si sostituisce al nodo mobile e per fare questo utilizza dei messaggi ARP appositi: Proxy ARP: è un particolare ARP Reply inviato a fronte di un ARP Request indirizzato ad altro nodo incapace di rispondere; Gratuitous ARP: è un ARP Request o ARP Reply usato per forzare tutte le macchine della sottorete all aggiornamento delle loro tabelle ARP. Quando l Home Agent intercetta un ARP Request diretta ad un nodo mobile che gestisce, risponde utilizzando un Proxy ARP indicando come indirizzo di livello Data Link quello associato alla sua interfaccia di rete. 96

97 Quando un nodo mobile si registra al suo Home Agent con un care-of-address, oltre alle già citate procedure di registrazione, invia in broadcast nella sottorete un messaggio di Gratuitous ARP per costringere tutti i nodi della sottorete ad aggiornare le loro tabelle ARP. Le tabelle ARP dei nodi della home network assoceranno l home address del nodo mobile con l indirizzo di livello data link dell Home Agent. Quando un nodo mobile torna nella sua home network, spedisce un messaggio di Gratuitous ARP quindi si deregistra con il suo Home Agent. A deregistrazione completata l Home Agent invia a sua volta un messaggio Gratuitous ARP; in tal modo tutti i nodi presenti nella home network aggiorneranno le loro tabelle ARP associando all home address l indirizzo di livello Data Link del nodo mobile. 97

98 4.4 Cellular IP: un approccio all Host Mobility Questo documento presenta un nuovo modo di vedere Internet dal punto di vista di un utente mobile. Rimarcando la separazione che con il tempo è andata quasi dissolvendosi tra aree locali e aree estese (cioè tra LAN e WAN), le prestazioni di alcuni protocolli di connessione mobile proposti in passato (vedi Mobile IP) possono essere significativamente migliorate. Cellular IP è un protocollo leggero e allo stesso tempo robusto, ottimizzato per supportare mobilità in aree locali e per interagire efficientemente con Mobile IP fornendone una sorta di integrazione per fornire il supporto per la mobilità in aree estese. Esso mostra enormi progressi rispetto alle altre proposte di connessione mobile soprattutto per scenari dove gli utenti si muovono e migrano frequentemente da una rete ad un altra, situazione questa molto più vicina ad una regola che ad un eccezione in una realtà dove gli accessi wireless ad Internet diventano sempre più frequenti nel tempo e nello spazio. Questo protocollo mantiene delle cache distribuite per tutti i meccanismi di gestione delle locazioni e del routing. Queste cache rimangono in stato di inattività (o stato idle) per ogni utente ma vengono usate per determinare velocemente e con efficienza gli utenti idle che vogliono impegnarsi per una comunicazione attiva. 98

99 Questo approccio è vantaggioso perché si possono allocare tanti clienti in una rete senza sovraccaricare il sistema di gestione delle locazioni. Altre cache dette di routing restano nello stato attivo nell area dove è fornita la connessione ma viene fatto un refresh dinamico dello stato di routing per quegli utenti attivi che richiedono un handoff. In questo modo, gli algoritmi distribuiti di gestione delle locazioni e del routing hanno un implementazione semplice e di basso costo e non sovraccaricano Internet giacché non richiedono pacchetti in un nuovo formato né altra allocazione di spazio oltre a quella normalmente richiesta dal protocollo IP Introduzione a Cellular IP Data la dimensione sempre più ridotta dei computer portatili e la connessione a una rete globale pressoché onnipresente, la domanda di fornire un accesso alla rete agli utenti mobili è sempre più rapidamente in crescita. La difficoltà di base della maggior parte dei protocolli che offrono questo tipo di connessione [25][26][27][28] risiede nella natura dell indirizzo IP che ha un duplice significato: esso è infatti sia un identificativo univoco dell utente (che perciò dovrebbe essere mantenuto costante indipendentemente dalla locazione), sia un parametro che identifica la posizione e che quindi deve cambiare così come l utente si sposta [29]. Questi sono due requisiti che vanno in competizione tra loro e che il protocollo di connessione mobile dovrebbe risolvere efficientemente [29][30]. Il problema fondamentale da risolvere è la separazione di questi due ruoli e allo stesso tempo si deve rendere disponibile una mappa di identificativi di utenti e delle loro relative informazioni di localizzazione. 99

100 Immaginiamo quindi un utente mobile in uno scenario in cui la connessione a Internet avviene tipicamente in maniera wireless - anche se oggi questo è ancora un eccezione. Pensiamo quindi a un ambiente in cui sia presente un gran numero di utenti mobili che si muovono e che spesso migrano da una zona ad un altra durante il trasferimento di dati e che si aspettano che la rete gestisca questi handoff con il minimo disturbo sulla sessione. Anche se è poco probabile (e poco prudente!) che si legga un testo o si guardi un video mentre si guida o si cammina, si potrebbe comunque desiderare di scaricare dati o di parlare a telefono sfruttando Internet mentre si è in movimento. Con la diffusione di computer portatili e palmari sempre più piccoli ed economicamente convenienti, la visione di una rete globale di computer diventa una realtà. Nasce così l esigenza di un accesso wireless a Internet economico e onnipresente. Si potrebbe addirittura pensare che in tale realtà la popolarità dei telefoni cellulari possa essere offuscata dall uso di palmari che supportino Internet insieme ad una vasta gamma di servizi che si adattino perfettamente ad ogni situazione senza il minimo intervento da parte dell utente, un po come avviene oggi per i telefonini. In altre parole si può pensare che telefonini e computer palmari evolveranno insieme verso un successore comune. Si può vedere [28] che in uno scenario simile Mobile IP non rappresenta una soluzione ottimale essendo meglio impiegato per mobilità di macro-livello dove gli utenti si muovono lentamente e poco frequentemente. Infatti ad ogni migrazione, Mobile IP prevede l invio un messaggio di aggiornamento della locazione verso una stazione server detta home agent che potrebbe anche 100

101 trovarsi molto lontano: questo potrebbe da un lato avere effetti sulla latenza di handoff e dall altro sovraccaricare una parte della rete Internet. Per sorpassare questa limitazione si introduce un approccio gerarchico della gestione della mobilità: la soluzione è un architettura formata da due livelli: un primo livello è composto da più reti locali con accesso wireless che gestiscono facilmente la mobilità locale; un secondo livello comprende una grande rete Internet gestita da Mobile IP che vi fornisce un servizio di mobilità per l area estesa. In questo caso una stazione home agent è informata del movimento di un host solamente quando questo si sposta da una rete di accesso ad un altra mentre rimane all oscuro degli spostamenti che effettuano gli host quando questi, pur movendosi, restano nella stessa area di accesso (figura 4.3). Figura 4.3: Compresenza di Celular IP e Mobile IP Il vantaggio principale di dividere la mobilità tra l area locale e estesa sta proprio nel fatto che le home agent non hanno bisogno di essere informate circa gli spostamenti locali all interno delle aree di accesso wireless e questo 101

102 diventa sempre più importante quando le celle diventano sempre più piccole, la frequenza delle migrazioni più alta e la popolazione degli host più estesa. Gestendo localmente la maggior parte degli handoff, possiamo studiare metodi per renderli più veloci, limitare l impatto che questi possono avere sulle sessioni attive e inoltre evitare il problema delle migrazioni verso stazioni home agent lontane. Un ulteriore beneficio dell approccio architetturale gerarchico della mobilità sorge nel caso in cui un grande numero di utenti vuole spostarsi trasportando computer portatili che hanno bisogno di essere permanentemente connessi a Internet: questi utenti genererebbero frequenti messaggi di aggiornamento di locazione anche non essendo attivamente in fase di trasmissione di dati. La diminuzione della dimensione della singola cella porterebbe poi a un aumento dei messaggi di servizio e il traffico da questi generato potrebbe raggiungere un entità paragonabile al traffico utile. Quindi per permettere la connessione a un gran numero di utenti, il protocollo di gestione della mobilità ha bisogno di uno schema di trasporto delle informazioni di locazione che sia semplice e che allo stesso tempo non sovraccarichi con traffico o processi la rete globale quando gli host sono in stato idle. Ci riferiremo a questa proprietà chiamandola connessione passiva leggera (cheap passive connectivity). Per questi obiettivi viene utilizzato Cellular IP, un protocollo di mobilità ottimizzato per reti ad accesso wireless con un gran numero di utenti. Il primo obiettivo che Cellular IP si prefigge è la semplicità: il fatto che un AP wireless di Cellular IP possa essere costituito da dispositivo un piccolo ed economico (è necessaria una sola BS per ogni ufficio o per ogni piano) rende 102

103 possibile un applicazione per così dire domestica. D altro canto Cellular IP può essere implementato anche sui classici router IP per permettere delle migrazioni più facili sui sistemi già installati e funzionanti. Un altro obiettivo chiave è la scalabilità: il sistema di gestione distribuito rende possibile l uso dello stesso protocollo e degli stessi nodi topologici (che ricordiamo sono all oscuro di ciò che inoltrano) sia in piccoli sistemi domestici, sia in aree molto estese, sia addirittura in sistemi eterogenei. Questo permette agli utenti di migrare liberamente e senza difficoltà tra aree con diverse caratteristiche: si può pensare di ottenere una connessione dagli operatori locali di telefonia cellulare che danno il servizio di Cellular IP e un utente può ricevere una banda ampia per scaricare dati o per usare VoIP (Voice over IP) mentre passeggia tranquillamente per strada e poi continuare a farlo usando sempre lo stesso protocollo quando entra in un ufficio o in un edificio in cui c è una copertura wireless. Si può vedere che fornire trasparenza insieme ad un supporto della qualità del servizio indipendente dalla locazione non è un obiettivo semplice da ottenere per protocolli di mobilità che lavorano in scenari wireless [29]. Cellular IP aggira l ostacolo fornendo scalabilità cioè la capacità di avere lo stesso protocollo in ambienti diversi ottenendo sempre lo stesso servizio. Questa proprietà inoltre permette ai gestori di rete di estendere la dimensione della zona di servizio quando la domanda cresce. Ciò risulta molto importante giacché la capacità globale dei sistemi wireless è determinata proprio dalla densità delle BS e può essere estesa installando nuove apparecchiature che portano con sé tutti i problemi relativi al costo. Un altro vantaggio nell uso di Cellular IP è la sua completa compatibilità con il protocollo IP: non si richiede l invio di pacchetti supplementari, non si 103

104 richiedono ulteriori incapsulamenti, non si richiede spazio extra per gli indirizzi. Il sistema di Cellular IP usa tre tipi di pacchetti di controllo che possono essere implementate come opzioni di IP perciò non c è alcun bisogno di aggiornare il funzionamento dei regolari router IP. Nel paragrafo seguente si propone un approccio alternativo al problema della mobilità e lo paragona tale approccio al metodo di Cellular IP; nel paragrafo 3 si presenta un nuovo modello di rete ad accesso wireless; nel paragrafo 4 vengono analizzate nel dettaglio le caratteristiche di Cellular IP; nel quinto e sesto si discutono gli argomenti relativi all implementazione Approccio alternativo alla gestione degli utenti mobili Una soluzione che richieda agli utenti mobili un processo di aggiornamento continuo, supporta portabilità ma non mobilità [29]. Il primo obiettivo quindi per un protocollo di mobilità è permettere all utente di cambiare punto di accesso senza una riconfigurazione manuale. Questo requisito è fondamentale per la proprietà di trasparenza. Un utente potrebbe desiderare di spostarsi durante il trasferimento di dati effettuando così un cambio di punto di accesso mentre la connessione è attiva, operazione chiamata migrazione o handoff. Un altra caratteristica importante per un protocollo che si occupa di utenza mobile è la gestione di questi handoff senza disturbi significativi alla trasmissione di dati. 104

105 Si può vedere [30] che molti protocolli per la gestione di utenti mobili, compreso il famoso IETF Mobile IP [31], possono essere considerati casi speciali di un architettura a due livelli di indirizzamento perché un utente mobile è logicamente associato a due indirizzi IP: un indirizzo detto home address assegnato dalla prima stazione (home agent) che è un identificatore dell utente e che rimane sempre lo stesso; un altro indirizzo relativo all attuale punto di collegamento a Internet, dipendente perciò dalla posizione. Quest architettura generalizzata comprende tre componenti fondamentali: una Tabella di Locazioni (Local Directory) cioè un data base possibilmente distribuito che contiene i dati aggiornati relativi a ogni utente e ai suoi due indirizzi; un Unità di Traduzione degli Indirizzi (Address Translation Agent) che associa ad ogni utente l indirizzo della destinazione dei pacchetti da esso generati gestendo le richieste sia della Local Directory, sia di altre cache locali; un Unità di Spedizione (Forwarding Agent) che assicura che i pacchetti che arrivano all utente mobile hanno un campo con l home address e uno con la destinazione finale. Anche se queste soluzioni, in particolare quella dell IETF Mobile IP, raggiungono gli obiettivi di trasparenza operazionale e supporto degli handoff, sono in realtà ottimizzate per gli utenti che si muovono molto lentamente e diventano addirittura inefficienti nel caso di migrazioni frequenti [28]. Mobile IP richiede che la stazione home agent sia informata ogniqualvolta un suo utente si muova verso un altro agent. Durante la fase di aggiornamento che può durare non poco, alcuni utenti possono spostarsi e quindi i pacchetti a 105

106 questi destinati verranno inoltrati verso una destinazione sbagliata con conseguente disturbo per la trasmissione di dati. Analogamente, durante l ottimizzazione del processo di instradamento [32][33], la trasmissione di dati sarà disturbata mentre il corrispondente host otterrà un nuova connessione. L effetto di questi ritardi ovviamente cresce con l aumento della frequenza di migrazione. Inoltre i messaggi di aggiornamento possono sovraccaricare sia Internet che la home agent quando un utente si muove anche se non sta attivamente trasferendo dati (stato idle). L entità del sovraccarico è proporzionale al numero degli utenti mobili e non al traffico generato quindi si potrebbe venire a creare una situazione in cui un solo utente sia in trasmissione attiva ma comunque incontri una rete sovraccaricata da traffico di servizio. Come se non bastasse, questo problema paradossalmente cresce con lo sviluppo della mobilità perché la connessione deve essere onnipresente, le celle più piccole e gli handoff più frequenti. Per superare le limitazioni di Mobile IP, nasce un approccio di gestione della mobilità di tipo gerarchico [28]. Sono definiti quindi tre livelli di mobilità: il livello di mobilità locale; il livello di mobilità all interno di un dominio amministrativo; il livello di mobilità globale. Per ognuno di questi livelli viene proposto un protocollo di mobilità e Mobile IP viene associato al livello di mobilità globale. Cellular IP differisce da questo approccio per due aspetti importanti: prima di tutto, invece di definire livelli gerarchici di mobilità, fornisce una 106

107 struttura che può scalare da sistemi di piccoli uffici fino ad aree molto estese. Infatti spesso queste aree possono trovarsi sovrapposte, per esempio un ufficio potrebbe avere la sua propria rete locale e nello stesso tempo essere all interno di un campus e della sua relativa rete o in un un area metropolitana; ognuna di queste reti o sottoreti potrebbe usare lo stesso protocollo di Cellular IP sebbene con un impostazione diversa del dispositivo di gestione delle locazioni (ved. paragrafo 4); in seconda istanza Cellular IP utilizza un efficiente schema della gestione e della ricerca delle locazioni che evita i problemi relativi al trasporto degli utenti in stato idle, ovvero riducendo il carico sulle reti ad accesso wireless. Questa caratteristica è necessaria per la proprietà di connessione passiva leggera che abbiamo identificato come un importante obiettivo per i futuri sistemi wireless basati su IP. Una tecnica familiare alla telefonia cellulare è basata su un trasporto leggero della posizione degli utenti mobili per poi zoomare su di essi quando c è bisogno di una connessione attiva, cioè quando inoltrano o ricevono una chiamata. Per esempio nel sistema GSM (Global System for Mobile Communications) gli utenti non attivi (ovvero in stato idle) sono localizzati con una precisione molto bassa, si associa ad ognuno di essi solo l area di localizzazione, ma vengono focalizzati all interno dell area (si dice paged) quando c è una chiamata in arrivo o in uscita [34]. Aumentando la dimensione dell area di localizzazione il traffico di paging può essere associato al traffico di aggiornamento delle localizzazioni; il punto operazionale ottimale dipende dalle caratteristiche di chiamata e di mobilità degli utenti. Cellular IP si basa su questo concetto e analogamente al sistema di telefonia 107

108 cellulare, tende a evitare le procedure di aggiornamento delle localizzazioni degli utenti non attivi che consumano risorse. Tuttavia diversamente dal sistema di voce, Cellular IP non può far affidamento su una fase di inizializzazione della connessione per focalizzare gli utenti mobili come avviene nel sistema GSM ogni volta che si accende un telefonino. Al contrario anzi, la gestione delle localizzazioni è basato su un sistema di segnalazione leggera, detta soft-state, che è in grado di distinguere gli host attivi e quelli inattivi (active o idle) senza introdurre operazioni come l inizializzazione della connessione. Una tale visione differenzia il nostro approccio anche dai i continui sforzi di fornire un servizio di trasporto dati attraverso la rete della telefonia cellulare. Infatti il sistema GPRS (General Packet Radio Service) per esempio, prima che una vera e propria trasmissione abbia inizio, richiede che sia stabilita una connessione riservando un canale logico tra il cliente mobile e la rete. Inoltre il sistema GPRS è implementato sull infrastruttura di GSM che limita l applicabilità a piccole reti, specialmente quelle di tipo domestico. Il sistema mobile di terza generazione è predisposto per fornire più servizi di dati agli utenti mobili e questo, unito ai sistemi ATM e CDMA, dà supporto a una vasta gamma di servizi che va dalla trasmissione di voce a quella di multimedia di alta qualità [13]. In confronto a questa standard evoluto, Cellular IP fornisce un approccio semplicistico offrendo un servizio di consegna non garantito e perciò è molto più appropriato per i traffici best effort. In ogni caso essendo disegnato intorno al paradigma IP, esso può evolvere per soddisfare futuri schemi della qualità del sevizio di IP [15]. 108

109 Diversamente da alcune tecniche multicast di IP pensate per risolvere problemi di indirizzamento e locazioni che richiedono alla rete la continua conoscenza della posizione di ogni utente non attivo, Cellular IP usa un albero di percorsi tempo-variante per ricercare gli utenti mobili. Queste tecniche multicast non soddisfano il requisito di connessione passiva leggera e inoltre, come molti altri protocolli di questo tipo, c è bisogno di un router IP speciale in ogni stazione base, cosa molto costosa rispetto al meccanismo proposto con Cellular IP Modello di rete ad accesso wireless Una rete ad accesso wireless consiste in prima analisi di una o più BS (Base Station) interconnesse con collegamenti wired come illustrato in figura 4.4. Figura 4.4: Modello di rete ad accesso wireless 109

110 A parte la stazione base, la rete può contenere nodi che non contengono dispositivi radio ma che fungono da concentratori di traffico o supportano funzioni di controllo della mobilità. Nella figura 4.4 tutti i nodi, ad eccezione del nodo E, hanno un dispositivo radio. Le reti ad accesso wireless sono connesse ad Internet attraverso i router gateway. Questo router speciale rappresenta anche la migliore posizione per la stazione home agent se la rete di accesso wireless funziona da home network per alcuni utenti mobili; inoltre quella è anche la migliore posizione per la stazione detta foreign agent per utenti ospiti. Si supponga che nella rete Internet globale la mobilità sia affidata a Mobile IP e che la precisione di localizzazione sia la posizione della rete ad accesso wireless. Entrando in una rete wireless (azione 1 della figura) un utente mobile X si connette attraverso la sua home agent (azione 2) che quindi inoltrerà i pacchetti diretti all utente X verso quella la rete wireless (azione 3). Quindi fino a che l utente rimane connesso alla stessa rete, i suoi spostamenti sono celati alla sua home agent che d altro canto si comporterebbe nella stessa maniera anche se ne fosse informata. Gli spostamenti tra reti wireless avvengono con una frequenza molto bassa e perciò Mobile IP risulta un buon protocollo di controllo. Nel prosieguo identificheremo alcuni requisiti chiave per le reti ad accesso wireless. All interno dell area di servizio della rete wireless, gli utenti mobili non hanno una locazione base o un punto dedicato al loro aggancio alla rete. Le BS perciò inviano periodicamente segnali di controllo per permettere agli utenti mobili di 110

111 identificare una stazione base disponibile. Fino a che sono connessi alla rete wireless, gli utenti mobili esterni alla rete (come l utente X della figura) sono trattati come se fossero interni. Però quando uno di questi utenti si collega o lascia una rete ospitante, conformemente a quanto richiesto da Mobile IP, deve informare la sua home agent. Inoltre nel caso di ingresso a una rete ospitante, c è bisogno anche di procedure di registrazione e autenticazione. Per facilitare la mobilità globale, le procedure di registrazione alla rete devono essere facili e veloci. Tuttavia sebbene per migliorare una ricercabilità globale, un utente ospite dovrebbe avere un indirizzo locale, è comunque vantaggioso in termini di trasparenza che esso sia identificato proprio dal suo indirizzo IP originario (quello della home network) anche all interno di una rete ospitante. In uno scenario dove gli utenti si portano dietro computer portatili capaci di connettersi in maniera wireless che siano sempre accesi, un altro requisito importante è la capacità di permettere l accesso al maggior numero di utenti possibile in una data rete ad accesso wireless. E mentre il traffico generato dagli utenti attivi può essere limitato da alcuni meccanismi della rete, agli utenti idle, che hanno bisogno solo della possibilità di essere raggiunti, si deve imporre la generazione di traffico esiguo. Come già precedentemente detto, ci riferiamo a questa proprietà chiamandola connessione passiva leggera (cheap passive connectivity). Una situazione comune e anche comoda si presenta quando due celle adiacenti hanno angoli sovrapposti, facilitando così un perfetto supporto degli handoff. In questo caso il protocollo della rete wireless può considerare soft handoff, cioè se un utente cambia cella diventando temporaneamente irraggiungibile, i 111

112 pacchetti continuano a essere consegnati anche se con un piccolo disordine. Ciò si realizza permettendo temporaneamente una trasmissione simultanea da/verso entrambe le stazioni base. In ogni caso anche se ciò non fosse possibile perché le celle non si sovrappongono, il protocollo deve comunque funzionare efficientemente. Ora siccome le celle di solito coprono un area piccola (delle dimensioni di qualche stanza o tratto strada), la rete wireless deve poter funzionare bene anche in presenza di migrazioni molto frequenti. Tenere nota di ogni movimento di un utente con la precisione di una cella richiede che sia inviato un messaggio di controllo dopo ogni migrazione verso una locazione base e che questo sia processato in quel punto, cosa che può diventare molto inefficiente in regime di un alta frequenza di handoff. E comunque lasciare che un utente si muova in un area servita da una rete wireless senza che nessuno ne rilevi il movimento per poi localizzarlo solo quando ci siano dati da consegnare è una soluzione inefficiente e poco scalabile. Uno schema di gestione delle locazioni efficiente deve invece mantenere informazioni circa la posizione degli utenti inattivi senza sovraccaricare la rete con messaggi di aggiornamento e dovrebbe anche utilizzare un algoritmo di ricerca veloce ed efficiente, da utilizzare anche nel caso in cui non ci siano dati da consegnare ad utenti inattivi. Dato che la frequenza delle migrazioni può variare nelle reti, il meccanismo di gestione delle localizzazioni dovrebbe essere adattabile a caratteristiche locali, in particolare in scenari con una frequenza di handoff bassa, si dovrebbe mantenere per gli utenti idle un informazione della localizzazione più accurata mentre al contrario, in sistemi con una frequenza di migrazioni alta dovrebbero 112

113 riporre molta fiducia in un meccanismo di ricerca on-demand per limitare il più possibile il carico imposto dai messaggi di aggiornamento delle localizzazioni. Per permettere la connessione anche a dispositivi portatili di bassa potenza (e costo!), una rete ad accesso wireless non dovrebbe affidare una complessità alta agli utenti mobili. Idealmente un host mobile è senza memoria (o memoryless) nel senso che esso continua ad operare le stesse azioni elementari per restare connesso sia nel caso in cui sia sotto l azione di ricerca di una BS, sia nel caso in cui resti inattivo. Inoltre nessuna operazione particolare dovrebbe essere richiesta nel caso di un handoff o dopo un black out radio temporaneo. In definitiva il disegno del protocollo di Cellular IP è motivato da ben 5 requisiti chiave che una rete di accesso wireless deve soddisfare: 1. migrazione globale semplice; 2. connessione passiva leggera; 3. supporto degli handof flessibile; 4. semplice gestione delle locazioni; 5. comportamento degli host mobili semplici e senza memoria Cellular IP In aggiunta ai requisiti discussi nel paragrafo precedente, l obiettivo principale di Cellular IP è fornire la massima scalabilità e robustezza con la minima complessità. Una rete Cellular IP è completamente distribuita se: 113

114 i nodi non conoscono la topologia della rete; non esiste un data base centralizzato né alcun altro punto debole; nessun elemento della rete può far aumentare la complessità quando aumenta l area di copertura (e quindi il potenziale numero di utenti connessi) Meccanismi di mapping: Paging e Routing Caches Per semplicità e scalabilità, in una rete Cellular IP nessuno dei nodi conosce l esatta posizione di un utente mobile. I pacchetti indirizzati ad un utente mobile sono inviati alla sua attuale BS con il classico metodo hop-by-hop dove ogni nodo ha bisogno di sapere solo su quale porto di uscita inoltrare i pacchetti. Questa tecnica di limitare le informazioni di routing solo localmente non richiede che i nodi abbiano conoscenza della topologia dell intera rete wireless. Ci riferiremo a questo tipo di operazioni con la parola mapping (che tradotto letteralmente significa disegnare una mappa ) perché si associano un ogni utente mobile (ovvero ad ogni suo identificatore, rappresentato dall indirizzo IP) ad un numero di porto. Il meccanismo del mapping è generato e tenuto in piedi grazie all invio dei pacchetti trasmessi da tutti gli utenti mobili della rete: i pacchetti viaggiano nella rete di accesso verso il gateway che è governato da una politica hop-byhop. Monitorando questi pacchetti e assegnando l indirizzo del mittente al relativo porto entrante, i nodi della rete creano un percorso inverso hop-by-hop utile per i pacchetti che in futuro verranno indirizzati a quel determinato utente. Per minimizzare la segnalazione di controllo, i dati di mapping non vengono 114

115 cancellati in modo esplicito subito dopo un handoff; piuttosto si assegnato un timer, scaduto il quale il mapping viene considerato antiquato e solo in quel caso viene cancellato definitivamente. Questo implica quello per mantenere vivo l insieme di informazioni utili al proprio mapping, un utente deve inviare pacchetti fittizi (detti dummy) periodicamente anche quando non ha nessuno dato reale da spedire. La combinazione di pacchetti emessi periodicamente e timer associati ai mapping assicura che appena un utente mobile entri in un area di servizio, tra il gateway della rete ospitante e la BS di quell host esisteranno sempre delle informazioni aggiornate riguardanti il mapping. Questo schema porta vantaggi anche relativamente alla facile migrazione tra reti di accesso perché i nodi non hanno bisogno di nessuna informazione preliminare riguardo ad un utente mobile per creare le tabelle di mapping e non ha bisogno di essere informati quando un utente lascia l area. Comunque, affidarsi al meccanismo dei timer genera il seguente trade off: dopo che un utente abbia compiuto un handoff, il suo percorso relativo alla vecchia staziona rimarrà valido finché i tutte le informazioni di mapping non saranno cancellate. Ma se nel frattempo verranno inviati dei pacchetti a quell utente, non saranno consegnati solo alla sua BS attuale ma anche a quella vecchia. Questo risulta un spreco di risorse che può essere minimizzato selezionando un timeout abbastanza piccolo. D altra parte gli utenti idle hanno bisogno di emettere pacchetti dummy con un periodo comparabile con il timeout del mapping e minore risulta essere questo parametro, più frequentemente saranno inviati pacchetti fittizi e quindi più alto sarà il rischio di sovraccarico della rete! 115

116 Questo può essere particolarmente pericoloso laddove le risorse radio sono scarse perché in questi casi il timeout deve essere piccolo. Per superare questo problema, si può osservare innanzitutto che il sistema ha due caratteristici livelli di temporizzazione: per minimizzare lo spreco di risorse dovuto ad informazioni di mapping non usate ma non ancora cancellate, il timeout dovrebbe essere dell ordine del tempo di consegna pacchetto (detto anche tempo di pacchetto); ma d altra parte per una periodicità ragionevole dei pacchetti dummy, il timeout dovrebbe durare tutto il tempo che un utente resta agganciato ad una BS, cioè il tempo tra due handoff successivi, che può essere di ordini di grandezza maggiore del tempo considerato precedentemente. Cellular IP risolve questo problema usando due strutture di mapping parallele. I nodi mantengono un primo insieme di mapping, chiamato Paging Caches (PC) che viene usato solo per gli utenti mobili inattivi. I mapping relativi alle PC hanno un timeout comparabile alla frequenza di migrazione, possibilmente nell ordine dei secondi o addirittura dei minuti. Poi indipendentemente dalle Paging Caches, i nodi mantengono un altro set di mapping chiamato Routing Caches (RC): le informazioni che vi sono contenute sono utilizzate solamente per quegli utenti mobili che attualmente ricevono o sono in attesa di ricevere dati. Per i mapping delle Routing Caches il timeout può essere dello stesso ordine di grandezza del tempo di pacchetto. Perciò questo motivo le Paging Caches si possono considerare dei data base di informazioni di locazione di basso livello, adatto solo agli utenti idle. Quando poi uno di questi utenti comincia ad entrare effettivamente in fase di trasmissione attiva, ad esso vengono applicate le informazioni delle Routing Caches, viste come data base più nobili. 116

117 In figura 4.5 è rappresentata la relazione tra le Paging Caches e le Routing Caches. Fintantoché rimane inattivo, l utente X tiene aggiornata la sua PC emettendo pacchetti dummy ad una frequenza bassa (azione 1 della figura). Le Paging Caches hanno un timeout relativamente lungo, poiché gli basta tener traccia di un utente in maniera scadente, dato che l utente in questione è inattivo. Figura 4.5: Paging e Routing Quando ci sono pacchetti da indirizzare ad un utente mobile idle, vengono utilizzati i mapping delle PC per localizzare l utente (azione 2 della figura). Da questo momento e fintantoché continuano ad arrivare dati, un utente mantiene attivi i timeout delle Routing Caches, sia attraverso i suoi pacchetti in partenza, sia attraverso la trasmissione di pacchetti dummy (azione 3 della figura). I pacchetti indirizzati all utente sono gestiti dalle RC (azione 4 della figura) che diversamente dalle PC localizzano l utente più da vicino. 117

118 La separazione delle Paging Caches dalle Routing Caches ha un ulteriore vantaggio: una rete di accesso wireless può avere un grande numero di utenti mobili collegati allo stesso tempo, dei quali solamente una piccola percentuale sta ricevendo effettivamente dati. In questo caso, la Paging Cache conterrà in ogni momento un gran numero di tabelle di mapping, perciò il suo data base risulterà molto più esteso di quello della Routing Cache. E siccome le PC sono usate solamente per cercare utenti inattivi e non per inviare dati con un bit rate alto, il gestore della rete può scegliere di mettere le Paging Caches solamente in un piccolo numero di nodi posizionati strategicamente e lasciare agli altri nodi il compito di ricerca broadcast, che è un operazione ovviamente più delicata. Creando più PC le informazioni di locazione possono essere realizzate con più precisione riducendo così la dimensione dell area di ricerca. Questa caratteristica architetturale lascia al gestore della rete la libertà di sincronizzare le operazioni di localizzazione secondo le caratteristiche di mobilità di quella particolare rete. Si discuterà più approfonditamente di questo problema nel paragrafo Paging di Cellular IP Gli utenti mobili inattivi periodicamente generano pacchetti di controllo, di lunghezza molto ridotta, chiamati pacchetti di aggiornamento del paging (paging-update packets) e li spediscono alla stazione base attiva più vicina. I pacchetti di aggiornamento del paging viaggiano nella rete di accesso verso il router gateway (GW), instradati attraverso la politica dell hop-by-hop, come 118

119 illustrato in figura 4.6. I nodi dotati di Paging Caches monitorano continuamente i pacchetti di aggiornamento che vi passano e mantengono attive le cache che associano l identificativo di utente con il porto al quale il pacchetto di aggiornamento del paging è destinato (si veda il paragrafo 5.1 per l indirizzamento mobile). Il router gateway scarta automaticamente da Internet i pacchetti di aggiornamento del paging che trasportano informazioni circa alcune specifiche operazioni di Cellular IP. Come illustrato in figura 4.6, un utente mobile X è attualmente nella cella del nodo G. Figura 4.6: Il mapping nelle PC creato dai pacchetti di aggiornamento del paging I paging-update packets generati da X viaggiano verso il GW attraverso nodi G, E, C ed A. In questo esempio i nodi A ed E contengono Paging Caches ma nodo C no. Ora C semplicemente inoltra i pacchetti di aggiornamento del paging verso il gateway senza registrare alcuna informazione di localizzazione sull utente X. Il nodo A nota che i pacchetti arrivano da X attraverso il porto di C, mentre il nodo E nota che i pacchetti di X arrivano attraverso il porto di G. 119

120 Quando un utente idle si muove, continua a spedire i suoi pacchetti di aggiornamento del paging alla BS più vicina, forzando le Paging Caches ad avere informazioni relative al mapping sempre aggiornate. I mapping antiquati vengono fisicamente cancellati dopo uno specifico timeout impostato dal sistema. Se per esempio l utente X si muove verso la cella F, i suoi pacchetti aggiornamento del paging saranno spediti alla stazione F come illustrato in figura 4.7: mentre il nodo A non noterà alcuna differenza, nel nodo E sarà creato un nuovo percorso di instradamento per X e dopo un po (quando il relativo timeout sarà scaduto) il vecchio percorso sarà considerato antiquato e perciò verrà cancellato. Figura 4.7: Aggiornamento delle Paging Caches per un utente mobile Per un po di tempo i due percorsi di mapping coesistono garantendo sempre la raggiungibilità per l utente X anche durante la migrazione. Quando al router gateway arrivano i pacchetti IP indirizzati ad un utente mobile 120

121 per il quale non è disponibile nessuna informazione di mapping aggiornata, vengono usate le Paging Caches per rintracciare l utente. Siccome non conosce l esatta localizzazione del destinatario, il gateway accoda i pacchetti IP arrivati e genera un pacchetto di controllo con lo scopo di rintracciare l utente, chiamato pacchetto di paging che contiene l identificatore dell utente mobile cercato. Il pacchetto di paging è instradato nella rete di accesso dalle Paging Caches che semplicemente invertono il percorso di instradamento degli ultimi pacchetti di aggiornamento del paging. A questo punto se tutti i nodi sono forniti di Paging Caches, allora è disponibile un hop-by-hop inverso e si può risalire alla posizione corrente dell utente; se alcuni nodi invece non hanno le Paging Caches, allora spediranno il pacchetto di paging a tutti i porti in uscita. Continuando l esempio (figura 4.8) per instradare i pacchetti di paging, il nodo A controlla la sua cache e scopre che i paging update packets di X sono arrivati recentemente al suo porto attraverso il nodo C. Quindi A inoltra il pacchetto di paging verso C che invece non ha informazioni sull utente X e perciò inoltra il pacchetto in tutte le possibili direzioni. Il pacchetto di paging spedito verso il nodo D si scarta perché D sa che l utente X non è nella sua cella. Quello mandato ad E invece invita il nodo a controllare le sue cache e si scopre che X sta spedendo pacchetti attraverso F; perciò E inoltra il pacchetto di paging a F e quindi a X. 121

122 Figura 4.8: I pacchetti di paging vengono indirizzati dalle PC verso l utente mobile Una volta ricevuto il pacchetto di paging, l utente mobile crea un pacchetto di controllo chiamato pacchetto di aggiornamento dell instradamento (routeupdate packet) e lo invia alla sua stazione basi (F nell esempio dell utente X). Analogamente ai pacchetti di aggiornamento del paging, i pacchetti di aggiornamento dell instradamento viaggiano verso il router gateway in base ad un meccanismo hop-by-hop e creano il mapping nelle Routing Caches per l utente mobile che ha spedito quel pacchetto. Quando i pacchetti di aggiornamento dell instradamento raggiungono il router gateway, tutte le Routing Caches incontrate per la strada vengono automaticamente aggiornate e i pacchetti di dati accodati nel router gateway possono finalmente essere consegnati all utente mobile. Questo processo di ricerca dell utente ritarda la consegna del primo pacchetto di dati ma una volta che il percorso risulta stabilito, i pacchetti seguenti usano le informazioni acquisite precedentemente senza ripetere la ricerca. Comunque se in qualunque momento durante il trasferimento dei dati, l utente diviene temporaneamente irraggiungibile e scadono i timeout delle Routing 122

123 Caches, i prossimi pacchetti di dati genereranno un nuovo processo di paging proprio a partire dalle ultime informazioni che avevano a disposizione. In questo modo anche un black-out temporaneo del canale radio non genera nessuna reazione dell utente, al più provoca un ulteriore ritardo nel processo di paging Routing di Cellular IP I pacchetti di dati emessi da un utente mobile sono instradati verso il router gateway in una base ad una politica hop-by-hop. I nodi che contengono Routing Caches controllano tutti i pacchetti di dati che vi passano e li usano per creare le associazioni tra identificatori di utente e numeri di porto. I pacchetti indirizzati verso l utente mobile sono instradati dalle Routing Caches attraverso un percorso hop-by-hop inverso quando ci sono le relative informazioni oppure vengono mandati in broadcast quando queste informazioni non ci sono. La struttura e le operazione principali del routing sono fondamentalmente le stesse di quelle del paging. Per chiarire la dualità tra i due meccanismi, nella tabella 4.2 si espongono in breve alcune caratteristiche delle Paging Caches a confronto con quelle delle Routing Caches. Può essere utile notare ancora una volta che le due funzioni sono divise a causa dell intrinseca differenza delle temporizzazioni caratteristiche dei relativi meccanismi di funzionamento. 123

124 configurate da localizzazione scopo timeout Paging Caches (PC) tutti i pacchetti generati da un utente mobile (dati,route-update, paging-update) sia degli utenti mobili attivi che idle Instradamento dei pacchetti di paging dell ordine di grandezza della frequenza di handoff Routing Caches (RS) pacchetti dati e route-update packets originati da un utente mobile solo degli utenti mobili attivi instradamento dei pacchetti dati indirizzati ad un utente mobile dell ordine di grandezza del tempo di pacchetto Tabella 4.2: confronto tra PC e RC Le Routing Caches si occupano solamente degli utenti attivi (cioè di quelli che effettivamente stanno ricevendo o emettendo pacchetti di dati) e sono aggiornate da timeout dell ordine di grandezza del cosiddetto tempo di pacchetto, cioè quel tempo necessario alla consegna di un pacchetto. Questo permette alle Paging Caches di operare su una scala temporale molto più grande, la cui misura è data dalla frequenza di handoff, in modo da evitare frequenti aggiornamenti del paging operati da utenti inattivi. L utente mobile può continuare a ricevere pacchetti di dati per un certo tempo anche se non ha niente da spedire. Per mantenere le Routing Caches configurate ed evitare paging ripetuti, gli utenti mobili che sono in attesa di dati ma non hanno nessuno pacchetto da inviare (cosa che succede ad esempio quando è aperta una connessione TCP) 124

125 devono inviare periodicamente i pacchetti di aggiornamento dell instradamento. Così come i pacchetti di dati, anche i route-udate packets configurano le Routing Caches ed assicurano che il percorso di instradamento basato sull hopby-hop dal router gateway verso l utente mobile rimanga aggiornato. Si può notare poi che per scopi di affidabilità, le Paging Caches non smettono mai di inseguire gli utenti quando questi sono attivi e che comunque gli utenti attivi non hanno bisogno di spedire pacchetti di aggiornamento del paging perché le Paging Caches sono configurate anche dai pacchetti di aggiornamento dell instradamento e da qualunque altro tipo di pacchetto generato dagli utenti Handoff di Cellular IP I meccanismi sopra descritti assicurano che gli handoff, che altro non sono che migrazioni durante un trasferimento dei dati in corso, vengano gestiti automaticamente. Un handoff in Cellular IP è sempre provocato dal movimento dell utente: appena un utente si avvicina ad una nuova stazione base, reindirizza i suoi pacchetti di dati dalla vecchia alla nuova stazione. Il primo di questi pacchetti reindirizzati configura automaticamente un nuovo percorso che sarà utilizzato dalle Routing Caches per la localizzazione per di quell utente. Per un tempo uguale a quello del timeout del mapping delle Routing Caches, i pacchetti indirizzati all utente mobile saranno consegnati ad ambo le stazioni base, quella vecchia e quella nuova. Nel caso in cui l apparecchiatura radio dell utente sia capace di gestire due canali logici nello stesso tempo, gli handoff saranno detti soft. 125

126 Se invece l utente non è capace di stare in ascolto di due stazioni contemporaneamente, allora l handoff è detto hard e l efficienza della migrazione dipende esclusivamente dalle apparecchiature radio. Dopo un certo tempo, il percorso relativo alla vecchia stazione base sarà giudicato antiquato e verrà cancellato, mentre i pacchetti inizieranno ad essere consegnati alla locazione corrente dell utente attraverso la sua nuova stazione base. In figura 4.9 è illustrato uno scenario di handoff. L utente mobile X sta trasferendosi dalla cella F a D mentre sta spedendo e ricevendo pacchetti di dati. Presumendo che tutti i nodi abbiano a disposizione delle Routing Caches, prima che l utente si sia mosso, le informazioni di localizzazione delle RC sono quelle indicate nelle bandiere. Dopo la migrazione, i pacchetti di dati generati dall utente, indicate in figura con frecce continue, comunicano al nodo C un nuovo percorso di localizzazione. Per un certo tempo, i pacchetti indirizzati a X sono consegnati sia a D che a F; questo è mostrato in figura con frecce tratteggiate. Dopo un tempo pari al timeout della Routing Cache del nodo E, il vecchio percorso di localizzazione viene cancellato, così come quello della Routing Cache del nodo F. Da quel momento in poi, è usato solamente il percorso di instradamento aggiornato. La cache di A rimane invariata per l intera durata del processo. Questo processo di handoff è semplice, trasparente ed automatico. Nei nodi dove ai vecchi e ai nuovi percorsi corrisponde lo stesso instradamento, i vecchi mapping vengono riusati automaticamente rendendo non necessaria per 126

127 Cellular IP una nuova ricerca per quei punti detti di cross-over. Figura 4.9: Il meccanismo di handoff di Cellular IP Inoltre se vecchie e nuove celle si sovrappongono, c è una piccola interruzione o disturbo nella comunicazione: infatti se all atto di un handoff l utente mobile rimane temporaneamente fuori contatto radio mentre si muove tra due celle, negli strati superiori (cioè i TCP) si possono verificare dei ritardi e alcuni pacchetti possono perfino andare persi; ma la comunicazione è comunque ripresa appena l utente riappare nella nuova cella. Si può verificare che questo meccanismo è efficiente anche se applicato a quegli utenti che temporaneamente risultano irraggiungibili a causa di ragioni diverse dall handoff. Se un utente riappare prima della scadenza del timeout della Routing Cache, il servizio continua senza alcun ulteriore ritardo; se invece il timeout è scaduto, le Routing Caches vengono riconfigurate dal primo pacchetto inviato dall utente al quale non è neanche richiesto di conoscere la sua condizione di raggiungibilità 127

128 dalla Routing Cache quando verso un altra cella. Nella descrizione del processo di handoff, si presuppone implicitamente che l utente mobile abbia sempre pacchetti di dati da spedire. Quando un utente si aggancia alla rete ed entra nella zona di servizio di nuova cella, per configurare il percorso di localizzazione manda immediatamente dei pacchetti di aggiornamento dell instradamento; questo però non accade nel caso di un handoff perché l utente è all oscuro della sua migrazione: è la rete a gestire il tutto in accordo con la regola di non caricare su un terminale le procedure di gestione della rete. Tuttavia siccome i pacchetti di dati hanno lo stesso effetto dei pacchetti di aggiornamento dell instradamento, il meccanismo degli handoff è gestito comunque ottimamente quando un utente invia un pacchetto di dati. Ovviamente nel caso in cui l utente a non abbia nessun dati da spedire, continuerà a inviare pacchetti di aggiornamento dell instradamento alla sua nuova cella per mantenere la localizzazione. Mentre questo processo darebbe luogo normalmente a handoff semplici, ci sono dei casi, soprattutto in sistemi domestici, dove gli handoff si possono verificare con una frequenza molto alta oppure può addirittura accadere che un utente mobile sia sul confine tra due celle e che il suo servizio rimbalzi tra le due stazioni base. Per assicurare una comunicazione continua in queste situazioni, l utente mobile mantiene il percorso di instradamento delle Routing Caches in entrambe le stazioni base spedendo i suoi pacchetti di dati ad una e mandando in parallelo i pacchetti di aggiornano dell instradamento all altra. In questo caso, la rete è preparata per l handoff e la trasmissione di dati sarà 128

129 continua anche nel momento in cui l utente decidesse improvvisamente di spostarsi verso una delle due stazioni diventando irraggiungibile per l altra. Si noti che la stessa politica può essere usata per gli utenti mobili idle per assicurarsi la raggiungibilità: invece di spedire pacchetti di aggiornamento del paging a una sola stazione base, l utente può spedirli a due o più stazioni in parallelo. Cellular IP può usare queste strategie per migliorare la raggiungibilità e la qualità degli handoff in cambio di una piccola degradazione dell efficienza della rete Problemi relativi al disegno del protocollo Nelle sezioni precedenti sono stati descritti i concetti base di Cellular IP e le sue funzioni di paging, instradamento e handoff. In seguito saranno discussi alcuni dettagli algoritmici di Cellular IP Indirizzamento e Migrazione Siccome gli indirizzi dell utente mobile non hanno un significato relativo alla localizzazione all interno di una rete di Cellular IP, può essere usato qualunque spazio di identificatori di utente. L uso dell home address IP è una soluzione semplice ma che allo stesso tempo ha il vantaggio di non cambiare i pacchetti IP né mascherarli quando vengono usati nella rete di accesso. 129

130 Non è necessario nessun incapsulamento né conversione di indirizzo in una rete di Cellular IP: l uso degli indirizzi di IP come identificatori di utente mobile rende la migrazione tra reti di accesso incredibilmente semplice. Un utente mobile che accede ad una rete Cellular IP, ha semplicemente il compito di comunicare l indirizzo del router gateway locale alla sua home agent 1. L home agent invierà quindi i suoi pacchetti al router gateway che a sua volta poi li smisterà sulla rete di Cellular IP. Il processo di paging e settaggio/modifica delle Routing Caches non hanno bisogno di nessuna informazioni preliminare per cominciare a creare le informazioni di mapping per l utente che si è appena agganciato alla rete, né richiedono di essere informati quando un utente mobile lascia rete di accesso Pacchetti di controllo I tre tipi di pacchetti di controllo (del paging, di aggiornamento del paging e di aggiornamento dell instradamento) usati da Cellular IP possono essere regolari pacchetti IP. Tutti e tre i tipi contengono solamente un singolo elemento di informazione: l identificatore dell utente mobile. E poiché questo elemento viene indicato nel campo di origine o di destinazione del pacchetto (per i pacchetti di aggiornamento del paging/dell instradamento e per i pacchetti di paging rispettivamente), la parte contenente il payload può anche rimanere vuota. I pacchetti di controllo possono essere implementati da una IP nuova opzione e 1 L indirizzo di IP del router gateway può essere incluso in una segnalazione di controllo della stazione base. Serve poi anche ad identificare la rete di accesso wireless quando l utente è coperto da più reti di accesso contemporaneamente. 130

131 non è necessario che i router semplici comprendano il funzionamento di questa opzione Configurazione dei nodi In una rete Cellular IP, nessun dei nodi ha bisogno di avere una visione del livello di rete o informazioni topologiche del sistema, né ha bisogno di conoscere la propria posizione all interno della rete. I nodi non hanno bisogno di essere configurati: Cellular IP è una soluzione plug-and-play che permette anche il recupero di un nodo se questo dovesse subire un crash. Comunque in ogni nodo deve essere disponibile una certa quantità di informazioni di routing. Un nodo deve sapere quale dei suoi porti usare per instradare i pacchetti verso il router gateway. Un modo semplice per mantenere queste informazioni è implementato proprio dal router gateway che periodicamente trasmette segnali di controllo in broadcast per permettere che i nodi registrino il porto attraverso il quale hanno ricevuto l ultimo pacchetto. Nella descrizione degli algoritmi, ci si riferirà a questo porto con il nome uplink-port. Inoltre il nodo deve sapere quali dei suoi porti è connesso all uplink-port di un altro nodo 2. Questi porti saranno chiamati downlink-port. È importante che le informazioni di instradamento immagazzinate nei nodi siano consistenti, nel senso che esiste sempre un percorso di instradamento (che si suppone senza cappi) che collega qualsiasi nodo al router gateway. Mentre le modifiche frequenti di questi percorsi di instradamento possono 2 Questa informazione serve ad evitare dei loop quando dei pacchetti indirizzati ad un utente mobile sono inviati in broadcast. 131

132 degradare le prestazioni della rete in termini di aumento dei tempi di consegna e del tasso di perdita dei pacchetti, il ripristino delle informazioni di instradamento dopo un crash o la congestione temporanea di un tratto di rete non mettono in pericolo le prestazioni, anzi questi meccanismi possono essere usati per garantire la tolleranza alle situazioni anomale quando Cellular IP lavora su una rete soggetta a frequenti congestioni Algoritmi dei nodi I nodi che non hanno né Paging Caches né Routing Caches semplicemente inoltrano tutti i pacchetti che arrivano al downlink-port verso il loro uplink-port e i pacchetti che arrivano all uplink-port verso il downlink-port. Un nodo con una Paging Cache deve monitorare tutti i pacchetti che arrivano dai suoi downlinkport: prima di instradarli attraverso l uplink-port, legge l indirizzo del mittente ed lo usa per aggiornare la PC secondo le seguenti regole: se sono disponibili informazioni di localizzazione circa l utente mobile mittente al porto al quale il pacchetto è arrivato, il timer per questo mapping è azzerato; se queste informazioni di localizzazione non esistono, vengono create adesso e il timer viene inizializzato. Quando un pacchetto di paging arriva attraverso l uplinkport, viene controllata la Paging Cache: se esistono informazioni aggiornate sulla localizzazione della destinazione, il pacchetto è spedito sui relativi porti; se non ci sono informazioni di localizzazione, il pacchetto viene scartato. L operazione di un nodo con Routing Caches differisce in due parti: primo, come discusso nel paragrafo , i pacchetti di aggiornamento del paging non aggiornano le Routing Caches. Secondo, invece dei pacchetti di paging, le Routing Caches inoltrano i pacchetti dati che vi arrivano dall uplink-port. Ovviamente possono esserci nodi che hanno allo stesso tempo sia Paging 132

133 Caches che Routing Caches nel qual caso vengono eseguiti entrambi gli algoritmi. I nodi senza Paging Caches indirizzano tutti i pacchetti di paging verso tutti i downlink-port mentre i nodi senza le Routing Caches spediscono tutti i pacchetti di dati che arrivano dall uplink-port a tutti i downlink-port Realizzazione del protocollo Cellular IP definisce una struttura generale che dà grande libertà ad un amministratore di rete di regolare il sistema in funzione delle caratteristiche locali. Attualmente le reti Cellular IP sono soltanto di tipo sperimentale e servono per lo più come testbed per studi di prestazioni di sistema e di dipendenze dei settaggi Realizzazione della temporizzazione I timer giocano un ruolo fondamentale per l efficienza di Cellular IP; anche se l accuratezza delle temporizzatori non è un fattore cruciale (e quindi la sincronizzazione potrebbe essere omessa), i valori dei timeout delle Paging Caches e delle Routing Caches e il periodo di invio dei pacchetti di aggiornamento del paging e dei pacchetti di aggiornamento dell instradamento devono essere dimensionati attentamente per avere buone prestazioni. Per entrambi i timeout, un valore più alto dà luogo a comunicazioni di controllo meno frequenti, ma estende la validità di percorsi non usati. Se dopo migrazione l utente spedisce sempre un pacchetto di aggiornamento 133

134 del paging extra alla nuova stazione base, allora la frequenza dei pacchetti di aggiornamento del paging può essere bassa senza mettere in pericolo la raggiungibilità. L ideale sarebbe settare tale frequenza ad un valore approssimativamente uguale alla quello della frequenza di migrazione. Per mantenere le informazioni di mapping delle Paging Caches anche se si verificano alcune perdite di pacchetti di aggiornamento del paging consecutive, i timeout delle Paging Caches dovrebbero essere qualche multiplo del tempo dei pacchetti di aggiornamento del paging: con questo settaggio, il carico imposto dai pacchetti di aggiornamento del paging sarà comparabile con quello imposto dalla segnalazione relativa alle migrazioni esplicite. Il tasso dei pacchetti di aggiornamento del paging è perciò il parametro primario da considerare per la gestione della mobilità di Cellular IP e va accordato con la dimensione della cella del sistema e la velocità media dell utente. Le prestazioni sono anche molto sensibili ai timeout delle Routing Caches: questo parametro dovrebbe essere settato in modo tale che un utente mobile che generi un handoff soft riceva solo pochi pacchetti da ambo le stazioni base per assicurare handoff senza difetti. Un timeout delle Routing Caches più lungo dovrebbe essere evitato per limitare lo spreco di risorse. Il tasso di invio dei pacchetti di aggiornamento dell instradamento dovrebbe essere tale che durante il timeout delle Routing Caches arrivino pochi pacchetti di aggiornamento dell instradamento per mantenere il mapping anche quando tali pacchetti vanno persi. 134

135 Si noti che in molte sessioni di comunicazione ci saranno anche tanti pacchetti di dati o di acknowledgement emessi dall utente mobile, perciò i pacchetti di aggiornamento dell instradamento non sono sempre necessari Realizzazione delle Caches Un altro modo per adattare la rete alle caratteristiche locali è utilizzando le Paging e le Routing Caches. Anche se il protocollo supporta nodi senza Routing Caches, è probabile che per un utilizzo efficiente delle risorse della rete, si possa scegliere di associare una RC ad ogni nodo. Invece per le Paging Caches, che contengono un data base considerevolmente più grande, si può pensare di posizionarle solamente in alcuni punti strategici della rete. Poiché i nodi senza Paging Caches non fanno altro che inoltrare in broadcast i pacchetti di impaginazione, il processo di paging resta operativo anche con poche PC. Perciò più Paging Caches danno luogo a meno carico di paging in cambio ad un costo hardware ovviamente superiore. Quindi l amministratore posizionerà tipicamente le Paging Caches in nodi con molti porti foglia (cioè quelli che sono connessi ad altri nodi ma che a loro volta non sono connessi con altri) ed in nodi che interconnettono grandi aree della rete che sono separate da tutto il resto. Poiché il carico di routing è proporzionale al numero di sessioni e non al traffico globale, ottimizzare la densità delle Paging Caches è il modo migliore per adattare la rete alle caratteristiche del traffico: un numero di Paging Caches maggiore dovrebbe essere considerato solo nel caso in cui il traffico consista 135

136 principalmente di frequenti burst, cioè di comunicazioni piccole nella durata ma grandi per la quantità di dati inviati; al contrario un numero di Paging Caches minore è giustificato nel caso in cui il traffico sia formato soprattutto da trasmissioni di dati grandi e prolungate nel tempo. Comunque il router gateway dovrebbe contenere sempre una Paging Cache per evitare l accodamento dei pacchetti di quegli utenti che non sono più collegati alla rete di accesso. Sebbene nella descrizione del protocollo questo non è stato evidenziato, è possibile avere nodi che hanno solo Paging Caches per alcuni dei loro downlinkport, ma non per tutti. Questo può avere senso specialmente nel caso di stazioni base con porti molto usati e che perciò dovrebbero avere una PC anche se la loro posizione nella rete può non giustifichi la presenza in quel punto. Questi nodi si comporteranno come stazioni con Paging Caches per i porti per i quali mantengono la cache, ma sembreranno nodi di senza PC per gli altri porti foglia Realizzazione del Paging Dipendentemente dalla dimensione di rete, il tempo per localizzare un utente mobile qualche volta può essere lungo. Sono necessari ulteriori studi per vedere se questi ritardi sono accettabile per la maggior parte delle applicazioni IP: se il ritardo di paging è troppo alto, è possibile usare il primo pacchetto di dati (o i primi pacchetti) come pacchetti di paging invece di accodarli nel router gateway e generare dei piccoli pacchetti di paging. Questa soluzione semplifica anche le realizzazioni dei router gateway, sebbene 136

137 provochi un più alto carico della rete giacché i pacchetti di dati sono ovviamente più grandi di quelli di paging. Si possono poi considerare delle implementazioni più sofisticate, intermedie tra queste due soluzioni proposte e scelte ad hoc in funzione dalla dimensione e dal tipo di payload dei pacchetti Conclusioni su Cellular IP In questo capitolo sono state discusse alcune limitazioni dei protocolli per la gestione di utenti mobili (come Mobile IP) che diventano difficilmente utilizzabili in ambienti wireless dove gli utenti mobili si spostano molto velocemente dando luogo a frequenti operazioni di handoff. Quindi è stato analizzato nei dettagli un altro protocollo chiamato Cellular IP che ha come scopo principale il miglioramento e l integrazione di reti wireless con barriere tecniche di quel tipo. L architettura di Cellular IP conta sulla separazione della mobilità locale dalla mobilità di area estesa. È stato affermato che mentre Mobile IP può sostenere efficientemente la mobilità di un area estesa (come Internet ad esempio), la mobilità locale impone speciali requisiti non presi in considerazione nel disegno e dallo sviluppo di Mobile IP. Si identificano perciò un insieme di requisiti chiave, come la migrazione globale semplice, la connessione passiva leggera, il supporto flessibile degli handoff, la gestione locale efficiente ed il concetto di utente mobile senza memoria: Cellular IP è ottimizzato per reti ad accesso wireless ed è stato progettato per soddisfare questi requisiti chiave. Due ulteriori vantaggi del protocollo sono la sua semplicità e la sua robustezza. 137

138 Una rete Cellular IP inoltre è scalabile: si possono usare gli stessi nodi semplici ed economici sia per piccoli sistemi domestici che per aree metropolitane estese. La semplicità di un nodo di Cellular IP e la capacità di intercomunicazione con Mobile IP facilita ne facilita l introduzione nel panorama attuale dei sistemi di gestione degli utenti mobili, data anche la sua compatibilità con sistemi più datati; per queste proprietà una rete wireless può essere facilmente estesa incrementandone un po per volta la sua dimensione e le sue capacità. Attualmente le reti di Cellular IP esistono solo per scopi sperimentali che serviranno come testbed per studi futuri. 138

139 Capitolo 5 Access Point con supporto della qualità del servizio: HostAP e HostQs Questo capitolo rappresenta la parte principale per l acquisizione dello stato dell arte delle tecnologie che si sono utilizzate: attraverso uno studio dei software di base HostAP 3 e HostQs 4 si può ottenere una prima realizzazione di un Access Point che fornisca un supporto della qualità del servizio. Sfortunatamente le regole sulle quali si basa la politica di schedulazione dell HostQs, o più precisamente di quella parte dell HostQs che viene chiamata Queue Manager, non sono utili alla realizzazione della idea iniziale di cui si è parlato precedentemente. Tuttavia per un buon utilizzo delle strategie da realizzare, si rende necessaria un analisi approfondita di questi due elementi chiave

140 5.1 HostAP Il progetto di HostAP è formato da tre componenti principali: il driver di HostAP che lavora sotto Linux con schede basate su tecnologia Prism2/2.5/3 5 il demone hostapd per gli Access Point: include funzioni base per l autenticazione di sistemi Linux e BSD basate sullo standard IEEE802.11x, identificatori EAP e autenticazioni per server RADIUS WPA Supplicant per driver di Linux, BSD e Windows HostAP è un driver che controlla sotto Linux le schede wireless basate sul chipset Intersil Prism 2/2.5/3. Il driver supporta la cosiddetta modalità HostAP o Master che controlla i time critical tasks, cioè le funzioni di gestione dello standard IEEE802.11x per fa sì che un normale computer agisca come un Access Point, senza alcun aggiunta di ulteriori firmware. Inoltre esso fornisce supporti per le operazioni delle normali stazioni BBS e IBBS. Alcune le funzioni (come WPA e RSN) sono supportate solo se il driver viene accompagnato da altri programmi di utilità quali hostapd e WPA Supplicant

141 Le stazioni con tecnologia Intersil Prism2 supportano il cosiddetto modo HostAP nel quale si gestiscono quei compiti legati alle temporizzazioni critiche come l invio di segnali di controllo e di riconoscimento di frame (beacon e acknowledgement) ma lasciano gli altri compiti di gestione al driver del computer host. Oltre a implementare le funzioni di base necessarie a inizializzare e configurare le schede basate sulla tecnologia Prism2, a inviare e ricevere frame, il driver è anche fornito di un sistema per raccogliere informazioni di tipo statistico. Inoltre esso include un implementazione delle seguenti funzioni dello standard IEEE802.11: autenticazione (e deautenticazione) associazione (con riassociazione e deassociazione) trasmissione di dati tra due stazioni wireless controllo dell energia (PS - Power Saving) gestione di frame per il PS con segnalazioni e buffering. Nel pacchetto di HostAP sono presenti anche altre funzioni per il debugging e il controllo di strutture dello standard IEEE come l accesso alle configurazioni dei record hardware, ai registri di I/O e alle frames con gli header Quando viene usato anche il demone, la combinazione di HostAP e hostapd permette funzioni speciali: il settaggio della chiave come previsto dall IEEE802.1x e del WEP (Wired Encryption Privacy) dinamico; l accounting RADIUS per l autenticazione IEEE (nel caso si utilizzi questo server come supporto); 141

142 l accesso al sistema; e altre funzionalità base dello standard IEEE802.11f. Hostapd è un demone per Access Point e server di autenticazione che implementa alcune funzionalità base degli Access Point previste dallo standard IEEE802.11, come l autenticazione così come preista dello standard IEEE802.1x/WPA e autenticazione RADIUS. Il WPA (Wi-Fi Protected Access) è una tecnologia che ha come scopo la gestione della sicurezza delle reti wireless attraverso la protezione dei dati (encrypting) e il controllo di accesso alla rete attraverso un forte controllo sull utente: l autenticazione e l associazione sono affidati ad un meccanismo di negoziazione di una chiave mentre il roaming è controllato dal driver wireless. Sia l hostapd che il WPA sono disegnati per essere programmi demone che vengono eseguiti in background e agiscono come componenti finali controllando le autenticazioni e le connessioni wireless. 142

143 5.2 HostQs: Differenziazione del traffico in WLAN La questione del supporto della qualità del servizio (QoS - Quality of Service) nelle attuali reti locali senza filo (WLAN - Wireless Local Area Network) è affrontata dal software Queue Manager con un approccio molto innovativo, chiamato HostQs, che mira alla differenziazione del traffico a seconda di requisiti di QoS lavorando a livello 2, ovvero al livello LLC. L approccio è basato sulla creazione di una coda LLC per ogni categoria di traffico e sulla schedulazione delle code in accordo con il concetto di connessione virtuale tra le differenti priorità all interno della stazione wireless. La frame alla testa della coda LLC che vince la contesa è consegnata al livello MAC e gestita in base alle regole di questo sottolivello. Il meccanismo proposto è stato implementato in ambiente Linux su un Access Point Open-Source usando una scheda basata su un chipset Prism Introduzione a HostQs Una delle applicazioni più promettenti delle WLAN basate sulla tecnologia IEEE è senza dubbio il supporto di traffico multimediale come ad esempio Voice over IP (VoIP). In realtà le WLAN potrebbero essere utilizzate con molto successo per 143

144 trasportare traffico voce su un architettura IP se la rete fosse utilizzata solo per questo scopo! Ma nelle WLAN classiche che trasportano traffico di natura eterogenea nascono molti problemi a causa del limitato grado di sviluppo del supporto QoS che l attuale tecnologia b riesce a fornire. L esigenza di servizi più potenti ha portato quindi allo sviluppo di nuovi standard IEEE o almeno a degli abbozzi di standard, come il cosiddetto IEEE e [35], nel quale si definiscono le procedure MAC per supportare applicazioni LAN con requisiti di QoS, compreso traffico voce, audio e video su WLAN. Lo standard IEEE e introduce una funzione di coordinamento ibrido (HFC - Hybryd Coordination Function) e specifica poi due schemi di accesso: l accesso a canale distribuito migliorato (EDCA - Enhanced Distributed Channel Access) e l accesso a canale controllato da HCF (HCCA - HCF Controlled Channel Access) [35]. Un analisi un po più approfondita dei meccanismi di accesso e possono essere trovati in [37]. Tuttavia non si trovano disponibili implementazioni commerciali né dell EDCA né del HCCA e lo studio delle prestazioni si basa soltanto su analisi teoriche e simulazioni. In particolare in [36] viene presentato uno studio analitico mentre in [38], [39] e [40] si possono trovare risultati di simulazione. L approccio HostQs non fa parte dell IEEE e ma può essere visto come un miglioramento dell architettura dello standard IEEE b che fornisce una differenziazione del traffico in modo simile a EDCA ma senza richiedere modifiche al livello MAC. L interpretazione principale di questo approccio è un architettura che può essere vista come una soluzione intermedia prima che lo standard e sia definitivamente e largamente diffuso: siccome l approccio HostQs si basa sugli stessi principi dell EDCA, è comprensibile come entrambe le soluzioni possano 144

145 coesistere e allo stesso tempo, poiché HostQs non apporta modifiche al MAC b, si garantisce una compatibilità di base. Nel prossimo paragrafo si elencano le principali caratteristiche dell EDCA, nel paragrafo si descrivono le modifiche al livello LLC dell IEEE b, nel l implementazione di HostQs su una piattaforma Open-Source e infine nel paragrafo vengono proposti i risultati di alcune misurazioni effettuate con questo nuovo approccio e l effettiva funzionalità della soluzione proposta QoS dell IEEE e: la funzione EDCA In questo paragrafo saranno esposte brevemente le caratteristiche principali dell EDCA; per ulteriori informazioni si rimanda a [35] e [37]. Così come la funzione di coordinamento distribuito (DCF - Distributed Coordination Function) presente nell , anche la funzione EDCA è basata sullo schema CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) e impiega il concetto di Inter Frame Space (IFS) come meccanismo di backoff. Le innovazioni introdotte sono: ogni volta che una stazione e si aggancia a un canale, viene autorizzata a trasmettere una o più frame in un dato intervallo di tempo chiamato Transmission Opportunity (TXOP) che è caratterizzato da una durata massima, indicata con TXOP-limit; vengono definite categorie di accesso (AC - Access Categories), ognuna delle quali corrisponde ad un differente livello di priorità e ad un differente insieme di parametri che vengono usati per la contesa del canale. In particolare una stazione e che opera con la funzione EDCA può includere fino a 4 code MAC. Una coda utilizza i seguenti parametri per accedere al canale: 145

146 o spazio tra due frame (AIFS[AC] - Arbitration Inter Frame Space), parametro simile al DIFS usato dalla DCF; o la Finestra di Contesa Minima e Massima, Contention Window (CW min [AC],CW max [AC]); o il tempo limite TXOP-limit[AC] 6 Più è alta la priorità di una AC, più sono piccoli i parametri AIFS[AC], CW min [AC],CW max [AC]; più è grande TXOP-limit[AC], maggiore risulta la capacità della categoria di accesso. In ogni caso i valori di CW min [AC] e CW max [AC] devono essere scelti con molta cura per evitare situazioni di alta probabilità di collisioni nei flussi di traffico che appartengono alla stessa AC; all interno di ogni stazione e, uno schedulatore risolve le collisioni virtuali tra le code AC, ovvero tra le varie istanze CSMA/CA, abilitando alla trasmissione sempre la coda associata alla priorità più alta Differenziazione del traffico a livello LLC Come già precedentemente sottolineato, l obiettivo principale della implementazione di un nuovo meccanismo di differenziazione del traffico è realizzata attraverso uno schema di priorità simile a quello che lo standard IEEE e introdurrebbe se dovesse gestire un traffico molto eterogeneo, mantenendo comunque una compatibilità di base con le WLAN esistenti. I punti cardine del sistema sono: nessuna modifica introdotta al livello MAC: per questo motivo il protocollo CSMA/CA è applicato come nello standard IEEE b; le 6 Il valore di AIFS deve essere grande almeno quanto l intervallo DIFS; l unica eccezione è rappresentata nel caso di un AP che può usare un AIFS grande anche μs. 146

147 modifiche sono limitate al livello LLC; la differenziazione del traffico è basata sull inserimento delle frame di differenti categorie di traffico in differenti code; tale divisione delle frame viene effettuata in base ad un etichetta che nella soluzione proposta è rappresentata dal valore del campo ToS (Type of Service); sebbene le priorità possano essere forzate usando un qualsiasi algoritmo già esistente (round robin, EDF, ecc.), la scelta di emulare EDCA ha portato ad un supporto delle priorità attraverso contese e collisioni virtuali tra le code LLC. Figura 5.1: Il ToS nel pacchetto IP In figura 5.2 è rappresentato un disegno concettuale del nuovo livello LLC e delle sue due componenti principali, le code di traffico e lo schedulatore delle collisioni. Le diverse frame vengono accodate in accordo con le indicazioni dei livelli superiori: in questa implementazione è stato usato lo standard DiffServ nel campo ToS del pacchetto IP. Ogni coda di traffico i-ma ha una particolare priorità che è espressa dai valori di quantità chiamate Finestra Minima e Finestra Massima di Contesa Virtuale (VCW min,i,vcw max,i - Minimum, Maximum 147

148 Virtual Contention Window). Figura 5.2: Schema del sistema delle code del livello LLC introdotto da HostQs Le code di traffico sono poi servite in accordo all ordine stabilito da una contesa virtuale tra differenti Finestre di Connessione Virtuali VCW i : ad ogni coda di traffico i-ma viene associato un numero intero tra 0 e VCW i che rappresenta il tempo di backoff per la coda i-ma, tempo che sarà indicato con t b,i. La coda con il tempo di backoff più piccolo, che sarà indicato con t b,min, vince la contesa virtuale e viene quindi servita per prima: la frame in cima a tale coda sarà 148

149 perciò la prima ad essere trasferita al livello MAC una volta scaduto il timer di backoff, cioè non appena trascorso il tempo t b,min. Allo stesso istante in tutte le altre code, il valore t b,i viene decrementato di una quantità che corrisponde esattamente a t b,min e ci si prepara ad un nuovo processo di contesa. La coda vincitrice quindi genera un altro tempo di backoff che il cui il valore è tra zero 0 e VCW i e la nuova contesa può iniziare. Se in due code diverse il timer di backoff scade allo stesso istante, la coda a trasferire la prima frame al MAC è quella con la priorità nominale più alta mentre la coda perdente (o le code perdenti) che partecipavano alla collisione virtuale generano un altro tempo di backoff dove però la nuova Finestra di Connessione Virtuale è più grande e il suo valore cresce in maniera esponenziale secondo la relazione: VCW new = old 2 * VCW + 1 Di conseguenza viene generato un flusso da inviare al MAC e l ordine delle frame risulta lo stesso di quello che sarebbe stato rispettato da una stazione wireless e. Successivamente le frame vengono trasmesse (o sarebbe meglio dire che cercano di essere trasmesse) con spaziatura temporale che ricorda quella del sistema di backoff orientato alle priorità adottato nello standard e. Ovviamente con questo metodo a fianco alla struttura dei tempi di backoff imposta al MAC si introduce un ulteriore backoff ma questa sovrapposizione è necessaria per forzare la stessa priorità tra le varie stazioni wireless della WLAN: in questo modo il traffico con bassa priorità accede al canale in media con un tempo più lungo del normale periodo di backoff. 149

150 In seguito si vedrà che il backoff addizionale viene richiesto solo se più di una stazione implementa la differenziazione di traffico allo strato LLC, nel qual caso il traffico con bassa priorità viene egualmente penalizzato L implementazione di HostQs L architettura di seguito proposta è stata implementata su un sistema Linux facente uso di una scheda di rete dotata di una tecnologia particolare 7. Il sistema è fornito quindi di un driver capace di supportare la cosiddetta funzionalità HostAP [41], cioè ha la capacità di gestire le funzioni dello standard IEEE in modo tale da trasformare un normale computer portatile fornito di una scheda di rete wireless in un potente Access Point senza richiedere l utilizzo di alcun firmware ulteriore. Oltre a comportarsi come un Access Point, la funzionalità HostAP supporta anche la possibilità di gestire le normali operazioni sulle stazioni di una sottorete semplice o BSS (Basic Service Set). Nella modalità HostAP, il firmware si occupa della gestione dei compiti basati sui cosiddetti tempi critici come ad esempio l invio di segnali e la richiesta di conferme di avvenuta ricezione delle frame (in gergo dette acknowledgement o ack), lasciando gli altri compiti di gestione al computer host. Questo driver implementa inoltre le funzionalità base necessarie per inizializzare e configurare una scheda basata su tecnologia Prism2, per mandare e ricevere frame e per raccogliere informazioni di tipo statistico. Inoltre esso include l implementazione di molte funzioni IEEE come l autenticazione (e la deautenticazione), l associazione (la reassociazione e la deassociazione) di una utente mobile, la trasmissione dati tra due stazioni wireless, il controllo della potenza (PS - Power 7 scheda di rete dotata di chipset basato su tecnologia Intersil s Prism2/2.5/3. 150

151 Saving) e buffering di segnali e di frame per le stazioni PS. HostQs è stato implementato attraverso la modifica del codice originale del driver HostAP e l aggiunta di un modulo supplementare che si occupa di frame allo strato LLC (figura 5.2). Il modulo del driver contiene una funzione di trasmissione modificata che invia i pacchetti di rete non direttamente allo strato MAC ma prima al modulo supplementare la cui funzione di accodamento è rappresentata attraverso simboli del kernel. La funzione di trasmissione originale è mantenuta nel driver sotto un nome diverso e rappresentata anch essa attraverso simboli del kernel in modo da permettere che possa essere utilizzata dal modulo supplementare per la spedizione dei pacchetti. Il modulo supplementare conserva i pacchetti in code separate, dipendentemente dai loro valori del ToS; un elemento separato risolve la contesa virtuale e schedula le frame secondo il risultato della contesa virtuale. Quando pacchetti devono essere spediti, il modulo utilizza la funzione di trasmissione originale implementata nel driver di HostAP, così i messaggi vengono spediti nello stesso ordine in cui erano stati accodati dallo strato superiore. Le code di traffico implementate con priorità decrescente sono le seguenti : traffico in tempo reale (ad esempio chiamate VoIP) applicazioni di streaming multimediale dati best effort (trasferimento file, navigazione web, ecc.) e i valori di VCW che vi sono stati assegnati sono mostrati in tabella 5.1. La realizzazione è stata ottimizzata in modo da poter essere lanciata anche su terminali lenti: nelle prove eseguite è stato usato un sistema operativo Linux versione installato su un Pentium III da 450 MHz con 256 MB RAM. 151

152 Una implementazione Open-Source di HostQs è disponibile su rete [42]. Tabella 5.1: Impostazione del VCW Risultati del test In figura 5.3 è mostrata la configurazione di rete utilizzata per il test. Figura 5.3: Scenario del test Il nodo di HostQs è configurato come un Access Point per una BSS che include alcune stazioni wireless indicate con WS (Wireless Stations). HostQs raccoglie 152

153 traffico da un sintetizzatore di voce, da un generatore di streaming video e da un generatore di traffico TCP. Quindi spedisce le frame alle varie WS dopo aver stabilito le priorità attraverso il meccanismo della contesa virtuale. Le priorità sono assegnate in ordine decrescente a voce, video e dati rispettivamente; in tabella 5.1 sono stati riportati i valori scelti per le rispettive VCW min e VCW max. Le stazioni wireless accedono al canale usando i criteri dello standard IEEE b senza alcun miglioramento e senza alcuna priorità sul traffico. Così la differenziazione di traffico e l impostazione delle priorità è realizzata solamente dalla direzione di downstreaming, in altre parole il blocco avviene tra Queue Manager e il driver HostAP ma solo nella fase di invio dei dati diretti alle WS. La fonte di voce sintetica proveniente dal server voce è pensata per emulare un flusso di traffico che potrebbe essere generato da VoIP codificato attraverso vocoder G.711 a 64 Kbps senza nessuna funzione di rivelazione di voce VAD (Voice Activity Detection). Lo streaming video è di tipo Unicast, scorre con una frequenza di 350 Kbps ed è generato da un server Fenice, un progetto Open- Source studiato appunto per applicazioni di questo tipo[43]. Alcuni esperimenti comprendono anche interferenza di traffico UDP, generato sinteticamente nella direzione di downstream. La valutazione delle prestazioni relative alla qualità della voce è operata da elementi come Agilent VQT e PESQ [44]. PESQ (Perceptual Evaluation of Speech Quality) è un tool di misurazione che può predire i risultati di un test di ascolto su sistemi di telefonia basandosi su un modello sensoriale che confronta il segnale originale, e perciò non processato, col il segnale degradato dalla rete o da un elemento della rete. La qualità che alla fine ne risulta è analoga a una qualità media soggettivamente testata, 153

154 cioè misurata con prove empiriche; il valore che si dà a questa grandezza si indica con l acronimo MOS (Mean Opinion Score). I risultati di PESQ sono calibrati usando un database molto complesso di test soggettivi che dà alla qualità media soggettivamente testata una valutazione da 1 a 4.5. La qualità eccellente è indicata con valori tra 3.2 e 4.5, quella mediocre è rappresentata da valori di PESQ tra il 2.5 ed il 3.2, quella cattiva infine ottiene valori inferiori a 2.5. La valutazione della prestazione di traffico video è operata direttamente dai client video, in termini di percentuale di pacchetti video perduti. Come nota finale, si riporta l osservazione che l uso di HostQs in una situazione dove la BSS è formata da stazioni wireless che non offrono un supporto di qualità del servizio, ha suggerito una semplificazione nell algoritmo di schedulazione di HostQs stesso. Infatti c è effettivamente un piccolo svantaggio nell usare un meccanismo supplementare di gestione dei tempi di backoff nello strato LLC poiché ogni WS usa una scheda gestita dai criteri di IEEE b: il traffico al livello di HostQs sarebbe perciò inutilmente ritardato e i relativi pacchetti verrebbero retrocessi per abbassare le priorità rispetto al traffico proveniente dalle stazioni wireless, senza tener conto delle effettive priorità interne. Analogamente l uso di HostQs in un architettura che non supporta qualità del servizio ha poco senso in termini di AIFS (Arbitration Inter Frame Space), cioè lo spazio tra due frame. Per questo motivo, lo strato LLC dell HostQs è autorizzato a inoltrare immediatamente le frame al livello MAC quando la contesa è risolta, senza aspettare il tempo di backoff. Le contese virtuali divengono così semplicemente un algoritmo di ordinazione all interno del blocco HostQs, sebbene abbiano l importantissima proprietà di fornire un ordinazione simile a quella della funzione EDCA dello standard 154

155 802.11e. Nella tabella 5.2 è mostrata una valutazione preliminare: lo scopo è riportare delle scelte di CW min e CW max col relativo throughput ottenuto da due flussi UDP con diverse priorità che usano quei CW. Ai due flussi corrispondono diversi valori del ToS nell header IP; questi valori del ToS sono quindi elencati secondo tre categorie di accesso diverse, una alta indicata con H, una media indicata con M e infine una bassa indicata con L; il ToS pari a 6 indica una priorità alta, pari a 5 per una priorità media, pari al valore nullo per una priorità bassa. Tabella 5.2: Throughput dei flussi UDP per differenti valori di CW, ovvero per priorità alta (H), media (M) e bassa (L) I throughput della tabella misurati in Mbps evidenziano che: è possibile ottenere delle priorità scalabili, cioè gradi diversi di priorità. Infatti da un analisi più accurata dei valori risulta che nella metà superiore della tabella si nota una differenza di throughput molto grande tra flussi con priorità alta e i flussi con priorità bassa; nella metà inferiore della tabella invece la differenza di throughpu tra i flussi con priorità alta e i flussi con priorità media è molto ridotta; 155

156 CW min è il parametro dominante, mentre il sistema è insensibile alle variazioni del valore di CW max. Si osservi infatti che nella seconda riga della tabella 5.2 è stato cambiato solo un valore rispetto alla prima riga: il CW min è stato ridotto da un valore 3 ad un valore nullo; per la relativa categoria di accesso bassa (indicata con L) questo equivale a dare una priorità molto bassa a tutti i flussi di quella categoria, come del resto ci si poteva aspettare. Si noti poi che nella terza riga della tabella 5.2 invece, l unico valore ad essere stato variato risulta il CW max della categoria di accesso alta, ridotta da un valore di 1023 a un valore di 511: la risposta del sistema in termini di throughput risulta assolutamente invariata! Il successivo insieme di risultati si riferisce ad un singolo flusso VoIP con rumore di fondo crescente che interferisce con traffico UDP. Figura 5.4. PESQ come funzione del traffico UDP formato da un flusso VoIP e traffico interferente 156

157 La figura 5.4 mostra il PESQ rilevato per tale flusso visto come funzione del traffico globale offerto alla WLAN. Le due curve della figura riportano le prestazioni del flusso VoIP con e senza il supporto delle priorità. Si vede chiaramente che nel caso in cui vengano applicati solamente i normali criteri di gestione del traffico dello standard IEEE b senza il supporto delle priorità, la qualità del flusso VoIP comincia a degradarsi appena dopo i 4 Mbps di traffico offerto e che prima dei 5 Mbps la qualità scende molto al di sotto di livelli accettabili. L ultimo insieme di risultati delle figure 5.5, 5.6 e 5.7 mostrano le prestazioni di una WLAN che trasporta un singolo flusso VoIP e 1, 2 o 3 streaming video concorrenti, considerati di nuovo come una funzione di traffico UDP interferente. È interessante osservare che nel caso in cui vengano applicati solamente i normali criteri di gestione del traffico IEEE senza il supporto delle priorità, sia VoIP che i flussi di video incontrano una degradazione della qualità approssimativamente della stessa consistenza che si riscontra fra i 4.5 Mbps e 5 Mbps, dipendentemente dal numero di video concorrenti. Al contrario il traffico che ha precedenza, cioè quello voce e video, sebbene con priorità diverse, mantiene lo stesso livello di QoS indipendentemente dal carico della rete. 157

158 Figura 5.5: PESQ e percentuale di perdita di pacchetti video come funzione del traffico UDP interferente formato da un flusso VoIP, uno streaming video e traffico interferente Figura 5.6: PESQ e percentuale di perdita di pacchetti video come funzione del traffico UDP interferente formato da un flusso VoIP, due streaming video e traffico interferente 158

159 Figura 5.7: PESQ e percentuale di perdita di pacchetti video come funzione del traffico UDP interferente formato da un flusso VoIP, tre streaming video e traffico interferente Conclusioni e sviluppi futuri Nel contesto delle reti locali ad accesso wireless (WLAN) è stato studiato un approccio innovativo che punta alla differenziazione del traffico al livello LLC in base a dei requisiti di qualità del servizio. Questo approccio chiamato HostQs è basato sulla creazione di una coda al livello LLC per ogni categoria di traffico desiderata e sulla schedulazione delle code in base a priorità di traffico. Questo meccanismo può offrire una differenziazione di traffico per lo standard IEEE b attualmente in uso che non supporta alcun tipo di gestione delle precedenze e allo stesso tempo può servire per migliorare il supporto della qualità del servizio già previsto nel nuovo standard e, benché nella versione attuale la gestione sia limitata a sole 4 categorie di accesso. 159

160 È stato implementato a tale scopo un meccanismo basato su un Access Point Open-Source che lavora in ambiente Linux e che si appoggia su un altro interessante progetto chiamato HostAP che richiede l uso di una scheda di rete basata su un chipset con tecnologia Prism2. Sono stati poi mostrati dei risultati preliminari che illustrano la flessibilità e l efficacia di configurazioni di BSS in cui HostQs venga montato su un solo nodo, circondato poi da molte altre stazioni che lavorano in una normale ambientazione wireless basata sullo standard IEEE b. Gli sviluppi futuri prevedono uno scenario in cui anche le singole stazioni wireless implementino un sistema di differenziazione del traffico basato su classi di servizio che vengano gestite dallo strato LLC in modo da raggiungere una interoperabilità ottimale tra i vari nodi di una rete. 160

161 Capitolo 6 Sviluppo software e misurazioni Per poter realizzare l idea iniziale di sviluppare un prodotto software che gestisca il supporto della qualità del servizio su sistemi wireless secondo i criteri utili per il nostro fine, il punto di partenza è stato l utilizzo dello schedulatore fornito da Queue Manager che si appoggia a sua volta su HostAP: il primo pacchetto software fornisce il vero e proprio schedulatore che a seconda di determinate informazioni lette nell header IP, accoda i pacchetti in diverse liste, ognuna delle quali dotata di un proprio livello di priorità; il secondo software invece fornisce il driver che gestendo i tempi critici delle schede wireless dotate di tecnologia Intersil Prism, è capace di utilizzare un normale terminale mobile come se si trattasse di un vero e proprio Access Point: esso permette di ricevere - oltre che di inviare - le informazioni via radio. Questi due software messi insieme forniscono quello che è stato chiamato l approccio HostQs: 161

162 Figura 6.1: Gestione dei sottolivelli LLC e MAC Tuttavia l HostQs, di cui è presente una implementazione su Internet [42], basa la distinzione del traffico e la selezione dei pacchetti sul parametro ToS (Type of Service) dell header IP. In verità tale campo fu pensato proprio per scopi di questa natura: infatti nei suoi 8 bit, il ToS ne contiene 3 che rappresentano il sottocampo chiamato Precedence, i 3 bit successivi sono i flag Delay, Throughput e Reliability, mentre gli ultimi 2 bit completano l ottetto e sono riservati per scopi futuri. 162

163 Figura 6.2: I bit del campo ToS Su 3 bit possono codificarsi 8 valori, ma come già affermato precedentemente, Queue Manager implementa solo 3 code, a ognuna delle quali è associata un livello di precedenza. Le 3 code si riferiscono a: traffico in tempo reale (ad esempio chiamate VoIP) applicazioni di streaming multimediale dati best effort (trasferimento file, navigazione web, ecc.) L ordine dell elenco rappresenta anche l ordine della priorità. Ma da un analisi più approfondita del codice sorgente si può vedere che esiste 163