Subject: [Roll] Comments on draft-dt-roll-p2p-rpl-01

From: JP Vasseur <[email-masked]>
Date: Wed, 16 Jun 2010 12:00:06 +0200

Dear authors,

Since I had a number of comments I inserted them in the ID itself. As  
you will notice:
1) Some of them are purely editorial
2) Others are more fundamental and may require just clarifications,  
more discussion on the mailing list, ... In this case, feel free to  
start a separate thread (note that ticket cannot be assigned to non WG  
document).
3) I also suggested new sections

Internet Engineering Task Force                            M. Goyal, Ed.
Internet-Draft                         University of Wisconsin Milwaukee
Intended status: Informational                          E. Baccelli, Ed.
JP> Are you sure that you want to make it informational ?

Expires: December 16, 2010                                         INRIA
                                                                P2P.  
Team
                                                            June 14,  
2010

    Reactive Discovery of Point-to-Point Routes in Low Power and Lossy
                                 Networks
                         draft-dt-roll-p2p-rpl-01

Abstract

    This document describes a mechanism to discover and establish "on
    demand" one or more routes between two routers in a low power and
    lossy network.

JP> Needs a bit more details + explicitly refer to IPv6 in the abstract
and introduction.

Status of this Memo

    This Internet-Draft is submitted to IETF in full conformance with  
the
    provisions of BCP 78 and BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.

    Internet-Drafts are draft documents valid for a maximum of six  
months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    This Internet-Draft will expire on December 16, 2010.

Copyright Notice

    Copyright (c) 2010 IETF Trust and the persons identified as the
    document authors.  All rights reserved.

    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
    carefully, as they describe your rights and restrictions with  
respect
    to this document.  Code Components extracted from this document must
    include Simplified BSD License text as described in Section 4.e of
    the Trust Legal Provisions and are provided without warranty as

Goyal, et al.           Expires December 16, 2010               [Page 1]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

    described in the Simplified BSD License.

Table of Contents

    1.   
Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
    2.  Targeted Use  
Cases . . . . . . . . . . . . . . . . . . . . . .  4
    3.   
Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
    4.  Functional  
Overview  . . . . . . . . . . . . . . . . . . . . .  5
    5.  Propagation of Discovery  
Messages  . . . . . . . . . . . . . .  7
      5.1.  The Route Discovery  
Option . . . . . . . . . . . . . . . .  7
      5.2.  Setting a DIO Carrying a Route Discovery  
Option  . . . . .  9
      5.3.  Processing of a DIO Carrying a Route Discovery Option
            At An Intermediate Node  . . . . . . . . . . . . . . . . .  
10
      5.4.  Processing of a DIO Carrying a Route Discovery Option
            At The Target Router . . . . . . . . . . . . . . . . . . .  
12
    6.  Propagation of Discovery Reply Messages  . . . . . . . . . . .  
13
      6.1.  The Discovery Reply Object (DRO) . . . . . . . . . . . . .  
13
        6.1.1.  The Source Route Option  . . . . . . . . . . . . . . .  
15
      6.2.  DRO as Acknowledgement for Backward Source Routes  . . . .  
16
      6.3.  DRO as Carrier of Forward/Bidirectional Source Routes  . .  
17
      6.4.  Establishing Hop-by-hop Routes Via DRO . . . . . . . . . .  
17
    7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  
18
    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  
18
    9.  Authors and Contributors . . . . . . . . . . . . . . . . . . .  
18
    10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  
18
      10.1. Normative References . . . . . . . . . . . . . . . . . . .  
18
      10.2. Informative References . . . . . . . . . . . . . . . . . .  
18
    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  
19

Goyal, et al.           Expires December 16, 2010               [Page 2]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

1.  Introduction

    RPL [I-D.ietf-roll-rpl] provides multipoint-to-point (MP2P) routes
    from routers in a low power and lossy network (LLN) to a sink router
    by organizing the routers along a Directed Acyclic Graph (DAG)  
rooted
    at the sink.
JP> low power and lossy .... Low Power and Lossy
JP> RPL provides P2MP, MP2P and P2P routes too.

The DAG root initiates the DAG formation by originating
    a DODAG Information Object (DIO) message.  The DIO message is sent
    via link-local multicast and carries information about the
    originating router's position (the "rank") in the DAG.  On receiving
    DIO messages sent by its neighbors, a router determines its own
    "rank" in the DAG and originates its own DIO message.
JP> Without going too much in the details, you may just want to add
that a node decides to join a DODAG according to a number of parameters
(identity of the DODAG, OF, routing/constraints a specified in the  
metric-ID,...).
    RPL enables point-to-multipoint (P2MP) routing from a router to its
    descendants in the DAG by allowing a router to send a Destination
    Advertisement Object (DAO) upwards along the DAG.  The DAO carries
    the aggregated
JP> Potentially "aggregated"
information regarding the descendants (and other local
    prefixes) reachable through the originating router.

    RPL also provides mechanisms for point-to-point (P2P) routing  
between
    any two routers in the DAG.
JP> Yes.
If the destination is within the
    source's "range", the source may directly send packets to the
    destination.  Otherwise, if the destination is a DAG descendant and
    the source maintains "downwards" routing state about this  
descendant,
    it can forward the packet along this route.  Otherwise, the source
    sends the packet to a DAG parent, which then applies the same set of
    rules to forward the packet further.  Thus, a packet travels up the
    DAG until it reaches a router that knows of the downwards route to
    the destination and then it travels down the DAG towards its
    destination.  A router may or may not maintain routing state about a
    descendant depending on whether its immediate children send it such
    information in their DAOs and whether the router can store this
    information.  Thus, in the best case scenario, the "upwards" segment
    of the P2P route between a source and a destination ends at the  
first
    common ancestor of the source and the destination.  In the worst
    case, the "upwards" segment would extend all the way to the DAG's
    root.  If the destination did not originate a DAO, the packet will
    travel all the way to the DAG's root, where it will be dropped.

JP> This may require to be a bit more accurate here. If there is no DAO,
there RPL is used for MP2P routing only (that is not a protocol design
characteristic though).
    The P2P routing functionality available in RPL suffers from several
    shortcomings [I-D.brandt-roll-rpl-applicability-home-building]:

JP> "suffering from several shortcomings" is a bit strong though. You  
may
want to say that additional mechanisms may be required to address  
specific
situation and list them.
    o  The need to maintain routes "proactively", i.e. every possible
       destination in the DAG must originate a DAO.

    o  The constraint to route only along a DAG potentialy leading to
       significantly suboptimal P2P routes and traffic congestion near
       the DAG root.
JP>
First bullet: you can mention that this requires to pro-actively  
advertise the
route and to keep refreshing the state accordingly
Second bullet: just to be very accurate, mention that the route may be  
sub-optimal.
This is highly network topology / OF dependent.

Goyal, et al.           Expires December 16, 2010               [Page 3]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

    These shortcomings are not compatible with the home and commercial
    building domain application requirements described in [RFC5826] and
    [I-D.ietf-roll-building-routing-reqs].
JP> Again, to be accurate, there are no MUST requirements listed in
these ID that are not satisfied by RPL (with regards to the  
aforementioned
issues). I am NOT saying that the proposed mechanism is not useful
(by all means), just that the statement above is not correct.

Such applications require a
    mechanism providing source-initiated discovery of P2P routes that  
are
    not along a DAG.
JP> In some cases, it may be desirable to make use of source- 
initiated ...

This document thus describes such a mechanism,
    complementary to the basic RPL specification.

    The specified scheme is based on a reactive on-demand approach,  
which
    enables a router to discover one or more "good-enough" routes in
    either direction between itself and another router in the LLN  
without
    any constraints regarding the existing DAG-membership of the links
    that such routes may use.
JP> This will be an aspect triggering some discussion. How "good" is
"good enough" ? You will need some text to elaborate here or point
to another section explaining what is meant by "good enough"
Such routes may be source-routes or hop-
    by-hop ones.
JP> Just terminology: instead of referring to hop-by-hop routes, you may
want to say that once a route has been computed between two nodes in
the network, IPv6 packet may be forward using a source routing mechanism
as specified in [XX] or in a hop by hop fashion.
A complementary functionality, necessary to help decide
    whether to initiate a route discovery, is a mechanism to measure the
    end-to-end cost of an existing route.
JP> s/cost/path cost
Such functionality will be
    described in a separate document.

JP> But its use is described in this document ?

2.  Targeted Use Cases

    The mechanisms described in this document are intended to be  
employed
    as complementary to RPL in specific scenarios that need point-to-
    point (P2P) routes between arbitrary routers.

    One target use case, common in a home environment, involves a remote
    control (or a motion sensor) that suddenly needs to communicate with
    a lamp module, whose network address it knows apriori.  In this  
case,
    the source of data (the remote control or the motion sensor) must be
    able to discover a route to the destination (the lamp module) "on
    demand".

    Another target use case, common in a large commercial building
    environment, involves a large LLN deployment where P2P communication
    along a particular DAG among hundreds (or thousands) of routers
    creates severe traffic congestion near that DAG's root, and thus
    routes across this DAG are desirable.

    Targeted use cases also include scenarios where energy or delay
    constraints are not satisfied by the P2P routes along a DAG because
    they involve traversing many more intermediate routers than  
necessary
    to reach the destination.
JP> What I would suggest is to summarize it, put in the introduction,
and detail the use case in the applicability statement.

3.  Terminology

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
    "OPTIONAL" in this document are to be interpreted as described in

Goyal, et al.           Expires December 16, 2010               [Page 4]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

    [RFC2119].

    Additionally, this document uses terminology from
    [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl], and introduces
    the following terminology:

    Origin Router: The router initiating the route discovery.  The  
origin
    router acts as one end point of the routes to be discovered.

    Target Router: The other end point of the routes to be discovered.

    Intermediate Router: A router that is neither the origin nor the
    target.

    Forward Route: A route from the origin router to the target router.

    Backward Route: A route from the target router to the origin router.

    Bidirectional Route: A route that can be used in both directions:
    from the origin router to the target router and vice versa.

    Source Route: A complete and ordered list of routers that can be  
used
    by a packet to travel from a source to a destination.  Such source
    routes can be carried by a packet in a proposed Type 4 Routing  
Header
    [I-D.hui-6man-rpl-routing-header].

    Hop-by-hop Route: A route from a source to a destination where each
    router in the route knows only the address of the next hop on the
    route.
JP> I would suggest to change the definition for "routing paradigm
whereby packets are routed from their source to destination by
on a hop by hop basis where the packets is routed by a set of routers
along the path according to the routing table stored by each router
along the path".

    In this document, the term 'router' refers to any LLN device that  
can
    forward packets generated at other devices.

4.  Functional Overview

    Router A originates a "Discovery" message listing router B as the
    target.  Node A also indicates in the message:

    o  The nature of the routing cost, the method for accumulating the
       end-to-end cost
JP> This may de detailed hereafter but I guess that you will point to
the metric-ID for the metric used?

and the criteria used to determine if a route is
       "good enough";

    o  The direction (forward: router A to router B; backward: router B
       to router A; or both) of the route being discovered;

    o  The desired number of routes;

Goyal, et al.           Expires December 16, 2010               [Page 5]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

    o  Whether the route is a source-route or a hop-by-hop one; and

    o  A limit on the "distance" the Discovery message may travel.

JP> Need to define the term "distance": is it a max path cost, number of
hops, ... ?

    The Discovery message propagates via link-local multicast
JP> Indicate "IPv6"
with each
    receiving router making the decision regarding whether to forward  
the
    message further based on the "distance" (from router A) that this
    particular copy of the message has already traveled.  Note that this
    document does not require a receiving router to use the "good  
enough"
    criteria to make the forwarding decision.  This is because the
    evaluation of such criteria may be too complex for a constrained
    intermediate router to perform for each received copy of the
    Discovery message.
JP> So I guess that you define later what to do in both cases (the node
cannot process the "good enough" criteria or it can process it) ?
The calculation of the "distance" that a copy of
    the Discovery message has already travelled should be simple enough
    for a constrained router to perform.
JP> Again it is hard to tell from what you wrote if this can  
reasonably be
achieved; it depends on the definition of the term "distance".
A router may optionally decide
    not to forward a copy of the Discovery message further because the
    aggregated cost of the route so far fails the "good enough"  
criteria.
JP> You will nee to be more specific here. Is it a "may" or a "MAY".
Define what happens in this case. You may provide more details later
in the document.

    The underlying mechanism being used to propagate the Discovery
    message may put further restrictions on its propagation.  A router
    should not propagate the Discovery message further if hop-by-hop
    routes are desired and the router can not store state for this  
route.

    As a copy of the Discovery message travels towards router B, it
    accumulates the relevant forward/backward costs as well as the route
    it takes.  When router B receives a copy of the Discovery message,  
it
    determines whether the route traveled by the message meets the "good
    enough" criteria.
JP> I think that you already mentioned this.

    If router A had requested the discovery of backward source-routes,
JP> Didn't you mean "forward" ?

    router B caches one or more good enough source-routes it identifies.
    Additionally, router B sends one or more "Discovery Reply" message  
to
    router A to acknowledge the discovery of these routes.  These
    acknowledgements allow router A to judge the success of the route
    discovery.  The Discovery Reply messages can travel towards router A
    in any manner chosen by router B. For example, router B may source-
    route the messages or send them towards router A along a DAG.

    If router A had requested the discovery of "n" forward source- 
routes,
    router B sends the "n" good enough source-routes it identifies to
    router A in one or more Discovery Reply messages.  Again, these
    Discovery Reply messages can travel towards router A in any manner
    chosen by router B.
JP> What if the DAG is "broken": retry from A after expiration of a  
local
timer ?

    If router A had requested the discovery of "n" bidirectional source-
    routes, router B caches the "n" good enough source-routes it
    identifies and also sends these routes to router A in one or more
    Discovery Reply messages.  These Discovery Reply messages can travel
    towards router A in any manner chosen by router B.

Goyal, et al.           Expires December 16, 2010               [Page 6]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

    If router A had requested the discovery of "n" forward/backward/
    bidirectional hop-by-hop routes, router B sends out a Discovery  
Reply
    message to router A for each one of the "n" good enough routes it
    identifies.
JP> Do you need one "Discovery Reply message" per route or next-hop
in this case?
The Discovery Reply message travels towards router A
    using the source-route accumulated by the Discovery message.
JP> In the case of hop-by-hop routes, source routes, both ?
As this
    message travels towards router A, it establishes appropriate  
forward/
    backward routing state in the en-route routers.  This "non DAG"
    routing state should be specially marked to associate it with the
    routing metrics
JP> Refer to metric ID ?
used to discover the route and to distinguish such
    state from other DAG-specific routing state the router may have.
JP> Not sure that you need to distinguish the state. Suppose that you
discover a hop-by-hop route (not a big fan of that terms as pointed out
above but let's continue to use it for the time being), a storing node
may indeed have two routes for the same destination: do you want to
state that it should always use the P2P routes discovered by this
mechanism or let it choose the best one according to the metric in
use?
JP> What if there are two routes using different metrics?

5.  Propagation of Discovery Messages

    RPL uses DIO message propagation to build a DAG.  The DIO message
    travels via link-local multicast.
JP> Add everywhere "IPv6 link-local multicast addresses"

Each router joining the DAG
    determines a rank for itself and ignores the subsequent DIO messages
    received from lower (higher in numerical value) ranked neighbors.
    Thus, the DIO messages propagate outwards rather than return inwards
    towards the DAG root.
JP> I would suggest to align to the RPL terminology. Inward/outward
are not used anymore.

The DIO message generation at a router is
    further controlled by a trickle timer that allows a router to avoid
    generating unnecessary messages.
JP> Add a reference to the Trickle ID

The link-local multicast based
    propagation, trickle-controlled generation and the rank-based
    poisoning of messages traveling in the wrong direction (towards the
    DAG root) provide powerful incentives to use the DIO message as the
    Discovery message and propagate the DIO/Discovery message by  
creating
    a "temporary" DAG.

5.1.  The Route Discovery Option

        0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        |   Type = 9    | Option Length | D |S|  N  | L |O|  Max  
Rank   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
         
|                                                               |
        |                       Target  
Address                          |
         
|                                                               |
         
|                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        |              OCP              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 1: Format of the Route Discovery Option

    In order to be used as a Discovery message, a DIO MUST carry a  
"Route
    Discovery" option illustrated in Figure 1.  A DIO MUST NOT carry  
more

Goyal, et al.           Expires December 16, 2010               [Page 7]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

    than one Route Discovery options.
JP> Explain what you do if more than one is present:
	* Ignore the second one?
	* Ignore the entire message?

A Route Discovery option consists
    of the following fields:

    o  Option Type = 0x09 (to be confirmed by IANA).

    o  Option Length = 20 or 22 octets depending on whether the OCP  
field
       is included or not.

    o  D: A 2-bit field that indicates the direction of the desired
       routes:

       *  D = 0x00: Forward;

       *  D = 0x01: Backward;

       *  D = 0x02: Bidirectional.

    o  S: A flag that indicates whether source routes are desired.  The
       flag is set if the source routes are desired.  The flag is clear
       if hop-by-hop routes are desired.

    o  N: A 3-bit unsigned integer indicating the number of routes
       desired.

    o  L: A 2-bit field indicating the minimum "Life Time" of the
       temporary DAG, i.e., the minimum duration a router joining the
       temporary DAG must maintain its membership in the DAG:

       *  L = 0x00: Minimum life time is 5 seconds;

       *  L = 0x01: Minimum life time is 10 seconds;

       *  L = 0x02: Minimum life time is 1 minute;

       *  L = 0x03: Minimum life time is 10 minutes.

JP> Placeholder ... indicate what happens if a node cannot store that
additional state (add a manageability section).

    o  O: A flag that indicates whether the same OCP is used for route
       discovery as well as temporary DAG formation.  If this flag is
       clear, the OCP contained in the DODAG Configuration option in the
       DIO is used for route discovery as well.  Otherwise, the OCP
       specified in the Route Discovery option is used for route
       selection
JP> s/route selection/route discovery

and the metrics/constraints used for route selection are
       carried in a Metrics Container option immediately following the
       Route Discovery option.
JP> Since OF is decoupled from metrics, you always need to indicate
the metric in use. That said, I do not see your point here. Indeed, the
temporary DAG is built according to some OF and metrics so the
resulting routes will inherit these metrics?

    o  Max Rank: A 7-bit unsigned integer that indicates the maximum  
rank
       allowed in the temporary DAG advertised by the DIO message.  This
       upper limit on the DAG rank serves as the "distance" referred to

Goyal, et al.           Expires December 16, 2010               [Page 8]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

       in Section 4 and provides a control over how far the Route
       Discovery option contained in the DODAG Configuration option in
       the DIO message may travel.
JP> You may discuss it later in this document ... but the distance is  
tied
to how you compute the rank.
A router MUST not
JP> s/MUST not/MUST NOT
join the temporary
       DAG if its rank in the DAG will exceed this limit.  Later  
versions
       of this draft will map the 128 value space available in this  
field
       to 16-bit long limits on the DAG rank.

    o  Target Address: The IPv6 address of the target router.

    o  OCP: 16 bit unsigned integer.  An optional field, present only if
       the O flag is set, that indicates the objective code point (OCP)
       to be used for route selection.

5.2.  Setting a DIO Carrying a Route Discovery Option

    A DIO message that carries a Route Discovery option MUST set the  
Base
    Object, described in [I-D.ietf-roll-rpl], in the following manner:

    o  RPLInstanceID: RPLInstanceID MUST be a local value as described  
in
       Section 4.1 of [I-D.ietf-roll-rpl].

    o  Grounded (G) Flag: MUST be clear since the objective of DAG
       formation is the propagation of Route Discovery option.  This DAG
       is temporary in nature and is not used for routing purpose.

    o  Destination Advertisement Supported (A) Flag: MUST be clear for
       same reasons as described above.

    o  Destination Advertisement Trigger (T) Flag: MUST be clear.

    o  Mode of Operation (MOP): Since the temporary DAG is not to be  
used
       for routing purposes, the value of this field is immaterial.  To
       allow constrained routers to join the DAG, the MOP field SHOULD  
be
       set to 00 (non-storing).

JP> I'd rather suggest to specify a new MOP value (0x02)

    o  DODAGPreference (Prf): TBD

    o  Destination Advertisement Trigger Sequence Number (DTSN): TBD

JP> To be discussed on the mailing list ?

    o  DODAGID: IPv6 address of the router initiating the route
       discovery.

JP> Origin router.

    The other fields in the Base Object are set as per the rules
    described in [I-D.ietf-roll-rpl].

    The DODAG Configuration option, carried in the DIO message,  
specifies
    the parameters for the trickle timer operation that governs the
    generation of DIO messages by the routers joining the temporary DAG.

JP> Also according to RPL ID or would you recommend different
default values ? Default values for RPL are TBD but we could easily
think of different values in this case. To be revisited in the future.

Goyal, et al.           Expires December 16, 2010               [Page 9]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

    The other fields defined in the DODAG Configuration option are set  
as
    follows:

    o  The MaxRankIncrease field MUST be set to 0 to disable local  
repair
       of the temporary DAG.

    o  This document RECOMMENDS a value 1 for the MinHopRankInc field.

    o  Objective Code Point (OCP): The OCP to be used for temporary DAG
       formation.  This document RECOMMENDS RPL Objective Function 0, as
       defined in [I-D.ietf-roll-of0], for use as the objective function
       for the formation of the temporary DAG.

    A DIO, that contains a Route Discovery option with O flag set, MUST
    also contain a Metric Container option immediately following the
    Route Discovery option.  This Metric Container option carries the
    values for the routing metrics as well as the constraints
    (constituting the "good enough" criteria) used for route selection.
JP> This is confusing: the metric and constraint carried within the  
Metric
Container are used for the DODAG formation. Do you want to use them
for a different purpose ? At this point, you have not yet defined the  
use of
the good enough criteria but one can guess that you would use the good
enough metrics to control the flooding and the metric/OF to effectively
build the temporary DAG and discover the routes. If so, the good enough
metrics are of different use.

    Note that if O flag in the Route Discovery option is clear, the OCP
    and Metric Container used for temporary DAG formation are used for
    route selection as well.

    A DIO, carrying a Route Discovery option, MUST not carry any Route
JP> s/MUST not/MUST NOT

    Information or Prefix Information options described in
    [I-D.ietf-roll-rpl].

5.3.  Processing of a DIO Carrying a Route Discovery Option At An
       Intermediate Node

    The rules for DIO processing and transmission, described in  
Section 7
    of RPL [I-D.ietf-roll-rpl], apply to DIOs carrying a Route Discovery
    option as well except as modified in this document.

    When an intermediate router joins a temporary DAG advertized by a  
DIO
    carrying the Route Discovery option, it MUST maintain its membership
    in the DAG for the Minimum Life Time duration listed in the Route
    Discovery option.
JP> What if it cannot ? Just not join the DAG and log an error ?
Maintaining membership in the DAG implies
    remembering:

    o  The RPLInstanceID, the DODAGID and the DODAGVersionNumber for the
       temporary DAG;

    o  The router's rank in the temporary DAG;

    o  The best Metric Container,
JP> you mean the best path cost?
along with the associated source route
       from the initiator of route discovery till this router (carried  
in
       a Record Route IPv6 Extension Header proposed in
       [I-D.thubert-6man-reverse-routing-header]), for the Route

Goyal, et al.           Expires December 16, 2010              [Page 10]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

       Discovery option being propagated by the temporary DAG.  If the
       router can not compare Metric Containers, it MUST remember the
       latest Metric Container it has received, along with the  
associated
       source route.
JP> Requires clarification on what you mean by "compare"

    A router belonging to a temporary DAG need not remember the identity
    of its DAG parents since the temporary DAG is not used for routing.
JP> Are you sure ? What is a hop-by-hop route is needed ? Don't you
need to remember your parent, or do you still record the route ?

    The main purpose of a temporary DAG's existence is to facilitate the
    propagation of the Route Discovery option.

    The router does not process a Route Discovery option, contained in
    the received DIO, any further if any of the following conditions are
    true:

    o  The router does not support the objective function
JP> and/or metrics
being used for
       route discovery

    o  The router does not have sufficient information to calculate the
       relevant routing metrics/constraints in the right direction (as
       specified by the D field).

    o  The S field is clear, i.e. hop-by-hop routes are desired, but the
       router can not participate in a hop-by-hop route.

    o  The router is an intermediate router and the router's rank in the
       temporary DAG, calculated on the basis of the rank and objective
       function carried in the Base Object in the DIO, exceeds the Max
       Rank value specified in the Route Discovery option.

    A router MUST discard the DIO if the Route Discovery option  
contained
    in the message does not need further processing.
JP> Log an error ?
Otherwise, the
    Route Discovery option is processed as follows.

    The router updates the Metrics Container associated with the  
received
    Route Discovery option as per the specified objective function.
JP> And routing metrics

The
    router may optionally check the Metric Container to determine if the
    aggregated values for the routing metrics meet all the constraints
    listed in the Metric Container.
JP> The aggregated values are for the metrics. Constraints are used to
prune potential path.
If not, the Route Discovery option
    is discarded
JP> You mean the DIO message.
without further processing.  Otherwise, the router
    updates its in-memory copy of the latest/best Metric Container for
    this Route Discovery option along with the associated source route
    updated in the correct direction (based on the D field of the Route
    Discovery option).  Any change in the in-memory copy also requires
    resetting the trickle timer and generating a new DIO carrying the
    Route Discovery option, the updated latest/best Metric Container and
    the associated source route (in a Record Route IPv6 extension header
    proposed in [I-D.thubert-6man-reverse-routing-header]) when the  
timer
    fires.
JP> If the changes occur during the lifetime window.
Note that the Metric Container MUST immediately follow the

Goyal, et al.           Expires December 16, 2010              [Page 11]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

    Route Discovery option if the O flag in the Route Discovery option  
is
    set.

5.4.  Processing of a DIO Carrying a Route Discovery Option At The
       Target Router

    When the target router joins the temporary DAG advertized by a DIO
    carrying the Route Discovery option, it MUST maintain its membership
    in the DAG for the Minimum Life Time duration listed in the Route
    Discovery option.  Maintaining membership in the DAG implies
    remembering:

    o  The RPLInstanceID, the DODAGID and the DODAGVersionNumber for the
       temporary DAG;

    o  The router's rank in the temporary DAG;

    The target router does not process a Route Discovery option,
    contained in the received DIO, any further if any of the following
    conditions are true:

    o  The router does not support the objective function used for route
       discovery

    o  The router does not have sufficient information to calculate the
       relevant routing metrics/constraints in the right direction (as
       specified by the D field).

JP> or does not support the metric.

    The target router MUST discard the DIO if the Route Discovery option
    contained in the message does not need further processing.
JP> ? How does it knows (simply because it reaches the destination) ?

    Otherwise, the Route Discovery option is processed as follows.

    The target router updates the Metrics Container associated with the
    received Route Discovery option as per the specified objective
    function.
JP> and routing metrics (remember they are decoupled).

The target router then checks the Metric Container to
    determine if the aggregated values for the routing metrics meet all
    the constraints listed in the Metric Container.
JP> See previous comments.

If not, the Route
    Discovery option is discarded without further processing.   
Otherwise,
    the router MAY select the source route accumulated by the received
    DIO as one of the discovered routes.
JP> "MAY" ? When ?
The target router MUST send one
    or more RPL Control Messages carrying a Discovery Reply Object
    (defined in the next section) back to the origin router (identified
    by the DODAGID field in the DIO Base Object) as discussed in the
    following sections.

    The target router MUST NOT forward a DIO carrying a Route Discovery
    option that lists one of its own addresses as the Target Address.

Goyal, et al.           Expires December 16, 2010              [Page 12]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

6.  Propagation of Discovery Reply Messages

6.1.  The Discovery Reply Object (DRO)

        0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        | RPLInstanceID |    Version    | D |S|  N  |      
Reserved      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
         
|                                                               |
        |                         DODAGID                           |
         
|                                                               |
         
|                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
         
|                                                               |
        |                       Target  
Address                          |
         
|                                                               |
         
|                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        | Option(s)...
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

            Figure 2: Format of the Discovery Reply Object (DRO)

    This document defines a new RPL Control Message type, the Discovery
    Reply Object (DRO) with code 0x04 (to be confirmed by IANA), that
    serves the following functions:

    o  An acknowledgement from the target router to the origin router
       regarding the successful discovery of backward source routes;
JP> ACK of routes from the origin to the target: you may not have routes
in the opposite direction.

    o  Carries one or more forward/bidirectional source routes from the
       target to the origin router;

    o  Establishes a hop-by-hop forward/backward/bidirectional route as
       it travels from the target to the origin router.

    The format for a Discovery Reply Object (DRO) is shown in Figure 2.
    A DRO consists of the following fields:

    o  RPLInstanceID: The RPLInstanceID of the temporary DAG used for
       route discovery.

    o  Version: The Version of the temporary DAG used for route
       discovery.

Goyal, et al.           Expires December 16, 2010              [Page 13]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

    o  DODAGID: The DODAGID of the temporary DAG used for route
       discovery.  The DODAGID also identifies the origin router.  The
       RPLInstanceID, the Version and the DODAGID together uniquely
       identify the temporary DAG used for route discovery and can be
       copied from the Base Object of the DIO advertizing the temporary
       DAG.

    o  D: A 2-bit field that indicates the direction of the discovered
       routes:

       *  D = 0x00: Forward;

       *  D = 0x01: Backward;

       *  D = 0x02: Bidirectional.

       This field has the same value as the corresponding field in the
       Route Discovery option.

    o  S: A flag that is clear if the Discovery Reply Object is
       establishing an hop-by-hop route.  The flag is set if the
       Discovery Reply Object carries (or is an acknowledgement for the
       discovery of) one or more source routes.

    o  N: A 3-bit field that indicates the number of source routes
       carried or acknowledged in the Discovery Reply Object.

    o  Target Address: The IPv6 address of the target router originating
       the Discovery Reply Object.

    o  Reserved: These bits are reserved for future use.  These bits  
MUST
       be set to zero on transmission and MUST be ignored on reception.

    o  Options: The Discovery Reply Object MAY carry up to 7 Source  
Route
       options (defined in the next section) with each such option
       carrying a complete forward/bidirectional source route and
       optionally followed by a Metric Container option that lists the
       aggregated values for the routing metrics for the source route.
JP> This may not be an aggregated value but recorded metric too.

Goyal, et al.           Expires December 16, 2010              [Page 14]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

6.1.1.  The Source Route Option

        0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
        |   Type = 10   | Option Length | Compr |  Pad  |      
Resvd     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+
         
|                                                               |
        .                       
Addresses[1..n]                          .
        .                                                               .
         
|                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
+-+

                 Figure 3: Format of the Source Route Option

    The Source Route option, illustrated in Figure 3, carries a complete
    forward/bidirectional source route from the target router to the
    origin router.  A Source Route option can only be a part of the
    Discovery Reply Object and MAY be immediately followed by a Metric
    Container option that contains the aggregated values of the routing
    metrics for this source route.

    A Route Discovery option consists of the following fields:

    o  Option Type = 0x0A (to be confirmed by IANA).

    o  Option Length = Variable, depending on the size of the Addresses
       vector.

    o  Compr: 4-bit unsigned interger indicating the number of prefix
       octets that are elided from each address.  For example, Compr
       value will be 0 if full IPv6 addresses are carried in the
       Addresses vector.

    o  Pad: 4-bit unsigned integer.  Number of octets that are used for
       padding between Address[n] and the end of the Source Route  
option.

    o  Address[1..n]: Vector of addresses, numbered 1 to n.  Each vector
       element has size (16 - Compr) octets.

    A common network configuration for an RPL domain is that all routers
    within an LLN share a common prefix.  The Source Route option uses
    the Compr field to allow compaction of the Addresses[1..n] vector
    when all entries share the same prefix as the DODAGID or the Target
    Address of the encapsulating Discovery Reply Object.  The shared
    prefix octets are not carried within the Source Route option and  
each
    entry in Address[1..n] has size (16 - Compr) octets.  When Compr is

Goyal, et al.           Expires December 16, 2010              [Page 15]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

    non-zero, there may exist unused octets between the last entry,
    Address[n], and the end of the Source Route option.  The Pad field
    indicates the number of unused octets that are used for padding.
    Note that when Compr is 0, Pad MUST be null and carry a value 0.

    The Source Route option MUST NOT specify a path that visits a router
    more than once.  When generating a Source Route option, the target
    router may not know the mapping between IPv6 addresses and routers.
    Minimally, the target router MUST ensure that:

    o  The IPv6 Addresses do not appear more than once;

    o  The IPv6 addresses of the origin and the target routers do not
       appear in the Address vector;

    o  The Address vector represents a source route in forward direction
       with Address[1] being the next hop for the origin router.

    Multicast addresses MUST NOT appear in a Source Route option.

JP> you may want to add a ref to RH4 since the format is very similar.

6.2.  DRO as Acknowledgement for Backward Source Routes

    When a target router discovers a backward source route,
JP> I have an issue with your terminology. When the target receives the
DIO with route discovery option, what is discovered is a forward route ?

it sends a
    DRO message to the origin router as an acknowlegement for the
    discovered route.  Optionally, a target router MAY send a DRO
    acknowledgement to the origin router after discovering multiple
    backward source routes.  A DRO, serving as an acknowledgement for
    backward source route discovery, has its D field set to 0x01
    (indicating backward) while the S flag is set to 1 (indicating  
source
    route).  The N field is set to indicate the number of discovered
    backward source routes being acknowledged.  Such a DRO message MUST
    NOT contain any option.

    This document does not require a particular method for sending  
such a
    DRO message to the origin router.  The target router MAY send the  
DRO
    message to the origin router in any fashion, including:

    o  Using a source route carried in a Type 4 Routing header
       [I-D.hui-6man-rpl-routing-header];

    o  Along any DAG connecting the target and the origin routers;

    o  Along the temporary DAG created for route discovery, provided  
that
       the target router is reasonably sure that the DAG's life time is
       sufficiently long and the routers in the DAG do remember one or
       more of their parents in the DAG.
JP> You may want to explain a bit more why you the origin router
would be interested in receiving an ACK without the route itself (case
6.3): hop-by-hop routes.

Goyal, et al.           Expires December 16, 2010              [Page 16]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

6.3.  DRO as Carrier of Forward/Bidirectional Source Routes

    When a target router discovers a forward source route,
JP> Here, I agree that this is a forward route.
it sends a DRO
    message to the origin router carrying the discovered source route
    inside a Source Route option.  Similarly, when a target router
    discovers a bidirectional source route, it caches the route for its
    own use and then sends a DRO message to the origin router carrying
    the discovered route inside a Source Route option.  Rather than
    immediately sending a discovered route back to the origin router, a
    target router MAY optionally send one DRO message after discovering
    multiple forward/bidirectional source routes with the sent DRO
    carrying the discovered source routes (in multiple Source Route
    options).
JP> Note that the algorithm for "best route" selection is outside the  
scope
of this document, so does the use of a timer on the target side to  
determine
how much time to wait before answering, ...

    A DRO message carrying one or more Source Route options MUST have  
its
    D field set to 0x00 (for forward routes) or 0x02 (for bidirectional
    routes).  The S flag MUST be set to 1 and the N field MUST indicate
    the number of Source Route options in the message.  A Source Route
    option MAY immediately be followed by a Metric Container option that
    carries the aggregated
JP> or recorded
values of the routing metrics for this source
    route.  The target router may send this DRO message to the origin
    router in any fashion it desires including the options listed in
    Section 6.2.

6.4.  Establishing Hop-by-hop Routes Via DRO

    In order to establish a hop-by-hop route, the target router sends a
    DRO message along the reverse of the discovered route (via a Type 4
    Routing Header specified in [I-D.hui-6man-rpl-routing-header]).  The
    D field of the message is set to convey the route's direction
    (forward/backward/bidirectional) and the S flag MUST be clear
    (indicating hop-by-hop).  The N field MUST be set to 1.  Such a DRO
    MUST NOT contain any option.

    A router receiving such a DRO message SHOULD establish hop-by-hop
    state in the right direction corresponding to the route carried in
    the Type 4 Routing Header of the DRO message.  If a router does not
    establish such state, it MUST drop the DRO message.  Otherwise, it
    MUST forward the DRO message along the source route contained in  
Type
    4 Routing Header of the received message.

JP> Any error log if it does not ? (optional) ICMP sent to the target  
node?

    A router SHOULD associate the hop-by-hop routing state, thus
    established, with the objective function and metrics used for route
    discovery.

Goyal, et al.           Expires December 16, 2010              [Page 17]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

JP> New section to indicate how to clean-up the temporary DAG ?

7.  Security Considerations

    TBA

8.  IANA Considerations

    TBA

9.  Authors and Contributors

    In addition to the editor, the authors of this document include the
    following individuals (listed in alphabetical order).

    Anders Brandt, Sigma Designs, Emdrupvej 26A, 1., Copenhagen,  
Dk-2100,
    Denmark.  Phone: +45 29609501; Email: [email-masked]

    Robert Cragie, Gridmerge Ltd, 89 Greenfield Crescent, Wakefieldm WF4
    4WA, UK.  Phone: +44 1924910888; Email: [email-masked]

    Jerald Martocci, Johnson Controls, Milwaukee, WI 53202, USA.  Phone:
    +1 414 524 4010; Email:[email-masked]

    Charles Perkins, Tellabs Inc., USA.  Email:[email-masked]

    Authors gratefully acknowledge the contributions of Richard Kelsey
    and Zach Shelby in the development of this document.

10.  References

10.1.  Normative References

    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

10.2.  Informative References

    [I-D.brandt-roll-rpl-applicability-home-building]
               Brandt, A., Baccelli, E., and R. Cragie, "Applicability
               Statement: The use of RPL in Building and Home
               Environments",
               draft-brandt-roll-rpl-applicability-home-building-00  
(work
               in progress), April 2010.

    [I-D.hui-6man-rpl-routing-header]
               Hui, J., Vasseur, J., and D. Culler, "A Source Routing

Goyal, et al.           Expires December 16, 2010              [Page 18]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

               Header for RPL", draft-hui-6man-rpl-routing-header-00
               (work in progress), May 2010.

    [I-D.ietf-roll-building-routing-reqs]
               Martocci, J., Riou, N., Mil, P., and W. Vermeylen,
               "Building Automation Routing Requirements in Low Power  
and
               Lossy Networks", draft-ietf-roll-building-routing-reqs-09
               (work in progress), January 2010.

    [I-D.ietf-roll-of0]
               Thubert, P., "RPL Objective Function 0",
               draft-ietf-roll-of0-02 (work in progress), June 2010.

    [I-D.ietf-roll-routing-metrics]
               Vasseur, J., Kim, M., Networks, D., and H. Chong,  
"Routing
               Metrics used for Path Calculation in Low Power and Lossy
               Networks", draft-ietf-roll-routing-metrics-07 (work in
               progress), June 2010.

    [I-D.ietf-roll-rpl]
               Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing
               Protocol for Low power and Lossy Networks",
               draft-ietf-roll-rpl-09 (work in progress), June 2010.

    [I-D.ietf-roll-terminology]
               Vasseur, J., "Terminology in Low power And Lossy
               Networks", draft-ietf-roll-terminology-03 (work in
               progress), March 2010.

    [I-D.thubert-6man-reverse-routing-header]
               Thubert, P., "Reverse Routing Header",
               draft-thubert-6man-reverse-routing-header-00 (work in
               progress), June 2010.

    [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
               Routing Requirements in Low-Power and Lossy Networks",
               RFC 5826, April 2010.

Goyal, et al.           Expires December 16, 2010              [Page 19]

Internet-Draft          draft-dt-roll-p2p-rpl-01               June 2010

Authors' Addresses

    Mukul Goyal (editor)
    University of Wisconsin Milwaukee
    3200 N Cramer St
    Milwaukee, WI  53211
    USA

    Phone: +1 414 2295001
    Email: [email-masked]

    Emmanuel Baccelli (editor)
    INRIA

    Phone: +33-169-335-511
    Email: [email-masked]
    URI:   http://www.emmanuelbaccelli.org/

    P2P Team

JP> Remove P2P Team unless you list the people.

Goyal, et al.           Expires December 16, 2010              [Page 20]

---

From: JP Vasseur <[email-masked]>
Date: Wed, 16 Jun 2010 12:10:59 +0200

Hi,

As promised here is some text wrt the trade-off on on-demand routing.

"As pointed out in this document, RPL does provide support of P2P  
routes via a common
ancestor. Using the mechanism described in this document, more optimal  
routes with
regards to some metrics may be discovered but it is worth pointing out  
that this comes
at the price of additional control messages in the network since the  
discovery process
requires sending additional routing control plane messages. The gain  
in terms of path
optimality may vary with the network topology and networking  
conditions. Thus network
designer may want to take into account the trade-off between the  
potential discovery of a
more optimal route and the associated cost in terms of network and  
node resources.
Note that on-demand routing also offers the benefit of not having to  
maintains states
as with proactive routing."

Thanks.

JP.

On Jun 16, 2010, at 12:00 PM, JP Vasseur wrote:

> Dear authors,
>
> Since I had a number of comments I inserted them in the ID itself.  
> As you will notice:
> start a separate thread (note that ticket cannot be assigned to non  
> WG document).
>  Status of this Memo    This Internet-Draft is submitted to IETF in  
> full conformance with the   provisions of BCP 78 and BCP 79.     
> working documents as Internet-Drafts.  The list of current  
> Internet-   Drafts is at http://datatracker.ietf.org/drafts/ 
> current/.    Internet-Drafts are draft documents valid for a maximum  
> of six months   and may be updated, replaced, or obsoleted by other  
> documents at any   time.  It is inappropriate to use Internet-Drafts  
> as reference   material or to cite them other than as "work in  
> progress."    This Internet-Draft will expire on December 16, 2010.  
> Copyright Notice    Copyright (c) 2010 IETF Trust and the persons  
> identified as the   document authors.  All rights reserved.    This  
> document is subject to BCP 78 and the IETF Trust's Legal    
> Provisions Relating to IETF Documents   (http://trustee.ietf.org/license-info 
> ) in effect on the date of   publication of this document.  Please  
> review these documents   carefully, as they describe your rights and  
> restrictions with respect   to this document.  Code Components  
> extracted from this document must   include Simplified BSD License  
> text as described in Section 4.e of   the Trust Legal Provisions and  
> are provided without warranty as Goyal, et al.           Expires  
> December 16, 2010               [Page 1]  Internet-Draft          dra 
> ft-dt-roll-p2p-rpl-01               June 2010    described in the  
> Simplified BSD License. Table of Contents    1.   
> 2.  Targeted Use Cases . . . . . . . . . . . . . . . . . . . . . .   
> 4   3.   
> 4.  Functional Overview  . . . . . . . . . . . . . . . . . . . . .   
> 5   5.  Propagation of Discovery  
> Messages  . . . . . . . . . . . . . .  7     5.1.  The Route  
> Discovery Option . . . . . . . . . . . . . . . .  7     5.2.   
> Setting a DIO Carrying a Route Discovery Option  . . . . .  9      
> 5.3.  Processing of a DIO Carrying a Route Discovery  
> Option           At An Intermediate  
> Node  . . . . . . . . . . . . . . . . . 10     5.4.  Processing of a  
> DIO Carrying a Route Discovery Option           At The Target  
> Router . . . . . . . . . . . . . . . . . . . 12   6.  Propagation of  
> Discovery Reply Messages  . . . . . . . . . . . 13     6.1.  The  
> Discovery Reply Object (DRO) . . . . . . . . . . . . . 13        
> 15     6.2.  DRO as Acknowledgement for Backward Source  
> Routes  . . . . 16     6.3.  DRO as Carrier of Forward/Bidirectional  
> Source Routes  . . 17     6.4.  Establishing Hop-by-hop Routes Via  
> DRO . . . . . . . . . . 17   7.  Security  
> Considerations  . . . . . . . . . . . . . . . . . . . 18   8.  IANA  
> Considerations  . . . . . . . . . . . . . . . . . . . . . 18   9.   
> Authors and Contributors . . . . . . . . . . . . . . . . . . . 18    
> 18     10.1. Normative  
> References . . . . . . . . . . . . . . . . . . . 18     10.2.  
> Informative References . . . . . . . . . . . . . . . . . . 18    
> 19 Goyal, et al.           Expires December 16, 2010                
> [Page 2]  Internet-Draft          draft-dt-roll-p2p-rpl-01            
>     June 2010 1.  Introduction    RPL [I-D.ietf-roll-rpl] provides  
> multipoint-to-point (MP2P) routes   from routers in a low power and  
> lossy network (LLN) to a sink router   by organizing the routers  
> along a Directed Acyclic Graph (DAG) rooted   at the sink.
> JP> "suffering from several shortcomings" is a bit strong though.  
> You may
> Second bullet: just to be very accurate, mention that the route may  
> be sub-optimal.
>  Goyal, et al.           Expires December 16, 2010                
> [Page 3]  Internet-Draft          draft-dt-roll-p2p-rpl-01            
>     June 2010    These shortcomings are not compatible with the home  
> and commercial   building domain application requirements described  
> in [RFC5826] and   [I-D.ietf-roll-building-routing-reqs].
>  2.  Targeted Use Cases    The mechanisms described in this document  
> are intended to be employed   as complementary to RPL in specific  
> scenarios that need point-to-   point (P2P) routes between arbitrary  
> routers.    One target use case, common in a home environment,  
> involves a remote   control (or a motion sensor) that suddenly needs  
> to communicate with   a lamp module, whose network address it knows  
> apriori.  In this case,   the source of data (the remote control or  
> the motion sensor) must be   able to discover a route to the  
> destination (the lamp module) "on   demand".    Another target use  
> case, common in a large commercial building   environment, involves  
> a large LLN deployment where P2P communication   along a particular  
> DAG among hundreds (or thousands) of routers   creates severe  
> traffic congestion near that DAG's root, and thus   routes across  
> this DAG are desirable.    Targeted use cases also include scenarios  
> where energy or delay   constraints are not satisfied by the P2P  
> routes along a DAG because   they involve traversing many more  
> intermediate routers than necessary   to reach the destination.
>    it takes.  When router B receives a copy of the Discovery  
> message, it
>    Additionally, router B sends one or more "Discovery Reply"  
> message to
> JP> You may discuss it later in this document ... but the distance  
> is tied
>    o  RPLInstanceID: RPLInstanceID MUST be a local value as  
> described in
>       allow constrained routers to join the DAG, the MOP field  
> SHOULD be
>       set to 00 (non-storing).
>
>    The other fields defined in the DODAG Configuration option are  
> set as
>    follows:
>
> for a different purpose ? At this point, you have not yet defined  
> the use of
>       from the initiator of route discovery till this router  
> (carried in
>    Route Discovery option if the O flag in the Route Discovery  
> option is
>    set.
>
>    The target router MUST discard the DIO if the Route Discovery  
> option   contained in the message does not need further processing.
>  Goyal, et al.           Expires December 16, 2010               
> [Page 14]  Internet-Draft          draft-dt-roll-p2p-rpl-01           
>      June 2010 6.1.1.  The Source Route Option         
> 0                   1                   2                   3         
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0  
> 1       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+-+       |   Type = 10   | Option Length | Compr |  Pad  |      
> Resvd     |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+-+-+-+-+-+-+        
> |                                                                
> |       .                       
> Addresses 
> [1 
> ..n 
> ]                          .       .                                                               .       | 
>                                                                 
> |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+-+                 Figure 3: Format of the Source Route Option     
> The Source Route option, illustrated in Figure 3, carries a  
> complete   forward/bidirectional source route from the target router  
> to the   origin router.  A Source Route option can only be a part of  
> the   Discovery Reply Object and MAY be immediately followed by a  
> Metric   Container option that contains the aggregated values of the  
> routing   metrics for this source route.    A Route Discovery option  
> consists of the following fields:    o  Option Type = 0x0A (to be  
> confirmed by IANA).    o  Option Length = Variable, depending on the  
> size of the Addresses      vector.    o  Compr: 4-bit unsigned  
> interger indicating the number of prefix      octets that are elided  
> from each address.  For example, Compr      value will be 0 if full  
> IPv6 addresses are carried in the      Addresses vector.    o  Pad:  
> 4-bit unsigned integer.  Number of octets that are used for       
> option.    o  Address[1..n]: Vector of addresses, numbered 1 to n.   
> Each vector      element has size (16 - Compr) octets.    A common  
> network configuration for an RPL domain is that all routers   within  
> an LLN share a common prefix.  The Source Route option uses   the  
> Compr field to allow compaction of the Addresses[1..n] vector   when  
> all entries share the same prefix as the DODAGID or the Target    
> each   entry in Address[1..n] has size (16 - Compr) octets.  When  
> Compr is Goyal, et al.           Expires December 16,  
> 2010              [Page 15]  Internet-Draft          draft-dt-roll-p2 
> p-rpl-01               June 2010    non-zero, there may exist unused  
> octets between the last entry,   Address[n], and the end of the  
> Source Route option.  The Pad field   indicates the number of unused  
> octets that are used for padding.   Note that when Compr is 0, Pad  
> MUST be null and carry a value 0.    The Source Route option MUST  
> NOT specify a path that visits a router   more than once.  When  
> generating a Source Route option, the target   router may not know  
> the mapping between IPv6 addresses and routers.   Minimally, the  
> target router MUST ensure that:    o  The IPv6 Addresses do not  
> appear more than once;    o  The IPv6 addresses of the origin and  
> the target routers do not      appear in the Address vector;    o   
> The Address vector represents a source route in forward  
> direction      with Address[1] being the next hop for the origin  
> router.    Multicast addresses MUST NOT appear in a Source Route  
> option.
>  Goyal, et al.           Expires December 16, 2010               
> [Page 16]  Internet-Draft          draft-dt-roll-p2p-rpl-01           
>      June 2010 6.3.  DRO as Carrier of Forward/Bidirectional Source  
> Routes    When a target router discovers a forward source route,
> JP> Note that the algorithm for "best route" selection is outside  
> the scope
>     A DRO message carrying one or more Source Route options MUST  
> have its   D field set to 0x00 (for forward routes) or 0x02 (for  
> bidirectional   routes).  The S flag MUST be set to 1 and the N  
> field MUST indicate   the number of Source Route options in the  
> message.  A Source Route   option MAY immediately be followed by a  
> Metric Container option that   carries the aggregated
> JP> or recorded
> JP> Any error log if it does not ? (optional) ICMP sent to the  
> target node?
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Anders Brandt" <[email-masked]>
Date: Wed, 16 Jun 2010 12:42:22 +0200

Hi JP
 
Good starting point.
 
I would like to add that several application spaces have a need for
almost immediate delivery at any time.
For these applications, the optimal route is convenience while swift
delivery is a must. Reactive discovery
is the way to guarantee swift delivery at any time.
 
Thanks,
  Anders

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of JP Vasseur
	Sent: Wednesday, June 16, 2010 12:11
	To: Mukul Goyal; Emmanuel Baccelli
	Cc: ROLL WG
	Subject: Re: [Roll] Comments on draft-dt-roll-p2p-rpl-01

	Hi, 

	As promised here is some text wrt the trade-off on on-demand
routing.

	"As pointed out in this document, RPL does provide support of
P2P routes via a common
	ancestor. Using the mechanism described in this document, more
optimal routes with 
	regards to some metrics may be discovered but it is worth
pointing out that this comes
	at the price of additional control messages in the network since
the discovery process
	requires sending additional routing control plane messages. The
gain in terms of path 
	optimality may vary with the network topology and networking
conditions. Thus network 
	designer may want to take into account the trade-off between the
potential discovery of a 
	more optimal route and the associated cost in terms of network
and node resources.
	Note that on-demand routing also offers the benefit of not
having to maintains states 
	as with proactive routing."

	Thanks.

	JP.

		Dear authors,

		Since I had a number of comments I inserted them in the
ID itself. As you will notice:
		1) Some of them are purely editorial
		2) Others are more fundamental and may require just
clarifications, more discussion on the mailing list, ... In this case,
feel free to start a separate thread (note that ticket cannot be
assigned to non WG document).
		3) I also suggested new sections

		Internet Engineering Task Force
M. Goyal, Ed.
		Internet-Draft                         University of
Wisconsin Milwaukee
		Intended status: Informational
E. Baccelli, Ed.
		
		JP> Are you sure that you want to make it informational
?

		Expires: December 16, 2010
INRIA
	
P2P. Team
	
June 14, 2010

		   Reactive Discovery of Point-to-Point Routes in Low
Power and Lossy
		                                Networks
		                        draft-dt-roll-p2p-rpl-01
		
		Abstract
		
		   This document describes a mechanism to discover and
establish "on
		   demand" one or more routes between two routers in a
low power and
		   lossy network.

		JP> Needs a bit more details + explicitly refer to IPv6
in the abstract 
		and introduction.
		Status of this Memo This Internet-Draft is submitted to
IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet- Drafts is at
http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft
documents valid for a maximum of six months and may be updated,
replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite
them other than as "work in progress." This Internet-Draft will expire
on December 16, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and
the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info) in
effect on the date of publication of this document. Please review these
documents carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this document
must include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as Goyal,
et al. Expires December 16, 2010 [Page 1]  Internet-Draft
draft-dt-roll-p2p-rpl-01 June 2010 described in the Simplified BSD
License. Table of Contents 1. Introduction . . . . . . . . . . . . . . .
. . . . . . . . . . 3 2. Targeted Use Cases . . . . . . . . . . . . . .
. . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . .
. . . . . 4 4. Functional Overview . . . . . . . . . . . . . . . . . . .
. . 5 5. Propagation of Discovery Messages . . . . . . . . . . . . . . 7
5.1. The Route Discovery Option . . . . . . . . . . . . . . . . 7 5.2.
Setting a DIO Carrying a Route Discovery Option . . . . . 9 5.3.
Processing of a DIO Carrying a Route Discovery Option At An Intermediate
Node . . . . . . . . . . . . . . . . . 10 5.4. Processing of a DIO
Carrying a Route Discovery Option At The Target Router . . . . . . . . .
. . . . . . . . . . 12 6. Propagation of Discovery Reply Messages . . .
. . . . . . . . 13 6.1. The Discovery Reply Object (DRO) . . . . . . . .
. . . . . 13 6.1.1. The Source Route Option . . . . . . . . . . . . . .
. 15 6.2. DRO as Acknowledgement for Backward Source Routes . . . . 16
6.3. DRO as Carrier of Forward/Bidirectional Source Routes . . 17 6.4.
Establishing Hop-by-hop Routes Via DRO . . . . . . . . . . 17 7.
Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA
Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. Authors
and Contributors . . . . . . . . . . . . . . . . . . . 18 10. References
. . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative
References . . . . . . . . . . . . . . . . . . . 18 10.2. Informative
References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . .
. . . . . . . . . . . . . . . . . . . . . . 19 Goyal, et al. Expires
December 16, 2010 [Page 2]  Internet-Draft draft-dt-roll-p2p-rpl-01
June 2010 1. Introduction RPL [I-D.ietf-roll-rpl] provides
multipoint-to-point (MP2P) routes from routers in a low power and lossy
network (LLN) to a sink router by organizing the routers along a
Directed Acyclic Graph (DAG) rooted at the sink.  

		The DAG root initiates the DAG formation by originating
		   a DODAG Information Object (DIO) message.  The DIO
message is sent
		   via link-local multicast and carries information
about the
		   originating router's position (the "rank") in the
DAG.  On receiving
		   DIO messages sent by its neighbors, a router
determines its own
		   "rank" in the DAG and originates its own DIO message.

		JP> Without going too much in the details, you may just
want to add
		that a node decides to join a DODAG according to a
number of parameters
		(identity of the DODAG, OF, routing/constraints a
specified in the metric-ID,...).
		   RPL enables point-to-multipoint (P2MP) routing from a
router to its
		   descendants in the DAG by allowing a router to send a
Destination
		   Advertisement Object (DAO) upwards along the DAG.
The DAO carries
		   the aggregated 

		   RPL also provides mechanisms for point-to-point (P2P)
routing between
		   any two routers in the DAG.  
		
		JP> Yes.
		If the destination is within the
		   source's "range", the source may directly send
packets to the
		   destination.  Otherwise, if the destination is a DAG
descendant and
		   the source maintains "downwards" routing state about
this descendant,
		   it can forward the packet along this route.
Otherwise, the source
		   sends the packet to a DAG parent, which then applies
the same set of
		   rules to forward the packet further.  Thus, a packet
travels up the
		   DAG until it reaches a router that knows of the
downwards route to
		   the destination and then it travels down the DAG
towards its
		   destination.  A router may or may not maintain
routing state about a
		   descendant depending on whether its immediate
children send it such
		   information in their DAOs and whether the router can
store this
		   information.  Thus, in the best case scenario, the
"upwards" segment
		   of the P2P route between a source and a destination
ends at the first
		   common ancestor of the source and the destination.
In the worst
		   case, the "upwards" segment would extend all the way
to the DAG's
		   root.  If the destination did not originate a DAO,
the packet will
		   travel all the way to the DAG's root, where it will
be dropped.

		JP> This may require to be a bit more accurate here. If
there is no DAO,
		there RPL is used for MP2P routing only (that is not a
protocol design 
		characteristic though). 
		   The P2P routing functionality available in RPL
suffers from several
		   shortcomings
[I-D.brandt-roll-rpl-applicability-home-building]:

		JP> "suffering from several shortcomings" is a bit
strong though. You may
		want to say that additional mechanisms may be required
to address specific
		situation and list them. 
		   o  The need to maintain routes "proactively", i.e.
every possible
		      destination in the DAG must originate a DAO.
		
		   o  The constraint to route only along a DAG
potentialy leading to
		      significantly suboptimal P2P routes and traffic
congestion near
		      the DAG root.
		
		JP> 
		First bullet: you can mention that this requires to
pro-actively advertise the
		route and to keep refreshing the state accordingly
		Second bullet: just to be very accurate, mention that
the route may be sub-optimal.
		This is highly network topology / OF dependent.
		Goyal, et al. Expires December 16, 2010 [Page 3] 
Internet-Draft draft-dt-roll-p2p-rpl-01 June 2010 These shortcomings are
not compatible with the home and commercial building domain application
requirements described in [RFC5826] and
[I-D.ietf-roll-building-routing-reqs].  
		
		JP> Again, to be accurate, there are no MUST
requirements listed in
		these ID that are not satisfied by RPL (with regards to
the aforementioned
		issues). I am NOT saying that the proposed mechanism is
not useful 
		(by all means), just that the statement above is not
correct.

		Such applications require a
		   mechanism providing source-initiated discovery of P2P
routes that are
		   not along a DAG.  
		
		JP> In some cases, it may be desirable to make use of
source-initiated ... 

		   The specified scheme is based on a reactive on-demand
approach, which
		   enables a router to discover one or more
"good-enough" routes in
		   either direction between itself and another router in
the LLN without
		   any constraints regarding the existing DAG-membership
of the links
		   that such routes may use.  
		
		JP> This will be an aspect triggering some discussion.
How "good" is
		"good enough" ? You will need some text to elaborate
here or point 
		to another section explaining what is meant by "good
enough"
		Such routes may be source-routes or hop-
		   by-hop ones.  
		
		JP> Just terminology: instead of referring to hop-by-hop
routes, you may
		want to say that once a route has been computed between
two nodes in 
		the network, IPv6 packet may be forward using a source
routing mechanism
		as specified in [XX] or in a hop by hop fashion.
		A complementary functionality, necessary to help decide
		   whether to initiate a route discovery, is a mechanism
to measure the
		   end-to-end cost of an existing route.  
		
		JP> s/cost/path cost

		JP> But its use is described in this document ?
		2. Targeted Use Cases The mechanisms described in this
document are intended to be employed as complementary to RPL in specific
scenarios that need point-to- point (P2P) routes between arbitrary
routers. One target use case, common in a home environment, involves a
remote control (or a motion sensor) that suddenly needs to communicate
with a lamp module, whose network address it knows apriori. In this
case, the source of data (the remote control or the motion sensor) must
be able to discover a route to the destination (the lamp module) "on
demand". Another target use case, common in a large commercial building
environment, involves a large LLN deployment where P2P communication
along a particular DAG among hundreds (or thousands) of routers creates
severe traffic congestion near that DAG's root, and thus routes across
this DAG are desirable. Targeted use cases also include scenarios where
energy or delay constraints are not satisfied by the P2P routes along a
DAG because they involve traversing many more intermediate routers than
necessary to reach the destination. 
		
		JP> What I would suggest is to summarize it, put in the
introduction,
		and detail the use case in the applicability statement.
		3.  Terminology
		
		   The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT",
		   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and
		   "OPTIONAL" in this document are to be interpreted as
described in

[Page 4]
		
		Internet-Draft          draft-dt-roll-p2p-rpl-01
June 2010

		   [RFC2119].
		
		   Additionally, this document uses terminology from
		   [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl],
and introduces
		   the following terminology:
		
		   Origin Router: The router initiating the route
discovery.  The origin
		   router acts as one end point of the routes to be
discovered.
		
		   Target Router: The other end point of the routes to
be discovered.
		
		   Intermediate Router: A router that is neither the
origin nor the
		   target.
		
		   Forward Route: A route from the origin router to the
target router.
		
		   Backward Route: A route from the target router to the
origin router.
		
		   Bidirectional Route: A route that can be used in both
directions:
		   from the origin router to the target router and vice
versa.
		
		   Source Route: A complete and ordered list of routers
that can be used
		   by a packet to travel from a source to a destination.
Such source
		   routes can be carried by a packet in a proposed Type
4 Routing Header
		   [I-D.hui-6man-rpl-routing-header].
		
		   Hop-by-hop Route: A route from a source to a
destination where each
		   router in the route knows only the address of the
next hop on the
		   route.
		
		JP> I would suggest to change the definition for
"routing paradigm
		whereby packets are routed from their source to
destination by 
		on a hop by hop basis where the packets is routed by a
set of routers
		along the path according to the routing table stored by
each router
		along the path".
		   In this document, the term 'router' refers to any LLN
device that can
		   forward packets generated at other devices.

		4.  Functional Overview
		
		   Router A originates a "Discovery" message listing
router B as the
		   target.  Node A also indicates in the message:
		
		   o  The nature of the routing cost, the method for
accumulating the
		      end-to-end cost 
		
		JP> This may de detailed hereafter but I guess that you
will point to 
		the metric-ID for the metric used?

		   o  The direction (forward: router A to router B;
backward: router B
		      to router A; or both) of the route being
discovered;

		
		
[Page 5]
		
		Internet-Draft          draft-dt-roll-p2p-rpl-01
June 2010

		   o  Whether the route is a source-route or a
hop-by-hop one; and
		
		   o  A limit on the "distance" the Discovery message
may travel.

		JP> Need to define the term "distance": is it a max path
cost, number of
		hops, ... ?
		The Discovery message propagates via link-local
multicast 
		
		JP> Indicate "IPv6"
		with each
		   receiving router making the decision regarding
whether to forward the
		   message further based on the "distance" (from router
A) that this
		   particular copy of the message has already traveled.
Note that this
		   document does not require a receiving router to use
the "good enough"
		   criteria to make the forwarding decision.  This is
because the
		   evaluation of such criteria may be too complex for a
constrained
		   intermediate router to perform for each received copy
of the
		   Discovery message.  
		
		JP> So I guess that you define later what to do in both
cases (the node
		cannot process the "good enough" criteria or it can
process it) ?
		The calculation of the "distance" that a copy of
		   the Discovery message has already travelled should be
simple enough
		   for a constrained router to perform.  
		
		JP> Again it is hard to tell from what you wrote if this
can reasonably be
		achieved; it depends on the definition of the term
"distance".
		A router may optionally decide
		   not to forward a copy of the Discovery message
further because the
		   aggregated cost of the route so far fails the "good
enough" criteria.
		
		JP> You will nee to be more specific here. Is it a "may"
or a "MAY". 
		Define what happens in this case. You may provide more
details later
		in the document.
		   The underlying mechanism being used to propagate the
Discovery
		   message may put further restrictions on its
propagation.  A router
		   should not propagate the Discovery message further if
hop-by-hop
		   routes are desired and the router can not store state
for this route.
		
		   As a copy of the Discovery message travels towards
router B, it
		   accumulates the relevant forward/backward costs as
well as the route
		   it takes.  When router B receives a copy of the
Discovery message, it
		   determines whether the route traveled by the message
meets the "good
		   enough" criteria.
		
		JP> I think that you already mentioned this.
		   If router A had requested the discovery of backward
source-routes,
		
		JP> Didn't you mean "forward" ?
		   router B caches one or more good enough source-routes
it identifies.
		   Additionally, router B sends one or more "Discovery
Reply" message to
		   router A to acknowledge the discovery of these
routes.  These
		   acknowledgements allow router A to judge the success
of the route
		   discovery.  The Discovery Reply messages can travel
towards router A
		   in any manner chosen by router B. For example, router
B may source-
		   route the messages or send them towards router A
along a DAG.
		
		   If router A had requested the discovery of "n"
forward source-routes,
		   router B sends the "n" good enough source-routes it
identifies to
		   router A in one or more Discovery Reply messages.
Again, these
		   Discovery Reply messages can travel towards router A
in any manner
		   chosen by router B.
		
		JP> What if the DAG is "broken": retry from A after
expiration of a local
		timer ?
		   If router A had requested the discovery of "n"
bidirectional source-
		   routes, router B caches the "n" good enough
source-routes it
		   identifies and also sends these routes to router A in
one or more
		   Discovery Reply messages.  These Discovery Reply
messages can travel
		   towards router A in any manner chosen by router B.

[Page 6]
		
		Internet-Draft          draft-dt-roll-p2p-rpl-01
June 2010

		   If router A had requested the discovery of "n"
forward/backward/
		   bidirectional hop-by-hop routes, router B sends out a
Discovery Reply
		   message to router A for each one of the "n" good
enough routes it
		   identifies.  
		
		JP> Do you need one "Discovery Reply message" per route
or next-hop
		in this case?
		The Discovery Reply message travels towards router A
		   using the source-route accumulated by the Discovery
message.  
		
		JP> In the case of hop-by-hop routes, source routes,
both ?
		As this
		   message travels towards router A, it establishes
appropriate forward/
		   backward routing state in the en-route routers.  This
"non DAG"
		   routing state should be specially marked to associate
it with the
		   routing metrics 
		
		JP> Refer to metric ID ?
		used to discover the route and to distinguish such
		   state from other DAG-specific routing state the
router may have.
		
		JP> Not sure that you need to distinguish the state.
Suppose that you
		discover a hop-by-hop route (not a big fan of that terms
as pointed out
		above but let's continue to use it for the time being),
a storing node
		may indeed have two routes for the same destination: do
you want to
		state that it should always use the P2P routes
discovered by this
		mechanism or let it choose the best one according to the
metric in
		use?
		
		JP> What if there are two routes using different
metrics?
		5.  Propagation of Discovery Messages
		
		   RPL uses DIO message propagation to build a DAG.  The
DIO message
		   travels via link-local multicast.  

		Each router joining the DAG
		   determines a rank for itself and ignores the
subsequent DIO messages
		   received from lower (higher in numerical value)
ranked neighbors.
		   Thus, the DIO messages propagate outwards rather than
return inwards
		   towards the DAG root.  
		
		JP> I would suggest to align to the RPL terminology.
Inward/outward
		are not used anymore.

		The DIO message generation at a router is
		   further controlled by a trickle timer that allows a
router to avoid
		   generating unnecessary messages.  

		The link-local multicast based
		   propagation, trickle-controlled generation and the
rank-based
		   poisoning of messages traveling in the wrong
direction (towards the
		   DAG root) provide powerful incentives to use the DIO
message as the
		   Discovery message and propagate the DIO/Discovery
message by creating
		   a "temporary" DAG.

		       0                   1                   2
3
		        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
4 5 6 7 8 9 0 1
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		       |   Type = 9    | Option Length | D |S|  N  | L
|O|  Max Rank   |
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		       |
|
		       |                       Target Address
|
		       |
|
		       |
|
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		       |              OCP              |
		       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

		              Figure 1: Format of the Route Discovery
Option
		
		   In order to be used as a Discovery message, a DIO
MUST carry a "Route
		   Discovery" option illustrated in Figure 1.  A DIO
MUST NOT carry more

[Page 7]
		
		Internet-Draft          draft-dt-roll-p2p-rpl-01
June 2010

		
		
		   o  Option Length = 20 or 22 octets depending on
whether the OCP field
		      is included or not.
		
		   o  D: A 2-bit field that indicates the direction of
the desired
		      routes:
		
		      *  D = 0x00: Forward;
		
		      *  D = 0x01: Backward;

		   o  S: A flag that indicates whether source routes are
desired.  The
		      flag is set if the source routes are desired.  The
flag is clear
		      if hop-by-hop routes are desired.
		
		   o  N: A 3-bit unsigned integer indicating the number
of routes
		      desired.
		
		   o  L: A 2-bit field indicating the minimum "Life
Time" of the
		      temporary DAG, i.e., the minimum duration a router
joining the
		      temporary DAG must maintain its membership in the
DAG:

		

		
		JP> Placeholder ... indicate what happens if a node
cannot store that
		additional state (add a manageability section).
		   o  O: A flag that indicates whether the same OCP is
used for route
		      discovery as well as temporary DAG formation.  If
this flag is
		      clear, the OCP contained in the DODAG
Configuration option in the
		      DIO is used for route discovery as well.
Otherwise, the OCP
		      specified in the Route Discovery option is used
for route
		      selection 

		and the metrics/constraints used for route selection are
		      carried in a Metrics Container option immediately
following the
		      Route Discovery option.
		
		JP> Since OF is decoupled from metrics, you always need
to indicate
		the metric in use. That said, I do not see your point
here. Indeed, the 
		temporary DAG is built according to some OF and metrics
so the 
		resulting routes will inherit these metrics?
		   o  Max Rank: A 7-bit unsigned integer that indicates
the maximum rank
		      allowed in the temporary DAG advertised by the DIO
message.  This
		      upper limit on the DAG rank serves as the
"distance" referred to

[Page 8]
		
		Internet-Draft          draft-dt-roll-p2p-rpl-01
June 2010

		      in Section 4 and provides a control over how far
the Route
		      Discovery option contained in the DODAG
Configuration option in
		      the DIO message may travel.  
		
		JP> You may discuss it later in this document ... but
the distance is tied
		to how you compute the rank.
		A router MUST not 
		
		JP> s/MUST not/MUST NOT
		join the temporary
		      DAG if its rank in the DAG will exceed this limit.
Later versions
		      of this draft will map the 128 value space
available in this field
		      to 16-bit long limits on the DAG rank.
		
		   o  Target Address: The IPv6 address of the target
router.
		
		   o  OCP: 16 bit unsigned integer.  An optional field,
present only if
		      the O flag is set, that indicates the objective
code point (OCP)
		      to be used for route selection.

		   A DIO message that carries a Route Discovery option
MUST set the Base
		   Object, described in [I-D.ietf-roll-rpl], in the
following manner:
		
		   o  RPLInstanceID: RPLInstanceID MUST be a local value
as described in
		      Section 4.1 of [I-D.ietf-roll-rpl].
		
		   o  Grounded (G) Flag: MUST be clear since the
objective of DAG
		      formation is the propagation of Route Discovery
option.  This DAG
		      is temporary in nature and is not used for routing
purpose.
		
		   o  Destination Advertisement Supported (A) Flag: MUST
be clear for
		      same reasons as described above.
		
		   o  Destination Advertisement Trigger (T) Flag: MUST
be clear.
		
		   o  Mode of Operation (MOP): Since the temporary DAG
is not to be used
		      for routing purposes, the value of this field is
immaterial.  To
		      allow constrained routers to join the DAG, the MOP
field SHOULD be
		      set to 00 (non-storing).

		
		   o  Destination Advertisement Trigger Sequence Number
(DTSN): TBD

		JP> To be discussed on the mailing list ?
		   o  DODAGID: IPv6 address of the router initiating the
route
		      discovery.

		JP> Origin router.
		   The other fields in the Base Object are set as per
the rules
		   described in [I-D.ietf-roll-rpl].
		
		   The DODAG Configuration option, carried in the DIO
message, specifies
		   the parameters for the trickle timer operation that
governs the
		   generation of DIO messages by the routers joining the
temporary DAG.

		JP> Also according to RPL ID or would you recommend
different
		default values ? Default values for RPL are TBD but we
could easily
		think of different values in this case. To be revisited
in the future.
		
[Page 9]
		
		Internet-Draft          draft-dt-roll-p2p-rpl-01
June 2010

		   The other fields defined in the DODAG Configuration
option are set as
		   follows:
		
		   o  The MaxRankIncrease field MUST be set to 0 to
disable local repair
		      of the temporary DAG.
		
		   o  This document RECOMMENDS a value 1 for the
MinHopRankInc field.
		
		   o  Objective Code Point (OCP): The OCP to be used for
temporary DAG
		      formation.  This document RECOMMENDS RPL Objective
Function 0, as
		      defined in [I-D.ietf-roll-of0], for use as the
objective function
		      for the formation of the temporary DAG.
		
		   A DIO, that contains a Route Discovery option with O
flag set, MUST
		   also contain a Metric Container option immediately
following the
		   Route Discovery option.  This Metric Container option
carries the
		   values for the routing metrics as well as the
constraints
		   (constituting the "good enough" criteria) used for
route selection.
		
		JP> This is confusing: the metric and constraint carried
within the Metric
		Container are used for the DODAG formation. Do you want
to use them
		for a different purpose ? At this point, you have not
yet defined the use of
		the good enough criteria but one can guess that you
would use the good
		enough metrics to control the flooding and the metric/OF
to effectively 
		build the temporary DAG and discover the routes. If so,
the good enough
		metrics are of different use.
		   Note that if O flag in the Route Discovery option is
clear, the OCP
		   and Metric Container used for temporary DAG formation
are used for
		   route selection as well.
		
		   A DIO, carrying a Route Discovery option, MUST not
carry any Route
		
		JP> s/MUST not/MUST NOT
		   Information or Prefix Information options described
in
		   [I-D.ietf-roll-rpl].
		
Option At An
		      Intermediate Node
		
		   The rules for DIO processing and transmission,
described in Section 7
		   of RPL [I-D.ietf-roll-rpl], apply to DIOs carrying a
Route Discovery
		   option as well except as modified in this document.
		
		   When an intermediate router joins a temporary DAG
advertized by a DIO
		   carrying the Route Discovery option, it MUST maintain
its membership
		   in the DAG for the Minimum Life Time duration listed
in the Route
		   Discovery option.  
		
		JP> What if it cannot ? Just not join the DAG and log an
error ?
		Maintaining membership in the DAG implies
		   remembering:
		
		   o  The RPLInstanceID, the DODAGID and the
DODAGVersionNumber for the
		      temporary DAG;

		
		JP> you mean the best path cost?
		along with the associated source route
		      from the initiator of route discovery till this
router (carried in
		      a Record Route IPv6 Extension Header proposed in
		      [I-D.thubert-6man-reverse-routing-header]), for
the Route

[Page 10]
		
		Internet-Draft          draft-dt-roll-p2p-rpl-01
June 2010

		      Discovery option being propagated by the temporary
DAG.  If the
		      router can not compare Metric Containers, it MUST
remember the
		      latest Metric Container it has received, along
with the associated
		      source route.
		
		JP> Requires clarification on what you mean by "compare"
		   A router belonging to a temporary DAG need not
remember the identity
		   of its DAG parents since the temporary DAG is not
used for routing.
		
		JP> Are you sure ? What is a hop-by-hop route is needed
? Don't you
		need to remember your parent, or do you still record the
route ?
		   The main purpose of a temporary DAG's existence is to
facilitate the
		   propagation of the Route Discovery option.
		
		   The router does not process a Route Discovery option,
contained in
		   the received DIO, any further if any of the following
conditions are
		   true:

		JP> and/or metrics
		being used for
		      route discovery
		
		   o  The router does not have sufficient information to
calculate the
		      relevant routing metrics/constraints in the right
direction (as
		      specified by the D field).
		
		   o  The S field is clear, i.e. hop-by-hop routes are
desired, but the
		      router can not participate in a hop-by-hop route.
		
		   o  The router is an intermediate router and the
router's rank in the
		      temporary DAG, calculated on the basis of the rank
and objective
		      function carried in the Base Object in the DIO,
exceeds the Max
		      Rank value specified in the Route Discovery
option.
		
		   A router MUST discard the DIO if the Route Discovery
option contained
		   in the message does not need further processing.  
		
		JP> Log an error ?
		Otherwise, the
		
		   The router updates the Metrics Container associated
with the received
		   Route Discovery option as per the specified objective
function.  
		
		JP> And routing metrics

		The
		   router may optionally check the Metric Container to
determine if the
		   aggregated values for the routing metrics meet all
the constraints
		   listed in the Metric Container.  
		
		JP> The aggregated values are for the metrics.
Constraints are used to
		prune potential path.
		If not, the Route Discovery option
		   is discarded 
		
		JP> You mean the DIO message.
		without further processing.  Otherwise, the router
		   updates its in-memory copy of the latest/best Metric
Container for
		   this Route Discovery option along with the associated
source route
		   updated in the correct direction (based on the D
field of the Route
		   Discovery option).  Any change in the in-memory copy
also requires
		   resetting the trickle timer and generating a new DIO
carrying the
		   Route Discovery option, the updated latest/best
Metric Container and
		   the associated source route (in a Record Route IPv6
extension header
		   proposed in
[I-D.thubert-6man-reverse-routing-header]) when the timer
		   fires.  
		
		JP> If the changes occur during the lifetime window.
		Note that the Metric Container MUST immediately follow
the

[Page 11]
		
		Internet-Draft          draft-dt-roll-p2p-rpl-01
June 2010

		   Route Discovery option if the O flag in the Route
Discovery option is
		   set.
		
		5.4.  Processing of a DIO Carrying a Route Discovery
Option At The
		      Target Router
		
		   When the target router joins the temporary DAG
advertized by a DIO
		   carrying the Route Discovery option, it MUST maintain
its membership
		   in the DAG for the Minimum Life Time duration listed
in the Route
		   Discovery option.  Maintaining membership in the DAG
implies
		   remembering:
		
		   o  The RPLInstanceID, the DODAGID and the
DODAGVersionNumber for the
		      temporary DAG;

		   The target router does not process a Route Discovery
option,
		   contained in the received DIO, any further if any of
the following
		   conditions are true:
		
used for route
		      discovery
		
		   o  The router does not have sufficient information to
calculate the
		      relevant routing metrics/constraints in the right
direction (as
		      specified by the D field).

		JP> or does not support the metric.
		The target router MUST discard the DIO if the Route
Discovery option contained in the message does not need further
processing.
		
		JP> ? How does it knows (simply because it reaches the
destination) ?
		   Otherwise, the Route Discovery option is processed as
follows.
		
		   The target router updates the Metrics Container
associated with the
		   received Route Discovery option as per the specified
objective
		   function.  

		The target router then checks the Metric Container to
		   determine if the aggregated values for the routing
metrics meet all
		   the constraints listed in the Metric Container.  

		If not, the Route
		   Discovery option is discarded without further
processing.  Otherwise,
		   the router MAY select the source route accumulated by
the received
		   DIO as one of the discovered routes.  
		
		JP> "MAY" ? When ?
		The target router MUST send one
		   or more RPL Control Messages carrying a Discovery
Reply Object
		   (defined in the next section) back to the origin
router (identified
		   by the DODAGID field in the DIO Base Object) as
discussed in the
		   following sections.
		
		   The target router MUST NOT forward a DIO carrying a
Route Discovery
		   option that lists one of its own addresses as the
Target Address.

		
[Page 12]
		
		Internet-Draft          draft-dt-roll-p2p-rpl-01
June 2010

		
		       0                   1                   2
3
		        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
4 5 6 7 8 9 0 1
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		       | RPLInstanceID |    Version    | D |S|  N  |
Reserved      |
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		       |
|
		       |                         DODAGID
|
		       |
|
		       |
|
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		       |
|
		       |                       Target Address
|
		       |
|
		       |
|
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
		       | Option(s)...
		       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

		           Figure 2: Format of the Discovery Reply
Object (DRO)
		
		   This document defines a new RPL Control Message type,
the Discovery
		   Reply Object (DRO) with code 0x04 (to be confirmed by
IANA), that
		   serves the following functions:
		
		   o  An acknowledgement from the target router to the
origin router
		      regarding the successful discovery of backward
source routes;

		JP> ACK of routes from the origin to the target: you may
not have routes
		in the opposite direction.
		   o  Carries one or more forward/bidirectional source
routes from the
		      target to the origin router;
		
		   o  Establishes a hop-by-hop
forward/backward/bidirectional route as
		      it travels from the target to the origin router.
		
		   The format for a Discovery Reply Object (DRO) is
shown in Figure 2.
		   A DRO consists of the following fields:
		
		   o  RPLInstanceID: The RPLInstanceID of the temporary
DAG used for
		      route discovery.
		
		   o  Version: The Version of the temporary DAG used for
route
		      discovery.

[Page 13]
		
		Internet-Draft          draft-dt-roll-p2p-rpl-01
June 2010

		   o  DODAGID: The DODAGID of the temporary DAG used for
route
		      discovery.  The DODAGID also identifies the origin
router.  The
		      RPLInstanceID, the Version and the DODAGID
together uniquely
		      identify the temporary DAG used for route
discovery and can be
		      copied from the Base Object of the DIO advertizing
the temporary
		      DAG.
		
		   o  D: A 2-bit field that indicates the direction of
the discovered
		      routes:
		
		      *  D = 0x00: Forward;
		
		      *  D = 0x01: Backward;

		      This field has the same value as the corresponding
field in the
		      Route Discovery option.
		
		   o  S: A flag that is clear if the Discovery Reply
Object is
		      establishing an hop-by-hop route.  The flag is set
if the
		      Discovery Reply Object carries (or is an
acknowledgement for the
		      discovery of) one or more source routes.
		
		   o  N: A 3-bit field that indicates the number of
source routes
		      carried or acknowledged in the Discovery Reply
Object.
		
		   o  Target Address: The IPv6 address of the target
router originating
		      the Discovery Reply Object.
		
		   o  Reserved: These bits are reserved for future use.
These bits MUST
		      be set to zero on transmission and MUST be ignored
on reception.
		
		   o  Options: The Discovery Reply Object MAY carry up
to 7 Source Route
		      options (defined in the next section) with each
such option
		      carrying a complete forward/bidirectional source
route and
		      optionally followed by a Metric Container option
that lists the
		      aggregated values for the routing metrics for the
source route.
		
		JP> This may not be an aggregated value but recorded
metric too.
		Goyal, et al. Expires December 16, 2010 [Page 14] 
Internet-Draft draft-dt-roll-p2p-rpl-01 June 2010 6.1.1. The Source
Route Option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type
= 10 | Option Length | Compr | Pad | Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | .
Addresses[1..n] . . . | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure
3: Format of the Source Route Option The Source Route option,
illustrated in Figure 3, carries a complete forward/bidirectional source
route from the target router to the origin router. A Source Route option
can only be a part of the Discovery Reply Object and MAY be immediately
followed by a Metric Container option that contains the aggregated
values of the routing metrics for this source route. A Route Discovery
option consists of the following fields: o Option Type = 0x0A (to be
confirmed by IANA). o Option Length = Variable, depending on the size of
the Addresses vector. o Compr: 4-bit unsigned interger indicating the
number of prefix octets that are elided from each address. For example,
Compr value will be 0 if full IPv6 addresses are carried in the
Addresses vector. o Pad: 4-bit unsigned integer. Number of octets that
are used for padding between Address[n] and the end of the Source Route
option. o Address[1..n]: Vector of addresses, numbered 1 to n. Each
vector element has size (16 - Compr) octets. A common network
configuration for an RPL domain is that all routers within an LLN share
a common prefix. The Source Route option uses the Compr field to allow
compaction of the Addresses[1..n] vector when all entries share the same
prefix as the DODAGID or the Target Address of the encapsulating
Discovery Reply Object. The shared prefix octets are not carried within
the Source Route option and each entry in Address[1..n] has size (16 -
Compr) octets. When Compr is Goyal, et al. Expires December 16, 2010
[Page 15]  Internet-Draft draft-dt-roll-p2p-rpl-01 June 2010 non-zero,
there may exist unused octets between the last entry, Address[n], and
the end of the Source Route option. The Pad field indicates the number
of unused octets that are used for padding. Note that when Compr is 0,
Pad MUST be null and carry a value 0. The Source Route option MUST NOT
specify a path that visits a router more than once. When generating a
Source Route option, the target router may not know the mapping between
IPv6 addresses and routers. Minimally, the target router MUST ensure
that: o The IPv6 Addresses do not appear more than once; o The IPv6
addresses of the origin and the target routers do not appear in the
Address vector; o The Address vector represents a source route in
forward direction with Address[1] being the next hop for the origin
router. Multicast addresses MUST NOT appear in a Source Route option. 

		JP> you may want to add a ref to RH4 since the format is
very similar.
		6.2.  DRO as Acknowledgement for Backward Source Routes
		
		   When a target router discovers a backward source
route, 
		
		JP> I have an issue with your terminology. When the
target receives the
		DIO with route discovery option, what is discovered is a
forward route ?

		it sends a
		   DRO message to the origin router as an acknowlegement
for the
		   discovered route.  Optionally, a target router MAY
send a DRO
		   acknowledgement to the origin router after
discovering multiple
		   backward source routes.  A DRO, serving as an
acknowledgement for
		   backward source route discovery, has its D field set
to 0x01
		   (indicating backward) while the S flag is set to 1
(indicating source
		   route).  The N field is set to indicate the number of
discovered
		   backward source routes being acknowledged.  Such a
DRO message MUST
		   NOT contain any option.
		
		   This document does not require a particular method
for sending such a
		   DRO message to the origin router.  The target router
MAY send the DRO
		   message to the origin router in any fashion,
including:
		
		   o  Using a source route carried in a Type 4 Routing
header
		      [I-D.hui-6man-rpl-routing-header];
		
		   o  Along any DAG connecting the target and the origin
routers;
		
		   o  Along the temporary DAG created for route
discovery, provided that
		      the target router is reasonably sure that the
DAG's life time is
		      sufficiently long and the routers in the DAG do
remember one or
		      more of their parents in the DAG.
		
		JP> You may want to explain a bit more why you the
origin router
		would be interested in receiving an ACK without the
route itself (case
		6.3): hop-by-hop routes.
		Goyal, et al. Expires December 16, 2010 [Page 16] 
Internet-Draft draft-dt-roll-p2p-rpl-01 June 2010 6.3. DRO as Carrier of
Forward/Bidirectional Source Routes When a target router discovers a
forward source route, 
		
		JP> Here, I agree that this is a forward route.
		it sends a DRO
		   message to the origin router carrying the discovered
source route
		   inside a Source Route option.  Similarly, when a
target router
		   discovers a bidirectional source route, it caches the
route for its
		   own use and then sends a DRO message to the origin
router carrying
		   the discovered route inside a Source Route option.
Rather than
		   immediately sending a discovered route back to the
origin router, a
		   target router MAY optionally send one DRO message
after discovering
		   multiple forward/bidirectional source routes with the
sent DRO
		   carrying the discovered source routes (in multiple
Source Route
		   options).
		
		JP> Note that the algorithm for "best route" selection
is outside the scope
		of this document, so does the use of a timer on the
target side to determine
		how much time to wait before answering, ... 
		A DRO message carrying one or more Source Route options
MUST have its D field set to 0x00 (for forward routes) or 0x02 (for
bidirectional routes). The S flag MUST be set to 1 and the N field MUST
indicate the number of Source Route options in the message. A Source
Route option MAY immediately be followed by a Metric Container option
that carries the aggregated 
		
		JP> or recorded
		values of the routing metrics for this source
		   route.  The target router may send this DRO message
to the origin
		   router in any fashion it desires including the
options listed in
		   Section 6.2.

		   In order to establish a hop-by-hop route, the target
router sends a
		   DRO message along the reverse of the discovered route
(via a Type 4
		   Routing Header specified in
[I-D.hui-6man-rpl-routing-header]).  The
		   D field of the message is set to convey the route's
direction
		   (forward/backward/bidirectional) and the S flag MUST
be clear
		   (indicating hop-by-hop).  The N field MUST be set to
1.  Such a DRO
		   MUST NOT contain any option.
		
		   A router receiving such a DRO message SHOULD
establish hop-by-hop
		   state in the right direction corresponding to the
route carried in
		   the Type 4 Routing Header of the DRO message.  If a
router does not
		   establish such state, it MUST drop the DRO message.
Otherwise, it
		   MUST forward the DRO message along the source route
contained in Type
		   4 Routing Header of the received message.

		JP> Any error log if it does not ? (optional) ICMP sent
to the target node?
		   A router SHOULD associate the hop-by-hop routing
state, thus
		   established, with the objective function and metrics
used for route
		   discovery.

		
		
[Page 17]
		
		Internet-Draft          draft-dt-roll-p2p-rpl-01
June 2010

		JP> New section to indicate how to clean-up the
temporary DAG ?
		7.  Security Considerations
		
		   TBA

		8.  IANA Considerations
		
		   TBA

		   In addition to the editor, the authors of this
document include the
		   following individuals (listed in alphabetical order).
		
		   Anders Brandt, Sigma Designs, Emdrupvej 26A, 1.,
Copenhagen, Dk-2100,
		   Denmark.  Phone: +45 29609501; Email: [email-masked]
		
		   Robert Cragie, Gridmerge Ltd, 89 Greenfield Crescent,
Wakefieldm WF4
		   4WA, UK.  Phone: +44 1924910888; Email:
[email-masked]
		
		   Jerald Martocci, Johnson Controls, Milwaukee, WI
53202, USA.  Phone:
		   +1 414 524 4010; Email:[email-masked]
		
		   Charles Perkins, Tellabs Inc., USA.
Email:[email-masked]
		
		   Authors gratefully acknowledge the contributions of
Richard Kelsey
		   and Zach Shelby in the development of this document.

		10.  References

		   [RFC2119]  Bradner, S., "Key words for use in RFCs to
Indicate
		              Requirement Levels", BCP 14, RFC 2119,
March 1997.

		   [I-D.brandt-roll-rpl-applicability-home-building]
		              Brandt, A., Baccelli, E., and R. Cragie,
"Applicability
		              Statement: The use of RPL in Building and
Home
		              Environments",
	
draft-brandt-roll-rpl-applicability-home-building-00 (work
		              in progress), April 2010.
		
		   [I-D.hui-6man-rpl-routing-header]
		              Hui, J., Vasseur, J., and D. Culler, "A
Source Routing

[Page 18]
		
		Internet-Draft          draft-dt-roll-p2p-rpl-01
June 2010

		              Header for RPL",
draft-hui-6man-rpl-routing-header-00
		              (work in progress), May 2010.
		
		   [I-D.ietf-roll-building-routing-reqs]
		              Martocci, J., Riou, N., Mil, P., and W.
Vermeylen,
		              "Building Automation Routing Requirements
in Low Power and
		              Lossy Networks",
draft-ietf-roll-building-routing-reqs-09
		              (work in progress), January 2010.
		
		   [I-D.ietf-roll-of0]
		              Thubert, P., "RPL Objective Function 0",
		              draft-ietf-roll-of0-02 (work in progress),
June 2010.
		
		   [I-D.ietf-roll-routing-metrics]
		              Vasseur, J., Kim, M., Networks, D., and H.
Chong, "Routing
		              Metrics used for Path Calculation in Low
Power and Lossy
		              Networks",
draft-ietf-roll-routing-metrics-07 (work in
		              progress), June 2010.
		
		   [I-D.ietf-roll-rpl]
		              Winter, T., Thubert, P., and R. Team,
"RPL: IPv6 Routing
		              Protocol for Low power and Lossy
Networks",
		              draft-ietf-roll-rpl-09 (work in progress),
June 2010.
		
		   [I-D.ietf-roll-terminology]
		              Vasseur, J., "Terminology in Low power And
Lossy
		              Networks", draft-ietf-roll-terminology-03
(work in
		              progress), March 2010.

		
		   [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home
Automation
		              Routing Requirements in Low-Power and
Lossy Networks",
		              RFC 5826, April 2010.

		

		

[Page 19]
		
		Internet-Draft          draft-dt-roll-p2p-rpl-01
June 2010

		Authors' Addresses
		
		   Mukul Goyal (editor)
		
		   Phone: +1 414 2295001
		   Email: [email-masked]

		   Phone: +33-169-335-511

		   P2P Team

---

From: "Anders Brandt" <[email-masked]>
Date: Wed, 16 Jun 2010 13:13:12 +0200

Comments inline
 
Cheers,
  Anders

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of JP Vasseur
	Sent: Wednesday, June 16, 2010 12:00
	To: Mukul Goyal; Emmanuel Baccelli
	Cc: ROLL WG
	Subject: [Roll] Comments on draft-dt-roll-p2p-rpl-01

	Dear authors,

	Since I had a number of comments I inserted them in the ID
itself. As you will notice:
	1) Some of them are purely editorial
	2) Others are more fundamental and may require just
clarifications, more discussion on the mailing list, ... In this case,
feel free to start a separate thread (note that ticket cannot be
assigned to non WG document).
	3) I also suggested new sections

	Internet Engineering Task Force                            M.
Goyal, Ed.
	Internet-Draft                         University of Wisconsin
Milwaukee
	Intended status: Informational                          E.
Baccelli, Ed.

	
P2P. Team
	                                                           June
14, 2010

	   Reactive Discovery of Point-to-Point Routes in Low Power and
Lossy
	                                Networks
	                        draft-dt-roll-p2p-rpl-01
	
	Abstract
	
	   This document describes a mechanism to discover and establish
"on
	   demand" one or more routes between two routers in a low power
and
	   lossy network.

	JP> Needs a bit more details + explicitly refer to IPv6 in the
abstract 
	and introduction.

	The DAG root initiates the DAG formation by originating
	   a DODAG Information Object (DIO) message.  The DIO message is
sent
	   via link-local multicast and carries information about the
	   originating router's position (the "rank") in the DAG.  On
receiving
	   DIO messages sent by its neighbors, a router determines its
own
	   "rank" in the DAG and originates its own DIO message.

	JP> Without going too much in the details, you may just want to
add
	that a node decides to join a DODAG according to a number of
parameters
	(identity of the DODAG, OF, routing/constraints a specified in
the metric-ID,...).
	   RPL enables point-to-multipoint (P2MP) routing from a router
to its
	   descendants in the DAG by allowing a router to send a
Destination
	   Advertisement Object (DAO) upwards along the DAG.  The DAO
carries
	   the aggregated 

	
	JP> Yes.
	If the destination is within the
	   source's "range", the source may directly send packets to the
	   destination.  Otherwise, if the destination is a DAG
descendant and
	   the source maintains "downwards" routing state about this
descendant,
	   it can forward the packet along this route.  Otherwise, the
source
	   sends the packet to a DAG parent, which then applies the same
set of
	   rules to forward the packet further.  Thus, a packet travels
up the
	   DAG until it reaches a router that knows of the downwards
route to
	   the destination and then it travels down the DAG towards its
	   destination.  A router may or may not maintain routing state
about a
	   descendant depending on whether its immediate children send
it such
	   information in their DAOs and whether the router can store
this
	   information.  Thus, in the best case scenario, the "upwards"
segment
	   of the P2P route between a source and a destination ends at
the first
	   common ancestor of the source and the destination.  In the
worst
	   case, the "upwards" segment would extend all the way to the
DAG's
	   root.  If the destination did not originate a DAO, the packet
will
	   travel all the way to the DAG's root, where it will be
dropped.

	JP> This may require to be a bit more accurate here. If there is
no DAO,
	there RPL is used for MP2P routing only (that is not a protocol
design 
	characteristic though). 
	   The P2P routing functionality available in RPL suffers from
several
	   shortcomings
[I-D.brandt-roll-rpl-applicability-home-building]:

	JP> "suffering from several shortcomings" is a bit strong
though. You may
	want to say that additional mechanisms may be required to
address specific
	situation and list them.  

[ABR:]
I think that the wording is adequate and nobody objected to the
conclusions of the applicability draft so far.
The applicability draft evaluates the usefulness of the current RPL
proposal and concludes that
basic requirements are not met for home and building application spaces.

	   o  The need to maintain routes "proactively", i.e. every
possible
	      destination in the DAG must originate a DAO.
	
	   o  The constraint to route only along a DAG potentialy
leading to
	      significantly suboptimal P2P routes and traffic congestion
near
	      the DAG root.
	
	JP> 
	Second bullet: just to be very accurate, mention that the route
may be sub-optimal.
	
	JP> Again, to be accurate, there are no MUST requirements listed
in
	these ID that are not satisfied by RPL (with regards to the
aforementioned
	issues). I am NOT saying that the proposed mechanism is not
useful 
	(by all means), just that the statement above is not correct. 

[ABR:]
I have to disagree.
 
RFC5826 says: 
The routing protocol MUST converge within 0.5 seconds if no nodes
   have moved (see Section 3.2 <outbind://43/#section-3.2>  for
motivation).

   The routing protocol MUST converge within four seconds if nodes have
   moved to re-establish connectivity within a time that a human
   operator would find tolerable as, for example, when moving a remote
   control unit.

	Such applications require a
	   mechanism providing source-initiated discovery of P2P routes
that are
	   not along a DAG.  

[ABR:]
I have to disagree.
If I am looking for a light module and the DAG states represent broken
paths, I have a requirement for
source-initiated discovery. I cannot wait for the RPL DAG timers to
fire. 

	   The specified scheme is based on a reactive on-demand
approach, which
	   enables a router to discover one or more "good-enough" routes
in
	   either direction between itself and another router in the LLN
without
	   any constraints regarding the existing DAG-membership of the
links
	   that such routes may use.  
	
	JP> This will be an aspect triggering some discussion. How
"good" is
	"good enough" ? You will need some text to elaborate here or
point 
	to another section explaining what is meant by "good enough"
	Such routes may be source-routes or hop-
	   by-hop ones.  
	
	JP> Just terminology: instead of referring to hop-by-hop routes,
you may
	want to say that once a route has been computed between two
nodes in 
	the network, IPv6 packet may be forward using a source routing
mechanism
	as specified in [XX] or in a hop by hop fashion.
	A complementary functionality, necessary to help decide
	   whether to initiate a route discovery, is a mechanism to
measure the
	   end-to-end cost of an existing route.  
	
	JP> s/cost/path cost

	

[ABR:]
 
Good point

	3.  Terminology
	
	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT",
	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and
	   "OPTIONAL" in this document are to be interpreted as
described in

	

	   [RFC2119].
	
	   Additionally, this document uses terminology from
	   [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl], and
introduces
	   the following terminology:
	
	   Origin Router: The router initiating the route discovery.
The origin
	   router acts as one end point of the routes to be discovered.
	
	   Target Router: The other end point of the routes to be
discovered.
	
	   Intermediate Router: A router that is neither the origin nor
the
	   target.
	
	   Forward Route: A route from the origin router to the target
router.
	
	   Backward Route: A route from the target router to the origin
router.

	   Source Route: A complete and ordered list of routers that can
be used
	   by a packet to travel from a source to a destination.  Such
source
	   routes can be carried by a packet in a proposed Type 4
Routing Header
	   [I-D.hui-6man-rpl-routing-header].
	
	   Hop-by-hop Route: A route from a source to a destination
where each
	   router in the route knows only the address of the next hop on
the
	   route.
	
	JP> I would suggest to change the definition for "routing
paradigm
	whereby packets are routed from their source to destination by 
	on a hop by hop basis where the packets is routed by a set of
routers
	along the path according to the routing table stored by each
router
	along the path".
	   In this document, the term 'router' refers to any LLN device
that can
	   forward packets generated at other devices.

	4.  Functional Overview
	
	   Router A originates a "Discovery" message listing router B as
the
	   target.  Node A also indicates in the message:

	JP> This may de detailed hereafter but I guess that you will
point to 
	the metric-ID for the metric used?

	   o  The direction (forward: router A to router B; backward:
router B
	      to router A; or both) of the route being discovered;

	
	
	

	   o  Whether the route is a source-route or a hop-by-hop one;
and
	
	   o  A limit on the "distance" the Discovery message may
travel.

	JP> Need to define the term "distance": is it a max path cost,
number of
	hops, ... ?
	The Discovery message propagates via link-local multicast 
	
	JP> Indicate "IPv6"
	with each
	   receiving router making the decision regarding whether to
forward the
	   message further based on the "distance" (from router A) that
this
	   particular copy of the message has already traveled.  Note
that this
	   document does not require a receiving router to use the "good
enough"
	   criteria to make the forwarding decision.  This is because
the
	   evaluation of such criteria may be too complex for a
constrained
	   intermediate router to perform for each received copy of the
	   Discovery message.  
	
	JP> So I guess that you define later what to do in both cases
(the node
	cannot process the "good enough" criteria or it can process it)
?
	The calculation of the "distance" that a copy of
	   the Discovery message has already travelled should be simple
enough
	   for a constrained router to perform.  
	
	   not to forward a copy of the Discovery message further
	
	JP> You will nee to be more specific here. Is it a "may" or a
"MAY". 
	Define what happens in this case. You may provide more details
later
	in the document.
	   The underlying mechanism being used to propagate the
Discovery
	   message may put further restrictions on its propagation.  A
router
	   should not propagate the Discovery message further if
hop-by-hop
	   routes are desired and the router can not store state for
this route.
	
	   As a copy of the Discovery message travels towards router B,
it
	   accumulates the relevant forward/backward costs as well as
the route
	   it takes.  When router B receives a copy of the Discovery
message, it
	   determines whether the route traveled by the message meets
the "good
	   enough" criteria.

	JP> Didn't you mean "forward" ?
	   router B caches one or more good enough source-routes it
identifies.
	   Additionally, router B sends one or more "Discovery Reply"
message to
	   router A to acknowledge the discovery of these routes.  These
	   acknowledgements allow router A to judge the success of the
route
	   discovery.  The Discovery Reply messages can travel towards
router A
	   in any manner chosen by router B. For example, router B may
source-
	   route the messages or send them towards router A along a DAG.
	
	   If router A had requested the discovery of "n" forward
source-routes,
	   router B sends the "n" good enough source-routes it
identifies to
	   router A in one or more Discovery Reply messages.  Again,
these
	   Discovery Reply messages can travel towards router A in any
manner
	   chosen by router B.
	
	JP> What if the DAG is "broken": retry from A after expiration
of a local
	timer ?
	   If router A had requested the discovery of "n" bidirectional
source-
	   routes, router B caches the "n" good enough source-routes it
	   identifies and also sends these routes to router A in one or
more
	   Discovery Reply messages.  These Discovery Reply messages can
travel
	   towards router A in any manner chosen by router B.

	

	   If router A had requested the discovery of "n"
forward/backward/
	   bidirectional hop-by-hop routes, router B sends out a
Discovery Reply
	   message to router A for each one of the "n" good enough
routes it
	   identifies.  
	
	JP> Do you need one "Discovery Reply message" per route or
next-hop
	in this case?
	The Discovery Reply message travels towards router A
	   using the source-route accumulated by the Discovery message.

	JP> In the case of hop-by-hop routes, source routes, both ?
	As this
	   message travels towards router A, it establishes appropriate
forward/
	   backward routing state in the en-route routers.  This "non
DAG"
	   routing state should be specially marked to associate it with
the
	   routing metrics 
	
	JP> Refer to metric ID ?
	used to discover the route and to distinguish such
	   state from other DAG-specific routing state the router may
have.
	
	JP> Not sure that you need to distinguish the state. Suppose
that you
	discover a hop-by-hop route (not a big fan of that terms as
pointed out
	above but let's continue to use it for the time being), a
storing node
	may indeed have two routes for the same destination: do you want
to
	state that it should always use the P2P routes discovered by
this
	mechanism or let it choose the best one according to the metric
in
	use?

	
	   RPL uses DIO message propagation to build a DAG.  The DIO
message
	   travels via link-local multicast.  

	Each router joining the DAG
	   determines a rank for itself and ignores the subsequent DIO
messages
	   received from lower (higher in numerical value) ranked
neighbors.
	   Thus, the DIO messages propagate outwards rather than return
inwards
	   towards the DAG root.  

	The DIO message generation at a router is
	   further controlled by a trickle timer that allows a router to
avoid
	   generating unnecessary messages.  

	The link-local multicast based
	   propagation, trickle-controlled generation and the rank-based
	   poisoning of messages traveling in the wrong direction
(towards the
	   DAG root) provide powerful incentives to use the DIO message
as the
	   Discovery message and propagate the DIO/Discovery message by
creating
	   a "temporary" DAG.

	       0                   1                   2
3
	        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
8 9 0 1

	

	   In order to be used as a Discovery message, a DIO MUST carry
a "Route
	   Discovery" option illustrated in Figure 1.  A DIO MUST NOT
carry more

	

	
	
	   o  Option Length = 20 or 22 octets depending on whether the
OCP field
	      is included or not.
	
	   o  D: A 2-bit field that indicates the direction of the
desired
	      routes:
	
	      *  D = 0x00: Forward;
	
	      *  D = 0x01: Backward;

	   o  S: A flag that indicates whether source routes are
desired.  The
	      flag is set if the source routes are desired.  The flag is
clear
	      if hop-by-hop routes are desired.
	
	   o  N: A 3-bit unsigned integer indicating the number of
routes
	      desired.
	
	   o  L: A 2-bit field indicating the minimum "Life Time" of the
	      temporary DAG, i.e., the minimum duration a router joining
the
	      temporary DAG must maintain its membership in the DAG:

	

	
	JP> Placeholder ... indicate what happens if a node cannot store
that
	additional state (add a manageability section).
	   o  O: A flag that indicates whether the same OCP is used for
route
	      discovery as well as temporary DAG formation.  If this
flag is
	      clear, the OCP contained in the DODAG Configuration option
in the
	      DIO is used for route discovery as well.  Otherwise, the
OCP
	      specified in the Route Discovery option is used for route
	      selection 

	
	JP> Since OF is decoupled from metrics, you always need to
indicate
	the metric in use. That said, I do not see your point here.
Indeed, the 
	temporary DAG is built according to some OF and metrics so the 
	resulting routes will inherit these metrics?
	   o  Max Rank: A 7-bit unsigned integer that indicates the
maximum rank
	      allowed in the temporary DAG advertised by the DIO
message.  This
	      upper limit on the DAG rank serves as the "distance"
referred to

	

	      in Section 4 and provides a control over how far the Route
	      Discovery option contained in the DODAG Configuration
option in
	      the DIO message may travel.  
	
	JP> You may discuss it later in this document ... but the
distance is tied
	to how you compute the rank.
	A router MUST not 
	
	JP> s/MUST not/MUST NOT
	join the temporary
	      DAG if its rank in the DAG will exceed this limit.  Later
versions
	      of this draft will map the 128 value space available in
this field
	      to 16-bit long limits on the DAG rank.

	   o  OCP: 16 bit unsigned integer.  An optional field, present
only if
	      the O flag is set, that indicates the objective code point
(OCP)
	      to be used for route selection.

	   A DIO message that carries a Route Discovery option MUST set
the Base
	   Object, described in [I-D.ietf-roll-rpl], in the following
manner:

	   o  Grounded (G) Flag: MUST be clear since the objective of
DAG
	      formation is the propagation of Route Discovery option.
This DAG
	      is temporary in nature and is not used for routing
purpose.
	
	   o  Destination Advertisement Supported (A) Flag: MUST be
clear for
	      same reasons as described above.

	   o  Mode of Operation (MOP): Since the temporary DAG is not to
be used
	      for routing purposes, the value of this field is
immaterial.  To
	      allow constrained routers to join the DAG, the MOP field
SHOULD be
	      set to 00 (non-storing).

	
	   o  Destination Advertisement Trigger Sequence Number (DTSN):
TBD

	
	JP> Origin router.
	
	   The DODAG Configuration option, carried in the DIO message,
specifies
	   the parameters for the trickle timer operation that governs
the
	   generation of DIO messages by the routers joining the
temporary DAG.

	JP> Also according to RPL ID or would you recommend different
	default values ? Default values for RPL are TBD but we could
easily
	think of different values in this case. To be revisited in the
future.

	

	   The other fields defined in the DODAG Configuration option
are set as
	   follows:
	
	   o  The MaxRankIncrease field MUST be set to 0 to disable
local repair
	      of the temporary DAG.
	
	   o  This document RECOMMENDS a value 1 for the MinHopRankInc
field.
	
	   o  Objective Code Point (OCP): The OCP to be used for
temporary DAG
	      formation.  This document RECOMMENDS RPL Objective
Function 0, as
	      defined in [I-D.ietf-roll-of0], for use as the objective
function
	      for the formation of the temporary DAG.
	
	   A DIO, that contains a Route Discovery option with O flag
set, MUST
	   also contain a Metric Container option immediately following
the
	   Route Discovery option.  This Metric Container option carries
the
	   values for the routing metrics as well as the constraints
	   (constituting the "good enough" criteria) used for route
selection.
	
	JP> This is confusing: the metric and constraint carried within
the Metric
	Container are used for the DODAG formation. Do you want to use
them
	for a different purpose ? At this point, you have not yet
defined the use of
	the good enough criteria but one can guess that you would use
the good
	enough metrics to control the flooding and the metric/OF to
effectively 
	build the temporary DAG and discover the routes. If so, the good
enough
	metrics are of different use.
	   Note that if O flag in the Route Discovery option is clear,
the OCP
	   and Metric Container used for temporary DAG formation are
used for
	   route selection as well.
	
	   A DIO, carrying a Route Discovery option, MUST not carry any
Route
	
	JP> s/MUST not/MUST NOT
	
	5.3.  Processing of a DIO Carrying a Route Discovery Option At
An
	      Intermediate Node
	
	   The rules for DIO processing and transmission, described in
Section 7
	   of RPL [I-D.ietf-roll-rpl], apply to DIOs carrying a Route
Discovery
	   option as well except as modified in this document.
	
	   When an intermediate router joins a temporary DAG advertized
by a DIO
	   carrying the Route Discovery option, it MUST maintain its
membership
	   in the DAG for the Minimum Life Time duration listed in the
Route
	   Discovery option.  

	   o  The RPLInstanceID, the DODAGID and the DODAGVersionNumber
for the
	      temporary DAG;

	

	

	      Discovery option being propagated by the temporary DAG.
If the
	      router can not compare Metric Containers, it MUST remember
the
	      latest Metric Container it has received, along with the
associated
	      source route.
	
	JP> Requires clarification on what you mean by "compare"
	   A router belonging to a temporary DAG need not remember the
identity
	   of its DAG parents since the temporary DAG is not used for
routing.
	
	JP> Are you sure ? What is a hop-by-hop route is needed ? Don't
you
	need to remember your parent, or do you still record the route ?

[ABR:] 
I would guess that neighboring information could be used by the node to
update the neighbor caches
for the "normal" DODAGs that the nodes already use.
The temporary DODAGID is mainly a unique handle for the discovery
session to avoid loops and control
the number of transmissions by an individual node during the discovery
time window.

	
	
	JP> and/or metrics
	being used for
	      route discovery

	   o  The S field is clear, i.e. hop-by-hop routes are desired,
but the
	      router can not participate in a hop-by-hop route.
	
	   o  The router is an intermediate router and the router's rank
in the
	      temporary DAG, calculated on the basis of the rank and
objective
	      function carried in the Base Object in the DIO, exceeds
the Max
	      Rank value specified in the Route Discovery option.

	JP> Log an error ?
	Otherwise, the

	JP> And routing metrics

	The
	   router may optionally check the Metric Container to determine
if the
	   aggregated values for the routing metrics meet all the
constraints
	   listed in the Metric Container.  
	
	JP> The aggregated values are for the metrics. Constraints are
used to
	prune potential path.
	If not, the Route Discovery option
	   is discarded 
	
	JP> You mean the DIO message.
	without further processing.  Otherwise, the router
	   updates its in-memory copy of the latest/best Metric
Container for
	   this Route Discovery option along with the associated source
route
	   updated in the correct direction (based on the D field of the
Route
	   Discovery option).  Any change in the in-memory copy also
requires
	   resetting the trickle timer and generating a new DIO carrying
the
	   Route Discovery option, the updated latest/best Metric
Container and
	   the associated source route (in a Record Route IPv6 extension
header
	   proposed in [I-D.thubert-6man-reverse-routing-header]) when
the timer
	   fires.  

	
	

	5.4.  Processing of a DIO Carrying a Route Discovery Option At
The
	      Target Router
	
	   When the target router joins the temporary DAG advertized by
a DIO
	   carrying the Route Discovery option, it MUST maintain its
membership
	   in the DAG for the Minimum Life Time duration listed in the
Route
	   Discovery option.  Maintaining membership in the DAG implies
	   remembering:
	
	   o  The RPLInstanceID, the DODAGID and the DODAGVersionNumber
for the
	      temporary DAG;

	   The target router does not process a Route Discovery option,
	   contained in the received DIO, any further if any of the
following
	   conditions are true:
	
	   o  The router does not support the objective function used
for route
	      discovery

	

[ABR:]
 
e.g. if the updated rank exceeds the limit, i.e. "TTL == 0"

	   The target router updates the Metrics Container associated
with the
	   received Route Discovery option as per the specified
objective
	   function.  

	The target router then checks the Metric Container to
	   determine if the aggregated values for the routing metrics
meet all
	   the constraints listed in the Metric Container.  

	If not, the Route
	   Discovery option is discarded without further processing.
Otherwise,
	   the router MAY select the source route accumulated by the
received
	   DIO as one of the discovered routes.  
	
	JP> "MAY" ? When ?
	The target router MUST send one
	   or more RPL Control Messages carrying a Discovery Reply
Object
	   (defined in the next section) back to the origin router
(identified
	   by the DODAGID field in the DIO Base Object) as discussed in
the
	   following sections.
	
	   The target router MUST NOT forward a DIO carrying a Route
Discovery
	   option that lists one of its own addresses as the Target
Address.

	
	

	
	       0                   1                   2
3
	        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
8 9 0 1

	

	
	   This document defines a new RPL Control Message type, the
Discovery
	   Reply Object (DRO) with code 0x04 (to be confirmed by IANA),
that
	   serves the following functions:
	
	   o  An acknowledgement from the target router to the origin
router
	      regarding the successful discovery of backward source
routes;

	JP> ACK of routes from the origin to the target: you may not
have routes
	in the opposite direction. 

[ABR:]
True - and in that case, the requester most likely retries the
discovery. Randomization causes other
routes to be found in the second attempt - or the the "B" node also
starts a discovery.
I agree that the doc should be clearer on this aspect.

	   o  Carries one or more forward/bidirectional source routes
from the
	      target to the origin router;
	
	   o  Establishes a hop-by-hop forward/backward/bidirectional
route as
	      it travels from the target to the origin router.
	
	   The format for a Discovery Reply Object (DRO) is shown in
Figure 2.
	   A DRO consists of the following fields:
	
	   o  RPLInstanceID: The RPLInstanceID of the temporary DAG used
for
	      route discovery.

	

	

	   o  DODAGID: The DODAGID of the temporary DAG used for route
	      discovery.  The DODAGID also identifies the origin router.
The
	      RPLInstanceID, the Version and the DODAGID together
uniquely
	      identify the temporary DAG used for route discovery and
can be
	      copied from the Base Object of the DIO advertizing the
temporary
	      DAG.
	
	   o  D: A 2-bit field that indicates the direction of the
discovered
	      routes:
	
	      *  D = 0x00: Forward;
	
	      *  D = 0x01: Backward;

	      This field has the same value as the corresponding field
in the
	      Route Discovery option.
	
	   o  S: A flag that is clear if the Discovery Reply Object is
	      establishing an hop-by-hop route.  The flag is set if the
	      Discovery Reply Object carries (or is an acknowledgement
for the
	      discovery of) one or more source routes.
	
	   o  N: A 3-bit field that indicates the number of source
routes
	      carried or acknowledged in the Discovery Reply Object.
	
	   o  Target Address: The IPv6 address of the target router
originating
	      the Discovery Reply Object.
	
	   o  Reserved: These bits are reserved for future use.  These
bits MUST
	      be set to zero on transmission and MUST be ignored on
reception.
	
	   o  Options: The Discovery Reply Object MAY carry up to 7
Source Route
	      options (defined in the next section) with each such
option
	      carrying a complete forward/bidirectional source route and
	      optionally followed by a Metric Container option that
lists the
	      aggregated values for the routing metrics for the source
route.

	JP> you may want to add a ref to RH4 since the format is very
similar.
	6.2.  DRO as Acknowledgement for Backward Source Routes

	JP> I have an issue with your terminology. When the target
receives the
	DIO with route discovery option, what is discovered is a forward
route ?

	it sends a
	   DRO message to the origin router as an acknowlegement for the
	   discovered route.  Optionally, a target router MAY send a DRO
	   acknowledgement to the origin router after discovering
multiple
	   backward source routes.  A DRO, serving as an acknowledgement
for
	   backward source route discovery, has its D field set to 0x01
	   (indicating backward) while the S flag is set to 1
(indicating source
	   route).  The N field is set to indicate the number of
discovered
	   backward source routes being acknowledged.  Such a DRO
message MUST
	   NOT contain any option.
	
	   This document does not require a particular method for
sending such a
	   DRO message to the origin router.  The target router MAY send
the DRO
	   message to the origin router in any fashion, including:

	
	   o  Along the temporary DAG created for route discovery,
provided that
	      the target router is reasonably sure that the DAG's life
time is
	      sufficiently long and the routers in the DAG do remember
one or
	      more of their parents in the DAG.
	
	would be interested in receiving an ACK without the route itself
(case
	
	JP> Here, I agree that this is a forward route.
	it sends a DRO
	   message to the origin router carrying the discovered source
route
	   inside a Source Route option.  Similarly, when a target
router
	   discovers a bidirectional source route, it caches the route
for its
	   own use and then sends a DRO message to the origin router
carrying
	   the discovered route inside a Source Route option.  Rather
than
	   immediately sending a discovered route back to the origin
router, a
	   target router MAY optionally send one DRO message after
discovering
	   multiple forward/bidirectional source routes with the sent
DRO
	   carrying the discovered source routes (in multiple Source
Route
	   options).
	
	JP> Note that the algorithm for "best route" selection is
outside the scope
	of this document, so does the use of a timer on the target side
to determine
	how much time to wait before answering, ...  

[ABR:]
Well, if I am in a hurry, I can live with the best enough route, i.e.
the first one received, while in
other cases, I can accept waiting for some time to get a number of
backup routes in the same message.

	JP> or recorded
	values of the routing metrics for this source
	   route.  The target router may send this DRO message to the
origin
	   router in any fashion it desires including the options listed
in
	   Section 6.2.

	   In order to establish a hop-by-hop route, the target router
sends a
	   DRO message along the reverse of the discovered route (via a
Type 4
	   Routing Header specified in
[I-D.hui-6man-rpl-routing-header]).  The
	   D field of the message is set to convey the route's direction
	   (forward/backward/bidirectional) and the S flag MUST be clear
	   (indicating hop-by-hop).  The N field MUST be set to 1.  Such
a DRO
	   MUST NOT contain any option.
	
	   A router receiving such a DRO message SHOULD establish
hop-by-hop
	   state in the right direction corresponding to the route
carried in
	   the Type 4 Routing Header of the DRO message.  If a router
does not
	   establish such state, it MUST drop the DRO message.
Otherwise, it
	   MUST forward the DRO message along the source route contained
in Type
	   4 Routing Header of the received message.

	JP> Any error log if it does not ? (optional) ICMP sent to the
target node?
	   A router SHOULD associate the hop-by-hop routing state, thus
	   established, with the objective function and metrics used for
route
	   discovery.

	
	
	

	   TBA

	8.  IANA Considerations
	
	   TBA

	   In addition to the editor, the authors of this document
include the
	   following individuals (listed in alphabetical order).

	
	   Jerald Martocci, Johnson Controls, Milwaukee, WI 53202, USA.
Phone:
	   +1 414 524 4010; Email:[email-masked]

	   Authors gratefully acknowledge the contributions of Richard
Kelsey
	   and Zach Shelby in the development of this document.

	10.  References

	

	
	   [I-D.hui-6man-rpl-routing-header]
	              Hui, J., Vasseur, J., and D. Culler, "A Source
Routing

	

	              Header for RPL",
	
	              "Building Automation Routing Requirements in Low
Power and
	
	   [I-D.ietf-roll-of0]
	              Thubert, P., "RPL Objective Function 0",
	              draft-ietf-roll-of0-02 (work in progress), June
2010.
	
	   [I-D.ietf-roll-routing-metrics]
	              Vasseur, J., Kim, M., Networks, D., and H. Chong,
"Routing
	              Metrics used for Path Calculation in Low Power and
Lossy
	              Networks", draft-ietf-roll-routing-metrics-07
(work in
	              progress), June 2010.
	
	   [I-D.ietf-roll-rpl]
	              Winter, T., Thubert, P., and R. Team, "RPL: IPv6
Routing
	              Protocol for Low power and Lossy Networks",
	              draft-ietf-roll-rpl-09 (work in progress), June
2010.

	   [I-D.thubert-6man-reverse-routing-header]
	              Thubert, P., "Reverse Routing Header",
	              draft-thubert-6man-reverse-routing-header-00 (work
in
	              progress), June 2010.
	
	   [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home
Automation
	              Routing Requirements in Low-Power and Lossy
Networks",
	              RFC 5826, April 2010.

	

	

	

	Authors' Addresses
	
	   Mukul Goyal (editor)
	
	   Phone: +1 414 2295001
	   Email: [email-masked]

	   Phone: +33-169-335-511

	   P2P Team

---

From: JP Vasseur <[email-masked]>
Date: Wed, 16 Jun 2010 15:05:52 +0200

Replying to where you replied (note that these are not the most  
important points that I raised but Mukul already said that he would  
start threads on the list).

On Jun 16, 2010, at 1:13 PM, Anders Brandt wrote:

> Comments inline
>
> Cheers,
>   Anders
>
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of JP Vasseur
It is just important to properly position the two. What you call the  
applicability ID, which
is a mix of problem statement and applicability document (still a good  
document !!) is
not even a WG document at this point. What I was proposing is a softer  
language, which
is IMO appropriate in this case. But again, what matters is to  
continue to keep moving
forward, this is why I made a detailed review.
>    have moved (see Section 3.2 for motivation).
>
Not quibbling at all. But to be perfectly accurate this does not  
translate into "a reactive protocol
is needed". Once again (not to make sure that there is no confusion),  
I am not trying to say that
this complementary mechanism is not useful.
> If I am looking for a light module and the DAG states represent  
> broken paths, I have a requirement for
We could argue but let's focus on the mechanisms and make it work.
> I would guess that neighboring information could be used by the node  
> to update the neighbor caches
> the number of transmissions by an individual node during the  
> discovery time window.

JP> This just needs to be spelled out.
> e.g. if the updated rank exceeds the limit, i.e. "TTL == 0"
JP> Same comment

> Well, if I am in a hurry, I can live with the best enough route,  
> i.e. the first one received, while in
> its D field set to 0x00 (for forward routes) or 0x02 (for  
> bidirectional routes). The S flag MUST be set to 1 and the N field  
> MUST indicate the number of Source Route options in the message. A  
> Source Route option MAY immediately be followed by a Metric  
> Container option that carries the aggregated
> JP> or recorded
> [Page 20]

---

From: JP Vasseur <[email-masked]>
Date: Wed, 16 Jun 2010 15:07:04 +0200

> is the way to guarantee swift delivery at any time.

iff the overhead required to maintain connectivity with pro-active  
routing is too expensive.

> regards to some metrics may be discovered but it is worth pointing  
> out that this comes
>> current/.    Internet-Drafts are draft documents valid for a  
>> maximum of six months   and may be updated, replaced, or obsoleted  
>> by other documents at any   time.  It is inappropriate to use  
>> Internet-Drafts as reference   material or to cite them other than  
>> as "work in progress."    This Internet-Draft will expire on  
>> December 16, 2010. Copyright Notice    Copyright (c) 2010 IETF  
>> Trust and the persons identified as the   document authors.  All  
>> rights reserved.    This document is subject to BCP 78 and the IETF  
>> Trust's Legal   Provisions Relating to IETF Documents   (http://trustee.ietf.org/license-info 
>> review these documents   carefully, as they describe your rights  
>> and restrictions with respect   to this document.  Code Components  
>> text as described in Section 4.e of   the Trust Legal Provisions  
>> and are provided without warranty as Goyal, et al.            
>> Expires December 16, 2010               [Page 1]  Internet-Draft     
>>       draft-dt-roll-p2p-rpl-01               June 2010    described  
>> in the Simplified BSD License. Table of Contents    1.   
>> Node  . . . . . . . . . . . . . . . . . 10     5.4.  Processing of  
>> a DIO Carrying a Route Discovery Option           At The Target  
>> Router . . . . . . . . . . . . . . . . . . . 12   6.  Propagation  
>> of Discovery Reply Messages  . . . . . . . . . . . 13     6.1.  The  
>> Routes  . . . . 16     6.3.  DRO as Carrier of Forward/ 
>> Bidirectional Source Routes  . . 17     6.4.  Establishing Hop-by- 
>> hop Routes Via DRO . . . . . . . . . . 17   7.  Security  
>>      June 2010    These shortcomings are not compatible with the  
>> home and commercial   building domain application requirements  
>> described in [RFC5826] and   [I-D.ietf-roll-building-routing-reqs].
>> document are intended to be employed   as complementary to RPL in  
>> specific scenarios that need point-to-   point (P2P) routes between  
>> arbitrary routers.    One target use case, common in a home  
>> environment, involves a remote   control (or a motion sensor) that  
>> suddenly needs to communicate with   a lamp module, whose network  
>> address it knows apriori.  In this case,   the source of data (the  
>> remote control or the motion sensor) must be   able to discover a  
>> route to the destination (the lamp module) "on   demand".     
>> environment, involves a large LLN deployment where P2P  
>> communication   along a particular DAG among hundreds (or  
>> thousands) of routers   creates severe traffic congestion near that  
>> DAG's root, and thus   routes across this DAG are desirable.     
>> constraints are not satisfied by the P2P routes along a DAG  
>> because   they involve traversing many more intermediate routers  
>> than necessary   to reach the destination.
>>    When an intermediate router joins a temporary DAG advertized by  
>> a DIO
>> 3        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8  
>> 9 0 1       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
>> +-+-+-+-+       |   Type = 10   | Option Length | Compr |  Pad   
>> |     Resvd     |       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
>> +-+-+-+-+-+-+-+-+-+-+        
>> |                                                                
>> |       .                       
>> Addresses 
>> [1 
>> ..n 
>> ]                          .       .                                                               .       | 
>>                                                                 
>> +-+-+                 Figure 3: Format of the Source Route  
>> Option    The Source Route option, illustrated in Figure 3, carries  
>> a complete   forward/bidirectional source route from the target  
>> router to the   origin router.  A Source Route option can only be a  
>> part of the   Discovery Reply Object and MAY be immediately  
>> followed by a Metric   Container option that contains the  
>> aggregated values of the routing   metrics for this source  
>> route.    A Route Discovery option consists of the following  
>> fields:    o  Option Type = 0x0A (to be confirmed by IANA).    o   
>> Option Length = Variable, depending on the size of the  
>> Addresses      vector.    o  Compr: 4-bit unsigned interger  
>> indicating the number of prefix      octets that are elided from  
>> each address.  For example, Compr      value will be 0 if full IPv6  
>> addresses are carried in the      Addresses vector.    o  Pad: 4- 
>> bit unsigned integer.  Number of octets that are used for       
>> network configuration for an RPL domain is that all routers    
>> within an LLN share a common prefix.  The Source Route option  
>> uses   the Compr field to allow compaction of the Addresses[1..n]  
>> vector   when all entries share the same prefix as the DODAGID or  
>> the Target   Address of the encapsulating Discovery Reply Object.   
>> The shared   prefix octets are not carried within the Source Route  
>> option and each   entry in Address[1..n] has size (16 - Compr)  
>> octets.  When Compr is Goyal, et al.           Expires December 16,  
>> 2010              [Page 15]  Internet-Draft          draft-dt-roll-p 
>> 2p-rpl-01               June 2010    non-zero, there may exist  
>> unused octets between the last entry,   Address[n], and the end of  
>> the Source Route option.  The Pad field   indicates the number of  
>> unused octets that are used for padding.   Note that when Compr is  
>> 0, Pad MUST be null and carry a value 0.    The Source Route option  
>> MUST NOT specify a path that visits a router   more than once.   
>> When generating a Source Route option, the target   router may not  
>> know the mapping between IPv6 addresses and routers.   Minimally,  
>> the target router MUST ensure that:    o  The IPv6 Addresses do not  
>>       June 2010 6.3.  DRO as Carrier of Forward/Bidirectional  
>> Source Routes    When a target router discovers a forward source  
>> route,

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 16 Jun 2010 17:07:23 -0500 (CDT)

Hi JP

Thanks for the text. I think that there is a need for an Applicability section that would contain this text as part of a general discussion of when to do P2P route discovery.

Thanks
Mukul

----- Original Message -----
From: "JP Vasseur" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>, "Emmanuel Baccelli" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>
Sent: Wednesday, June 16, 2010 5:10:59 AM
Subject: Re: [Roll] Comments on draft-dt-roll-p2p-rpl-01

Hi,

"As pointed out in this document, RPL does provide support of P2P routes
via a common
ancestor. Using the mechanism described in this document, more optimal
routes with
regards to some metrics may be discovered but it is worth pointing out
that this comes
at the price of additional control messages in the network since the
discovery process
requires sending additional routing control plane messages. The gain in
terms of path
optimality may vary with the network topology and networking conditions.
Thus network
designer may want to take into account the trade-off between the
potential discovery of a
more optimal route and the associated cost in terms of network and node
resources. Note that on-demand routing also offers the benefit of not
having to maintains states
as with proactive routing."

Thanks.

JP.

Dear authors,

Since I had a number of comments I inserted them in the ID itself. As
you will notice:
1) Some of them are purely editorial
2) Others are more fundamental and may require just clarifications, more
discussion on the mailing list, ... In this case, feel free to start a
separate thread (note that ticket cannot be assigned to non WG
document). 3) I also suggested new sections

Internet Engineering Task Force M. Goyal, Ed.
Internet-Draft University of Wisconsin Milwaukee
Intended status: Informational E. Baccelli, Ed. JP> Are you sure that
you want to make it informational ?
Expires: December 16, 2010 INRIA
P2P. Team
June 14, 2010

Reactive Discovery of Point-to-Point Routes in Low Power and Lossy
Networks draft-dt-roll-p2p-rpl-01

Abstract

This document describes a mechanism to discover and establish "on
demand" one or more routes between two routers in a low power and
lossy network.
JP> Needs a bit more details + explicitly refer to IPv6 in the abstract
and introduction. Status of this Memo This Internet-Draft is submitted
to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet- Drafts is at
http://datatracker.ietf.org/drafts/current/ . Internet-Drafts are draft
documents valid for a maximum of six months and may be updated,
replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite
them other than as "work in progress." This Internet-Draft will expire
on December 16, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and
the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents ( http://trustee.ietf.org/license-info ) in
effect on the date of publication of this document. Please review these
documents carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this document
must include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as Goyal,
et al. Expires December 16, 2010 [Page 1] Internet-Draft
draft-dt-roll-p2p-rpl-01 June 2010 described in the Simplified BSD
License. Table of Contents 1. Introduction . . . . . . . . . . . . . . .
. . . . . . . . . . 3 2. Targeted Use Cases . . . . . . . . . . . . . .
. . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . .
. . . . . 4 4. Functional Overview . . . . . . . . . . . . . . . . . . .
. . 5 5. Propagation of Discovery Messages . . . . . . . . . . . . . . 7
5.1. The Route Discovery Option . . . . . . . . . . . . . . . . 7 5.2.
Setting a DIO Carrying a Route Discovery Option . . . . . 9 5.3.
Processing of a DIO Carrying a Route Discovery Option At An Intermediate
Node . . . . . . . . . . . . . . . . . 10 5.4. Processing of a DIO
Carrying a Route Discovery Option At The Target Router . . . . . . . . .
. . . . . . . . . . 12 6. Propagation of Discovery Reply Messages . . .
. . . . . . . . 13 6.1. The Discovery Reply Object (DRO) . . . . . . . .
. . . . . 13 6.1.1. The Source Route Option . . . . . . . . . . . . . .
. 15 6.2. DRO as Acknowledgement for Backward Source Routes . . . . 16
6.3. DRO as Carrier of Forward/Bidirectional Source Routes . . 17 6.4.
Establishing Hop-by-hop Routes Via DRO . . . . . . . . . . 17 7.
Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA
Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. Authors
and Contributors . . . . . . . . . . . . . . . . . . . 18 10. References
. . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative
References . . . . . . . . . . . . . . . . . . . 18 10.2. Informative
References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . .
. . . . . . . . . . . . . . . . . . . . . . 19 Goyal, et al. Expires
December 16, 2010 [Page 2] Internet-Draft draft-dt-roll-p2p-rpl-01 June
2010 1. Introduction RPL [I-D.ietf-roll-rpl] provides
multipoint-to-point (MP2P) routes from routers in a low power and lossy
network (LLN) to a sink router by organizing the routers along a
Directed Acyclic Graph (DAG) rooted at the sink. JP> low power and lossy
.... Low Power and Lossy JP> RPL provides P2MP, MP2P and P2P routes too.
The DAG root initiates the DAG formation by originating
a DODAG Information Object (DIO) message. The DIO message is sent
via link-local multicast and carries information about the
originating router's position (the "rank") in the DAG. On receiving
DIO messages sent by its neighbors, a router determines its own
"rank" in the DAG and originates its own DIO message. JP> Without going
too much in the details, you may just want to add that a node decides to
join a DODAG according to a number of parameters (identity of the DODAG,
OF, routing/constraints a specified in the metric-ID,...). RPL enables
point-to-multipoint (P2MP) routing from a router to its
descendants in the DAG by allowing a router to send a Destination
Advertisement Object (DAO) upwards along the DAG. The DAO carries
the aggregated JP> Potentially "aggregated" information regarding the
descendants (and other local
prefixes) reachable through the originating router.

RPL also provides mechanisms for point-to-point (P2P) routing between
any two routers in the DAG. JP> Yes. If the destination is within the
source's "range", the source may directly send packets to the
destination. Otherwise, if the destination is a DAG descendant and
the source maintains "downwards" routing state about this descendant,
it can forward the packet along this route. Otherwise, the source
sends the packet to a DAG parent, which then applies the same set of
rules to forward the packet further. Thus, a packet travels up the
DAG until it reaches a router that knows of the downwards route to
the destination and then it travels down the DAG towards its
destination. A router may or may not maintain routing state about a
descendant depending on whether its immediate children send it such
information in their DAOs and whether the router can store this
information. Thus, in the best case scenario, the "upwards" segment
of the P2P route between a source and a destination ends at the first
common ancestor of the source and the destination. In the worst
case, the "upwards" segment would extend all the way to the DAG's
root. If the destination did not originate a DAO, the packet will
travel all the way to the DAG's root, where it will be dropped.
JP> This may require to be a bit more accurate here. If there is no DAO,
there RPL is used for MP2P routing only (that is not a protocol design
characteristic though). The P2P routing functionality available in RPL
suffers from several
shortcomings [I-D.brandt-roll-rpl-applicability-home-building]:
JP> "suffering from several shortcomings" is a bit strong though. You
may want to say that additional mechanisms may be required to address
specific situation and list them. o The need to maintain routes
"proactively", i.e. every possible
destination in the DAG must originate a DAO.

o The constraint to route only along a DAG potentialy leading to
significantly suboptimal P2P routes and traffic congestion near
the DAG root. JP> First bullet: you can mention that this requires to
pro-actively advertise the route and to keep refreshing the state
accordingly Second bullet: just to be very accurate, mention that the
route may be sub-optimal. This is highly network topology / OF
dependent. Goyal, et al. Expires December 16, 2010 [Page 3]
Internet-Draft draft-dt-roll-p2p-rpl-01 June 2010 These shortcomings are
not compatible with the home and commercial building domain application
requirements described in [RFC5826] and
[I-D.ietf-roll-building-routing-reqs]. JP> Again, to be accurate, there
are no MUST requirements listed in these ID that are not satisfied by
RPL (with regards to the aforementioned issues). I am NOT saying that
the proposed mechanism is not useful (by all means), just that the
statement above is not correct.
Such applications require a
mechanism providing source-initiated discovery of P2P routes that are
not along a DAG. JP> In some cases, it may be desirable to make use of
source-initiated ...
This document thus describes such a mechanism,
complementary to the basic RPL specification.

The specified scheme is based on a reactive on-demand approach, which
enables a router to discover one or more "good-enough" routes in
either direction between itself and another router in the LLN without
any constraints regarding the existing DAG-membership of the links
that such routes may use. JP> This will be an aspect triggering some
discussion. How "good" is "good enough" ? You will need some text to
elaborate here or point to another section explaining what is meant by
"good enough" Such routes may be source-routes or hop-
by-hop ones. JP> Just terminology: instead of referring to hop-by-hop
routes, you may want to say that once a route has been computed between
two nodes in the network, IPv6 packet may be forward using a source
routing mechanism as specified in [XX] or in a hop by hop fashion. A
complementary functionality, necessary to help decide
whether to initiate a route discovery, is a mechanism to measure the
end-to-end cost of an existing route. JP> s/cost/path cost Such
functionality will be
described in a separate document.
JP> But its use is described in this document ? 2. Targeted Use Cases
The mechanisms described in this document are intended to be employed as
complementary to RPL in specific scenarios that need point-to- point
(P2P) routes between arbitrary routers. One target use case, common in a
home environment, involves a remote control (or a motion sensor) that
suddenly needs to communicate with a lamp module, whose network address
it knows apriori. In this case, the source of data (the remote control
or the motion sensor) must be able to discover a route to the
destination (the lamp module) "on demand". Another target use case,
common in a large commercial building environment, involves a large LLN
deployment where P2P communication along a particular DAG among hundreds
(or thousands) of routers creates severe traffic congestion near that
DAG's root, and thus routes across this DAG are desirable. Targeted use
cases also include scenarios where energy or delay constraints are not
satisfied by the P2P routes along a DAG because they involve traversing
many more intermediate routers than necessary to reach the destination.
JP> What I would suggest is to summarize it, put in the introduction,
and detail the use case in the applicability statement. 3. Terminology

[RFC2119].

Origin Router: The router initiating the route discovery. The origin
router acts as one end point of the routes to be discovered.

Source Route: A complete and ordered list of routers that can be used
by a packet to travel from a source to a destination. Such source
routes can be carried by a packet in a proposed Type 4 Routing Header
[I-D.hui-6man-rpl-routing-header].

Hop-by-hop Route: A route from a source to a destination where each
router in the route knows only the address of the next hop on the
route. JP> I would suggest to change the definition for "routing
paradigm whereby packets are routed from their source to destination by
on a hop by hop basis where the packets is routed by a set of routers
along the path according to the routing table stored by each router
along the path". In this document, the term 'router' refers to any LLN
device that can
forward packets generated at other devices.

4. Functional Overview

o The nature of the routing cost, the method for accumulating the
end-to-end cost JP> This may de detailed hereafter but I guess that you
will point to the metric-ID for the metric used?
and the criteria used to determine if a route is
"good enough";

o A limit on the "distance" the Discovery message may travel.
JP> Need to define the term "distance": is it a max path cost, number of
hops, ... ? The Discovery message propagates via link-local multicast
JP> Indicate "IPv6" with each
receiving router making the decision regarding whether to forward the
message further based on the "distance" (from router A) that this
particular copy of the message has already traveled. Note that this
document does not require a receiving router to use the "good enough"
criteria to make the forwarding decision. This is because the
evaluation of such criteria may be too complex for a constrained
intermediate router to perform for each received copy of the
Discovery message. JP> So I guess that you define later what to do in
both cases (the node cannot process the "good enough" criteria or it can
process it) ? The calculation of the "distance" that a copy of
the Discovery message has already travelled should be simple enough
for a constrained router to perform. JP> Again it is hard to tell from
what you wrote if this can reasonably be achieved; it depends on the
definition of the term "distance". A router may optionally decide
not to forward a copy of the Discovery message further because the
aggregated cost of the route so far fails the "good enough" criteria.
JP> You will nee to be more specific here. Is it a "may" or a "MAY".
Define what happens in this case. You may provide more details later in
the document. The underlying mechanism being used to propagate the
Discovery message may put further restrictions on its propagation. A
router should not propagate the Discovery message further if hop-by-hop
routes are desired and the router can not store state for this route.

As a copy of the Discovery message travels towards router B, it
accumulates the relevant forward/backward costs as well as the route
it takes. When router B receives a copy of the Discovery message, it
determines whether the route traveled by the message meets the "good
enough" criteria. JP> I think that you already mentioned this. If router
A had requested the discovery of backward source-routes, JP> Didn't you
mean "forward" ? router B caches one or more good enough source-routes
it identifies.
Additionally, router B sends one or more "Discovery Reply" message to
router A to acknowledge the discovery of these routes. These
acknowledgements allow router A to judge the success of the route
discovery. The Discovery Reply messages can travel towards router A
in any manner chosen by router B. For example, router B may source-
route the messages or send them towards router A along a DAG.

If router A had requested the discovery of "n" forward source-routes,
router B sends the "n" good enough source-routes it identifies to
router A in one or more Discovery Reply messages. Again, these
Discovery Reply messages can travel towards router A in any manner
chosen by router B. JP> What if the DAG is "broken": retry from A after
expiration of a local timer ? If router A had requested the discovery of
"n" bidirectional source-
routes, router B caches the "n" good enough source-routes it
identifies and also sends these routes to router A in one or more
Discovery Reply messages. These Discovery Reply messages can travel
towards router A in any manner chosen by router B.

If router A had requested the discovery of "n" forward/backward/
bidirectional hop-by-hop routes, router B sends out a Discovery Reply
message to router A for each one of the "n" good enough routes it
identifies. JP> Do you need one "Discovery Reply message" per route or
next-hop in this case? The Discovery Reply message travels towards
router A
using the source-route accumulated by the Discovery message. JP> In the
case of hop-by-hop routes, source routes, both ? As this
message travels towards router A, it establishes appropriate forward/
backward routing state in the en-route routers. This "non DAG"
routing state should be specially marked to associate it with the
routing metrics JP> Refer to metric ID ? used to discover the route and
to distinguish such
state from other DAG-specific routing state the router may have. JP> Not
sure that you need to distinguish the state. Suppose that you discover a
hop-by-hop route (not a big fan of that terms as pointed out above but
let's continue to use it for the time being), a storing node may indeed
have two routes for the same destination: do you want to state that it
should always use the P2P routes discovered by this mechanism or let it
choose the best one according to the metric in use? JP> What if there
are two routes using different metrics? 5. Propagation of Discovery
Messages

RPL uses DIO message propagation to build a DAG. The DIO message
travels via link-local multicast. JP> Add everywhere "IPv6 link-local
multicast addresses"
Each router joining the DAG
determines a rank for itself and ignores the subsequent DIO messages
received from lower (higher in numerical value) ranked neighbors.
Thus, the DIO messages propagate outwards rather than return inwards
towards the DAG root. JP> I would suggest to align to the RPL
terminology. Inward/outward are not used anymore.
The DIO message generation at a router is
further controlled by a trickle timer that allows a router to avoid
generating unnecessary messages. JP> Add a reference to the Trickle ID
The link-local multicast based
propagation, trickle-controlled generation and the rank-based
poisoning of messages traveling in the wrong direction (towards the
DAG root) provide powerful incentives to use the DIO message as the
Discovery message and propagate the DIO/Discovery message by creating
a "temporary" DAG.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 9 | Option Length | D |S| N | L |O| Max Rank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       Target Address |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              OCP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In order to be used as a Discovery message, a DIO MUST carry a "Route
Discovery" option illustrated in Figure 1. A DIO MUST NOT carry more

than one Route Discovery options. JP> Explain what you do if more than
one is present: * Ignore the second one? * Ignore the entire message?
A Route Discovery option consists
of the following fields:

o Option Length = 20 or 22 octets depending on whether the OCP field
is included or not.

* D = 0x00: Forward;

* D = 0x01: Backward;

* L = 0x03: Minimum life time is 10 minutes.
JP> Placeholder ... indicate what happens if a node cannot store that
additional state (add a manageability section). o O: A flag that
indicates whether the same OCP is used for route
discovery as well as temporary DAG formation. If this flag is
clear, the OCP contained in the DODAG Configuration option in the
DIO is used for route discovery as well. Otherwise, the OCP
specified in the Route Discovery option is used for route
selection JP> s/route selection/route discovery
and the metrics/constraints used for route selection are
carried in a Metrics Container option immediately following the
Route Discovery option. JP> Since OF is decoupled from metrics, you
always need to indicate the metric in use. That said, I do not see your
point here. Indeed, the temporary DAG is built according to some OF and
metrics so the resulting routes will inherit these metrics? o Max Rank:
A 7-bit unsigned integer that indicates the maximum rank
allowed in the temporary DAG advertised by the DIO message. This
upper limit on the DAG rank serves as the "distance" referred to

in Section 4 and provides a control over how far the Route
Discovery option contained in the DODAG Configuration option in
the DIO message may travel. JP> You may discuss it later in this
document ... but the distance is tied to how you compute the rank. A
router MUST not JP> s/MUST not/MUST NOT join the temporary
DAG if its rank in the DAG will exceed this limit. Later versions
of this draft will map the 128 value space available in this field
to 16-bit long limits on the DAG rank.

A DIO message that carries a Route Discovery option MUST set the Base
Object, described in [I-D.ietf-roll-rpl], in the following manner:

o RPLInstanceID: RPLInstanceID MUST be a local value as described in
Section 4.1 of [I-D.ietf-roll-rpl].

o Mode of Operation (MOP): Since the temporary DAG is not to be used
for routing purposes, the value of this field is immaterial. To
allow constrained routers to join the DAG, the MOP field SHOULD be
set to 00 (non-storing).
JP> I'd rather suggest to specify a new MOP value (0x02) o
DODAGPreference (Prf): TBD

o Destination Advertisement Trigger Sequence Number (DTSN): TBD
JP> To be discussed on the mailing list ? o DODAGID: IPv6 address of the
router initiating the route
discovery. JP> Origin router. The other fields in the Base Object are
set as per the rules
described in [I-D.ietf-roll-rpl].

The DODAG Configuration option, carried in the DIO message, specifies
the parameters for the trickle timer operation that governs the
generation of DIO messages by the routers joining the temporary DAG.
JP> Also according to RPL ID or would you recommend different default
values ? Default values for RPL are TBD but we could easily think of
different values in this case. To be revisited in the future. Goyal, et
al. Expires December 16, 2010 [Page 9]

The other fields defined in the DODAG Configuration option are set as
follows:

o The MaxRankIncrease field MUST be set to 0 to disable local repair
of the temporary DAG.

A DIO, that contains a Route Discovery option with O flag set, MUST
also contain a Metric Container option immediately following the
Route Discovery option. This Metric Container option carries the
values for the routing metrics as well as the constraints
(constituting the "good enough" criteria) used for route selection. JP>
This is confusing: the metric and constraint carried within the Metric
Container are used for the DODAG formation. Do you want to use them for
a different purpose ? At this point, you have not yet defined the use of
the good enough criteria but one can guess that you would use the good
enough metrics to control the flooding and the metric/OF to effectively
build the temporary DAG and discover the routes. If so, the good enough
metrics are of different use. Note that if O flag in the Route Discovery
option is clear, the OCP
and Metric Container used for temporary DAG formation are used for
route selection as well.

A DIO, carrying a Route Discovery option, MUST not carry any Route JP>
s/MUST not/MUST NOT Information or Prefix Information options described
in [I-D.ietf-roll-rpl].

The rules for DIO processing and transmission, described in Section 7
of RPL [I-D.ietf-roll-rpl], apply to DIOs carrying a Route Discovery
option as well except as modified in this document.

When an intermediate router joins a temporary DAG advertized by a DIO
carrying the Route Discovery option, it MUST maintain its membership
in the DAG for the Minimum Life Time duration listed in the Route
Discovery option. JP> What if it cannot ? Just not join the DAG and log
an error ? Maintaining membership in the DAG implies
remembering:

o The best Metric Container, JP> you mean the best path cost? along with
the associated source route
from the initiator of route discovery till this router (carried in
a Record Route IPv6 Extension Header proposed in
[I-D.thubert-6man-reverse-routing-header]), for the Route

Discovery option being propagated by the temporary DAG. If the
router can not compare Metric Containers, it MUST remember the
latest Metric Container it has received, along with the associated
source route. JP> Requires clarification on what you mean by "compare" A
router belonging to a temporary DAG need not remember the identity
of its DAG parents since the temporary DAG is not used for routing. JP>
Are you sure ? What is a hop-by-hop route is needed ? Don't you need to
remember your parent, or do you still record the route ? The main
purpose of a temporary DAG's existence is to facilitate the
propagation of the Route Discovery option.

o The router does not support the objective function JP> and/or metrics
being used for
route discovery

A router MUST discard the DIO if the Route Discovery option contained
in the message does not need further processing. JP> Log an error ?
Otherwise, the Route Discovery option is processed as follows.

The router updates the Metrics Container associated with the received
Route Discovery option as per the specified objective function. JP> And
routing metrics
The router may optionally check the Metric Container to determine if the
aggregated values for the routing metrics meet all the constraints
listed in the Metric Container. JP> The aggregated values are for the
metrics. Constraints are used to prune potential path. If not, the Route
Discovery option
is discarded JP> You mean the DIO message. without further processing.
Otherwise, the router
updates its in-memory copy of the latest/best Metric Container for
this Route Discovery option along with the associated source route
updated in the correct direction (based on the D field of the Route
Discovery option). Any change in the in-memory copy also requires
resetting the trickle timer and generating a new DIO carrying the
Route Discovery option, the updated latest/best Metric Container and
the associated source route (in a Record Route IPv6 extension header
proposed in [I-D.thubert-6man-reverse-routing-header]) when the timer
fires. JP> If the changes occur during the lifetime window. Note that
the Metric Container MUST immediately follow the

Route Discovery option if the O flag in the Route Discovery option is
set.

o The router does not have sufficient information to calculate the
relevant routing metrics/constraints in the right direction (as
specified by the D field).
JP> or does not support the metric. The target router MUST discard the
DIO if the Route Discovery option contained in the message does not need
further processing. JP> ? How does it knows (simply because it reaches
the destination) ? Otherwise, the Route Discovery option is processed as
follows.

The target router updates the Metrics Container associated with the
received Route Discovery option as per the specified objective
function. JP> and routing metrics (remember they are decoupled).
The target router then checks the Metric Container to
determine if the aggregated values for the routing metrics meet all
the constraints listed in the Metric Container. JP> See previous
comments. If not, the Route
Discovery option is discarded without further processing. Otherwise,
the router MAY select the source route accumulated by the received
DIO as one of the discovered routes. JP> "MAY" ? When ? The target
router MUST send one
or more RPL Control Messages carrying a Discovery Reply Object
(defined in the next section) back to the origin router (identified
by the DODAGID field in the DIO Base Object) as discussed in the
following sections.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID | Version | D |S| N | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                         DODAGID |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       Target Address |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

o An acknowledgement from the target router to the origin router
regarding the successful discovery of backward source routes; JP> ACK of
routes from the origin to the target: you may not have routes in the
opposite direction. o Carries one or more forward/bidirectional source
routes from the
target to the origin router;

* D = 0x00: Forward;

* D = 0x01: Backward;

o Reserved: These bits are reserved for future use. These bits MUST
be set to zero on transmission and MUST be ignored on reception.

o Options: The Discovery Reply Object MAY carry up to 7 Source Route
aggregated values for the routing metrics for the source route. JP> This
may not be an aggregated value but recorded metric too. Goyal, et al.
Expires December 16, 2010 [Page 14] Internet-Draft
draft-dt-roll-p2p-rpl-01 June 2010 6.1.1. The Source Route Option 0 1 2
3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

When a target router discovers a backward source route, JP> I have an
issue with your terminology. When the target receives the DIO with route
discovery option, what is discovered is a forward route ?
it sends a
DRO message to the origin router as an acknowlegement for the
discovered route. Optionally, a target router MAY send a DRO
acknowledgement to the origin router after discovering multiple
backward source routes. A DRO, serving as an acknowledgement for
backward source route discovery, has its D field set to 0x01
(indicating backward) while the S flag is set to 1 (indicating source
route). The N field is set to indicate the number of discovered
backward source routes being acknowledged. Such a DRO message MUST
NOT contain any option.

This document does not require a particular method for sending such a
DRO message to the origin router. The target router MAY send the DRO
message to the origin router in any fashion, including:

o Along the temporary DAG created for route discovery, provided that
the target router is reasonably sure that the DAG's life time is
sufficiently long and the routers in the DAG do remember one or
more of their parents in the DAG. JP> You may want to explain a bit more
why you the origin router would be interested in receiving an ACK
without the route itself (case 6.3): hop-by-hop routes. Goyal, et al.
Expires December 16, 2010 [Page 16] Internet-Draft
draft-dt-roll-p2p-rpl-01 June 2010 6.3. DRO as Carrier of
Forward/Bidirectional Source Routes When a target router discovers a
forward source route, JP> Here, I agree that this is a forward route. it
sends a DRO
message to the origin router carrying the discovered source route
inside a Source Route option. Similarly, when a target router
discovers a bidirectional source route, it caches the route for its
own use and then sends a DRO message to the origin router carrying
the discovered route inside a Source Route option. Rather than
immediately sending a discovered route back to the origin router, a
target router MAY optionally send one DRO message after discovering
multiple forward/bidirectional source routes with the sent DRO
carrying the discovered source routes (in multiple Source Route
options). JP> Note that the algorithm for "best route" selection is
outside the scope of this document, so does the use of a timer on the
target side to determine how much time to wait before answering, ... A
DRO message carrying one or more Source Route options MUST have its D
field set to 0x00 (for forward routes) or 0x02 (for bidirectional
routes). The S flag MUST be set to 1 and the N field MUST indicate the
number of Source Route options in the message. A Source Route option MAY
immediately be followed by a Metric Container option that carries the
aggregated JP> or recorded values of the routing metrics for this source
route. The target router may send this DRO message to the origin
router in any fashion it desires including the options listed in
Section 6.2.

A router receiving such a DRO message SHOULD establish hop-by-hop
state in the right direction corresponding to the route carried in
the Type 4 Routing Header of the DRO message. If a router does not
establish such state, it MUST drop the DRO message. Otherwise, it
MUST forward the DRO message along the source route contained in Type
4 Routing Header of the received message.
JP> Any error log if it does not ? (optional) ICMP sent to the target
node? A router SHOULD associate the hop-by-hop routing state, thus
established, with the objective function and metrics used for route
discovery.

Internet-Draft draft-dt-roll-p2p-rpl-01 June 2010 JP> New section to
indicate how to clean-up the temporary DAG ? 7. Security Considerations

TBA

8. IANA Considerations

TBA

Anders Brandt, Sigma Designs, Emdrupvej 26A, 1., Copenhagen, Dk-2100,
Denmark. Phone: +45 29609501; Email: [email-masked] Robert Cragie,
Gridmerge Ltd, 89 Greenfield Crescent, Wakefieldm WF4
4WA, UK. Phone: +44 1924910888; Email: [email-masked]
Jerald Martocci, Johnson Controls, Milwaukee, WI 53202, USA. Phone:
+1 414 524 4010; Email: [email-masked] Charles Perkins,
Tellabs Inc., USA. Email: [email-masked] Authors gratefully
acknowledge the contributions of Richard Kelsey
and Zach Shelby in the development of this document.

10. References

[I-D.brandt-roll-rpl-applicability-home-building]
Brandt, A., Baccelli, E., and R. Cragie, "Applicability
Statement: The use of RPL in Building and Home
Environments", draft-brandt-roll-rpl-applicability-home-building-00
(work in progress), April 2010.

"Building Automation Routing Requirements in Low Power and

[I-D.ietf-roll-of0]

[I-D.ietf-roll-routing-metrics]
Vasseur, J., Kim, M., Networks, D., and H. Chong, "Routing
Metrics used for Path Calculation in Low Powe

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 17 Jun 2010 09:42:54 +0200

Hi JP,

> these ID that are not satisfied by RPL (with regards to the aforementioned
>
> Not quibbling at all. But to be perfectly accurate this does not translate
> into "a reactive protocol
> is needed". Once again (not to make sure that there is no confusion), I am
> not trying to say that

Quite right. But I think we are rather getting to the point raised by Dave
in yesterday's virtual meeting, i.e. we need to decide :
(i) what minimum functionalities are needed in the basic RPL spec,
(ii) what extra functionalities we want to specify in companion documents.

So the point that is made here, rather than saying "a reactive protocol is
needed", is saying:
(i) source-initiated path establishment is required by some applications,
(ii) this functionality does not belong in the basic RPL spec

This is why we propose a companion draft providing source-initiated path
establishment (and yes, a reactive approach is one way to do it ;).

Emmanuel

---

From: JP Vasseur <[email-masked]>
Date: Thu, 17 Jun 2010 09:47:16 +0200

Hi,

On Jun 17, 2010, at 9:42 AM, Emmanuel Baccelli wrote:

> is needed". Once again (not to make sure that there is no  
> confusion), I am not trying to say that
> Quite right. But I think we are rather getting to the point raised  
> by Dave in yesterday's virtual meeting, i.e. we need to decide :
> So the point that is made here, rather than saying "a reactive  
> protocol is needed", is saying:

I did look at it and it seems that the demarcation line is pretty  
clear. So far, your ID does not
require an RPL core specification modification but this is important  
to know if you think otherwise.

> This is why we propose a companion draft providing source-initiated  
> path establishment

I was just pointing out that the MUST listed the requirements were not  
the way to justify it.
If there is a WG consensus to use this approach, we will standardize it.

Cheers.

JP.

> (and yes, a reactive approach is one way to do it ;).
>
> Emmanuel
>
>
>