7

I've been reading about the 6LoWPAN protocol (which is used by Thread, among other network protocols), and it seems to be highly useful for networking, and has the advantage of allowing each device to easily be addressable.

Wikipedia says that 6LoWPAN uses a form of header compression to reduce transmission size (hence saving time and energy):

The target for IP networking for low-power radio communication is applications that need wireless internet connectivity at lower data rates for devices with very limited form factor. An example is automation and entertainment applications in home, office and factory environments. The header compression mechanisms standardized in RFC6282 can be used to provide header compression of IPv6 packets over such networks.

It refers to RFC 6282 as the compression format used. The abstract is rather brief in how it works:

The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope.

As far as I can tell, 'shared context' is used to elide some header fields and save space. How, exactly, is this 'shared context' managed, and why doesn't every IPv6 device (e.g. my computer) use this compression?

Community
  • 1
Aurora0001
  • 18,520
  • 13
  • 55
  • 169

1 Answers1

4

The RFC draft explains a bit better how the header compression works. What is described as arbitrary prefixes in the abstract is essentially a bunch of information that is assumed to be in a certain range or having a specific value. Thus, making transmitting those information unnecessary.

To enable effective compression LOWPAN_IPHC relies on information pertaining to the entire 6LoWPAN.

This assumption goes for the entire 6LoWPAN, breaking down the next sentence we have six information that are assumed to be known or in a considerably smaller range of values.

  • Version is 6;
  • Traffic Class and Flow Label are both zero;
  • Payload Length can be inferred from lower layers from either the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header;
  • Hop Limit will be set to a well-known value by the source;
  • addresses assigned to 6LoWPAN interfaces will be formed using the link-local prefix or a small set of routable prefixes assigned to the entire 6LoWPAN;
  • addresses assigned to 6LoWPAN interfaces are formed with an IID derived directly from either the 64-bit extended or 16-bit short IEEE 802.15.4 addresses.

(Bullet points by me, otherwise continuing section three of the draft.)

This also explains why this compression is not used by devices like your PC. Your PC has to be able to address the whole world basically. However the compression as described above is only really effective if used in a sufficiently constrained environment—the entire 6LoWPAN—and not the world.

In the best case, the LOWPAN_IPHC can compress the IPv6 header down to two octets (the dispatch octet and the LOWPAN_IPHC encoding) with link-local communication.

(Still same draft section)

As described in the RFC draft the compression gets even better when it's in a more constricted environment. For link local only it's down to two octets. Of course, we want our usual computers and end devices to be able to address everything else instead. However, if we want to be able to change all those values this compression takes as granted it doesn't work anymore. We'd have a mismatch between what we mean and what every other network participant thinks we mean, because the compression takes values for granted.

Thus, the compression severely limits the vast possibilities of IPv6 to reach smaller headers and gain efficiency in time and energy in a very well defined small environment.

Community
  • 1
Helmar
  • 8,450
  • 6
  • 36
  • 84