draft-ietf-roll-p2p-rpl-01.txt   draft-ietf-roll-p2p-rpl-02.txt 
Internet Engineering Task Force M. Goyal, Ed. Internet Engineering Task Force M. Goyal, Ed.
Internet-Draft University of Wisconsin Milwaukee Internet-Draft University of Wisconsin Milwaukee
Intended status: Experimental E. Baccelli, Ed. Intended status: Experimental E. Baccelli
Expires: April 29, 2011 INRIA Expires: August 11, 2011 INRIA
October 26, 2010 A. Brandt
Sigma Designs
R. Cragie
Gridmerge Ltd
J. Martocci
Johnson Controls
C. Perkins
Tellabs Inc
February 7, 2011
Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Reactive Discovery of Point-to-Point Routes in Low Power and Lossy
Networks Networks
draft-ietf-roll-p2p-rpl-01 draft-ietf-roll-p2p-rpl-02
Abstract Abstract
Point to point (P2P) communication between arbitrary IPv6 routers and Point to point (P2P) communication between arbitrary IPv6 routers and
hosts in a Low power and Lossy Network (LLN) is a key requirement for hosts in a Low power and Lossy Network (LLN) is a key requirement for
many applications. RPL, the IPv6 Routing Protocol for LLNs, many applications. RPL, the IPv6 Routing Protocol for LLNs,
constrains the LLN topology to a Directed Acyclic Graph (DAG) and constrains the LLN topology to a Directed Acyclic Graph (DAG) and
requires the P2P routing to take place along the DAG links. Such P2P requires the P2P routing to take place along the DAG links. Such P2P
routes may be significantly suboptimal and may lead to traffic routes may be suboptimal and may lead to traffic congestion near the
congestion near the DAG root. This document describes a P2P route DAG root. This document specifies a P2P route discovery mechanism,
discovery mechanism complementary to RPL base functionality. This complementary to the RPL base functionality. This mechanism allows
mechanism allows an RPL-aware IPv6 router or host to discover and an RPL-aware IPv6 router or host to discover and establish, on
establish on demand one or more routes to another RPL-aware IPv6 demand, one or more routes to another RPL-aware IPv6 router or host
router or host in the LLN such that the discovered routes meet the in the LLN such that the discovered routes meet a specified cost
specified cost criteria. criteria.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 29, 2011. This Internet-Draft will expire on August 11, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Targeted Use Cases . . . . . . . . . . . . . . . . . . . . . . 4 2. The Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Functional Overview . . . . . . . . . . . . . . . . . . . . . 6 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Propagation of Discovery Messages . . . . . . . . . . . . . . 7 5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 7
5.1. The Route Discovery Option . . . . . . . . . . . . . . . . 8 6. Propagation of Discovery Messages . . . . . . . . . . . . . . 8
5.2. Setting a DIO Carrying a Route Discovery Option . . . . . 9 6.1. The Route Discovery Option . . . . . . . . . . . . . . . . 9
5.3. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 11 6.2. Setting a DIO Carrying a Route Discovery Option . . . . . 10
5.4. Processing a DIO Carrying a Route Discovery Option . . . . 11 6.3. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 12
5.5. Additional Processing of a DIO Carrying a Route 6.4. Processing a DIO Carrying a Route Discovery Option . . . . 12
Discovery Option At An Intermediate Router . . . . . . . . 12 6.5. Additional Processing of a DIO Carrying a Route
5.6. Additional Processing of a DIO Carrying a Route Discovery Option At An Intermediate Router . . . . . . . . 13
Discovery Option At The Target Node . . . . . . . . . . . 13 6.6. Additional Processing of a DIO Carrying a Route
6. Propagation of Discovery Reply Messages . . . . . . . . . . . 13 Discovery Option At The Target Node . . . . . . . . . . . 14
6.1. The Discovery Reply Object (DRO) . . . . . . . . . . . . . 14 7. Propagation of Discovery Reply Messages . . . . . . . . . . . 14
6.1.1. The Source Route Option . . . . . . . . . . . . . . . 16 7.1. The Discovery Reply Object (DRO) . . . . . . . . . . . . . 15
6.1.2. Processing a DRO At An Intermediate Router . . . . . . 17 7.1.1. The Source Route Option . . . . . . . . . . . . . . . 17
6.2. DRO as Acknowledgement for Backward Source Routes . . . . 18 7.1.2. Processing a DRO At An Intermediate Router . . . . . . 19
6.3. DRO as Carrier of Forward/Bidirectional Source Routes . . 18 7.2. DRO as Acknowledgement for Backward Source Routes . . . . 19
6.4. Establishing Hop-by-hop Routes Via DRO . . . . . . . . . . 18 7.3. DRO as Carrier of Forward/Bidirectional Source Routes . . 19
7. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 19 7.4. Establishing Hop-by-hop Routes Via DRO . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Authors and Contributors . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21
11.2. Informative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
RPL [I-D.ietf-roll-rpl] provides multipoint-to-point (MP2P) routes RPL [I-D.ietf-roll-rpl] provides multipoint-to-point (MP2P) routes
from nodes in a Low power and Lossy Network (LLN) to a sink node by from nodes in a Low power and Lossy Network (LLN) to a sink node by
organizing the nodes along a Directed Acyclic Graph (DAG) rooted at organizing the nodes along a Directed Acyclic Graph (DAG) rooted at
the sink. The nodes determine their position in the DAG so as to the sink. The nodes determine their position in the DAG so as to
optimize their routing cost to reach the DAG root. A node advertises optimize their routing cost on the path towards the DAG root. A node
its position (the "rank") in the DAG by originating a DODAG advertises its position (the "rank") in the DAG by originating a
Information Object (DIO) message. The DIO message is sent via link- DODAG Information Object (DIO) message. The DIO message is sent via
local multicast and also includes information such as the DAG root's link-local multicast and also includes information such as the DAG
identity, the routing metrics/constraints root's identity, routing metrics/constraints
[I-D.ietf-roll-routing-metrics] and the objective function (OF) in [I-D.ietf-roll-routing-metrics] and the objective function (OF) in
use. When a node joins the DAG, it determines its own rank in the use. When a node joins the DAG, it determines its own rank in the
DAG based on that advertised by its neighbors and originates its own DAG based on that advertised by its neighbors and originates its own
DIO message. DIO message.
RPL enables point-to-multipoint (P2MP) routing from a node to its RPL enables point-to-multipoint (P2MP) routing from a node to its
descendants in the DAG by allowing a node to send a Destination descendants in the DAG by allowing a node to send a Destination
Advertisement Object (DAO) upwards along the DAG. The DAO carries Advertisement Object (DAO) upwards along the DAG. The DAO carries
the potentially aggregated information regarding the descendants (and potentially aggregated information regarding the descendants (and
other local prefixes) reachable through the originating node. other local prefixes) reachable through the node originating this
DAO.
RPL also provides mechanisms for point-to-point (P2P) routing between RPL also provides mechanisms for point-to-point (P2P) routing between
any two nodes in the DAG. If the destination is within the source's any two nodes in the DAG. If the destination is within the source's
"range", the source may directly send packets to the destination. radio range, the source may directly send packets to the destination.
Otherwise, a packet's path from the source to the destination depends Otherwise, a packet's path from the source to the destination depends
on the storing/non-storing operation mode of the DAG. In non-storing on the storing/non-storing operation mode of the DAG. In non-storing
mode operation, only the DAG root maintains downward routing mode operation, only the DAG root maintains downward routing
information and hence a packet travels all the way to the DAG root, information and hence a packet travels all the way to the DAG root,
which then sends it towards its destination using a source route. In which then sends it towards its destination using a source route. In
storing mode operation, if the destination is a DAG descendant and storing mode operation, if the destination is a DAG descendant and
the source maintains "downwards" routing state about this descendant, the source maintains "downwards" hop-by-hop routing state about this
it can forward the packet along this route. Otherwise, the source descendant, it can forward the packet to a descendant router closer
sends the packet to a DAG parent, which then applies the same set of to the destination. Otherwise, the source sends the packet to a DAG
rules to forward the packet further. Thus, a packet travels up the parent, which then applies the same set of rules to forward the
DAG until it reaches a node that knows of the downwards route to the packet further. Thus, a packet travels up the DAG until it reaches a
destination and then it travels down the DAG towards its destination. node that knows of the downwards route to the destination and then it
A node may or may not maintain routing state about a descendant travels down the DAG towards its destination. A node may or may not
depending on whether its immediate children send it such information maintain routing state about a descendant depending on whether its
in their DAOs. Thus, in the best case storing mode scenario, the immediate children send it such information in their DAOs. Thus, in
"upwards" segment of the P2P route between a source and a destination the best case with storing mode operation, the "upwards" segment of
ends at the first common ancestor of the source and the destination. the P2P route between a source and a destination ends at the first
In the worst case, the "upwards" segment would extend all the way to common ancestor of the source and the destination. In the worst
the DAG's root. In both storing and non-storing mode operations, if case, the "upwards" segment would extend all the way to the DAG root.
the destination did not originate a DAO, the packet will travel all In both storing and non-storing mode operations, if the destination
the way to the DAG's root, where it will be dropped. did not originate a DAO, the packet will travel all the way to the
DAG's root, where it will be dropped.
The P2P routing functionality available in RPL may be inadequate for The P2P routing functionality available in RPL may be inadequate for
applications in the home and commercial building domains because of applications in the home and commercial building domains for the
the following reasons following reasons [I-D.brandt-roll-rpl-applicability-home-building]
[I-D.brandt-roll-rpl-applicability-home-building] [RFC5826][RFC5867]: [RFC5826][RFC5867]:
o The need to maintain routes "proactively", i.e. every possible o The need to maintain routes "proactively", i.e., every possible
destination in the DAG must originate a DAO. destination in the DAG must originate a DAO.
o Depending on the network topology and OF/metrics in use, the o Depending on the network topology and OF/metrics in use, the
constraint to route only along a DAG may potentially cause constraint to route only along a DAG may cause significantly
significantly suboptimal P2P routes and severe traffic congestion suboptimal P2P routes and severe traffic congestion near the DAG
near the DAG root. root.
Clearly, there is a need for a mechanism that provides source- Thus, there is a need for a mechanism that provides source-initiated
initiated discovery of P2P routes that are not along an existing DAG. discovery of P2P routes that are not along an existing DAG. This
This document thus describes such a mechanism, complementary to the document describes such a mechanism, complementary to the basic RPL
basic RPL functionality. functionality.
The specified scheme is based on a reactive on-demand approach, which The specified mechanism is based on a reactive on-demand approach,
enables a node to discover one or more "good enough" routes in either which enables a node to discover one or more routes in either
direction between itself and another node in the LLN without any direction between itself and another node in the LLN without any
constraints regarding the existing DAG-membership of the links that restrictions regarding the existing DAG-membership of the links that
such routes may use. Such routes may be source-routes or hop-by-hop such routes may use. The discovered routes may be source routes or
ones. A complementary functionality, necessary to help decide hop-by-hop routes. The discovered routes may not be the best
whether to initiate a route discovery, is a mechanism to measure the available but are guaranteed to satisfy the desired constraints in
end-to-end cost of an existing route. Section 7 provides further terms of the routing metrics and are thus considered "good enough"
details on how such functionality, to be described in a separate from the application's perspective.
document, can be used to determine the "good enough" criteria for use
in the route discovery mechanism described in this document.
2. Targeted Use Cases 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. Section 4 provides further details on how
such functionality, described in [I-D.goyal-roll-p2p-measurement],
can be used to determine the metric constraints for use in the route
discovery mechanism described in this document.
2. The Use Cases
The mechanisms described in this document are intended to be employed The mechanisms described in this document are intended to be employed
as complementary to RPL in specific scenarios that need point-to- as complementary to RPL in specific scenarios that need point-to-
point (P2P) routes between arbitrary routers. point (P2P) routes between arbitrary routers.
One target use case, common in a home environment, involves a remote One use case, common in a home environment, involves a remote control
control (or a motion sensor) that suddenly needs to communicate with (or a motion sensor) that suddenly needs to communicate with a lamp
a lamp module, whose network address it knows apriori. In this case, module, whose network address is a-priori known. In this case, the
the source of data (the remote control or the motion sensor) must be source of data (the remote control or the motion sensor) must be able
able to discover a route to the destination (the lamp module) "on to discover a route to the destination (the lamp module) "on demand".
demand".
Another target use case, common in a large commercial building Another use case, common in a large commercial building environment,
environment, involves a large LLN deployment where P2P communication involves a large LLN deployment where P2P communication along a
along a particular DAG among hundreds (or thousands) of routers particular DAG among hundreds (or thousands) of routers creates
creates severe traffic congestion near that DAG's root, and thus severe traffic congestion near that DAG's root, and thus routes
routes across this DAG are desirable. across this DAG are desirable.
Targeted use cases also include scenarios where energy or latency The use cases also include scenarios where energy or latency
constraints are not satisfied by the P2P routes along a DAG because constraints are not satisfied by the P2P routes along a DAG because
they involve traversing many more intermediate routers than necessary they involve traversing many more intermediate routers than necessary
to reach the destination. to reach the destination.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
Additionally, this document uses terminology from Additionally, this document uses terminology from
[I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. Specifically, [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. Specifically,
the term node refers to an RPL router or an RPL host as defined in the term node refers to an RPL router or an RPL host as defined in
[I-D.ietf-roll-rpl]. This document introduces the following terms: [I-D.ietf-roll-rpl]. This document introduces the following terms:
Origin Node: The RPL node initiating the route discovery. The origin Origin : The RPL node initiating the route discovery. The origin
node acts as one end point of the routes to be discovered. acts as one end point of the routes to be discovered.
Target Node: The RPL node at the other end point of the routes to be Target : The RPL node at the other end point of the routes to be
discovered. discovered.
Intermediate Router: An RPL router that is neither the origin nor the Intermediate Router: An RPL router that is neither the origin nor the
target. target.
Forward Route: A route from the origin node to the target node. Forward Route: A route from the origin to the target.
Backward Route: A route from the target node to the origin node. Backward Route: A route from the target to the origin.
Bidirectional Route: A route that can be used in both directions: Bidirectional Route: A route that can carry traffic in both
from the origin node to the target node and vice versa. directions.
Source Route: A complete and ordered list of routers that can be used Source Route: A complete and ordered list of routers that can be used
by a packet to travel from a source node to a destination node. Such by a packet to travel from a source node to a destination node. Such
source routes can be carried by a packet in a proposed Type 4 Routing source routes can be carried by a packet in a Type 4 Routing Header
Header [I-D.ietf-6man-rpl-routing-header]. [I-D.ietf-6man-rpl-routing-header].
Hop-by-hop Route: The route characterized by each router on the route Hop-by-hop Route: The route characterized by each router on the route
using its routing table to determine the next hop on the route. using its routing table to determine the next hop on the route.
Propagation Constraints: The constraints on aggregated routing metric Propagation Constraints: The constraints on the routing metrics
values, as defined in [I-D.ietf-roll-routing-metrics], that MUST be [I-D.ietf-roll-routing-metrics] that MUST be satisfied before an
satisfied before an intermediate router will process the Route intermediate router or the target will process the Route Discovery
Discovery Option (defined in this document) contained inside a DODAG Option (defined in this document) contained inside a DODAG
Information Object (DIO). Information Object (DIO).
Route Constraints: Additional constraints on aggregated routing Route Constraints: Additional constraints on the routing metrics
metric values, as defined in [I-D.ietf-roll-routing-metrics], that [I-D.ietf-roll-routing-metrics] that the target MUST enforce on the
MUST be satisfied by a discovered route in order to be considered received DIOs.
"good enough".
Good Enough Criteria: The propagation constraints and the route 4. Applicability
constraints together constitute the good enough criteria.
4. Functional Overview The route discovery mechanism, described in this document, may be
invoked by an origin when no route exists between itself and the
target or when the existing routes do not satisfy the desired
performance requirements. The mechanism is designed to discover one
or more "good enough" routes in either direction between an origin
and a target. In some application contexts, the metric constraints
that the discovered routes must satisfy are intrinsically known or
can be specified by the application. For example, an origin that
expects a target to be less than 5 hops away may use "hop-count < 5"
as the propagation or route constraint. In other application
contexts, the origin may need to measure the cost of an existing
route to the target to determine the propagation/route constraints.
For example, an origin that measures the total ETX of its along-DAG
route to the target to be 20 may use "ETX < x*20", where x is a
fraction that the origin decides, as the propagation/route
constraint. The functionality required to measure the cost of an
existing route between the origin and the target is described in
[I-D.goyal-roll-p2p-measurement]. In case, there is no existing
route between the origin and target or the cost measurement for the
existing route fails, the origin will have to guess the propagation/
route constraints used in the initial route discovery. Once, the
initial route discovery succeeds or fails, the origin will have a
better estimate for the constraints to be used in the subsequent
route discovery.
This document describes an on-demand discovery mechanism for P2P
routes that is complementary to the proactive routes offered by RPL
base functionality. The mechanism described in this document may
result in discovery of better P2P routes than the ones available
along a DAG designed to optimize routing cost to the DAG's root. The
improvement in route quality depends on a number of factors including
the network topology, the routing metrics in use and the prevalent
conditions in the network. A network designer may take in
consideration both the benefits (potentially better routes; no need
to maintain routes proactively) and costs (control messages generated
during the route discovery process) when using this mechanism.
5. Functional Overview
This section contains a high level description of the route discovery This section contains a high level description of the route discovery
mechanism proposed in this document. mechanism proposed in this document.
The route discovery begins with the origin node generating a The route discovery begins with the origin generating a "Discovery"
"Discovery" message. The origin node indicates in the message: message. The origin indicates in the message:
o The target node; o The target;
o The relevant routing metrics; o The relevant routing metrics;
o The constraints on how far the Discovery message may travel o The constraints on how far the Discovery message may travel
(henceforth called the propagation constraints); (henceforth called the propagation constraints);
o Additional constraints used to determine if a discovered route is o Additional constraints that the target must enforce (henceforth
"good enough" (henceforth called the route constraints); called the route constraints);
o The direction (forward: from the origin node to the target node; o The direction (forward: from the origin to the target; backward:
backward: from the target node to the origin node; or from the target to the origin; or bidirectional) of the route
bidirectional) of the route being discovered; being discovered;
o The desired number of routes; o The desired number of routes (in case forward/bidirectional routes
are being discovered);
o Whether the route is a source-route or a hop-by-hop one. o Whether the route is a source route or a hop-by-hop one.
The Discovery message propagates via IPv6 link-local multicast with a The Discovery message propagates via IPv6 link-local multicast with a
receiving router discarding the message if it does not satisfy the receiving router discarding the message if it does not satisfy the
propagation constraints or if hop-by-hop routes are desired and the propagation constraints or if the hop-by-hop routes are desired and
router cannot store state for such a route. As a copy of the the router cannot store the state for such a route. As a copy of the
Discovery message travels towards the target node, it accumulates the Discovery message travels towards the target, it accumulates the
relevant routing metric values as well as the route it takes. When relevant routing metric values as well as the route it takes. When
the target node receives a copy of the Discovery message, it applies the target receives a Discovery message, it applies both the
both the propagation constraints and the route constraints to propagation constraints and the route constraints on the routing
determine if the discovered route is good enough. Thus, the good metrics inside the Discovery message. Thus, the discovered routes
enough discovered routes satisfy both the propagation constraints as satisfy both the propagation constraints as well as the route
well as the route constraints although the propagation of Discovery constraints, although the propagation of Discovery messages is guided
messages is guided by propagation constraints alone. The propagation by propagation constraints alone. Using only a subset of the
constraints and the route constraints together constitute the good constraints as propagation constraints simplifies the operation of
enough criteria. Using only a subset of the good enough criteria as intermediate routers, an important consideration in many LLN
the propagation constraints simplifies the operation of intermediate application domains [RFC5826][RFC5867].
routers, an important consideration in many LLN application domains.
The route discovery process may result in the discovery of several The route discovery process may result in the discovery of several
good enough routes. This document does not specify how does the routes. This document does not specify how the target selects routes
target node select routes among the good enough ones. Example among the ones discovered. Example selection methods include
selection methods include selecting the routes as they are discovered selecting routes as they are discovered or selecting the best routes
or selecting the best routes discovered over a certain time period. discovered over a certain time period.
If the origin node had requested the discovery of backward source- If the origin had requested the discovery of backward source-routes,
routes, the target node caches one or more good enough source-routes the target caches one or more discovered source-routes.
it selects. Additionally, the target node sends one or more Additionally, the target sends one or more "Discovery Reply" messages
"Discovery Reply" message to the origin node to acknowledge the to the origin to acknowledge the discovery of these routes.
discovery of these routes. These acknowledgements allow the origin
node to judge the success of the route discovery.
If the origin node had requested the discovery of "n" forward source- If the origin had requested the discovery of "n" forward source-
routes, the target node sends the "n" good enough source-routes it routes, the target sends "n" discovered source-routes it selects to
selects to the origin node in one or more Discovery Reply messages. the origin in one or more Discovery Reply messages.
If the origin node had requested the discovery of "n" bidirectional If the origin had requested the discovery of "n" bidirectional
source-routes, the target node caches the "n" good enough source- source-routes, the target caches "n" discovered source-routes it
routes it identifies and also sends these routes to the origin node selects and also sends these routes to the origin in one or more
in one or more Discovery Reply messages. Discovery Reply messages.
If the origin node had requested the discovery of "n" forward/ If the origin had requested the discovery of "n" forward/backward/
backward/bidirectional hop-by-hop routes, the target node sends out a bidirectional hop-by-hop routes, the target sends out a Discovery
Discovery Reply message to the origin node for each one of the "n" Reply message to the origin for each one of the "n" discovered routes
good enough routes it selects. The Discovery Reply message travels it selects. The Discovery Reply message travels towards the origin
towards the origin node along the discovered route. As this message along the discovered route. As this message travels towards the
travels towards the origin node, it establishes appropriate forward/ origin, it establishes appropriate forward/backward routing state in
backward routing state in the routers on the path. the routers on the path.
5. Propagation of Discovery Messages 6. Propagation of Discovery Messages
RPL uses DIO message propagation to build a DAG. The DIO message RPL uses DIO message propagation to build a DAG. The DIO message
travels via IPv6 link-local multicast. Each node joining the DAG travels via IPv6 link-local multicast. Each node joining the DAG
determines a rank for itself and ignores the subsequent DIO messages determines a rank for itself and ignores the subsequent DIO messages
received from lower (higher in numerical value) ranked neighbors. received from lower (higher in numerical value) ranked neighbors.
Thus, the DIO messages propagate outward from the DAG root rather Thus, the DIO messages propagate outward from the DAG root rather
than return inward towards the DAG root. The DIO message generation than return inward towards the DAG root. The DIO message generation
at a node is further controlled by a trickle timer that allows a node at a node is further controlled by a trickle timer that allows a node
to avoid generating unnecessary messages [I-D.ietf-roll-trickle]. to avoid generating unnecessary messages [I-D.ietf-roll-trickle].
The link-local multicast based propagation, trickle-controlled The link-local multicast based propagation, trickle-controlled
generation and the rank-based poisoning of messages traveling in the generation and the rank-based poisoning of messages traveling in the
wrong direction (towards the DAG root) provide powerful incentives to wrong direction (towards the DAG root) provide powerful incentives to
use the DIO message as the Discovery message and propagate the DIO/ use the DIO message as the Discovery message and propagate the DIO/
Discovery message by creating a "temporary" DAG. The routing metrics Discovery message by creating a "temporary" DAG. Such an approach
also allows reuse of the routing metrics, objective function and
packet forwarding framework developed for RPL. The routing metrics
used for the creation of this temporary DAG SHOULD be same as (or be used for the creation of this temporary DAG SHOULD be same as (or be
a subset of) the routing metrics being used for route discovery. a subset of) the routing metrics being used for route discovery.
Similarly, the objective function, used for rank calculation in the Similarly, the objective function, used for rank calculation in the
temporary DAG, SHOULD be same as the objective function that temporary DAG, SHOULD be same as the objective function that
determines the aggregated cost of a route when limited to the routing determines the aggregated cost of a route when limited to the routing
metrics being used for temporary DAG creation. metrics being used for temporary DAG creation.
The propagation constraints limit the spread of the temporary DAG. The propagation constraints limit the spread of the temporary DAG.
The temporary DAG restricts the network topology within which the The temporary DAG restricts the network topology within which the
route discovery takes place. Thus, all the discovered routes lie route discovery takes place. The routes accumulated by the DIOs lie
within this restricted topology and implicitly satisfy the within this restricted topology and implicitly satisfy the
propagation constraints. Among the discovered routes, the good propagation constraints. As the target receives a DIO, it
enough routes are the ones that meet the route constraints. Thus, additionally applies the route constraints on the accumulated route.
for successful route discovery, the propagation constraints and the Thus, for successful route discovery, the propagation constraints and
route constraints MUST be compatible. The division of the overall the route constraints MUST be compatible. The division of the
good enough criteria between the two sets of constraints is an overall constraints in the two categories is an implementation
implementation specific decision. If desired, an implementation MAY specific decision. If desired, an implementation MAY consider all
include all constraints in the set of propagation constraints and the constraints as propagation constraints and keep the set of route
keep the set of route constraints empty. constraints empty.
5.1. The Route Discovery Option 6.1. The Route Discovery Option
0 1 2 3 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 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 |H| N | L |O| Reserved | | Type = 9 | Option Length | D |H| N | L |O|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Target Address | | Target Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Metric Container |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OCP | | OCP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of the Route Discovery Option Figure 1: Format of the Route Discovery Option
In order to be used as a Discovery message, a DIO MUST carry a "Route 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 Discovery" option illustrated in Figure 1. A DIO MUST NOT carry more
than one Route Discovery options. A router MUST ignore the second than one Route Discovery options. A router MUST ignore the second
and subsequent Route Discovery options carried by a DIO. A Route and subsequent Route Discovery options carried by a DIO. A Route
Discovery option consists of the following fields: Discovery option consists of the following fields:
o Option Type = 0x09 (to be confirmed by IANA). o Option Type = 0x09 (to be confirmed by IANA).
o Option Length = 20 or 22 octets depending on whether the OCP field o Option Length = The length of Route Discovery option including any
is included or not. Metric Container and OCP fields.
o D: A 2-bit field that indicates the direction of the desired o D: A 2-bit field that indicates the direction of the desired
routes: routes:
* D = 0x00: Forward; * D = 0x00: Forward;
* D = 0x01: Backward; * D = 0x01: Backward;
* D = 0x02: Bidirectional. * D = 0x02: Bidirectional.
The D field also specifies the direction in which the link-level
metrics being used for route discovery should be measured.
o H: This flag, when set, indicates if hop-by-hop routes are o H: This flag, when set, indicates if hop-by-hop routes are
desired. The flag is cleared if source routes are desired. desired. The flag is cleared if source routes are desired.
o N: A 3-bit unsigned integer indicating the number of routes o N: A 3-bit unsigned integer indicating the number of routes
desired. desired. Used when forward or bidirectional routes are being
discovered.
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. o L: A 4-bit field containing an exponent of 2, such that 2 raised
to the power L specifies, in units of seconds, 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.
o O: This flag, when set, indicates that an OCP field is present in o O: This flag, when set, indicates that an OCP field is present in
the Route Discovery option. the Route Discovery option.
o Target Address: The IPv6 address of the target node. o Target Address: The IPv6 address of the target.
o Metric Container: Contains the route constraints that the target
MUST apply. Any metric objects contained in this metric container
MUST be ignored.
o OCP: 16 bit unsigned integer. An optional field, present only if o OCP: 16 bit unsigned integer. An optional field, present only if
the O flag is set, This field indicates the objective function the O flag is set, This field indicates the objective function
that MAY be used by the target node to compare two good enough that MAY be used by the target to compare two discovered routes.
routes.
5.2. Setting a DIO Carrying a Route Discovery Option 6.2. Setting a DIO Carrying a Route Discovery Option
A DIO message that carries a Route Discovery option MUST set the Base 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: Object, described in [I-D.ietf-roll-rpl], in the following manner:
o RPLInstanceID: RPLInstanceID MUST be a local value as described in o RPLInstanceID: RPLInstanceID MUST be a local value as described in
Section 4.1 of [I-D.ietf-roll-rpl]. Section 5.1 of [I-D.ietf-roll-rpl]. The origin MUST ensure that
different RPLInstanceID values are used in two or more concurrent
route discoveries it initiates.
o Grounded (G) Flag: MUST be cleared since the objective of DAG o Grounded (G) Flag: MUST be cleared since the objective of DAG
formation is the propagation of Route Discovery option. This DAG formation is propagation of Route Discovery option. This DAG is
is temporary in nature and is not used for routing purpose. temporary in nature and is not used for routing purpose.
o Destination Advertisement Supported (A) Flag: MUST be cleared for o Destination Advertisement Supported (A) Flag: MUST be cleared for
same reasons as described above. same reasons as described above.
o Destination Advertisement Trigger (T) Flag: MUST be cleared. o Destination Advertisement Trigger (T) Flag: MUST be cleared.
o Mode of Operation (MOP): This document suggests a new value (0x04) o Mode of Operation (MOP): This document suggests a new value (0x04)
for this field (to be confirmed by IANA). for this field (to be confirmed by IANA).
o DODAGPreference (Prf): TBD o DODAGPreference (Prf): TBD
o Destination Advertisement Trigger Sequence Number (DTSN): TBD o Destination Advertisement Trigger Sequence Number (DTSN): TBD
o DODAGID: IPv6 address of the origin node. o DODAGID: IPv6 address of the origin.
The other fields in the Base Object are set as per the rules The other fields in the Base Object are set as per the rules
described in [I-D.ietf-roll-rpl]. described in [I-D.ietf-roll-rpl].
The DODAG Configuration option, carried in the DIO message, specifies The DODAG Configuration option, carried in the DIO message, specifies
the parameters for the trickle timer operation that governs the the parameters for the trickle timer operation that governs the
generation of DIO messages by the routers joining the temporary DAG. generation of DIO messages by routers joining the temporary DAG. The
The future versions of this document will specify the default values future versions of this document will specify the default values to
to be used for these parameters. The other fields defined in the be used for these parameters. The other fields defined in the DODAG
DODAG Configuration option are set as follows: Configuration option are set as follows:
o The MaxRankIncrease field MUST be set to 0 to disable local repair o The MaxRankIncrease field MUST be set to 0 to disable local repair
of the temporary DAG. of the temporary DAG.
o This document RECOMMENDS a value 1 for the MinHopRankInc field. o This document RECOMMENDS a value 1 for the MinHopRankInc field.
o Objective Code Point (OCP): The OCP to be used for temporary DAG o Objective Code Point (OCP): The OCP to be used for temporary DAG
formation. This document RECOMMENDS RPL Objective Function 0, as formation. The objective function used for temporary DAG
defined in [I-D.ietf-roll-of0], for use as the objective function formation SHOULD be compatible with the objective function to
for the formation of the temporary DAG. The objective function determine the aggregated cost of a discovered route.
used for temporary DAG formation SHOULD be compatible with the
objective function to determine the aggregated cost of a
discovered route.
A DIO, that contains a Route Discovery option, MUST specify the A DIO, that contains a Route Discovery option, MUST specify the
propagation constraints in one or more Metric Container options propagation constraints in one or more Metric Container options
placed before the Route Discovery option and the route constraints in placed outside the Route Discovery option. As mentioned before, the
the Metric Container options placed after the Route Discovery option route constraints are listed in the Metric Container option placed
inside the DIO. The routing metrics being used for temporary DAG inside the Route Discovery option. The routing metrics being used
formation SHOULD be same as or a subset of the routing metrics being for temporary DAG formation SHOULD be same as or a subset of the
used for route discovery. These routing metrics MUST be placed in routing metrics being used for route discovery. These routing
the Metric Container options placed before the Route Discovery metrics MUST be placed in the Metric Container options placed outside
option. the Route Discovery option. Any link-level metrics being used for
route discovery MUST be measured in the direction indicated by the D
field in Route Discovery option. Any metric object contained inside
the Metric Container inside the Route Discovery option MUST be
ignored.
A DIO, carrying a Route Discovery option, MUST NOT carry any Route A DIO, carrying a Route Discovery option, MUST NOT carry any Route
Information or Prefix Information options described in Information or Prefix Information options described in
[I-D.ietf-roll-rpl]. [I-D.ietf-roll-rpl].
5.3. Joining a Temporary DAG 6.3. Joining a Temporary DAG
When a node joins a temporary DAG advertized by a DIO carrying the When a node joins a temporary DAG advertized by a DIO carrying the
Route Discovery option, it MUST maintain its membership in the DAG Route Discovery option, it MUST maintain its membership in the DAG
for the Minimum Life Time duration listed in the Route Discovery for the Minimum Life Time duration listed in the Route Discovery
option. Maintaining membership in the DAG implies remembering: option. Maintaining membership in the DAG implies remembering:
o The RPLInstanceID, the DODAGID and the DODAGVersionNumber for the o The RPLInstanceID, the DODAGID and the DODAGVersionNumber for the
temporary DAG; temporary DAG;
o The node's rank in the temporary DAG as well as the address of at o The node's rank in the temporary DAG as well as the address of at
least one DAG parent; least one DAG parent;
o The propagation and the route constraints being used; o The propagation and the route constraints being used;
o In case of intermediate routers, the values for the routing o In case of intermediate routers, the values for the routing
metrics, along with the associated source route from the origin metrics, along with the associated source route from the origin
node till this node (carried in a Record Route IPv6 Extension untill this node (carried in a Record Route IPv6 Extension Header
Header proposed in [I-D.thubert-6man-reverse-routing-header]), proposed in [I-D.thubert-6man-reverse-routing-header]), contained
contained in the best DIO (as per the OCP specified in the DODAG in the best DIO (in terms of the routing metrics and potentially
Configuration option) received so far. using the OCP specified in the DODAG Configuration option)
received so far.
Although the main purpose of a temporary DAG's existence is to Although the main purpose of a temporary DAG's existence is to
facilitate the propagation of the Route Discovery option, the facilitate the propagation of the Route Discovery option, the
temporary DAG MAY also be used for the Discovery Reply Object temporary DAG MAY also be used for the Discovery Reply Object
(defined in Section 6.1 to travel from the target node to the origin (defined in Section 7.1 to travel from the target to the origin.
node. Hence, a node in a temporary DAG SHOULD also remember the Hence, a node in a temporary DAG SHOULD also remember the address of
address of at least one DAG parent that provides, as per the node's at least one DAG parent that provides the best known path back to the
knowledge, the best end-to-end route back to the origin node. A node origin. A node SHOULD delete information about a temporary DAG once
SHOULD delete information about a temporary DAG once the duration of the duration of its membership in the DAG has exceeded the DAG's
its membership in the DAG has exceeded the DAG's minimum life time. minimum life time.
5.4. Processing a DIO Carrying a Route Discovery Option 6.4. Processing a DIO Carrying a Route Discovery Option
The rules for DIO processing and transmission, described in Section 7 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 of RPL [I-D.ietf-roll-rpl], apply to DIOs carrying a Route Discovery
option as well except as modified in this document. option as well except as modified in this document.
The following rules for processing a DIO carrying a Route Discovery The following rules for processing a DIO carrying a Route Discovery
Option apply to both intermediate routers and the target nodes. Option apply to both intermediate routers and the target.
A node MUST discard the DIO with no further processing and optionally
log an error if any of the following conditions are true:
o The node does not support the OCP specified in the DODAG A node MUST discard a DIO with no further processing if:
Configuration option.
o The node does not support one or more of the metrics contained in o The DIO contains two or more Route Discovery options;
the Metric Container options in the DIO.
o The node does not have sufficient information to calculate the o The node can not evaluate one or more of the propagation
values of these routing metrics. constraints listed in a Metric Container inside the DIO.
A node MUST discard the DIO with no further processing and optionally A node MUST discard a DIO with no further processing if any of the
log an error if any of the following conditions are found to be true following conditions are found to be true while processing a Route
while processing a Route Discovery option contained in the received Discovery option contained in that DIO:
DIO:
o The H field is set, i.e. hop-by-hop routes are desired, but the o The H field is set, i.e., hop-by-hop routes are desired, and the
node cannot participate in a hop-by-hop route. node chooses not to participate in a hop-by-hop route;
o The node cannot maintain its membership in the temporary DAG for o The node cannot maintain its membership in the temporary DAG for
the minimum life time duration mentioned in the Route Discovery the minimum life time specified in the Route Discovery option.
option.
5.5. Additional Processing of a DIO Carrying a Route Discovery Option A node MUST update the values of link-level routing metrics included
inside the DIO in accordance with the D field in the Route Discovery
option. If the D field is 0x00, i.e., the forward routes are being
discovered, any link-level routing metric MUST be measured in the
direction towards the node receiving the DIO. If the D field is
0x01, i.e., the backward routes are being discovered, any link-level
routing metric MUST be measured in the direction towards the node
originating the DIO. If the D field is 0x02, i.e., the bidirectional
routes are being discovered, any link-level routing metric MUST be
calculated so as to take in account the metric's value in both
directions. The rules for calculating bidirectional metric values
will be specified in a separate document.
6.5. Additional Processing of a DIO Carrying a Route Discovery Option
At An Intermediate Router At An Intermediate Router
After executing the steps listed in Section 5.4, an intermediate An intermediate router MUST process a received DIO, carrying a Route
router processes a received DIO carrying a Route Discovery option in Discovery option, in accordance with the following rules.
the following manner.
The router updates the routing metric values contained in all the An intermediate router MUST discard the DIO with no further
Metric Container options inside the DIO. The router MUST discard the processing if the routing metric values do not satisfy one or more
DIO with no further processing and optionally log an error if the propagation constraints listed in the DIO. The router MAY check the
aggregated values of the routing metrics do not meet every route constraints listed inside the Route Discovery option and
propagation constraint listed in the DIO. The router MAY optionally discard the DIO with no further processing if these constraints are
check the route constraints listed in the DIO and discard the DIO not met.
with no further processing if these constraints are not met.
The router determines if this DIO is the best it has received so far An intermediate router MUST determine if this DIO is the best it has
for this temporary DAG (as per the OCP in the DODAG Configuration received so far for this temporary DAG in terms of the routing
object). If yes, the router makes a copy of the routing metric metrics (potentially using the OCP in the DODAG Configuration
values contained in this DIO along with the route travelled by the object). If yes, the intermediate router MUST remember the routing
DIO so far. The router also resets the trickle timer and, at the metric values contained in this DIO along with the route travelled by
expiry of the timer, generates a new DIO for this temporary DAG the DIO so far and reset the trickle timer associated with the
temporary DAG.
When the trickle timer associated with the temporary DAG fires, an
intermediate router MUST generate a new DIO for this temporary DAG
carrying the Route Discovery option, the best metric values it knows carrying the Route Discovery option, the best metric values it knows
and the source route associated with these values (in a Record Route and the source route associated with these values (in a Record Route
IPv6 extension header proposed in IPv6 extension header [I-D.thubert-6man-reverse-routing-header]).
[I-D.thubert-6man-reverse-routing-header]).
5.6. Additional Processing of a DIO Carrying a Route Discovery Option 6.6. Additional Processing of a DIO Carrying a Route Discovery Option
At The Target Node At The Target Node
After executing the steps listed in Section 5.4, a target node A node MUST process a received DIO, carrying a Route Discovery option
processes a received DIO carrying a Route Discovery option in the that lists this node as the target, in accordance with the following
following manner. rules.
The target node updates the routing metric values contained in all A target MUST discard the DIO with no further processing if it can
the Metric Container options inside the DIO. The target node MUST not evaluate the route constraints listed inside the Route Discovery
discard the DIO with no further processing and optionally log an option or if the routing metric values do not satisfy one or more of
error if the aggregated values of the routing metrics do not meet the propagation and route constraints.
every propagation and route constraint listed in the Metric Container
options in the DIO.
Otherwise, the target node considers the source route accumulated by Otherwise, the target considers the source route accumulated by the
the received DIO as good enough and MAY select it as one of the received DIO as one of the discovered routes. This document does not
discovered routes. This document does not prescribe a particular prescribe a particular method for selecting routes among the
method for selecting routes among the good enough ones. Suppose the discovered ones. Suppose the Route Discovery option requires the
Route Discovery option requires the target node to select "n" good discovery of "n" routes. The target may select these "n" routes in
enough routes. The target node may select these "n" routes in any any manner it desires. Example selection methods include selecting
manner it desires. Example selection methods include selecting the the first "n" routes it discovers or selecting the "n" best routes
first "n" good enough routes it discovers or selecting the "n" best discovered over a certain time period, potentially using the OCP
good enough routes (using the OCP specified in the Route Discovery specified in the Route Discovery option for route comparison.
option to do the comparison) discovered over a certain time period.
If the target node selects at least one good enough route, it MUST After selecting one or more discovered routes, the target MUST send
send one or more RPL Control Messages carrying a Discovery Reply one or more RPL Control Messages carrying a Discovery Reply Object
Object (defined in the next section) back to the origin node (defined in the next section) back to the origin (identified by the
(identified by the DODAGID field in the DIO Base Object) as discussed DODAGID field in the DIO Base Object) as specified in Section 7.
in the following sections.
A node MUST NOT forward a DIO carrying a Route Discovery option that A target MUST NOT forward a DIO carrying a Route Discovery option any
lists one of its own addresses as the Target Address. further.
6. Propagation of Discovery Reply Messages 7. Propagation of Discovery Reply Messages
6.1. The Discovery Reply Object (DRO) 7.1. The Discovery Reply Object (DRO)
0 1 2 3 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 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 |H| N | Reserved | | RPLInstanceID | Version | D |H| N | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| DODAGID(*) | | DODAGID(*) |
| | | |
| | | |
skipping to change at page 14, line 28 skipping to change at page 15, line 28
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 2: Format of the Discovery Reply Object (DRO) Figure 2: Format of the Discovery Reply Object (DRO)
This document defines a new RPL Control Message type, the Discovery This document defines a new RPL Control Message type, the Discovery
Reply Object (DRO) with code 0x04 (to be confirmed by IANA), that Reply Object (DRO) with code 0x04 (to be confirmed by IANA), that
serves the following functions: serves one of the following functions:
o An acknowledgement from the target node to the origin node o An acknowledgement from the target to the origin regarding the
regarding the successful discovery of backward source routes; successful discovery of backward source routes;
o Carries one or more forward/bidirectional source routes from the o Carries one or more forward/bidirectional source routes from the
target to the origin node; target to the origin;
o Establishes a hop-by-hop forward/backward/bidirectional route as o Establishes one hop-by-hop forward/backward/bidirectional route as
it travels from the target to the origin node. it travels from the target to the origin.
The format for a Discovery Reply Object (DRO) is shown in Figure 2. The format for a Discovery Reply Object (DRO) is shown in Figure 2.
A DRO consists of the following fields: A DRO consists of the following fields:
o RPLInstanceID: The RPLInstanceID of the temporary DAG used for o RPLInstanceID: The RPLInstanceID of the temporary DAG used for
route discovery. route discovery.
o Version: The Version of the temporary DAG used for route o Version: The Version of the temporary DAG used for route
discovery. discovery.
skipping to change at page 15, line 14 skipping to change at page 16, line 14
* D = 0x00: Forward; * D = 0x00: Forward;
* D = 0x01: Backward; * D = 0x01: Backward;
* D = 0x02: Bidirectional. * D = 0x02: Bidirectional.
This field has the same value as the corresponding field in the This field has the same value as the corresponding field in the
Route Discovery option. Route Discovery option.
o H: A flag that is set if the Discovery Reply Object is o H: A flag that is set if the DRO is establishing an hop-by-hop
establishing an hop-by-hop route. If this flag is set, the route. If this flag is set, the DRO MUST travel from the target
Discovery Reply Object also includes: to the origin along the hop-by-hop route being established and
MUST include one Source Route option (defined in Section 7.1.1)
that contains the remaining routers on this route (as described in
Section 7.4). Since the state that a node needs to maintain
regarding a hop-by-hop route includes the RPLInstanceID, the
DODAGID and the IPv6 address of the route's destination, a DRO
with H flag set MUST also include:
* The DODAGID and Target Address fields; and * The DODAGID of the temporary DAG used for route discovery; and
* One Source Route option (defined in Section 6.1.1) that * The Target Address if the hop-by-hop route is forward or
contains the remaining routers on the hop-by-hop route being bidirectional.
established.
This flag is clear if the Discovery Reply Object carries (or is an The H flag MUST be clear if the DRO carries (or is an
acknowledgement for the discovery of) one or more source routes acknowledgement for the discovery of) one or more source routes
contained in the Source Route options. contained in the Source Route options. The target can unicast
such a DRO to the origin or send it along the temporary DAG used
for route discovery. If the DRO is unicast to the origin, it MUST
NOT include the DODAGID and Target Address fields. If the DRO is
sent along the temporary DAG, it MUST include the DODAGID field
and MUST NOT include the Target Address field.
o N: A 3-bit field that indicates the number of source routes o N: A 3-bit field that indicates the number of source routes
carried or acknowledged in the Discovery Reply Object. This field carried or acknowledged in the DRO. This field MUST have value 1
MUST have value 1 if the Discovery Reply Object is establishing a if the DRO is establishing a hop-by-hop route.
hop-by-hop route.
o Reserved: These bits are reserved for future use. These bits MUST o Reserved: These bits are reserved for future use. These bits MUST
be set to zero on transmission and MUST be ignored on reception. be set to zero on transmission and MUST be ignored on reception.
o DODAGID: The DODAGID of the temporary DAG used for route o DODAGID: The DODAGID of the temporary DAG used for route
discovery. The DODAGID also identifies the origin node. This is discovery. The DODAGID also identifies the origin. This field
an optional field that MUST be present in the Discovery Reply MUST be present in the DRO if the H flag is set or if the H flag
Object if H flag is set. The RPLInstanceID, the Version and the is clear but the DRO needs to travel along the temporary DAG.
DODAGID together uniquely identify the temporary DAG used for Otherwise, this field need not be present in the DRO. The
route discovery and can be copied from the Base Object of the DIO RPLInstanceID, the Version and the DODAGID together uniquely
advertizing the temporary DAG. identify the temporary DAG used for route discovery and can be
copied from the Base Object of the DIO advertizing the temporary
DAG.
o Target Address: The IPv6 address of the target node originating o Target Address: The IPv6 address of the target generating the
the Discovery Reply Object. This is an optional field that MUST Discovery Reply Object. This field MUST be present in the DRO if
be present in the Discovery Reply Object if H flag is set. the H flag is set and the hop-by-hop route being established is
forward or bidirectional.
o Options: The Discovery Reply Object MAY carry up to N Source Route o Options: The Discovery Reply Object MAY carry up to N Source Route
options (defined in the next section) with each such option options (defined in the next section) with each such option
carrying a source route and optionally followed by a Metric carrying a source route and optionally followed by a Metric
Container option that lists the aggregated values for the routing Container option that lists the aggregated values for the routing
metrics for the source route. metrics for the source route.
6.1.1. The Source Route Option 7.1.1. The Source Route Option
0 1 2 3 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 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 | D | Resvd | | Type = 10 | Option Length | Compr | Pad | D | Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Address[1..n] . . Address[1..n] .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of the Source Route Option Figure 3: Format of the Source Route Option
The Source Route option, illustrated in Figure 3, carries a source The Source Route option, illustrated in Figure 3, carries a source
route. A Source Route option MAY be a part of the Discovery Reply route. When a Source Route option carries a complete source route
Object. When a Source Route option carries a complete source route between the origin and the target, it MAY be immediately followed by
between the origin and the target node, it MAY be immediately a Metric Container option that contains the aggregated values of the
followed by a Metric Container option that contains the aggregated routing metrics for this source route.
values of the routing metrics for this source route.
A Source Route option consists of the following fields: A Source Route option consists of the following fields:
o Option Type = 0x0A (to be confirmed by IANA). o Option Type = 0x0A (to be confirmed by IANA).
o Option Length = Variable, depending on the size of the Addresses o Option Length = Variable, depending on the size of the Addresses
vector. vector.
o Compr: 4-bit unsigned integer indicating the number of prefix o Compr: 4-bit unsigned integer indicating the number of prefix
octets that are elided from each address. For example, Compr octets that are elided from each address. For example, Compr
value will be 0 if full IPv6 addresses are carried in the value will be 0 if full IPv6 addresses are carried in the
Addresses vector. Addresses vector.
o Pad: 4-bit unsigned integer. Number of octets that are used for 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. padding between Address[n] and the end of the Source Route option.
o D: A 2-bit field that indicates the direction of the source route: o D: A 2-bit field that indicates the direction of the source route:
* D = 0x00: Forward, i.e. from the origin node to the target * D = 0x00: Forward, i.e., from the origin to the target;
node;
* D = 0x01: Backward i. e., from the target node to the origin * D = 0x01: Backward i. e., from the target to the origin;
node;
* D = 0x02: Bidirectional. * D = 0x02: Bidirectional.
Note that the D field in a Source Route option is independent from Note that the D field in a Source Route option is independent from
the D field in the DRO containing the Source Route option. the D field in the DRO containing the Source Route option.
o Resvd: These bits are reserved for future use. These bits MUST be o Resvd: These bits are reserved for future use. These bits MUST be
set to zero on transmission and MUST be ignored on reception. set to zero on transmission and MUST be ignored on reception.
o Address[1..n]: Vector of addresses, numbered 1 to n. Each vector o Address[1..n]: Vector of addresses, numbered 1 to n. Each vector
skipping to change at page 17, line 32 skipping to change at page 18, line 43
Address of the encapsulating Discovery Reply Object. The shared Address of the encapsulating Discovery Reply Object. The shared
prefix octets are not carried within the Source Route option and each 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 entry in Address[1..n] has size (16 - Compr) octets. When Compr is
non-zero, there may exist unused octets between the last entry, non-zero, there may exist unused octets between the last entry,
Address[n], and the end of the Source Route option. The Pad field Address[n], and the end of the Source Route option. The Pad field
indicates the number of unused octets that are used for padding. 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. 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 The Source Route option MUST NOT specify a path that visits a router
more than once. When generating a Source Route option, the target more than once. When generating a Source Route option, the target
node may not know the mapping between IPv6 addresses and routers. may not know the mapping between IPv6 addresses and routers.
Minimally, the target node MUST ensure that: Minimally, the target MUST ensure that:
o The IPv6 Addresses do not appear more than once; o The IPv6 Addresses do not appear more than once;
o The IPv6 addresses of the origin and the target nodes do not o The IPv6 addresses of the origin and the target do not appear in
appear in the Address vector. the Address vector.
Multicast addresses MUST NOT appear in a Source Route option. Multicast addresses MUST NOT appear in a Source Route option.
6.1.2. Processing a DRO At An Intermediate Router 7.1.2. Processing a DRO At An Intermediate Router
When an intermediate router receives a DRO with a clear H flag, it When an intermediate router receives a DRO with a clear H flag, it
MUST forward the DRO to a parent node in the temporary DAG. MUST forward the DRO to a parent node in the temporary DAG.
When an intermediate router receives a DRO that has H flag set and When an intermediate router receives a DRO that has H flag set and
contains multiple Source Route options, the router MUST drop the DRO contains multiple Source Route options, the router MUST drop the DRO
with no further processing and optionally log an error message. with no further processing.
When an intermediate router receives a DRO that has H flag set and When an intermediate router receives a DRO that has H flag set and
contains a single Source Route option, the router processes the DRO contains a single Source Route option, the router processes the DRO
as described in Section 6.4. as described in Section 7.4.
6.2. DRO as Acknowledgement for Backward Source Routes
After selecting one or more backward source routes, a target node 7.2. DRO as Acknowledgement for Backward Source Routes
MUST send a DRO message to the origin node as an acknowledgement for
the discovered routes. Such an acknowledgement helps the origin node
determine the success of route discovery.
A DRO, serving as an acknowledgement for backward source route After selecting one or more backward source routes, a target MAY send
discovery, has its D field set to 0x01 (indicating backward) while a DRO message to the origin as an acknowledgement for the discovered
the H flag is cleared (indicating source route). The N field is set routes. A DRO, serving as an acknowledgement for backward source
to indicate the number of discovered backward source routes being route discovery, has its D field set to 0x01 (indicating backward)
acknowledged. Such a DRO message MUST NOT contain any option. while the H flag is cleared (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.
The target node MAY unicast this DRO message to the origin node or it The target MAY unicast this DRO message to the origin or it MAY
MAY forward the DRO message to a parent in the temporary DAG. The forward the DRO message to a parent in the temporary DAG. The target
target node should take in consideration the minimum life time of the should take into consideration the minimum life time of the temporary
temporary DAG when deciding to use it to send the DRO to the origin DAG when deciding to use it to send the DRO to the origin.
node.
6.3. DRO as Carrier of Forward/Bidirectional Source Routes 7.3. DRO as Carrier of Forward/Bidirectional Source Routes
The target node conveys the discovered forward/bidirectional source The target MUST convey the discovered forward/bidirectional source
routes to the origin node via the Source Route options inside one or routes to the origin via the Source Route options inside one or more
more DRO messages. Such a DRO message MUST have its D field set to DRO messages. Such a DRO message MUST have its D field set to 0x00
0x00 (if it carries forward routes) or 0x02 (if its carries (if it carries forward routes) or 0x02 (if its carries bidirectional
bidirectional routes). Also, the H flag MUST be cleared and the N routes). Also, the H flag MUST be cleared and the N field MUST
field MUST indicate the number of Source Route options in the DRO. indicate the number of Source Route options in the DRO. Each Source
Each Source Route option inside the DRO MAY immediately be followed Route option inside the DRO MAY immediately be followed by a Metric
by a Metric Container option that carries the aggregated values of Container option that carries the aggregated values of the relevant
the relevant routing metrics for this source route. routing metrics for this source route.
The target node MAY unicast this DRO message to the origin node or it The target MAY unicast this DRO message to the origin or it MAY
MAY forward the DRO message to a parent in the temporary DAG. The forward the DRO message to a parent in the temporary DAG. The target
target node should take in consideration the minimum life time of the should take into consideration the minimum life time of the temporary
temporary DAG when deciding to use it to send the DRO to the origin DAG when deciding to use it to send the DRO to the origin.
node.
6.4. Establishing Hop-by-hop Routes Via DRO 7.4. Establishing Hop-by-hop Routes Via DRO
In order to establish a hop-by-hop route, the target node sends a DRO In order to establish a hop-by-hop route, the target MUST send a DRO
message along the discovered route, which is specified in a Source message along the discovered route, which is specified in a Source
Route option. The D field in the DRO is set to reflect the direction Route option. The D field in the DRO MUST reflect the direction of
of the discovered route. The H bit in the DRO MUST be set and the the discovered route. The H bit in the DRO MUST be set and the DRO
DRO MUST include the DODAGID and Target Address fields. The N field MUST include the DODAGID field. If a forward or bidirectional hop-
in the DRO MUST be set to 1. The target node forwards the DRO to the by-hop route is being established, the DRO MUST include the Target
next hop along the discovered route and includes the discovered Address field as well. The N field in the DRO MUST be set to 1 and
route, excluding itself and the origin node, inside the Source Route the DRO MUST include exactly one Source Route option. The target
option in backward direction. Thus, the D field in the Source Route forwards the DRO to the next hop along the discovered route and
option MUST be 0x01. includes the discovered route, excluding itself and the origin,
inside the Source Route option in backward direction. Thus, the D
A router receiving a DRO message MUST drop the DRO and optionally log field in the Source Route option MUST be 0x01.
an error if the router cannot establish the hop-by-hop state for the
route or if its own address does not lie as the first element in the
Address vector inside the Source Route option. Otherwise, the router
MUST establish the hop-by-hop state in the direction specified in the
D field in the DRO. The hop-by-hop state in the forward direction
includes the RPLInstanceID, the DODAGID and the target node's
address. The hop-by-hop state in the backward direction includes the
RPLInstanceID, the DODAGID and the origin node's address. After
establishing the hop-by-hop state, the router MUST remove its own
address from the route contained in the Source Route option and
forward the DRO to the next hop (Address[0] in the Source Route
option).
7. Applicability
The route discovery mechanism described in this document may be If the hop-by-hop route is in the backward direction, the target MUST
invoked by an origin node when no route exists between itself and the establish the hop-by-hop state for the route before sending the DRO
target node or when the existing routes do not satisfy the desired message. Such hop-by-hop state includes the RPLInstanceID, the
performance requirements. The mechanism is designed to discover one DODAGID and the route's destination ( in this case, the origin's
or more "good enough" routes in either direction between an origin address or the DODAGID).
and a target node. In some application contexts, the good enough
criteria is intrinsically known. For example, an origin node that
expects a target node to be less than 5 hops away may use "hop-count
< 5" as the good enough criteria. In other application contexts, the
origin node may need to measure the cost of an existing route to the
target node to determine the good enough criteria. For example, an
origin node that measures the total ETX of its along-DAG route to the
target node to be 20 may use "ETX < x*20", where x is a fraction that
the origin node decides, as the good enough criteria. The
functionality required to measure the cost of an existing route
between the origin and the target node will be described in a
separate document. In case, there is no existing route between the
origin and target nodes or the cost measurement for the existing
route fails, the origin node will have to guess the good enough
criteria for the initial route discovery. Once, the initial route
discovery succeeds or fails, the origin node will have a better
estimate for the good enough criteria to be used in the subsequent
route discovery.
This document describes an on-demand discovery mechanism for P2P A router receiving a DRO message MUST drop the DRO if the router
routes that is complimentary to the proactive routes offered by RPL cannot establish the hop-by-hop state for the route or if its own
base functionality. The mechanism described in this document may address does not appear as the first element in the Address vector in
result in discovery of better P2P routes than the ones available the Source Route option. Otherwise, the router MUST establish the
along a DAG designed to optimize routing cost to the DAG's root. The hop-by-hop state in the direction specified in the D field in the
improvement in route quality depends on a number of factors including DRO. The hop-by-hop state in the forward direction includes the
the network topology, the routing metrics in use and the prevalent RPLInstanceID, the DODAGID and the target's address. The hop-by-hop
conditions in the network. A network designer may take in state in the backward direction includes the RPLInstanceID, the
consideration both the benefits (potentially better routes; no need DODAGID and the origin's address. After establishing the hop-by-hop
to maintain routes proactively) and costs (control messages generated state, the router MUST remove its own address from the route
during the route discovery process) when using this mechanism. contained in the Source Route option and forward the DRO to the next
hop (Address[0] in the Source Route option).
8. Security Considerations 8. Security Considerations
TBA TBA
9. IANA Considerations 9. IANA Considerations
TBA TBA
10. Authors and Contributors 10. Acknowledgements
In addition to the editors, 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: abr@sdesigns.dk
Robert Cragie, Gridmerge Ltd, 89 Greenfield Crescent, Wakefieldm WF4
4WA, UK. Phone: +44 1924910888; Email: robert.cragie@gridmerge.com
Jerald Martocci, Johnson Controls, Milwaukee, WI 53202, USA. Phone:
+1 414 524 4010; Email:jerald.p.martocci@jci.com
Charles Perkins, Tellabs Inc., USA. Email:charliep@computer.org
Authors gratefully acknowledge the contributions of Richard Kelsey Authors gratefully acknowledge the contributions of the following
and Zach Shelby in the development of this document. individuals (in alphabetical order) in the development of this
document: Dominique Barthel, Thomas Clausen, Richard Kelsey, Zach
Shelby, Pascal Thubert and JP Vasseur.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [I-D.goyal-roll-p2p-measurement]
Requirement Levels", BCP 14, RFC 2119, March 1997. Goyal, M. and E. Baccelli, "A Mechanism to Measure the
Quality of a Point-to-point Route in a Low Power and Lossy
11.2. Informative References Network", draft-goyal-roll-p2p-measurement-01 (work in
progress), October 2010.
[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.ietf-6man-rpl-option] [I-D.ietf-6man-rpl-option]
Hui, J. and J. Vasseur, "RPL Option for Carrying RPL Hui, J. and J. Vasseur, "RPL Option for Carrying RPL
Information in Data-Plane Datagrams", Information in Data-Plane Datagrams",
draft-ietf-6man-rpl-option-01 (work in progress), draft-ietf-6man-rpl-option-01 (work in progress),
October 2010. October 2010.
[I-D.ietf-6man-rpl-routing-header] [I-D.ietf-6man-rpl-routing-header]
Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6 Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with RPL", Routing Header for Source Routes with RPL",
draft-ietf-6man-rpl-routing-header-01 (work in progress), draft-ietf-6man-rpl-routing-header-01 (work in progress),
October 2010. October 2010.
[I-D.ietf-roll-of0]
Thubert, P., "RPL Objective Function 0",
draft-ietf-roll-of0-03 (work in progress), July 2010.
[I-D.ietf-roll-routing-metrics] [I-D.ietf-roll-routing-metrics]
Vasseur, J., Kim, M., Networks, D., Dejean, N., and D. Vasseur, J., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics used for Path Calculation in Low Barthel, "Routing Metrics used for Path Calculation in Low
Power and Lossy Networks", Power and Lossy Networks",
draft-ietf-roll-routing-metrics-11 (work in progress), draft-ietf-roll-routing-metrics-17 (work in progress),
October 2010. January 2011.
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
Kelsey, R., Levis, P., Networks, D., Struik, R., and J. Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and Vasseur, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-13 (work in Lossy Networks", draft-ietf-roll-rpl-17 (work in
progress), October 2010. progress), December 2010.
[I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-04 (work in
progress), September 2010.
[I-D.ietf-roll-trickle] [I-D.ietf-roll-trickle]
Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", draft-ietf-roll-trickle-04 (work "The Trickle Algorithm", draft-ietf-roll-trickle-08 (work
in progress), August 2010. in progress), January 2011.
[I-D.thubert-6man-reverse-routing-header] [I-D.thubert-6man-reverse-routing-header]
Thubert, P., "Reverse Routing Header", Thubert, P., "Reverse Routing Header",
draft-thubert-6man-reverse-routing-header-00 (work in draft-thubert-6man-reverse-routing-header-00 (work in
progress), June 2010. progress), June 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.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-01 (work
in progress), November 2010.
[I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-04 (work in
progress), September 2010.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks", Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, April 2010. RFC 5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and "Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, June 2010. Lossy Networks", RFC 5867, June 2010.
Authors' Addresses Authors' Addresses
Mukul Goyal (editor) Mukul Goyal (editor)
University of Wisconsin Milwaukee University of Wisconsin Milwaukee
3200 N Cramer St 3200 N Cramer St
Milwaukee, WI 53211 Milwaukee, WI 53201
USA USA
Phone: +1 414 2295001 Phone: +1 414 2295001
Email: mukul@uwm.edu Email: mukul@uwm.edu
Emmanuel Baccelli (editor) Emmanuel Baccelli
INRIA INRIA
Phone: +33-169-335-511 Phone: +33-169-335-511
Email: Emmanuel.Baccelli@inria.fr Email: Emmanuel.Baccelli@inria.fr
URI: http://www.emmanuelbaccelli.org/ URI: http://www.emmanuelbaccelli.org/
Anders Brandt
Sigma Designs
Emdrupvej 26A, 1.
Copenhagen, Dk-2100
Denmark
Phone: +45-29609501
Email: abr@sdesigns.dk
Robert Cragie
Gridmerge Ltd
89 Greenfield Crescent
Wakefield WF4 4WA
UK
Phone: +44-1924910888
Email: robert.cragie@gridmerge.com
Jerald Martocci
Johnson Controls
507 E Michigan St
Milwaukee, WI 53202
USA
Phone: +1 414-524-4010
Email: jerald.p.martocci@jci.com
Charles Perkins
Tellabs Inc.
charliep@computer.org
 End of changes. 133 change blocks. 
473 lines changed or deleted 495 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/