Atmel AVR2070 User Manual

 

8240B-AVR-06/09 

 

A message will be properly parsed by end-nodes regardless if traffic class and flow 
label is compressed or uncompressed. However the value itself is not read, hence to 
avoid wasting space all messages should have the traffic class and flow label set to 
zero. 

The code supports carrying all 128 bytes; or compressing an address down to 64, 16, 
or 0 bytes of extra payload. 

Only a UDP packet will have the next header field compressed, any other type will 
have the next header field carried in full. 

A hop limit of 255, 64, or 1 will result in the hop limit being compressed. Any other 
value will result in the hop limit field being carried in full. 

UDP Header compression is supported by this implementation. 

If sniffing a 6LoWPAN network, it can be useful to understand the header. Note that 
the 802.15.4 payload will be the RUM frame, which includes some additional fields. 
The 6LoWPAN header described here is actually the RUM payload. Table C-6-1 
illustrates this relationship. 

Table C-6-1 Understanding the relationship between 6LoWPAN, RUM, and 802.15.4 Frames. 

Frame 

 

The 6LoWPAN Frame contains three bytes of interest at the beginning. The first is the 
‘dispatch’ which is always set to 0x03, which corresponds to the header compression 
used. The HC01 Encoding is specified in two bytes, and a detailed description of this 
field is given at 

http://tools.ietf.org/html/draft-ietf-6lowpan-hc-01

 in section C.5.1. 

Additionally the source code for the avr_sixlowpan.c file in the 
sixlowpan_hc01_process() function provides a reference for decoding the 
compressed 6LoWPAN header. 

Table C-6-2 6LoWPAN Frame