Targeting Low power and Lossy Networks (LLNs), the RPL routing
protocol [RFC6550] provides paths along a Directed Acyclic Graph
(DAG) rooted at a single router in the network. Establishment and
maintenance of a DAG is performed by routers in the LLN using DODAG
Information Object (DIO) messages. When two arbitrary routers
(neither of which is the DAG's root) need to communicate, the data
packets are restricted to travel only along the links in the DAG.
Such point-to-point (P2P) routing functionality may not be sufficient
for several Home and Building Automation applications [RFC5826]
[RFC5867] due to the following reasons:
o The need to pre-establish routes: each potential destination in
the network must declare itself as such ahead of the time a source
needs to reach it.
o The need to route only along the links in the DAG: A DAG is built
to optimize the routing cost to reach the root. Restricting P2P
routes to use only the in-DAG links may result in significantly
suboptimal routes and severe traffic congestion near the DAG root.
This document describes an extension to core RPL that enables an IPv6
router in the LLN to discover routes to one or more IPv6 routers in
the LLN "on demand", such that the discovered routes meet the
specified metrics constraints, without necessarily going along the
links in an existing DAG. This reactive P2P route discovery
mechanism is henceforth referred to as P2P-RPL. P2P-RPL does not
guarantee discovery of a route. Also, the discovered routes may not
be optimal. However, any discovered routes are guaranteed to satisfy
the desired constraints in terms of the routing metrics and are thus
considered "good enough" from the application's perspective.
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
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
P2P-RPL and the metric constraints to be used for this purpose.
Working Group Summary:
No discontent. Once again, few comments, request for clarifications
that have all been addressed in this revision.
Yes there are several known implementations of these specification,
with interop testing.
An interoperability event was carried out Oct 2012 with INRIA's
implementation against Sigma Design's implementation. The
report can be found:
Experiments with P2P-RPL have also taken place on the Senslab
testbed gathering boards based on MSP430 and 802.15.4 at
The Document Shepherd is JP Vasseur (firstname.lastname@example.org)
The responsible AD is Adrian Farrel (email@example.com)
RFC Editor Note
The reference to RFC 5226 may be removed.
Section 6.1 New bullet on page 13.
In the list of bullets under
The DODAG Configuration Option, inside a P2P mode DIO MUST be set in
the following manner:
Add a new bullet at the top of the list as follows:
o As discussed in Section 14, P2P-RPL does not distinguish between
the "preinstalled" and "authenticated" security modes described in
[RFC6550]. Consequently, the Origin MUST set the Authentication
Enabled (A) flag to zero. A received P2P mode DIO MUST be
discarded if the A flag inside the DODAG Configuration Option is
Section 6.1 New bullet on page 14
In the list of bullets under
A P2P mode DIO:
Add a new bullet to the end of the list as follows:
o MAY carry one DODAG Configuration Option. If a P2P mode DIO does
not carry an explicit DODAG Configuration Option, the default
DODAG Configuration Option defined in this section is considered
to be in effect.