Hi Vishwas,
If we go down the route of specifying a RH4_MIN_MTU, I'm not so sure
we want to send the ICMP message to any place other than the source.
Destination unreachable messages should go to the source. Packet too
big messages should also go back to the source (after the RPL edge
router does its magic to remove any side effects of RH4 headers).
Sending the ICMP message back to the source would maintain the same
prevalent behavior within IP today.
--
Jonathan Hui
On Jun 3, 2010, at 10:40 PM, Vishwas Manral wrote:
Hi JP,
The approach is good, we however still need to solve the ICMP message
being sent to the source not the edge of the RPL network.
We can probably use the addr[0] approach which was discussed earlier.
Thanks,
Vishwas
On Thu, Jun 3, 2010 at 10:35 PM, JP Vasseur <[email protected]> wrote:
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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
