Hi, Jonathan,
I think I now understand. My understanding is as if the cases 2 and 3 were
written in the following way:
2. Datagrams, which can be forwarded within the same RPL Instance as in
the RPL Option contained in outer-most IPv6 header inside the
datagrams, are forwarded to the correct interface.
3. Datagrams, which cannot be forwarded within the same RPL Instance
as in the RPL option contained in the outer-most IPv6 header inside
the datagrams, are dropped.
4. Datagrams, which does not contain a RPL option in the outer-most IPv6
Header inside the datagrams, can be either forwarded to available
network or dropped if the next hop cannot be determined.
RPL router may encapsulate the datagrams using IPv6-in-IPv6 tunneling
when forwarding them, adding RPL Option to the newly added outer
IPv6 header.
Note that, if a datagram, which does not contain a RPL option, was
delivered to the RPL router using IPv6-in-IPv6 tunneling, and the
outer IPv6 header contained a RPL option, and the recipient RPL
router decides to forward the datagram using the same RPL Instance
as in the processed RPL option, the RPL router encapsulates the
packet again and include the same RPL Option following the
requirements mentioned above in this section.
Is my understanding correct?
Thank you.
BR,
Kundok
> -----Original Message-----
> From: Jonathan Hui [mailto:jon...@cisco.com]
> Sent: Friday, December 16, 2011 3:49 PM
> To: Park, Kundok
> Cc: ipv6@ietf.org
> Subject: Re: I-D Action: draft-ietf-6man-rpl-option-06.txt
>
>
> Hi Kundok,
>
> As the processing rules state, Case 1 only occurs when the RPL router is
> the tunnel exit-point. Case 2 and 3 occur only when the RPL router is
> *not* the tunnel exit-point and is an intermediate hop of a tunnel.
>
> Take the following example of nested tunnels:
>
> | TunnelA | TunnelB | Datagram |
>
> If the RPL router is the exit-point for TunnelA, the RPL router will first
> apply Case 1, decapsulate the packet by removing the TunnelA header, and
> resubmit the datagram for further processing.
>
> The RPL router then applies the processing rules again to the resubmitted
> datagram. In this case, the outer-most header now refers to TunnelB. If
> the RPL router is not the exit-point for TunnelB, it applies either Case 2
> or 3.
>
> This is typically how nested tunnels are handled in IPv6.
>
> --
> Jonathan Hui
>
> On Dec 16, 2011, at 3:21 PM, Park, Kundok wrote:
>
> > Hi, Jonathan,
> >
> > Thanks for your quick reply.
> >
> > Unfortunately I am still a bit confused.
> >
> > Based on your reply, I guess that the case 1 is meant only for the case
> of tunnel exit-point being the final RPL router along a path, when the
> tunnel is used.
> >
> > The same RPL instance mentioned in case 2 perhaps means the RPL instance
> in the outer header when a tunnel is used and when the RPL router is not
> the final RPL router along a path, and does the case 2 also apply to a
> case where RPL router is the final RPL router along a path?
> >
> > Does the case 3 only apply to the RPL router being the final RPL router
> along a path when tunnel is used but not to the RPL router not being the
> final router along a path? If the answer is yes, by the outer-most IPv6
> header, did you mean the outer-most IPv6 header of the inner packet and
> does RPL Instance in this context mean any RPL instance that the RPL
> router joined?
> >
> > I'd appreciate if you can clarify furthermore.
> >
> > BR,
> > Kundok
> >
> >> -----Original Message-----
> >> From: Jonathan Hui [mailto:jon...@cisco.com]
> >> Sent: Friday, December 16, 2011 2:00 PM
> >> To: Park, Kundok
> >> Cc: ipv6@ietf.org
> >> Subject: Re: I-D Action: draft-ietf-6man-rpl-option-06.txt
> >>
> >>
> >> Hi Kundok,
> >>
> >> If the RPL router is serves as the tunnel-exit, it falls into case 1
> and
> >> removes the outer-most header in the usual way. If the IPv6 header
> after
> >> decapsulation includes another RPL Option, the router uses the RPL
> >> Instance of that RPL Option and evaluates the forwarding rules again
> (this
> >> time applying case 2 or 3). RPL can support a hierarchy of RPL routing
> >> topologies.
> >>
> >> Does that help?
> >>
> >> --
> >> Jonathan Hui
> >>
> >> On Dec 16, 2011, at 8:55 AM, Park, Kundok wrote:
> >>
> >>> Hi, Jonathan,
> >>>
> >>> I have a question on the following text on version 6, on page 8.
> >>>
> >>> "
> >>> 2. Datagrams destined elsewhere within the same RPL Instance are
> >>> forwarded to the correct interface.
> >>>
> >>> 3. Datagrams destined to nodes outside the RPL Instance are dropped
> >>> if the outer-most IPv6 header contains a RPL Option not generated
> >>> by the RPL router forwarding the datagram.
> >>> "
> >>>
> >>> Can you clarify the meaning of the (same) RPL instance in the above
> >> text? Is it the RPL instance in the outer-most IPv6 header? For
> instance,
> >> if a RPL packet is tunneled to a RPL router using another RPL instance
> and
> >> the recipient RPL router is the exit point of the outer tunnel, must
> the
> >> router discard such a packet whether the router joined the RPL instance
> of
> >> the inner packet or not?
> >>> To phrase it differently, can RPL be used in a virtual network over a
> >> network which happens to use another RPL instance as an underlying
> routing
> >> protocol?
> >>>
> >>> Thank you.
> >>>
> >>> BR,
> >>> Kundok Park
> >>> Texas Instruments
> >>> --------------------------------------------------------------------
> >>> 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
--------------------------------------------------------------------
