draft-ietf-roll-rpl-12.txt   draft-ietf-roll-rpl-13.txt 
ROLL T. Winter, Ed. ROLL T. Winter, Ed.
Internet-Draft Internet-Draft
Intended status: Standards Track P. Thubert, Ed. Intended status: Standards Track P. Thubert, Ed.
Expires: April 4, 2011 Cisco Systems Expires: April 25, 2011 Cisco Systems
A. Brandt A. Brandt
Sigma Designs Sigma Designs
T. Clausen T. Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
J. Hui J. Hui
Arch Rock Corporation Arch Rock Corporation
R. Kelsey R. Kelsey
Ember Corporation Ember Corporation
P. Levis P. Levis
Stanford University Stanford University
K. Pister K. Pister
Dust Networks Dust Networks
R. Struik R. Struik
JP. Vasseur JP. Vasseur
Cisco Systems Cisco Systems
October 1, 2010 October 22, 2010
RPL: IPv6 Routing Protocol for Low power and Lossy Networks RPL: IPv6 Routing Protocol for Low power and Lossy Networks
draft-ietf-roll-rpl-12 draft-ietf-roll-rpl-13
Abstract Abstract
Low power and Lossy Networks (LLNs) are a class of network in which Low power and Lossy Networks (LLNs) are a class of network in which
both the routers and their interconnect are constrained. LLN routers both the routers and their interconnect are constrained. LLN routers
typically operate with constraints on processing power, memory, and typically operate with constraints on processing power, memory, and
energy (battery power). Their interconnects are characterized by energy (battery power). Their interconnects are characterized by
high loss rates, low data rates, and instability. LLNs are comprised high loss rates, low data rates, and instability. LLNs are comprised
of anything from a few dozen and up to thousands of routers. of anything from a few dozen and up to thousands of routers.
Supported traffic flows include point-to-point (between devices Supported traffic flows include point-to-point (between devices
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 April 4, 2011. This Internet-Draft will expire on April 25, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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 6, line 12 skipping to change at page 6, line 12
17.4.2. Destination Oriented Directed Acyclic Graph (DAG) 17.4.2. Destination Oriented Directed Acyclic Graph (DAG)
Table . . . . . . . . . . . . . . . . . . . . . . . . 116 Table . . . . . . . . . . . . . . . . . . . . . . . . 116
17.4.3. Routing Table and DAO Routing Entries . . . . . . . . 117 17.4.3. Routing Table and DAO Routing Entries . . . . . . . . 117
17.5. Fault Management . . . . . . . . . . . . . . . . . . . . 118 17.5. Fault Management . . . . . . . . . . . . . . . . . . . . 118
17.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 118 17.6. Policy . . . . . . . . . . . . . . . . . . . . . . . . . 118
17.7. Liveness Detection and Monitoring . . . . . . . . . . . 119 17.7. Liveness Detection and Monitoring . . . . . . . . . . . 119
17.8. Fault Isolation . . . . . . . . . . . . . . . . . . . . 120 17.8. Fault Isolation . . . . . . . . . . . . . . . . . . . . 120
17.9. Impact on Other Protocols . . . . . . . . . . . . . . . 120 17.9. Impact on Other Protocols . . . . . . . . . . . . . . . 120
17.10. Performance Management . . . . . . . . . . . . . . . . . 120 17.10. Performance Management . . . . . . . . . . . . . . . . . 120
17.11. Diagnostics . . . . . . . . . . . . . . . . . . . . . . 121
18. Security Considerations . . . . . . . . . . . . . . . . . . . 122 18. Security Considerations . . . . . . . . . . . . . . . . . . . 122
18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 122 18.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 122
19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124
19.1. RPL Control Message . . . . . . . . . . . . . . . . . . 124 19.1. RPL Control Message . . . . . . . . . . . . . . . . . . 124
19.2. New Registry for RPL Control Codes . . . . . . . . . . . 124 19.2. New Registry for RPL Control Codes . . . . . . . . . . . 124
19.3. New Registry for the Mode of Operation (MOP) DIO 19.3. New Registry for the Mode of Operation (MOP) DIO
Control Field . . . . . . . . . . . . . . . . . . . . . 125 Control Field . . . . . . . . . . . . . . . . . . . . . 125
19.4. RPL Control Message Option . . . . . . . . . . . . . . . 126 19.4. RPL Control Message Option . . . . . . . . . . . . . . . 126
19.5. Objective Code Point (OCP) Registry . . . . . . . . . . 126 19.5. Objective Code Point (OCP) Registry . . . . . . . . . . 126
19.6. New Registry for the Security Section Algorithm . . . . 127 19.6. New Registry for the Security Section Algorithm . . . . 127
skipping to change at page 77, line 12 skipping to change at page 77, line 12
2. A node SHOULD delay sending a DAO message with a timer 2. A node SHOULD delay sending a DAO message with a timer
(DelayDAO). Receiving a DAO message starts the DelayDAO timer. (DelayDAO). Receiving a DAO message starts the DelayDAO timer.
DAO messages received while the DelayDAO timer is active do not DAO messages received while the DelayDAO timer is active do not
reset the timer. When the DelayDAO timer expires, the node sends reset the timer. When the DelayDAO timer expires, the node sends
a DAO. a DAO.
3. When a node adds a node to its DAO parent set, it SHOULD schedule 3. When a node adds a node to its DAO parent set, it SHOULD schedule
a DAO message transmission. a DAO message transmission.
DelayDAO's value and calculation is implementation-dependent. DelayDAO's value and calculation is implementation-dependent. A
default value of DEFAULT_DAO_DELAY is defined in this specification.
9.5. Triggering DAO Messages 9.5. Triggering DAO Messages
Nodes can trigger their sub-DODAG to send DAO messages. Each node Nodes can trigger their sub-DODAG to send DAO messages. Each node
maintains a DAO Trigger Sequence Number (DTSN), which it communicates maintains a DAO Trigger Sequence Number (DTSN), which it communicates
through DIO messages. through DIO messages.
1. If a node hears one of its DAO parents increment its DTSN, the 1. If a node hears one of its DAO parents increment its DTSN, the
node MUST schedule a DAO message transmission using rules in node MUST schedule a DAO message transmission using rules in
Section 9.3 and Section 9.4. Section 9.3 and Section 9.4.
skipping to change at page 107, line 5 skipping to change at page 107, line 5
configure k for the DIO trickle timer. configure k for the DIO trickle timer.
DEFAULT_DIO_REDUNDANCY_CONSTANT has a value of 10. This DEFAULT_DIO_REDUNDANCY_CONSTANT has a value of 10. This
configuration is a conservative value for trickle suppression configuration is a conservative value for trickle suppression
mechanism. mechanism.
DEFAULT_MIN_HOP_RANK_INCREASE This is the default value of DEFAULT_MIN_HOP_RANK_INCREASE This is the default value of
MinHopRankIncrease. DEFAULT_MIN_HOP_RANK_INCREASE has a value MinHopRankIncrease. DEFAULT_MIN_HOP_RANK_INCREASE has a value
of 256. This configuration results in an 8-bit wide integer of 256. This configuration results in an 8-bit wide integer
part of Rank. part of Rank.
DEFAULT_DAO_DELAY This is the default value for the DelayDAO Timer.
DEFAULT_DAO_DELAY has value of 1 second. See Section 9.4.
DIO Timer One instance per DODAG that a node is a member of. Expiry DIO Timer One instance per DODAG that a node is a member of. Expiry
triggers DIO message transmission. Trickle timer with variable triggers DIO message transmission. Trickle timer with variable
interval in [0, DIOIntervalMin..2^DIOIntervalDoublings]. See interval in [0, DIOIntervalMin..2^DIOIntervalDoublings]. See
Section 8.3.1 Section 8.3.1
DAG Version Increment Timer Up to one instance per DODAG that the DAG Version Increment Timer Up to one instance per DODAG that the
node is acting as DODAG root of. May not be supported in all node is acting as DODAG root of. May not be supported in all
implementations. Expiry triggers increment of implementations. Expiry triggers increment of
DODAGVersionNumber, causing a new series of updated DIO message DODAGVersionNumber, causing a new series of updated DIO message
to be sent. Interval should be chosen appropriate to to be sent. Interval should be chosen appropriate to
skipping to change at page 112, line 41 skipping to change at page 112, line 41
configuration at the DODAG root to refresh the DODAG states by configuration at the DODAG root to refresh the DODAG states by
updating the DODAGVersionNumber. A RPL implementation SHOULD allow updating the DODAGVersionNumber. A RPL implementation SHOULD allow
configuring whether or not periodic or event triggered mechanisms are configuring whether or not periodic or event triggered mechanisms are
used by the DODAG root to control DODAGVersionNumber change (which used by the DODAG root to control DODAGVersionNumber change (which
triggers a global repair as specified in Section 3.3.2. triggers a global repair as specified in Section 3.3.2.
17.2.6. Configuration of RPL Parameters related to DAO-based mechanisms 17.2.6. Configuration of RPL Parameters related to DAO-based mechanisms
DAO messages are optional and used in DODAGs that require downward DAO messages are optional and used in DODAGs that require downward
routing operation. This section deals with the set of parameters routing operation. This section deals with the set of parameters
related to DAO message and provides recommendations on their related to DAO messages and provides recommendations on their
configuration. configuration.
As stated in Section 9.4, it is recommended to delay the sending of As stated in Section 9.4, it is recommended to delay the sending of
DAO message to DAO parents in order to maximize the chances to DAO message to DAO parents in order to maximize the chances to
perform route aggregation. Upon receiving a DAO message, the node perform route aggregation. Upon receiving a DAO message, the node
should thus start a DelayDAO timer. A RPL implementation MAY allow should thus start a DelayDAO timer. The default value is
for configuring the DelayDAO timer. DEFAULT_DAO_DELAY. A RPL implementation MAY allow for configuring
the DelayDAO timer.
In a storing mode of operation, a storing node may increment DTSN in In a storing mode of operation, a storing node may increment DTSN in
order to reliably trigger a set of DAO updates from its immediate order to reliably trigger a set of DAO updates from its immediate
children, as part of routine routing table updates and maintenance. children, as part of routine routing table updates and maintenance.
A RPL implementation MAY allow for configuring a set of rules A RPL implementation MAY allow for configuring a set of rules
specifying the triggers for DTSN increment (manual or event-based). specifying the triggers for DTSN increment (manual or event-based).
When a DAO entry times out or is invalidated, a node SHOULD make a When a DAO entry times out or is invalidated, a node SHOULD make a
reasonable attempt to report a No-Path to each of the DAO parents. reasonable attempt to report a No-Path to each of the DAO parents.
That number of attempts MAY be configurable. That number of attempts MAY be configurable.
An implementation should support rate-limiting the sending of DAO An implementation should support rate-limiting the sending of DAO
messages. The related parameters MAY be configurable. messages. The related parameters MAY be configurable.
skipping to change at page 114, line 14 skipping to change at page 114, line 14
17.2.8. Default Values 17.2.8. Default Values
This document specifies default values for the following set of RPL This document specifies default values for the following set of RPL
variables: variables:
DEFAULT_PATH_CONTROL_SIZE DEFAULT_PATH_CONTROL_SIZE
DEFAULT_DIO_INTERVAL_MIN DEFAULT_DIO_INTERVAL_MIN
DEFAULT_DIO_INTERVAL_DOUBLINGS DEFAULT_DIO_INTERVAL_DOUBLINGS
DEFAULT_DIO_REDUNDANCY_CONSTANT DEFAULT_DIO_REDUNDANCY_CONSTANT
DEFAULT_MIN_HOP_RANK_INCREASE DEFAULT_MIN_HOP_RANK_INCREASE
DEFAULT_DAO_DELAY
It is recommended to specify default values in protocols; that being It is recommended to specify default values in protocols; that being
said, as discussed in [RFC5706], default values may make less and said, as discussed in [RFC5706], default values may make less and
less sense. RPL is a routing protocol that is expected to be used in less sense. RPL is a routing protocol that is expected to be used in
a number of contexts where network characteristics such as the number a number of contexts where network characteristics such as the number
of nodes, link and nodes types are expected to vary significantly. of nodes, link and nodes types are expected to vary significantly.
Thus, these default values are likely to change with the context and Thus, these default values are likely to change with the context and
as the technology will evolve. Indeed, LLNs' related technology as the technology will evolve. Indeed, LLNs' related technology
(e.g. hardware, link layers) have been evolving dramatically over the (e.g. hardware, link layers) have been evolving dramatically over the
past few years and such technologies are expected to change and past few years and such technologies are expected to change and
skipping to change at page 116, line 13 skipping to change at page 116, line 13
o Number of packets with the 'F' bit set o Number of packets with the 'F' bit set
o Number of packets with the 'R' bit set o Number of packets with the 'R' bit set
17.4. Monitoring of the RPL data structures 17.4. Monitoring of the RPL data structures
17.4.1. Candidate Neighbor Data Structure 17.4.1. Candidate Neighbor Data Structure
A node in the candidate neighbor list is a node discovered by the A node in the candidate neighbor list is a node discovered by the
some means and qualified to potentially become a parent (with high some means and qualified to potentially become a parent (with high
enough local confidence). A RPL implementation SHOULD provide a way enough local confidence). A RPL implementation SHOULD provide a way
to monitor the candidate neighbor list with some metric reflecting to allow for the candidate neighbor list to be monitored with some
local confidence (the degree of stability of the neighbors) as metric reflecting local confidence (the degree of stability of the
measured by some metrics. neighbors) as measured by some metrics.
A RPL implementation MAY provide a counter reporting the number of A RPL implementation MAY provide a counter reporting the number of
times a candidate neighbor has been ignored, should the number of times a candidate neighbor has been ignored, should the number of
candidate neighbors exceeds the maximum authorized value. candidate neighbors exceeds the maximum authorized value.
17.4.2. Destination Oriented Directed Acyclic Graph (DAG) Table 17.4.2. Destination Oriented Directed Acyclic Graph (DAG) Table
For each DODAG, a RPL implementation is expected to keep track of the For each DODAG, a RPL implementation is expected to keep track of the
following DODAG table values: following DODAG table values:
skipping to change at page 117, line 15 skipping to change at page 117, line 15
17.4.3. Routing Table and DAO Routing Entries 17.4.3. Routing Table and DAO Routing Entries
A RPL implementation maintains several information elements related A RPL implementation maintains several information elements related
to the DODAG and the DAO entries (for storing nodes). In the case of to the DODAG and the DAO entries (for storing nodes). In the case of
a non storing node, a limited amount of information is maintained a non storing node, a limited amount of information is maintained
(the routing table is mostly reduced to a set of DODAG parents along (the routing table is mostly reduced to a set of DODAG parents along
with characteristics of the DODAG as mentioned above) whereas in the with characteristics of the DODAG as mentioned above) whereas in the
case of storing nodes, this information is augmented with routing case of storing nodes, this information is augmented with routing
entries. entries.
A RPL implementation SHOULD provide the ability to monitor the A RPL implementation SHOULD allow for the following parameters to be
following parameters: monitored:
o Next Hop (DODAG parent) o Next Hop (DODAG parent)
o Next Hop Interface o Next Hop Interface
o Path metrics value for each DODAG parent o Path metrics value for each DODAG parent
A DAO Routing Table Entry conceptually contains the following A DAO Routing Table Entry conceptually contains the following
elements (for storing nodes only): elements (for storing nodes only):
skipping to change at page 122, line 5 skipping to change at page 121, line 7
o Number of times and duration during which a devices could not o Number of times and duration during which a devices could not
forward a packet because of a lack of reachable neighbor in its forward a packet because of a lack of reachable neighbor in its
routing table routing table
o Monitoring of resources consumption by RPL in terms of bandwidth o Monitoring of resources consumption by RPL in terms of bandwidth
and required memory and required memory
o Number of RPL control messages sent and received o Number of RPL control messages sent and received
17.11. Diagnostics
There may be situations where a node should be placed in "verbose"
mode to improve diagnostics. Thus a RPL implementation SHOULD
provide the ability to place a node in and out of verbose mode in
order to get additional diagnostic information.
18. Security Considerations 18. Security Considerations
18.1. Overview 18.1. Overview
From a security perspective, RPL networks are no different from any From a security perspective, RPL networks are no different from any
other network. They are vulnerable to passive eavesdropping attacks other network. They are vulnerable to passive eavesdropping attacks
and potentially even active tampering when physical access to a wire and potentially even active tampering when physical access to a wire
is not required to participate in communications. The very nature of is not required to participate in communications. The very nature of
ad hoc networks and their cost objectives impose additional security ad hoc networks and their cost objectives impose additional security
constraints, which perhaps make these networks the most difficult constraints, which perhaps make these networks the most difficult
skipping to change at page 137, line 25 skipping to change at page 137, line 25
[I-D.ietf-6man-rpl-routing-header] [I-D.ietf-6man-rpl-routing-header]
Hui, J., Vasseur, J., and D. Culler, "An IPv6 Routing Hui, J., Vasseur, J., and D. Culler, "An IPv6 Routing
Header for Source Routes with RPL", Header for Source Routes with RPL",
draft-ietf-6man-rpl-routing-header-00 (work in progress), draft-ietf-6man-rpl-routing-header-00 (work in progress),
July 2010. July 2010.
[I-D.ietf-roll-routing-metrics] [I-D.ietf-roll-routing-metrics]
Vasseur, J., Kim, M., Networks, D., Dejean, N., and D. Vasseur, J., Kim, M., Networks, D., Dejean, N., and D.
Barthel, "Routing Metrics used for Path Calculation in Low Barthel, "Routing Metrics used for Path Calculation in Low
Power and Lossy Networks", Power and Lossy Networks",
draft-ietf-roll-routing-metrics-09 (work in progress), draft-ietf-roll-routing-metrics-10 (work in progress),
September 2010. October 2010.
[I-D.ietf-roll-trickle] [I-D.ietf-roll-trickle]
Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", draft-ietf-roll-trickle-04 (work "The Trickle Algorithm", draft-ietf-roll-trickle-04 (work
in progress), August 2010. in progress), August 2010.
[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.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
 End of changes. 15 change blocks. 
16 lines changed or deleted 29 lines changed or added

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