draft-ietf-roll-p2p-rpl-10.txt   draft-ietf-roll-p2p-rpl-11.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: November 6, 2012 E. Baccelli Expires: November 7, 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
May 5, 2012 May 6, 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-10 draft-ietf-roll-p2p-rpl-11
Abstract Abstract
This document specifies a point-to-point route discovery mechanism, This document specifies a point-to-point route discovery mechanism,
complementary to the RPL core functionality. This mechanism allows complementary to the RPL core functionality. This mechanism allows
an IPv6 router to discover "on demand" routes to one or more IPv6 an IPv6 router to discover "on demand" routes to one or more IPv6
routers in the LLN such that the discovered routes meet specified routers in the LLN such that the discovered routes meet specified
metrics constraints. metrics constraints.
Status of this Memo Status of this Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 6, 2012. This Internet-Draft will expire on November 7, 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 31 skipping to change at page 2, line 31
6.1. Setting a P2P Mode DIO . . . . . . . . . . . . . . . . . . 9 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) . . . . . . . . . . . 12 7.1. P2P Route Discovery Option (P2P-RDO) . . . . . . . . . . . 12
7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. Data Option . . . . . . . . . . . . . . . . . . . . . . . 15
8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 15 8. The Discovery Reply Object (DRO) . . . . . . . . . . . . . . . 15
8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Secure DRO . . . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Setting a P2P-RDO Carried in a Discovery Reply Object . . 18 8.2. Setting a P2P-RDO Carried in a Discovery Reply Object . . 18
9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 18 9. P2P-RPL Route Discovery By Creating a Temporary DAG . . . . . 18
9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 18 9.1. Joining a Temporary DAG . . . . . . . . . . . . . . . . . 18
9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 19 9.2. Trickle Operation For P2P Mode DIOs . . . . . . . . . . . 19
9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 20 9.3. Processing a P2P Mode DIO . . . . . . . . . . . . . . . . 21
9.4. Additional Processing of a P2P Mode DIO At An 9.4. Additional Processing of a P2P Mode DIO At An
Intermediate Router . . . . . . . . . . . . . . . . . . . 21 Intermediate Router . . . . . . . . . . . . . . . . . . . 22
9.5. Additional Processing of a P2P Mode DIO At The Target . . 22 9.5. Additional Processing of a P2P Mode DIO At The Target . . 22
9.6. Processing a DRO At An Intermediate Router . . . . . . . . 24 9.6. Processing a DRO At An Intermediate Router . . . . . . . . 24
9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 25 9.7. Processing a DRO At The Origin . . . . . . . . . . . . . . 25
10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 26 10. The Discovery Reply Object Acknowledgement (DRO-ACK) . . . . . 27
11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 27 11. Packet Forwarding Along a Route Discovered Using P2P-RPL . . . 27
12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 28 12. Interoperability with Core RPL . . . . . . . . . . . . . . . . 28
13. Security Considerations . . . . . . . . . . . . . . . . . . . 28 13. Security Considerations . . . . . . . . . . . . . . . . . . . 29
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
14.1. Additions to DIO Mode of Operation . . . . . . . . . . . . 29 14.1. Additions to DIO Mode of Operation . . . . . . . . . . . . 29
14.2. Additions to RPL Control Message Options . . . . . . . . . 29 14.2. Additions to RPL Control Message Options . . . . . . . . . 30
14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 30 14.3. Additions to RPL Control Codes . . . . . . . . . . . . . . 30
14.4. New Registry for Upper Layer Headers inside Data Option . 30 14.4. New Registry for Upper Layer Headers inside Data Option . 30
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
16.1. Normative References . . . . . . . . . . . . . . . . . . . 31 16.1. Normative References . . . . . . . . . . . . . . . . . . . 31
16.2. Informative References . . . . . . . . . . . . . . . . . . 31 16.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 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 [RFC6550] provides paths along a Directed Acyclic Graph protocol [RFC6550] provides paths along a Directed Acyclic Graph
(DAG) rooted at a single router in the network. Establishment and (DAG) rooted at a single router in the network. Establishment and
skipping to change at page 10, line 43 skipping to change at page 10, line 43
the DODAG Configuration Option in the outgoing P2P mode DIOs to the DODAG Configuration Option in the outgoing P2P mode DIOs to
the values they had in the incoming P2P mode DIOs for this DAG. 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. This value is roughly one order
of magnitude larger than the typical transmission delay on IEEE
802.15.4 links and corresponds to the recommendation in
Section 9.2 for well-connected topologies.
o DIORedundancyConstant: 1 o DIORedundancyConstant: 1. See the discussion in Section 9.2.
o MaxRankIncrease: 0 o MaxRankIncrease: 0 (to disable local repair of the temporary DAG).
o Default Lifetime: 0xFF o Default Lifetime: 0xFF, to correspond to infinity.
o Lifetime Unit: 0xFFFF, to correspond to infinity.
o Lifetime Unit: 0xFFFF
o Objective Code Point: 0, i.e., OF0 [RFC6552] is the default o Objective Code Point: 0, i.e., OF0 [RFC6552] is the default
objective function. objective function.
o The remaining parameters have default values as specified in o The remaining parameters have default values as specified in
[RFC6550]. [RFC6550].
Individual P2P-RPL deployments are encouraged to share their
experience with these default values with ROLL working group to help
guide the development of standards track version of the protocol.
The routing metrics and constraints [RFC6551] used in P2P-RPL route The routing metrics and constraints [RFC6551] used in P2P-RPL route
discovery are included in one or more Metric Container Options discovery are included in one or more Metric Container Options
[RFC6550] inside the P2P mode DIO. Note that a DIO need not include [RFC6550] inside the P2P mode DIO. Note that a DIO need not include
a Metric Container if OF0 is the objective function in effect. In a Metric Container if OF0 is the objective function in effect. In
that case, a P2P mode DIO may still specify an upper limit on the that case, a P2P mode DIO may still specify an upper limit on the
maximum rank, that a router may have in the temporary DAG, inside the maximum rank, that a router may have in the temporary DAG, inside the
P2P Route Discovery Option (described in Section 7.1). P2P Route Discovery Option (described in Section 7.1).
A P2P mode DIO: A P2P mode DIO:
skipping to change at page 13, line 32 skipping to change at page 13, line 35
* 0x01: 4 seconds; * 0x01: 4 seconds;
* 0x02: 16 seconds; * 0x02: 16 seconds;
* 0x03: 64 seconds; * 0x03: 64 seconds;
The Origin sets this field based on its expectation regarding the The Origin sets this field based on its expectation regarding the
time required for the route discovery to complete, which includes time required for the route discovery to complete, which includes
the time required for the DIOs to reach the Target(s) and the DROs the time required for the DIOs to reach the Target(s) and the DROs
to travel back to the Origin. While deciding the temporary DAG's to travel back to the Origin. The time required for the DIOs to
lifetime, the Origin should also take in account the fact that all reach the Target(s) would in turn depend on the Trickle parameters
nodes joining the temporary DAG would need to stay in the DAG for (Imin and the redundancy constant) as well as the expected
at least this much time. distance (in terms of hops and/or ETX) to the Target(s). 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 [RFC6550]) (calculated using the DAGRank() macro defined in [RFC6550])
that a router may have in the temporary DAG being created. An that a router may have in the temporary DAG being created. An
Intermediate Router MUST NOT join a temporary DAG being created Intermediate Router MUST NOT join a temporary DAG being created
by a P2P mode DIO if the integer portion of its rank would be by a P2P mode DIO if the integer portion of its rank would be
equal to or higher (in numerical value) than the MaxRank limit. equal to or higher (in numerical value) than the MaxRank limit.
skipping to change at page 20, line 23 skipping to change at page 20, line 23
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
value of the Imin parameter. value of the Imin parameter. Since the route discovery must
complete within the lifetime of the temporary DAG created for the
purpose, the Origin should set this lifetime to a large enough
value taking in account the Imin value as well as the expected
distance (in terms of hops and/or ETX) to the Target(s).
o The Imax parameter SHOULD be set to a large value (several orders o The Imax parameter SHOULD be set to a large value (several orders
of magnitude higher than the Imin value) and is unlikely to be of magnitude higher than the Imin value) and is unlikely to be
critical for P2P-RPL operation. This is because the first receipt critical for P2P-RPL operation. This is because the first receipt
of a P2P mode DIO for a particular temporary DAG is considered an of a P2P mode DIO for a particular temporary DAG is considered an
inconsistent event and would lead to resetting of Trickle timer inconsistent event and would lead to resetting of Trickle timer
duration to the Imin value. Given the temporary nature of the duration to the Imin value. Given the temporary nature of the
DAGs used in P2P-RPL, Trickle timer may not get a chance to DAGs used in P2P-RPL, Trickle timer may not get a chance to
increase much. increase much.
o The recommended value of redundancy constant "k" is 1. With this o The recommended value of redundancy constant "k" is 1. With this
value of "k", a DIO transmission will be suppressed if the router value of "k", a DIO transmission will be suppressed if the router
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. A higher value for the redundancy constant may be more
value for the redundancy constant may be more suitable. suitable in environments with high packet loss rates or in
deployments where specific destinations are reachable only through
specific intermediate routers (and hence these intermediate
routers should not suppress their DIOs). A particular deployment
should take in account typical loss rates, the topological
characteristics of the LLN (the average/typical connectivity of
the nodes and the variance in connectivity: whether some
destinations have only a small set of neighbors) and the need to
contain the message overhead of the route discovery when deciding
the value of the redundancy constant.
9.3. Processing a P2P Mode DIO 9.3. Processing a P2P Mode DIO
The rules for DIO processing and transmission, described in Section 8 The rules for DIO processing and transmission, described in Section 8
of RPL [RFC6550], apply to P2P mode DIOs as well except as modified of RPL [RFC6550], apply to P2P mode DIOs as well except as modified
in this document. in 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.
skipping to change at page 26, line 11 skipping to change at page 26, line 24
the P2P mode DIOs used for this route discovery. This lifetime the P2P mode DIOs used for this route discovery. This lifetime
could be extended (or shortened) appropriately following a hint could be extended (or shortened) appropriately following a hint
from an upper-layer protocol. from an upper-layer protocol.
o 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 Hop-by-hop Route (H=1), the Origin MUST store in its memory the
state for the discovered route in the manner described in state for the discovered route in the manner described in
Section 9.6. This hop-by-hop routing state MUST expire at the end Section 9.6. This hop-by-hop routing state MUST expire at the end
of the lifetime specified by the Default Lifetime and Lifetime of the lifetime specified by the Default Lifetime and Lifetime
Unit parameters inside the DODAG Configuration Option used in P2P Unit parameters inside the DODAG Configuration Option used in P2P
mode DIOs for this route discovery. A future version of this mode DIOs for this route discovery. The standards track version
document may consider specifying a signaling mechanism that will of P2P-RPL may consider specifying a signaling mechanism that will
allow the Origin to extend (or shorten) the lifetime of a P2P-RPL 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 Hop-by-hop Route following a suitable hint from an upper-layer
protocol. protocol.
o If the received DRO message contains one or more Metric Container o If the received DRO message contains one or more Metric Container
Options, the Origin MAY store the values of the routing metrics Options, the Origin MAY store the values of the routing metrics
associated with the discovered route in its memory. This associated with the discovered route in its memory. This
information may be useful in formulating the constraints for any information may be useful in formulating the constraints for any
future P2P-RPL route discovery to the Target. future P2P-RPL route discovery to the Target.
 End of changes. 20 change blocks. 
24 lines changed or deleted 48 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/