Many of the low power lossy networks that will form the bulk of the future IoT will rely on IPv6 - a network protocol that will put the Internet in the IoT. However, IPv6 and low-power are often at odds with each other. One technique to make IPv6 a better choice for low-power lossy networks is 6LoWPAN header compression originally published in RFC4944 around 2009.
A standard IPv6 packet transferring a UDP datagram consumes 40 bytes for the IPv6 header and 8 bytes for the UDP header. A lossy and low-power wireless personal area network (LoWPAN) offers a standard over-the-air packet of 127 bytes and formatted according to 802.15.4. Within these 127 bytes must fit:
- 802.15.4 MAC header with security (AES+CCM): 46 bytes.
- 6LoWPAN fragmentation header: up to 5 bytes (4 on first frame).
- IPv6 header: 40 bytes
- UDP header: 8 bytes
- Frame checksum: 2 bytes
The 802.15.4 packet can offer just 127-46-5-40-8-2 = 26 bytes for the payload (actual application data to be transferred over the air), with over 3x header to payload ratio in each packet. Obviously a wasteful setup when considering energy and reliability.
Fortunately, a scheme has been developed to reduce the number of bytes needed for the IPv6 and UDP headers by using knowledge about the network and other information already present in the lower layer (I.e. the 802.15.4 MAC header). This scheme was originally defined in RFC 4944 and called "HC1" for compressing IPv6, and "HC2" for compressing UDP, TCP and ICMPv6 headers. These techniques are also called stateless header compression.
A more recent header compression scheme has been introduced called draft-hui-6lowpan-hc-01 Compression format for IPv6 datagrams in 6lowpan Networks . This standard offers an enhanced compression scheme called "HC", with corresponding components "IPHC" for IPv6 header compression, and "NHC" for arbitrary protocol header compression (e.g. UDP, TCP, etc). This standard is also called stateful header compression with context.
The key takeaways are as follows:
- Maximum compression is obtained for "link-local" unicast addresses only, that is, addresses starting with FE80. These are typically used by mesh maintenance protocols like RPL. These compress to a total of 7 bytes with HC1/HC2 and 6 bytes with HC.
- Link-local multicast messages, also used by mesh maintenance protocols, can compress to a maximum of 23 bytes. These compress to a total of 23 bytes with HC1/HC2 and 7 bytes with HC.
- Global messages, that is, messages routable outside of the LoWPAN mesh, are compressed to 31 bytes with HC1/HC2 and 10 bytes with HC.
- UDP header is compressible only if source and destination ports are within the defined range of [61616, 61631].
- Contiki OS offers support for RFC4944 as well as draft-hui-6lowpan-hc-06.
- When upper layer packets cannot fit into a single 802.15.4 packet, they are fragmented. Only the first fragment contains the compressed IPv6/UDP header.
Additional Notes
Compression is an optimization, and like all optimizations, should be enabled/investigated only after a baseline and a need for such optimization has been established. Most systems will work whether compression is on or off.
A system delivering many small messages will actually benefit from compression more than a system delivering fewer larger messages. Packing data into larger messages that are subsequently fragmented will benefit from compression less because the header is present in just the first message.