draft-ietf-roll-p2p-rpl-09.txt   draft-ietf-roll-p2p-rpl-10.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: September 7, 2012 E. Baccelli Expires: November 6, 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
March 6, 2012 May 5, 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-09 draft-ietf-roll-p2p-rpl-10
Abstract Abstract
This document specifies a point-to-point route discovery mechanism, This document specifies a point-to-point route discovery mechanism,
complementary to the RPL core functionality. This mechanism allows complementary to the RPL core functionality. This mechanism allows
an IPv6 router to discover "on demand" routes to one or more IPv6 an IPv6 router to discover "on demand" routes to one or more IPv6
routers in the LLN such that the discovered routes meets specified routers in the LLN such that the discovered routes meet specified
metrics constraints. metrics constraints.
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 September 7, 2012. This Internet-Draft will expire on November 6, 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 19 skipping to change at page 2, line 19
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. 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 . . . . . . . . . . . . . . . . . . . . . 6
6. P2P Route Discovery Mode Of Operation . . . . . . . . . . . . 8 6. P2P Route Discovery Mode Of Operation . . . . . . . . . . . . 9
6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . . 8 6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . . 9
7. New RPL Control Message Options . . . . . . . . . . . . . . . 11 7. New RPL Control Message Options . . . . . . . . . . . . . . . 11
7.1. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . 11 7.1. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . 12
7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 15
8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 14 8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 15
8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Setting a P2P-RDO Carried in a Discovery Reply Object . . 16 8.2. Setting a P2P-RDO Carried in a Discovery Reply Object . . 18
9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 17 9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 18
9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 17 9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 18
9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 18 9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 19
9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 19 9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 20
9.4. Additional Processing of a P2P Mode DIO At An 9.4. Additional Processing of a P2P Mode DIO At An
Intermediate Router . . . . . . . . . . . . . . . . . . . 20 Intermediate Router . . . . . . . . . . . . . . . . . . . 21
9.5. Additional Processing of a P2P Mode DIO At The Target . . 21 9.5. Additional Processing of a P2P Mode DIO At The Target . . 22
9.6. Processing a DRO At An Intermediate Router . . . . . . . . 22 9.6. Processing a DRO At An Intermediate Router . . . . . . . . 24
9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 23 9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 25
10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 24 10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 26
11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 24 11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 27
12. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 28
13. Interoperability with Core RPL . . . . . . . . . . . . . . . . 25 13. Security Considerations . . . . . . . . . . . . . . . . . . . 28
14. Security Considerations . . . . . . . . . . . . . . . . . . . 26 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 14.1. Additions to DIO Mode of Operation . . . . . . . . . . . . 29
15.1. Additions to DIO Mode of Operation . . . . . . . . . . . . 26 14.2. Additions to RPL Control Message Options . . . . . . . . . 29
15.2. Additions to RPL Control Message Options . . . . . . . . . 27 14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 30
15.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 27 14.4. New Registry for Upper Layer Headers inside Data Option . 30
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
17.1. Normative References . . . . . . . . . . . . . . . . . . . 28 16.1. Normative References . . . . . . . . . . . . . . . . . . . 31
17.2. Informative References . . . . . . . . . . . . . . . . . . 28 16.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
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 [RFC6550] provides paths along a Directed Acyclic Graph
Graph (DAG) rooted at a single router in the network. Establishment (DAG) rooted at a single router in the network. Establishment and
and maintenance of a DAG is performed by routers in the LLN using maintenance of a DAG is performed by routers in the LLN using DODAG
DODAG Information Object (DIO) messages. When two arbitrary routers Information Object (DIO) messages. When two arbitrary routers
(neither of which is the DAG's root) need to communicate, the data (neither of which is the DAG's root) need to communicate, the data
packets are restricted to travel only along the links in the DAG. packets are restricted to travel only along the links in the DAG.
Such point-to-point (P2P) routing functionality may not be sufficient Such point-to-point (P2P) routing functionality may not be sufficient
for several Home and Building Automation applications [RFC5826] for several Home and Building Automation applications [RFC5826]
[RFC5867] due to the following reasons: [RFC5867] due to the following reasons:
o The need to pre-establish routes: each potential destination in o The need to pre-establish routes: each potential destination in
the network must declare itself as such ahead of the time a source the network must declare itself as such ahead of the time a source
needs to reach it. needs to reach it.
skipping to change at page 3, line 34 skipping to change at page 3, line 34
routes to use only the in-DAG links may result in significantly routes to use only the in-DAG links may result in significantly
suboptimal routes and severe traffic congestion near the DAG root. suboptimal routes and severe traffic congestion near the DAG root.
This document describes an extension to core RPL that enables an IPv6 This document describes an extension to core RPL that enables an IPv6
router in the LLN to discover routes to one or more IPv6 routers in router in the LLN to discover routes to one or more IPv6 routers in
the LLN "on demand", such that the discovered routes meet the the LLN "on demand", such that the discovered routes meet the
specified metrics constraints, without necessarily going along the specified metrics constraints, without necessarily going along the
links in an existing DAG. This reactive P2P route discovery links in an existing DAG. This reactive P2P route discovery
mechanism is henceforth referred to as P2P-RPL. P2P-RPL does not mechanism is henceforth referred to as P2P-RPL. P2P-RPL does not
guarantee discovery of a route. Also, the discovered routes may not guarantee discovery of a route. Also, the discovered routes may not
be the best available. However, any discovered routes are guaranteed be optimal. However, any discovered routes are guaranteed to satisfy
to satisfy the desired constraints in terms of the routing metrics the desired constraints in terms of the routing metrics and are thus
and are thus considered "good enough" from the application's considered "good enough" from the application's perspective.
perspective.
A mechanism to measure the end-to-end cost of an existing route has A mechanism to measure the end-to-end cost of an existing route is
been specified in [I-D.ietf-roll-p2p-measurement]. As discussed in specified in [I-D.ietf-roll-p2p-measurement]. As discussed in
Section 4, measuring the end-to-end cost of an existing route may Section 4, measuring the end-to-end cost of an existing route may
help decide whether to initiate the discovery of a better route using help decide whether to initiate the discovery of a better route using
P2P-RPL and the metric constraints to be used for this purpose. P2P-RPL and the metric constraints to be used for this purpose.
2. The Use Cases 2. The Use Cases
One use case, common in home and commercial building environments, One use case, common in home and commercial building environments,
involves a device (say a remote control or an airduct controller) involves a device (say a remote control or an airduct controller)
that suddenly needs to communicate with another device (say a lamp or that suddenly needs to communicate with another device (say a lamp or
a humidity sensor) to which it does not already have a route. In a humidity sensor) to which it does not already have a route. In
skipping to change at page 4, line 25 skipping to change at page 4, line 24
they involve traversing many more intermediate routers than necessary they involve traversing many more intermediate routers than necessary
to reach the destination. to reach the destination.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
Additionally, this document uses terminology from Additionally, this document uses terminology from [RFC6550]. This
[I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. This document document introduces the following terms:
introduces the following terms:
Origin : The IPv6 router initiating the P2P-RPL route discovery. Origin : The IPv6 router initiating the P2P-RPL route discovery.
Target : The IPv6 router at the other end point of the P2P route(s) Target : The IPv6 router at the other end point of the P2P route(s)
to be discovered. A P2P-RPL route discovery can discover routes to to be discovered. A P2P-RPL route discovery can discover routes to
multiple targets at the same time. multiple Targets at the same time.
Intermediate Router: An IPv6 router that is neither the origin nor a Intermediate Router: An IPv6 router that is neither the Origin nor a
target. Target.
Forward Route: A route in the forward direction, i.e., from the Forward direction: The direction from the Origin to the Target.
origin to the target.
Backward Route: A route in the backward direction, i.e., from the Backward direction: The direction from the Target to the Origin.
target to the origin.
Bidirectional Route: A route that can be used in both forward and Forward Route: A route in the Forward direction.
backward directions.
Backward Route: A route in the Backward direction.
Bidirectional Route: A route that can be used in both Forward and
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(s) or when the existing route exists between itself and the Target(s) or when the existing
routes do not satisfy the application requirements. P2P-RPL is routes do not satisfy the application requirements. P2P-RPL is
designed to discover hop-by-hop or source routes to one or more designed to discover Hop-by-hop or Source Routes to one or more
targets such that the discovered routes meet the specified Targets such that the discovered routes meet the specified
constraints. In some application contexts, the constraints that the constraints. In some application contexts, the constraints that the
discovered routes must satisfy are intrinsically known or can be discovered routes must satisfy are intrinsically known or can be
specified by the application. For example, an origin that expects specified by the application. For example, an Origin that expects
its targets to be less than 5 hops away may use "hop-count < 5" as its Targets to be less than 5 hops away may use "hop-count < 5" as
the constraint. In other application contexts, the origin may need the constraint. In other application contexts, the Origin may need
to measure the cost of the existing route to a target to determine to measure the cost of the existing route to a Target to determine
the constraints. For example, an origin that measures the total ETX the constraints. For example, an Origin that measures the total ETX
along its current route to a target to be 20 may use "ETX < x*20", along its current route to a Target to be 20 may use "ETX < x*20",
where x is a fraction that the origin decides, as the constraint. A where x is a fraction that the Origin decides, as the constraint. A
mechanism to measure the cost of an existing route between two IPv6 mechanism to measure the cost of an existing route between two IPv6
routers is specified in [I-D.ietf-roll-p2p-measurement]. If there is routers is specified in [I-D.ietf-roll-p2p-measurement]. If there is
no existing route between the origin and the target(s) or the cost no existing route between the Origin and the Target(s) or the cost
measurement for the existing routes fails, the origin will have to measurement for the existing routes fails, the Origin will have to
guess the constraints to be used in the initial route discovery. guess the constraints to be used in the initial route discovery.
Once, the initial route discovery succeeds or fails, the origin will Once, the initial route discovery succeeds or fails, the Origin will
have a better estimate for the constraints to be used in the have a better estimate 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 global DAG designed to optimize routing cost to the
root. The improvement in route quality depends on a number of DAG's 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 "distance" between the
and the prevalent conditions in the network. A network designer may Origin and the Target (in terms of the routing metrics in use) and
take into consideration both the benefits (potentially better routes; the prevalent conditions in the network. In general, a P2P-RPL route
no need to maintain routes proactively) and costs (control messages may be better than the one along a global DAG if the Origin and the
generated during the route discovery process) when using P2P-RPL. Target are nearby. Similarly, a P2P-RPL route may not be much better
than the one along a global DAG if the Origin and the Target are far
apart. Note that, even when P2P-RPL routes are not much better than
those along a global DAG, P2P-RPL routes may still be able to avoid
congestion that might occur near the root if the routing takes place
only along a global DAG. In general, the costs associated with a
P2P-RPL route discovery (in terms of the control messages, mostly
DIOs, generated) increases with the distance between the Origin and
the Target. However, it is possible to limit the cost of route
discovery by carefully setting the routing constraints, the Trickle
parameters (that govern the DIO generation) and the lifetime of the
temporary DAG created for the route discovery. A network designer
may take into consideration both the benefits (potentially better
routes; no need to maintain routes proactively; avoid congestion near
the global DAG's root) and costs when using P2P-RPL. The latency
associated with a P2P-RPL route discovery again depends on the
distance between the Origin and the Target and the Trickle
parameters.
Note that the participation in a P2P-RPL route discovery is limited
to the routers with IPv6 addresses that are reachable in both Forward
and Backward directions.
5. Functional Overview 5. Functional Overview
This section contains a high level description of P2P-RPL. This section contains a high level description of P2P-RPL.
A P2P-RPL route discovery takes place by forming a DAG rooted at the A P2P-RPL route discovery takes place by forming a DAG rooted at the
origin. As is the case with core RPL, P2P-RPL uses IPv6 link-local Origin. As is the case with core RPL, P2P-RPL uses IPv6 link-local
multicast DIO messages to establish a DAG. However, unlike core RPL, multicast DIO messages to establish a DAG. However, unlike core RPL,
this DAG is temporary in nature and routers in the DAG leave once the this DAG is temporary in nature and routers in the DAG leave once the
DAG's life time is over. The sole purpose of DAG creation is to DAG's life time is over. The sole purpose of DAG creation is to
discover routes to the target(s) and DIOs serve as the route discover routes to the Target(s) and DIOs serve as the route
discovery messages. Each router joining the DAG determines a rank discovery messages. Each router joining the DAG determines a rank
for itself in the DAG and ignores the subsequent DIOs received from for itself in the DAG and ignores the subsequent DIOs received from
lower (higher in numerical value) ranked neighbors. Thus, the route lower (higher in numerical value) ranked neighbors. Thus, the route
discovery messages propagate away from the origin rather than return discovery messages propagate away from the Origin rather than return
back to it. As in core RPL, DIO generation at a router is controlled back to it. As in core RPL, DIO generation at a router is controlled
by a Trickle timer [RFC6206] that allows a router to avoid generating by a Trickle timer [RFC6206] that allows a router to avoid generating
unnecessary messages while providing protection against unreliable unnecessary messages while providing protection against packet loss.
wireless communication. P2P-RPL also uses the routing metrics P2P-RPL also uses the routing metrics [RFC6551], objective functions
[I-D.ietf-roll-routing-metrics], objective functions and packet and packet forwarding framework [RFC6554][RFC6553] developed for core
forwarding framework RPL.
[I-D.ietf-6man-rpl-routing-header][I-D.ietf-6man-rpl-option]
developed for core RPL.
An origin may use P2P-RPL to discover routes to one or more targets An Origin may use P2P-RPL to discover routes to one or more Targets
identified by one or more unicast/multicast addresses. P2P-RPL identified by one or more unicast/multicast addresses. P2P-RPL
allows for the discovery of one hop-by-hop route or upto four source allows for the discovery of one Hop-by-hop Route or up to four Source
routes per target. P2P-RPL allows an origin to piggyback time- Routes per Target. P2P-RPL allows an Origin to piggyback time-
critical application data on the DIO messages for delivery to the 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(s). P2P-RPL does not guarantee discovery of a route to a
target. Also, the discovered routes may not be the best available. Target. Also, the discovered routes may not be the best available.
However, any discovered routes are guaranteed to satisfy the desired However, any discovered routes are guaranteed to satisfy the desired
constraints in terms of the routing metrics and are thus considered constraints in terms of the routing metrics and are thus considered
"good enough" from the application's perspective. "good enough" from the application's perspective.
A P2P-RPL route discovery takes place by forming a temporary DAG 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). The DIOs, listing the P2P Route Discovery defined in Section 6). The DIOs, listing the P2P Route Discovery
mode as the Mode of Operation, are henceforth referred to as the P2P mode as the Mode of Operation, are henceforth referred to as the P2P
mode DIOs. A P2P mode DIO always carries one P2P Route Discovery mode DIOs. A P2P mode DIO always carries one P2P Route Discovery
Option (defined in Section 7.1) in which the origin specifies the Option (defined in Section 7.1) in which the Origin specifies the
following information: following information:
o The IPv6 address of a target. This could be a unicast address or o The IPv6 address of a Target. This could be a unicast address or
a multicast one. Any additional targets may be specified by a multicast one. Any additional Targets may be specified by
including one or more RPL Target Options [I-D.ietf-roll-rpl] including one or more RPL Target Options [RFC6550] inside the DIO.
inside the DIO.
o The nature of the route(s) to be discovered: hop-by-hop or source o The nature of the route(s) to be discovered: hop-by-hop or Source
routes. This specification allows for the discovery of one hop- Routes. This specification allows for the discovery of one Hop-
by-hop route or up to four source routes per target. by-hop Route or up to four Source Routes per Target.
o The desired number of routes (if source routes are being o The desired number of routes (if Source Routes are being
discovered). discovered).
o Whether the target(s) should send Discovery Reply Object (DRO) o Whether the Target(s) should send Discovery Reply Object (DRO)
messages (defined in Section 8) back to the origin on receiving a messages (defined in Section 8) back to the Origin on receiving a
DIO message. A DRO message carries a discovered source route back DIO message. A DRO message carries a discovered Source Route back
to the origin or establishes a hop-by-hop route between the origin to the Origin or establishes a Hop-by-hop Route between the Origin
and the target. By not allowing the generation of DRO messages, and the Target. By not allowing the generation of DRO messages,
an origin can use P2P-RPL as purely a mechanism to deliver time- an Origin can use P2P-RPL as purely a mechanism to deliver time-
critical application data to the target(s). critical application data to the Target(s).
A P2P Route Discovery Option also accumulates a route from the origin A P2P Route Discovery Option also accumulates a route from the Origin
to a target as the routers join the temporary DAG. to a Target as the routers join the temporary DAG.
A P2P mode DIO MAY also carry: A P2P mode DIO MAY also carry:
o One or more Metric Container Options to specify: o One or more Metric Container Options to specify:
* The relevant routing metrics. * The relevant routing metrics.
* The constraints that the discovered route must satisfy. These * The constraints that the discovered route must satisfy. These
constraints also limit how far the DIOs message may travel. constraints also limit how far the DIOs message may travel.
o One or more RPL Target options to specify additional unicast or o One or more RPL Target options to specify additional unicast or
multicast targets. multicast Targets.
o One or more Data Options (defined in Section 7.2) to carry time- o One Data Option (defined in Section 7.2) to carry time-critical
critical application-level data to be delivered to the target(s). 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. A with the corresponding routing metrics, in their P2P mode DIOs. A
router, including the target(s), discards a received P2P mode DIO if router, including the Target(s), discards a received P2P mode DIO if
the aggregated routing metrics on the route advertised by the DIO do the aggregated routing metrics on the route advertised by the DIO do
not satisfy the listed constraints. These constraints can be used to not satisfy the listed constraints. These constraints can be used to
limit the propagation of P2P mode DIO messages. A router may also limit the propagation of P2P mode DIO messages. A router may also
discard a received P2P mode DIO if it does not wish to be a part of 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 the discovered route due to limited resources or due to policy
reasons. reasons.
When a target receives a P2P mode DIO, it forwards the data in any When a Target receives a P2P mode DIO, it forwards the data in the
Data Options to the higher layer. The target may remember the Data Option, if present, to the higher layer. The Target may
discovered route for use as a source route to reach the origin. If remember the discovered route for use as a Source Route to reach the
the origin has requested DRO messages to be sent back, the target may Origin. If the Origin has requested DRO messages to be sent back,
select the route contained in the received DIO for further processing the Target may select the route contained in the received DIO for
as described next. This document does not specify a particular further processing as described next. This document does not specify
method for the target to use to select a route for further a particular method for the Target to use to select a route for
processing. Example methods include selecting any route that meets further processing. Example methods include selecting any route that
the constraints or selecting the best route(s) discovered over a meets the constraints or selecting the best route(s) discovered over
certain time period. 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 selected source routes to the origin via DRO messages with one the selected Source Routes to the Origin via DRO messages with one
DRO message carrying one discovered route. On receiving a DRO DRO message carrying one discovered route. On receiving a DRO
message, the origin stores the discovered route in its memory. If a message, the Origin stores the discovered route in its memory. If a
hop-by-hop route is being discovered, the target sends a DRO message Hop-by-hop Route is being discovered, the Target sends a DRO message
containing the selected route to the origin. The DRO message travels containing the selected route to the Origin. The DRO message travels
back to the origin along the selected route, establishing state for back to the Origin along the selected route, establishing state for
this route in the routers on the path. The target may include one or this route in the routers on the path. The Target may include a Data
more Data Options in a DRO message to deliver any time-critical Option in a DRO message to deliver any time-critical application data
application data to the origin. 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. If 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"
flag 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. The routers receiving completion of the route discovery process. The routers receiving
such a DRO should not generate any more DIOs for this temporary DAG. such a DRO should not generate any more DIOs for this temporary DAG.
Neither should they process any received 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 in future. However, such routers must still process the DROs
received for this temporary DAG. 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
skipping to change at page 8, line 46 skipping to change at page 9, line 20
identified as performing a P2P-RPL 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 and only one P2P Route temporary DAG. A P2P mode DIO MUST carry one and only one P2P Route
Discovery Option (specified in Section 7.1). 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 [RFC6550]. The Origin MUST NOT use the same
same RPLInstanceID in two or more concurrent route discoveries. RPLInstanceID in two or more concurrent route discoveries. When
initiating a new route discovery to a particular Target, the
Origin MUST NOT reuse the RPLInstanceID used in a previous route
discovery to this Target if the previously discovered routes might
still exist. The Default Lifetime and Lifetime Unit parameters in
the DODAG Configuration Option specify the lifetime of the state
the routers, including the Origin and the Target, maintain for a
hop-by-hop or a Source Route discovered using P2P-RPL. Thus, an
Origin can safely reuse an RPLInstanceID to discover a new route
to a Target if the lifetime of all previously discovered routes to
this Target using this RPLInstanceID is over.
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 set to zero since this DAG is temporary o Grounded (G) Flag: This flag MUST be set to one. Unlike a global
in nature, is created solely for the purpose of P2P-RPL route RPL instance, the concept of a floating DAG, used to provide
discovery and MUST NOT be used for packet routing. connectivity within a sub-DAG detached from a grounded DAG, does
not apply to a local RPL instance. Hence, an Origin MUST always
set the G flag to one when initiating a P2P-RPL route discovery.
Further, clause 3 of Section 8.2.2.2 in [RFC6550] does not apply
and a node MUST NOT initiate a new DAG if it does not have any
parent left in a P2P-RPL DAG.
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
Route Discovery mode. Route Discovery mode.
o DTSN: MUST be set to zero on transmission and ignored on o DTSN: MUST be set to zero on transmission and ignored on
reception. reception.
o DODAGPreference (Prf): This field MUST be set to zero (least o DODAGPreference (Prf): This field MUST be set to zero (least
preferred). preferred).
o DODAGID: This field MUST be set to an IPv6 address of the origin. o DODAGID: This field MUST be set to an IPv6 address of the Origin.
o The other fields in the DIO Base Object can be set in the desired o The other fields in the DIO Base Object can be set in the desired
fashion as per the rules described in [I-D.ietf-roll-rpl]. fashion as per the rules described in [RFC6550].
The DODAG Configuration Option, inside a P2P mode DIO MUST be set in The DODAG Configuration Option, inside a P2P mode DIO MUST be set in
the following manner: the following manner:
o MaxRankIncrease: This field MUST be set to zero to disable local o The Origin MUST set the MaxRankIncrease parameter to zero to
repair of the temporary DAG. disable local repair of the temporary DAG.
o Trickle parameters (DIOIntervalDoublings, DIOIntervalMin, o The Origin SHOULD set the Trickle parameters
DIORedundancyConstant) SHOULD be set as described in Section 9.2. (DIOIntervalDoublings, DIOIntervalMin, DIORedundancyConstant) as
recommended in Section 9.2.
o The Default Lifetime and Lifetime Unit parameters in DODAG o The Origin sets the Default Lifetime and Lifetime Unit parameters
Configuration option indicate the life time of the state the to indicate the lifetime of the state the routers, including the
routers maintain for a hop-by-hop route established using P2P-RPL Origin and the Target(s), maintain for a hop-by-hop or a Source
and may be set as desired. Route discovered using P2P-RPL.
o The other fields in the DODAG Configuration Option, including the o The Origin sets the other fields in the DODAG Configuration
OCP identifying the Objective function, can be set in the desired Option, including the OCP identifying the Objective function, in
fashion as per the rules described in [I-D.ietf-roll-rpl]. the desired fashion as per the rules described in [RFC6550].
o An Intermediate Router (or a Target) MUST set various fields in
the DODAG Configuration Option in the outgoing P2P mode DIOs to
the values they had in the incoming P2P mode DIOs for this DAG.
A default DODAG Configuration Option comes in effect if a P2P mode A default DODAG Configuration Option comes in effect if a P2P mode
DIO does not carry an explicit one. The default DODAG Configuration DIO does not carry an explicit one. The default DODAG Configuration
Option has the following parameter values: Option has the following parameter values:
o Authentication Enabled: 0 o Authentication Enabled: 0
o DIOIntervalMin: 6, which translates to 64ms as the value for Imin o DIOIntervalMin: 6, which translates to 64ms as the value for Imin
parameter in Trickle operation. parameter in Trickle operation.
o DIORedundancyConstant: 1 o DIORedundancyConstant: 1
o MaxRankIncrease: 0 o MaxRankIncrease: 0
o Default Lifetime: 0xFF o Default Lifetime: 0xFF
o Lifetime Unit: 0xFFFF o Lifetime Unit: 0xFFFF
o Objective Code Point: 0, i.e., OF0 [RFC6552] is the default
o Objective Code Point: 0, i.e., OF0 [I-D.ietf-roll-of0] is the 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]. [RFC6550].
The routing metrics and constraints [I-D.ietf-roll-routing-metrics] The routing metrics and constraints [RFC6551] used in P2P-RPL route
used in P2P-RPL route discovery are included in one or more Metric discovery are included in one or more Metric Container Options
Container Options [I-D.ietf-roll-rpl] inside the P2P mode DIO. Note [RFC6550] inside the P2P mode DIO. Note that a DIO need not include
that a DIO need not include a Metric Container if OF0 is the a Metric Container if OF0 is the objective function in effect. In
objective function in effect. In that case, a P2P mode DIO may still that case, a P2P mode DIO may still specify an upper limit on the
specify an upper limit on the maximum rank, that a router may have in maximum rank, that a router may have in the temporary DAG, inside the
the temporary DAG, inside the P2P Route Discovery Option (described P2P Route Discovery Option (described in Section 7.1).
in Section 7.1).
A P2P mode DIO: A P2P mode DIO:
o MUST carry one (and only one) P2P Route Discovery Option o MUST carry one (and only one) P2P Route Discovery Option
(described in Section 7.1). The P2P Route Discovery Option allows (described in Section 7.1). The P2P Route Discovery Option allows
for the specification of one unicast or multicast address for the for the specification of one unicast or multicast address for the
target. Target.
o MAY carry one or more RPL Target Options to specify additional o MAY carry one or more RPL Target Options to specify additional
unicast/multicast addresses for the target. unicast/multicast addresses for the Target.
o MAY carry one or more Metric Container Options to specify routing o MAY carry one or more Metric Container Options to specify routing
metrics and constraints. metrics and constraints.
o MAY carry one or more Data Options (described in Section 7.2) o MAY carry one Data Option (described in Section 7.2) containing
containing time-critical application data to be delivered to the time-critical application data to be delivered to the Target(s).
target(s).
o MAY carry one or more Route Information or Prefix Information o MAY carry one or more Route Information or Prefix Information
Options (described in [I-D.ietf-roll-rpl]). Options (described in [RFC6550]).
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. New RPL Control Message Options 7. New RPL Control Message Options
This document defines two new RPL control message options: the P2P This document defines two new RPL control message options: the P2P
Route Discovery Option and the Data Option. Route Discovery Option and the Data Option.
7.1. P2P Route Discovery Option (P2P-RDO) 7.1. P2P Route Discovery Option (P2P-RDO)
skipping to change at page 11, line 42 skipping to change at page 12, line 37
in Figure 1. A P2P mode DIO and a DRO (defined in Section 8) message in Figure 1. A P2P mode DIO and a DRO (defined in Section 8) message
MUST carry one and at most one P2P-RDO. A P2P-RDO consists of the MUST carry one and at most one P2P-RDO. A P2P-RDO consists of the
following fields: 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 Reply (R): The origin sets this flag to one to allow the target(s) o Reply (R): The Origin sets this flag to one to allow the Target(s)
to send DRO messages back to the origin. If this flag is zero, a to send DRO messages back to the Origin. If this flag is zero, a
target MUST NOT generate any DRO message. Target MUST NOT generate any DRO message.
o Hop-by-hop (H): This flag is valid only if the R flag is set to o Hop-by-hop (H): This flag is valid only if the R flag is set to
one. The origin sets this flag to one if it desires hop-by-hop one. The Origin sets this flag to one if it desires Hop-by-hop
routes. The origin sets this flag to zero if it desires source Routes. The Origin sets this flag to zero if it desires Source
routes. This specification allows for the establishment of one Routes. This specification allows for the establishment of one
hop-by-hop route or up to four source routes per target. The hop- hop-by-hop route or up to four Source Routes per Target. The Hop-
by-hop route is established in the forward direction, i.e. from by-hop Route is established in the Forward direction, i.e. from
the origin to the target. This specification does not allow for the Origin to the Target. This specification does not allow for
the establishment of hop-by-hop routes in the backward direction. the establishment of Hop-by-hop Routes in the Backward direction.
o Number of Routes (N): This flag is valid only if the R flag is one o Number of Routes (N): This flag is valid only if the R flag is one
and H flag is zero, i.e. the targets are allowed to generate DRO and H flag is zero, i.e. the Targets are allowed to generate DRO
messages carrying discovered source routes back to the origin. In messages carrying discovered Source Routes back to the Origin. In
this case, the value in the N field plus one indicates the number this case, the value in the N field plus one indicates the number
of source routes that each target should convey to the origin. of Source Routes that each Target should convey to the Origin.
When hop-by-hop routes are being discovered, the N field MUST be When Hop-by-hop Routes are being discovered, the N field MUST be
set to zero on transmission and ignored on reception. set to zero on transmission and ignored on reception.
o Compr: 4-bit unsigned integer indicating the number of prefix o Compr: 4-bit unsigned integer indicating the number of prefix
octets that are elided from the Target field and the Address octets that are elided from the Target field and the Address
vector. For example, Compr value will be zero if full IPv6 vector. For example, Compr value will be zero if full IPv6
addresses are carried in the Target field and the Address vector. addresses are carried in the Target field and the Address vector.
o Life Time (L): A 2-bit field that indicates the suggested life o Life Time (L): A 2-bit field that indicates the minimum life time
time of the temporary DAG, i.e., the suggested duration a router of the temporary DAG, i.e., the minimum duration a router joining
joining the temporary DAG SHOULD maintain its membership in the the temporary DAG MUST maintain its membership in the DAG. The
DAG. The mapping between the values in this field and the life mapping between the values in this field and the life time of the
time of the temporary DAG is as follows: temporary DAG is as follows:
* 0x00: 1 second; * 0x00: 1 second;
* 0x01: 4 seconds; * 0x01: 4 seconds;
* 0x02: 16 seconds; * 0x02: 16 seconds;
* 0x03: 64 seconds; * 0x03: 64 seconds;
The origin sets this field based on its expectation regarding the The Origin sets this field based on its expectation regarding the
time required for the DIOs to reach the target(s). time required for the route discovery to complete, which includes
the time required for the DIOs to reach the Target(s) and the DROs
to travel back to the Origin. While deciding the temporary DAG's
lifetime, the Origin should also take in account the fact that all
nodes joining the temporary DAG would need to stay in the DAG for
at least this much time.
o MaxRank/NH: o MaxRank/NH:
* When a P2P-RDO is included in a P2P mode DIO, this field * When a P2P-RDO is included in a P2P mode DIO, this field
indicates the upper limit on the integer portion of the rank indicates the upper limit on the integer portion of the rank
(calculated using the DAGRank() macro defined in (calculated using the DAGRank() macro defined in [RFC6550])
[I-D.ietf-roll-rpl]) that a router may have in the temporary that a router may have in the temporary DAG being created. An
DAG being created. An intermediate router MUST NOT join a Intermediate Router MUST NOT join a temporary DAG being created
temporary DAG being created by a P2P mode DIO if the integer by a P2P mode DIO if the integer portion of its rank would be
portion of its rank would be equal to or higher (in numerical equal to or higher (in numerical value) than the MaxRank limit.
value) than the MaxRank limit. A target can join the temporary A Target can join the temporary DAG at a rank whose integer
DAG at a rank whose integer portion is equal to the MaxRank. A portion is equal to the MaxRank. A router MUST discard a
router MUST discard a received P2P mode DIO if the integer part received P2P mode DIO if the integer part of the advertized
of the advertized rank equals or exceeds the MaxRank limit. A rank equals or exceeds the MaxRank limit. A value 0 in this
value 0 in this field indicates that the MaxRank is infinity. field indicates that the MaxRank is infinity.
* When a P2P-RDO is included in a DRO message, this field * When a P2P-RDO is included in a 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: An IPv6 address of the target after eliding Compr number o Target: An IPv6 address of the Target after eliding Compr number
of prefix octets. When the P2P-RDO is included in a P2P mode DIO, 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 this field may contain a unicast address or a multicast one. Any
additional target addresses can be specified by including one or additional Target addresses can be specified by including one or
more RPL Target Options [I-D.ietf-roll-rpl] in the DIO. When the more RPL Target Options [RFC6550] in the DIO. When the P2P-RDO is
P2P-RDO is included in a DRO, this field MUST contain a unicast included in a DRO, this field MUST contain a unicast IPv6 address
IPv6 address of the target generating the DRO. 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 IPv6 addresses in the Address vector MUST be reachable in * The IPv6 addresses in the Address vector MUST be reachable in
both forward and backward directions. Reachability in the both Forward and Backward directions. Reachability in the
backward direction allows a DRO message to use the route Backward direction allows a DRO message to use the route
accumulated in the Address vector to travel from the target to accumulated in the Address vector to travel from the 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 7.2. Data Option
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | Option Length | Data | | Type = 11 | Option Length | SeqNo | Upper | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Figure 2: Format of Data Option Figure 2: Format of Data Option
The format of a Data Option is illustrated in Figure 2. A P2P mode 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 DIO and a DRO (defined in Section 8) message MAY carry one or more
Data Options. A P2P-RDO consists of the following fields: Data Options. A P2P-RDO consists of the following fields:
o Option Type: 0x0B (to be confirmed by IANA). o Option Type: 0x0B (to be confirmed by IANA).
o Option Length: 8-bit unsigned integer, representing the length in o Option Length: An 8-bit unsigned integer, representing the length
octets of the option, not including the Option Type and Option in octets of the option, not including the Option Type and Option
Length fields. Length fields.
o SeqNo: A 4-bit field representing the sequence number of the data
carried by the Data Option.
o Upper: A 4-bit field that identifies the upper layer protocol
header with which the information in the Data field starts. A
value 0x00 in this field identifies UDP as the upper layer
protocol. The other values are reserved at present.
o Data: If the Data Option is contained in a DIO, this field o Data: If the Data Option is contained in a DIO, this field
contains application data to be delivered to the target(s). If contains application data to be delivered to the Target(s). If
the Data Option is contained in a DRO, this field contains the Data Option is contained in a DRO, this field contains
application data to be delivered to the origin. 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 a target to the origin; o Carry a discovered Source Route from a Target to the Origin;
o Establish a hop-by-hop route as it travels from a target to the o Establish a Hop-by-hop Route as it travels from a Target to the
origin. Origin.
A DRO message MAY serve the function of letting the routers in the A DRO message MAY serve the function of letting the routers in the
LLN know that a P2P-RPL route discovery is complete and no more DIO LLN know that a P2P-RPL route discovery is complete and no more DIO
messages need to be generated for the corresponding temporary DAG. A messages need to be generated for the corresponding temporary DAG. A
DRO message MAY also carry time-critical application data from the DRO message MAY also carry time-critical application data from the
target to the origin in one or more Data Options. A DRO message MUST Target to the Origin in a Data Option. A DRO message MUST carry one
carry one P2P-RDO whose Target field MUST contain a unicast IPv6 P2P-RDO whose Target field MUST contain a unicast IPv6 address of the
address of the target that generated the DRO. A DRO message travels Target that generated the DRO. A DRO message travels from the Target
from the target to the origin via link-local multicast along the to the Origin via link-local multicast along the route specified
route specified inside the Address vector in the P2P-RDO. 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 |S|A|Seq| Reserved | | RPLInstanceID | Version |S|A|Seq| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| DODAGID | | DODAGID |
| | | |
| | | |
skipping to change at page 15, line 30 skipping to change at page 16, line 38
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 3. 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 Stop (S): This flag, when set to one by a target, indicates that o Stop (S): This flag, when set to one by a Target, indicates that
the P2P-RPL route discovery is over. All the routers receiving the P2P-RPL route discovery is over. All the routers receiving
such a DRO, including the ones not listed in the route carried such a DRO, including the ones not listed in the route carried
inside P2P-RDO, inside P2P-RDO,
* SHOULD NOT process any more DIOs received for this temporary * SHOULD NOT process any more DIOs received for this temporary
DAG; DAG;
* SHOULD NOT generate any more DIOs for this temporary DAG; * SHOULD NOT generate any more DIOs for this temporary DAG;
* SHOULD cancel any pending DIO transmission for this temporary * SHOULD cancel any pending DIO transmission for this temporary
DAG. DAG.
Note that the stop flag serves to stop further DIO generation/ Note that the stop flag serves to stop further DIO generation/
processing for a P2P-RPL route discovery but it does not affect processing for a P2P-RPL route discovery but it does not affect
the processing of DRO messages at either the origin or the the processing of DRO messages at either the Origin or the
intermediate routers. In other words, a router (the origin or an Intermediate Routers. In other words, a router (the Origin or an
intermediate router) MUST continue to process the DRO messages Intermediate Router) MUST continue to process the DRO messages
even if an earlier DRO message (with same RPLInstanceID and even if an earlier DRO message (with the same RPLInstanceID and
DODAGID fields) had the stop flag set to one. DODAGID fields) had the stop flag set to one.
o Ack Required (A): This flag, when set to one by the target, o Ack Required (A): This flag, when set to one by the Target,
indicates that the origin MUST unicast a DRO-ACK message (defined indicates that the Origin MUST unicast a DRO-ACK message (defined
in Section 10) to the target when it receives the DRO. in Section 10) to the Target when it receives the DRO.
o Sequence Number (Seq): This 2-bit field indicates the sequence o Sequence Number (Seq): This 2-bit field indicates the sequence
number for the DRO. This field is relevant when the A flag is set number for the DRO. This field is relevant when the A flag is set
to one, i.e., the target requests an acknowledgement from the to one, i.e., the Target requests an acknowledgement from the
origin for a received DRO. The origin includes the RPLInstanceID, Origin for a received DRO. The Origin includes the RPLInstanceID,
the DODAGID and the Sequence Number of the received DRO inside the the DODAGID and the Sequence Number of the received DRO inside the
DRO-ACK message it sends back to the target. DRO-ACK message it sends back to the Target.
o Reserved: These bits are reserved for future use. These bits MUST o Reserved: These bits are reserved for future use. These bits MUST
be set to zero on transmission and MUST be ignored on reception. be set to zero on transmission and MUST be ignored on reception.
o DODAGID: The DODAGID of the temporary DAG used for route o DODAGID: The DODAGID of the temporary DAG used for route
discovery. The DODAGID also identifies the origin. The discovery. The DODAGID also identifies the Origin. The
RPLInstanceID, the Version and the DODAGID together uniquely RPLInstanceID, the Version and the DODAGID together uniquely
identify the temporary DAG used for route discovery and can be identify the temporary DAG used for route discovery and can be
copied from the DIO message advertizing the temporary DAG. copied from the DIO message advertizing the temporary DAG.
o Options: The DRO message: o Options: The DRO message:
* MUST carry one P2P-RDO that MUST specify a complete route * MUST carry one P2P-RDO that MUST specify a complete route
between the target and the origin; between the Target and the Origin;
* MAY carry one or more Metric Container Options that contains * MAY carry one or more Metric Container Options that contains
the aggregated routing metrics values for the route specified the aggregated routing metrics values for the route specified
in P2P-RDO; in P2P-RDO;
* MAY carry one or more Data Options to carry any time-critical * MAY carry one Data Option to carry any time-critical
application data to the origin. 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 [RFC6550],
[I-D.ietf-roll-rpl], where the base format is the base DRO shown in where the base format is the base DRO shown in Figure 3.
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.1. Specifically, the following fields MUST be defined in Section 7.1. Specifically, the following fields MUST be
set as specified next: set as specified next:
o Reply (R): This flag MUST be set to zero on transmission and o Reply (R): This flag MUST be set to zero on transmission and
ignored on reception. ignored on reception.
skipping to change at page 17, line 16 skipping to change at page 18, line 25
message MUST have the same value as the H flag in the P2P-RDO message MUST have the same value as the H flag in the P2P-RDO
inside the corresponding DIO message. inside the corresponding DIO message.
o Number of Routes (N): This field MUST be set to zero on o Number of Routes (N): This field MUST be set to zero on
transmission and ignored on reception. transmission and ignored on reception.
o Life Time (L): This field MUST be set to zero on transmission and o Life Time (L): This field MUST be set to zero on transmission and
ignored on reception. ignored on reception.
o MaxRank/NH: This field indicates the index of the next hop address o MaxRank/NH: This field indicates the index of the next hop address
in the Address vector. When a target generates a DRO message, the in the Address vector. When a Target generates a 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 o Target: This field MUST contain a unicast IPv6 address of the
target generating the DRO. 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 P2P-RPL route discovery operation. This section details the P2P-RPL route discovery operation.
9.1. Joining a Temporary DAG 9.1. Joining a Temporary DAG
All the routers participating in a P2P-RPL route discovery, including All the routers participating in a P2P-RPL route discovery, including
the origin and the target(s), MUST join the temporary DAG being the Origin and the Target(s), MUST join the temporary DAG being
created for the purpose. When a router joins a temporary DAG created for the purpose. When a router joins a temporary DAG
advertized by a P2P mode DIO, it SHOULD maintain its membership in advertized by a P2P mode DIO, it SHOULD maintain its membership in
the temporary DAG for the suggested Life Time duration listed in the the temporary DAG for the suggested Life Time duration listed in the
P2P-RDO. The only purpose of a temporary DAG's existence is to P2P-RDO. The only purpose of a temporary DAG's existence is to
facilitate the P2P-RPL route discovery process. The temporary DAG facilitate the P2P-RPL route discovery process. The temporary DAG
MUST NOT be used to route packets. A router SHOULD detach from the MUST NOT be used to route packets. A router SHOULD detach from the
temporary DAG once the duration of its membership in the DAG has temporary DAG once the duration of its membership in the DAG has
exceeded the DAG's suggested life time. After receiving a DRO with exceeded the DAG's life time. After receiving a DRO with the stop
the stop flag set to one, a router SHOULD NOT send or receive any flag set to one, a router SHOULD NOT send or receive any more DIOs
more DIOs for this temporary DAG and SHOULD also cancel any pending for this temporary DAG and SHOULD also cancel any pending DIO
DIO transmission. transmission.
9.2. Trickle Operation For P2P Mode DIOs 9.2. Trickle Operation For P2P Mode DIOs
An RPL router uses a Trickle timer [RFC6206] to control DIO An RPL router uses a Trickle timer [RFC6206] to control DIO
transmissions. The Trickle control of DIO transmissions provides transmissions. The Trickle control of DIO transmissions provides
quick resolution of any "inconsistency" while avoiding redundant DIO quick resolution of any "inconsistency" while avoiding redundant DIO
transmissions. The Trickle algorithm also imparts protection against transmissions. The Trickle algorithm also imparts protection against
loss of DIOs due to inherent lack of reliability in wireless loss of DIOs due to inherent lack of reliability in LLNs. When
communication. When controlling the transmissions of a P2P mode DIO, controlling the transmissions of a P2P mode DIO, a Trickle timer
a Trickle timer SHOULD follow the following rules: SHOULD follow the following rules:
o The receipt of a P2P mode DIO, that allows the router to advertise o The receipt of a P2P mode DIO, that allows the router to advertise
a better route (in terms of the routing metrics and the OF in use) a better route (in terms of the routing metrics and the OF in use)
than before, is considered "inconsistent" and hence resets the than before, is considered "inconsistent" and hence resets the
Trickle timer. Note that the first receipt of a P2P mode DIO Trickle timer. Note that the first receipt of a P2P mode DIO
advertising a particular temporary DAG is always considered an advertising a particular temporary DAG is always considered an
"inconsistent" event. "inconsistent" event.
o The receipt of a P2P mode DIO from a parent in the temporary DAG o The receipt of a P2P mode DIO from a parent in the temporary DAG
is considered neither "consistent" nor "inconsistent" if it does is considered neither "consistent" nor "inconsistent" if it does
skipping to change at page 19, line 6 skipping to change at page 20, line 12
what the router advertises (or would advertise when it gets a what the router advertises (or would advertise when it gets a
chance to generate its DIO), is considered neither "consistent" chance to generate its DIO), is considered neither "consistent"
nor "inconsistent", i.e., the receipt of such a DIO has no impact nor "inconsistent", i.e., the receipt of such a DIO has no impact
on the Trickle operation. on the Trickle operation.
o The Imin parameter SHOULD be set taking in account the o The Imin parameter SHOULD be set taking in account the
connectivity within the network. For highly connected networks, a connectivity within the network. For highly connected networks, a
small Imin value (of the order of the typical transmission delay small Imin value (of the order of the typical transmission delay
for a DIO) may lead to congestion in the network as a large number for a DIO) may lead to congestion in the network as a large number
of routers reset their Trickle timers in response to the first of routers reset their Trickle timers in response to the first
receipt of a DIO from the origin. These routers would generate receipt of a DIO from the Origin. These routers would generate
their DIOs within Imin interval and cause additional routers to their DIOs within Imin interval and cause additional routers to
reset their trickle timers and generate more DIOs. Thus, for reset their trickle timers and generate more DIOs. Thus, for
highly connected networks, the Imin parameter SHOULD be set to a highly connected networks, the Imin parameter SHOULD be set to a
value at least one order of magnitude larger than the typical value at least one order of magnitude larger than the typical
transmission delay for a DIO. For sparsely connected networks, transmission delay for a DIO. For sparsely connected networks,
the Imin parameter can be set to a value that is a small multiple the Imin parameter can be set to a value that is a small multiple
of the typical transmission delay for a DIO. Note that the Imin of the typical transmission delay for a DIO. Note that the Imin
value has a direct impact on the time required for a P2P-RPL route value has a direct impact on the time required for a P2P-RPL route
discovery to complete. In general, the time required for a P2P- discovery to complete. In general, the time required for a P2P-
RPL route discovery would increase approximately linearly with the RPL route discovery would increase approximately linearly with the
skipping to change at page 19, line 40 skipping to change at page 20, line 46
receives even a single "consistent" DIO during a timer interval. receives even a single "consistent" DIO during a timer interval.
This setting for the redundancy constant is designed to reduce the This setting for the redundancy constant is designed to reduce the
number of messages generated during a route discovery process and number of messages generated during a route discovery process and
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 [RFC6550], apply to P2P mode DIOs as well except as modified
modified in this document. in this document.
The following rules for processing a received P2P mode DIO apply to The following rules for processing a received P2P mode DIO apply to
both 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 generated the received DIO. Note that bidirectional neighbor that generated the received DIO. Note that bidirectional
reachability does not mean that the link must have the same values reachability does not mean that the link must have the same values
for a routing metric in both directions. A router SHOULD calculate for a routing metric in both directions. A router SHOULD calculate
the values of the link-level routing metrics included in the received the values of the link-level routing metrics included in the received
DIO taking in account the metric's value in both forward and backward DIO taking in account the metric's value in both forward and Backward
directions. Bidirectional reachability along a discovered route directions. Bidirectional reachability along a discovered route
allows the target to use this route to reach the origin. In allows the Target to use this route to reach the Origin. In
particular, the DRO messages travel from the target to the origin particular, the DRO messages travel from the Target to the Origin
along a discovered route. along a discovered route.
A router MUST discard a received P2P mode DIO with no further A router MUST discard a received P2P mode DIO with no further
processing: processing:
o If the DIO advertises INFINITE_RANK as defined in o If the DIO advertises INFINITE_RANK as defined in [RFC6550].
[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 o If the router previously received a DRO message with the same
RPLInstanceID and DODAGID as the received DIO and with the stop RPLInstanceID and DODAGID as the received DIO and with the stop
flag set to one. flag set to one.
The router MUST check the target addresses listed in the P2P-RDO and The router MUST check the Target addresses listed in the P2P-RDO and
any RPL Target Options included in the received DIO. If one of its any RPL Target Options included in the received DIO. If one of its
IPv6 addresses is listed as a target address or if it belongs to the IPv6 addresses is listed as a Target address or if it belongs to the
multicast group specified as one of the target addresses, the router multicast group specified as one of the Target addresses, the router
considers itself a target and processes the received DIO as specified considers itself a Target and processes the received DIO as specified
in Section 9.5. Otherwise, the router considers itself an in Section 9.5. Otherwise, the router considers itself an
intermediate router and processes the received DIO as specified in Intermediate Router and processes the received DIO as specified in
Section 9.4. Section 9.4.
9.4. Additional Processing of a P2P Mode DIO At An Intermediate Router 9.4. Additional Processing of a P2P Mode DIO At An Intermediate Router
An intermediate router MUST discard a received P2P mode DIO with no An Intermediate Router MUST discard a received P2P mode DIO with no
further processing if the router cannot elide Compr (as specified in further processing 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 do the
whether this DIO advertises a better route than the router itself and following:
whether the receipt of the DIO would allow the router to advertise a
better route than before. Accordingly, the router SHOULD consider o The router updates the Data Option to be carried in the router's
this DIO as consistent/inconsistent from Trickle perspective as DIOs if the one in the received DIO has a higher sequence number
described in Section 9.2. Note that the route comparison in a P2P- than what the router currently has (or if the router currently is
RPL route discovery is performed using the parent selection rules of not aware of any Data Option).
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 advertise a better o The router determines whether this DIO advertises a better route
route, the router MUST remember the route advertised (inside the P2P- than the router itself and whether the receipt of the DIO would
RDO) in the DIO (after adding its own IPv6 address to the route) as allow the router to advertise a better route than before.
well as any Data Options for inclusion in its future DIOs. When an Accordingly, the router SHOULD consider this DIO as consistent/
intermediate router adds itself to a route, it MUST ensure that the inconsistent from Trickle perspective as described in Section 9.2.
IPv6 address added to the route is reachable in both forward and Note that the route comparison in a P2P-RPL route discovery is
backward directions. To improve the diversity of the routes being performed using the parent selection rules of the OF in use as
discovered, an intermediate router SHOULD keep track of multiple specified in Section 14 of RPL [RFC6550]. If the received DIO
partial routes to be advertised in the P2P-RDO inside its DIO. When would allow the router to advertise a better route, the router
the router generates its DIO, it SHOULD randomly select the partial MUST remember the route advertised (inside the P2P-RDO) in the DIO
route to be included in the P2P-RDO. (after adding its own IPv6 address to the route) for inclusion in
its future DIOs. When an Intermediate Router adds itself to a
route, it MUST ensure that the IPv6 address added to the route is
reachable in both Forward and Backward directions. To improve the
diversity of the routes being discovered, an Intermediate Router
SHOULD keep track of multiple partial routes to be advertised in
the P2P-RDO inside its DIO. When the router generates its DIO, it
SHOULD randomly select the partial route to be included in the
P2P-RDO. Note that the route accumulation in a P2P mode DIO MUST
take place even if the Origin does not want any DRO messages to be
generated (i.e., the R flag inside the P2P-RDO is set to zero).
This is because the Target may still be able to use the
accumulated route as a source route to reach the Origin.
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 MUST deliver the data contained in any Data Options in the The Target MUST determine if the received DIO contains a Data Option
received DIO to the application layer. The target MAY store the and deliver the data to the specified upper layer protocol if the
route contained in the P2P-RDO in the received DIO for use as a option's sequence number is higher than that of the options in the
source route to reach the origin. If the Reply flag inside the P2P- previously received DIOs for this route discovery (or if the DIOs
RDO is zero, the target MUST discard the received DIO with no further received earlier did not have a Data Option). If this route
processing. Otherwise, the target MAY select the route contained in discovery involves multiple Targets, the Target MUST remember the
the P2P-RDO to send a DRO message back to the origin. If the H flag Data Option with highest sequence number for inclusion in its own
inside the P2P-RDO is one, the target needs to select one route and DIOs.
send a DRO message along this route back to the origin. If the H
flag is zero, the number of routes to be selected (and the number of
DRO messages to be sent back) is given by one plus the value of the N
field in the P2P-RDO. This document does not prescribe a particular
method for the target to select the routes. Example methods include
selecting each route that meets the specified routing constraints
until the desired number have been selected or selecting the best
routes discovered over a certain time period. If multiple routes are
to be selected, the target SHOULD avoid selecting routes that have
large segments in common.
If the target selects the route contained in the P2P-RDO in the The Target MAY store the route contained in the P2P-RDO in the
received DIO, it sends a DRO message back to the origin (identified received DIO for use as a Source Route to reach the Origin. The
lifetime of this Source Route is specified by the Default Lifetime
and Lifetime Unit parameters inside the DODAG Configuration Option
currently in effect. This lifetime can be extended (or shortened)
appropriately following a hint from an upper-layer protocol.
If the Reply flag inside the P2P-RDO in the received DIO is zero, the
Target MUST discard the received DIO with no further processing.
Otherwise, the Target MAY select the route contained in the P2P-RDO
to send a DRO message back to the Origin. If the H flag inside the
P2P-RDO is one, the Target needs to select one route and send a DRO
message along this route back to the Origin. If the H flag is zero,
the number of routes to be selected (and the number of DRO messages
to be sent back) is given by one plus the value of the N field in the
P2P-RDO. This document does not prescribe a particular method for
the Target to select the routes. Example methods include selecting
each route that meets the specified routing constraints until the
desired number have been selected or selecting the best routes
discovered over a certain time period. If multiple routes are to be
selected, the Target SHOULD avoid selecting routes that have large
segments in common.
If the Target selects the route contained in the P2P-RDO in the
received DIO, it sends a DRO message back to the Origin (identified
by the DODAGID field in the DIO). The DRO message MUST include a by the DODAGID field in the DIO). The DRO message MUST include a
P2P-RDO that contains the selected route inside the Address vector. P2P-RDO that contains the selected route inside the Address vector.
Various fields inside the P2P-RDO MUST be set as specified in Various fields inside the P2P-RDO MUST be set as specified in
Section 8.2. The target MAY set the A flag inside the DRO message to Section 8.2. The Target MAY set the A flag inside the DRO message to
one if it desires the origin to send back a DRO-ACK message on one if it desires the Origin to send back a DRO-ACK message on
receiving the DRO. In this case, the target waits for receiving the DRO. In this case, the Target waits for
DRO_ACK_WAIT_TIME duration for the DRO-ACK message to arrive. DRO_ACK_WAIT_TIME duration for the DRO-ACK message to arrive.
Failure to receive the DRO-ACK message within this time duration Failure to receive the DRO-ACK message within this time duration
causes the target to retransmit the DRO message. The target MAY causes the Target to retransmit the DRO message. The Target MAY
retransmit the DRO message in this fashion up to retransmit the DRO message in this fashion up to
MAX_DRO_RETRANSMISSIONS times. The values of DRO_ACK_WAIT_TIME and MAX_DRO_RETRANSMISSIONS times. Both DRO_ACK_WAIT_TIME and
MAX_DRO_RETRANSMISSIONS are defined in Section 12. MAX_DRO_RETRANSMISSIONS are configurable parameters to be decided
based on the characteristics of individual deployments. Note that
all DRO transmissions and retransmissions MUST take place while the
Target is still a part of the temporary DAG created for the route
discovery. A Target MUST NOT transmit a DRO if it no longer belongs
to this DAG.
The target MAY set the stop flag inside the DRO message to one if The Target MAY set the stop flag inside the DRO message to one if
o this router is the only target specified in the corresponding DIO,
o this router is the only Target specified in the corresponding DIO,
i.e., the corresponding DIO specified a unicast address of the i.e., the corresponding DIO specified a unicast address of the
router as the Target inside the P2P-RDO with no additional targets router as the Target inside the P2P-RDO with no additional Targets
specified via RPL Target Options; and specified via RPL Target Options; and
o the target has already selected the desired number of routes. o the Target has already selected the desired number of routes.
The target MAY include a Metric Container Option in the DRO message. The Target MAY include a Metric Container Option in the 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 include one for the route specified in the P2P-RDO. The Target MAY include one
or more Data Options in the DRO message to carry time-critical Data Option in the DRO message to carry time-critical application
application data for the origin. The target MUST transmit the DRO data for the Origin. Note that this Data Option is not same as the
message via a link-local multicast. Data Option that the Target may include in the DIOs it generates for
this route discovery (if the route discovery involves multiple
Targets). The Target MUST transmit the DRO message via a link-local
multicast.
A target MUST NOT forward a P2P mode DIO any further. A Target MUST NOT forward a P2P mode DIO any further if no other
Targets are to be discovered, i.e., if a unicast IPv6 address (of
this Target) is specified as the Target inside the P2P-RDO and no
additional Targets are specified via RPL Target Options inside the
DIOs for this route discovery. Otherwise, the Target MUST generate
DIOs for this route discovery as an Intermediate Router would.
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 If the DODAGID field in the received DRO does not list a router's own
address in the DODAGID field, the router MUST process the received IPv6 address, the router considers itself an Intermediate Router and
message in the following manner: MUST process the received message in the following manner:
o The router MUST discard the received DRO with no further
processing if it does not belong to the temporary DAG identified
by the RPLInstanceID and the DODAGID fields in the DRO.
o If the stop flag inside the received DRO is set to one, the router o If the stop flag inside the received DRO is set to one, the router
SHOULD NOT send or receive any more DIOs for this temporary DAG SHOULD NOT send or receive any more DIOs for this temporary DAG
and SHOULD cancel any pending DIO transmission. and SHOULD cancel any pending DIO transmission.
o An intermediate router MUST ignore any Metric Container and Data o The router MUST ignore any Metric Container and Data Options
Options contained in the DRO message. contained in the DRO message.
o If Address[NH] element inside the Route Discovery Option lists the o If Address[NH] element inside the P2P-RDO lists the router's own
router's own IPv6 address, the router is a part of the route unicast IPv6 address, the router is a part of the route carried in
carried in the P2P-RDO. In this case, the router MUST do the the P2P-RDO. In this case, the router MUST do the following:
following:
* To prevent loops, the router MUST discard the DRO message with
no further processing if the Address vector in the P2P-RDO
includes multiple IPv6 addresses assigned to the router's
interfaces and if such addresses do not appear back to back
inside the Address vector.
* If the H flag inside the P2P-RDO is one, the router MUST store * If the H flag inside the P2P-RDO is one, the router MUST store
the state for the forward hop-by-hop route carried inside the the state for the forward hop-by-hop route carried inside the
P2P-RDO. This state consists of: P2P-RDO. This state consists of:
+ The RPLInstanceID and the DODAGID fields of the DRO. + The RPLInstanceID and the DODAGID fields of the DRO.
+ The route's destination, the target (identified by Target + The route's destination, the Target (identified by Target
field inside 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).
This hop-by-hop routing state MUST expire at the end of the
lifetime specified by the Default Lifetime and Lifetime Unit
parameters inside the DODAG Configuration Option used in P2P
mode DIOs for this route discovery.
* If the router already maintains a hop-by-hop state listing the * If the router already maintains a hop-by-hop state listing the
target as the destination and carrying same RPLInstanceID and Target as the destination and carrying same RPLInstanceID and
DODAGID fields as the received DRO and the next hop information DODAGID fields as the received 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 discard 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 message in corresponding P2P-RPL route discovery and processes the message in
the following manner. the following manner:
The origin MUST deliver data in any Data Options in the received DRO o The Origin MUST discard the received DRO with no further
to the application layer. processing if it no longer belongs to the temporary DAG identified
by the RPLInstanceID and the DODAGID fields in the DRO.
If the stop flag inside the received DRO is set to one, the origin o The Origin MUST check if the received DRO contains a Data Option
SHOULD NOT generate any more DIOs for this temporary DAG and SHOULD with higher sequence number than what was received previously (or
cancel any pending DIO transmission. if this Data Option is the first one received). In that case, the
Origin MUST deliver the data inside the Data Option to the upper
layer protocol identified inside the Data Option.
If the P2P-RDO inside the DRO identifies the discovered route as a o If the stop flag inside the received DRO is set to one, the Origin
source route (H=0), the origin MUST store in its memory the SHOULD NOT generate any more DIOs for this temporary DAG and
discovered route contained in the Address vector. SHOULD cancel any pending DIO transmission.
If the P2P-RDO inside the DRO identifies the discovered route as a o If the P2P-RDO inside the DRO identifies the discovered route as a
hop-by-hop route (H=1), the origin MUST store in its memory the state Source Route (H=0), the Origin MUST store in its memory the
for the discovered route in the manner described in Section 9.6. discovered route contained in the Address vector. The lifetime of
this Source Route is specified by the Default Lifetime and
Lifetime Unit parameters inside the DODAG Configuration Option in
the P2P mode DIOs used for this route discovery. This lifetime
could be extended (or shortened) appropriately following a hint
from an upper-layer protocol.
If the received DRO message contains one or more Metric Container o If the P2P-RDO inside the DRO identifies the discovered route as a
Options, the origin MAY store the values of the routing metrics Hop-by-hop Route (H=1), the Origin MUST store in its memory the
associated with the discovered route in its memory. This information state for the discovered route in the manner described in
may be useful in formulating the constraints for any future P2P-RPL Section 9.6. This hop-by-hop routing state MUST expire at the end
route discovery to the target. of the lifetime specified by the Default Lifetime and Lifetime
Unit parameters inside the DODAG Configuration Option used in P2P
mode DIOs for this route discovery. A future version of this
document may consider specifying a signaling mechanism that will
allow the Origin to extend (or shorten) the lifetime of a P2P-RPL
Hop-by-hop Route following a suitable hint from an upper-layer
protocol.
If the A flag is set to one in the received DRO message, the origin o If the received DRO message contains one or more Metric Container
MUST generate a DRO-ACK message as described in Section 10 and Options, the Origin MAY store the values of the routing metrics
unicast the message to the target (identified by the Target field associated with the discovered route in its memory. This
inside the P2P-RDO). The origin MAY use the route just discovered to information may be useful in formulating the constraints for any
send the DRO-ACK message to the target. Section 11 describes how a future P2P-RPL route discovery to the Target.
packet may be forwarded along a source/hop-by-hop route discovered
using P2P-RPL. o If the A flag is set to one in the received DRO message, the
Origin MUST generate a DRO-ACK message as described in Section 10
and unicast the message to the Target (identified by the Target
field inside the P2P-RDO). The Origin MAY use the route just
discovered to send the DRO-ACK message to the Target. Section 11
describes how a packet may be forwarded along a source/Hop-by-hop
Route 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 4: 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
unreliable wireless communication. Since a DRO message travels via unreliable packet transmission in LLNs. Since a DRO message travels
link-local multicast, it cannot use link-level acknowledgements to via link-local multicast, it cannot use link-level acknowledgements
improve the reliability of its transmission. Also, an intermediate to improve the reliability of its transmission. Also, an
router may drop the DRO message (e.g., because of its inability to Intermediate Router may drop the DRO message (e.g., because of its
store the state for the hop-by-hop route the DRO is establishing). inability to store the state for the Hop-by-hop Route the DRO is
To protect against the potential failure of a DRO message to reach establishing). To protect against the potential failure of a DRO
the origin, the target MAY request the origin to send back a DRO message to reach the Origin, the Target MAY request the Origin to
Acknowledgement (DRO-ACK) message on receiving a DRO message. send back a DRO Acknowledgement (DRO-ACK) message on receiving a DRO
Failure to receive such an acknowledgement within the message. 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 4. 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 [RFC6550], where the base format is same as the base DRO-ACK shown
DRO-ACK shown in Figure 4. in Figure 4.
11. Packet Forwarding Along a Route Discovered Using P2P-RPL 11. Packet Forwarding Along a Route Discovered Using P2P-RPL
An origin MAY use a Source Routing Header (SRH) An Origin MAY use a Source Routing Header (SRH) [RFC6554] to send a
packet along a Source Route discovered using P2P-RPL.
[I-D.ietf-6man-rpl-routing-header] to send a packet along a source
route discovered using P2P-RPL.
Travel along a hop-by-hop route, established using P2P-RPL, requires Travel along a Hop-by-hop Route, established using P2P-RPL, requires
specifying the RPLInstanceID and the DODAGID (of the temporary DAG specifying the RPLInstanceID and the DODAGID (of the temporary DAG
used for the route discovery) to identify the route. This is because used for the route discovery) to identify the route. This is because
a P2P-RPL route discovery does not use globally unique RPLInstanceID a P2P-RPL route discovery does not use globally unique RPLInstanceID
values and hence both the RPLInstanceID (a local value assigned by values and hence both the RPLInstanceID (a local value assigned by
the origin) and the DODAGID (an IPv6 address of the origin) are the Origin) and the DODAGID (an IPv6 address of the Origin) are
required to uniquely identify a P2P-RPL hop-by-hop route to a required to uniquely identify a P2P-RPL Hop-by-hop Route to a
particular destination. particular destination.
An origin MAY include an RPL option [I-D.ietf-6man-rpl-option] inside An Origin MAY include an RPL option [RFC6553] inside the IPv6 hop-by-
the IPv6 hop-by-hop options header of a packet to send it along a hop options header of a packet to send it along a Hop-by-hop Route
hop-by-hop route established using P2P-RPL. For this purpose, the established using P2P-RPL. For this purpose, the Origin MUST set the
origin MUST set the DODAGID of the temporary DAG used for the route DODAGID of the temporary DAG used for the route discovery as the
discovery as the source IPv6 address of the packet. Further, the source IPv6 address of the packet. Further, the Origin MUST specify
origin MUST specify inside the RPL option the RPLInstanceID of the inside the RPL option the RPLInstanceID of the temporary DAG used for
temporary DAG used for the route discovery and set the O flag inside the route discovery and set the O flag inside the RPL option to one.
the RPL option to one. On receiving this packet, an intermediate On receiving this packet, an Intermediate Router checks the O flag
router checks the O flag and correctly infer the source IPv6 address and correctly infer the source IPv6 address of the packet as the
of the packet as the DODAGID of the hop-by-hop route. The router DODAGID of the Hop-by-hop Route. The router then uses the DODAGID,
then uses the DODAGID, the RPLInstanceID and the destination address the RPLInstanceID and the destination address to identify the routing
to identify the routing state to be used to forward the packet state to be used to forward the packet further.
further.
12. Constants
This document defines the following constants:
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
value of 1 second.
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
response. MAX_DRO_RETRANSMISSIONS has a value 2.
13. Interoperability with Core RPL 12. Interoperability with Core RPL
This section describes how RPL routers that implement P2P-RPL This section describes how RPL routers that implement P2P-RPL
interact with RPL routers that do not. In general, P2P-RPL operation interact with RPL routers that do not. In general, P2P-RPL operation
does not affect core RPL operation and vice versa. However, core RPL does not affect core RPL operation and vice versa. However, core RPL
does allow a router to join a DAG as a leaf node even if it does not does allow a router to join a DAG as a leaf node even if it does not
understand the Mode of Operation (MOP) used in the DAG. Thus, an RPL understand the Mode of Operation (MOP) used in the DAG. Thus, an RPL
router that does not implement P2P-RPL may conceivably join a router that does not implement P2P-RPL may conceivably join a
temporary DAG being created for a P2P-RPL route discovery as a leaf temporary DAG being created for a P2P-RPL route discovery as a leaf
node and maintain its membership even though the DAG no longer node and maintain its membership even though the DAG no longer
exists. This may impose a drain on the router's memory. However, exists. This may impose a drain on the router's memory. However,
skipping to change at page 26, line 21 skipping to change at page 28, line 32
join a DAG whose MOP it does not understand. Moreover, RPL routers join a DAG whose MOP it does not understand. Moreover, RPL routers
in a particular deployment may have strict restrictions on the DAGs in a particular deployment may have strict restrictions on the DAGs
they may join, thereby mitigating the problem. they may join, thereby mitigating the problem.
The P2P-RPL mechanism described in this document works best when all The P2P-RPL mechanism described in this document works best when all
the RPL routers in the LLN implement P2P-RPL. In general, the the RPL routers in the LLN implement P2P-RPL. In general, the
ability to discover routes as well as the quality of discovered ability to discover routes as well as the quality of discovered
routes would deteriorate with the fraction of RPL routers that routes would deteriorate with the fraction of RPL routers that
implement P2P-RPL. implement P2P-RPL.
14. Security Considerations 13. Security Considerations
The security considerations for the operation of P2P-RPL are similar A P2P-RPL deployment may be susceptible to denial of service attacks
to the ones for the operation of RPL (as described in Section 19 of by rogue routers that initiate fake route discoveries. A rogue
[I-D.ietf-roll-rpl]). Section 10 of RPL specification router could join a temporary DAG and advertise false information in
[I-D.ietf-roll-rpl] describes a variety of security mechanisms that its DIOs in order to include itself in the discovered route(s). It
provide data confidentiality, authentication, replay protection and could generate bogus DRO messages carrying bad routes or maliciously
delay protection services. Each RPL control message has a secure modify genuine DRO messages it receives.
version that allows the specification of the level of security and
the algorithms used to secure the message. The mechanism defined in In general, the security considerations for the operation of P2P-RPL
this document is based on the use of DIOs to form a temporary DAG and are similar to the ones for the operation of RPL (as described in
Section 19 of [RFC6550]). Section 10 of RPL specification [RFC6550]
describes a variety of security mechanisms that provide data
confidentiality, authentication, replay protection and delay
protection services. Each RPL control message has a secure version
that allows the specification of the level of security and the
algorithms used to secure the message. The mechanism defined in 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 P2P- and DRO-ACK) have secure versions as well. In addition, a P2P-RPL
RPL deployment can analyze its security requirements and use the deployment may use the security features provided by the link layer
appropriate set of RPL security mechanisms that meet those in use. Thus, a particular P2P-RPL deployment can analyze its
requirements. security requirements and use the appropriate set of RPL (or link
layer) security mechanisms that meet those requirements.
15. IANA Considerations Since a DRO message travels along a Source Route specified inside the
message, some of the security concerns that led to the deprecation of
Type 0 routing header [RFC5095] may apply. To avoid the possibility
of a DRO message traveling in a routing loop, this document requires
each Intermediate Router to confirm that the Source Route listed
inside the message does not contain any routing loop involving itself
before the router could forward the message further. As specified in
Section 9.6, this check involves the router making sure that its IPv6
addresses do not appear multiple times inside the Source Route with
one or more other IPv6 addresses in between.
15.1. Additions to DIO Mode of Operation 14. IANA Considerations
14.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.
+----------+-----------------------------------------+--------------+ +----------+-----------------------------------------+--------------+
| MOP | Description | Reference | | MOP | Description | Reference |
| 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 14.2. Additions to RPL Control Message Options
IANA is requested to allocate new values in the "RPL Control Message IANA is requested to allocate new values in the "RPL Control Message
Options" registry for the "P2P Route Discovery Option" and the "Data Options" registry for the "P2P Route Discovery Option" and the "Data
Option" described in this 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 | | 11 | Data | This document |
+-------+---------------------+---------------+ +-------+---------------------+---------------+
RPL Control Message Options RPL Control Message Options
15.3. Additions to RPL Control Codes 14.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.
+------+--------------------------------------------+---------------+ +------+--------------------------------------------+---------------+
| Code | Description | Reference | | Code | Description | Reference |
+------+--------------------------------------------+---------------+ +------+--------------------------------------------+---------------+
| 0x04 | Discovery Reply Object | This document | | 0x04 | Discovery Reply Object | This document |
| 0x05 | Discovery Reply Object Acknowledgement | This document | | 0x05 | Discovery Reply Object Acknowledgement | This document |
| 0x84 | Secure Discovery Reply Object | This document | | 0x84 | Secure Discovery Reply Object | This document |
| 0x85 | Secure Discovery Reply Object | This document | | 0x85 | Secure Discovery Reply Object | This document |
| | Acknowledgement | | | | Acknowledgement | |
+------+--------------------------------------------+---------------+ +------+--------------------------------------------+---------------+
RPL Control Codes RPL Control Codes
16. Acknowledgements 14.4. New Registry for Upper Layer Headers inside Data Option
This document creates a new IANA registry for the Upper Layer Header
type inside the RPL Data Option, with the following initial content:
+-------+-------------+---------------+
| Value | Description | Reference |
+-------+-------------+---------------+
| 0x00 | UDP Header | This document |
+-------+-------------+---------------+
Upper Layer Header Types inside RPL Data Option
15. Acknowledgements
Authors gratefully acknowledge the contributions of the following Authors gratefully acknowledge the contributions of the following
individuals (in alphabetical order) in the development of this individuals (in alphabetical order) in the development of this
document: Dominique Barthel, Jakob Buron, 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 16. References
17.1. Normative References
[I-D.ietf-roll-routing-metrics]
Barthel, D., Vasseur, J., Pister, K., Kim, M., and N.
Dejean, "Routing Metrics used for Path Calculation in Low
Power and Lossy Networks",
draft-ietf-roll-routing-metrics-19 (work in progress),
March 2011.
[I-D.ietf-roll-rpl] 16.1. Normative References
Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P.,
Levis, P., Struik, R., Kelsey, R., Clausen, T., and T.
Winter, "RPL: IPv6 Routing Protocol for Low power and
Lossy Networks", draft-ietf-roll-rpl-19 (work in
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 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R.,
Levis, P., Pister, K., Struik, R., Vasseur, JP., and R.
[I-D.ietf-6man-rpl-option] Alexander, "RPL: IPv6 Routing Protocol for Low-Power and
Hui, J. and J. Vasseur, "RPL Option for Carrying RPL Lossy Networks", RFC 6550, March 2012.
Information in Data-Plane Datagrams",
draft-ietf-6man-rpl-option-06 (work in progress),
December 2011.
[I-D.ietf-6man-rpl-routing-header] [RFC6551] Vasseur, JP., Kim, M., Pister, K., Dejean, N., and D.
Culler, D., Hui, J., Vasseur, J., and V. Manral, "An IPv6 Barthel, "Routing Metrics Used for Path Calculation in
Routing Header for Source Routes with RPL", Low-Power and Lossy Networks", RFC 6551, March 2012.
draft-ietf-6man-rpl-routing-header-07 (work in progress),
December 2011.
[I-D.ietf-roll-of0] 16.2. Informative References
Thubert, P., "RPL Objective Function Zero",
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
Mechanism to Measure the Quality of a Point-to-point Route Mechanism to Measure the Quality of a Point-to-point Route
in a Low Power and Lossy Network", in a Low Power and Lossy Network",
draft-ietf-roll-p2p-measurement-03 (work in progress), draft-ietf-roll-p2p-measurement-04 (work in progress),
March 2012. March 2012.
[I-D.ietf-roll-terminology] [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
Vasseur, J., "Terminology in Low power And Lossy of Type 0 Routing Headers in IPv6", RFC 5095,
Networks", draft-ietf-roll-terminology-06 (work in December 2007.
progress), September 2011.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks", Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, April 2010. RFC 5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power and "Building Automation Routing Requirements in Low-Power and
Lossy Networks", RFC 5867, June 2010. Lossy Networks", RFC 5867, June 2010.
[RFC6552] Thubert, P., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)",
RFC 6552, March 2012.
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL
Information in Data-Plane Datagrams", RFC 6553,
March 2012.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554,
March 2012.
Authors' Addresses Authors' Addresses
Mukul Goyal (editor) Mukul Goyal (editor)
University of Wisconsin Milwaukee University of Wisconsin Milwaukee
3200 N Cramer St 3200 N Cramer St
Milwaukee, WI 53201 Milwaukee, WI 53201
USA USA
Phone: +1 414 2295001 Phone: +1 414 2295001
Email: mukul@uwm.edu Email: mukul@uwm.edu
 End of changes. 163 change blocks. 
475 lines changed or deleted 603 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/