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 On Dec 16, 2011, at 4:56 PM, Park, Kundok wrote: > 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 --------------------------------------------------------------------
