Subject: Re: [6lowpan] [Roll] [ipdir] IP Directorate review of draft-ietf-roll-rpl-12

From: Carsten Bormann <[email-masked]>
Date: Sun, 24 Oct 2010 08:30:59 +0200

On Oct 21, 2010, at 16:48, Margaret Wasserman wrote:
[in her RPL review about RPL's various forms of encapsulation:]

> (1) 6lowpan,
>            which is the only link type I know of that RPL has been
>            run over to date, has an MTU of 1280, not 1280+++ as
>            required by the 6lowpan spec,

(I think you meant 6man/RPL spec at the end.)

Indeed.

However, the number 1280 is somewhat arbitrary for 6LoWPAN, as we have to piece L3 packets together out of ~100 byte L2 fragments anyway.  The actual adaptation layer format is fine with any MTU up to 2047; we just chose the lowest MTU possible*) in IPv6 as a concession for constrained nodes (and 1280 still is quite heavy for some of them).

So it is not unconceivable that 6LoWPAN could help RPL routers by adding a mode that extends the MTU somewhat.
Of course, the details of such an extension would need to be defined, preferably in conjunction with the rest of the 6man/RPL stack.

Gruesse, Carsten

*) The assumption was that, as a stub network, a 6LoWPAN would not need to support tunneling.
That assumption may have been wrong.

---

From: Margaret Wasserman <[email-masked]>
Date: Sun, 24 Oct 2010 22:01:09 -0400

> (I think you meant 6man/RPL spec at the end.)

Yes, I did.  The 6man/RPL spec says it will only work on networks that  
have an MTO of 1280+40-something+128+something unspecified.  And,  
6lowpan currently specifies an MTU of 1280 (which is fine).

> However, the number 1280 is somewhat arbitrary for 6LoWPAN, as we  
> have to piece L3 packets together out of ~100 byte L2 fragments  
> anyway.  The actual adaptation layer format is fine with any MTU up  
> to 2047; we just chose the lowest MTU possible*) in IPv6 as a  
> concession for constrained nodes (and 1280 still is quite heavy for  
> some of them).

Even if the number _were_ 2047, you would still need to do something  
special with the MTU to make this work.  For instance the tunnel  
encapsulator (in this case the border router) would want to present a  
lower MTU (presumably 1280) for this network on interfaces outside the  
RPL instance, while presenting the full size MTU on internal  
interfaces.  This isn't a huge technical problem to resolve, but the  
expected behaviour would need to be properly specified, IMO.

> So it is not unconceivable that 6LoWPAN could help RPL routers by  
> adding a mode that extends the MTU somewhat.
> Of course, the details of such an extension would need to be  
> defined, preferably in conjunction with the rest of the 6man/RPL  
> stack.

Exactly.

Thanks for the feedback!
Margaret