Subject: [Roll] [roll] #64: RPL Instance ID in flow label or RPL option

From: "roll issue tracker" <[email-masked]>
Date: Thu, 15 Jul 2010 08:21:33 -0000

#64: RPL Instance ID in flow label or RPL option
-----------------------------+----------------------------------------------
 Reporter:  jpv@…            |       Owner:  pthubert@…        
     Type:  enhancement      |      Status:  new               
 Priority:  major            |   Milestone:                    
Component:  rpl              |     Version:                    
 Severity:  In WG Last Call  |    Keywords:                    
-----------------------------+----------------------------------------------
 Email from JP:

 Section 4 says:

 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
 We need to choose ... if the packet is originated from outside of the RPL
 domain it has to be in the flow
 label unless the BR makes the selection. We should clarify this and
 indicate when carried in the flow label
 and when carried in the RPL option. Suggest to be consistent and put in
 flow label.

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/64>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Sat, 24 Jul 2010 15:09:41 -0000

#64: RPL Instance ID in flow label or RPL option
-----------------------------+----------------------------------------------
 Reporter:  jpv@…            |        Owner:  pthubert@…        
     Type:  enhancement      |       Status:  closed            
 Priority:  major            |    Milestone:                    
Component:  rpl              |      Version:                    
 Severity:  In WG Last Call  |   Resolution:  fixed             
 Keywords:                   |  
-----------------------------+----------------------------------------------
Changes (by jpv@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Email from JP July 24 Following an email from Pascal.

 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:

 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.

 è

              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.

 JP> + add:

 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].

 As usual, please speak up if theres an issue with the proposed
 resolution!

 Pascal

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/64#comment:1>
roll <http://tools.ietf.org/wg/roll/>

---

From: Dario Tedeschi <[email-masked]>
Date: Tue, 27 Jul 2010 17:05:58 -0700

If the flow label is used by a source to identify a RPL Instance how 
would the same source use the flow label for other flows not related to 
RPL. Put another way, if an application (or a transport like TCP) wanted 
to identify a new data flow, how would the ingress router know that the 
label was identifying the new flow and not the RPL Instance.

Reading RFC 3697, it would appear that the flow label is used in 
identifying the end-to-end flow, not for identify a route.

 From Section 2 in RFC 3697:

   The Flow Label value set by the source MUST be delivered unchanged to
   the destination node(s).
   
   IPv6 nodes MUST NOT assume any mathematical or other properties of
   the Flow Label values assigned by source nodes.  Router performance
   SHOULD NOT be dependent on the distribution of the Flow Label values.

Regards
Dario

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Jul 2010 20:31:52 -0400

>>>>> "Dario" == Dario Tedeschi <[email-masked]> writes:
    Dario> If the flow label is used by a source to identify a RPL
    Dario> Instance how would the same source use the flow label for
    Dario> other flows not related to RPL. Put another way, if an
    Dario> application (or a transport like TCP) wanted to identify a
    Dario> new data flow, how would the ingress router know that the
    Dario> label was identifying the new flow and not the RPL Instance.

    Dario> Reading RFC 3697, it would appear that the flow label is used
    Dario> in identifying the end-to-end flow, not for identify a route.

Because, in most cases, at least one end point of the flow, is a control
or sensor in the LLN, and therefore it's got a right to participate in
the end-to-end settings.

If the collector machine is not a part of the LLN, then it is going to
have be provisioned with the right flow labels.

If the LLN is connected to the machines outside it's Autonomous System,
then the gateway system at the end is going to have to validate flow
labels anyway, and essentially either permit some through, or "reset" them
all.  Since the labels need to be delivered according to 3697, this may
mean that a gateway machine will need to classify all untrusted flow
labels into some kind of layer-2 tag which indicates "not-trusted" so
that downstream routers will not act on the flow labels.

What I write about may not be "stock" for IPv6, but few things are yet.
It's really our job (in this WG) to establish a typical use for them.

Nobody really knows what the flow labels will get used for, but many
think they will get mapped to things like MPLS labels at border routers.

    Dario> From Section 2 in RFC 3697:

    Dario>   The Flow Label value set by the source MUST be delivered
    Dario> unchanged to the destination node(s).  IPv6 nodes MUST NOT
    Dario> assume any mathematical or other properties of the Flow Label
    Dario> values assigned by source nodes.  Router performance SHOULD
    Dario> NOT be dependent on the distribution of the Flow Label
    Dario> values.

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 28 Jul 2010 09:41:06 +0200

Thanks for your email. As discussed, it will go in the RPL option.

On Jul 28, 2010, at 2:05 AM, Dario Tedeschi wrote:

> would the same source use the flow label for other flows not related  
> to RPL. Put another way, if an application (or a transport like TCP)  
> wanted to identify a new data flow, how would the ingress router  
> know that the label was identifying the new flow and not the RPL  
> Instance.
>
>> ----------------------------- 
>> +----------------------------------------------
>> Reporter:  jpv@…            |        Owner:   
>> pthubert@…             Type:  enhancement      |       Status:   
>> closed             Priority:  major            |     
>> Milestone:                    Component:  rpl              |       
>> Version:                     Severity:  In WG Last Call  |    
>> Resolution:  fixed              Keywords:                   |   
>> ----------------------------- 
>> +----------------------------------------------
>> Changes (by jpv@…):
>>
>>  * status:  new => closed
>>  * resolution:  => fixed
>>
>>
>> Comment:
>>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 28 Jul 2010 10:02:05 +0200

Exactly.

As you know, I do support the idea of using the flow label in a number of circumstances. I'm in fact very much along Michael's lines.

But really, this has nothing to do with the main spec that we need to focus on right now. RPL is completely agnostic to the way the ingress router ( the L3-5 ingress GW in general) will figure the RPLInstanceID. OTOH, RPL describes and owns the RPLInstanceID itself and provides instructions on how it is used to learn/distribute routes, and look up routes while forwarding.

Where exactly the RPLInstanceID is placed I the data packet must be consistent within a network, but might differ from a network to another. We had to provide at least one reference operation as a companion draft. This was done is a separate draft, and the consensus was to use an option in the hop-by-hop header.

If there's interest, and I hope there is, then we can start a draft on a flow-label-based alternative and have WG discussions around it in due time. I'll be glad to participate. In the interest of progress and stability of the main work, let us trust the chairs to guide us on when this and other discussions can best happen.

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of JP
> Vasseur
> Sent: Wednesday, July 28, 2010 9:41 AM
> To: Dario Tedeschi
> Cc: [email-masked]
> Subject: Re: [Roll] [roll] #64: RPL Instance ID in flow label or RPL option
> 
> > wanted to identify a new data flow, how would the ingress router know
> > that the label was identifying the new flow and not the RPL Instance.
> >
> >> 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 carries routing information in a RPL Option
> >> contained in an  IPv6
> >>                 DODAG as discussed in Section 11.2 and may be
> >> extended in future
> >> option ([I-D.hui-6man-rpl-option]) as further described in Section
> >> 10.2
> >>
> >> è
> >>
> >>                 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 contained within
> >> the data
> >>                 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),
> >>                 source of the packet might be aware of the RPL
> >> network, of the
> >>                 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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 28 Jul 2010 06:08:01 -0400

>>>>> "Pascal" == Pascal Thubert <(pthubert)" <[email-masked]>> writes:
    Pascal> As you know, I do support the idea of using the flow label
    Pascal> in a number of circumstances. I'm in fact very much along
    Pascal> Michael's lines.

Good.

    Pascal> But really, this has nothing to do with the main spec that
    Pascal> we need to focus on right now. RPL is completely agnostic to

I agree, mostly: it goes in another specification, but our document may
well block at rfc-editor step waiting for at least one such specification!

It's about RPL-over-FOO, and it certainly affects some very low level 
structures in nodes that are expected to be routes.

    Pascal> If there's interest, and I hope there is, then we can start
    Pascal> a draft on a flow-label-based alternative and have WG
    Pascal> discussions around it in due time. I'll be glad to
    Pascal> participate. In the interest of progress and stability of
    Pascal> the main work, let us trust the chairs to guide us on when
    Pascal> this and other discussions can best happen.

I think that it's somewhat more urgent.
If there are layer-2 places where the RPLinstanceID/flow-label can be
*copied*, then great.  I'm not aware of any other than 801q or MPLS, and
I think given that most of the stacks are custom, either involves adding
equivalent amounts of code as just leaving it in L3 flow label.

---

From: Dario Tedeschi <[email-masked]>
Date: Wed, 28 Jul 2010 13:49:53 -0700

That seems a more appropriate place for it. Thanks.

JP Vasseur wrote:
>>> contained in
>>> extended in
>>> coming
>>> determined
>>> that
>>> confirmed by
>>> network, of
>>> label
>>> exist,
>>> specified
>>> MUST