Hi Erik,

On Jun 3, 2010, at 2:10 AM, Erik Nordmark wrote:

On 06/ 3/10 01:03 AM, JP Vasseur wrote:

We can use the outlined approach as long as we can require such media to support a MTU for IP packets that is slightly larger than 1280. Thus we'd need a maximum size for the amount the ROLL ingress would add to the packet (RH4 and the HBH), and then require that the ROLL links support at least 1280 plus that max. Essentially a ROLL_MIN_MTU.

That would ensure that the ROLL ingress would never need to fragment a 1280 byte packet. And for packets larger than 1280, the rewriting of the ICMP errors at the ROLL boundary would make path MTU discovery work.

But if we can't mandate such a ROLL_MIN_MTU, then the sensible approach would seem to be to do IP in IP encapsulation at the ROLL ingress.


Thanks for all your thoughts on this subject. The two options are clear.

Of the two choices, I prefer to specify a ROLL_MIN_MTU and avoid IP in IP encapsulation just to support routing. The former approach seems to be less onerous on resource constrained nodes that are expected within a RPL network. It avoids one possible source of IP-layer fragmentation. Of course, as you noted, the edge router must not allow any side effects of RH4 to escape the RPL network, which is really the intended use of RH4 anyway.

It's also important that we include the rpl-option overhead in ROLL_MIN_MTU, so we'll have to specify a maximum for both the rpl- option and rpl-routing-header (as you noted in the Anaheim meeting).

In 6LoWPAN networks, while RFC 4944 indicates a MTU of 1280 bytes, the fragmentation mechanism does support up to 2048 bytes so that is comforting. So far, I'm not aware of any existing links intended for use with RPL that cannot support an MTU that is a bit larger than 1280 bytes.

If people think specifying a ROLL_MIN_MTU is reasonable, we'll submit an update to the rpl-routing-header draft that incorporates these changes and the several other ones brought up over the past week.

--
Jonathan Hui

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to