draft-ietf-roll-p2p-rpl-16.txt   draft-ietf-roll-p2p-rpl-17.txt 
Internet Engineering Task Force M. Goyal, Ed. Internet Engineering Task Force M. Goyal, Ed.
Internet-Draft University of Wisconsin Internet-Draft University of Wisconsin
Intended status: Experimental Milwaukee Intended status: Experimental Milwaukee
Expires: August 7, 2013 E. Baccelli Expires: September 21, 2013 E. Baccelli
M. Philipp M. Philipp
INRIA INRIA
A. Brandt A. Brandt
Sigma Designs Sigma Designs
J. Martocci J. Martocci
Johnson Controls Johnson Controls
February 3, 2013 March 20, 2013
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-16 draft-ietf-roll-p2p-rpl-17
Abstract Abstract
This document specifies a point-to-point route discovery mechanism, This document specifies a point-to-point route discovery mechanism,
complementary to the RPL core functionality. This mechanism allows complementary to the RPL core functionality. This mechanism allows
an IPv6 router to discover "on demand" routes to one or more IPv6 an IPv6 router to discover "on demand" routes to one or more IPv6
routers in the LLN such that the discovered routes meet specified routers in the LLN such that the discovered routes meet specified
metrics constraints. metrics constraints.
Status of this Memo Status of this Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 August 7, 2013. This Internet-Draft will expire on September 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Known Issues/Future Work . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 6 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
6. P2P Route Discovery Mode Of Operation . . . . . . . . . . . . 9 5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 8
6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . . 9 6. P2P Route Discovery Mode Of Operation . . . . . . . . . . . . 10
7. New RPL Control Message Options . . . . . . . . . . . . . . . 12 6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . . 11
7.1. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . 13 7. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . . . 14
7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 16 8. The P2P Discovery Reply Object (P2P-DRO) . . . . . . . . . . . 18
8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 17 8.1. Secure P2P-DRO . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 19 8.2. Setting a P2P-RDO Carried in a P2P Discovery Reply
8.2. Setting a P2P-RDO Carried in a Discovery Reply Object . . 19 Object . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 20 9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 21
9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 20 9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 21
9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 20 9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 22
9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 23 9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 24
9.4. Additional Processing of a P2P Mode DIO At An 9.4. Additional Processing of a P2P Mode DIO At An
Intermediate Router . . . . . . . . . . . . . . . . . . . 24 Intermediate Router . . . . . . . . . . . . . . . . . . . 25
9.5. Additional Processing of a P2P Mode DIO At The Target . . 25 9.5. Additional Processing of a P2P Mode DIO At The Target . . 26
9.6. Processing a DRO At An Intermediate Router . . . . . . . . 26 9.6. Processing a P2P-DRO At An Intermediate Router . . . . . . 27
9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 28 9.7. Processing a P2P-DRO At The Origin . . . . . . . . . . . . 29
10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 29 10. The P2P Discovery Reply Object Acknowledgement
11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 30 (P2P-DRO-ACK) . . . . . . . . . . . . . . . . . . . . . . . . 30
12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 30 11. Secure P2P-RPL Operation . . . . . . . . . . . . . . . . . . . 31
13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 12. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 32
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 13. Interoperability with Core RPL . . . . . . . . . . . . . . . . 33
14.1. Additions to Mode of Operation . . . . . . . . . . . . . . 32 14. Security Considerations . . . . . . . . . . . . . . . . . . . 33
14.2. Additions to RPL Control Message Options . . . . . . . . . 32 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 33 15.1. Additions to Mode of Operation . . . . . . . . . . . . . . 35
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 15.2. Additions to RPL Control Message Options . . . . . . . . . 35
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 15.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 36
16.1. Normative References . . . . . . . . . . . . . . . . . . . 34 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 37
16.2. Informative References . . . . . . . . . . . . . . . . . . 35 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 17.1. Normative References . . . . . . . . . . . . . . . . . . . 37
17.2. Informative References . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
Targeting Low power and Lossy Networks (LLNs), the IPv6 Routing Targeting Low power and Lossy Networks (LLNs), the IPv6 Routing
Protocol for LLNs (RPL) [RFC6550] provides paths along a Directed Protocol for LLNs (RPL) [RFC6550] provides paths along a Directed
Acyclic Graph (DAG) rooted at a single router in the network. Acyclic Graph (DAG) rooted at a single router in the network.
Establishment and maintenance of a DAG is performed by routers in the Establishment and maintenance of a DAG is performed by routers in the
LLN using Destination-Oriented DAG (DODAG) Information Object (DIO) LLN using Destination-Oriented DAG (DODAG) Information Object (DIO)
messages. When two arbitrary routers (neither of which is the DAG's messages. When two arbitrary routers (neither of which is the DAG's
root) need to communicate, the data packets are restricted to travel root) need to communicate, the data packets are restricted to travel
skipping to change at page 3, line 43 skipping to change at page 4, line 43
such routes are considered "good enough" from the application's such routes are considered "good enough" from the application's
perspective. This reactive P2P route discovery mechanism is perspective. This reactive P2P route discovery mechanism is
henceforth referred to as P2P-RPL. henceforth referred to as P2P-RPL.
A mechanism to measure the end-to-end cost of an existing route is A mechanism to measure the end-to-end cost of an existing route is
specified in [I-D.ietf-roll-p2p-measurement]. As discussed in specified in [I-D.ietf-roll-p2p-measurement]. As discussed in
Section 4, measuring the end-to-end cost of an existing route may Section 4, measuring the end-to-end cost of an existing route may
help decide whether to initiate the discovery of a better route using help decide whether to initiate the discovery of a better route using
P2P-RPL and the metric constraints to be used for this purpose. P2P-RPL and the metric constraints to be used for this purpose.
1.1. Known Issues/Future Work
This document is presented as an Experimental specification to This document is presented as an Experimental specification to
facilitate P2P-RPL's deployment in LLN scenarios where reactive P2P facilitate P2P-RPL's deployment in LLN scenarios where reactive P2P
route discovery is considered useful or necessary. It is anticipated route discovery is considered useful or necessary. It is anticipated
that, once sufficient operational experience has been gained, this that, once sufficient operational experience has been gained, this
specification will be revised to progress it on to the Standards specification will be revised to progress it on to the Standards
Track. Experience reports regarding P2P-RPL implementation and Track. Experience reports regarding P2P-RPL implementation and
deployment are encouraged particularly with respect to: deployment are encouraged particularly with respect to:
o The values in the default DODAG Configuration Option o Secure P2P-RPL operation (Section 11);
(Section 6.1);
o The rules governing Trickle operation (Section 9.2); o Rules governing Trickle operation (Section 9.2);
o The utility and the implementation complexity of the Data Option o Values in the default DODAG Configuration Option (Section 6.1);
(Section 7.2) that provides a facility to piggyback time-critical
application data on the routing messages;
o The utility and the implementation complexity of allowing multiple o The RPLInstanceID reuse policy (Section 6.1);
Target addresses in a P2P-RPL route discovery.
o Utility and implementation complexity of allowing multiple Target
addresses in a P2P-RPL route discovery.
2. The Use Cases 2. The Use Cases
One use case, common in home [RFC5826] and commercial building One use case, common in home [RFC5826] and commercial building
[RFC5867] environments, involves a device (say a remote control or an [RFC5867] environments, involves a device (say a remote control) that
airduct controller) that suddenly needs to communicate with another suddenly needs to communicate with another device (say a lamp) to
device (say a lamp or a humidity sensor) to which it does not already which it does not already have a route (and whose network address it
have a route. In this case, the remote control (or the airduct knows apriory). In this case, the remote control must be able to
controller) must be able to discover a route to the lamp (or the discover a route to the lamp "on demand".
humidity sensor) "on demand".
Another use case, common in a commercial building environment, Another use case, common in a commercial building environment,
involves a large LLN deployment where P2P communication along a involves a large LLN deployment where P2P communication along a
particular DAG among hundreds (or thousands) of routers creates particular DAG among hundreds (or thousands) of routers creates
severe traffic congestion near that DAG's root, and thus routes severe traffic congestion near that DAG's root. In this case, it is
across this DAG are desirable. desirable to discover direct routes between various source-
destination pairs that do not pass through the DAG's root.
Other use cases involve scenarios where energy or latency constraints Other use cases involve scenarios where energy or latency constraints
are not satisfied by the P2P routes along an existing DAG because are not satisfied by the P2P routes along an existing 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 [RFC6550]. This Additionally, this document uses terminology from [RFC6550] and
document introduces the following terms: [I-D.ietf-roll-terminology]. This document introduces the following
terms:
Origin : The IPv6 router initiating the P2P-RPL route discovery. Origin : The IPv6 router initiating the P2P-RPL route discovery.
Target : The IPv6 router at the other end point of the P2P route(s) Target : The IPv6 router at the other end point of the P2P route(s)
to be discovered. A P2P-RPL route discovery can discover routes to to be discovered. A P2P-RPL route discovery can discover routes to
multiple Targets at the same time. multiple Targets at the same time.
Intermediate Router: An IPv6 router that is neither the Origin nor a Intermediate Router: An IPv6 router that is neither the Origin nor a
Target. Target.
skipping to change at page 5, line 19 skipping to change at page 6, line 21
Reverse direction: The direction from the Target to the Origin. Reverse direction: The direction from the Target to the Origin.
Forward Route: A route in the Forward direction. Forward Route: A route in the Forward direction.
Reverse Route: A route in the Reverse direction. Reverse Route: A route in the Reverse direction.
Bidirectional Route: A route that can be used in both Forward and Bidirectional Route: A route that can be used in both Forward and
Reverse directions. Reverse directions.
Ingress-only Interface: A network interface that can only receive
packets.
Egress-only Interface: A network interface that can only send
packets.
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 to a destination node. by a packet to travel from a source to a destination node.
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.
RPL Security Configuration: The values for Counter is Time, Security
Algorithm, Key Identifier Mode and Security Level fields, defined in
Section 6.1 of [RFC6550], inside the Security section of a secure RPL
control message.
4. Applicability 4. Applicability
A route discovery using P2P-RPL may be performed by an Origin when no A route discovery using P2P-RPL may be performed by an Origin when no
route exists between itself and the Target(s) or when the existing route exists between itself and the Target(s) or when the existing
routes do not satisfy the application requirements. P2P-RPL is routes do not satisfy the application requirements. P2P-RPL is
designed to discover Hop-by-hop or Source Routes to one or more designed to discover Hop-by-hop or Source Routes to one or more
Targets such that the discovered routes meet the specified Targets such that the discovered routes meet the specified
constraints. In some application contexts, the constraints that the constraints. In some application contexts, the constraints that the
discovered routes must satisfy are intrinsically known or can be discovered routes must satisfy are intrinsically known or can be
specified by the application. For example, an Origin that expects specified by the application. For example, an Origin that expects
skipping to change at page 6, line 19 skipping to change at page 7, line 33
Target are nearby. Similarly, a P2P-RPL route may not be much better Target are nearby. Similarly, a P2P-RPL route may not be much better
than the one along a global DAG if the Origin and the Target are far than the one along a global DAG if the Origin and the Target are far
apart. Note that, even when P2P-RPL routes are not much better than apart. Note that, even when P2P-RPL routes are not much better than
those along a global DAG, P2P-RPL routes may still be able to avoid those along a global DAG, P2P-RPL routes may still be able to avoid
congestion that might occur near the root if the routing takes place congestion that might occur near the root if the routing takes place
only along a global DAG. In general, the costs associated with a only along a global DAG. In general, the costs associated with a
P2P-RPL route discovery (in terms of the control messages, mostly P2P-RPL route discovery (in terms of the control messages, mostly
DIOs, generated) increases with the distance between the Origin and DIOs, generated) increases with the distance between the Origin and
the Target. However, it is possible to limit the cost of route the Target. However, it is possible to limit the cost of route
discovery by carefully setting the routing constraints, the Trickle discovery by carefully setting the routing constraints, the Trickle
parameters (that govern the DIO generation) and the lifetime of the parameters (that govern the DIO generation) and the time duration for
temporary DAG created for the route discovery. A network designer which a router maintains its membership in the temporary DAG created
may take into consideration both the benefits (potentially better for the route discovery. A network designer may take into
routes; no need to maintain routes proactively; avoid congestion near consideration both the benefits (potentially better routes; no need
the global DAG's root) and costs when using P2P-RPL. The latency to maintain routes proactively; avoid congestion near the global
associated with a P2P-RPL route discovery again depends on the DAG's root) and costs when using P2P-RPL. The latency associated
distance between the Origin and the Target and the Trickle with a P2P-RPL route discovery again depends on the distance between
parameters. the Origin and the Target and the Trickle parameters.
Like core RPL [RFC6550], P2P-RPL operation requires links to have Like core RPL [RFC6550], P2P-RPL operation requires links to have
bidirectional reachability. Routers participating in a P2P-RPL route bidirectional reachability. For this reason, the routers
discovery must ensure that participating in a P2P-RPL route discovery must ensure that
o Links that do not have bidirectional reachability do not become o Links that do not have bidirectional reachability do not become
part of the route being discovered; and part of the route being discovered; and
o IPv6 addresses belonging to egress-only or ingress-only interfaces o IPv6 addresses belonging to Ingress-only (or Egress-only)
do not become part of the route being discovered. Interfaces do not become part of the route being discovered.
5. Functional Overview 5. Functional Overview
This section contains a high level description of P2P-RPL. This section contains a high level description of P2P-RPL.
A P2P-RPL route discovery takes place by forming a DAG rooted at the A P2P-RPL route discovery takes place by forming a DAG rooted at the
Origin. As is the case with core RPL, P2P-RPL uses IPv6 link-local Origin. As is the case with core RPL, P2P-RPL uses IPv6 link-local
multicast DIO messages to establish a DAG. However, unlike core RPL, multicast DIO messages to establish a DAG. However, unlike core RPL,
this DAG is temporary in nature and routers in the DAG leave once the this DAG is temporary in nature. The routes are discovered and
DAG's life time is over. The sole purpose of DAG creation is to installed while the DAG is alive. Once the specified duration of
discover routes to the Target(s) and DIOs serve as the route their membership in the DAG is over, the routers leave the DAG and
discovery messages. Each router joining the DAG determines a rank hence the DAG ceases to exist. However, the installed routes are
for itself in the DAG and ignores the subsequent DIOs received from retained for their specified life time (which is different than the
lower (higher in numerical value) ranked neighbors. Thus, the route specified duration of a router's membership in the DAG) even though
discovery messages propagate away from the Origin rather than return the DAG that caused their installation no longer exists. In P2P-RPL,
back to it. As in core RPL, DIO generation at a router is controlled the sole purpose of DAG creation is to discover routes to the
by a Trickle timer [RFC6206] that allows a router to avoid generating Target(s) and DIOs serve as the route discovery messages. Each
unnecessary messages while providing protection against packet loss. router joining the DAG determines a rank for itself in the DAG and
P2P-RPL also uses the routing metrics [RFC6551], objective functions ignores the subsequent DIOs received from lower (higher in numerical
and packet forwarding framework [RFC6554][RFC6553] developed for core value) ranked neighbors. Thus, the route discovery messages
propagate away from the Origin rather than return back to it. As in
core RPL, DIO generation at a router is controlled by a Trickle timer
[RFC6206] that allows a router to avoid generating unnecessary
messages while providing protection against packet loss. P2P-RPL
also uses the routing metrics [RFC6551], objective functions and
packet forwarding framework [RFC6554][RFC6553] developed for core
RPL. RPL.
An Origin may use P2P-RPL to discover routes to one or more Target(s) An Origin may use P2P-RPL to discover routes to one or more Target(s)
identified by one or more unicast/multicast addresses. P2P-RPL identified by one or more unicast/multicast addresses. P2P-RPL
allows for the discovery of one Hop-by-hop Route or up to four Source allows for the discovery of one Hop-by-hop Route or up to four Source
Routes per Target. The discovered routes are guaranteed to meet the Routes per Target. The discovered routes are guaranteed to meet the
specified routing metric constraints but may not be the best specified routing metric constraints but may not be the best
available. P2P-RPL may fail to discover any route if the specified available. P2P-RPL may fail to discover any route if the specified
routing constraints are overly strict. P2P-RPL allows an Origin to routing constraints are overly strict.
piggyback time-critical application data on the DIO messages for
delivery to the Target(s).
The Origin initiates a P2P-RPL route discovery by forming a temporary The Origin initiates a P2P-RPL route discovery by forming a temporary
DAG rooted at itself. The DIOs used to create the temporary DAG are DAG rooted at itself. The DIOs used to create the temporary DAG are
identified by a new Mode of Operation (P2P Route Discovery mode identified by a new Mode of Operation (P2P Route Discovery mode
defined in Section 6). The DIOs listing the P2P Route Discovery mode defined in Section 6). The DIOs listing the P2P Route Discovery mode
as the Mode of Operation are henceforth referred to as the P2P mode as the Mode of Operation are henceforth referred to as the P2P mode
DIOs. A P2P mode DIO always carries exactly one P2P Route Discovery DIOs. A P2P mode DIO always carries exactly one P2P Route Discovery
Option (defined in Section 7.1) in which the Origin specifies the Option (P2P-RDO, defined in Section 7) in which the Origin specifies
following information: the following information:
o The IPv6 address of a Target. This could be a unicast address or o The IPv6 address of a Target. This could be a unicast address or
a multicast address. Any additional Targets may be specified by a multicast address. Any additional Targets may be specified by
including one or more RPL Target Options [RFC6550] inside the DIO. including one or more RPL Target Options [RFC6550] inside the DIO.
o The nature of the route(s) to be discovered: Hop-by-hop or Source o The nature of the route(s) to be discovered: Hop-by-hop or Source
Routes. This specification allows for the discovery of one Hop- Routes. This specification allows for the discovery of one Hop-
by-hop Route or up to four Source Routes per Target. by-hop Route or up to four Source Routes per Target.
o The desired number of routes (if Source Routes are being o The desired number of routes (if Source Routes are being
discovered). discovered).
o Whether the Target(s) should send Discovery Reply Object (DRO) o Whether the Target(s) should send P2P Discovery Reply Object (P2P-
messages (defined in Section 8) back to the Origin on receiving a DRO) messages (defined in Section 8) back to the Origin on
DIO message. A DRO message carries a discovered Source Route back receiving a DIO message. A P2P-DRO message carries a discovered
to the Origin or establishes a Hop-by-hop Route between the Origin Source Route back to the Origin or establishes a Hop-by-hop Route
and the Target. By not allowing the generation of DRO messages, between the Origin and the Target.
an Origin can use P2P-RPL as purely a mechanism to deliver time-
critical application data to the Target(s).
A P2P Route Discovery Option also accumulates a route from the Origin A P2P-RDO also includes the best route from the Origin that the
to a Target as the routers join the temporary DAG. router, generating the P2P mode DIO, has seen so far.
A P2P mode DIO MAY also carry: A P2P mode DIO MAY also carry:
o One or more Metric Container Options to specify: o One or more Metric Container Options to specify:
* The relevant routing metrics. * The relevant routing metrics.
* The constraints that the discovered route must satisfy. These * The constraints that the discovered route must satisfy. These
constraints also limit how far the DIOs message may travel. constraints also limit how far the DIOs message may travel.
o One or more RPL Target options to specify additional unicast or o One or more RPL Target options to specify additional unicast or
multicast Targets. multicast Targets.
o One Data Option (defined in Section 7.2) to carry time-critical
application-level data to be delivered to the Target(s).
As the routers join the temporary DAG, they keep track of the best As the routers join the temporary DAG, they keep track of the best
route(s) (so far from the Origin) they have seen and advertise these route(s) (so far from the Origin) they have seen and advertise these
routes, along with the corresponding routing metrics, in their P2P routes, along with the corresponding routing metrics, in their P2P
mode DIOs. A router, including the Target(s), discards a received mode DIOs. A router, including the Target(s), discards a received
P2P mode DIO if the aggregated routing metrics on the route P2P mode DIO if the aggregated routing metrics on the route
advertised by the DIO do not satisfy the listed constraints. These advertised by the DIO do not satisfy the listed constraints. These
constraints can be used to limit the propagation of P2P mode DIO constraints can be used to limit the propagation of P2P mode DIO
messages. A router may also discard a received P2P mode DIO if it messages. A router may also discard a received P2P mode DIO if it
does not wish to be a part of the discovered route due to limited does not wish to be a part of the discovered route due to limited
resources or due to policy reasons. resources or due to policy reasons.
When a Target receives a P2P mode DIO, it forwards the data in the When a Target receives a P2P mode DIO, it contains inside the P2P-RDO
Data Option, if present, to the higher layer. Since the links in the a complete Source Route from the Origin to this Target. Since the
discovered route have bidirectional reachability (Section 7.1), the links in the discovered route have bidirectional reachability
Target may remember the discovered route for use as a Source Route to (Section 7), the Target may use the discovered route to reach the
reach the Origin. If the Origin has requested DRO messages to be Origin. Thus, a router that provides a particular service in the LLN
sent back, the Target may select the route contained in the received (e.g. an outside temperature server) could initiate a P2P-RPL route
DIO for further processing as described next. This document does not discovery listing all its potential clients as Targets, thereby
specify a particular method for the Target to use to select a route allowing the clients to discover a Source Route back to the server.
for further processing. Example methods include selecting any route In this case, the Origin (the server) might want to disable the
that meets the constraints or selecting the best route(s) discovered generation of P2P-DRO messages by the Targets (the clients). If the
over a certain time period. Origin has requested P2P-DRO messages to be sent back, the Target may
select the discovered route in the received DIO for further
processing as described next. This document does not specify a
particular method for the Target to use to select a route for further
processing. Example methods include selecting any route that meets
the constraints or selecting the best route(s) discovered over a
certain time period.
If one or more Source Route(s) are being discovered, the Target sends If one or more Source Route(s) are being discovered, the Target sends
the selected Source Route(s) to the Origin via DRO messages with one the selected Source Route(s) to the Origin via P2P-DRO messages with
DRO message carrying one discovered route. On receiving a DRO one P2P-DRO message carrying one discovered route. On receiving a
message, the Origin stores the discovered route in its memory. This P2P-DRO message, the Origin stores the discovered route in its
specification allows the Origin to discover up to four Source Routes memory. This specification allows the Origin to discover up to four
per Target, thereby allowing the Origin to have sufficient ready-to- Source Routes per Target, thereby allowing the Origin to have
use alternatives should one or more of these routes fail. If a Hop- sufficient ready-to-use alternatives should one or more of these
by-hop Route is being discovered, the Target sends a DRO message routes fail. If a Hop-by-hop Route is being discovered, the Target
containing the selected route to the Origin. The DRO message travels sends a P2P-DRO message containing the selected route to the Origin.
back to the Origin along the selected route, establishing state for The P2P-DRO message travels back to the Origin along the selected
the Forward Route in the routers on the path. The Target may include route, establishing state for the Forward Route in the routers on the
a Data Option in a DRO message to deliver any time-critical path.
application data to the Origin.
The Target may request the Origin to acknowledge the receipt of a DRO The Target may request the Origin to acknowledge the receipt of a
message by sending back a DRO Acknowledgement (DRO-ACK) message P2P-DRO message by sending back a P2P-DRO Acknowledgement (P2P-DRO-
(defined in Section 10). The Origin unicasts a DRO-ACK message to ACK) message (defined in Section 10). The Origin unicasts a P2P-DRO-
the Target. If the Target does not receive the requested DRO-ACK ACK message to the Target. If the Target does not receive the
within a certain time interval of sending a DRO, it resends the DRO requested P2P-DRO-ACK within a certain time interval of sending a
message (up to a certain number of times) carrying the same route as P2P-DRO, it resends the P2P-DRO message (up to a certain number of
before. times) carrying the same route as before.
The use of trickle timers to delay the propagation of DIO messages The use of trickle timers to delay the propagation of DIO messages
may cause some nodes to generate these messages even when the desired may cause some nodes to generate these messages even when the desired
routes have already been discovered. In order to preempt the routes have already been discovered. In order to preempt the
generation of such unnecessary messages, the Target may set a "Stop" generation of such unnecessary messages, the Target may set a "Stop"
flag in the DRO message to let the nodes in the LLN know about the flag in the P2P-DRO message to let the nodes in the LLN know about
completion of the route discovery process. The routers receiving the completion of the route discovery process. The routers receiving
such a DRO should not generate any more DIOs for this temporary DAG. such a P2P-DRO should not generate any more DIOs for this temporary
Neither should they process any received DIOs for this temporary DAG DAG. Neither should they process any received DIOs for this
in future. However, such routers must still process the DROs temporary DAG in future. However, such routers must still process
received for this temporary DAG. the P2P-DROs received for this temporary DAG.
6. P2P Route Discovery Mode Of Operation 6. P2P Route Discovery Mode Of Operation
This section specifies a new RPL Mode of Operation (MOP), P2P Route This section specifies a new RPL Mode of Operation (MOP), P2P Route
Discovery Mode (or P2P mode, for short), with value TBD1. A DIO Discovery Mode (or P2P mode, for short), with value TBD1. A DIO
message, listing P2P mode as the MOP, is identified as performing a message, listing P2P mode as the MOP, is identified as performing a
P2P-RPL route discovery by creating a temporary DAG. A P2P mode DIO P2P-RPL route discovery by creating a temporary DAG. A P2P mode DIO
MUST carry exactly one P2P Route Discovery Option (specified in MUST carry exactly one P2P Route Discovery Option (P2P-RDO, specified
Section 7.1). in Section 7).
6.1. Setting a P2P Mode DIO 6.1. Setting a P2P Mode DIO
The Base Object in a P2P mode DIO message MUST be set in the The Base Object in a P2P mode DIO message MUST be set in the
following manner: 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 5.1 of [RFC6550]. The Origin MUST NOT reuse an Section 5.1 of [RFC6550]. The Origin chooses the RPLInstanceID to
RPLInstanceID for a route discovery if its previous route be used for a particular route discovery in accordance with the
discovery using this RPLInstanceID might still be going on. As following rules:
described in Section 7.1, the Life Time parameter in the P2P Route
Discovery Option specifies the time duration the route discovery * The Origin SHOULD NOT reuse an RPLInstanceID for a route
lasts. So, the Origin MUST NOT reuse an RPLInstanceID in a route discovery if some routers might still maintain membership in
discovery until the Life Time of its previous route discovery the DAG the Origin had initiated for the previous route
using this RPLInstanceID is over. When initiating a new route discovery using this RPLInstanceID. As described in Section 7,
discovery to a particular Target, the Origin MUST NOT reuse the a router's membership in a DAG created for a P2P-RPL route
RPLInstanceID used in a previous route discovery to this Target if discovery lasts for the time duration (say 'l' seconds)
the previously discovered routes might still exist. The Default indicated by the L field inside the P2P-RDO. In general, there
Lifetime and Lifetime Unit parameters in the DODAG Configuration is no upper bound on the time duration by when all the routers
Option specify the lifetime of the state the routers, including have left the DAG created for a P2P-RPL route discovery. In
the Origin and the Target, maintain for a Hop-by-hop or a Source the specific case where the discovered route must be at most
Route discovered using P2P-RPL. Thus, an Origin can safely reuse 'n' hops in length, all the routers must have left the DAG
an RPLInstanceID to discover a new route to a Target if the "(n+1)*l" seconds after its initiation by the Origin. In
lifetime of all previously discovered routes to this Target using practice, all the routers should have joined the DAG within 'l'
this RPLInstanceID is over. seconds of its initiation (since the route discovery must
complete while the Origin still belongs to the DAG) and hence
all the routers should have left the DAG within "2*l" seconds
of its initiation. Hence, it is usually sufficient that the
Origin wait for twice the duration indicated by the L field
inside the P2P-RDO used for the previous route discovery before
reusing the RPLInstanceID for a new route discovery.
Individual P2P-RPL deployments are encouraged to share their
experience with various RPLInstanceID reuse policies to help
guide the development of standards track version of the
protocol.
* When initiating a new route discovery to a particular Target,
the Origin MUST NOT reuse the RPLInstanceID used in a previous
route discovery to this Target if the state created during the
previous route discovery might still exist in some routers.
Note that it is possible that the previous route discovery did
not succeed yet some routers still ended up creating state.
The Default Lifetime and Lifetime Unit parameters in the DODAG
Configuration Option specify the lifetime of the state the
routers, including the Origin and the Target, maintain for a
Hop-by-hop or a Source Route discovered using P2P-RPL. Suppose
this lifetime is 'X' seconds. As discussed above, any state
created during the previous route discovery was likely created
within "2*l" seconds of its initiation. Hence, it is
sufficient that the Origin lets a time duration equal to
"X+2*l" seconds pass since the initiation of the previous route
discovery before initiating a new route discovery to the same
Target using the same RPLInstanceID.
o Version Number: MUST be set to zero. The temporary DAG used for o Version Number: MUST be set to zero. The temporary DAG used for
P2P-RPL route discovery does not exist long enough to have new P2P-RPL route discovery does not exist long enough to have new
versions (the Life Time parameter inside the P2P Route Discovery versions.
Option, defined in Section 7.1, specifies the life time of the
temporary DAG).
o Grounded (G) Flag: This flag MUST be set to one. Unlike a global o Grounded (G) Flag: This flag MUST be set to one. Unlike a global
RPL instance, the concept of a floating DAG, used to provide RPL instance, the concept of a floating DAG, used to provide
connectivity within a sub-DAG detached from a grounded DAG, does connectivity within a sub-DAG detached from a grounded DAG, does
not apply to a local RPL instance. Hence, an Origin MUST always not apply to a local RPL instance. Hence, an Origin MUST always
set the G flag to one when initiating a P2P-RPL route discovery. set the G flag to one when initiating a P2P-RPL route discovery.
Further, clause 3 of Section 8.2.2.2 in [RFC6550] does not apply Further, clause 3 of Section 8.2.2.2 in [RFC6550] does not apply
and a node MUST NOT initiate a new DAG if it does not have any and a node MUST NOT initiate a new DAG if it does not have any
parent left in a P2P-RPL DAG. parent left in a P2P-RPL DAG.
skipping to change at page 11, line 51 skipping to change at page 13, line 49
o Lifetime Unit: 0xFFFF, to correspond to infinity. o Lifetime Unit: 0xFFFF, to correspond to infinity.
o Objective Code Point: 0, i.e., OF0 [RFC6552] is the default o Objective Code Point: 0, i.e., OF0 [RFC6552] is the default
objective function. objective function.
o The remaining parameters have default values as specified in o The remaining parameters have default values as specified in
[RFC6550]. [RFC6550].
Individual P2P-RPL deployments are encouraged to share their Individual P2P-RPL deployments are encouraged to share their
experience with these default values with ROLL working group to help experience with these default values to help guide the development of
guide the development of standards track version of the protocol. standards track version of the protocol.
The routing metrics and constraints [RFC6551] used in P2P-RPL route The routing metrics and constraints [RFC6551] used in P2P-RPL route
discovery are included in one or more Metric Container Options discovery are included in one or more Metric Container Options
[RFC6550] inside the P2P mode DIO. Note that a DIO need not include [RFC6550] inside the P2P mode DIO. Note that a DIO need not include
a Metric Container if OF0 is the objective function in effect. In a Metric Container if OF0 is the objective function in effect. In
that case, a P2P mode DIO may still specify an upper limit on the that case, a P2P mode DIO may still specify an upper limit on the
maximum rank, that a router may have in the temporary DAG, inside the maximum rank, that a router may have in the temporary DAG, inside the
P2P Route Discovery Option (described in Section 7.1). P2P-RDO.
A P2P mode DIO: A P2P mode DIO:
o MUST carry one (and only one) P2P Route Discovery Option o MUST carry one (and only one) P2P-RDO. The P2P-RDO allows for the
(described in Section 7.1). The P2P Route Discovery Option allows specification of one unicast or multicast address for the Target.
for the specification of one unicast or multicast address for the A received P2P mode DIO MUST be discarded if it does not contain
Target. A received P2P mode DIO MUST be discarded if it does not exactly one P2P-RDO.
contain exactly one P2P Route Discovery Option.
o MAY carry one or more RPL Target Options to specify additional o MAY carry one or more RPL Target Options to specify additional
unicast/multicast addresses for the Target. unicast/multicast addresses for the Target. If a unicast address
is specified, it MUST be a global address or a unique local
address.
o MAY carry one or more Metric Container Options to specify routing o MAY carry one or more Metric Container Options to specify routing
metrics and constraints. metrics and constraints.
o MAY carry one Data Option (described in Section 7.2) containing
time-critical application data to be delivered to the Target(s).
A received P2P mode DIO MUST be discarded if it contains multiple
Data Options.
o MAY carry one or more Route Information Options [RFC6550]. In the o MAY carry one or more Route Information Options [RFC6550]. In the
context of P2P-RPL, a Route Information Option advertizes to the context of P2P-RPL, a Route Information Option advertizes to the
Target(s) the Origin's connectivity to the prefix specified in the Target(s) the Origin's connectivity to the prefix specified in the
option. option.
o MAY carry one or more Prefix Information Options subject to the An RPL Option, besides the ones listed above, MUST be ignored when
usage and rules specified in Section 6.7.10 in [RFC6550]. found inside a received P2P mode DIO and MUST NOT be included in the
P2P mode DIOs the receiving router generates.
7. New RPL Control Message Options In accordance with core RPL, a P2P mode DIO MUST propagate via link-
local multicast. The IPv6 source address in a P2P mode DIO MUST be a
link-local address and the IPv6 destination address MUST be the link-
local multicast address all-RPL-nodes [RFC6550]. A P2P mode DIO MUST
be transmitted on all interfaces the router has in this RPL domain
[I-D.ietf-roll-terminology].
This document defines two new RPL control message options: the P2P 7. P2P Route Discovery Option (P2P-RDO)
Route Discovery Option and the Data Option.
7.1. P2P Route Discovery Option (P2P-RDO) This section defines a new RPL control message option: the P2P Route
Discovery Option (P2P-RDO).
- -
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 = TBD2 | Option Length |R|H| N | Compr | L |MaxRank/NH | | Type = TBD2 | Option Length |R|H| N | Compr | L |MaxRank/NH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| TargetAddr | | TargetAddr |
| | | |
skipping to change at page 13, line 27 skipping to change at page 15, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address[1..n] | | Address[1..n] |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of P2P Route Discovery Option (P2P-RDO) Figure 1: Format of P2P Route Discovery Option (P2P-RDO)
The format of a P2P Route Discovery Option (P2P-RDO) is illustrated The format of a P2P Route Discovery Option (P2P-RDO) is illustrated
in Figure 1. A P2P mode DIO and a DRO (defined in Section 8) message in Figure 1. A P2P mode DIO and a P2P-DRO (defined in Section 8)
MUST carry exactly one P2P-RDO. A P2P-RDO consists of the following message MUST carry exactly one P2P-RDO. A P2P-RDO consists of the
fields: following fields:
o Option Type: TBD2. o Option Type: TBD2.
o Option Length: 8-bit unsigned integer, representing the length in o Option Length: 8-bit unsigned integer, representing the length in
octets of the option, not including the Option Type and Option octets of the option, not including the Option Type and Option
Length fields. Length fields.
o Reply (R): The Origin sets this flag to one to allow the Target(s) o Reply (R): The Origin sets this flag to one to allow the Target(s)
to send DRO messages back to the Origin. If this flag is zero, a to send P2P-DRO messages back to the Origin. If this flag is
Target MUST NOT generate any DRO message. zero, a Target MUST NOT generate any P2P-DRO message.
o Hop-by-hop (H): This flag is valid only if the R flag is set to o Hop-by-hop (H): This flag is valid only if the R flag is set to
one. The Origin sets this flag to one if it desires Hop-by-hop one. The Origin sets this flag to one if it desires Hop-by-hop
Routes. The Origin sets this flag to zero if it desires Source Routes. The Origin sets this flag to zero if it desires Source
Routes. This specification allows for the establishment of one Routes. This specification allows for the establishment of one
Hop-by-hop route or up to four Source Routes per Target. The Hop- Hop-by-hop route or up to four Source Routes per Target. The Hop-
by-hop Route is established in the Forward direction, i.e. from by-hop Route is established in the Forward direction, i.e. from
the Origin to the Target. This specification does not allow for the Origin to the Target. This specification does not allow for
the establishment of Hop-by-hop Routes in the Reverse direction. the establishment of Hop-by-hop Routes in the Reverse direction.
o Number of Routes (N): This field is valid only if the R flag is o Number of Routes (N): This field is valid only if the R flag is
one and H flag is zero, i.e. the Targets are allowed to generate one and H flag is zero, i.e. the Targets are allowed to generate
DRO messages carrying discovered Source Routes back to the Origin. P2P-DRO messages carrying discovered Source Routes back to the
In this case, the value in the N field plus one indicates the Origin. In this case, the value in the N field plus one indicates
number of Source Routes that each Target should convey to the the number of Source Routes that each Target should convey to the
Origin. When Hop-by-hop Routes are being discovered, the N field Origin. When Hop-by-hop Routes are being discovered, the N field
MUST be set to zero on transmission and ignored on reception. MUST be set to zero on transmission and ignored on reception.
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 the Target field and the Address octets that are elided from the Target field and the Address
vector. For example, Compr value will be zero if full IPv6 vector. For example, Compr value will be zero if full IPv6
addresses are carried in the Target field and the Address vector. addresses are carried in the Target field and the Address vector.
o Life Time (L): A 2-bit field that indicates the life time of the o Life Time (L): A 2-bit field that indicates the exact duration a
temporary DAG, i.e., the exact duration a router joining the router joining the temporary DAG, including the Origin and the
temporary DAG MUST maintain its membership in the DAG. The Target(s), MUST maintain its membership in the DAG. A router MUST
mapping between the values in this field and the life time of the leave the temporary DAG once the time elapsed since it joined
temporary DAG is as follows: reaches the value indicated by this field. The mapping between
the value in this field and the duration of the router's
membership in the temporary DAG is as follows:
* 0x00: 1 second; * 0x00: 1 second;
* 0x01: 4 seconds; * 0x01: 4 seconds;
* 0x02: 16 seconds; * 0x02: 16 seconds;
* 0x03: 64 seconds; * 0x03: 64 seconds;
The Origin sets this field based on its expectation regarding the The Origin sets this field based on its expectation regarding the
time required for the route discovery to complete, which includes time required for the route discovery to complete, which includes
the time required for the DIOs to reach the Target(s) and the DROs the time required for the DIOs to reach the Target(s) and the P2P-
to travel back to the Origin. The time required for the DIOs to DROs to travel back to the Origin. The time required for the DIOs
reach the Target(s) would in turn depend on the Trickle parameters to reach the Target(s) would in turn depend on the Trickle
(Imin and the redundancy constant) as well as the expected parameters (Imin and the redundancy constant) as well as the
distance (in terms of hops and/or ETX) to the Target(s). While expected distance (in terms of hops and/or ETX) to the Target(s).
deciding the temporary DAG's lifetime, the Origin should also take While deciding the value in this field, the Origin should also
in account the fact that all routers joining the temporary DAG take in account the fact that all routers joining the temporary
would need to stay in the DAG for this much time. DAG would need to stay in the DAG for this much time.
o MaxRank/NH: o MaxRank/NH:
* When a P2P-RDO is included in a P2P mode DIO, this field * When a P2P-RDO is included in a P2P mode DIO, this field
indicates the upper limit on the integer portion of the rank indicates the upper limit on the integer portion of the rank
(calculated using the DAGRank() macro defined in [RFC6550]) (calculated using the DAGRank() macro defined in [RFC6550])
that a router may have in the temporary DAG being created. An that a router may have in the temporary DAG being created. An
Intermediate Router MUST NOT join a temporary DAG being created Intermediate Router MUST NOT join a temporary DAG being created
by a P2P mode DIO if the integer portion of its rank would be by a P2P mode DIO if the integer portion of its rank would be
equal to or higher (in numerical value) than the MaxRank limit. equal to or higher (in numerical value) than the MaxRank limit.
A Target can join the temporary DAG at a rank whose integer A Target can join the temporary DAG at a rank whose integer
portion is equal to the MaxRank. A router MUST discard a portion is equal to the MaxRank. A router MUST discard a
received P2P mode DIO if the integer part of the advertized received P2P mode DIO if the integer part of the advertized
rank equals or exceeds the MaxRank limit. A value 0 in this rank equals or exceeds the MaxRank limit. A value 0 in this
field indicates that the MaxRank is infinity. field indicates that the MaxRank is infinity.
* When a P2P-RDO is included in a DRO message, this field * When a P2P-RDO is included in a P2P-DRO message, this field
indicates the index of the next hop address inside the Address indicates the index of the next hop address inside the Address
vector. vector.
o TargetAddr: An IPv6 address of the Target after eliding Compr o TargetAddr: An IPv6 address of the Target after eliding Compr
number of prefix octets. When the P2P-RDO is included in a P2P number of prefix octets. When the P2P-RDO is included in a P2P
mode DIO, this field may contain a unicast address or a multicast mode DIO, this field may contain a unicast address or a multicast
address. Any additional Target addresses can be specified by address. If a unicast address is specified, it MUST be a global
including one or more RPL Target Options [RFC6550] in the DIO. address or a unique local address. Any additional Target
When the P2P-RDO is included in a DRO, this field MUST contain a addresses can be specified by including one or more RPL Target
unicast IPv6 address of the Target generating the DRO. Options [RFC6550] in the DIO. When the P2P-RDO is included in a
P2P-DRO, this field MUST contain a unicast global or unique local
IPv6 address of the Target generating the P2P-DRO.
o Address[1..n]: A vector of IPv6 addresses representing a complete o Address[1..n]: A vector of IPv6 addresses representing a complete
route so far in the Forward direction: route so far in the Forward direction:
* Each element in the Address vector has size (16 - Compr) octets * Each element in the Address vector has size (16 - Compr) octets
and MUST contain a valid IPv6 address with first Compr octets and MUST contain a valid global or unique local IPv6 address
elided. with first Compr octets elided.
* The total number of elements inside the Address vector is given * The total number of elements inside the Address vector is given
by n = (Option Length - 2 - (16 - Compr))/(16 - Compr). by n = (Option Length - 2 - (16 - Compr))/(16 - Compr).
* IPv6 addresses of ingress-only (or egress-only) router * The IPv6 address that a router adds to the vector MUST belong
interfaces MUST NOT be added to the Address vector. This to the interface on which the router received the DIO
allows the route accumulated in the Address vector to be a containing this P2P-RDO. Further, this interface MUST NOT be
Bidirectional Route that can be used by a Target to send a DRO an Ingress-only Interface. This allows the route accumulated
message to the Origin. in the Address vector to be a Bidirectional Route that can be
used by a Target to send a P2P-DRO message to the Origin.
* The Address vector MUST carry the accumulated route in the * The Address vector MUST carry the accumulated route in the
Forward direction, i.e., the first element in the Address Forward direction, i.e., the first element in the Address
vector must contain the IPv6 address of the router next to the vector must contain the IPv6 address of the router next to the
Origin and so on. Origin and so on.
* The Origin and Target addresses MUST NOT be included in the * The Origin and Target addresses MUST NOT be included in the
Address vector. Address vector.
* A router adding its address to the vector MUST ensure that any * A router adding its address to the vector MUST ensure that any
of its addresses do not already exist in the vector. A Target of its addresses do not already exist in the vector. A Target
specifying a complete route in the Address vector MUST ensure specifying a complete route in the Address vector MUST ensure
that the vector does not contain any address more than once. that the vector does not contain any address more than once.
* The Address vector MUST NOT contain any multicast addresses. * The Address vector MUST NOT contain any multicast addresses.
7.2. Data Option 8. The P2P Discovery Reply Object (P2P-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD3 | Option Length | UpperLayerPrt | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 2: Format of Data Option
The format of a Data Option is illustrated in Figure 2. A P2P mode
DIO and a DRO (defined in Section 8) message MAY carry one Data
Option. A P2P-RDO consists of the following fields:
o Option Type: TBD3.
o Option Length: An 8-bit unsigned integer, representing the length
in octets of the option, not including the Option Type and Option
Length fields.
o Upper Layer Protocol: An 8-bit field that identifies the upper
layer protocol header with which the information in the Data field
starts. The protocol identifiers used in this field are same as
those defined in IANA's "Protocol Numbers" registry [PROTOCOL].
o Data: If the Data Option is contained in a DIO, this field
contains application data to be delivered to the Target(s). If
the Data Option is contained in a DRO, this field contains
application data to be delivered to the Origin.
If the Origin chooses to include a Data Option inside its DIO, it
MUST include the same Data Option in all its future DIO transmissions
for this temporary DAG. An Intermediate Router MUST NOT modify the
Data Option received inside a parent's DIO and MUST include this Data
Option in all its future DIO transmissions for this temporary DAG.
The same is true for a Target that needs to propagate the DIOs
further (required when the route discovery involves multiple
Targets). If a Target chooses to include a Data Option inside a DRO,
it MUST include the same Data Option in all retransmissions of this
DRO message and MUST NOT include a different Data Option in any other
DRO messages it generates for this route discovery. Also, an
Intermediate Router, which needs to forward a received DRO message
further, MUST include in the forwarded message a verbatim copy of the
Data Option found inside the received message.
Note that the data inside a Data Option has the same level of
security as the DIO/DRO message it is part of. A P2P-RPL deployment
SHOULD take in consideration the security requirements of the data
being sent inside the Data Options when deciding the overall security
requirements. Further, note that P2P-RPL does not guarantee
successful delivery of the data contained in a Data Option.
8. The Discovery Reply Object (DRO)
This section defines two new RPL Control Message types, the Discovery This section defines two new RPL Control Message types, the P2P
Reply Object (DRO), with code TBD4, and the Secure DRO, with code Discovery Reply Object (P2P-DRO), with code TBD3, and the Secure P2P-
TBD5. A DRO serves one of the following functions: DRO, with code TBD4. A P2P-DRO serves one of the following
functions:
o Carry a discovered Source Route from a Target to the Origin; o Carry a discovered Source Route from a Target to the Origin;
o Establish a Hop-by-hop Route as it travels from a Target to the o Establish a Hop-by-hop Route as it travels from a Target to the
Origin. Origin.
A DRO message MAY serve the function of letting the routers in the A P2P-DRO message can also serve the function of letting the routers
LLN know that a P2P-RPL route discovery is complete and no more DIO in the LLN know that a P2P-RPL route discovery is complete and no
messages need to be generated for the corresponding temporary DAG. A more DIO messages need to be generated for the corresponding
DRO message MAY also carry time-critical application data from the temporary DAG. A P2P-DRO message MUST carry one (and only one) P2P-
Target to the Origin in a Data Option. A DRO message MUST carry one RDO whose TargetAddr field MUST contain a unicast IPv6 address of the
(and only one) P2P-RDO whose TargetAddr field MUST contain a unicast Target that generates the P2P-DRO. A P2P-DRO message MUST travel
IPv6 address of the Target that generates the DRO. A DRO message from the Target to the Origin via link-local multicast along the
travels from the Target to the Origin via link-local multicast along route specified inside the Address vector in the P2P-RDO, as included
the route specified inside the Address vector in the P2P-RDO, as in the P2P-DRO. The IPv6 source address in a P2P-DRO message MUST be
included in the DRO. a link-local address and the IPv6 destination address MUST be the
link-local multicast address all-RPL-nodes [RFC6550]. A P2P-DRO
message MUST be transmitted on all interfaces the router has in this
RPL domain [I-D.ietf-roll-terminology].
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 |S|A|Seq| Reserved | | RPLInstanceID | Version |S|A|Seq| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| DODAGID | | DODAGID |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 3: Format of the base Discovery Reply Object (DRO) Figure 2: Format of the base P2P Discovery Reply Object (P2P-DRO)
The format of the base Discovery Reply Object (DRO) is shown in The format of the base P2P Discovery Reply Object (P2P-DRO) is shown
Figure 3. A base DRO consists of the following fields: in Figure 2. A base P2P-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. Since a temporary DAG always has value zero for the discovery. Since a temporary DAG always has value zero for the
Version, this field MUST always be set to zero. Version, this field MUST always be set to zero.
o Stop (S): This flag, when set to one by a Target, indicates that o Stop (S): This flag, when set to one by a Target, indicates that
the P2P-RPL route discovery is over. All the routers receiving the P2P-RPL route discovery is over. All the routers receiving
such a DRO, including the ones not listed in the route carried such a P2P-DRO, including the ones not listed in the route carried
inside P2P-RDO, inside P2P-RDO,
* SHOULD NOT process any more DIOs received for this temporary * SHOULD NOT process any more DIOs received for this temporary
DAG; DAG;
* SHOULD NOT generate any more DIOs for this temporary DAG; * SHOULD NOT generate any more DIOs for this temporary DAG;
* SHOULD cancel any pending DIO transmission for this temporary * SHOULD cancel any pending DIO transmission for this temporary
DAG. DAG.
Note that the Stop flag serves to stop further DIO generation/ Note that the Stop flag serves to stop further DIO generation/
processing for a P2P-RPL route discovery but it does not affect processing for a P2P-RPL route discovery but it does not affect
the processing of DRO messages at either the Origin or the the processing of P2P-DRO messages at either the Origin or the
Intermediate Routers. In other words, a router (the Origin or an Intermediate Routers. In other words, a router (the Origin or an
Intermediate Router) MUST continue to process the DRO messages Intermediate Router) MUST continue to process the P2P-DRO messages
even if an earlier DRO message (with the same RPLInstanceID and even if an earlier P2P-DRO message (with the same RPLInstanceID
DODAGID fields) had the Stop flag set to one. When set to zero, and DODAGID fields) had the Stop flag set to one. When set to
this flag does not imply any thing and MUST be ignored on zero, this flag does not imply any thing and MUST be ignored on
reception. reception.
o Ack Required (A): This flag, when set to one by the Target, o Ack Required (A): This flag, when set to one by the Target,
indicates that the Origin MUST unicast a DRO-ACK message (defined indicates that the Origin MUST unicast a P2P-DRO-ACK message
in Section 10) to the Target when it receives the DRO. (defined in Section 10) to the Target when it receives the P2P-
DRO.
o Sequence Number (Seq): This 2-bit field indicates the sequence o Sequence Number (Seq): This 2-bit field indicates the sequence
number for the DRO. This field is relevant when the A flag is set number for the P2P-DRO. This field is relevant when the A flag is
to one, i.e., the Target requests an acknowledgement from the set to one, i.e., the Target requests an acknowledgement from the
Origin for a received DRO. The Origin includes the RPLInstanceID, Origin for a received P2P-DRO. The Origin includes the
the DODAGID and the Sequence Number of the received DRO inside the RPLInstanceID, the DODAGID and the Sequence Number of the received
DRO-ACK message it sends back to the Target. P2P-DRO inside the P2P-DRO-ACK message it sends back to the
Target.
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. The discovery. The DODAGID also identifies the Origin. The
RPLInstanceID, the Version and the DODAGID together uniquely RPLInstanceID, the Version and the DODAGID together uniquely
identify the temporary DAG used for route discovery and can be identify the temporary DAG used for route discovery and can be
copied from the DIO message advertizing the temporary DAG. copied from the DIO message advertizing the temporary DAG.
o Options: The DRO message: o Options: The P2P-DRO message:
* MUST carry one (and only one) P2P-RDO that MUST specify a * MUST carry one (and only one) P2P-RDO that MUST specify a
complete route between the Target and the Origin; complete route between the Target and the Origin. A received
P2P-DRO message MUST be discarded if it does not contain
exactly one P2P-RDO.
* MAY carry one or more Metric Container Options that contains * MAY carry one or more Metric Container Options that contains
the aggregated routing metrics values for the route specified the aggregated routing metrics values for the route specified
in P2P-RDO; in P2P-RDO.
* MAY carry one Data Option to carry any time-critical
application data to the Origin, subject to the following
conditions: if a Target chooses to include a Data Option inside
a DRO,
+ it MUST include the same Data Option in all retransmissions
of this DRO message and
+ it MUST NOT include a different Data Option in any other DRO
messages it generates for this route discovery.
The Target MAY repeat the same Data Option in multiple DRO
messages it generates for a particular route discovery.
A received DRO message MUST be discarded if it does not contain An RPL Option, besides the ones listed above, MUST be ignored when
exactly one P2P-RDO or if it contains multiple Data Options. found inside a received P2P-DRO message.
8.1. Secure DRO 8.1. Secure P2P-DRO
A Secure DRO message follows the format in Figure 7 of [RFC6550], A Secure P2P-DRO message follows the format in Figure 7 of [RFC6550],
where the base format is the base DRO shown in Figure 3. where the base format is the base P2P-DRO shown in Figure 2.
8.2. Setting a P2P-RDO Carried in a Discovery Reply Object 8.2. Setting a P2P-RDO Carried in a P2P Discovery Reply Object
A Discovery Reply Object MUST carry one (and only one) P2P-RDO, which A P2P Discovery Reply Object MUST carry one (and only one) P2P-RDO,
MUST be set as defined in Section 7.1. Specifically, the following which MUST be set as defined in Section 7. Specifically, the
fields MUST be set as specified next: following fields MUST be set as specified next:
o Reply (R): This flag MUST be set to zero on transmission and o Reply (R): This flag MUST be set to zero on transmission and
ignored on reception. ignored on reception.
o Hop-by-Hop (H): The H flag in the P2P-RDO included in a DRO o Hop-by-Hop (H): The H flag in the P2P-RDO included in a P2P-DRO
message MUST have the same value as the H flag in the P2P-RDO message MUST have the same value as the H flag in the P2P-RDO
inside the corresponding DIO message. inside the corresponding DIO message.
o Number of Routes (N): This field MUST be set to zero on o Number of Routes (N): This field MUST be set to zero on
transmission and ignored on reception. transmission and ignored on reception.
o Life Time (L): This field MUST be set to zero on transmission and o Life Time (L): This field MUST be set to zero on transmission and
ignored on reception. ignored on reception.
o MaxRank/NH: This field indicates the index of the next hop address o MaxRank/NH: This field indicates the index of the next hop address
in the Address vector. When a Target generates a DRO message, the in the Address vector. When a Target generates a P2P-DRO message,
NH field is set to n = (Option Length - 2 - (16 - Compr))/(16 - the NH field is set to n = (Option Length - 2 - (16 - Compr))/(16
Compr). - Compr).
o TargetAddr: This field MUST contain a unicast IPv6 address of the o TargetAddr: This field MUST contain a unicast global or unique
Target generating the DRO. local IPv6 address of the Target generating the P2P-DRO.
o Address[1..n]: The Address vector MUST contain a complete route o Address[1..n]: The Address vector MUST contain a complete route
between the Origin and the Target such that the first element in between the Origin and the Target such that the first element in
the vector contains the IPv6 address of the router next to the the vector contains the IPv6 address of the router next to the
Origin and the last element contains the IPv6 address of the Origin and the last element contains the IPv6 address of the
router next to the Target. router next to the Target.
9. P2P-RPL Route Discovery By Creating a Temporary DAG 9. P2P-RPL Route Discovery By Creating a Temporary DAG
This section details the P2P-RPL route discovery operation. This section details the P2P-RPL route discovery operation.
9.1. Joining a Temporary DAG 9.1. Joining a Temporary DAG
All the routers participating in a P2P-RPL route discovery, including All the routers participating in a P2P-RPL route discovery, including
the Origin and the Target(s), MUST join the temporary DAG being the Origin and the Target(s), MUST join the temporary DAG being
created for the purpose. When a router joins a temporary DAG created for the purpose. When a router joins a temporary DAG
advertized by a P2P mode DIO, it MUST maintain its membership in the advertized by a P2P mode DIO, it MUST maintain its membership in the
temporary DAG for the Life Time duration listed in the P2P-RDO. The temporary DAG for the duration indicated by the L field inside the
only purpose of a temporary DAG's existence is to facilitate the P2P- P2P-RDO. The only purpose of a temporary DAG's existence is to
RPL route discovery process. The temporary DAG MUST NOT be used to facilitate the P2P-RPL route discovery process. The temporary DAG
route packets. A router MUST detach from the temporary DAG once the MUST NOT be used to route data packets. In other words, joining a
duration of its membership in the DAG has reached the DAG's life temporary DAG does not allow a router to provision routing table
time. After receiving a DRO with the Stop flag set to one, a router entries listing the router's parents in the temporary DAG as the next
SHOULD NOT send or receive any more DIOs for this temporary DAG and hops (i.e., the last bullet point in Section 3.2.8 of [RFC6550] is
SHOULD also cancel any pending DIO transmission. not applicable when the DAG is a temporary DAG created for the
purpose of a P2P-RPL route discovery.).
Given the nature of a temporary DAG created for a P2P-RPL route
discovery, this document disallows the solicitation of P2P mode DIOs
using DODAG Information Solicitation (DIS) messages as described in
[RFC6550]. A router participating in a P2P-RPL route discovery MUST
NOT reset its Trickle timer that controls the transmission of P2P
mode DIOs in response to a multicast DIS. Also, the router MUST NOT
send a P2P mode DIO in response to a unicast DIS. In other words,
the rules in Section 8.3 of [RFC6550] regarding a router's response
to a multicast/unicast DIS are not applicable for P2P mode DIOs.
A router MUST detach from the temporary DAG created for a P2P-RPL
route discovery once the duration of its membership in the DAG has
reached the value indicated by the L field inside the P2P-RDO. After
receiving a P2P-DRO with the Stop flag set to one, a router SHOULD
NOT send or process any more DIOs for this temporary DAG and SHOULD
also cancel any pending DIO transmission.
9.2. Trickle Operation For P2P Mode DIOs 9.2. Trickle Operation For P2P Mode DIOs
An RPL router uses a Trickle timer [RFC6206] to control DIO An RPL router uses a Trickle timer [RFC6206] to control DIO
transmissions. The Trickle control of DIO transmissions provides transmissions. The Trickle control of DIO transmissions provides
quick resolution of any "inconsistency" while avoiding redundant DIO quick resolution of any "inconsistency" while avoiding redundant DIO
transmissions. The Trickle algorithm also imparts protection against transmissions. The Trickle algorithm also imparts protection against
loss of DIOs due to inherent lack of reliability in LLNs. When loss of DIOs due to inherent lack of reliability in LLNs. When
controlling the transmissions of a P2P mode DIO, a Trickle timer controlling the transmissions of a P2P mode DIO, a Trickle timer
SHOULD follow the following rules: SHOULD follow the following rules:
skipping to change at page 22, line 8 skipping to change at page 23, line 18
reset their trickle timers and generate more DIOs. Thus, for reset their trickle timers and generate more DIOs. Thus, for
highly connected networks, the Imin parameter SHOULD be set to a highly connected networks, the Imin parameter SHOULD be set to a
value at least one order of magnitude larger than the typical value at least one order of magnitude larger than the typical
transmission delay for a DIO. For sparsely connected networks, transmission delay for a DIO. For sparsely connected networks,
the Imin parameter can be set to a value that is a small multiple the Imin parameter can be set to a value that is a small multiple
of the typical transmission delay for a DIO. Note that the Imin of the typical transmission delay for a DIO. Note that the Imin
value has a direct impact on the time required for a P2P-RPL route value has a direct impact on the time required for a P2P-RPL route
discovery to complete. In general, the time required for a P2P- discovery to complete. In general, the time required for a P2P-
RPL route discovery would increase approximately linearly with the RPL route discovery would increase approximately linearly with the
value of the Imin parameter. Since the route discovery must value of the Imin parameter. Since the route discovery must
complete within the lifetime of the temporary DAG created for the complete while the Origin still belongs to the temporary DAG
purpose, the Origin should set this lifetime to a large enough created for the purpose, the Origin should set the time duration a
value taking in account the Imin value as well as the expected router maintains its membership in the temporary DAG (indicated by
distance (in terms of hops and/or ETX) to the Target(s). the L field inside the P2P-RDO) to a large enough value taking in
account the Imin value as well as the expected distance (in terms
of hops and/or ETX) to the Target(s).
o The Imax parameter SHOULD be set to a large value (several orders o The Imax parameter SHOULD be set to a large value (several orders
of magnitude higher than the Imin value) and is unlikely to be of magnitude higher than the Imin value) and is unlikely to be
critical for P2P-RPL operation. This is because the first receipt critical for P2P-RPL operation. This is because the first receipt
of a P2P mode DIO for a particular temporary DAG is considered an of a P2P mode DIO for a particular temporary DAG is considered an
inconsistent event and would lead to resetting of Trickle timer inconsistent event and would lead to resetting of Trickle timer
duration to the Imin value. Given the temporary nature of the duration to the Imin value. Given the temporary nature of the
DAGs used in P2P-RPL, Trickle timer may not get a chance to DAGs used in P2P-RPL, Trickle timer may not get a chance to
increase much. increase much.
skipping to change at page 22, line 45 skipping to change at page 24, line 9
process to complete needs to be as small as possible; or process to complete needs to be as small as possible; or
* Deployments where specific destinations are reachable only * Deployments where specific destinations are reachable only
through specific intermediate routers (and hence these through specific intermediate routers (and hence these
intermediate routers should not suppress their DIOs). intermediate routers should not suppress their DIOs).
A particular deployment should take in account the above mentioned A particular deployment should take in account the above mentioned
factors when deciding the value of the redundancy constant. factors when deciding the value of the redundancy constant.
Individual P2P-RPL deployments are encouraged to share their Individual P2P-RPL deployments are encouraged to share their
experience with these rules with ROLL working group to help guide the experience with these rules to help guide the development of
development of standards track version of the protocol. standards track version of the protocol. Applicability Statements
Applicability Statements that specify the use of P2P-RPL MUST provide that specify the use of P2P-RPL MUST provide guidance for setting
guidance for setting Trickle parameters, particularly Imin and the Trickle parameters, particularly Imin and the redundancy constant.
redundancy constant.
9.3. Processing a P2P Mode DIO 9.3. Processing a P2P Mode DIO
The rules for DIO processing and transmission, described in Section 8 The rules for DIO processing and transmission, described in Section 8
of RPL [RFC6550], apply to P2P mode DIOs as well except as modified of RPL [RFC6550], apply to P2P mode DIOs as well except as modified
in this document. In particular, in accordance with Section 8.2.3 of in this document. In particular, in accordance with Section 8.2.3 of
RPL [RFC6550], a received P2P mode DIO MUST be discarded if it is RPL [RFC6550], a received P2P mode DIO MUST be discarded if it is
malformed according to the rules specified in this document and in malformed according to the rules specified in this document and in
[RFC6550]. [RFC6550].
skipping to change at page 23, line 26 skipping to change at page 24, line 35
A router SHOULD discard a received P2P mode DIO with no further A router SHOULD discard a received P2P mode DIO with no further
processing if it does not have bidirectional reachability with the processing if it does not have bidirectional reachability with the
neighbor that generated the received DIO. Note that bidirectional neighbor that generated the received DIO. Note that bidirectional
reachability does not mean that the link must have the same values reachability does not mean that the link must have the same values
for a routing metric in both directions. A router SHOULD calculate for a routing metric in both directions. A router SHOULD calculate
the values of the link-level routing metrics included in the received the values of the link-level routing metrics included in the received
DIO taking in account the metric's value in both Forward and Reverse DIO taking in account the metric's value in both Forward and Reverse
directions. Bidirectional reachability along a discovered route directions. Bidirectional reachability along a discovered route
allows the Target to use this route to reach the Origin. In allows the Target to use this route to reach the Origin. In
particular, the DRO messages travel from the Target to the Origin particular, the P2P-DRO messages travel from the Target to the Origin
along a discovered route. along a discovered route.
A router MUST discard a received P2P mode DIO with no further A router MUST discard a received P2P mode DIO with no further
processing: processing:
o If the DIO advertises INFINITE_RANK as defined in Section 17 of o If the DIO advertises INFINITE_RANK as defined in Section 17 of
[RFC6550]. [RFC6550].
o If the integer part of the rank advertised in the DIO equals or o If the integer part of the rank advertised in the DIO equals or
exceeds the MaxRank limit listed in the P2P Route Discovery exceeds the MaxRank limit listed in the P2P Route Discovery
Option. Option.
o If the routing metric values do not satisfy one or more of the o If the routing metric values do not satisfy one or more of the
mandatory route constraints listed in the DIO or if the router mandatory route constraints listed in the DIO or if the router
cannot evaluate the mandatory route constraints, e.g., if the cannot evaluate the mandatory route constraints, e.g., if the
router does not support the metrics used in the constraints. router does not support the metrics used in the constraints.
o If the router previously received a DRO message with the same o If the router previously received a P2P-DRO message with the same
RPLInstanceID and DODAGID as the received DIO and with the Stop RPLInstanceID and DODAGID as the received DIO and with the Stop
flag set to one. flag set to one.
The router MUST check the Target addresses listed in the P2P-RDO and The router MUST check the Target addresses listed in the P2P-RDO and
any RPL Target Options included in the received DIO. If one of its any RPL Target Options included in the received DIO. If one of its
IPv6 addresses is listed as a Target address or if it belongs to the IPv6 addresses is listed as a Target address or if it belongs to the
multicast group specified as one of the Target addresses, the router multicast group specified as one of the Target addresses, the router
considers itself a Target and processes the received DIO as specified considers itself a Target and processes the received DIO as specified
in Section 9.5. Otherwise, the router considers itself an in Section 9.5. Otherwise, the router considers itself an
Intermediate Router and processes the received DIO as specified in Intermediate Router and processes the received DIO as specified in
Section 9.4. Section 9.4.
9.4. Additional Processing of a P2P Mode DIO At An Intermediate Router 9.4. Additional Processing of a P2P Mode DIO At An Intermediate Router
An Intermediate Router MUST discard a received P2P mode DIO with no An Intermediate Router MUST discard a received P2P mode DIO with no
further processing if the router cannot elide Compr (as specified in further processing
the P2P-RDO) prefix octets from its IPv6 address or if adding its
IPv6 address to the Address vector (inside the P2P-RDO) would result o if the DIO is received on an Ingress-only Interface; or
in the Address vector containing multiple, non-back-to-back addresses
belonging to this router. o if the receiving interface does not have a global or unique local
IPv6 address configured with the address prefix implied by the
Compr field in the P2P-RDO inside the received DIO; or
o if the router can not uniquely identify the address prefix implied
by the Compr field in the P2P-RDO (this might happen if the
receiving interface has multiple global/unique-local IPv6
addresses, each configured with a different address prefix); or
o if adding its IPv6 address to the route in the Address vector
inside the P2P-RDO would result in the route containing multiple
addresses belonging to this router.
On receiving a P2P mode DIO, an Intermediate Router MUST do the On receiving a P2P mode DIO, an Intermediate Router MUST do the
following: following. The router MUST determine whether this DIO advertises a
better route than the router itself and whether the receipt of the
DIO would allow the router to advertise a better route than before.
Accordingly, the router SHOULD consider this DIO as consistent/
inconsistent from Trickle perspective as described in Section 9.2.
Note that the route comparison in a P2P-RPL route discovery is
performed using the parent selection rules of the OF in use as
specified in Section 14 of RPL [RFC6550]. If the received DIO would
allow the router to advertise a better route, the router MUST add a
unicast IPv6 address of the receiving interface (after eliding Compr
prefix octets) to the route in the Address vector inside the P2P-RDO
and remember this route for inclusion in its future DIOs.
o The router MUST determine whether this DIO advertises a better When an Intermediate Router adds an IPv6 address to a route, it MUST
route than the router itself and whether the receipt of the DIO ensure that
would allow the router to advertise a better route than before.
Accordingly, the router SHOULD consider this DIO as consistent/
inconsistent from Trickle perspective as described in Section 9.2.
Note that the route comparison in a P2P-RPL route discovery is
performed using the parent selection rules of the OF in use as
specified in Section 14 of RPL [RFC6550]. If the received DIO
would allow the router to advertise a better route, the router
MUST remember the route advertised (inside the P2P-RDO) in the DIO
(after adding its own IPv6 address to the route) for inclusion in
its future DIOs. When an Intermediate Router adds itself to a
route, it MUST ensure that the IPv6 address added to the route
does not belong to an ingress-only or an egress-only interface.
To improve the diversity of the routes being discovered, an
Intermediate Router SHOULD keep track of multiple routes (as long
as all these routes are the best seen so far), one of which SHOULD
be selected in a uniform random manner for inclusion in the P2P-
RDO inside the router's next DIO. Note that the route
accumulation in a P2P mode DIO MUST take place even if the Origin
does not want any DRO messages to be generated (i.e., the R flag
inside the P2P-RDO is set to zero). This is because the Target
may still be able to use the accumulated route as a source route
to reach the Origin.
o The router MUST copy any Data Option (to be included in its future o the IPv6 address is a unicast global or unique local IPv6 address
DIO transmissions) if the received DIO comes from a parent and is assigned to the interface on which the DIO containing the route
the first parent-originated DIO received with a Data Option was received;
inside.
9.5. Additional Processing of a P2P Mode DIO At The Target o the IPv6 address was configured with the address prefix implied by
the Compr field in the P2P-RDO inside the received DIO;
The Target MUST determine if the received DIO contains a Data Option To improve the diversity of the routes being discovered, an
and deliver the data to the specified upper layer protocol unless it Intermediate Router SHOULD keep track of multiple routes (as long as
has already done so in response to a previously received DIO. If all these routes are the best seen so far), one of which SHOULD be
this route discovery involves multiple Targets, the Target MUST selected in a uniform random manner for inclusion in the P2P-RDO
remember this Data Option for inclusion in its own DIOs. inside the router's next DIO. Note that the route accumulation in a
P2P mode DIO MUST take place even if the Origin does not want any
P2P-DRO messages to be generated (i.e., the R flag inside the P2P-RDO
is set to zero). This is because the Target may still be able to use
the accumulated route as a source route to reach the Origin.
The Target MAY store the route contained in the P2P-RDO in the 9.5. Additional Processing of a P2P Mode DIO At The Target
received DIO for use as a Source Route to reach the Origin. The
lifetime of this Source Route is specified by the Default Lifetime
and Lifetime Unit parameters inside the DODAG Configuration Option
currently in effect. This lifetime can be extended (or shortened)
appropriately following a hint from an upper-layer protocol.
If the Reply flag inside the P2P-RDO in the received DIO is zero, the The Target MAY remember the discovered route contained in the P2P-RDO
Target MUST discard the received DIO with no further processing. in the received DIO for use as a Source Route to reach the Origin.
Otherwise, the Target MAY select the route contained in the P2P-RDO The lifetime of this Source Route is specified by the Default
to send a DRO message back to the Origin. If the H flag inside the Lifetime and Lifetime Unit parameters inside the DODAG Configuration
P2P-RDO is one, the Target needs to select one route and send a DRO Option currently in effect. This lifetime can be extended (or
message along this route back to the Origin. If the H flag is zero, shortened) appropriately following a hint from an upper-layer
the number of routes to be selected (and the number of DRO messages protocol.
to be sent back) is given by one plus the value of the N field in the
P2P-RDO. This document does not prescribe a particular method for If the Reply flag inside the P2P-RDO in the received DIO is set to
the Target to select the routes. Example methods include selecting one, the Target MUST select one or more discovered routes and send
each route that meets the specified routing constraints until the one or more P2P-DRO messages, carrying one discovered route each,
desired number have been selected or selecting the best routes back to the Origin. If the H flag inside the P2P-RDO is set to one,
discovered over a certain time period. If multiple routes are to be the Target needs to select one route and send a P2P-DRO message along
selected, the Target SHOULD avoid selecting routes that have large this route back to the Origin. As this P2P-DRO message travels back
segments in common. to the Origin, the routers on the path establish hop-by-hop routing
state, thereby establishing a Hop-by-hop Route in the Forward
direction. If the H flag is set to zero, the number of Source Routes
to be selected (and the number of P2P-DRO messages to be sent back)
is given by one plus the value of the N field in the P2P-RDO. The
Target may select the discovered route inside the received DIO as
(one of) the route(s) that would be carried inside a P2P-DRO message
back to the Origin. This document does not prescribe a particular
method for the Target to select the routes. Example methods include
selecting each route that meets the specified routing constraints
until the desired number have been selected or selecting the best
routes discovered over a certain time period. If multiple routes are
to be selected, the Target SHOULD avoid selecting routes that have
large segments in common.
If the Target selects the route contained in the P2P-RDO in the If the Target selects the route contained in the P2P-RDO in the
received DIO, it sends a DRO message back to the Origin (identified received DIO, it sends a P2P-DRO message back to the Origin
by the DODAGID field in the DIO). The DRO message MUST include a (identified by the DODAGID field in the DIO). The P2P-DRO message
P2P-RDO that contains the selected route inside the Address vector. MUST include a P2P-RDO that contains the selected route inside the
Various fields inside the P2P-RDO MUST be set as specified in Address vector. Various fields inside the P2P-RDO MUST be set as
Section 8.2. The Target MAY set the A flag inside the DRO message to specified in Section 8.2. The Target MAY set the A flag inside the
one if it desires the Origin to send back a DRO-ACK message on P2P-DRO message to one if it desires the Origin to send back a P2P-
receiving the DRO. In this case, the Target waits for DRO-ACK message on receiving the P2P-DRO. In this case, the Target
DRO_ACK_WAIT_TIME duration for the DRO-ACK message to arrive. waits for P2P_DRO_ACK_WAIT_TIME duration for the P2P-DRO-ACK message
Failure to receive the DRO-ACK message within this time duration to arrive. Failure to receive the P2P-DRO-ACK message within this
causes the Target to retransmit the DRO message. The Target MAY time duration causes the Target to retransmit the P2P-DRO message.
retransmit the DRO message in this fashion up to The Target MAY retransmit the P2P-DRO message in this fashion up to
MAX_DRO_RETRANSMISSIONS times. Both DRO_ACK_WAIT_TIME and MAX_P2P_DRO_RETRANSMISSIONS times. Both P2P_DRO_ACK_WAIT_TIME and
MAX_DRO_RETRANSMISSIONS are configurable parameters to be decided MAX_P2P_DRO_RETRANSMISSIONS are configurable parameters to be decided
based on the characteristics of individual deployments. Note that based on the characteristics of individual deployments. Note that
all DRO transmissions and retransmissions MUST take place while the all P2P-DRO transmissions and retransmissions MUST take place while
Target is still a part of the temporary DAG created for the route the Target is still a part of the temporary DAG created for the route
discovery. A Target MUST NOT transmit a DRO if it no longer belongs discovery. A Target MUST NOT transmit a P2P-DRO if it no longer
to this DAG. belongs to this DAG.
The Target MAY set the Stop flag inside the DRO message to one if The Target MAY set the Stop flag inside the P2P-DRO message to one if
o this router is the only Target specified in the corresponding DIO, o this router is the only Target specified in the corresponding DIO,
i.e., the corresponding DIO specified a unicast address of the i.e., the corresponding DIO specified a unicast address of the
router as the TargetAddr inside the P2P-RDO with no additional router as the TargetAddr inside the P2P-RDO with no additional
Targets specified via RPL Target Options; and Targets specified via RPL Target Options; and
o the Target has already selected the desired number of routes. o the Target has already selected the desired number of routes.
The Target MAY include a Metric Container Option in the DRO message. The Target MAY include a Metric Container Option in the P2P-DRO
This Metric Container contains the end-to-end routing metric values message. This Metric Container contains the end-to-end routing
for the route specified in the P2P-RDO. The Target MAY include one metric values for the route specified in the P2P-RDO. The Target
Data Option in the DRO message to carry time-critical application MUST transmit the P2P-DRO message via a link-local multicast.
data for the Origin, subject to the conditions listed in Section 8.
The Target MUST transmit the DRO message via a link-local multicast.
A Target MUST NOT forward a P2P mode DIO any further if no other A Target MUST NOT forward a P2P mode DIO any further if no other
Targets are to be discovered, i.e., if a unicast IPv6 address (of Targets are to be discovered, i.e., if a unicast IPv6 address (of
this Target) is specified as the TargetAddr inside the P2P-RDO and no this Target) is specified as the TargetAddr inside the P2P-RDO and no
additional Targets are specified via RPL Target Options inside the additional Targets are specified via RPL Target Options inside the
DIOs for this route discovery. Otherwise, the Target MUST generate DIOs for this route discovery. Otherwise, the Target MUST generate
DIOs for this route discovery as an Intermediate Router would. DIOs for this route discovery as an Intermediate Router would.
9.6. Processing a DRO At An Intermediate Router 9.6. Processing a P2P-DRO At An Intermediate Router
If the DODAGID field in the received DRO does not list a router's own If the DODAGID field in the received P2P-DRO does not list a router's
IPv6 address, the router considers itself an Intermediate Router and own IPv6 address, the router considers itself an Intermediate Router
MUST process the received message in the following manner: and MUST process the received message in the following manner:
o The router MUST discard the received DRO with no further o The router MUST discard the received P2P-DRO with no further
processing if it does not belong to the temporary DAG identified processing if it does not belong to the temporary DAG identified
by the RPLInstanceID and the DODAGID fields in the DRO. by the RPLInstanceID and the DODAGID fields in the P2P-DRO.
o If the Stop flag inside the received DRO is set to one, the router o If the Stop flag inside the received P2P-DRO is set to one, the
SHOULD NOT send or receive any more DIOs for this temporary DAG router SHOULD NOT send or receive any more DIOs for this temporary
and SHOULD cancel any pending DIO transmission. DAG and SHOULD cancel any pending DIO transmission.
o The router MUST ignore any Metric Container and Data Options o The router MUST ignore any Metric Container Options contained in
contained in the DRO message. the P2P-DRO message.
o If Address[NH] element inside the P2P-RDO lists the router's own o If Address[NH] element inside the P2P-RDO lists the router's own
unicast IPv6 address, the router is a part of the route carried in unicast IPv6 address, the router is a part of the route carried in
the P2P-RDO. In this case, the router MUST do the following: the P2P-RDO. In this case, the router MUST do the following:
* To prevent loops, the router MUST discard the DRO message with * To prevent loops, the router MUST discard the P2P-DRO message
no further processing if the Address vector in the P2P-RDO with no further processing if the Address vector in the P2P-RDO
includes multiple IPv6 addresses assigned to the router's includes multiple IPv6 addresses assigned to the router's
interfaces. interfaces.
* If the H flag inside the P2P-RDO is one, the router MUST store * If the H flag inside the P2P-RDO is one, the router MUST store
the state for the Forward Hop-by-hop route carried inside the the state for the Forward Hop-by-hop route carried inside the
P2P-RDO. This state consists of: P2P-RDO. This state consists of:
+ The RPLInstanceID and the DODAGID fields of the DRO. + The RPLInstanceID and the DODAGID fields of the P2P-DRO.
+ The route's destination, the Target (identified by + The route's destination, the Target (identified by
TargetAddr field inside P2P-RDO). TargetAddr field inside P2P-RDO).
+ The IPv6 address of the next hop, Address[NH+1] (unless NH + The IPv6 address of the next hop, Address[NH+1] (unless NH
value equals the number of elements in the Address vector, value equals the number of elements in the Address vector,
in which case the Target itself is the next hop). in which case the Target itself is the next hop).
This Hop-by-hop routing state MUST expire at the end of the This Hop-by-hop routing state MUST expire at the end of the
lifetime specified by the Default Lifetime and Lifetime Unit lifetime specified by the Default Lifetime and Lifetime Unit
parameters inside the DODAG Configuration Option used in P2P parameters inside the DODAG Configuration Option used in P2P
mode DIOs for this route discovery. mode DIOs for this route discovery.
* If the router already maintains a Hop-by-hop state listing the * If the router already maintains a Hop-by-hop state listing the
Target as the destination and carrying same RPLInstanceID and Target as the destination and carrying same RPLInstanceID and
DODAGID fields as the received DRO and the next hop information DODAGID fields as the received P2P-DRO and the next hop
in the state does not match the next hop indicated in the information in the state does not match the next hop indicated
received DRO, the router MUST discard the DRO message with no in the received P2P-DRO, the router MUST discard the P2P-DRO
further processing. Note that this situation would occur in message with no further processing. Note that this situation
the following two cases: would occur in the following two cases:
+ When the route listed in the Address vector inside the P2P- + When the route listed in the Address vector inside the P2P-
RDO contains a previously undetected loop. In this case, RDO contains a previously undetected loop. In this case,
the rule above causes the DRO messages to be discarded. the rule above causes the P2P-DRO messages to be discarded.
+ When a Hop-by-hop Route between the Origin and the Target, + When a Hop-by-hop Route between the Origin and the Target,
previously established using the same RPLInstanceID and previously established using the same RPLInstanceID and
DODAGID as the route currently being established, still DODAGID as the route currently being established, still
exists and at least partially overlaps the route currently exists and at least partially overlaps the route currently
being established. being established.
* The router MUST decrement the NH field inside the P2P-RDO and * The router MUST decrement the NH field inside the P2P-RDO and
send the DRO message further via link-local multicast. send the P2P-DRO message further via link-local multicast.
9.7. Processing a DRO At The Origin 9.7. Processing a P2P-DRO At The Origin
When a router receives a DRO message that lists its IPv6 address in When a router receives a P2P-DRO message that lists its IPv6 address
the DODAGID field, the router recognizes itself as the Origin for the in the DODAGID field, the router recognizes itself as the Origin for
corresponding P2P-RPL route discovery, notes the Target that the corresponding P2P-RPL route discovery, notes the Target that
originated this message (from the TargetAddr field inside the P2P- originated this message (from the TargetAddr field inside the P2P-
RDO) and processes the message in the following manner: RDO) and processes the message in the following manner:
o The Origin MUST discard the received DRO with no further o The Origin MUST discard the received P2P-DRO with no further
processing if it no longer belongs to the temporary DAG identified processing if it no longer belongs to the temporary DAG identified
by the RPLInstanceID and the DODAGID fields in the DRO. by the RPLInstanceID and the DODAGID fields in the P2P-DRO.
o If the received DRO contains a Data Option and if it has not
already done so following the receipt of an earlier DRO from this
Target, the Origin MUST deliver the data inside the Data Option to
the specified upper layer protocol.
o If the Stop flag inside the received DRO is set to one, the Origin o If the Stop flag inside the received P2P-DRO is set to one, the
SHOULD NOT generate any more DIOs for this temporary DAG and Origin SHOULD NOT generate any more DIOs for this temporary DAG
SHOULD cancel any pending DIO transmission. and SHOULD cancel any pending DIO transmission.
o If the P2P-RDO inside the DRO has the H flag set to 0, the Address o If the P2P-RDO inside the P2P-DRO has the H flag set to 0, the
vector inside the P2P-RDO contains a Source Route to this Target Address vector inside the P2P-RDO contains a Source Route to this
and the Origin MUST store this Source Route in its memory. The Target. The Origin MUST set the lifetime of this Source Route to
lifetime of this Source Route is specified by the Default Lifetime the value specified by the Default Lifetime and Lifetime Unit
and Lifetime Unit parameters inside the DODAG Configuration Option parameters inside the DODAG Configuration Option in the P2P mode
in the P2P mode DIOs used for this route discovery. This lifetime DIOs used for this route discovery. This lifetime could be
could be extended (or shortened) appropriately following a hint extended (or shortened) appropriately following a hint from an
from an upper-layer protocol. upper-layer protocol.
o If the P2P-RDO inside the DRO has the H flag set to 1, the DRO o If the P2P-RDO inside the P2P-DRO has the H flag set to 1, the
message is establishing a Hop-by-hop Route to this Target and the P2P-DRO message is establishing a Hop-by-hop Route to this Target
Origin MUST store in its memory the state for this Hop-by-hop and the Origin MUST store in its memory the state for this Hop-by-
Route in the manner described in Section 9.6. This Hop-by-hop hop Route in the manner described in Section 9.6. This Hop-by-hop
routing state MUST expire at the end of the lifetime specified by routing state MUST expire at the end of the lifetime specified by
the Default Lifetime and Lifetime Unit parameters inside the DODAG the Default Lifetime and Lifetime Unit parameters inside the DODAG
Configuration Option used in P2P mode DIOs for this route Configuration Option used in P2P mode DIOs for this route
discovery. The standards track version of P2P-RPL may consider discovery. The standards track version of P2P-RPL may consider
specifying a signaling mechanism that will allow the Origin to specifying a signaling mechanism that will allow the Origin to
extend (or shorten) the lifetime of a P2P-RPL Hop-by-hop Route extend (or shorten) the lifetime of a P2P-RPL Hop-by-hop Route
following a suitable hint from an upper-layer protocol. following a suitable hint from an upper-layer protocol.
o If the received DRO message contains one or more Metric Container o If the received P2P-DRO message contains one or more Metric
Options, the Origin MAY store the values of the routing metrics Container Options, the Origin MAY store the values of the routing
associated with the discovered route in its memory. This metrics associated with the discovered route in its memory. This
information may be useful in formulating the constraints for any information may be useful in formulating the constraints for any
future P2P-RPL route discovery to this Target. future P2P-RPL route discovery to this Target.
o If the A flag is set to one in the received DRO message, the o If the A flag is set to one in the received P2P-DRO message, the
Origin MUST generate a DRO-ACK message as described in Section 10 Origin MUST generate a P2P-DRO-ACK message as described in
and unicast the message to the Target. The Origin MAY use the Section 10 and unicast the message to the Target. The Origin MAY
route just discovered to send the DRO-ACK message to the Target. use the route just discovered to send the P2P-DRO-ACK message to
Section 11 describes how a packet may be forwarded along a Source/ the Target. Section 12 describes how a packet may be forwarded
Hop-by-hop Route discovered using P2P-RPL. along a Source/Hop-by-hop Route discovered using P2P-RPL.
10. The Discovery Reply Object Acknowledgement (DRO-ACK) 10. The P2P Discovery Reply Object Acknowledgement (P2P-DRO-ACK)
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 |Seq| Reserved | | RPLInstanceID | Version |Seq| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| DODAGID | | DODAGID |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of the base Discovery Reply Object Acknowledgement Figure 3: Format of the base P2P Discovery Reply Object
(DRO-ACK) Acknowledgement (P2P-DRO-ACK)
A DRO message may fail to reach the Origin due to a number of A P2P-DRO message may fail to reach the Origin due to a number of
reasons. Unlike the DIO messages that benefit from Trickle- reasons. Unlike the DIO messages that benefit from Trickle-
controlled retransmissions, the DRO messages are prone to loss due to controlled retransmissions, the P2P-DRO messages are prone to loss
unreliable packet transmission in LLNs. Since a DRO message travels due to unreliable packet transmission in LLNs. Since a P2P-DRO
via link-local multicast, it cannot use link-level acknowledgements message travels via link-local multicast, it cannot use link-level
to improve the reliability of its transmission. Also, an acknowledgements to improve the reliability of its transmission.
Intermediate Router may drop the DRO message (e.g., because of its Also, an Intermediate Router may drop the P2P-DRO message (e.g.,
inability to store the state for the Hop-by-hop Route the DRO is because of its inability to store the state for the Hop-by-hop Route
establishing). To protect against the potential failure of a DRO the P2P-DRO is establishing). To protect against the potential
message to reach the Origin, the Target MAY request the Origin to failure of a P2P-DRO message to reach the Origin, the Target MAY
send back a DRO Acknowledgement (DRO-ACK) message on receiving a DRO request the Origin to send back a P2P-DRO Acknowledgement (P2P-DRO-
message. Failure to receive such an acknowledgement within the ACK) message on receiving a P2P-DRO message. Failure to receive such
DRO_ACK_WAIT_TIME interval of sending the DRO message forces the an acknowledgement within the P2P_DRO_ACK_WAIT_TIME interval of
Target to resend the message. sending the P2P-DRO message forces the Target to resend the message
(as described in Section 9.5).
This section defines two new RPL Control Message types: DRO This section defines two new RPL Control Message types: P2P-DRO
Acknowledgement (DRO-ACK; with code TBD6) and Secure DRO-ACK (with Acknowledgement (P2P-DRO-ACK; with code TBD5) and Secure P2P-DRO-ACK
code TBD7). A DRO-ACK message MUST travel as a unicast message from (with code TBD6). A P2P-DRO-ACK message MUST travel as a unicast
the Origin to the Target. The format of a base DRO-ACK message is message from the Origin to the Target. The IPv6 source and
shown in Figure 4. Various fields in a DRO-ACK message MUST have the destination addresses used in a P2P-DRO-ACK message MUST be global or
same values as the corresponding fields in the DRO message. The unique local. The format of a base P2P-DRO-ACK message is shown in
field marked as "Reserved" MUST be set to zero on transmission and Figure 3. Various fields in a P2P-DRO-ACK message MUST have the same
MUST be ignored on reception. A Secure DRO-ACK message follows the values as the corresponding fields in the P2P-DRO message. The field
marked as "Reserved" MUST be set to zero on transmission and MUST be
ignored on reception. A Secure P2P-DRO-ACK message follows the
format in Figure 7 of [RFC6550], where the base format is same as the format in Figure 7 of [RFC6550], where the base format is same as the
base DRO-ACK shown in Figure 4. base P2P-DRO-ACK shown in Figure 3.
11. Packet Forwarding Along a Route Discovered Using P2P-RPL 11. Secure P2P-RPL Operation
An Origin MAY use a Source Routing Header (SRH) [RFC6554] to send a Each RPL control message type, including the ones defined in this
document, has a secure version. A secure RPL control message is
identified by the value 1 in the most significant bit of the Code
field. Each secure RPL control message contains a security section
(see Figure 7 of [RFC6550]), whose contents are described in Section
6.1 of [RFC6550]. Sections 6.1, 10 and 19 of [RFC6550] describe core
RPL's security apparatus. These sections are applicable to P2P-RPL's
secure operation as well except as constrained in this section.
Core RPL allows a router to decide locally on a per-packet basis
whether to use security and if yes what Security Configuration (see
definition in Section 3) to use (the only exception being the
requirement to send a Secure DIO in response to a Secure DIS; see
Section 10.2 of [RFC6550]). In contrast, this document requires
routers participating in a P2P-RPL route discovery to follow the
Origin's lead regarding security. The Origin decides whether to use
security and the particular Security Configuration to be used for
this purpose. All the routers participating in this route discovery
MUST generate only secure control messages if the Origin decides so
and MUST use for this purpose the Security Configuration that the
Origin chose. The Origin MUST NOT set the "Key Identifier Mode"
field inside the chosen Security Configuration to value 1 since this
setting indicates the use of a per-pair key which is not suitable for
securing messages that travel by (link local) multicast (e.g. DIOs)
or that travel over multiple hops (e.g. P2P-DROs). The Origin MUST
use the chosen Security Configuration to secure all the control
messages (DIOs and P2P-DRO-ACKs) it generates.
A router MUST NOT join the temporary DAG being created for a P2P-RPL
route discovery if:
o it receives both secure and unsecure DIOs or Secure DIOs with
different Security Configurations pertaining to this route
discovery (i.e., referring to the same RPLInstanceID and DODAGID
combination) prior to joining; or
o it can not use the Security Configuration found in the Secure DIOs
pertaining to this route discovery.
When a router (an Intermediate Router or a Target) joins a temporary
DAG being created using Secure DIOs, it MUST remember the common
Security Configuration used in the received Secured DIOs and MUST use
this configuration to secure all the control messages (DIOs and P2P-
DROs) it generates.
If an Intermediate Router (or a Target) encounters a control message
(a DIO or a P2P-DRO or a P2P-DRO-ACK) pertaining to this route
discovery that is either not secure or does not follow the Security
Configuration the router remembers for this route discovery, the
router MUST enter the "lock down" mode for the remainder of its stay
in this temporary DAG. An Intermediate Router (or a Target) in the
"lock down" mode MUST NOT generate or process any control message
(irrespective of the Security Configuration used) pertaining to this
route discovery. If the Origin receives a control message (a P2P-
DRO) that does not follow the Security Configuration the Origin has
chosen for this route discovery, it MUST discard the received message
with no further processing.
12. Packet Forwarding Along a Route Discovered Using P2P-RPL
An Origin uses the Source Routing Header (SRH) [RFC6554] to send a
packet along a Source Route discovered using P2P-RPL. packet along a Source Route discovered using P2P-RPL.
Travel along a Hop-by-hop Route, established using P2P-RPL, requires Travel along a Hop-by-hop Route, established using P2P-RPL, requires
specifying the RPLInstanceID and the DODAGID (of the temporary DAG specifying the RPLInstanceID and the DODAGID (of the temporary DAG
used for the route discovery) to identify the route. This is because used for the route discovery) to identify the route. This is because
a P2P-RPL route discovery does not use globally unique RPLInstanceID a P2P-RPL route discovery does not use globally unique RPLInstanceID
values and hence both the RPLInstanceID (a local value assigned by values and hence both the RPLInstanceID (a local value assigned by
the Origin) and the DODAGID (an IPv6 address of the Origin) are the Origin) and the DODAGID (an IPv6 address of the Origin) are
required to uniquely identify a P2P-RPL Hop-by-hop Route to a required to uniquely identify a P2P-RPL Hop-by-hop Route to a
particular destination. particular destination.
An Origin MAY include an RPL option [RFC6553] inside the IPv6 hop-by- An Origin includes an RPL option [RFC6553] inside the IPv6 hop-by-hop
hop options header of a packet to send it along a Hop-by-hop Route options header of a packet to send it along a Hop-by-hop Route
established using P2P-RPL. For this purpose, the Origin MUST set the established using P2P-RPL. For this purpose, the Origin MUST set the
DODAGID of the temporary DAG used for the route discovery as the DODAGID of the temporary DAG used for the route discovery as the
source IPv6 address of the packet. Further, the Origin MUST specify source IPv6 address of the packet. Further, the Origin MUST specify
inside the RPL option the RPLInstanceID of the temporary DAG used for inside the RPL option the RPLInstanceID of the temporary DAG used for
the route discovery and set the O flag inside the RPL option to one. the route discovery and set the O flag inside the RPL option to one.
On receiving this packet, an Intermediate Router checks the O flag On receiving this packet, an Intermediate Router checks the O flag
and correctly infer the source IPv6 address of the packet as the and correctly infer the source IPv6 address of the packet as the
DODAGID of the Hop-by-hop Route. The router then uses the DODAGID, DODAGID of the Hop-by-hop Route. The router then uses the DODAGID,
the RPLInstanceID and the destination address to identify the routing the RPLInstanceID and the destination address to identify the routing
state to be used to forward the packet further. state to be used to forward the packet further.
12. Interoperability with Core RPL 13. Interoperability with Core RPL
This section describes how RPL routers that implement P2P-RPL This section describes how RPL routers that implement P2P-RPL
interact with RPL routers that do not. In general, P2P-RPL operation interact with RPL routers that do not. In general, P2P-RPL operation
does not affect core RPL operation and vice versa. However, core RPL does not affect core RPL operation and vice versa. However, core RPL
does allow a router to join a DAG as a leaf node even if it does not does allow a router to join a DAG as a leaf node even if it does not
understand the Mode of Operation (MOP) used in the DAG. Thus, an RPL understand the Mode of Operation (MOP) used in the DAG. Thus, an RPL
router that does not implement P2P-RPL may conceivably join a router that does not implement P2P-RPL may conceivably join a
temporary DAG being created for a P2P-RPL route discovery as a leaf temporary DAG being created for a P2P-RPL route discovery as a leaf
node and maintain its membership even though the DAG no longer node and maintain its membership even though the DAG no longer
exists. This may impose a drain on the router's memory. However, exists. This may impose a drain on the router's memory. However,
skipping to change at page 31, line 13 skipping to change at page 33, line 34
join a DAG whose MOP it does not understand. Moreover, RPL routers join a DAG whose MOP it does not understand. Moreover, RPL routers
in a particular deployment may have strict restrictions on the DAGs in a particular deployment may have strict restrictions on the DAGs
they may join, thereby mitigating the problem. they may join, thereby mitigating the problem.
The P2P-RPL mechanism described in this document works best when all The P2P-RPL mechanism described in this document works best when all
the RPL routers in the LLN implement P2P-RPL. In general, the the RPL routers in the LLN implement P2P-RPL. In general, the
ability to discover routes as well as the quality of discovered ability to discover routes as well as the quality of discovered
routes would deteriorate with the fraction of RPL routers that routes would deteriorate with the fraction of RPL routers that
implement P2P-RPL. implement P2P-RPL.
13. Security Considerations 14. Security Considerations
A P2P-RPL deployment may be susceptible to denial of service attacks
by rogue routers that initiate fake route discoveries. A rogue
router could join a temporary DAG and advertise false information in
its DIOs in order to include itself in the discovered route(s). It
could generate bogus DRO messages carrying bad routes or maliciously
modify genuine DRO messages it receives.
In general, the security considerations for the operation of P2P-RPL In general, the security considerations for the operation of P2P-RPL
are similar to the ones for the operation of RPL (as described in are similar to the ones for the operation of RPL (as described in
Section 19 of [RFC6550]). Section 10 of RPL specification [RFC6550] Section 19 of [RFC6550]). Sections 6.1 and 10 of RPL specification
describes a variety of security mechanisms that provide data [RFC6550] describe RPL's security framework that provides data
confidentiality, authentication, replay protection and delay confidentiality, authentication, replay protection and delay
protection services. Each RPL control message has a secure version protection services. This security framework can also be used in
that allows the specification of the level of security and the P2P-RPL after taking in account the constraints specified in
algorithms used to secure the message. The mechanism defined in this Section 11. P2P-RPL requires all routers participating in a secure
document is based on the use of DIOs to form a temporary DAG and route discovery to use the Security Configuration decided by the
discover P2P routes. These DIOs can be used in their secure versions Origin. The intention is to avoid compromising the overall security
if desired. New RPL control messages defined in this document (DRO of a route discovery due to some routers using a weaker Security
and DRO-ACK) have secure versions as well. In addition, a P2P-RPL Configuration. With "lock down" mechanism, described in Section 11,
deployment may use the security features provided by the link layer in effect, it is unlikely that an Origin would accept a route
in use. Thus, a particular P2P-RPL deployment can analyze its discovered under a Security Configuration other than the one it
security requirements and use the appropriate set of RPL (or link intended. Any attempt to use a different Security Configuration
layer) security mechanisms that meet those requirements. Note that (than the one the Origin intended) is likely to result, in the worst
the contents of the Data Option, if used, has the same level of case, in the failure of the route discovery process. In the best
security as the DIO/DRO message it is part of. Hence, a P2P-RPL case scenario, any such attempt by a rogue router would result in its
deployment SHOULD take in consideration the security requirements of neighbors entering the "lock down" mode and acting as firewalls to
the data being sent inside the Data Options when deciding the overall allow the route discovery to proceed in the remaining network.
security requirements.
Since a DRO message travels along a Source Route specified inside the RPL specification describes three modes of security: unsecured, pre-
message, some of the security concerns that led to the deprecation of installed and authenticated. In the unsecured mode, secure control
Type 0 routing header [RFC5095] may apply. To avoid the possibility messages are not used and the only available security is the one
of a DRO message traveling in a routing loop, this document requires provided by the link layer protocols. In the pre-installed mode, all
each Intermediate Router to confirm that the Source Route listed the nodes use a pre-installed group key to join a secure DAG as the
inside the message does not contain any routing loop involving itself "routers" or "hosts", where the term "router" means a node that is
before the router could forward the message further. As specified in capable of forwarding packets received from its parents or children
Section 9.6, this check involves the router making sure that its IPv6 in the DAG and the term "host" refers to nodes that can not function
addresses do not appear multiple times inside the Source Route with as "routers". In the authenticated mode, the nodes can join a secure
one or more other IPv6 addresses in between. DAG as "hosts" using the pre-installed key but then need to
authenticate themselves to a key server to obtain the key that will
allow them to work as "routers". The temporary DAG created for a
P2P-RPL discovery can not be used for routing packets. Hence, it is
not meaningful to say that a node joins this DAG as a "router" or a
"host" in the sense defined above. Hence, in P2P-RPL, there is no
distinction between the pre-installed and authenticated modes. A
router can join a temporary DAG created for a secure P2P-RPL route
discovery only if it can support the Security Configuration in use,
which also specifies the key in use. It does not matter whether the
key is pre-installed or dynamically acquired. The router must have
the key in use before it can join the DAG beiing created for a secure
P2P-RPL route discovery.
14. IANA Considerations If a rogue router can support the Security Configuration in use (in
particular, it knows the key in use), it can join the secure P2P-RPL
route discovery and cause a variety of damage. Such a rogue router
could advertise false information in its DIOs in order to include
itself in the discovered route(s). It could generate bogus P2P-DRO
messages carrying bad routes or maliciously modify genuine P2P-DRO
messages it receives. A rogue router acting as the Origin could
launch denial of service attacks against the LLN deployment by
initiating fake P2P-RPL route discoveries. Here, RPL's authenticated
mode operation would be useful, where a node can obtain the key to
use for a P2P-RPL route discovery only after proper authentication.
14.1. Additions to Mode of Operation Since a P2P-DRO message travels along a Source Route specified inside
the message, some of the security concerns that led to the
deprecation of Type 0 routing header [RFC5095] may apply. To avoid
the possibility of a P2P-DRO message traveling in a routing loop,
this document requires each Intermediate Router to confirm that the
Source Route listed inside the message does not contain any routing
loop involving itself before the router could forward the message
further. As specified in Section 9.6, this check involves the router
making sure that its IPv6 addresses do not appear multiple times
inside the Source Route with one or more other IPv6 addresses in
between.
15. IANA Considerations
15.1. Additions to Mode of Operation
This document defines a new Mode of Operation, entitled "P2P Route This document defines a new Mode of Operation, entitled "P2P Route
Discovery Mode" (see Section 6), assigned a value TBD1 from the "Mode Discovery Mode" (see Section 6), assigned a value TBD1 from the "Mode
of Operation" space [to be removed upon publication: of Operation" space [to be removed upon publication:
http://www.iana.org/assignments/rpl/rpl.xml#mop] [RFC6550]. IANA is http://www.iana.org/assignments/rpl/rpl.xml#mop] [RFC6550]. IANA is
requested to allocate a suitable value to TBD1. The string TBD1 in requested to allocate a suitable value to TBD1. The string TBD1 in
this document should be replaced by the allocated value. The this document should be replaced by the allocated value. The
previous two sentences should be removed before publication. previous two sentences should be removed before publication.
+-------+---------------------------------------+---------------+ +-------+---------------------------------------+---------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+---------------------------------------+---------------+ +-------+---------------------------------------+---------------+
| TBD1 | P2P Route Discovery Mode of Operation | This document | | TBD1 | P2P Route Discovery Mode of Operation | This document |
+-------+---------------------------------------+---------------+ +-------+---------------------------------------+---------------+
Mode of Operation Mode of Operation
14.2. Additions to RPL Control Message Options 15.2. Additions to RPL Control Message Options
This document defines two new RPL options:
o "P2P Route Discovery Option" (see Section 7.1), assigned a value
TBD2 from the "RPL Control Message Options" space [to be removed
upon publication: http://www.iana.org/assignments/rpl/
rpl.xml#control-message-options] [RFC6550]. IANA is requested to
allocate a suitable value to TBD2. The string TBD2 in this
document should be replaced by the allocated value. The previous
two sentences should be removed before publication.
o "Data Option" (see Section 7.2), assigned a value TBD3 from the This document defines a new RPL option: "P2P Route Discovery Option"
"RPL Control Message Options" space [to be removed upon (see Section 7), assigned a value TBD2 from the "RPL Control Message
publication: http://www.iana.org/assignments/rpl/ Options" space [to be removed upon publication:
rpl.xml#control-message-options] [RFC6550]. IANA is requested to http://www.iana.org/assignments/rpl/rpl.xml#control-message-options]
allocate a suitable value to TBD3. The string TBD3 in this [RFC6550]. IANA is requested to allocate a suitable value to TBD2.
document should be replaced by the allocated value. The previous The string TBD2 in this document should be replaced by the allocated
two sentences should be removed before publication. value. The previous two sentences should be removed before
publication.
+-------+---------------------+---------------+ +-------+---------------------+---------------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+-------+---------------------+---------------+ +-------+---------------------+---------------+
| TBD2 | P2P Route Discovery | This document | | TBD2 | P2P Route Discovery | This document |
| TBD3 | Data | This document |
+-------+---------------------+---------------+ +-------+---------------------+---------------+
RPL Control Message Options RPL Control Message Options
14.3. Additions to RPL Control Codes 15.3. Additions to RPL Control Codes
This document defines the following new RPL messages: This document defines the following new RPL messages:
o "Discovery Reply Object" (see Section 8), assigned a value TBD4 o "P2P Discovery Reply Object" (see Section 8), assigned a value
from the "RPL Control Codes" space [to be removed upon TBD3 from the "RPL Control Codes" space [to be removed upon
publication: publication:
http://www.iana.org/assignments/rpl/rpl.xml#control-codes] http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
[RFC6550]. IANA is requested to allocate TBD4 from the range [RFC6550]. IANA is requested to allocate TBD3 from the range
0x00-0x7F to indicate a message without security enabled. The 0x00-0x7F to indicate a message without security enabled. The
string TBD4 in this document should be replaced by the allocated string TBD3 in this document should be replaced by the allocated
value. The previous two sentences should be removed before value. The previous two sentences should be removed before
publication. publication.
o "Secure Discovery Reply Object" (see Section 8.1), assigned a o "Secure P2P Discovery Reply Object" (see Section 8.1), assigned a
value TBD5 from the "RPL Control Codes" space [to be removed upon value TBD4 from the "RPL Control Codes" space [to be removed upon
publication: publication:
http://www.iana.org/assignments/rpl/rpl.xml#control-codes] http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
[RFC6550]. IANA is requested to allocate TBD5 from the range [RFC6550]. IANA is requested to allocate TBD4 from the range
0x80-0xFF to indicate a message with security enabled. The string 0x80-0xFF to indicate a message with security enabled. The string
TBD5 in this document should be replaced by the allocated value. TBD4 in this document should be replaced by the allocated value.
The previous two sentences should be removed before publication. The previous two sentences should be removed before publication.
o "Discovery Reply Object Acknowledgement" (see Section 10), o "P2P Discovery Reply Object Acknowledgement" (see Section 10),
assigned a value TBD6 from the "RPL Control Codes" space [to be assigned a value TBD5 from the "RPL Control Codes" space [to be
removed upon publication: removed upon publication:
http://www.iana.org/assignments/rpl/rpl.xml#control-codes] http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
[RFC6550]. IANA is requested to allocate TBD6 from the range [RFC6550]. IANA is requested to allocate TBD5 from the range
0x00-0x7F to indicate a message without security enabled. The 0x00-0x7F to indicate a message without security enabled. The
string TBD6 in this document should be replaced by the allocated string TBD5 in this document should be replaced by the allocated
value. The previous two sentences should be removed before value. The previous two sentences should be removed before
publication. publication.
o "Secure Discovery Reply Object Acknowledgement" (see Section 10), o "Secure P2P Discovery Reply Object Acknowledgement" (see
assigned a value TBD7 from the "RPL Control Codes" space [to be Section 10), assigned a value TBD6 from the "RPL Control Codes"
removed upon publication: space [to be removed upon publication:
http://www.iana.org/assignments/rpl/rpl.xml#control-codes] http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
[RFC6550]. IANA is requested to allocate TBD7 from the range [RFC6550]. IANA is requested to allocate TBD6 from the range
0x80-0xFF to indicate a message with security enabled. The string 0x80-0xFF to indicate a message with security enabled. The string
TBD7 in this document should be replaced by the allocated value. TBD6 in this document should be replaced by the allocated value.
The previous two sentences should be removed before publication. The previous two sentences should be removed before publication.
+------+--------------------------------------------+---------------+ +------+---------------------------------------------+--------------+
| Code | Description | Reference | | Code | Description | Reference |
+------+--------------------------------------------+---------------+ +------+---------------------------------------------+--------------+
| TBD4 | Discovery Reply Object | This document | | TBD3 | P2P Discovery Reply Object | This |
| TBD5 | Secure Discovery Reply Object | This document | | | | document |
| TBD6 | Discovery Reply Object Acknowledgement | This document | | TBD4 | Secure P2P Discovery Reply Object | This |
| TBD7 | Secure Discovery Reply Object | This document | | | | document |
| | Acknowledgement | | | TBD5 | P2P Discovery Reply Object Acknowledgement | This |
+------+--------------------------------------------+---------------+ | | | document |
| TBD6 | Secure P2P Discovery Reply Object | This |
| | Acknowledgement | document |
+------+---------------------------------------------+--------------+
RPL Control Codes RPL Control Codes
15. Acknowledgements 16. Acknowledgements
Authors gratefully acknowledge the contributions of the following Authors gratefully acknowledge the contributions of the following
individuals (in alphabetical order) in the development of this individuals (in alphabetical order) in the development of this
document: Dominique Barthel, Jakob Buron, Cedric Chauvenet, Thomas document: Dominique Barthel, Jakob Buron, Cedric Chauvenet, Thomas
Clausen, Robert Cragie, Ted Humpal, Richard Kelsey, Phil Levis, Clausen, Robert Cragie, Ralph Droms, Adrian Farrel, Stephen Farrell,
Charles Perkins, Joseph Reddy, Michael Richardson, Zach Shelby, Brian Haberman, Ted Humpal, Richard Kelsey, Phil Levis, Charles
Pascal Thubert, Hristo Valev and JP Vasseur. Perkins, Joseph Reddy, Michael Richardson, Zach Shelby, Martin
Stiemerling, Pascal Thubert, Hristo Valev and JP Vasseur.
16. References 17. References
16.1. Normative References 17.1. Normative References
[PROTOCOL] [I-D.ietf-roll-terminology]
"Protocol Numbers", <http://www.iana.org/assignments/ Vasseur, J., "Terminology in Low power And Lossy
protocol-numbers/protocol-numbers.xml>. Networks", draft-ietf-roll-terminology-10 (work in
progress), January 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, March 2011. "The Trickle Algorithm", RFC 6206, March 2011.
skipping to change at page 34, line 48 skipping to change at page 38, line 4
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, March 2011. "The Trickle Algorithm", RFC 6206, March 2011.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Lossy Networks", RFC 6550, March 2012. Lossy Networks", RFC 6550, March 2012.
[RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D. [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
Barthel, "Routing Metrics Used for Path Calculation in Barthel, "Routing Metrics Used for Path Calculation in
Low-Power and Lossy Networks", RFC 6551, March 2012. Low-Power and Lossy Networks", RFC 6551, March 2012.
16.2. Informative References 17.2. Informative References
[I-D.ietf-roll-p2p-measurement] [I-D.ietf-roll-p2p-measurement]
Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A Goyal, M., Baccelli, E., Brandt, A., and J. Martocci, "A
Mechanism to Measure the Routing Metrics along a Point-to- Mechanism to Measure the Routing Metrics along a Point-to-
point Route in a Low Power and Lossy Network", point Route in a Low Power and Lossy Network",
draft-ietf-roll-p2p-measurement-08 (work in progress), draft-ietf-roll-p2p-measurement-09 (work in progress),
January 2013. February 2013.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
December 2007. December 2007.
[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,
 End of changes. 149 change blocks. 
609 lines changed or deleted 715 lines changed or added

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