Subject: I-D Action: draft-ietf-6man-rpl-option-06.txt

From: [email-masked]
Date: Wed, 14 Dec 2011 07:34:27 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

	Title           : RPL Option for Carrying RPL Information in Data-Plane Datagrams
	Author(s)       : Jonathan W. Hui
                          JP Vasseur
	Filename        : draft-ietf-6man-rpl-option-06.txt
	Pages           : 14
	Date            : 2011-12-14

   The RPL protocol includes routing information in data-plane datagrams
   to quickly identify inconsistencies in the routing topology.  This
   document describes the RPL Option for use among RPL routers to
   include such routing information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-06.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-6man-rpl-option-06.txt

---

From: "Park, Kundok" <[email-masked]>
Date: Fri, 16 Dec 2011 16:55:32 +0000

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

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 16 Dec 2011 14:00:27 -0800

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:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Park, Kundok" <[email-masked]>
Date: Fri, 16 Dec 2011 23:21:25 +0000

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:[email-masked]]
> Sent: Friday, December 16, 2011 2:00 PM
> To: Park, Kundok
> Cc: [email-masked]
> 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
> 
> > 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

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 16 Dec 2011 15:48:31 -0800

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

---

From: "Park, Kundok" <[email-masked]>
Date: Sat, 17 Dec 2011 00:56:34 +0000

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

> Sent: Friday, December 16, 2011 3:49 PM
> To: Park, Kundok
> Cc: [email-masked]
> 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.
> 
> 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.
> 
> > 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?
> >

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 16 Dec 2011 17:52:05 -0800

Hi Kundok,

Your description is correct.  The processing rules in the draft do not apply if the packet does not contain a RPL Option.  If no RPL Option exists, then the RPL router should process the datagram like any other datagram it may receive from a node not running RPL.

--
Jonathan Hui