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

[Mukul Goyal <[e-mail]>]

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" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
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?

#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/>