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

[Mukul Goyal <[e-mail]>]

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" <[e-mail]>
To: "Mukul Goyal" <[e-mail]>, "Emmanuel Baccelli" <[e-mail]>
Cc: "ROLL WG" <[e-mail]>
Sent: Wednesday, June 16, 2010 5:10:59 AM
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.



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:
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: [phone]; Email: [e-mail] Robert Cragie,
Gridmerge Ltd, 89 Greenfield Crescent, Wakefieldm WF4
4WA, UK. Phone: [phone]; Email: [e-mail]
Jerald Martocci, Johnson Controls, Milwaukee, WI 53202, USA. Phone:
[phone]; Email: [e-mail] Charles Perkins,
Tellabs Inc., USA. Email: [e-mail] 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 Powe