Subject: [Roll] closing Ticket #64

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 24 Jul 2010 10:46:50 +0200

Dear WG:

Long discussions lead to specify only the location of the RPLinstanceID inside the RPL network, leaving it to policies the way the ingress router figures it out. The RPLinstanceID will be placed in the RPL option which is probably the cleanest and most generic thing we can do. Other drafts are allowed to come later and provide alternate forwarding rules eventually placing the content of the RPL option validation somewhere else, for instance in order to avoid IPinIP. A forwarding mode will probably indicate what the network does.

Proposed changes:

RPL uses  a hop-by-hop IPv6 header to detect possible loops within a

DODAG. 

->

             RPL carries routing information in a RPL Option contained in an  IPv6                        

                Hop-by-Hop Option as specified in [I-D.hui-6man-rpl-option]. Such                                          

                routing information are used for example for loop detection within a                                     

                DODAG as discussed in Section 11.2 and may be extended in future                                        

                documents for additional features.                                         

For data packets, the RPLInstanceID may be indicated in the flow

label by the source of the packet. If it is not, then it is inferred

and added by the RPL network ingress router in the RPL Hop-by-hop

option ([I-D.hui-6man-rpl-option]) as further described in

Section 10.2

è  

             Data packet that flow within the RP network expose the RPLInstanceID                     

                in the RPL option that is specified in [I-D.hui-6man-rpl-option], and                                         

                further described in Section 11.2. For data packets coming from                                                

                outside the RPL network, the RPLInstanceID is determined by the RPL                                   

                network ingress router and placed in the RPL option that is added to                                      

                the packet.

RPL loop detection uses information that is placed into the packet.          

A future version of this specification will detail how this

information is carried with the packet (e.g. a hop-by-hop option

([I-D.hui-6man-rpl-option]) or summarized somehow into the flow

label). For the purpose of RPL operations, the information carried

with a packet is constructed follows:

è  

            RPL loop detection uses information that contained within the data                                           

            packet using the RPL Option [I-D.hui-6man-rpl-option]) in an IPv6                                                

                Hop-by-Hop Option header. The RPL Option is a generic container for                                    

                a list of TLVs. This specification defines a new RPL Option type,                                  

                called the RPL Loop Detection. The RPL Loop Detection TLV is placed                                       

                in the RPL Option with Option Type = 1 (to be confirmed by IANA),                                          

                Option Data Length = 4 octets, and the Value has the following                                  

                format:                 

The RPLInstanceID is associated by the source with the packet. This

RPLInstanceID MUST match the RPL Instance onto which the packet is

placed by any node, be it a host or router. For traffic originating                

outside of the RPL domain there may be a mapping occurring at the        

gateway into the RPL domain, possibly based on an encoding within the

flow label. This aspect of RPL operation is to be clarified in a

future version of this specification.

The source of the packet might be aware of the RPL network, of the

constraints imposed on OFs, and of associated Instance IDs. In that

case, the source of the packet MAY tag the flow label with the

RPLInstanceID, in which case it is used in that form within the RPL

network.

A router that injects a data packet into the RPL network MUST tag the

packet by inserting a RPL Hop-by-hop option as specified in

[I-D.hui-6man-rpl-option]. If the RPLInstanceID is not present in

flow label of the data packet, the ingress router that injects the                

packet into the RPL network MUST add a RPLInstanceID field to the RPL                

Hop-by-hop option.        

è  

             The RPLInstanceID is associated by the source with the packet. This                                          

                RPLInstanceID MUST match the RPL Instance onto which the packet is                                   

                placed by any node, be it a host or router.           

                For a packet that is originated from outside the RPL network, the                                             

                source of the packet might be aware of the RPL network, of the                                               

                constraints imposed on OFs, and of associated RPLInstanceIDs. In                                            

                that case, the source of the packet MAY tag the flow label with the                                         

                RPLInstanceID.                                  

                A RPL router that forwards a packet in the RPL network MUST check if                                   

                the packet includes the RPL Loop Detection TLV in a RPL Option within                                   

                the IPv6 Hop-by-Hop Option header. If one does not exist, the RPL                                         

                router MUST insert a RPL Loop Detection type as specified in                                      

                [I-D.hui-6man-rpl-option]. If the router is an ingress router that                                                

                injects the packet into the RPL network, the router MUST set the                                            

                RPLInstanceID field in the RPL Loop Detection TLV.                          

As usual, please speak up if there's an issue with the proposed resolution!

Pascal

From: JP Vasseur [mailto:[email-masked]] 
Sent: Saturday, July 24, 2010 12:02 AM
To: Pascal Thubert (pthubert)
Subject: Re: Ticket #64 and Summary of our discussion today

could you please provide the final text then ?

Thanks Pascal.

On Jul 23, 2010, at 4:13 PM, Pascal Thubert (pthubert) wrote:

Hi JP;

I did the same in parallel; I changed very little as below. Please review; I'm resending the ready to forward mail to this list...

Pascal

From: JP Vasseur [mailto:[email-masked]] 
Sent: Friday, July 23, 2010 1:46 PM
To: Tim Winter; Pascal Thubert (pthubert); Jonathan Hui; [email-masked]
Subject: Re: Ticket #64 and Summary of our discussion today

OK here is the new text to close Ticket #64 - 

I combined the text from Pascal, Jonathan + my suggestions.

All please let us know today is you agree, then I will close that ticket.

Text to include in ticket #64 for closing

###############################

Please find below the various changes to close ticket #64

 The definition and provisioning of RPL instances are beyond the scope

 of this specification.  Those operations are expected to be such that

 data packets coming from the outside of the RPL network can

 unambiguously be associated to at least one RPL instance, and be

 safely routed over any instance that would match the packet.

 Information used to match a packet to a RPL instance can typically be

 taken from fields in the IPv6 header, like the flow label,

 differentiated services (DS) field, or destination address.

 Control and data packets within RPL network are tagged to

 unambiguously identify what RPL Instance they are part of.

 Every RPL control message has a RPLInstanceID field.  Some RPL

 control messages, when referring to a local RPLInstanceID as defined

 below, may also include a DODAGID.

 Data packets that flow within the RPL domain expose the

 RPLInstanceID in the RPL Hop-by-hop option that is specified in

 [I-D.ietf-6man-rpl-option],and further described in Section 11.2.

 For data packets coming from outside the RPL network, the

 RPLInstanceID is determined by the RPL network ingress router

 and placed in a RPL Hop-by-hop option that is added to the

 packet."

[Pascal] removed hop-by-hop per Jonathan's point

      <t>Data packet that flow within the RP network expose the

              RPLInstanceID in the RPL option that is specified in

              <xref target="I-D.hui-6man-rpl-option"></xref>,

              and further described in <xref target="loopdetect"></xref>.

              For data packets coming from outside the RPL network, the RPLInstanceID

              is determined by the RPL network ingress router and placed in the RPL

                option that is added to the packet.

"

   Data packet that flow within the RP network expose the RPLInstanceID

   in the RPL option that is specified in [I-D.hui-6man-rpl-option], and

   further described in Section 11.2.  For data packets coming from

   outside the RPL network, the RPLInstanceID is determined by the RPL

   network ingress router and placed in the RPL option that is added to

   the packet.

"

Then ...

3.3.7.  Datapath Validation and Loop Detection

 RPL uses a hop-by-hop IPv6 header to detect possible loops within a DODAG.

-->

RPL carried routing information in a RPL Option contained in an IPv6

Hop-by-Hop Option as specified in [I-D.ietf-6man-rpl-routing-header].
Such routing information are used for example for loop detection within
a DODAG as discussed in Section 10.2 and subject to additional information
defined in future document.

[Pascal] carried -> carries

[Pascal] and subject to additional information defined in future document.

->

and may be extended in future  documents for additional features.

5.  RPL Instance

 and added by the RPL network ingress router in the RPL Hop-by-hop option

--> and added by the RPL network ingress router in the RPL Option

[Pascal] This is actually the first change in the mail above. Do I miss something like a dup?

8.2.2.5.  Poisoning

 whose hop-by-hop option ([I-D.hui-6man-rpl-option]) includes a Rank

-->

 whose RPL Option ([I-D.hui-6man-rpl-option]) includes a Rank

[Pascal] done

11.2.  Loop Avoidance and Detection

 RPL loop detection uses information that is placed into the packet.

 A future version of this specification will detail how this

 information is carried with the packet (e.g. a hop-by-hop option

 ([I-D.hui-6man-rpl-option]) or summarized somehow into the flow

 label).  For the purpose of RPL operations, the information carried

 with a packet is constructed follows:

-->

 RPL loop detection uses information that contained within the data

 packet using the RPL Option [I-D.hui-6man-rpl-option] in an IPv6

 Hop-by-Hop Option header.  The RPL Option is a generic container for

 a list of TLVs.  This specification defines a new RPL Option type,

 called the RPL Loop Detection.  The RPL loop Detection TLV has the 

following format, with type=1 (to be confirmed by IANA).

HERE INSET THE FORMAT

[Pascal] as is

11.2.2.1.  Instance Forwarding

A router that injects a data packet into the RPL network MUST insert a RPL

Hop-by-hop option as specified in [I-D.ietf-6man-rpl-option].

If the RPLInstanceID is not present in flow label of the data packet, the ingress 

router that injects the packet into the RPL network MUST add a RPLInstanceID 

field to the RPL Hop-by-hop option.

-->

A RPL router that forwards a packet in the RPL domain MUST check if

 the packet includes the RPL Loop Detection TLV in a RPL Option with

 the IPv6 Hop-by-Hop Option header.  If one does not exist, the RPL router

 MUST insert a RPL Loop Detection type as specified in [I-D.ietf-6man-rpl-option].

 A router that forwards a packet to outside the RPL network MUST

 remove the RPL Hop-by-hop option.

-->

 A router that forwards a packet to outside the RPL domain MUST

 remove the RPL Option as specified in [I-D.ietf-6man-rpl-option].

[Pascal] as is.

---

From: JP Vasseur <[email-masked]>
Date: Sat, 24 Jul 2010 12:19:17 +0200

Great text, which I think address the ticket - minor comments below.

On Jul 24, 2010, at 10:46 AM, Pascal Thubert (pthubert) wrote:

> Dear WG:
>
> Long discussions lead to specify only the location of the  
> RPLinstanceID inside the RPL network, leaving it to policies the way  
> the ingress router figures it out. The RPLinstanceID will be placed  
> in the RPL option which is probably the cleanest and most generic  
> thing we can do. Other drafts are allowed to come later and provide  
> alternate forwarding rules eventually placing the content of the RPL  
> option validation somewhere else, for instance in order to avoid  
> IPinIP. A forwarding mode will probably indicate what the network  
> does.
>
> Proposed changes:
>

+ add:

> As usual, please speak up if there’s an issue with the proposed  
> resolution!
>
> Pascal
>
> I did the same in parallel; I changed very little as below. Please  
> review; I’m resending the ready to forward mail to this list…
>
> Pascal
>
> [Pascal] removed hop-by-hop per Jonathan’s point
> “
> “
> option
> router