Subject: Re: [6lowpan] Compressing the extension header

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 1 Feb 2010 10:19:59 +0100

Hi Daniel:

I do agree to. 
Mesh headers do not belong to L3 but routing headers do, so it makes a
lot more sense to discuss the compression of routing headers (RH) than
mesh headers in 6LoWPAN. 
I'm convinced that ROLL will work on compressing DAOs more. JP has
already proposed a BNF to pack information. The record route piece in
the DAO must also be compressed in a fashion that does not depend on
6LoWPAN but that 6LoWPAN HC could certainly take advantage of. 
It makes sense to me to do the RPL compression work first to make sure
we are compatible in the end...
What do you think?

Cheers,

Pascal
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Anders Brandt
Sent: mercredi 27 janvier 2010 13:26
To: [email-masked]; [email-masked]
Subject: Re: [6lowpan] Compressing the extension header

Daniel,

I agree.

This sounds like an obvious extension to the IPHC draft.

It is a fair requirement that all intermediate nodes are
in the same (local) subnet and may thus be compressed to short
addresses.
For sure the Internet or any backbone (?) will not use source routing
anyway.

Cheers,
  Anders

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Daniel Gavelle
Sent: Tuesday, January 26, 2010 18:29
To: [email-masked]
Subject: [6lowpan] Compressing the extension header

When ROLL sends a packet from the DAG root to a node over a 6LowPAN
network, there are two choices:-

(1) Source routing is used, where the DAG root (edge router) is the only
node that knows the route state.  The root node would then use the
"Routing Header" specified in RFC 2460 to specify the route.

(2) Each routing node has a full routing table that knows the route to
all its descendants (grand children, great grand children etc) as well
as its immediate children and parent.

Option (1) has several advantages, including reduced memory requirements
for normal router nodes and avoiding the need to poison routes as the
DAG changes.

However, using source routing requires the full IPv6 address of each
segment to be carried in the extension header. This will reduce the
effectiveness of the very good work that has been done in
draft-ietf-6lowpan-hc-06 to reduce the size of the IPv6 header.

Adding context based compression of the addresses in a routing header
would result in a much smaller header.  All the addresses will have at
least the same /64 prefix and if short addresses were used, only 16 bits
would need to be stored for each address.

Daniel.

--
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371
Registered In England http://www.jennic.com
__________________________________________________
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Daniel Gavelle <[email-masked]>
Date: Tue, 02 Feb 2010 08:53:35 +0000

If source routing is used, the route will be stored in every header, not 
just the ROLL ICMP messages.  Therefore this compression will need to go 
in the 6LowPAN HC rather than ROLL.  Compression of source route 
addresses in the extension header would be beneficial when any source 
routing were used, not just ROLL.

Compressing the addresses in ROLL DAO messages would also be useful.  In 
most LowPAN's, the first 64 bits of the sub-net is likely to be the same 
for every node in the network.  Even more bits will be common if 16 bit 
addresses are used.  Context based compression would be a very good way 
to compress these addresses.

Using the same address compression algorithm in ROLL and 6LowPAN-HC 
would reduce code size and ease implementation on what is likely to be a 
common class of nodes that run both ROLL and 6LowPAN-HC.

Daniel.

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________