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 protected] [mailto:[email protected]] On Behalf Of Anders Brandt Sent: mercredi 27 janvier 2010 13:26 To: [email protected]; [email protected] 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 protected] [mailto:[email protected]] On Behalf Of Daniel Gavelle Sent: Tuesday, January 26, 2010 18:29 To: [email protected] 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 protected] https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
