Comprimiamo l’UDP

Benvenuti a un nuovo appuntamento con la Rubrica Firmware Reload di Elettronica Open Source. In questa Rubrica del blog EOS abbiamo raccolto gli articoli tecnici della vecchia rivista cartacea Firmware, che contengono argomenti e temi passati ancora di interesse per Professionisti, Makers, Hobbisti e Appassionati di elettronica. La compressione dell’Header del protocollo UDP/IP è sicuramente uno degli aspetti più interessanti della tecnologia mobile perché permette di apportare significative prestazioni alle connessioni wireless.

Introduzione

La tecnologia mobile e Internet possono ben rappresentare due esempi significativi del progresso tecnologico di questi anni, come dimostrano le loro continue innovazioni ed i significativi trend di crescita. Il segmento mobile, insieme con la tecnologia Internet, offre una grande offerta di servizi che mirano, in prima battuta, a soddisfare le diverse esigenze degli utenti: da una comunicazione facile e flessibile fino a definire una piattaforma integrata con la coesione di differenti tecnologie. Infatti, si sta sempre più assistendo a una reale convergenza dei diversi media su un’unica piattaforma, con la possibilità di accedere ad essi in condizioni di mobilità, dovunque, e tramite svariati mezzi: gli utenti si aspettano di poter comunicare utilizzando qualsiasi rete insieme alla possibilità di scambiare email, trasportare la voce e diffondere le informazioni con estrema flessibilità. L’idea di base consiste nell’arrivare a un sistema distribuito in grado di offrire i servizi al pari della telefonia fissa cercando di coniugare sicurezza, affidabilità con prestazioni del tutto paragonabili utilizzando politiche QoS e sistemi trasmissivi estremamente flessibili e deterministici. In un sistema di questo tipo, le architetture basate su tecnologia mobile ben difficilmente possono assicurare le stesse prestazioni dei dispositivi fissi, anche per via delle bande di frequenza in gioco. Infatti, le connessioni via radio soffrono di limitazioni in termini di banda disponibile e di Bit Error Rate. La tendenza attuale, anche per ridurre gli investimenti, è cercare di uniformare l’intera connessione utilizzando il protocollo IP sia per le comunicazioni voce sia per i dati anche se, per via della larghezza di banda del canale radio, diventa necessario ottimizzare l’uso delle risorse.

È doveroso anche precisare che l’uso di un’architettura basata su IP (Internet Protocol), TCP o UDP non sempre si rileva ottimale; infatti, questi protocolli si basano su successivi incapsulamenti prodotti dai vari livelli per fornire servizi ai livelli superiori: una parte della banda richiesta dal servizio è così utilizzata per la trasmissione di informazione inutile e/o ripetitiva. Pensiamo, ad esempio, alle comunicazioni basate su RTP e UDP: in questo caso ci riferiamo alla tecnologia Voice over IP, dove troviamo un header di 40 byte nel caso di IPv4, o di 60 per IPv6, del tutto inutile, in termini funzionali, all’intero sistema. Al solito, per tentare di risolvere problemi di questo tipo, si ipotizza di utilizzare tecnologie compressive; in altre parole, la compressione delle informazioni da trasmettere, applicata sia ai “dati utente” veri e propri (data compression) sia soprattutto alle “informazioni di controllo” che li seguono nel loro percorso attraverso la rete (header compression). In questo particolare contesto, con questa tecnologia si intende la possibilità di comprimere la parte dati, il payload, o la sezione di controllo, anche nota come header compression. Quando si parla di rete mobile, spesso ci si riferisce alle reti a commutazione di pacchetto perché esse sono quelle che, più di ogni altra soluzione, riescono a offrire un uso ottimale e flessibile delle risorse disponibili. In questo caso le informazioni da trasmettere sono suddivise in unità indipendenti, ossia pacchetti, che possono transitare su uno qualunque dei canali fisici disponibili.

Ogni pacchetto contiene sia l’informazione d’utente, come i campioni di voce digitalizzata nel caso delle conversazioni telefoniche, sia l’informazione di controllo necessaria affinché i pacchetti possano muoversi nella rete, indipendentemente gli uni dagli altri, diretti verso la destinazione. In questo modo, ogni canale è sempre a disposizione di più utenti, i quali pagheranno il servizio non più in base al tempo di connessione, ma in base al volume di traffico generato. La compressione della parte header può essere rappresentata in Figura 1. Una riduzione del pacchetto da trasmettere implica anche migliorare il Frame Error Rate dove, a parità di rumore, il canale trasmette meno bit ottenendo un tasso d’errore sui pacchetti inferiore rispetto a un invio tipico. Non solo, con la compressione dell’header si ottiene anche un risparmio della banda che, con l’algoritmo ROHC, può arrivare anche a valori consistenti.

Figura 1: decompressione e compressione dell’header.

Figura 1: Decompressione e compressione dell’header

COMUNICARE CON LA “RETE”

Certamente l’obiettivo che consente di offrire un nuovo sistema di telecomunicazione universale non può non passare per una piattaforma che consenta una facile interoperabilità tra il mondo mobile e quello “tradizionale” su sistema fisso. Dunque diventa necessario integrare reti e servizi con caratteristiche e requisiti tecnici spesso molto diversi tra loro, con la particolarità di doverlo fare in modo “efficiente”. Non solo, diventa anche necessario proporre una QoS tale che permetta una diffusione rapida e flessibile della comunicazione. Per cercare di soddisfare questi requisiti ci si è decisamente orientati verso una piattaforma unica a commutazione di pacchetto, basata sul protocollo IP: questo protocollo è davvero l’unico collante che consente lo scambio di dati tra il gran numero di reti eterogenee che ne fanno parte.

La Figura 2 pone in evidenza l’header UDP: come si può vedere la struttura è abbastanza semplice. Ricordiamo che, in base allo standard ISO/OSI, la comunicazione tra i vari livelli avviene attraverso la tecnica dell’incapsulamento in trasmissione e del demultiplexing in ricezione. In trasmissione, il protocollo di ciascun livello riceve dati dal protocollo di livello superiore (payload) e aggiunge una propria - [1] RFC 3095 (luglio 2001) – ROHC: Framework and four profiles (RTP, UDP, ESP, and uncompressed) - [2] RFC 3096 (luglio 2001) - Requirements for robust IP/UDP/RTP header compression intestazione (header), dopodiché passa il tutto al livello inferiore. Il processo termina in corrispondenza del livello fisico dove viene generato il frame finale da trasmettere. La dimensione dell’header cambia in base al protocollo utilizzato; in effetti, con uno schema TCP la sua dimensione è pari a 20 byte, mentre con UDP essa si riduce a 8 byte.

Figura 2: pacchetto UDP.

Figura 2: Pacchetto UDP

LA COMPRESSIONE DELL’HEADER

Negli ultimi anni sono stati definiti diversi algoritmi di compressione per architetture di rete, ma questi si sposano ben difficilmente per applicazioni wireless, anzi si prestano in modo particolare per rispondere ai diversi criteri di efficienza e di ottimizzazione per i sistemi a rete fissa. Infatti, i sistemi così definiti non hanno l’esigenza di rispettare precisi vincoli di affidabilità: l’elevata rumorosità che caratterizza un canale radio, insieme con un elevato tempo minimo di interazione tra l’host mobile e la rete di trasporto cui è collegato, non garantiscono quei criteri funzionali che ne permettono l’uso in contesti tradizionali. Uno degli algoritmi di compressione che gode di maggiore credito è lo schema ROHC, ossia Robust Header Compression. Lo schema ROHC riesce a offrire un algoritmo di compressione in grado di gestire qualsiasi tipo di traffico implementabile su piattaforma TCP/IP, nell’ambito di un sistema misto wireless wired. In base alle sue specifiche, questo algoritmo di compressione suddivide i flussi di pacchetti in classi e definisce, per ciascuna di esse, un adeguato profilo di compressione, ossia un insieme di regole con le quali vanno interpretati i pacchetti durante il processo di compressione/decompressione.

L’ALGORITMO ROHC

L’algoritmo ROHC è in grado di gestire ogni tipo di flusso di pacchetti che faccia riferimento a una qualsiasi pila protocollare, anche se i candidati ideali rimangono i flussi RTP/UDP/IP. La compressione sfrutta la ridondanza esistente tra i campi dell’header sia nel singolo pacchetto sia tra pacchetti dello stesso flusso. Ai fini della compressione, ognuno degli header gestiti dall’algoritmo viene suddiviso in tre parti: statica, dinamica, ridondante, come mostra la Figura 3.

Figura 3: divisione dell’header del pacchetto.

Figura 3: Divisione dell’header del pacchetto

Figura 4: header IPV6.

Figura 4: Header IPV6

La parte statica è costituita dai campi che si mantengono costanti durante tutta la connessione. In condizioni ideali, tali campi possono essere inviati solo con il primo pacchetto della connessione perché, di norma, esso non è modificato durante la connessione. Al contrario, la parte dinamica è costituita dall’insieme dei campi che variano, in modo più o meno frequente, durante la singola connessione e che quindi devono essere trasmessi con ogni pacchetto. La parte ridondante, al contrario, è costituita da quei campi i cui valori possono essere ricavati attraverso la conoscenza della parte statica e dinamica o attraverso i campi degli header dei livelli inferiori a quello di rete: la parte ridondante, di solito, può non essere trasmessa nel corso della connessione. Ogni connessione ha un context associato, ovvero l’insieme delle parti statiche e dinamiche, oltre ad attributi propri, che ne permette di definire il flusso della connessione. Il CID, o Context Identifier, è un parametro che permette di identificare un singolo context assegnato durante la negoziazione tra ricevitore e trasmettitore.

Questa particolarità offre un indubbio vantaggio; in effetti, in questo modo è possibile, su uno stesso link, disporre di differenti flussi di compressione e decompressione. Non solo, il formato del pacchetto inviato dal compressore al momento della negoziazione permette al decompressore di registrare l’identificatore del contesto, o CID, associato alla connessione. In questo schema, il rapporto di compressione aumenta con il tempo di connessione: si passa da una fase iniziale con una compressione praticamente nulla, in cui manca solo la parte ridondante e, anzi, vengono anche aggiunte informazioni utili per inizializzare la connessione, fino a prevedere di inserire anche i campi dinamici che sono suscettibili di variazioni tra ogni invio. Secondo lo schema di decompressione in uso, ad ogni transazione è necessario registrare, per tutta la durata della connessione, il context associato, aggiornando gli attributi in base ad ogni pacchetto gestito. Lo schema prevede la definizione di profili di compressione, ossia un insieme di regole per ogni particolare protocollo utilizzato, al fine di ottimizzare i flussi sul canale. Lo schema ROHC prevede diversi profili di compressione:

  • il profilo ROHC RTP comprime flussi di dati RTP/UDP/IP tipicamente utilizzati in contesti VoIP
  • il profilo ROHC UDP comprime i flussi di tipo UDP/IP
  • il profilo ROHC ESP è utilizzato per comprimere i flussi protetti mediante protocollo di sicurezza dei dati
  • il profilo ROHC IP comprime i flussi che non appartengono ad alcuno dei precedenti ma che usano sempre il protocollo IP a livello di rete
  • il profilo ROHC UNCOMPRESSED è utile per comprimere i pacchetti che non possono essere compressi dai profili precedenti

Quando si ha l’esigenza di introdurre un nuovo profilo è necessario inserire una nuova regola sintattica che rispetti la politica di connessione. Così, in caso di trasmissione con un profilo TCP/IP, i campi che presentano valori costanti e noti a priori non devono essere inviati. Rientrano in questo insieme proprio i campi della pila TCP/IP, quali IPv6 Payload Length, IPv4 Header Length, IPv4 Reserved Flag, IPv4 More Fragment (MF) Flag, IPv4 Fragment Offset, TCP Header Length, TCP Reserved, IPv4 Header Checksum e IPv4 Total Length. Allo stesso modo, devono essere trasmessi solo all’inizio i campi che contengono valori costanti durante la vita di un flusso di pacchetti. Si tratta dei seguenti campi: IPv6 Version, IPv6 Source Address, IPv6 Destination Address, IPv6 Flow Label, IPv4 Version, IPv4 Source Address, IPv4 Destination Address, IPv4 Don’t Fragment (DF) Flag, IPv4 Network Byte Order (NBO) Flag, IPv4 Random (RND) Flag, TCP Source Port e TCP Destination Port. Infine, si prevede di trasmettere solo all’inizio, con riserva di aggiornamento, i campi che cambiano solo occasionalmente, ovvero i campi IPv6 Next Header, IPv6 Traffic Class, IPv6 Hop Limit, IPv4 Protocol, IPv4 Type Of Service (TOS), IPv4 Time To Live (TTL), TCP Window Size, TCP Urgent Pointer e TCP flag URG, ACK, PSH, RST, SYN, FIN.

I campi critici in uno schema ROHC sono quelli che variano sempre, in modo più o meno regolare, tra un pacchetto e l’altro di uno stesso flusso, tanto da dover prevedere un efficiente meccanismo di aggiornamento (codificando opportunamente e trasmettendo solo le variazioni) e ci si deve anche preparare ad inviarli così come sono in talune condizioni: TCP Sequence Number, TCP ACK Number e IPv4 Identification. Uno dei punti chiave dello schema ROHC è la sua robustezza, ossia la possibilità di impedire la propagazione degli errori per mezzo di interventi sul context. In ambito ROHC è opportuno ridurre la propagazione degli errori ricorrendo a controlli aggiuntivi assieme ad una riparazione del context utilizzato. Esistono almeno due meccanismi per controllare la presenza degli errori: il CRC e TWICE. Il primo meccanismo si basa su una verifica del CRC di ogni livello: solo i pacchetti decompressi che rispettano il CRC (3, 7 o 8 bit) possono aggiornare il context ed essere consegnati al rispettivo livello. A seguito di verifiche errate nella decodifica o di un context non valido si applicano gli algoritmi di correzione. Il secondo sistema, TWICE, verifica, dopo la decompressione, il checksum TCP: in caso di incongruenze si tenta di riparare i diversi campi dinamici. In caso di errori persistenti occorre procedere a una ritrasmissione del pacchetto.

Scarica subito una copia gratis

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend