10. Header Compression (Compressione delle intestazioni)

Esiste una quantità significativa di lavoro pubblicato e in corso di standardizzazione sulla compressione delle intestazioni. Tuttavia, la compressione delle intestazioni per IPv6 over IEEE 802.15.4 ha vincoli diversi, riassunti di seguito:

• Il lavoro esistente assume molti flussi tra due dispositivi qualunque. Qui si assume uno stile di compressione delle intestazioni molto semplice e con poco contesto. Pur essendo indipendente dal lavoro sui flussi, che possono anche essere più di uno, non usa alcun contesto specifico di flusso. Pertanto non può raggiungere il grado di compressione ottenibile da schemi che costruiscono contesti separati per ciascun flusso da comprimere.

• Date le dimensioni estremamente limitate dei pacchetti, è altamente desiderabile integrare la compressione di livello 2 e livello 3, cosa tradizionalmente non fatta, anche se sta cambiando grazie al lavoro del gruppo ROHC (RObust Header Compression).

• Ci si aspetta che i dispositivi IEEE 802.15.4 siano dispiegati in reti multi-hop. Tuttavia, la compressione delle intestazioni in una rete mesh è diversa dallo scenario usuale di collegamento punto-punto, in cui compressore e decompressore comunicano direttamente ed esclusivamente fra loro. Nelle reti IEEE 802.15.4 è altamente desiderabile che un dispositivo possa inviare pacchetti con intestazioni compresse attraverso qualunque vicino, con una costruzione preliminare del contesto quanto più ridotta possibile.

Ogni nuovo formato di pacchetto richiesto dalla compressione delle intestazioni riusa il formato di pacchetto di base definito nella Sezione 5, usando valori Dispatch diversi.

La compressione delle intestazioni può produrre un allineamento che non cade su un confine di ottetto. Poiché l'hardware normalmente non trasmette unità inferiori all'ottetto, è necessario usare padding. Il padding è eseguito così: prima si dispongono tutte le intestazioni compresse contigue, questo documento definisce solo schemi di compressione per intestazioni IPv6 e UDP, anche se altri schemi possono essere definiti altrove. Poi si aggiungono bit zero quanto basta per allineare al confine di ottetto. Questo elimina il possibile disallineamento introdotto dalla compressione delle intestazioni, così che i campi successivi, ad esempio intestazioni non compresse o payload dati, inizino su un confine di ottetto e procedano normalmente.

10.1. Encoding of IPv6 Header Fields (Codifica dei campi dell'intestazione IPv6)

Unendosi alla stessa rete 6LoWPAN, i dispositivi condividono una parte dello stato. Questo consente di comprimere le intestazioni senza costruire esplicitamente uno stato di contesto di compressione. Di conseguenza, la compressione delle intestazioni 6LoWPAN non conserva stato di flusso; si basa invece su informazioni associate all'intero collegamento. I seguenti valori dell'intestazione IPv6 sono previsti come comuni in una rete 6LoWPAN, perciò l'intestazione HC1 è progettata per comprimerli efficacemente fin dall'inizio:

• Version è IPv6
• Gli indirizzi IPv6 sorgente e destinazione sono entrambi link-local
• L'Interface Identifier IPv6, cioè i 64 bit meno significativi, dell'indirizzo sorgente o destinazione può essere dedotto dagli indirizzi sorgente e destinazione di livello 2; ciò vale naturalmente solo per Interface Identifier derivati dagli indirizzi MAC 802.15.4 sottostanti
• La lunghezza del pacchetto può essere dedotta dal livello 2, tramite il campo "Frame Length" nella PPDU IEEE 802.15.4, o dal campo "datagram_size" dell'intestazione di frammentazione, se presente
• Traffic Class e Flow Label sono entrambi zero
• Next Header è UDP, ICMP o TCP

L'unico campo dell'intestazione IPv6 che deve sempre essere trasportato per intero è Hop Limit (8 bit). A seconda di quanto il pacchetto corrisponde a questo caso comune, alcuni campi potrebbero non essere comprimibili e dovranno quindi essere trasportati "in-line" (Sezione 10.3.1). Questa intestazione IPv6 comune, descritta sopra, può essere compressa a 2 ottetti, uno per la codifica HC1 e uno per Hop Limit, invece dei 40 ottetti originali.

Un pacchetto di questo tipo può essere compresso con il formato LOWPAN_HC1 usando il valore Dispatch LOWPAN_HC1, seguito dal campo "HC1 encoding" dell'intestazione LOWPAN_HC1 (8 bit), che codifica le diverse combinazioni mostrate sotto.

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | HC1 encoding  |     Non-Compressed fields follow...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 9: LOWPAN_HC1 (codifica comune dell'intestazione compressa)

I campi indirizzo codificati da "HC1 encoding" sono interpretati così:

• PI: Prefix carried in-line
• PC: Prefix compressed, assume il prefisso link-local
• II: Interface identifier carried in-line
• IC: Interface identifier elided, derivabile dall'indirizzo di livello collegamento corrispondente

Codifica HC1, dai bit 0 a 7:

Indirizzo sorgente IPv6 (bit 0 e 1):

• 00: PI, II
• 01: PI, IC
• 10: PC, II
• 11: PC, IC

Indirizzo destinazione IPv6 (bit 2 e 3):

• 00: PI, II
• 01: PI, IC
• 10: PC, II
• 11: PC, IC

Traffic Class e Flow Label (bit 4):

• 0: non compressi; invia gli 8 bit completi di Traffic Class e i 20 bit di Flow Label
• 1: Traffic Class e Flow Label sono zero

Next Header (bit 5 e 6):

• 00: non compresso; invia gli 8 bit completi
• 01: UDP
• 10: ICMP
• 11: TCP

Codifica HC2 (bit 7):

• 0: non seguono altri bit di compressione delle intestazioni
• 1: la codifica HC1 è immediatamente seguita da ulteriori bit di compressione secondo il formato HC2. I bit 5 e 6 determinano quale possibile codifica HC2 si applica, ad esempio UDP, ICMP o TCP.

10.2. Encoding of UDP Header Fields (Codifica dei campi dell'intestazione UDP)

I bit 5 e 6 di LOWPAN_HC1 consentono di comprimere il campo Next Header dell'intestazione IPv6 per UDP, TCP e ICMP. È anche possibile comprimere ulteriormente ciascuna di queste intestazioni di protocollo. Questa sezione spiega come comprimere l'intestazione UDP. La codifica HC2 in questa sezione è la codifica HC_UDP, applicabile solo quando i bit 5 e 6 in HC1 indicano che il protocollo successivo all'intestazione IPv6 è UDP.

La codifica HC_UDP consente la compressione dei seguenti campi dell'intestazione UDP: Source Port, Destination Port e Length. Il campo Checksum dell'intestazione UDP non è compresso e viene quindi trasportato per intero. Lo schema definito sotto consente di comprimere l'intestazione UDP a 4 ottetti invece degli 8 originali.

L'unico campo dell'intestazione UDP il cui valore può essere dedotto da informazioni disponibili altrove è Length. Gli altri campi devono essere trasportati in-line per intero o in forma parzialmente compressa (Sezione 10.3.2).

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |HC_UDP encoding|     Fields carried in-line follow...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figura 10: HC_UDP (codifica comune dell'intestazione UDP compressa)

"HC_UDP encoding" per UDP, dai bit 0 a 7:

UDP Source Port (bit 0):

• 0: non compresso, trasportato in-line
• 1: compresso a 4 bit. La porta sorgente effettiva a 16 bit è ottenuta come P + valore short_port. Il valore di P è 61616 (0xF0B0). short_port è rappresentato come valore a 4 bit, trasportato in-line

UDP Destination Port (bit 1):

• 0: non compresso, trasportato in-line
• 1: compresso a 4 bit. La porta destinazione effettiva a 16 bit è ottenuta come P + valore short_port. Il valore di P è 61616 (0xF0B0). short_port è rappresentato come valore a 4 bit, trasportato in-line

Length (bit 2):

• 0: non compresso, trasportato in-line
• 1: compresso; la lunghezza è calcolata dalle informazioni di lunghezza dell'intestazione IPv6. Il valore del campo UDP Length è pari al Payload Length dell'intestazione IPv6, meno la lunghezza di eventuali intestazioni di estensione presenti tra l'intestazione IPv6 e l'intestazione UDP

Riservati (bit 3-7)

10.3. Non-Compressed Fields (Campi non compressi)

10.3.1. Non-Compressed IPv6 Fields (Campi IPv6 non compressi)

Questo schema consente di comprimere l'intestazione IPv6 a vari livelli. Pertanto è necessario trasmettere solo i campi non compressi, invece dell'intera intestazione IPv6 standard. L'intestazione successiva, indicata dal campo Next Header nell'intestazione IPv6 originale, segue immediatamente i campi IPv6 non compressi.

Il campo IPv6 non compresso che DEVE sempre essere presente è Hop Limit (8 bit). Questo campo DEVE sempre seguire i campi di codifica, ad esempio il campo "HC1 encoding" mostrato nella Figura 9, eventualmente insieme ad altri campi di codifica futuri. Gli altri campi non compressi DEVONO seguire Hop Limit nell'ordine implicato da "HC1 encoding", esattamente nello stesso ordine mostrato sopra nella Sezione 10.1: prefisso sorgente (64 bit) e/o Interface Identifier (64 bit), prefisso destinazione (64 bit) e/o Interface Identifier (64 bit), Traffic Class (8 bit), Flow Label (20 bit) e Next Header (8 bit). L'effettiva intestazione successiva, ad esempio UDP, TCP o ICMP, segue i campi non compressi.

10.3.2. Non-Compressed and Partially Compressed UDP Fields (Campi UDP non compressi e parzialmente compressi)

Questo schema consente di comprimere l'intestazione UDP a vari livelli. Pertanto è necessario trasmettere solo i campi non compressi o parzialmente compressi, invece dell'intera intestazione UDP standard.

I campi non compressi o parzialmente compressi dell'intestazione UDP DEVONO sempre seguire l'intestazione IPv6 e tutti i relativi campi in-line. Qualsiasi campo in-line UDP presente DEVE apparire nello stesso ordine dei campi corrispondenti nella normale intestazione UDP [RFC0768], cioè Source Port, Destination Port, Length e Checksum. Se Source Port o Destination Port usa la rappresentazione "short_port", come mostrato nell'intestazione UDP compressa, il numero di porta in-line occupa 4 bit invece di 16.

---