Subject: [Roll] [roll] #93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4?

From: "roll issue tracker" <[email-masked]>
Date: Thu, 05 Apr 2012 11:01:25 -0000

#93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4?

 Resolution: Open

 Discussion:

 p12 :  This specification does not allow for the establishment of hop-by-
 hop routes in the backward direction.

 [Cedric]
 Why ? This would enable to establish 2 routes within a single route
 request.
 Furthermore, you stipulates in the draft that links have to be
 bidirectional to propagates RDO, in order to be able to send back the DRO.
 So if I understand it correctly you ensure that you have a reliable path
 in both ways. Why using it in a single way only ?

 [Mukul]
 Suppose a DRO establishing a forward hop-by-hop route fails to make it to
 the origin. In this case, all we have is some nodes storing the hop-by-hop
 state for a broken route but that route is never used since the origin
 never gets the DRO. On the other hand, if the DRO establishing a backward
 hop-by-hop route fails to make it to the origin, we have a broken route
 that the target is likely to use (to reach the origin). So, if we want
 P2P-RPL to establish a backward hop-by-hop route, the target MUST ask for
 a DRO-ACK from the origin (to make sure that the DRO does reach the origin
 and hence the backward route is not broken). This can be done if you think
 it will be useful. We did not include this in P2P-RPL because we did not
 have a usecase for backward hop-by-hop routes and we wanted to avoid the
 additional complexity.

 This is how we can implement this functionality: we will let the target
 decide whether it wants the DRO to establish a backward hop-by-hop route.
 In that case:
 1) the target will set a new flag, the B flag (B for backward hop-by-hop
 route), inside the DRO to let intermediate routers know that backward
 route state needs to be established as well;
 2) the target will set the A flag to require a DRO-ACK from the origin;
 3) the target will specify (inside a new field in the DRO), an
 RPLInstanceID under which the hop-by-hop state for the backward route will
 be stored. Note that the RPLInstanceID of the forward route (selected by
 the origin) may not be OK for use in backward route (because the target
 may have already used this RPLInstanceID for another hop-by-hop route,
 using different routing-metrics/constraints/OF, to the origin).
 When the intermediate routers receive this DRO, they will store the hop-
 by-hop state for the backward route. This hop-by-hop state will consist
 of:
 1) Target address (taken from P2P-RDO inside the DRO).
 2) RPLInstanceID specified by the target
 3) The destination, i.e., the origin address (same as DODAGID inside the
 DRO).

 Do you want this functionality?

-- 
-----------------------------------+---------------------
 Reporter:  jpv@…                  |      Owner:  mukul@…
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/93>
roll <http://tools.ietf.org/wg/roll/>

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 5 Apr 2012 09:02:44 -0500 (CDT)

JP

This ticket should be titled differently:

Why P2P-RPL cannot establish a backward hop-by-hop route?

Thanks
Mukul

----- Original Message -----
From: "roll issue tracker" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Sent: Thursday, April 5, 2012 6:01:25 AM
Subject: [roll] #93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4?

 Resolution: Open

 Discussion:

 [Cedric]

 [Mukul]

---

From: C Chauvenet <[email-masked]>
Date: Thu, 5 Apr 2012 14:17:21 +0000

inline

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de roll issue tracker
Envoyé : jeudi 5 avril 2012 13:01
À : [email-masked]; [email-masked]
Cc : [email-masked]
Objet : [Roll] [roll] #93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4?

 Resolution: Open

 Discussion:

 p12 :  This specification does not allow for the establishment of hop-by-  hop routes in the backward direction.

 [Cedric]
 Why ? This would enable to establish 2 routes within a single route  request.
 Furthermore, you stipulates in the draft that links have to be  bidirectional to propagates RDO, in order to be able to send back the DRO.
 So if I understand it correctly you ensure that you have a reliable path  in both ways. Why using it in a single way only ?

 [Mukul]
 Suppose a DRO establishing a forward hop-by-hop route fails to make it to  the origin. In this case, all we have is some nodes storing the hop-by-hop  state for a broken route but that route is never used since the origin  never gets the DRO. On the other hand, if the DRO establishing a backward  hop-by-hop route fails to make it to the origin, we have a broken route  that the target is likely to use (to reach the origin). So, if we want  P2P-RPL to establish a backward hop-by-hop route, the target MUST ask for  a DRO-ACK from the origin (to make sure that the DRO does reach the origin  and hence the backward route is not broken). This can be done if you think  it will be useful. We did not include this in P2P-RPL because we did not  have a usecase for backward hop-by-hop routes and we wanted to avoid the  additional complexity.

 This is how we can implement this functionality: we will let the target  decide whether it wants the DRO to establish a backward hop-by-hop route.
 In that case:
 1) the target will set a new flag, the B flag (B for backward hop-by-hop  route), inside the DRO to let intermediate routers know that backward  route state needs to be established as well;
 2) the target will set the A flag to require a DRO-ACK from the origin;
 3) the target will specify (inside a new field in the DRO), an  RPLInstanceID under which the hop-by-hop state for the backward route will  be stored. Note that the RPLInstanceID of the forward route (selected by  the origin) may not be OK for use in backward route (because the target  may have already used this RPLInstanceID for another hop-by-hop route,  using different routing-metrics/constraints/OF, to the origin).
 When the intermediate routers receive this DRO, they will store the hop-  by-hop state for the backward route. This hop-by-hop state will consist
 of:
 1) Target address (taken from P2P-RDO inside the DRO).
 2) RPLInstanceID specified by the target
 3) The destination, i.e., the origin address (same as DODAGID inside the  DRO).

[Cedric2] 
The group has to discuss and decide wether it is usefull or not. I personnaly think that RPL-P2P draft may be used for binding devices, so it could be valuable to create a 2 way path between the origin and the target. So I would vote in favor of such a mechanism. 
Though, I don't think we should create a new DAG (i.e. select a new RPLInstanceID) for the backward route. What I would like is just the ability for 2 devices to exchange packet in both ways using the same temporary DAG created by RPL-P2P. Let me explain the use case with an example : For instance, if you have nodes deployed in a building or a city, and you want to configure some of them. An operator could go in the area where devices to be programmed are installed (or in the neighborhood at least) with a "configurator node", and need to established a P2P route between this configurator node and the node(s) to be configurated. They create a temporary DAG (possibly through several hops) and exchange configuration frames. Because such messages are  critically important, you often need application layer acknowledgments, so a backward route is needed.
Is the actual specification compliant with such a use case without modification ? (using piggybacked DATA inside RDO and DRO messages) ? Or do wee need an additional mechanism such as the one you described ?

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Mukul Goyal <[email-masked]>
Date: Sun, 8 Apr 2012 15:45:35 -0500 (CDT)

Please see inline (note the changed title of this ticket)

Thanks
Mukul

#93: Whether P2P-RPL should support establishment of a backward hop-by-hop route?

 Resolution: Open

 Discussion:

 [Cedric]

 [Mukul]

[Cedric2] 

[Mukul2]
The target can always use the route inside a received P2P-RDO to source-route a message (e.g. an application level ack) back to the origin. Also, as you noticed, the target can place one or more data options inside the DRO to send an application level message back to the origin. So, the use case you have mentioned (which is, by the way, a common use case in commercial building environment) is supported by current P2P-RPL specification. In my view, no additional mechanism is required if the intent is to just support the usecase you described. Infact, we could not come up with a usecase where backward hop-by-hop routes are absolutely must. So, we decided to keep the specs simple by not allowing establishment of such routes. Also, currently we are shooting for an experimental RFC. If, at a later stage, we realize that backward hop-by-hop routes are necessary, we could support them in standards track RFC.

---

From: C Chauvenet <[email-masked]>
Date: Tue, 10 Apr 2012 16:28:05 +0000

See inline,

-----Message d'origine-----
De : Mukul Goyal [mailto:[email-masked]] 
Envoyé : dimanche 8 avril 2012 22:46
À : C Chauvenet
Cc : [email-masked]; [email-masked]
Objet : Re: [Roll] [roll] #93: A single P2P-RPL invocation can discovery upto 4 source routes. Why 4?

Thanks
Mukul

 Resolution: Open

 Discussion:

 [Cedric]

 [Mukul]

[Cedric2] 

[Mukul2]

[Cedric3]
Ok, the data option seems simple and efficient enough for the use case I pointed out.
Let's keep it as the default option to do simple P2P data exchange.
If more periodic and reliable traffic is needed between 2 nodes in a RPL network, then I think we should include a 2 way path establishment.

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 11 Apr 2012 07:35:54 -0500 (CDT)

Inline.

 Resolution: Open

 Discussion:

 [Cedric]

 [Mukul]

[Cedric2] 

[Mukul2]

[Cedric3]
 
[Mukul3]
Whether the target uses data option in the DRO or a regular data packet (source routed using the discovered route) to reach the origin is target's prerogative. P2P-RPL spec has to be silent in this matter. 

[Cedric3]

[Mukul3]
So you want backward hop-by-hop route? Target using the discovered route as a source route won't be sufficient?

---

From: C Chauvenet <[email-masked]>
Date: Wed, 11 Apr 2012 12:44:27 +0000

inline,

> So you want backward hop-by-hop route? Target using the discovered route as a source route won't be sufficient?

[Cedric4]
Let me reword it : I'm OK to close this ticket as it is an experimental intended status.
Using the discovered route as a source route is sufficient, and the picky backed data option is OK with what I had in mind.
If this draft wants to step up to a standard track, then it could be valuable to discuss the backward hop by hop route establishment.

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 11 Apr 2012 07:53:19 -0500 (CDT)

Resolution:
---------------

No need to do so in current spec as it has experimental intended status.
Using the discovered route as a source route or the piggybacked data option is sufficient for now.
If this draft wants to step up to a standard track, then it could be valuable to discuss the backward hop by hop route establishment.

Discussion:
-----------------

[Cedric]
 
[Mukul]
 
When the intermediate routers receive this DRO, they will store the hop-  by-hop state for the backward route. This hop-by-hop state will consist of:

[Cedric2] 

 
[Mukul2]
 
[Cedric3]
 
[Mukul3]
 
[Cedric3]
 
[Mukul3]

[Cedric4]

---

From: "roll issue tracker" <[email-masked]>
Date: Wed, 11 Apr 2012 14:20:33 -0000

Changes (by jpv@…):

 * cc: roll@… (added)
 * status:  new => closed
 * resolution:   => fixed

Old description:

> the origin. In this case, all we have is some nodes storing the hop-by-
> hop state for a broken route but that route is never used since the
> origin never gets the DRO. On the other hand, if the DRO establishing a
> backward hop-by-hop route fails to make it to the origin, we have a
> broken route that the target is likely to use (to reach the origin). So,
> if we want P2P-RPL to establish a backward hop-by-hop route, the target
> MUST ask for a DRO-ACK from the origin (to make sure that the DRO does
> reach the origin and hence the backward route is not broken). This can be
> done if you think it will be useful. We did not include this in P2P-RPL
> because we did not have a usecase for backward hop-by-hop routes and we
> wanted to avoid the additional complexity.
>
> RPLInstanceID under which the hop-by-hop state for the backward route
> will be stored. Note that the RPLInstanceID of the forward route
> (selected by the origin) may not be OK for use in backward route (because
> the target may have already used this RPLInstanceID for another hop-by-
> hop route, using different routing-metrics/constraints/OF, to the
> origin).

New description:

 #93: Whether P2P-RPL should support establishment of a backward hop-by-hop
 route?

 Resolution:
 ---------------

 No need to do so in current spec as it has experimental intended status.
 Using the discovered route as a source route or the piggybacked data
 option is sufficient for now.
 If this draft wants to step up to a standard track, then it could be
 valuable to discuss the backward hop by hop route establishment.

 Discussion:
 -----------------

 [Cedric]

 [Mukul]

 [Cedric2]
 The group has to discuss and decide wether it is usefull or not. I
 personnaly think that RPL-P2P draft may be used for binding devices, so it
 could be valuable to create a 2 way path between the origin and the
 target. So I would vote in favor of such a mechanism.

 Though, I don't think we should create a new DAG (i.e. select a new
 RPLInstanceID) for the backward route. What I would like is just the
 ability for 2 devices to exchange packet in both ways using the same
 temporary DAG created by RPL-P2P. Let me explain the use case with an
 example : For instance, if you have nodes deployed in a building or a
 city, and you want to configure some of them. An operator could go in the
 area where devices to be programmed are installed (or in the neighborhood
 at least) with a "configurator node", and need to established a P2P route
 between this configurator node and the node(s) to be configurated. They
 create a temporary DAG (possibly through several hops) and exchange
 configuration frames. Because such messages are  critically important, you
 often need application layer acknowledgments, so a backward route is
 needed.

 Is the actual specification compliant with such a use case without
 modification ? (using piggybacked DATA inside RDO and DRO messages) ? Or
 do wee need an additional mechanism such as the one you described ?

 [Mukul2]
 The target can always use the route inside a received P2P-RDO to source-
 route a message (e.g. an application level ack) back to the origin. Also,
 as you noticed, the target can place one or more data options inside the
 DRO to send an application level message back to the origin. So, the use
 case you have mentioned (which is, by the way, a common use case in
 commercial building environment) is supported by current P2P-RPL
 specification. In my view, no additional mechanism is required if the
 intent is to just support the usecase you described. Infact, we could not
 come up with a usecase where backward hop-by-hop routes are absolutely
 must. So, we decided to keep the specs simple by not allowing
 establishment of such routes. Also, currently we are shooting for an
 experimental RFC. If, at a later stage, we realize that backward hop-by-
 hop routes are necessary, we could support them in standards track RFC.

 [Cedric3]
 Ok, the data option seems simple and efficient enough for the use case I
 pointed out.
 Let's keep it as the default option to do simple P2P data exchange.

 [Mukul3]
 Whether the target uses data option in the DRO or a regular data packet
 (source routed using the discovered route) to reach the origin is target's
 prerogative. P2P-RPL spec has to be silent in this matter.

 [Cedric3]
 If more periodic and reliable traffic is needed between 2 nodes in a RPL
 network, then I think we should include a 2 way path establishment.

 [Mukul3]
 So you want backward hop-by-hop route? Target using the discovered route
 as a source route won't be sufficient?

 [Cedric4]
 Let me reword it : I'm OK to close this ticket as it is an experimental
 intended status.
 Using the discovered route as a source route is sufficient, and the picky
 backed data option is OK with what I had in mind.
 If this draft wants to step up to a standard track, then it could be
 valuable to discuss the backward hop by hop route establishment.

--

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

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

---

From: JP Vasseur <[email-masked]>
Date: Wed, 11 Apr 2012 16:21:06 +0200

Ticket closed.