Thanks again for the feed-back. Does the WG support this approach ?
Thanks.
JP.
On Jun 4, 2010, at 6:30 AM, Jonathan Hui wrote:
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
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------