1. Introduzione
1. Introduzione
Lo standard [IEEE802.15.4] specifica una MTU di 127 byte, che produce circa 80 ottetti di carico utile effettivo Media Access Control (MAC) con la sicurezza abilitata, su un collegamento wireless con un throughput di collegamento di 250 kbps o inferiore. Il formato di adattamento 6LoWPAN [RFC4944] è stato specificato per trasportare datagrammi IPv6 su tali collegamenti vincolati, tenendo conto delle risorse limitate di larghezza di banda, memoria o energia che ci si aspetta in applicazioni come le reti di sensori wireless. [RFC4944] definisce un'intestazione Mesh Addressing per supportare l'inoltro sub-IP, un'intestazione di frammentazione per supportare il requisito di MTU minima IPv6 [RFC2460] e la compressione stateless dell'intestazione per i datagrammi IPv6 (LOWPAN_HC1 e LOWPAN_HC2) per ridurre le intestazioni IPv6 e UDP relativamente grandi a (nel migliore dei casi) pochi byte.
LOWPAN_HC1 e LOWPAN_HC2 sono insufficienti per la maggior parte degli usi pratici di IPv6 nelle 6LoWPAN. LOWPAN_HC1 è più efficace per la comunicazione unicast link-local, dove gli indirizzi IPv6 portano il prefisso link-local e un Interface Identifier (IID) derivato direttamente dagli indirizzi IEEE 802.15.4. In questo caso, entrambi gli indirizzi possono essere completamente omessi. Tuttavia, sebbene gli indirizzi link-local siano spesso utilizzati per interazioni di protocollo locali come IPv6 Neighbor Discovery [RFC4861], DHCPv6 [RFC3315] o protocolli di routing, di solito non vengono utilizzati per il traffico a livello applicativo, quindi il valore reale di questo meccanismo di compressione è limitato.
Gli indirizzi instradabili devono essere utilizzati quando si comunica con dispositivi esterni alla 6LoWPAN o in una configurazione route-over in cui l'inoltro IP avviene all'interno della 6LoWPAN. Per gli indirizzi instradabili, LOWPAN_HC1 richiede che entrambi gli indirizzi sorgente e destinazione IPv6 portino il prefisso inline (in linea). Nei casi in cui l'intestazione Mesh Addressing non viene utilizzata, l'IID di un indirizzo instradabile deve essere trasportato inline. Tuttavia, LOWPAN_HC1 richiede 64 bit per l'IID quando trasportato inline e non può essere ridotto, anche se derivato dall'indirizzo breve IEEE 802.15.4 a 16 bit. Quando la destinazione è un indirizzo multicast IPv6, LOWPAN_HC1 richiede che l'intero indirizzo a 128 bit sia trasportato inline.
Di conseguenza, questo documento definisce un formato di codifica, LOWPAN_IPHC, per una compressione efficace degli indirizzi IPv6 Unique Local, Global e Multicast basata su uno stato condiviso all'interno dei contesti. Inoltre, questo documento introduce anche una serie di miglioramenti aggiuntivi rispetto al formato di compressione dell'intestazione definito in [RFC4944].
LOWPAN_IPHC consente la compressione di alcuni valori IPv6 Hop Limit comunemente utilizzati. Se la 6LoWPAN è una mesh-under stub, un Hop Limit di 1 per il traffico in entrata e un valore predefinito come 64 per il traffico in uscita sono solitamente sufficienti per il traffico a livello applicativo. Inoltre, un valore di Hop Limit di 255 viene spesso utilizzato per verificare che una comunicazione avvenga su un singolo hop. Questa specifica consente la compressione del campo IPv6 Hop Limit in questi casi comuni, mentre LOWPAN_HC1 non lo fa.
Questo documento definisce anche LOWPAN_NHC, un formato di codifica per Next Header arbitrari. LOWPAN_IPHC indica se l'intestazione successiva è codificata utilizzando LOWPAN_NHC. In tal caso, i bit immediatamente successivi all'intestazione IPv6 compressa iniziano la codifica LOWPAN_NHC. Al contrario, LOWPAN_HC1 potrebbe essere esteso per supportare la compressione delle intestazioni successive utilizzando LOWPAN_HC2, ma solo per UDP, TCP e ICMPv6. Inoltre, l'ottetto LOWPAN_HC2 si trova tra l'ottetto LOWPAN_HC1 e i campi dell'intestazione IPv6 non compressi. Questa specifica sposta i bit di codifica Next Header in modo che seguano tutti i bit relativi a IPv6, consentendo una struttura correttamente stratificata e il supporto diretto per le intestazioni di estensione IPv6.
Utilizzando LOWPAN_NHC, questo documento definisce un meccanismo di compressione per UDP. Mentre [RFC4944] definisce un meccanismo di compressione per UDP, tale meccanismo non consente la compressione del checksum quando ciò è reso possibile da meccanismi aggiuntivi del livello superiore come Upper-Layer Message Integrity Check (MIC). Questa specifica aggiunge la capacità di omettere il checksum UDP sulla 6LoWPAN, consentendo di risparmiare altri due ottetti.
Inoltre, utilizzando LOWPAN_NHC, questo documento definisce formati di codifica per l'incapsulamento IPv6-in-IPv6, nonché per le intestazioni di estensione IPv6. Con LOWPAN_HC1 e LOWPAN_HC2, le catene di Next Header non possono essere codificate in modo efficiente.
1.1 Linguaggio dei requisiti
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in RFC 2119 [RFC2119].