draft-ietf-roll-p2p-rpl-07.txt   draft-ietf-roll-p2p-rpl-08.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 1, 2012 E. Baccelli Expires: September 3, 2012 E. Baccelli
M. Philipp M. Philipp
INRIA INRIA
A. Brandt A. Brandt
Sigma Designs Sigma Designs
J. Martocci J. Martocci
Johnson Controls Johnson Controls
January 29, 2012 March 2, 2012
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-07 draft-ietf-roll-p2p-rpl-08
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 and establish, on demand, a route to an IPv6 router to discover "on demand" routes to one or more IPv6
another IPv6 router in the LLN such that the discovered route meets routers in the LLN such that the discovered routes meets specified
specified metrics constraints, without necessarily going along the metrics constraints.
DAG links established by core RPL.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 1, 2012. This Internet-Draft will expire on September 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 22 skipping to change at page 2, line 20
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 5 5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 5
6. P2P Route Discovery Mode Of Operation . . . . . . . . . . . . 7 6. P2P Route Discovery Mode Of Operation . . . . . . . . . . . . 8
6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . . 8 6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . . 8
7. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . . . 10 7. New RPL Control Message Options . . . . . . . . . . . . . . . 11
8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 13 7.1. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . 11
8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 14
8.2. Setting a P2P-RDO Carried in a Discovery Reply Object . . 15 8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 14
9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 15 8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 15 8.2. Setting a P2P-RDO Carried in a Discovery Reply Object . . 16
9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 16 9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 17
9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 17 9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 17
9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 18
9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 19
9.4. Additional Processing of a P2P Mode DIO At An 9.4. Additional Processing of a P2P Mode DIO At An
Intermediate Router . . . . . . . . . . . . . . . . . . . 18 Intermediate Router . . . . . . . . . . . . . . . . . . . 20
9.5. Additional Processing of a P2P Mode DIO At The Target . . 19 9.5. Additional Processing of a P2P Mode DIO At The Target . . 21
9.6. Processing a DRO At An Intermediate Router . . . . . . . . 19 9.6. Processing a DRO At An Intermediate Router . . . . . . . . 22
9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 20 9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 23
10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 21 10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 24
11. Packet Forwarding Along a P2P-RPL Route . . . . . . . . . . . 22 11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 25
12. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13. Interoperability With Core RPL . . . . . . . . . . . . . . . . 23 13. Interoperability with Core RPL . . . . . . . . . . . . . . . . 26
14. Security Considerations . . . . . . . . . . . . . . . . . . . 23 14. Security Considerations . . . . . . . . . . . . . . . . . . . 26
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
15.1. Additions to DIO Mode of Operation . . . . . . . . . . . . 24 15.1. Additions to DIO Mode of Operation . . . . . . . . . . . . 27
15.2. Additions to RPL Control Message Options . . . . . . . . . 24 15.2. Additions to RPL Control Message Options . . . . . . . . . 27
15.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 25 15.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 27
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
17.1. Normative References . . . . . . . . . . . . . . . . . . . 25 17.1. Normative References . . . . . . . . . . . . . . . . . . . 28
17.2. Informative References . . . . . . . . . . . . . . . . . . 26 17.2. Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Targeting Low power and Lossy Networks (LLNs), the RPL routing Targeting Low power and Lossy Networks (LLNs), the RPL routing
protocol [I-D.ietf-roll-rpl] provides paths along a Directed Acyclic protocol [I-D.ietf-roll-rpl] provides paths along a Directed Acyclic
Graph (DAG) rooted at a single router in the network. Establishment Graph (DAG) rooted at a single router in the network. Establishment
and maintenance of the DAG is performed by each router in the LLN and maintenance of a DAG is performed by routers in the LLN using
using specific link-local multicast signaling (DIO messages). DODAG Information Object (DIO) messages. When two arbitrary routers
(neither of which is the DAG's root) need to communicate, the data
When two arbitrary routers (neither of which is the DAG's root) need packets are restricted to travel only along the links in the DAG.
to communicate, core RPL provides dog-legged paths along DAG links, Such point-to-point (P2P) routing functionality may not be sufficient
which may not be efficient enough for several Home and Building for several Home and Building Automation applications [RFC5826]
Automation applications [RFC5826][RFC5867], for the following [RFC5867] due to the following reasons:
reasons:
o The need to preprovision routes: each potential destination in the o The need to pre-establish routes: each potential destination in
network must declare itself as such, via specific additional the network must declare itself as such ahead of the time a source
signaling (DAO messages). needs to reach it.
o The need to route along DAG links: depending on the network o The need to route only along the links in the DAG: A DAG is built
topology and metrics in use, the constraint to route along a DAG to optimize the routing cost to reach the root. Restricting P2P
may cause significantly suboptimal P2P routes and severe traffic routes to use only the in-DAG links may result in significantly
congestion near the DAG root. suboptimal routes and severe traffic congestion near the DAG root.
This document thus describes a mechanism, complementary to the core This document describes an extension to core RPL that enables an IPv6
RPL functionality, that enables a router to discover on-demand a router in the LLN to discover routes to one or more IPv6 routers in
route to another arbitrary router in the LLN, such that the the LLN "on demand", such that the discovered routes meet the
discovered route meets specified metrics constraints, without specified metrics constraints, without necessarily going along the
necessarily going along an existing DAG. This reactive P2P route links in an existing DAG. This reactive P2P route discovery
discovery mechanism is henceforth referred to as P2P-RPL. P2P-RPL mechanism is henceforth referred to as P2P-RPL. P2P-RPL does not
allows for the discovery of source routes as well as hop-by-hop guarantee discovery of a route. Also, the discovered routes may not
routes. Discovered routes may not be the best available but are be the best available. However, any discovered routes are guaranteed
guaranteed to satisfy the desired constraints in terms of the routing to satisfy the desired constraints in terms of the routing metrics
metrics and are thus considered "good enough" from the application's and are thus considered "good enough" from the application's
perspective. perspective.
A complementary functionality that helps decide whether or not to A mechanism to measure the end-to-end cost of an existing route has
initiate a P2P route discovery, is a mechanism to measure the end-to- been specified in [I-D.ietf-roll-p2p-measurement]. As discussed in
end cost of an existing route. Section 4 provides further details on Section 4, measuring the end-to-end cost of an existing route may
how such functionality, specified in [I-D.ietf-roll-p2p-measurement], help decide whether to initiate the discovery of a better route using
is used to determine the value of metric constraints for the route P2P-RPL and the metric constraints to be used for this purpose.
discovery using P2P-RPL.
2. The Use Cases 2. The Use Cases
P2P-RPL is intended to be employed as complementary to RPL in One use case, common in home and commercial building environments,
specific scenarios that need P2P paths between arbitrary routers. involves a device (say a remote control or an airduct controller)
that suddenly needs to communicate with another device (say a lamp or
One use case, common in a home environment, involves a remote control a humidity sensor) to which it does not already have a route. In
(or a motion sensor) that suddenly needs to communicate with a lamp this case, the remote control (or the airduct controller) must be
module, whose network address is a-priori known. In this case, the able to discover a route to the lamp (or the humidity sensor) "on
source of data (the remote control or the motion sensor) must be able demand".
to discover a route to the destination (the lamp module) "on demand".
Another use case, common in a large 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, and thus routes
across this DAG are desirable. across this DAG are desirable.
The use cases also include scenarios where energy or latency Other use cases involve scenarios where energy or latency constraints
constraints are not satisfied by the routes provided by core RPL are not satisfied by the P2P routes along an existing DAG because
along a DAG because they involve traversing many more intermediate they involve traversing many more intermediate routers than necessary
routers than necessary to reach the destination. to reach the destination.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
Additionally, this document uses terminology from Additionally, this document uses terminology from
[I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. This document [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. This document
introduces the following terms: introduces the following terms:
Origin : The RPL router initiating the P2P route discovery. Origin : The IPv6 router initiating the P2P-RPL route discovery.
Target : The RPL router at the other end point of the P2P route(s) to Target : The IPv6 router at the other end point of the P2P route(s)
be discovered. to be discovered. A P2P-RPL route discovery can discover routes to
multiple targets at the same time.
Intermediate Router: An RPL router that is neither the origin nor the Intermediate Router: An IPv6 router that is neither the origin nor a
target. target.
Forward Route: A route in the forward direction, i.e., from the Forward Route: A route in the forward direction, i.e., from the
origin to the target. origin to the target.
Backward Route: A route in the backward direction, i.e., from the Backward Route: A route in the backward direction, i.e., from the
target to the origin. target to the origin.
Bidirectional Route: A route that can be used in both forward and Bidirectional Route: A route that can be used in both forward and
backward directions. backward directions.
Source Route: A complete and ordered list of routers that can be used Source Route: A complete and ordered list of routers that can be used
by a packet to travel from a source 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.
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 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 and establish one hop-by-hop route or discover designed to discover hop-by-hop or source routes to one or more
one or more source routes such that the discovered route(s) meet the targets such that the discovered routes meet the specified
specified constraints. In some application contexts, the constraints constraints. In some application contexts, the constraints that the
that the discovered route(s) must satisfy are intrinsically known or discovered routes must satisfy are intrinsically known or can be
can be specified by the application. For example, an origin that specified by the application. For example, an origin that expects
expects a target to be less than 5 hops away may use "hop-count < 5" its targets to be less than 5 hops away may use "hop-count < 5" as
as the constraint. In other application contexts, the origin may the constraint. In other application contexts, the origin may need
need to measure the cost of an existing route to the target to to measure the cost of the existing route to a target to determine
determine the constraints. For example, an origin that measures the the constraints. For example, an origin that measures the total ETX
total ETX of its along-DAG route to the target to be 20 may use "ETX along its current route to a target to be 20 may use "ETX < x*20",
< x*20", where x is a fraction that the origin decides, as the where x is a fraction that the origin decides, as the constraint. A
constraint. A mechanism to measure the cost of an existing route mechanism to measure the cost of an existing route between two IPv6
between the origin and the target is specified in routers is specified in [I-D.ietf-roll-p2p-measurement]. If there is
[I-D.ietf-roll-p2p-measurement]. If there is no existing route no existing route between the origin and the target(s) or the cost
between the origin and target or the cost measurement for the measurement for the existing routes fails, the origin will have to
existing route fails, the origin will have to guess the constraints guess the constraints to be used in the initial route discovery.
used in the initial route discovery. Once, the initial route Once, the initial route discovery succeeds or fails, the origin will
discovery succeeds or fails, the origin will have a better estimate have a better estimate for the constraints to be used in the
for the constraints to be used in the subsequent route discovery. subsequent route discovery.
P2P-RPL may result in discovery of better P2P routes than the ones P2P-RPL may result in discovery of better P2P routes than the ones
available along a DAG designed to optimize routing cost to the DAG's available along a DAG designed to optimize routing cost to the DAG's
root. The improvement in route quality depends on a number of root. The improvement in route quality depends on a number of
factors including the network topology, the routing metrics in use factors including the network topology, the routing metrics in use
and the prevalent conditions in the network. A network designer may and the prevalent conditions in the network. A network designer may
take into consideration both the benefits (potentially better routes; take into consideration both the benefits (potentially better routes;
no need to maintain routes proactively) and costs (control messages no need to maintain routes proactively) and costs (control messages
generated during the route discovery process) when using P2P-RPL. generated during the route discovery process) when using P2P-RPL.
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.
As is the case with core RPL, P2P-RPL uses IPv6 link-local multicast A P2P-RPL route discovery takes place by forming a DAG rooted at the
DIO messages to establish a DAG (unlike core RPL, this DAG is origin. As is the case with core RPL, P2P-RPL uses IPv6 link-local
temporary). Each router joining the DAG determines a rank for itself multicast DIO messages to establish a DAG. However, unlike core RPL,
in the DAG and ignores the subsequent DIO messages received from this DAG is temporary in nature and routers in the DAG leave once the
lower (higher in numerical value) ranked neighbors. Thus, the DIO DAG's life time is over. The sole purpose of DAG creation is to
messages propagate outward from the DAG root rather than return discover routes to the target(s) and DIOs serve as the route
inward towards the DAG root. As in core RPL, DIO message generation discovery messages. Each router joining the DAG determines a rank
at a router is further controlled by a Trickle timer that allows a for itself in the DAG and ignores the subsequent DIOs received from
router to avoid generating unnecessary messages [RFC6206]. P2P-RPL lower (higher in numerical value) ranked neighbors. Thus, the route
also uses the routing metrics [I-D.ietf-roll-routing-metrics], discovery messages propagate away from the origin rather than return
objective functions and packet forwarding framework specified for back to it. As in core RPL, DIO generation at a router is controlled
core RPL. by a Trickle timer [RFC6206] that allows a router to avoid generating
unnecessary messages while providing protection against unreliable
wireless communication. P2P-RPL also uses the routing metrics
[I-D.ietf-roll-routing-metrics], objective functions and packet
forwarding framework
[I-D.ietf-6man-rpl-routing-header][I-D.ietf-6man-rpl-option]
developed for core RPL.
In P2P-RPL, a route discovery takes place by forming a temporary DAG An origin may use P2P-RPL to discover routes to one or more targets
identified by one or more unicast/multicast addresses. P2P-RPL
allows for the discovery of one hop-by-hop route or upto four source
routes per target. P2P-RPL allows an origin to piggyback time-
critical application data on the DIO messages for delivery to the
target(s). P2P-RPL does not guarantee discovery of a route to a
target. Also, the discovered routes may not be the best available.
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 P2P-RPL route discovery takes place by forming a temporary DAG
rooted at the origin. The DIOs, used to create the temporary DAG, rooted at the origin. The DIOs, used to create the temporary DAG,
are identified by a new Mode of Operation (P2P Route Discovery mode are identified by a new Mode of Operation (P2P Route Discovery mode
defined in Section 6) and carry the following information (in a P2P defined in Section 6). The DIOs, listing the P2P Route Discovery
Route Discovery Option defined in Section 7): mode as the Mode of Operation, are henceforth referred to as the P2P
mode DIOs. A P2P mode DIO always carries one P2P Route Discovery
Option (defined in Section 7.1) in which the origin specifies the
following information:
o An IPv6 address of the target. o The IPv6 address of a target. This could be a unicast address or
a multicast one. Any additional targets may be specified by
including one or more RPL Target Options [I-D.ietf-roll-rpl]
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 in the forward direction. 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 route(s) need to be bidirectional. If bidirectional o Whether the target(s) should send Discovery Reply Object (DRO)
route(s) are being discovered, the target may store the route in messages (defined in Section 8) back to the origin on receiving a
backward direction for use as a source route. This specification DIO message. A DRO message carries a discovered source route back
does not provide for the establishment of backward hop-by-hop to the origin or establishes a hop-by-hop route between the origin
routes. and the target. By not allowing the generation of DRO messages,
an origin can use P2P-RPL as purely a mechanism to deliver time-
critical application data to the target(s).
The DIOs, listing the P2P Route Discovery mode as the Mode of A P2P Route Discovery Option also accumulates a route from the origin
Operation, are henceforth referred to as the P2P mode DIOs. The P2P to a target as the routers join the temporary DAG.
mode DIOs MAY also carry the following information (in one or more
Metric Container Options):
o The relevant routing metrics A P2P mode DIO MAY also carry:
o The constraints that the discovered route must satisfy. These o One or more Metric Container Options to specify:
constraints also limit how far the DIOs message may travel.
* The relevant routing metrics.
* The constraints that the discovered route must satisfy. These
constraints also limit how far the DIOs message may travel.
o One or more RPL Target options to specify additional unicast or
multicast targets.
o One or more Data Options (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
(partial) route(s) they have seen and advertise these routes, along (partial) route(s) they have seen and advertise these routes, along
with the corresponding routing metrics, in their P2P mode DIOs. The with the corresponding routing metrics, in their P2P mode DIOs. A
routing metrics are measured in forward direction unless router, including the target(s), discards a received P2P mode DIO if
bidirectional routes are being discovered, in which case the the aggregated routing metrics on the route advertised by the DIO do
measurement of routing metrics need to take into account both forward not satisfy the listed constraints. These constraints can be used to
and backward directions. A router, including the target, discards a limit the propagation of P2P mode DIO messages. A router may also
received P2P mode DIO if the aggregated routing metrics on the route discard a received P2P mode DIO if it does not wish to be a part of
advertised by the DIO do not satisfy the listed constraints. These the discovered route due to limited resources or due to policy
constraints can be used to limit the propagation of P2P mode DIO reasons.
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
resources or due to policy reasons.
When the target receives a P2P mode DIO, it checks whether the route When a target receives a P2P mode DIO, it forwards the data in any
advertised therein satisfies the routing constraints. If yes, the Data Options to the higher layer. The target may remember the
target may select the route for further processing as described next. discovered route for use as a source route to reach the origin. If
This document does not specify a particular method for the target to the origin has requested DRO messages to be sent back, the target may
select a route among the ones that satisfy the route constraints. select the route contained in the received DIO for further processing
Examples include selecting any route that meets the constraints or as described next. This document does not specify a particular
selecting the best route(s) discovered over a certain time period. 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 routes are being discovered, the target sends If one or more source routes are being discovered, the target sends
the discovered source routes to the origin via Discovery Reply Object the selected source routes to the origin via DRO messages with one
(DRO) messages (defined in Section 8) with one DRO message carrying DRO message carrying one discovered route. On receiving a DRO
one discovered route. On receiving a DRO message, the origin stores message, the origin stores the discovered route in its memory. If a
the route contained therein in its memory. hop-by-hop route is being discovered, the target sends a DRO message
containing the selected route to the origin. The DRO message travels
If a hop-by-hop route is being discovered, the target sends a DRO back to the origin along the selected route, establishing state for
message to the origin after selecting a suitable route among the ones this route in the routers on the path. The target may include one or
that satisfy the route constraints. The DRO message travels towards more Data Options in a DRO message to deliver any time-critical
the origin along the discovered route, establishing state for this application data to the origin.
route in the routers on the path.
The target may store a discovered route in its memory if it is
bidirectional and use it as a backward source-route to send packets
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 DRO
message by sending back a DRO Acknowledgement (DRO-ACK) message message by sending back a DRO Acknowledgement (DRO-ACK) message
(defined in Section 10). The origin unicasts a DRO-ACK message to (defined in Section 10). The origin unicasts a DRO-ACK message to
the target. When the target does not receive the requested DRO-ACK the target. When the target does not receive the requested DRO-ACK
within a certain time interval of sending a DRO, it resends the DRO within a certain time interval of sending a DRO, it resends the DRO
message (up to a certain number of times) carrying the same route as message (up to a certain number of times) carrying the same route as
before. 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"
bit in the DRO message to let the nodes in the LLN know about the flag in the DRO message to let the nodes in the LLN know about the
completion of the route discovery process. completion of the route discovery process. The routers receiving
such a DRO should not generate any more DIOs for this temporary DAG.
Neither should they process any received DIOs for this temporary DAG
in future. However, such routers must still process the 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 4 (to be Discovery mode (or P2P mode, for short), with value 4 (to be
confirmed by IANA). A DIO message, listing P2P mode as the MOP, is confirmed by IANA). A DIO message, listing P2P mode as the MOP, is
identified as performing reactive P2P route discovery by creating a identified as performing a P2P-RPL route discovery by creating a
temporary DAG. A P2P mode DIO MUST carry one P2P Route Discovery temporary DAG. A P2P mode DIO MUST carry one and only one P2P Route
Option (specified in Section 7). Discovery Option (specified in Section 7.1).
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 [I-D.ietf-roll-rpl]. The origin MUST NOT use the Section 5.1 of [I-D.ietf-roll-rpl]. The origin MUST NOT use the
same RPLInstanceID in two or more concurrent route discoveries. same RPLInstanceID in two or more concurrent route discoveries.
The origin MAY use the same RPLInstanceID value to establish hop-
by-hop P2P-RPL routes to different target routers as long as these
route discoveries are not concurrent.
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. versions.
o Grounded (G) Flag: MUST be cleared since this DAG is temporary in o Grounded (G) Flag: MUST be cleared since this DAG is temporary in
nature, is created solely for the purpose of P2P-RPL route nature, is created solely for the purpose of P2P-RPL route
discovery and MUST NOT be used for packet routing. discovery and MUST NOT be used for packet routing.
o Mode of Operation (MOP): MUST be set to 4, corresponding to P2P o Mode of Operation (MOP): MUST be set to 4, corresponding to P2P
skipping to change at page 9, line 39 skipping to change at page 10, line 21
o Lifetime Unit: 0xFFFF o Lifetime Unit: 0xFFFF
o Objective Code Point: 0, i.e., OF0 [I-D.ietf-roll-of0] is the o Objective Code Point: 0, i.e., OF0 [I-D.ietf-roll-of0] is the
default objective function. default objective function.
o The remaining parameters have default values as specified in o The remaining parameters have default values as specified in
[I-D.ietf-roll-rpl]. [I-D.ietf-roll-rpl].
The routing metrics and constraints [I-D.ietf-roll-routing-metrics] The routing metrics and constraints [I-D.ietf-roll-routing-metrics]
used in P2P-RPL route discovery are included in one or more Metric used in P2P-RPL route discovery are included in one or more Metric
Container options [I-D.ietf-roll-rpl] inside the P2P mode DIO. Note Container Options [I-D.ietf-roll-rpl] inside the P2P mode DIO. Note
that a DIO need not include a Metric Container if OF0 is the that a DIO need not include a Metric Container if OF0 is the
objective function in effect. In that case, a P2P mode DIO may still objective function in effect. In that case, a P2P mode DIO may still
specify an upper limit on the maximum rank, that a router may have in specify an upper limit on the maximum rank, that a router may have in
the temporary DAG, inside the P2P Route Discovery Option (described the temporary DAG, inside the P2P Route Discovery Option (described
in Section 7). in Section 7.1).
A P2P mode DIO: A P2P mode DIO:
o MUST NOT carry any Route Information or Prefix Information Options
(described in [I-D.ietf-roll-rpl]).
o MUST carry one (and only one) P2P Route Discovery Option o MUST carry one (and only one) P2P Route Discovery Option
(described in Section 7). (described in Section 7.1). The P2P Route Discovery Option allows
for the specification of one unicast or multicast address for the
target.
o MAY carry one or more RPL Target Options to specify additional
unicast/multicast addresses for the target.
o MAY carry one or more Metric Container Options to specify routing
metrics and constraints.
o MAY carry one or more Data Options (described in Section 7.2)
containing time-critical application data to be delivered to the
target(s).
o MAY carry one or more Route Information or Prefix Information
Options (described in [I-D.ietf-roll-rpl]).
A router MUST discard a received P2P mode DIO if it violates any of A router MUST discard a received P2P mode DIO if it violates any of
the rules listed above. the rules listed above.
7. P2P Route Discovery Option (P2P-RDO) 7. New RPL Control Message Options
This section specifies a new RPL option, P2P Route Discovery Option This document defines two new RPL control message options: the P2P
(P2P-RDO), one instance of which MUST be carried inside a P2P mode Route Discovery Option and the Data Option.
DIO message.
7.1. 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 = 10 | Option Length |D|H| N | Compr | L |MaxRank/NH | | Type = 10 | Option Length |R|H| N | Compr | L |MaxRank/NH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Target | | Target |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| 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-RDO is illustrated in Figure 1. A P2P mode DIO The format of a P2P Route Discovery Option (P2P-RDO) is illustrated
and a DRO (defined in Section 8 message MUST carry one P2P-RDO. A in Figure 1. A P2P mode DIO and a DRO (defined in Section 8) message
P2P-RDO consists of the following fields: MUST carry one and at most one P2P-RDO. A P2P-RDO consists of the
following fields:
o Option Type: 0x0A (to be confirmed by IANA). o Option Type: 0x0A (to be confirmed by IANA).
o Option Length: 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 Direction (D): This flag indicates the direction in which the o Reply (R): The origin sets this flag to 1 to allow the target(s)
desired routes should be optimized. The flag is set to 1 if the to send DRO messages back to the origin. If this flag is 0, a
routes are to be optimized for use in both forward and backward target MUST NOT generate any DRO message.
directions. If the discovered routes need to be optimized in the
forward direction only, the flag is reset to 0. Note that the
discovered routes should have bidirectional reachability
irrespective of the value of the D flag. This is because DRO
messages travel from the target back to the origin along one of
the discovered routes. The link-level metric objects contained in
the P2P mode DIO SHOULD be measured in the direction indicated by
the D flag.
o Hop-by-hop (H): This flag is set to 1 if a hop-by-hop route is o Hop-by-hop (H): This flag is valid only if the R flag is set to 1.
desired. The flag is reset to zero if source routes are desired. The origin sets this flag to 1 if it desires hop-by-hop routes.
This specification allows for the establishment of one hop-by-hop The origin sets this flag to 0 if it desires source routes. This
route or up to four source routes in the forward direction. This specification allows for the establishment of one hop-by-hop route
specification does not allow for the establishment of hop-by-hop or up to four source routes per target. The hop-by-hop route is
routes in the backward direction. If a bidirectional route is established in the forward direction, i.e. from the origin to the
discovered, the target MAY use the route in backward direction as target. This specification does not allow for the establishment
a source route to reach the origin, irrespective of the value of of hop-by-hop routes in the backward direction.
the H flag.
o Number of Routes (N): When source routes are being discovered, the o Number of Routes (N): This flag is valid only if the R flag is 1
value in this field plus one indicates the desired number of and H flag is 0, i.e. the targets are allowed to generate DRO
routes. When a hop-by-hop route is being discovered this field messages carrying discovered source routes back to the origin. In
MUST be set to zero on transmission and ignored on reception. this case, the value in the N field plus one indicates the number
of source routes that each target should convey to the origin.
When hop-by-hop routes are being discovered, the N field 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 0 if full IPv6 addresses vector. For example, Compr value will be 0 if full IPv6 addresses
are carried in the Target field and the Address vector. are carried in the Target field and the Address vector.
o Life Time (L): A 2-bit field that indicates the suggested life o Life Time (L): A 2-bit field that indicates the suggested life
time of the temporary DAG, i.e., the suggested duration a router time of the temporary DAG, i.e., the suggested duration a router
joining the temporary DAG SHOULD maintain its membership in the joining the temporary DAG SHOULD maintain its membership in the
DAG. The mapping between the values in this field and the life DAG. The mapping between the values in this field and the life
skipping to change at page 11, line 42 skipping to change at page 12, line 35
* 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 DIOs to reach the target. Note that a time required for the DIOs to reach the target(s).
router MAY detach from the temporary DAG sooner if it receives a
DRO message concerning this DAG with "stop" bit set.
o MaxRank/NH: o MaxRank/NH:
* When a P2P Route Disovery Option is included in a P2P mode DIO, * When a P2P-RDO is included in a P2P mode DIO, this field
this field indicates the upper limit on the integer portion of indicates the upper limit on the integer portion of the rank
the rank (calculated using the DAGRank() macro defined in (calculated using the DAGRank() macro defined in
[I-D.ietf-roll-rpl]) that a router may have in the temporary [I-D.ietf-roll-rpl]) that a router may have in the temporary
DAG being created. An intermediate router MUST NOT join a DAG being created. An intermediate router MUST NOT join a
temporary DAG being created by a P2P mode DIO if the integer temporary DAG being created by a P2P mode DIO if the integer
portion of its rank would be equal to or higher (in numerical portion of its rank would be equal to or higher (in numerical
value) than the MaxRank limit. The target can join the value) than the MaxRank limit. A target can join the temporary
temporary DAG at a rank whose integer portion is equal to the DAG at a rank whose integer portion is equal to the MaxRank. A
MaxRank. A router MUST discard a received P2P mode DIO if the router MUST discard a received P2P mode DIO if the integer part
integer part of the advertized rank equals or exceeds the of the advertized rank equals or exceeds the MaxRank limit. A
MaxRank limit. A value 0 in this field indicates that the value 0 in this field indicates that the MaxRank is infinity.
MaxRank is infinity.
* When a P2P-RDO is included in a DRO message, this field * When a P2P-RDO is included in a 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 Target: The IPv6 address of the target after eliding Compr number o Target: An IPv6 address of the target after eliding Compr number
of prefix octets. of prefix octets. When the P2P-RDO is included in a P2P mode DIO,
this field may contain a unicast address or a multicast one. Any
additional target addresses can be specified by including one or
more RPL Target Options [I-D.ietf-roll-rpl] in the DIO. When the
P2P-RDO is included in a DRO, this field MUST contain a unicast
IPv6 address of the target generating the DRO.
o Address[1..n]: A vector of IPv6 addresses representing a (partial) o Address[1..n]: A vector of IPv6 addresses representing a (partial)
route in the forward direction: route 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 IPv6 address with first Compr octets
elided. 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).
* The Address vector is used to accumulate a route optimized in
the direction specified by the D flag.
* The IPv6 addresses in the Address vector MUST be accessible in * The IPv6 addresses in the Address vector MUST be accessible in
both forward and backward directions. Accessibility in the both forward and backward directions. Accessibility in the
backward direction is required because the DRO message uses the backward direction allows a DRO message to use the route
route accumulated in the Address vector to travel from the accumulated in the Address vector to travel from the target to
target to the origin. 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 its * A router adding its address to the vector MUST ensure that its
address does not already exist in the vector. A router address does not already exist in the vector. A router
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
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 = 11 | Option Length | 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 or more
Data Options. A P2P-RDO consists of the following fields:
o Option Type: 0x0B (to be confirmed by IANA).
o Option Length: 8-bit unsigned integer, representing the length in
octets of the option, not including the Option Type and Option
Length fields.
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.
8. The Discovery Reply Object (DRO) 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 Discovery
Reply Object (DRO), with code 0x04 (to be confirmed by IANA), and the Reply Object (DRO), with code 0x04 (to be confirmed by IANA), and the
Secure DRO, with code 0x84 (to be confirmed by IANA). A DRO serves Secure DRO, with code 0x84 (to be confirmed by IANA). A DRO serves
one of the following functions: one of the following functions:
o Carry a discovered source route from the 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 the target to the o Establish a hop-by-hop route as it travels from a target to the
origin. origin.
A DRO message MAY also serve the function of letting the routers in A DRO message MAY serve the function of letting the routers in the
the LLN know that a P2P-RPL route discovery is complete and no more LLN know that a P2P-RPL route discovery is complete and no more DIO
DIO messages need to be generated for the corresponding temporary messages need to be generated for the corresponding temporary DAG. A
DAG. A DRO message MUST carry one P2P-RDO and travel from the target DRO message MAY also carry time-critical application data from the
to the origin via link-local multicast along the route specified target to the origin in one or more Data Options. A DRO message MUST
inside the Address vector in the P2P-RDO. carry one P2P-RDO whose Target field MUST contain a unicast IPv6
address of the target that generated the DRO. A DRO message travels
from the target to the origin via link-local multicast along the
route specified inside the Address vector in the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID | Version |Seq|S|A| Reserved | | RPLInstanceID | Version |S|A|Seq| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| DODAGID | | DODAGID |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 2: Format of the base Discovery Reply Object (DRO) Figure 3: Format of the base Discovery Reply Object (DRO)
The format of the base Discovery Reply Object (DRO) is shown in The format of the base Discovery Reply Object (DRO) is shown in
Figure 2. A base DRO consists of the following fields: Figure 3. A base 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 Sequence Number (Seq): This 2-bit field indicates the sequence o Stop (S): This flag, when set by a target, indicates that the P2P-
number for the DRO. This field is relevant when the A flag RPL route discovery is over. All the routers receiving such a
(specified below) is set, i.e., the target requests an
acknowledgement from the origin for a received DRO. The origin
includes the RPLInstanceID, the DODAGID and the Sequence Number of
the received DRO inside the DRO-ACK message it sends back to the
target.
o Stop (S): This flag, when set by the target, indicates that the
P2P-RPL route discovery is over. All the routers receiving such a
DRO, including the ones not listed in the route carried inside DRO, including the ones not listed in the route carried inside
P2P-RDO, SHOULD cancel any pending DIO transmissions for the P2P-RDO,
temporary DAG created for the route discovery and MAY detach from
this DAG immediately. Note that the stop flag serves to stop * SHOULD NOT process any more DIOs received for this temporary
further DIO transmissions for a P2P-RPL route discovery but it DAG;
does not affect the processing of DRO messages at either the
origin or the intermediate routers. In other words, a router (the * SHOULD NOT generate any more DIOs for this temporary DAG;
origin or an intermediate router) MUST continue to process the DRO
messages even if an earlier DRO message (with same RPLInstanceID, * SHOULD cancel any pending DIO transmission for this temporary
DODAGID and Version Number fields) had the stop flag set. DAG.
Note that the stop flag serves to stop further DIO transmissions
for a P2P-RPL route discovery but it does not affect the
processing of DRO messages at either the origin or the
intermediate routers. In other words, a router (the origin or an
intermediate router) MUST continue to process the DRO messages
even if an earlier DRO message (with same RPLInstanceID and
DODAGID fields) had the stop flag set to 1.
o Ack Required (A): This flag, when set by the target, indicates o Ack Required (A): This flag, when set by the target, indicates
that the origin SHOULD unicast a DRO-ACK message (defined in that the origin MUST unicast a DRO-ACK message (defined in
Section 10) to the target when it receives the DRO. Section 10) to the target when it receives the DRO.
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, i.e., the target requests an acknowledgement from the origin
for a received DRO. The origin includes the RPLInstanceID, the
DODAGID and the Sequence Number of the received DRO inside the
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 MUST carry one P2P-RDO that MUST specify o Options: The DRO message:
a complete route between the target and the origin. The DRO
message MAY carry a Metric Container Option that contains the * MUST carry one P2P-RDO that MUST specify a complete route
aggregated routing metrics values for the route specified in P2P- between the target and the origin;
RDO.
* MAY carry one or more Metric Container Options that contains
the aggregated routing metrics values for the route specified
in P2P-RDO;
* MAY carry one or more Data Options to carry any time-critical
application data to the origin.
8.1. Secure DRO 8.1. Secure DRO
A Secure DRO message follows the format in Figure 7 of A Secure DRO message follows the format in Figure 7 of
[I-D.ietf-roll-rpl], where the base format is the base DRO shown in [I-D.ietf-roll-rpl], where the base format is the base DRO shown in
Figure 2. Figure 3.
8.2. Setting a P2P-RDO Carried in a Discovery Reply Object 8.2. Setting a P2P-RDO Carried in a Discovery Reply Object
A Discovery Reply Object MUST carry one P2P-RDO, which MUST be set as A Discovery Reply Object MUST carry one P2P-RDO, which MUST be set as
defined in Section 7 with the following exceptions: defined in Section 7.1. Specifically, the following fields MUST be
set as specified next:
o Direction (D): 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
message MUST have the same value as the H flag in the P2P-RDO
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 DRO message, the
NH field is set to n = (Option Length - 2 - (16 - Compr))/(16 - NH field is set to n = (Option Length - 2 - (16 - Compr))/(16 -
Compr). Compr).
o Target: This field MUST contain a unicast IPv6 address of the
target generating the 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 functioning of P2P-RPL route discovery by This section details the functioning of P2P-RPL route discovery by
creating a temporary DAG, using the P2P mode DIO, DRO and DRO-ACK creating a temporary DAG, using the P2P mode DIO, DRO and DRO-ACK
messages. messages.
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, MUST join the temporary DAG being created the origin and the target(s), MUST join the temporary DAG being
for the purpose. When a router joins a temporary DAG advertized by a created for the purpose. When a router joins a temporary DAG
P2P mode DIO, it SHOULD maintain its membership in the temporary DAG advertized by a P2P mode DIO, it SHOULD maintain its membership in
for the suggested Life Time duration listed in the P2P-RDO. The only the temporary DAG for the suggested Life Time duration listed in the
purpose of a temporary DAG's existence is to facilitate the P2P-RPL P2P-RDO. The only purpose of a temporary DAG's existence is to
route discovery process. The temporary DAG MUST NOT be used to route facilitate the P2P-RPL route discovery process. The temporary DAG
packets. A router SHOULD detach from the temporary DAG once the MUST NOT be used to route packets. A router SHOULD detach from the
duration of its membership in the DAG has exceeded the DAG's temporary DAG once the duration of its membership in the DAG has
suggested life time. A router MAY detach from a temporary DAG sooner exceeded the DAG's suggested life time. A router SHOULD NOT send or
when it receives a DRO about the temporary DAG with the stop flag receive any more DIOs for the temporary DAG and SHOULD cancel any
set. pending DIO transmission when it receives a DRO about the temporary
DAG with the stop flag set to 1.
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 wireless loss of DIOs due to inherent lack of reliability in wireless
communication. When controlling the transmissions of a P2P mode DIO, communication. When controlling the transmissions of a P2P mode DIO,
a Trickle timer SHOULD follow the following rules: a Trickle timer SHOULD follow the following rules:
skipping to change at page 17, line 43 skipping to change at page 19, line 43
is suitable for environments with low or moderate packet loss is suitable for environments with low or moderate packet loss
rates. In environments with high packet loss rates, a higher rates. In environments with high packet loss rates, a higher
value for the redundancy constant may be more suitable. value for the redundancy constant may be more suitable.
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 [I-D.ietf-roll-rpl], apply to P2P mode DIOs as well except as of RPL [I-D.ietf-roll-rpl], apply to P2P mode DIOs as well except as
modified in this document. modified in this document.
The following rules for processing a P2P mode DIO apply to both The following rules for processing a received P2P mode DIO apply to
intermediate routers and the target. both intermediate routers and the target.
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 originated the received DIO. This is to ensure that a neighbor that generated the received DIO. Note that bidirectional
discovered route can be used to send a DRO message from the target to reachability does not mean that the link must have the same values
the origin. Note that bidirectional reachability does not mean that for a routing metric in both directions. A router SHOULD calculate
the link must have the same values for a routing metric in both the values of the link-level routing metrics included in the received
directions. A router SHOULD update the values of the link-level DIO taking in account the metric's value in both forward and backward
routing metrics included inside the DIO in the direction indicated by directions. Bidirectional reachability along a discovered route
the D flag in the P2P-RDO. If the D flag is 0, i.e., the discovered allows the target to use this route to reach the origin. In
routes need not be bidirectional, the link-level routing metrics particular, the DRO messages travel from the target to the origin
SHOULD be measured in the forward direction, i.e., towards the node along a discovered route.
receiving the DIO. If the D flag is 1, i.e., bidirectional routes
are desired, the link-level routing metrics SHOULD be calculated so
as to take into account the metric's value in both forward and
backward directions.
A router MUST discard the 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 o If the DIO advertises INFINITE_RANK as defined in
[I-D.ietf-roll-rpl]. [I-D.ietf-roll-rpl].
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 router cannot evaluate the mandatory route constraints o If the router cannot evaluate the mandatory route constraints
listed in the DIO or if the routing metric values do not satisfy listed in the DIO or if the routing metric values do not satisfy
one or more of the mandatory constraints. one or more of the mandatory constraints.
o If the router previously received a DRO message with same
RPLInstanceID and DODAGID as the received DIO and with the stop
flag set to 1.
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
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
considers itself a target and processes the received DIO as specified
in Section 9.5. Otherwise, the router considers itself an
intermediate router and processes the received DIO as specified in
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 if the router cannot elide Compr (as specified in
the P2P-RDO) prefix octets from its IPv6 address. the P2P-RDO) prefix octets from its IPv6 address.
On receiving a P2P mode DIO, an intermediate router MUST determine On receiving a P2P mode DIO, an intermediate router MUST determine
whether this DIO advertises a better route than the router itself and 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 whether the receipt of the DIO would allow the router to advertise a
better route than before. Accordingly, the router SHOULD consider better route than before. Accordingly, the router SHOULD consider
this DIO as consistent/inconsistent from Trickle perspective as this DIO as consistent/inconsistent from Trickle perspective as
described in Section 9.2. Note that the route comparison in a P2P- described in Section 9.2. Note that the route comparison in a P2P-
RPL route discovery is performed using the parent selection rules of RPL route discovery is performed using the parent selection rules of
the OF in use as specified in Section 14 of RPL [I-D.ietf-roll-rpl]. the OF in use as specified in Section 14 of RPL [I-D.ietf-roll-rpl].
If the received DIO would allow the router to improve the route it If the received DIO would allow the router to advertise a better
advertises, the router MUST store the route advertised in the DIO in route, the router MUST remember the route advertised (inside the P2P-
memory (after adding its own IPv6 address to the route) for inclusion RDO) in the DIO (after adding its own IPv6 address to the route) as
in its future DIOs. When an intermediate router adds itself to a well as any Data Options for inclusion in its future DIOs. When an
route, it MUST ensure that the IPv6 address added to the route is intermediate router adds itself to a route, it MUST ensure that the
accessible in both forward and backward directions. To improve the IPv6 address added to the route is reachable in both forward and
diversity of the routes being discovered, an intermediate router backward directions. To improve the diversity of the routes being
SHOULD keep track of multiple partial routes to be advertised in the discovered, an intermediate router SHOULD keep track of multiple
P2P-RDO inside its DIO. When the router generates its DIO, it SHOULD partial routes to be advertised in the P2P-RDO inside its DIO. When
randomly select the partial route to be included in the P2P-RDO. the router generates its DIO, it SHOULD randomly select the partial
route to be included in the P2P-RDO.
9.5. Additional Processing of a P2P Mode DIO At The Target 9.5. Additional Processing of a P2P Mode DIO At The Target
The target discards a received P2P mode DIO with no further The target MUST deliver the data contained in any Data Options in the
processing if the routing metrics inside the DIO do not satisfy the received DIO to the application layer. The target MAY store the
mandatory constraints. Otherwise, the target MAY select the route route contained in the P2P-RDO in the received DIO for use as a
contained in the P2P-RDO for further processing. This document does source route to reach the origin. If the Reply flag inside the P2P-
not prescribe a particular method for the target to select such RDO is 0, the target MUST discard the received DIO with no further
routes. Examples include selecting the desired number of routes as processing. Otherwise, the target MAY select the route contained in
they are identified or selecting the best routes discovered over a the P2P-RDO to send a DRO message back to the origin. If the H flag
certain time period. If multiple routes are desired, the target inside the P2P-RDO is 1, the target needs to select one route and
SHOULD avoid selecting routes that have large segments in common. If send a DRO message along this route back to the origin. If the H
a discovered route is bidirectional (D=1), the target MAY store the flag is 0, the number of routes to be selected (and the number of DRO
route in backward direction, obtained by reversing the discovered messages to be sent back) is given by one plus the value of the N
forward route, for use as a source route to reach the origin. After field in the P2P-RDO. This document does not prescribe a particular
selecting a route, the target sends a Discovery Reply Object (DRO) method for the target to select the routes. Example methods include
message back to the origin (identified by the DODAGID field in the selecting each route that meets the specified routing constraints
DIO). In this DRO, the target includes a P2P-RDO that contains the until the desired number have been selected or selecting the best
selected route inside the Address vector. The P2P-RDO included in routes discovered over a certain time period. If multiple routes are
the DRO message MUST copy the H flag from the P2P-RDO inside the to be selected, the target SHOULD avoid selecting routes that have
received DIO message. The other fields inside the P2P-RDO MUST be large segments in common.
set as specified in Section 7. The mechanism for the propagation of
DRO messages is described in Section 8.
The target MAY set the A flag inside the DRO message if it desires If the target selects the route contained in the P2P-RDO in the
the origin to send back a DRO-ACK message on receiving the DRO. In received DIO, it sends a DRO message back to the origin (identified
this case, the target waits for DRO_ACK_WAIT_TIME duration for the by the DODAGID field in the DIO). The DRO message MUST include a
DRO-ACK message to arrive. Failure to receive the DRO-ACK message P2P-RDO that contains the selected route inside the Address vector.
within this time duration causes the target to retransmit the DRO Various fields inside the P2P-RDO MUST be set as specified in
message. The target MAY retransmit the DRO message in this fashion Section 8.2. The target MAY set the A flag inside the DRO message if
up to MAX_DRO_RETRANSMISSIONS times. The values of DRO_ACK_WAIT_TIME it desires the origin to send back a DRO-ACK message on receiving the
and MAX_DRO_RETRANSMISSIONS are defined in Section 12. DRO. In this case, the target waits for DRO_ACK_WAIT_TIME duration
for the DRO-ACK message to arrive. Failure to receive the DRO-ACK
message within this time duration causes the target to retransmit the
DRO message. The target MAY retransmit the DRO message in this
fashion up to MAX_DRO_RETRANSMISSIONS times. The values of
DRO_ACK_WAIT_TIME and MAX_DRO_RETRANSMISSIONS are defined in
Section 12.
The target MAY set the stop flag inside the DRO message if
o this router is the only target specified in the corresponding DIO,
i.e., the corresponding DIO specified a unicast address of the
router as the Target inside the P2P-RDO with no additional targets
specified via RPL Target Options; and
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 DRO message.
This Metric Container contains the end-to-end routing metric values This Metric Container contains the end-to-end routing metric values
for the route specified in the P2P-RDO. The target MAY set the stop for the route specified in the P2P-RDO. The target MAY include one
flag inside the DRO message (and detach from the temporary DAG) if it or more Data Options in the DRO message to carry time-critical
has already selected the desired number of routes. A target MUST NOT application data for the origin. The target MUST transmit the DRO
forward a P2P mode DIO any further. message via a link-local multicast.
A target MUST NOT forward a P2P mode DIO any further.
9.6. Processing a DRO At An Intermediate Router 9.6. Processing a DRO At An Intermediate Router
When a router receives a DRO message that does not list its IPv6 When a router receives a DRO message that does not list its IPv6
address in the DODAGID field, the router MUST process the received address in the DODAGID field, the router MUST process the received
message in the following manner: message in the following manner:
o If the stop flag inside the received DRO is set and the router o If the stop flag inside the received DRO is set, the router SHOULD
currently belongs to the temporary DAG identified by the NOT send or receive any more DIOs for this temporary DAG and
(RPLInstanceID, DODAGID and Version fields of the) DRO, the router SHOULD cancel any pending DIO transmission.
SHOULD cancel any pending DIO transmissions for this temporary
DAG. Additionally, the router MAY detach from the temporary DAG
immediately.
o An intermediate router MUST ignore any Metric Container Option o An intermediate router MUST ignore any Metric Container and Data
contained in the DRO message. Options contained in the DRO message.
o If Address[NH] element inside the Route Discovery Option lists the o If Address[NH] element inside the Route Discovery Option lists the
router's own IPv6 address, the router is a part of the route router's own IPv6 address, the router is a part of the route
carried in the P2P-RDO. In this case, the router MUST do the carried in the P2P-RDO. In this case, the router MUST do the
following: following:
* If the H flag inside the P2P-RDO inside the DRO message is set, * If the H flag inside the P2P-RDO is 0 (i.e., the P2P-RDO is
the router SHOULD store the state for the forward hop-by-hop carrying a source route), the router MAY make a note of the
route carried inside the P2P-RDO. This state consists of: RPLInstanceID and the DODAGID values listed in the DRO. The
router may need this information to forward a packet traveling
along the discovered source route using a Source Routing Header
(SRH) [I-D.ietf-6man-rpl-routing-header] (see Section 11 for
details).
* If the H flag inside the P2P-RDO is 1, the router MUST store
the state for the forward hop-by-hop route carried inside the
P2P-RDO. This state consists of:
+ The RPLInstanceID and the DODAGID fields of the DRO. + The RPLInstanceID and the DODAGID fields of the DRO.
+ The route's destination, the target (identified by Target + The route's destination, the target (identified by Target
field in P2P-RDO). 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).
The router MUST drop the DRO message with no further processing
if the H flag inside the P2P-RDO is set but the router chooses
not to store the state for the hop-by-hop route.
* 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 DRO and the next hop information
in the state does not match the next hop indicated in the in the state does not match the next hop indicated in the
received DRO, the router MUST drop the DRO message with no received DRO, the router MUST drop the DRO message with no
further processing. further processing.
* 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 further via link-local multicast. send the DRO further via link-local multicast.
9.7. Processing a DRO At The Origin 9.7. Processing a DRO At The Origin
When a router receives a DRO message that lists its IPv6 address in When a router receives a DRO message that lists its IPv6 address in
the DODAGID field, the router recognizes itself as the origin for the the DODAGID field, the router recognizes itself as the origin for the
corresponding P2P-RPL route discovery and processes the P2P-RDO corresponding P2P-RPL route discovery and processes the message in
contained in the DRO in the following manner. the following manner.
If the stop flag inside the received DRO is set and the origin still The origin MUST deliver data in any Data Options in the received DRO
belongs to the temporary DAG it initiated, it SHOULD cancel any to the application layer.
pending DIO transmissions for this temporary DAG. Additionally, the
origin MAY detach from the temporary DAG immediately. If the stop flag inside the received DRO is set, the origin SHOULD
NOT generate any more DIOs for this temporary DAG and SHOULD cancel
any pending DIO transmission.
If the P2P-RDO inside the DRO identifies the discovered route as a If the P2P-RDO inside the DRO identifies the discovered route as a
source route (H=0), the origin SHOULD store in its memory the source route (H=0), the origin MUST store in its memory the
discovered route contained in the Address vector. discovered route contained in the Address vector.
If the P2P-RDO inside the DRO identifies the discovered route as a If the P2P-RDO inside the DRO identifies the discovered route as a
hop-by-hop route (H=1), the origin SHOULD store in its memory the hop-by-hop route (H=1), the origin MUST store in its memory the state
state for the discovered route in the manner described in for the discovered route in the manner described in Section 9.6.
Section 9.6.
If the received DRO message contains a Metric Container Option as If the received DRO message contains one or more Metric Container
well, the origin MAY store the values of the routing metrics Options, the origin MAY store the values of the routing metrics
associated with the discovered route in its memory. This information associated with the discovered route in its memory. This information
may be useful in formulating the constraints for any future P2P-RPL may be useful in formulating the constraints for any future P2P-RPL
route discovery to the target. route discovery to the target.
If the A flag is set to one in the received DRO message, the origin If the A flag is set to one in the received DRO message, the origin
SHOULD generate a DRO-ACK message as described in Section 10 and MUST generate a DRO-ACK message as described in Section 10 and
unicast the message to the target. The origin MAY source route the unicast the message to the target (identified by the Target field
DRO-ACK message to the target using the route contained in the inside the P2P-RDO). The origin MAY use the route just discovered to
received DRO. If the received DRO established a hop-by-hop route to send the DRO-ACK message to the target. Section 11 describes how a
the target, the origin MAY send the DRO-ACK message along this route. packet may be forwarded along a source/hop-by-hop route discovered
Section 11 describes how a packet may be forwarded along a route using P2P-RPL.
discovered using P2P-RPL.
10. The Discovery Reply Object Acknowledgement (DRO-ACK) 10. The Discovery Reply Object Acknowledgement (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 3: Format of the base Discovery Reply Object Acknowledgement Figure 4: Format of the base Discovery Reply Object Acknowledgement
(DRO-ACK) (DRO-ACK)
A DRO message may fail to reach the origin due to a number of A 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 DRO messages are prone to loss due to
reasons associated with wireless communication. Since a DRO message unreliable wireless communication. Since a DRO message travels via
travels via link-local multicast, it cannot use link-level link-local multicast, it cannot use link-level acknowledgements to
acknowledgements to improve the reliability of its transmission. improve the reliability of its transmission. Also, an intermediate
Also, an intermediate router may drop the DRO message (e.g., because router may drop the DRO message (e.g., because of its inability to
of its inability to store the state for the hop-by-hop route the DRO store the state for the hop-by-hop route the DRO is establishing).
is establishing). To protect against the potential failure of a DRO To protect against the potential failure of a DRO message to reach
message to reach the origin, the target MAY request the origin to the origin, the target MAY request the origin to send back a DRO
send back a DRO Acknowledgement (DRO-ACK) message on receiving a DRO Acknowledgement (DRO-ACK) message on receiving a DRO message.
message. Failure to receive such an acknowledgement within the Failure to receive such an acknowledgement within the
DRO_ACK_WAIT_TIME interval of sending the DRO message forces the DRO_ACK_WAIT_TIME interval of sending the DRO message forces the
target to resend the message. target to resend the message.
This section defines two new RPL Control Message types: DRO This section defines two new RPL Control Message types: DRO
Acknowledgement (DRO-ACK; with code 0x05; to be confirmed by IANA) Acknowledgement (DRO-ACK; with code 0x05; to be confirmed by IANA)
and Secure DRO-ACK (with code 0x85; to be confirmed by IANA). A DRO- and Secure DRO-ACK (with code 0x85; to be confirmed by IANA). A DRO-
ACK message MUST travel as a unicast message from the origin to the ACK message MUST travel as a unicast message from the origin to the
target. The format of a base DRO-ACK message is shown in Figure 3. target. The format of a base DRO-ACK message is shown in Figure 4.
Various fields in a DRO-ACK message MUST have the same values as the Various fields in a DRO-ACK message MUST have the same values as the
corresponding fields in the DRO message. The field marked as corresponding fields in the DRO message. The field marked as
"Reserved" MUST be set to zero on transmission and MUST be ignored on "Reserved" MUST be set to zero on transmission and MUST be ignored on
reception. A Secure DRO-ACK message follows the format in Figure 7 reception. A Secure DRO-ACK message follows the format in Figure 7
of [I-D.ietf-roll-rpl], where the base format is same as the base of [I-D.ietf-roll-rpl], where the base format is same as the base
DRO-ACK shown in Figure 3. DRO-ACK shown in Figure 4.
11. Packet Forwarding Along a P2P-RPL Route 11. Packet Forwarding Along a Route Discovered Using P2P-RPL
This document specifies a mechanism to discover P2P routes, which can An origin MAY use a Source Routing Header (SRH)
be either source routes or hop-by-hop ones. A packet MAY use an SRH [I-D.ietf-6man-rpl-routing-header] to send a packet along a source
header [I-D.ietf-6man-rpl-routing-header] to travel along a source route discovered using P2P-RPL. For this purpose, the origin MUST
route discovered using P2P-RPL. Travel along a hop-by-hop route, set the DODAGID of the temporary DAG used for the source route
established using P2P-RPL, requires specifying the RPLInstanceID and discovery as the source IPv6 address of the packet. Further, the
the DODAGID to identify the route. This is because P2P-RPL route origin MUST specify inside the SRH the RPLInstanceID of the temporary
discovery does not use globally unique RPLInstanceID values and hence DAG used for the source route discovery. An intermediate router
both the RPLInstanceID, which is a local value assigned by the verifies being on the source route (it must have noted the
origin, and the DODAGID, which is an IPv6 address belonging to the RPLInstanceID and DODAGID before forwarding the DRO message, carrying
origin, are required to uniquely identify a P2P-RPL hop-by-hop route the source route, towards the origin) before forwarding the packet
to a particular destination. A packet MAY include an RPL option further.
[I-D.ietf-6man-rpl-option] inside the IPv6 hop-by-hop options header
to travel along a hop-by-hop route established using P2P-RPL. In Travel along a hop-by-hop route, established using P2P-RPL, requires
this case, the origin MUST set the DODAGID of the P2P-RPL route as specifying the RPLInstanceID and the DODAGID (of the temporary DAG
the source IPv6 address of the packet. Further, the origin MUST used for the route discovery) to identify the route. This is because
specify the RPLInstanceID, associated with the P2P-RPL route, inside P2P-RPL route discovery does not use globally unique RPLInstanceID
the RPL option and set the O flag inside the RPL option to 1. A values and hence both the RPLInstanceID, a local value assigned by
router receiving this packet will check the O flag inside the RPL the origin, and the DODAGID, an IPv6 address of the origin, are
option and correctly infer the source IPv6 address of the packet as required to uniquely identify a P2P-RPL hop-by-hop route to a
the DODAGID of the hop-by-hop route to be used for forwarding the particular destination.
packet further.
An origin MAY include an RPL option [I-D.ietf-6man-rpl-option] inside
the IPv6 hop-by-hop 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 DODAGID of the temporary DAG used for the route
discovery as the source IPv6 address of the packet. Further, the
origin MUST specify 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 1. On receiving this packet, an intermediate
router checks the O flag 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, the RPLInstanceID and the destination address
to identify the routing state to be used to forward the packet
further.
12. Constants 12. Constants
This document defines the following constants: This document defines the following constants:
o DRO_ACK_WAIT_TIME: The time duration a target waits for the DRO- o DRO_ACK_WAIT_TIME: The time duration a target waits for the DRO-
ACK before retransmitting a DRO message. DRO_ACK_WAIT_TIME has a ACK before retransmitting a DRO message. DRO_ACK_WAIT_TIME has a
value of 1 second. value of 1 second.
o MAX_DRO_RETRANSMISSIONS: The maximum number of times a DRO message o MAX_DRO_RETRANSMISSIONS: The maximum number of times a DRO message
may be retransmitted if the target does not receive a DRO-ACK in may be retransmitted if the target does not receive a DRO-ACK in
response. MAX_DRO_RETRANSMISSIONS has a value 2. response. MAX_DRO_RETRANSMISSIONS has a value 2.
13. 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,
such RPL-only leaf nodes do not interfere with P2P-RPL route such RPL-only leaf nodes do not interfere with P2P-RPL route
discovery since a leaf node may only generate a DIO advertising an discovery since a leaf node may only generate a DIO advertising an
INFINITE_RANK and all routers implementing P2P-RPL are required to INFINITE_RANK and all routers implementing P2P-RPL are required to
discard such DIOs. discard such DIOs. Note that core RPL does not require a router to
join a DAG whose MOP it does not understand. Moreover, RPL routers
Note that core RPL does not require a router to join a DAG whose MOP in a particular deployment may have strict restrictions on the DAGs
it does not understand. Moreover, RPL routers would, in practice, they may join, thereby mitigating the problem.
have strict restrictions on the DAGs that may join. Thus, the
problem described in the preceding paragraph may not occur in
practice.
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.
14. Security Considerations 14. Security Considerations
The security considerations for the operation of the reactive P2P The security considerations for the operation of P2P-RPL are similar
route discovery mechanism described in this document are similar to to the ones for the operation of RPL (as described in Section 19 of
the ones for the operation of RPL (as described in Section 19 of
[I-D.ietf-roll-rpl]). Section 10 of RPL specification [I-D.ietf-roll-rpl]). Section 10 of RPL specification
[I-D.ietf-roll-rpl] describes a variety of security mechanisms that
[I-D.ietf-roll-rpl] describes a variety of security mechanisms to
provide data confidentiality, authentication, replay protection and provide data confidentiality, authentication, replay protection and
delay protection services. Each RPL control message has a secure delay protection services. Each RPL control message has a secure
version that allows the specification of the level of security and version that allows the specification of the level of security and
the algorithms used to secure the message. The mechanism defined in the algorithms used to secure the message. The mechanism defined in
this document is based on the use of DIOs to form temporary DAGs and this document is based on the use of DIOs to form a temporary DAG and
discover P2P routes. These DIOs can be used in their secure versions discover P2P routes. These DIOs can be used in their secure versions
if desired. New RPL control messages defined in this document (DRO if desired. New RPL control messages defined in this document (DRO
and DRO-ACK) have secure versions as well. Thus, a particular and DRO-ACK) have secure versions as well. Thus, a particular P2P-
deployment of the reactive P2P route discovery mechanism described in RPL deployment can analyze its security requirements and use the
this document can analyze its security requirements and use the
appropriate set of RPL security mechanisms that meet those appropriate set of RPL security mechanisms that meet those
requirements. requirements.
15. IANA Considerations 15. IANA Considerations
15.1. Additions to DIO Mode of Operation 15.1. Additions to DIO Mode of Operation
IANA is requested to allocate a new value in the "DIO Mode of IANA is requested to allocate a new value in the "DIO Mode of
Operation" registry for the "P2P Route Discovery Mode" described in Operation" registry for the "P2P Route Discovery Mode" described in
this document. this document.
skipping to change at page 24, line 39 skipping to change at page 27, line 25
| Value | | | | Value | | |
+----------+-----------------------------------------+--------------+ +----------+-----------------------------------------+--------------+
| 4 | Reactive P2P route discovery mode of | This | | 4 | Reactive P2P route discovery mode of | This |
| | operation | document | | | operation | document |
+----------+-----------------------------------------+--------------+ +----------+-----------------------------------------+--------------+
DIO Mode of Operation DIO Mode of Operation
15.2. Additions to RPL Control Message Options 15.2. Additions to RPL Control Message Options
IANA is requested to allocate a new value in the "RPL Control Message IANA is requested to allocate new values in the "RPL Control Message
Options" registry for the "Route Discovery Option" described in this Options" registry for the "P2P Route Discovery Option" and the "Data
document. Option" described in this document.
+-------+---------------------+---------------+ +-------+---------------------+---------------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+-------+---------------------+---------------+ +-------+---------------------+---------------+
| 10 | P2P Route Discovery | This document | | 10 | P2P Route Discovery | This document |
| 11 | Data | This document |
+-------+---------------------+---------------+ +-------+---------------------+---------------+
RPL Control Message Options RPL Control Message Options
15.3. Additions to RPL Control Codes 15.3. Additions to RPL Control Codes
IANA is requested to allocate new code points in the "RPL Control IANA is requested to allocate new code points in the "RPL Control
Codes" registry for the "Discovery Reply Object" and "Discovery Reply Codes" registry for the "Discovery Reply Object" and "Discovery Reply
Object Acknowledgement" (and their secure versions) described in this Object Acknowledgement" (and their secure versions) described in this
document. document.
skipping to change at page 25, line 37 skipping to change at page 28, line 30
individuals (in alphabetical order) in the development of this individuals (in alphabetical order) in the development of this
document: Dominique Barthel, Jakob Buron, Thomas Clausen, Richard document: Dominique Barthel, Jakob Buron, Thomas Clausen, Richard
Kelsey, Phil Levis, Zach Shelby, Pascal Thubert, Hristo Valev and JP Kelsey, Phil Levis, Zach Shelby, Pascal Thubert, Hristo Valev and JP
Vasseur. Vasseur.
17. References 17. References
17.1. Normative References 17.1. Normative References
[I-D.ietf-roll-routing-metrics] [I-D.ietf-roll-routing-metrics]
Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. Barthel, D., Vasseur, J., Pister, K., Kim, M., and N.
Barthel, "Routing Metrics used for Path Calculation in Low Dejean, "Routing Metrics used for Path Calculation in Low
Power and Lossy Networks", Power and Lossy Networks",
draft-ietf-roll-routing-metrics-19 (work in progress), draft-ietf-roll-routing-metrics-19 (work in progress),
March 2011. March 2011.
[I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl]
Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P.,
Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Levis, P., Struik, R., Kelsey, R., Clausen, T., and T.
Vasseur, "RPL: IPv6 Routing Protocol for Low power and Winter, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-19 (work in Lossy Networks", draft-ietf-roll-rpl-19 (work in
progress), March 2011. progress), March 2011.
[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.
[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.
17.2. Informative References 17.2. Informative References
[I-D.ietf-6man-rpl-option] [I-D.ietf-6man-rpl-option]
Hui, J. and J. Vasseur, "RPL Option for Carrying RPL Hui, J. and J. Vasseur, "RPL Option for Carrying RPL
Information in Data-Plane Datagrams", Information in Data-Plane Datagrams",
draft-ietf-6man-rpl-option-06 (work in progress), draft-ietf-6man-rpl-option-06 (work in progress),
December 2011. December 2011.
[I-D.ietf-6man-rpl-routing-header] [I-D.ietf-6man-rpl-routing-header]
Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6 Culler, D., Hui, J., Vasseur, J., and V. Manral, "An IPv6
Routing Header for Source Routes with RPL", Routing Header for Source Routes with RPL",
draft-ietf-6man-rpl-routing-header-07 (work in progress), draft-ietf-6man-rpl-routing-header-07 (work in progress),
December 2011. December 2011.
[I-D.ietf-roll-of0] [I-D.ietf-roll-of0]
Thubert, P., "RPL Objective Function Zero", Thubert, P., "RPL Objective Function Zero",
draft-ietf-roll-of0-20 (work in progress), September 2011. draft-ietf-roll-of0-20 (work in progress), September 2011.
[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
 End of changes. 108 change blocks. 
433 lines changed or deleted 552 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/