draft-ietf-roll-rpl-06.txt   draft-ietf-roll-rpl-07.txt 
Networking Working Group T. Winter, Ed. Networking Working Group T. Winter, Ed.
Internet-Draft Internet-Draft
Intended status: Standards Track P. Thubert, Ed. Intended status: Standards Track P. Thubert, Ed.
Expires: August 7, 2010 Cisco Systems Expires: September 9, 2010 Cisco Systems
ROLL Design Team ROLL Design Team
IETF ROLL WG IETF ROLL WG
February 03, 2010 March 8, 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-06 draft-ietf-roll-rpl-07
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 (any subset of) processing typically operate with constraints on (any subset of) processing
power, memory and energy (battery), and their interconnects are power, memory and energy (battery), and their interconnects are
characterized by (any subset of) high loss rates, low data rates and characterized by (any subset of) high loss rates, low data rates and
instability. LLNs are comprised of anything from a few dozen and up instability. LLNs are comprised of anything from a few dozen and up
to thousands of LLN routers, and support point-to-point traffic to thousands of LLN routers, and support point-to-point traffic
skipping to change at page 2, line 8 skipping to change at page 2, line 8
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 7, 2010. This Internet-Draft will expire on September 9, 2010.
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 3, line 21 skipping to change at page 3, line 21
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Topology Identifiers . . . . . . . . . . . . . . . . . 9 3.1.1. Topology Identifiers . . . . . . . . . . . . . . . . . 9
3.1.2. DODAG Information . . . . . . . . . . . . . . . . . . 10 3.1.2. DODAG Information . . . . . . . . . . . . . . . . . . 10
3.2. Instances, DODAGs, and DODAG Iterations . . . . . . . . . 11 3.2. Instances, DODAGs, and DODAG Iterations . . . . . . . . . 11
3.3. Traffic Flows . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Traffic Flows . . . . . . . . . . . . . . . . . . . . . . 13
3.3.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . 13 3.3.1. Multipoint-to-Point Traffic . . . . . . . . . . . . . 13
3.3.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . 13 3.3.2. Point-to-Multipoint Traffic . . . . . . . . . . . . . 13
3.3.3. Point-to-Point Traffic . . . . . . . . . . . . . . . . 13 3.3.3. Point-to-Point Traffic . . . . . . . . . . . . . . . . 13
3.4. Upward Routes and DODAG Construction . . . . . . . . . . . 13 3.4. Upward Routes and DODAG Construction . . . . . . . . . . . 13
3.4.1. DAG Information Object (DIO) . . . . . . . . . . . . . 14 3.4.1. DODAG Information Object (DIO) . . . . . . . . . . . . 14
3.4.2. DAG Repair . . . . . . . . . . . . . . . . . . . . . . 14 3.4.2. DAG Repair . . . . . . . . . . . . . . . . . . . . . . 14
3.4.3. Grounded and Floating DODAGs . . . . . . . . . . . . . 15 3.4.3. Grounded and Floating DODAGs . . . . . . . . . . . . . 15
3.4.4. Administrative Preference . . . . . . . . . . . . . . 15 3.4.4. Administrative Preference . . . . . . . . . . . . . . 15
3.4.5. Objective Function (OF) . . . . . . . . . . . . . . . 15 3.4.5. Objective Function (OF) . . . . . . . . . . . . . . . 15
3.4.6. Distributed Algorithm Operation . . . . . . . . . . . 15 3.4.6. Distributed Algorithm Operation . . . . . . . . . . . 15
3.5. Downward Routes and Destination Advertisement . . . . . . 16 3.5. Downward Routes and Destination Advertisement . . . . . . 16
3.5.1. Destination Advertisement Object (DAO) . . . . . . . . 16 3.5.1. Destination Advertisement Object (DAO) . . . . . . . . 16
3.6. Routing Metrics and Constraints Used By RPL . . . . . . . 17 3.6. Routing Metrics and Constraints Used By RPL . . . . . . . 17
3.6.1. Loop Avoidance . . . . . . . . . . . . . . . . . . . . 18 3.6.1. Loop Avoidance . . . . . . . . . . . . . . . . . . . . 18
3.6.2. Rank Properties . . . . . . . . . . . . . . . . . . . 19 3.6.2. Rank Properties . . . . . . . . . . . . . . . . . . . 19
skipping to change at page 3, line 47 skipping to change at page 3, line 47
5.1.3. DIO Suboptions . . . . . . . . . . . . . . . . . . . . 25 5.1.3. DIO Suboptions . . . . . . . . . . . . . . . . . . . . 25
5.2. DODAG Information Solicitation (DIS) . . . . . . . . . . . 30 5.2. DODAG Information Solicitation (DIS) . . . . . . . . . . . 30
5.3. Upward Route Discovery and Maintenance . . . . . . . . . . 30 5.3. Upward Route Discovery and Maintenance . . . . . . . . . . 30
5.3.1. RPL Instance . . . . . . . . . . . . . . . . . . . . . 30 5.3.1. RPL Instance . . . . . . . . . . . . . . . . . . . . . 30
5.3.2. Neighbors and Parents within a DODAG Iteration . . . . 30 5.3.2. Neighbors and Parents within a DODAG Iteration . . . . 30
5.3.3. Neighbors and Parents across DODAG Iterations . . . . 31 5.3.3. Neighbors and Parents across DODAG Iterations . . . . 31
5.3.4. DIO Message Communication . . . . . . . . . . . . . . 36 5.3.4. DIO Message Communication . . . . . . . . . . . . . . 36
5.3.5. DIO Transmission . . . . . . . . . . . . . . . . . . . 36 5.3.5. DIO Transmission . . . . . . . . . . . . . . . . . . . 36
5.3.6. DODAG Selection . . . . . . . . . . . . . . . . . . . 39 5.3.6. DODAG Selection . . . . . . . . . . . . . . . . . . . 39
5.4. Operation as a Leaf Node . . . . . . . . . . . . . . . . . 39 5.4. Operation as a Leaf Node . . . . . . . . . . . . . . . . . 39
5.5. Administrative Rank . . . . . . . . . . . . . . . . . . . 39 5.5. Administrative Rank . . . . . . . . . . . . . . . . . . . 40
5.6. Collision . . . . . . . . . . . . . . . . . . . . . . . . 40 5.6. Collision . . . . . . . . . . . . . . . . . . . . . . . . 40
6. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 40 6. Downward Routes . . . . . . . . . . . . . . . . . . . . . . . 40
6.1. Destination Advertisement Object (DAO) . . . . . . . . . . 40 6.1. Destination Advertisement Object (DAO) . . . . . . . . . . 41
6.1.1. DAO Suboptions . . . . . . . . . . . . . . . . . . . . 42 6.1.1. DAO Suboptions . . . . . . . . . . . . . . . . . . . . 42
6.2. Downward Route Discovery and Maintenance . . . . . . . . . 42 6.2. Downward Route Discovery and Maintenance . . . . . . . . . 43
6.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 42 6.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 43
6.2.2. Mode of Operation . . . . . . . . . . . . . . . . . . 43 6.2.2. Mode of Operation . . . . . . . . . . . . . . . . . . 44
6.2.3. Destination Advertisement Parents . . . . . . . . . . 44 6.2.3. Destination Advertisement Parents . . . . . . . . . . 44
6.2.4. Operation of DAO Storing Nodes . . . . . . . . . . . . 45 6.2.4. Operation of DAO Storing Nodes . . . . . . . . . . . . 45
6.2.5. Operation of DAO Non-storing Nodes . . . . . . . . . . 48 6.2.5. Operation of DAO Non-storing Nodes . . . . . . . . . . 48
6.2.6. Scheduling to Send DAO (or no-DAO) . . . . . . . . . . 48 6.2.6. Scheduling to Send DAO (or no-DAO) . . . . . . . . . . 49
6.2.7. Triggering DAO Message from the Sub-DODAG . . . . . . 49 6.2.7. Triggering DAO Message from the Sub-DODAG . . . . . . 49
6.2.8. Sending DAO Messages to DAO Parents . . . . . . . . . 50 6.2.8. Sending DAO Messages to DAO Parents . . . . . . . . . 51
6.2.9. Multicast Destination Advertisement Messages . . . . . 51 6.2.9. Multicast Destination Advertisement Messages . . . . . 52
7. Packet Forwarding and Loop Avoidance/Detection . . . . . . . . 51 7. Packet Forwarding and Loop Avoidance/Detection . . . . . . . . 52
7.1. Suggestions for Packet Forwarding . . . . . . . . . . . . 51 7.1. Suggestions for Packet Forwarding . . . . . . . . . . . . 53
7.2. Loop Avoidance and Detection . . . . . . . . . . . . . . . 52 7.2. Loop Avoidance and Detection . . . . . . . . . . . . . . . 54
7.2.1. Source Node Operation . . . . . . . . . . . . . . . . 53 7.2.1. Source Node Operation . . . . . . . . . . . . . . . . 55
7.2.2. Router Operation . . . . . . . . . . . . . . . . . . . 54 7.2.2. Router Operation . . . . . . . . . . . . . . . . . . . 55
8. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 56 8. Multicast Operation . . . . . . . . . . . . . . . . . . . . . 57
9. Maintenance of Routing Adjacency . . . . . . . . . . . . . . . 57 9. Maintenance of Routing Adjacency . . . . . . . . . . . . . . . 58
10. Guidelines for Objective Functions . . . . . . . . . . . . . . 58 10. Guidelines for Objective Functions . . . . . . . . . . . . . . 59
11. RPL Constants and Variables . . . . . . . . . . . . . . . . . 60 11. RPL Constants and Variables . . . . . . . . . . . . . . . . . 61
12. Manageability Considerations . . . . . . . . . . . . . . . . . 61 12. Manageability Considerations . . . . . . . . . . . . . . . . . 62
12.1. Control of Function and Policy . . . . . . . . . . . . . . 61 12.1. Control of Function and Policy . . . . . . . . . . . . . . 62
12.1.1. Initialization Mode . . . . . . . . . . . . . . . . . 61 12.1.1. Initialization Mode . . . . . . . . . . . . . . . . . 62
12.1.2. DIO Base option . . . . . . . . . . . . . . . . . . . 62 12.1.2. DIO Base option . . . . . . . . . . . . . . . . . . . 63
12.1.3. Trickle Timers . . . . . . . . . . . . . . . . . . . . 62 12.1.3. Trickle Timers . . . . . . . . . . . . . . . . . . . . 63
12.1.4. DAG Sequence Number Increment . . . . . . . . . . . . 63 12.1.4. DAG Sequence Number Increment . . . . . . . . . . . . 64
12.1.5. Destination Advertisement Timers . . . . . . . . . . . 63 12.1.5. Destination Advertisement Timers . . . . . . . . . . . 64
12.1.6. Policy Control . . . . . . . . . . . . . . . . . . . . 63 12.1.6. Policy Control . . . . . . . . . . . . . . . . . . . . 64
12.1.7. Data Structures . . . . . . . . . . . . . . . . . . . 63 12.1.7. Data Structures . . . . . . . . . . . . . . . . . . . 65
12.2. Information and Data Models . . . . . . . . . . . . . . . 64 12.2. Information and Data Models . . . . . . . . . . . . . . . 65
12.3. Liveness Detection and Monitoring . . . . . . . . . . . . 64 12.3. Liveness Detection and Monitoring . . . . . . . . . . . . 65
12.3.1. Candidate Neighbor Data Structure . . . . . . . . . . 64 12.3.1. Candidate Neighbor Data Structure . . . . . . . . . . 65
12.3.2. Directed Acyclic Graph (DAG) Table . . . . . . . . . . 64 12.3.2. Directed Acyclic Graph (DAG) Table . . . . . . . . . . 65
12.3.3. Routing Table . . . . . . . . . . . . . . . . . . . . 65 12.3.3. Routing Table . . . . . . . . . . . . . . . . . . . . 66
12.3.4. Other RPL Monitoring Parameters . . . . . . . . . . . 65 12.3.4. Other RPL Monitoring Parameters . . . . . . . . . . . 67
12.3.5. RPL Trickle Timers . . . . . . . . . . . . . . . . . . 66 12.3.5. RPL Trickle Timers . . . . . . . . . . . . . . . . . . 67
12.4. Verifying Correct Operation . . . . . . . . . . . . . . . 66 12.4. Verifying Correct Operation . . . . . . . . . . . . . . . 67
12.5. Requirements on Other Protocols and Functional 12.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 66 Components . . . . . . . . . . . . . . . . . . . . . . . . 67
12.6. Impact on Network Operation . . . . . . . . . . . . . . . 66 12.6. Impact on Network Operation . . . . . . . . . . . . . . . 67
13. Security Considerations . . . . . . . . . . . . . . . . . . . 66 13. Security Considerations . . . . . . . . . . . . . . . . . . . 67
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67
14.1. RPL Control Message . . . . . . . . . . . . . . . . . . . 66 14.1. RPL Control Message . . . . . . . . . . . . . . . . . . . 68
14.2. New Registry for RPL Control Codes . . . . . . . . . . . . 67 14.2. New Registry for RPL Control Codes . . . . . . . . . . . . 68
14.3. New Registry for the Control Field of the DIO Base . . . . 67 14.3. New Registry for the Control Field of the DIO Base . . . . 68
14.4. DAG Information Object (DIO) Suboption . . . . . . . . . . 68 14.4. DODAG Information Object (DIO) Suboption . . . . . . . . . 69
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 68 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 69
16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 69 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 70
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71
17.1. Normative References . . . . . . . . . . . . . . . . . . . 70 17.1. Normative References . . . . . . . . . . . . . . . . . . . 71
17.2. Informative References . . . . . . . . . . . . . . . . . . 70 17.2. Informative References . . . . . . . . . . . . . . . . . . 72
Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 72 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 74
A.1. Protocol Properties Overview . . . . . . . . . . . . . . . 72 A.1. Protocol Properties Overview . . . . . . . . . . . . . . . 74
A.1.1. IPv6 Architecture . . . . . . . . . . . . . . . . . . 72 A.1.1. IPv6 Architecture . . . . . . . . . . . . . . . . . . 74
A.1.2. Typical LLN Traffic Patterns . . . . . . . . . . . . . 73 A.1.2. Typical LLN Traffic Patterns . . . . . . . . . . . . . 74
A.1.3. Constraint Based Routing . . . . . . . . . . . . . . . 73 A.1.3. Constraint Based Routing . . . . . . . . . . . . . . . 74
A.2. Deferred Requirements . . . . . . . . . . . . . . . . . . 73 A.2. Deferred Requirements . . . . . . . . . . . . . . . . . . 75
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 74 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 75
B.1. Destination Advertisement . . . . . . . . . . . . . . . . 75 B.1. DAO Operation When Only the Root Node Stores DAO
B.2. Example: DODAG Parent Selection . . . . . . . . . . . . . 76 Information . . . . . . . . . . . . . . . . . . . . . . . 75
B.3. Example: DODAG Maintenance . . . . . . . . . . . . . . . . 78 B.2. DAO Operation When All Nodes Fully Store DAO
B.4. Example: Greedy Parent Selection and Instability . . . . . 79 Information . . . . . . . . . . . . . . . . . . . . . . . 77
B.3. DAO Operation When Nodes Have Mixed Capabilities . . . . . 79
Appendix C. Outstanding Issues . . . . . . . . . . . . . . . . . 81 Appendix C. Outstanding Issues . . . . . . . . . . . . . . . . . 81
C.1. Additional Support for P2P Routing . . . . . . . . . . . . 81 C.1. Additional Support for P2P Routing . . . . . . . . . . . . 81
C.2. Destination Advertisement / DAO Fan-out . . . . . . . . . 81 C.2. Destination Advertisement / DAO Fan-out . . . . . . . . . 81
C.3. Source Routing . . . . . . . . . . . . . . . . . . . . . . 81 C.3. Source Routing . . . . . . . . . . . . . . . . . . . . . . 81
C.4. Address / Header Compression . . . . . . . . . . . . . . . 82 C.4. Address / Header Compression . . . . . . . . . . . . . . . 81
C.5. Managing Multiple Instances . . . . . . . . . . . . . . . 82 C.5. Managing Multiple Instances . . . . . . . . . . . . . . . 82
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82
1. Introduction 1. Introduction
Low power and Lossy Networks (LLNs) consist of largely of constrained Low power and Lossy Networks (LLNs) consist of largely of constrained
nodes (with limited processing power, memory, and sometimes energy nodes (with limited processing power, memory, and sometimes energy
when they are battery operated). These routers are interconnected by when they are battery operated). These routers are interconnected by
lossy links, typically supporting only low data rates, that are lossy links, typically supporting only low data rates, that are
usually unstable with relatively low packet delivery rates. Another usually unstable with relatively low packet delivery rates. Another
skipping to change at page 10, line 28 skipping to change at page 10, line 28
and DODAGSequenceNumber uniquely identifies a DODAG Iteration. and DODAGSequenceNumber uniquely identifies a DODAG Iteration.
o The fourth is rank. The scope of rank is a DODAG Iteration. Rank o The fourth is rank. The scope of rank is a DODAG Iteration. Rank
establishes a partial order over a DODAG Iteration, defining establishes a partial order over a DODAG Iteration, defining
individual node positions with respect to the DODAG root. individual node positions with respect to the DODAG root.
3.1.2. DODAG Information 3.1.2. DODAG Information
For each DODAG that a node is, or may become, a member of, the For each DODAG that a node is, or may become, a member of, the
implementation should conceptually keep track of the following implementation should conceptually keep track of the following
information for each DODAG. The data structures described in this information. The data structures described in this section are
section are intended to illustrate a possible implementation to aid intended to illustrate a possible implementation to aid in the
in the description of the protocol, but are not intended to be description of the protocol, but are not intended to be normative.
normative.
o RPLInstanceID o RPLInstanceID
o DODAGID o DODAGID
o DODAGSequenceNumber o DODAGSequenceNumber
o DAG Metric Container, including DAGObjectiveCodePoint o DAG Metric Container, including DAGObjectiveCodePoint
o A set of Destination Prefixes offered by the DODAG root and o A set of Destination Prefixes offered by the DODAG root and
available via paths upwards along the DODAG available via paths upwards along the DODAG
o A set of DODAG parents o A set of DODAG parents
o A set of DODAG siblings o A set of DODAG siblings
o A timer to govern the sending of DIO messages o A timer to govern the sending of RPL control messages
3.2. Instances, DODAGs, and DODAG Iterations 3.2. Instances, DODAGs, and DODAG Iterations
Each RPL Instance constructs a routing topology optimized for a Each RPL Instance constructs a routing topology optimized for a
certain Objective Function (OF). A RPL Instance may provide routes certain Objective Function (OF). A RPL Instance may provide routes
to certain destination prefixes, reachable via the DODAG roots. A to certain destination prefixes, reachable via the DODAG roots. A
single RPL Instance contains one or more Destination Oriented DAG single RPL Instance contains one or more Destination Oriented DAG
(DODAG) roots. These roots may operate independently, or may (DODAG) roots. These roots may operate independently, or may
coordinate over a non-LLN backchannel. coordinate over a non-LLN backchannel.
skipping to change at page 11, line 40 skipping to change at page 11, line 40
the formation of multiple DODAGs as a means to dynamically and the formation of multiple DODAGs as a means to dynamically and
autonomously partition the network. autonomously partition the network.
o a single DODAG with a single virtual root coordinating LLN sinks o a single DODAG with a single virtual root coordinating LLN sinks
(with the same DODAGID) over some non-LLN backbone (with the same DODAGID) over some non-LLN backbone
* For example, multiple border routers operating with a reliable * For example, multiple border routers operating with a reliable
backbone, e.g. in support of a 6LowPAN application, that are backbone, e.g. in support of a 6LowPAN application, that are
capable to act as logically equivalent sinks to the same DODAG. capable to act as logically equivalent sinks to the same DODAG.
o a combination of one of the above as suited to some application o a combination of the above as suited to some application scenario.
scenario.
Traffic is bound to a specific RPL Instance by a marking in the flow Traffic is bound to a specific RPL Instance by a marking in the flow
label of the IPv6 header. Traffic originating in support of a label of the IPv6 header. Traffic originating in support of a
particular application may be tagged to follow an appropriate RPL particular application may be tagged to follow an appropriate RPL
instance which enables certain (path) properties, for example to instance which enables certain (path) properties, for example to
follow paths optimized for low latency or low energy. The follow paths optimized for low latency or low energy. The
provisioning or automated discovery of a mapping between a provisioning or automated discovery of a mapping between a
RPLInstanceID and a type or service of application traffic is beyond RPLInstanceID and a type or service of application traffic is beyond
the scope of this specification. the scope of this specification.
skipping to change at page 14, line 5 skipping to change at page 14, line 5
3.4. Upward Routes and DODAG Construction 3.4. Upward Routes and DODAG Construction
RPL provisions routes up towards DODAG roots, forming a DODAG RPL provisions routes up towards DODAG roots, forming a DODAG
optimized according to the Objective Function (OF) in use. RPL nodes optimized according to the Objective Function (OF) in use. RPL nodes
construct and maintain these DODAGs through exchange of DODAG construct and maintain these DODAGs through exchange of DODAG
Information Object (DIO) messages. Undirected links between siblings Information Object (DIO) messages. Undirected links between siblings
are also identified during this process, which can be used to provide are also identified during this process, which can be used to provide
additional diversity. additional diversity.
3.4.1. DAG Information Object (DIO) 3.4.1. DODAG Information Object (DIO)
A DIO identifies the RPL Instance, the DODAGID, the values used to A DIO identifies the RPL Instance, the DODAGID, the values used to
compute the RPL Instance's objective function, and the present DODAG compute the RPL Instance's objective function, and the present DODAG
Sequence Number. It can also include additional routing and Sequence Number. It can also include additional routing and
configuration information. The DIO includes a measure derived from configuration information. The DIO includes a measure derived from
the position of the node within the DODAG, the rank, which is used the position of the node within the DODAG, the rank, which is used
for nodes to determine their positions relative to each other and to for nodes to determine their positions relative to each other and to
inform loop avoidance/detection procedures. RPL exchanges DIO inform loop avoidance/detection procedures. RPL exchanges DIO
messages to establish and maintain routes. messages to establish and maintain routes.
skipping to change at page 16, line 37 skipping to change at page 16, line 37
RPL constructs and maintains DODAGs with DIO messages to establish RPL constructs and maintains DODAGs with DIO messages to establish
upward routes: it uses Destination Advertisement Object (DAO) upward routes: it uses Destination Advertisement Object (DAO)
messages to establish downward routes along the DODAG as well as messages to establish downward routes along the DODAG as well as
other routes. DAO messages are an optional feature for applications other routes. DAO messages are an optional feature for applications
that require P2MP or P2P traffic. DIO messages advertise whether that require P2MP or P2P traffic. DIO messages advertise whether
destination advertisements are enabled within a given DODAG. destination advertisements are enabled within a given DODAG.
3.5.1. Destination Advertisement Object (DAO) 3.5.1. Destination Advertisement Object (DAO)
A Destination Advertisement Object (DAO) conveys destination A Destination Advertisement Object (DAO) conveys destination
information upwards along the DODAG so that a DODAG root (an other information upwards along the DODAG so that a DODAG root (and other
intermediate nodes) can provision downward routes. A DAO message intermediate nodes) can provision downward routes. A DAO message
includes prefix information to identify destinations, a capability to includes prefix information to identify destinations, a capability to
record routes in support of source routing, and information to record routes in support of source routing, and information to
determine the freshness of a particular advertisement. determine the freshness of a particular advertisement.
Nodes that are capable of maintaining routing state may aggregate Nodes that are capable of maintaining routing state may aggregate
routes from DAO messages that they receive before transmitting a DAO routes from DAO messages that they receive before transmitting a DAO
message. Nodes that are not capable of maintaining routing state may message. Nodes that are not capable of maintaining routing state may
attach a next-hop address to the Reverse Route Stack contained within attach a next-hop address to the Reverse Route Stack contained within
the DAO message. The Reverse Route Stack is subsequently used to the DAO message. The Reverse Route Stack is subsequently used to
skipping to change at page 18, line 30 skipping to change at page 18, line 30
3.6.1.1. Greediness and Rank-based Instabilities 3.6.1.1. Greediness and Rank-based Instabilities
Once a node has joined a DODAG iteration, RPL disallows certain Once a node has joined a DODAG iteration, RPL disallows certain
behaviors, including greediness, in order to prevent resulting behaviors, including greediness, in order to prevent resulting
instabilities in the DODAG iteration. instabilities in the DODAG iteration.
If a node is allowed to be greedy and attempts to move deeper in the If a node is allowed to be greedy and attempts to move deeper in the
DODAG iteration, beyond its most preferred parent, in order to DODAG iteration, beyond its most preferred parent, in order to
increase the size of the parent set, then an instability can result. increase the size of the parent set, then an instability can result.
This is illustrated in Figure 16.
Suppose a node is willing to receive and process a DIO messages from Suppose a node is willing to receive and process a DIO messages from
a node in its own sub-DODAG, and in general a node deeper than a node in its own sub-DODAG, and in general a node deeper than
itself. In this case, a possibility exists that a feedback loop is itself. In this case, a possibility exists that a feedback loop is
created, wherein two or more nodes continue to try and move in the created, wherein two or more nodes continue to try and move in the
DODAG iteration while attempting to optimize against each other. In DODAG iteration while attempting to optimize against each other. In
some cases, this will result in instability. It is for this reason some cases, this will result in instability. It is for this reason
that RPL limits the cases where a node may process DIO messages from that RPL limits the cases where a node may process DIO messages from
deeper nodes to some forms of local repair. This approach creates an deeper nodes to some forms of local repair. This approach creates an
'event horizon', whereby a node cannot be influenced beyond some 'event horizon', whereby a node cannot be influenced beyond some
limit into an instability by the action of nodes that may be in its limit into an instability by the action of nodes that may be in its
own sub-DODAG. own sub-DODAG.
A further example of the consequences of greedy operation, and
instability related to processing DIO messages from nodes of greater
rank, may be found in Appendix B.4
3.6.1.2. DODAG Loops 3.6.1.2. DODAG Loops
A DODAG loop may occur when a node detaches from the DODAG and A DODAG loop may occur when a node detaches from the DODAG and
reattaches to a device in its prior sub-DODAG. This may happen in reattaches to a device in its prior sub-DODAG. This may happen in
particular when DIO messages are missed. Strict use of the DAG particular when DIO messages are missed. Strict use of the DAG
sequence number can eliminate this type of loop, but this type of sequence number can eliminate this type of loop, but this type of
loop may possibly be encountered when using some local repair loop may possibly be encountered when using some local repair
mechanisms. mechanisms.
3.6.1.3. DAO Loops 3.6.1.3. DAO Loops
A DAO loop may occur when the parent has a route installed upon A DAO loop may occur when the parent has a route installed upon
receiving and processing a DAO message from a child, but the child receiving and processing a DAO message from a child, but the child
has subsequently cleaned up the state. This loop happens when a no- has subsequently cleaned up the related DAO state. This loop happens
DAO was missed and persists until all state has been cleaned up. RPL when a no-DAO was missed and persists until all state has been
includes loop detection mechanisms that may mitigate the impact of cleaned up. RPL includes loop detection mechanisms that may mitigate
DAO loops and trigger their repair. the impact of DAO loops and trigger their repair.
In the case where stateless DAO operation is used, i.e. source In the case where stateless DAO operation is used, i.e. source
routing specifies the down routes, then DAO Loops should not occur on routing specifies the down routes, then DAO Loops should not occur on
the stateless portions of the path. the stateless portions of the path.
3.6.1.4. Sibling Loops 3.6.1.4. Sibling Loops
Sibling loops could occur if a group of siblings kept choosing Sibling loops could occur if a group of siblings kept choosing
amongst themselves as successors such that a packet does not make amongst themselves as successors such that a packet does not make
forward progress. This specification limits the number of times that forward progress. This specification limits the number of times that
skipping to change at page 20, line 22 skipping to change at page 20, line 17
Granularity: Rank is coarse grained. A fine granularity would Granularity: Rank is coarse grained. A fine granularity would
prevent the selection of siblings. prevent the selection of siblings.
Properties: Rank is strictly monotonic, and can be used to validate Properties: Rank is strictly monotonic, and can be used to validate
a progression from or towards the root. A metric, like a progression from or towards the root. A metric, like
bandwidth or jitter, does not necessarily exhibit this bandwidth or jitter, does not necessarily exhibit this
property. property.
Abstract: Rank does not have a physical unit, but rather a range of Abstract: Rank does not have a physical unit, but rather a range of
increment per hop that varies from 1 (best) to 16 (worst), increment per hop, where the assignment of each increment is
where the assignment of each value is to be determined by the to be determined by the implementation.
implementation.
The rank value feeds into DODAG parent selection, according to the The rank value feeds into DODAG parent selection, according to the
RPL loop-avoidance strategy. Once a parent has been added, and a RPL loop-avoidance strategy. Once a parent has been added, and a
rank value for the node within the DODAG has been advertised, the rank value for the node within the DODAG has been advertised, the
nodes further options with regard to DODAG parent selection and nodes further options with regard to DODAG parent selection and
movement within the DODAG are restricted in favor of loop avoidance. movement within the DODAG are restricted in favor of loop avoidance.
3.6.2.1. Rank Comparison 3.6.2.1. Rank Comparison (DAGRank())
Rank may be thought of as a fixed point number, where the position of Rank may be thought of as a fixed point number, where the position of
the decimal point is determined by MinHopRankIncrease. The integer the decimal point between the integer part and the fractional part is
portion of the Rank is determined by floor(Rank/MinHopRankIncrease). determined by MinHopRankIncrease. MinHopRankIncrease is the minimum
increase in rank between a node and any of its DODAG parents. When
an objective function computes rank, the objective function operates
on the entire (i.e. 16-bit) rank quantity. When rank is compared,
e.g. for determination of parent/sibling relationships or loop
detection, the integer portion of the rank is to be used. The
integer portion of the Rank is computed by the DAGRank() macro as
follows:
DAGRank(rank) = floor(rank/MinHopRankIncrease)
MinHopRankIncrease is provisioned at the DODAG Root and propagated in MinHopRankIncrease is provisioned at the DODAG Root and propagated in
the DIO message. For efficient implementation the MinHopRankIncrease the DIO message. For efficient implementation the MinHopRankIncrease
SHOULD be a power of 2. An implementation may configure a value SHOULD be a power of 2. An implementation may configure a value
MinHopRankIncrease as appropriate to balance between the loop MinHopRankIncrease as appropriate to balance between the loop
avoidance logic of RPL (i.e. selection of eligible parents and avoidance logic of RPL (i.e. selection of eligible parents and
siblings) and the metrics in use. siblings) and the metrics in use.
A node A has a rank less than the rank of a node B if floor(Rank(A) / By convention in this document, using the macro DAGRank(node) may be
MinHopRankIncrease) is less than floor (Rank(B) / interpreted as DAGRank(node.rank), where node.rank is the rank value
MinHopRankIncrease). as maintained by the node.
A node A has a rank equal to the rank of a node B if floor(Rank(A) / A node A has a rank less than the rank of a node B if DAGRank(A) is
MinHopRankIncrease) is equal to floor (Rank(B) / MinHopRankIncrease). less than DAGRank(B).
A node A has a rank greater than the rank of a node B if A node A has a rank equal to the rank of a node B if DAGRank(A) is
floor(Rank(A) / MinHopRankIncrease) is greater than floor (Rank(B) / equal to DAGRank(B).
MinHopRankIncrease).
A node A has a rank greater than the rank of a node B if DAGRank(A)
is greater than DAGRank(B).
3.6.2.2. Rank Relationships 3.6.2.2. Rank Relationships
The computation of the rank MUST be done in such a way so as to The computation of the rank MUST be done in such a way so as to
maintain the following properties for any nodes M and N that are maintain the following properties for any nodes M and N that are
neighbors in the LLN: neighbors in the LLN:
DAGRank(M) is less than DAGRank(N): In this case, the position of M DAGRank(M) is less than DAGRank(N): In this case, the position of M
is closer to the DODAG root than the position of N. Node M is closer to the DODAG root than the position of N. Node M
may safely be a DODAG parent for Node N without risk of may safely be a DODAG parent for Node N without risk of
creating a loop. Further, for a node N, all parents in the creating a loop. Further, for a node N, all parents in the
DODAG parent set must be of rank less than DAGRank(N). In DODAG parent set must be of rank less than DAGRank(N). In
other words, the rank presented by a node N MUST be greater other words, the rank presented by a node N MUST be greater
than that presented by any of its parents. than that presented by any of its parents.
DAGRank(M) equals DAGRank(N): In this case the positions of M and N DAGRank(M) equals DAGRank(N): In this case the positions of M and N
within the DODAG and with respect to the DODAG root are within the DODAG and with respect to the DODAG root are
similar (identical). In some cases, Node M may be used as a similar (identical). In some cases, Node M may be used as a
successor by Node N, which however entails the probability of successor by Node N, which however entails the chance of
creating a loop (which must be detected and resolved by some creating a loop (which must be detected and resolved by some
other means). other means).
DAGRank(M) is greater than DAGRank(N): In this case, the position of DAGRank(M) is greater than DAGRank(N): In this case, the position of
M is farther from the DODAG root than the position of N. M is farther from the DODAG root than the position of N.
Further, Node M may in fact be in the sub-DODAG of Node N. If Further, Node M may in fact be in the sub-DODAG of Node N. If
node N selects node M as DODAG parent there is a risk to node N selects node M as DODAG parent there is a risk to
create a loop. create a loop.
As an example, the rank could be computed in such a way so as to As an example, the rank could be computed in such a way so as to
closely track ETX when the objective function is to minimize ETX, or closely track ETX when the objective function is to minimize ETX, or
latency when the objective function is to minimize latency, or in a latency when the objective function is to minimize latency, or in a
more complicated way as appropriate to the objective code point being more complicated way as appropriate to the objective function being
used within the DODAG. used within the DODAG.
4. ICMPv6 RPL Control Message 4. ICMPv6 RPL Control Message
This document defines the RPL Control Message, a new ICMPv6 message. This document defines the RPL Control Message, a new ICMPv6 message.
In accordance with [RFC4443], the RPL Control Message has the In accordance with [RFC4443], the RPL Control Message has the
following format: following format:
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 | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Message Body + + Message Body +
skipping to change at page 22, line 20 skipping to change at page 22, line 23
| | | |
+ Message Body + + Message Body +
| | | |
Figure 3: RPL Control Message Figure 3: RPL Control Message
The RPL Control message is an ICMPv6 information message with a The RPL Control message is an ICMPv6 information message with a
requested Type of 155. requested Type of 155.
The Code field identifies the type of RPL Control Message. This The Code field identifies the type of RPL Control Message. This
document defines three types: document defines three codes for the following RPL Control Message
types:
o 0x01: DAG Information Solicitation (Section 5.2) o 0x01: DODAG Information Solicitation (Section 5.2)
o 0x02: DAG Information Object (Section 5.1) o 0x02: DODAG Information Object (Section 5.1)
o 0x04: Destination Advertisement Object (Section 6.1) o 0x04: Destination Advertisement Object (Section 6.1)
5. Upward Routes 5. Upward Routes
This section describes how RPL discovers and maintains upward routes. This section describes how RPL discovers and maintains upward routes.
It describes DODAG Information Objects (DIOs), the messages used to It describes DODAG Information Objects (DIOs), the messages used to
discover and maintain these routes. It specifies how RPL generates discover and maintain these routes. It specifies how RPL generates
and responds to DIOs. It also describes DAG Information Solicitation and responds to DIOs. It also describes DODAG Information
(DIS) messages, which are used to trigger DIO transmissions. Solicitation (DIS) messages, which are used to trigger DIO
transmissions.
5.1. DODAG Information Object (DIO) 5.1. DODAG Information Object (DIO)
The DODAG Information Object carries information that allows a node The DODAG Information Object carries information that allows a node
to discover a RPL Instance, learn its configuration parameters, to discover a RPL Instance, learn its configuration parameters,
select a DODAG parent set, and maintain the upward routing topology. select a DODAG parent set, and maintain the upward routing topology.
5.1.1. DIO Base Format 5.1.1. DIO Base Format
DIO Base is an always-present container option in a DIO message. DIO Base is an always-present container option in a DIO message.
skipping to change at page 23, line 33 skipping to change at page 23, line 33
Control Field: The DAG Control Field has three flags and one field: Control Field: The DAG Control Field has three flags and one field:
Grounded (G): The Grounded (G) flag indicates whether the Grounded (G): The Grounded (G) flag indicates whether the
upward routes this node advertises provide connectivity upward routes this node advertises provide connectivity
to the set of addresses which are application-defined to the set of addresses which are application-defined
goals. If the flag is set, the DODAG is grounded and goals. If the flag is set, the DODAG is grounded and
provides such connectivity. If the flag is cleared, the provides such connectivity. If the flag is cleared, the
DODAG is floating and may not provide such connectivity. DODAG is floating and may not provide such connectivity.
Destination Advertisement Supported (A): The Destination Destination Advertisement Supported (A): The Destination
Advertisement Supported (A) bit indicates whether the Advertisement Supported (A) flag indicates whether the
root of this DODAG can collect and use downward route root of this DODAG can collect and use downward route
state. The flag is set when nodes in the network are to state. If the flag is set, nodes in the network are
exchange destination advertisements messages to build enabled to exchange destination advertisements messages
downward routes (Section 6). The flag is cleared when to build downward routes (Section 6). If the flag is
the DODAG maintains only upward routes. cleared, destination advertisement messages are disabled
and the DODAG maintains only upward routes.
Destination Advertisement Trigger (T): The Destination Destination Advertisement Trigger (T): The Destination
Advertisement Trigger (T) flag is used to trigger a Advertisement Trigger (T) flag indicates a complete
complete refresh of downward routes. The details of this refresh of downward routes. If the flag is set, then a
process are described in Section 6. refresh of downward route state is to take place over the
entire DODAG. If the flag is cleared, the downward route
maintenance is in its normal mode of operation. The
further details of this process are described in
Section 6.
Destination Advertisements Stored (S): The Destination Destination Advertisements Stored (S): The Destination
Advertisements Stored (S) flag is used to indicate that a Advertisements Stored (S) flag is used to indicate that a
non-root ancestor is storing routing table entries non-root ancestor is storing routing table entries
learned from DAO messaging. The meaning and further use learned from DAO messaging. If the flag is set, then a
of this flag is described in Section 6. non-root ancestor is known to be storing routing table
entries learned from DAO messages. If the flag is
cleared, only the root node may be storing routing table
entries learned from DAO messaging. This flag is further
described in Section 6.
DODAGPreference (Prf): A 3-bit unsigned integer that defines DODAGPreference (Prf): A 3-bit unsigned integer that defines
how preferable the root of this DODAG is compared to how preferable the root of this DODAG is compared to
other DODAG roots within the DODAG. DAGPreference ranges other DODAG roots within the instance. DAGPreference
from 0x00 (least preferred) to 0x07 (most preferred). ranges from 0x00 (least preferred) to 0x07 (most
The default is 0 (least preferred). Section 5.3 preferred). The default is 0 (least preferred).
describes how DAGPreference affects DIO processing. Section 5.3 describes how DAGPreference affects DIO
processing.
Unassigned bits of the Control Field are reserved. They MUST Unassigned bits of the Control Field are reserved. They MUST
be set to zero on transmission and MUST be ignored on be set to zero on transmission and MUST be ignored on
reception. reception.
Sequence Number: 8-bit unsigned integer set by the DODAG root. Sequence Number: 8-bit unsigned integer set by the DODAG root.
Section 5.3 describes the rules for sequence numbers and how Section 5.3 describes the rules for sequence numbers and how
they affect DIO processing. they affect DIO processing.
Rank: 8-bit unsigned integer indicating the DODAG rank of the node Rank: 16-bit unsigned integer indicating the DODAG rank of the node
sending the DIO message. Section 5.3 describes how Rank is set sending the DIO message. Section 5.3 describes how Rank is set
and how it affects DIO processing. and how it affects DIO processing.
RPLInstanceID: 8-bit field set by the DODAG root that indicates RPLInstanceID: 8-bit field set by the DODAG root that indicates
which RPL Instance the DODAG is part of. which RPL Instance the DODAG is part of.
Destination Advertisement Trigger Sequence Number (DTSN): 8-bit Destination Advertisement Trigger Sequence Number (DTSN): 8-bit
unsigned integer set by the node issuing the DIO message. The unsigned integer set by the node issuing the DIO message. The
Destination Advertisement Trigger Sequence Number (DTSN) flag Destination Advertisement Trigger Sequence Number (DTSN) flag
is used as part of the procedure to maintain downward routes. is used as part of the procedure to maintain downward routes.
skipping to change at page 25, line 10 skipping to change at page 25, line 20
fields are: fields are:
1. Grounded (G) 1. Grounded (G)
2. Destination Advertisement Supported (A) 2. Destination Advertisement Supported (A)
3. Destination Advertisement Trigger (T) 3. Destination Advertisement Trigger (T)
4. DAGPreference (Prf) 4. DAGPreference (Prf)
5. Sequence 5. Sequence
6. RPLInstanceID 6. RPLInstanceID
7. DODAGID 7. DODAGID
3. A node MAY update the following fields at each hop: 3. A node MAY update the following fields at each hop:
1. DAGRank 1. Destination Advertisements Stored (S)
2. DTSN 2. DAGRank
3. DTSN
4. The DODAGID field each root sets MUST be unique within the RPL 4. The DODAGID field each root sets MUST be unique within the RPL
Instance. Instance.
5.1.3. DIO Suboptions 5.1.3. DIO Suboptions
This section describes the format of DIO suboptions and the five This section describes the format of DIO suboptions and the five
suboptions this document defines: Pad 1, Pad N, DAG Metric Container, suboptions this document defines: Pad 1, Pad N, DAG Metric Container,
DAG Destination Prefix, and DAG Configuration. DAG Destination Prefix, and DAG Configuration.
5.1.3.1. DIO Suboption Format 5.1.3.1. DIO Suboption Format
The Pad N, DAG Metric Container, DAG Destination Prefix, and DAG The Pad N, DAG Metric Container, DAG Destination Prefix, and DAG
Configuration suboptions all follow this format: Configuration suboptions all follow this format:
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Subopt. Type | Subopt Length | Subopt Data | Subopt. Type | Suboption Length | Suboption Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
Figure 5: DIO Suboption Generic Format Figure 5: DIO Suboption Generic Format
Suboption Type: 8-bit identifier of the type of suboption. Suboption Type: 8-bit identifier of the type of suboption.
Suboption Length: 16-bit unsigned integer, representing the length Suboption Length: 16-bit unsigned integer, representing the length
in octets of the suboption, not including the suboption Type in octets of the suboption, not including the suboption Type
and Length fields. and Length fields.
Suboption Data: A variable length field that contains data specific Suboption Data: A variable length field that contains data specific
to the option. to the option.
The following subsections specify the DIO message suboptions which The following subsections specify the DIO message suboptions which
are currently defined for use in the DAG Information Object. are currently defined for use in the DODAG Information Object.
When processing a DIO message containing a suboption for which the When processing a DIO message containing a suboption for which the
Suboption Type value is not recognized by the receiver, the receiver Suboption Type value is not recognized by the receiver, the receiver
MUST silently ignore the unrecognized option and continue to process MUST silently ignore the unrecognized option and continue to process
the following suboption, correctly handling any remaining options in the following suboption, correctly handling any remaining options in
the message. the message.
DIO message suboptions may have alignment requirements. Following DIO message suboptions may have alignment requirements. Following
the convention in IPv6, these options are aligned in a packet such the convention in IPv6, options with alignment requirements are
that multi-octet values within the Option Data field of each option aligned in a packet such that multi-octet values within the Option
fall on natural boundaries (i.e., fields of width n octets are placed Data field of each option fall on natural boundaries (i.e., fields of
at an integer multiple of n octets from the start of the header, for width n octets are placed at an integer multiple of n octets from the
n = 1, 2, 4, or 8). start of the header, for n = 1, 2, 4, or 8).
5.1.3.2. Pad1 5.1.3.2. Pad1
The Pad1 suboption does not have any alignment requirements. Its The Pad1 suboption format is as follows:
format is as follows:
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Type = 0 | | Type = 0 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 6: Pad 1 Figure 6: Pad 1
NOTE! the format of the Pad1 option is a special case - it has NOTE! the format of the Pad1 option is a special case - it has
neither Option Length nor Option Data fields. neither Option Length nor Option Data fields.
The Pad1 option is used to insert one or two octets of padding in the The Pad1 option is used to insert one or two octets of padding in the
DIO message to enable suboptions alignment. If more than two octets DIO message to enable suboptions alignment. If more than two octets
of padding is required, the PadN option, described next, should be of padding is required, the PadN option, described next, should be
used rather than multiple Pad1 options. used rather than multiple Pad1 options.
5.1.3.3. PadN 5.1.3.3. PadN
The PadN option does not have any alignment requirements. Its format The PadN suboption format is as follows:
is as follows:
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Type = 1 | Subopt Length | Subopt Data | Type = 1 | Suboption Length | Suboption Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
Figure 7: Pad N Figure 7: Pad N
The PadN option is used to insert three or more octets of padding in The PadN suboption is used to insert three or more octets of padding
the DIO message to enable suboptions alignment. For N (N > 2) octets in the DIO message to enable suboptions alignment. For N (N > 2)
of padding, the Option Length field contains the value N-3, and the octets of padding, the Suboption Length field contains the value N-3,
Option Data consists of N-3 zero-valued octets. PadN Option data and the Option Data consists of N-3 zero-valued octets. PadN Option
MUST be ignored by the receiver. data MUST be ignored by the receiver.
5.1.3.4. Metric Container 5.1.3.4. Metric Container
The Metric Container suboption may be aligned as necessary to support The Metric Container suboption format is as follows:
its contents. Its format is as follows:
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Type = 2 | Subopt Length | Metric Data | Type = 2 | Suboption Length | Metric Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
Figure 8: Metric Container Figure 8: Metric Container
The Metric Container is used to report aggregated path metrics along The Metric Container is used to report metrics along the DODAG. The
the DODAG. The Metric Container may contain a number of discrete Metric Container may contain a number of discrete node, link, and
node, link, and aggregate path metrics as chosen by the implementer. aggregate path metrics as chosen by the implementer. The Suboption
The Suboption Length field contains the length in octets of the Length field contains the length in octets of the Metric Data. The
Metric Data. The order, content, and coding of the Metric Container order, content, and coding of the Metric Container data is as
data is as specified in [I-D.ietf-roll-routing-metrics]. specified in [I-D.ietf-roll-routing-metrics].
The processing and propagation of the Metric Container is governed by The processing and propagation of the Metric Container is governed by
implementation specific policy functions. implementation specific policy functions.
5.1.3.5. Destination Prefix 5.1.3.5. Destination Prefix
The Destination Prefix suboption does not have any alignment The Destination Prefix suboption format is as follows:
requirements. Its format is as follows:
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 = 3 | Subopt Length |Resvd|Prf|Resvd| | Type = 3 | Suboption Length |Resvd|Prf|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Lifetime | | Prefix Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | | | Prefix Length | |
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ |
| Destination Prefix (Variable Length) | | Destination Prefix (Variable Length) |
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: DAG Destination Prefix Figure 9: DAG Destination Prefix
The Destination Prefix suboption is used when the DODAG root, or The Destination Prefix suboption is used to indicate that
another node located upwards along the DODAG on the path to the DODAG connectivity to the specified destination prefix is available from
root, needs to indicate that it offers connectivity to destination the DODAG root, or from another node located upwards along the DODAG
prefixes other than the default. This may be useful in cases where on the path to the DODAG root. This may be useful in cases where
more than one LBR is operating within the LLN and offering more than one LBR is operating within the LLN and offering
connectivity to different administrative domains, e.g. a home network connectivity to different administrative domains, e.g. a home network
and a utility network. In such cases, upon observing the Destination and a utility network. In such cases, upon observing the Destination
Prefixes offered by a particular DODAG, a node MAY decide to join Prefixes offered by a particular DODAG, a node MAY decide to join
multiple DODAGs in support of a particular application. multiple DODAGs in support of a particular application.
The Suboption Length is coded as the length of the suboption in The Suboption Length is coded as the length of the suboption in
octets, excluding the Type and Length fields. octets, excluding the Type and Length fields.
Prf is the Route Preference as in [RFC4191]. The reserved fields Prf is the Route Preference as in [RFC4191]. The reserved fields
skipping to change at page 28, line 42 skipping to change at page 29, line 12
The Destination Prefix contains Prefix Length significant bits of the The Destination Prefix contains Prefix Length significant bits of the
destination prefix. The remaining bits of the Destination Prefix, as destination prefix. The remaining bits of the Destination Prefix, as
required to complete the trailing octet, are set to 0. required to complete the trailing octet, are set to 0.
In the event that a DIO message may need to specify connectivity to In the event that a DIO message may need to specify connectivity to
more than one destination, the Destination Prefix suboption may be more than one destination, the Destination Prefix suboption may be
repeated. repeated.
5.1.3.6. DODAG Configuration 5.1.3.6. DODAG Configuration
The DODAG Configuration suboption does not have any alignment The DODAG Configuration suboption format is as follows:
requirements. Its format is as follows:
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 = 4 | Length | DIOIntDoubl. | | Type = 4 | Length | DIOIntDoubl. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DIOIntMin. | DIORedun. | MaxRankInc | MinHopRankInc | | DIOIntMin. | DIORedun. | MaxRankInc | MinHopRankInc |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: DODAG Configuration Figure 10: DODAG Configuration
The DODAG Configuration suboption is used to distribute configuration The DODAG Configuration suboption is used to distribute configuration
information for DODAG Operation through the DODAG. The information information for DODAG Operation through the DODAG. The information
communicated in this suboption is generally static and unchanging communicated in this suboption is generally static and unchanging
within the DODAG, therefore it is not necessary to include in every within the DODAG, therefore it is not necessary to include in every
DIO. This suboption MAY be included occasionally by the DODAG Root, DIO. This suboption MAY be included occasionally by the DODAG Root,
and MUST be included in response to a unicast request, e.g. a DODAG and MUST be included in response to a unicast request, e.g. a unicast
Information Solicitation (DIS) message. DODAG Information Solicitation (DIS) message.
The Length is coded as 5. The Length is coded as 5.
DIOIntervalDoublings is an 8-bit unsigned integer, configured on the DIOIntervalDoublings is an 8-bit unsigned integer, configured on the
DODAG root and used to configure the trickle timer (see DODAG root and used to configure the trickle timer (see
Section 5.3.5.1 for details on trickle timers) governing when DIO Section 5.3.5.1 for details on trickle timers) governing when DIO
message should be sent within the DODAG. DIOIntervalDoublings is the message should be sent within the DODAG. DIOIntervalDoublings is the
number of times that the DIOIntervalMin is allowed to be doubled number of times that the DIOIntervalMin is allowed to be doubled
during the trickle timer operation. during the trickle timer operation.
skipping to change at page 32, line 12 skipping to change at page 32, line 21
conventions of Serial Number Arithmetic as described in conventions of Serial Number Arithmetic as described in
[RFC1982]. [RFC1982].
5. Within a given DODAG, a node that is a not a root MUST NOT 5. Within a given DODAG, a node that is a not a root MUST NOT
advertise a DODAGSequenceNumber higher than the highest advertise a DODAGSequenceNumber higher than the highest
DODAGSequenceNumber it has heard. Higher is defined as the DODAGSequenceNumber it has heard. Higher is defined as the
greater-than operator in [RFC1982]. greater-than operator in [RFC1982].
6. Once a node has advertised a DODAG iteration by sending a DIO, it 6. Once a node has advertised a DODAG iteration by sending a DIO, it
MUST NOT be member of a previous DODAG iteration of the same MUST NOT be member of a previous DODAG iteration of the same
DODAG (i.e. with the same DODAGID and a lower DODAG (i.e. with the same RPLInstanceID, the same DODAGID, and a
DODAGSequenceNumber). Lower is defined as the less-than operator lower DODAGSequenceNumber). Lower is defined as the less-than
in [RFC1982]. operator in [RFC1982].
Within a particular implementation, a DODAG root may increment the Within a particular implementation, a DODAG root may increment the
DODAGSequenceNumber periodically, at a rate that depends on the DODAGSequenceNumber periodically, at a rate that depends on the
deployment. In other implementations, loop detection may be deployment. In other implementations, loop detection may be
considered sufficient to solve routing issues, and the DODAG root may considered sufficient to solve routing issues, and the DODAG root may
increment the DODAGSequenceNumber only upon administrative increment the DODAGSequenceNumber only upon administrative
intervention. Another possibility is that nodes within the LLN have intervention. Another possibility is that nodes within the LLN have
some means by which they can signal detected routing inconsistencies some means by which they can signal detected routing inconsistencies
or suboptimalities to the DODAG root, in order to request an on- or suboptimalities to the DODAG root, in order to request an on-
demand DODAGSequenceNumber increment (i.e. request a global repair of demand DODAGSequenceNumber increment (i.e. request a global repair of
the DODAG). the DODAG).
When the DODAG parent set is depleted on a node that is not a root, When the DODAG parent set becomes empty on a node that is not a root,
(i.e. the last parent is removed), then the DODAG information should (i.e. the last parent has been removed, causing the node to no longer
not be suppressed until after the expiration of an implementation- be associated with that DODAG), then the DODAG information should not
be suppressed until after the expiration of an implementation-
specific local timer in order to observe if the DODAGSequenceNumber specific local timer in order to observe if the DODAGSequenceNumber
has been incremented, should any new parents appear for the DODAG. has been incremented, should any new parents appear for the DODAG.
As the DODAGSequenceNumber is incremented, a new DODAG Iteration As the DODAGSequenceNumber is incremented, a new DODAG Iteration
spreads outward from the DODAG root. Thus a parent that advertises spreads outward from the DODAG root. Thus a parent that advertises
the new DODAGSequenceNumber can not possibly belong to the sub-DODAG the new DODAGSequenceNumber can not possibly belong to the sub-DODAG
of a node that still advertises an older DODAGSequenceNumber. A node of a node that still advertises an older DODAGSequenceNumber. A node
may safely add such a parent, without risk of forming a loop, without may safely add such a parent, without risk of forming a loop, without
regard to its relative rank in the prior DODAG Iteration. This is regard to its relative rank in the prior DODAG Iteration. This is
equivalent to jumping to a different DODAG. equivalent to jumping to a different DODAG.
skipping to change at page 33, line 37 skipping to change at page 33, line 44
DODAGSequenceNumber and other DODAG root determined parameters with DODAGSequenceNumber and other DODAG root determined parameters with
the virtual root over the backbone. the virtual root over the backbone.
5.3.3.3. DODAG Selection 5.3.3.3. DODAG Selection
The DODAGPreference (Prf) provides an administrative mechanism to The DODAGPreference (Prf) provides an administrative mechanism to
engineer the self-organization of the LLN, for example indicating the engineer the self-organization of the LLN, for example indicating the
most preferred LBR. If a node has the option to join a more most preferred LBR. If a node has the option to join a more
preferred DODAG while still meeting other optimization objectives, preferred DODAG while still meeting other optimization objectives,
then the node will generally seek to join the more preferred DODAG as then the node will generally seek to join the more preferred DODAG as
determined by the OF. determined by the OF. All else being equal, it is left to the
implementation to determine which DODAG is most preferred, possibly
based on additional criteria beyond Prf and the OF.
5.3.3.4. Rank and Movement within a DODAG Iteration 5.3.3.4. Rank and Movement within a DODAG Iteration
1. A node MUST NOT advertise a rank less than or equal to any member 1. A node MUST NOT advertise a rank less than or equal to any member
of its parent set within the DODAG Iteration. of its parent set within the DODAG Iteration.
2. A node MAY advertise a rank lower than its prior advertisement 2. A node MAY advertise a rank lower than its prior advertisement
within the DODAG Iteration. within the DODAG Iteration.
3. Let L be the lowest rank within a DODAG iteration that a given 3. Let L be the lowest rank within a DODAG iteration that a given
node has advertised. Within the same DODAG Iteration, that node node has advertised. Within the same DODAG Iteration, that node
MUST NOT advertise an effective rank higher than L + MUST NOT advertise an effective rank higher than L +
DAGMaxRankIncrease. INFINITE_RANK is an exception to this rule: DAGMaxRankIncrease. INFINITE_RANK is an exception to this rule:
skipping to change at page 35, line 11 skipping to change at page 35, line 22
the nodes in its sub-DODAG, by advertising an effective rank of the nodes in its sub-DODAG, by advertising an effective rank of
INFINITE_RANK and resetting the associated DIO trickle timer to INFINITE_RANK and resetting the associated DIO trickle timer to
cause this INFINITE_RANK to be announced promptly. cause this INFINITE_RANK to be announced promptly.
2. The node MAY advertise an effective rank of INFINITE_RANK for an 2. The node MAY advertise an effective rank of INFINITE_RANK for an
arbitrary number of DIO timer events, before announcing a new arbitrary number of DIO timer events, before announcing a new
rank. rank.
3. As per Section 5.3.3.4, the node MUST advertise INFINITE_RANK 3. As per Section 5.3.3.4, the node MUST advertise INFINITE_RANK
within the DODAG iteration in which it participates, if its within the DODAG iteration in which it participates, if its
revised rank would exceed the maximum rank increase. revision in rank would exceed the maximum rank increase.
An implementation may choose to employ this poisoning mechanism when An implementation may choose to employ this poisoning mechanism when
a node loses all of its current parents, i.e. the set of DODAG a node loses all of its current parents, i.e. the set of DODAG
parents becomes depleted, and it can not jump to an alternate DODAG. parents becomes depleted, and it can not jump to an alternate DODAG.
An alternate mechanism is to form a floating DODAG. An alternate mechanism is to form a floating DODAG.
The motivation for delaying announcement of the revised route through The motivation for delaying announcement of the revised route through
multiple DIO events is to (i) increase tolerance to DIO loss, (ii) multiple DIO events is to (i) increase tolerance to DIO loss, (ii)
allow time for the poisoning action to propagate, and (iii) to allow time for the poisoning action to propagate, and (iii) to
develop an accurate assessment of its new rank. Such gains are develop an accurate assessment of its new rank. Such gains are
skipping to change at page 36, line 44 skipping to change at page 37, line 6
greater rank). greater rank).
5.3.5. DIO Transmission 5.3.5. DIO Transmission
Each node maintains a timer, that governs when to multicast DIO Each node maintains a timer, that governs when to multicast DIO
messages. This timer is a trickle timer, as detailed in messages. This timer is a trickle timer, as detailed in
Section 5.3.5.1. The DIO Configuration Option includes the Section 5.3.5.1. The DIO Configuration Option includes the
configuration of a RPL Instance's trickle timer. configuration of a RPL Instance's trickle timer.
o When a node detects or causes an inconsistency, it MUST reset the o When a node detects or causes an inconsistency, it MUST reset the
interval of the trickle timer to its minimum value. trickle timer.
o When a node migrates to a new DODAG Iteration it MUST reset the o When a node migrates to a new DODAG Iteration it MUST reset the
trickle timer to its minimum value trickle timer to its minimum value
o When a node detects an inconsistency when forwarding a packet, as o When a node detects an inconsistency when forwarding a packet, as
detailed in Section 7.2, the node MUST reset the trickle timer to detailed in Section 7.2, the node MUST reset the trickle timer.
its minimum value.
o When a node receives a multicast DIS message, it MUST reset the o When a node receives a multicast DIS message, it MUST reset the
trickle timer to its minimum value. trickle timer to its minimum value.
o When a node receives a unicast DIS message, it MUST unicast a DIO o When a node receives a unicast DIS message, it MUST unicast a DIO
message in response, and MUST include the DODAG Configuration message in response, and the response MUST include the DODAG
Object. In this case the node SHOULD NOT reset the trickle timer. Configuration Object. This provides a means that an interrogating
node may be guaranteed to receive the DODAG Configuration Object,
which otherwise might not be included at the option of the sender.
In this case the node SHOULD NOT reset the trickle timer.
o If a node is not a member of a DODAG, it MUST suppress o If a node is not a member of a DODAG, it MUST suppress
transmission of DIO messages. transmission of DIO messages.
o When a node is initialized, it MAY be configured to remain silent o When a node is initialized, it MAY be configured to remain silent
and not multicast any DIO messages until it has encountered and and not multicast any DIO messages until it has encountered and
joined a DODAG (perhaps initially probing for a nearby DODAG with joined a DODAG (perhaps initially probing for a nearby DODAG with
an DIS message). Alternately, it MAY choose to root its own an DIS message). Alternately, it MAY choose to root its own
floating DODAG and begin multicasting DIO messages using a default floating DODAG and begin multicasting DIO messages using a default
trickle configuration. The second case may be advantageous if it trickle configuration. The second case may be advantageous if it
skipping to change at page 38, line 14 skipping to change at page 38, line 26
5.3.5.1.1. Resetting the Trickle Timer 5.3.5.1.1. Resetting the Trickle Timer
The trickle timer for a DODAG is reset by: The trickle timer for a DODAG is reset by:
1. Setting I_min and I_doublings to the values learned from the 1. Setting I_min and I_doublings to the values learned from the
DODAG root via a received DIO message. DODAG root via a received DIO message.
2. Setting C to zero. 2. Setting C to zero.
3. Setting I to I_min. 3. If I is not equal to I_min:
4. Setting T to a random value as described above. 1. Setting I to I_min.
5. Restarting the trickle timer to expire after a duration T 2. Setting T to a random value as described above.
3. Restarting the trickle timer to expire after a duration T
When a node learns about a DODAG through a DIO message, and makes the When a node learns about a DODAG through a DIO message, and makes the
decision to join this DODAG, it initializes the state of the trickle decision to join this DODAG, it initializes the state of the trickle
timer by resetting the trickle timer and listening. Each time it timer by resetting the trickle timer and listening. Each time it
hears a redundant DIO message for this DODAG, it MAY increment C. The hears a redundant DIO message for this DODAG, it MAY increment C. The
exact determination of what constitutes a redundant DIO message is exact determination of what constitutes a redundant DIO message is
left to an implementation; it could for example include DIOs that left to an implementation; it could for example include DIOs that
advertise the same rank. advertise the same rank.
When the timer fires at time T, the node compares C to the redundancy When the timer fires at time T, the node compares C to the redundancy
skipping to change at page 38, line 45 skipping to change at page 39, line 14
5.3.5.1.2. Determination of Inconsistency 5.3.5.1.2. Determination of Inconsistency
The trickle timer is reset whenever an inconsistency is detected The trickle timer is reset whenever an inconsistency is detected
within the DODAG, for example: within the DODAG, for example:
o The node joins a new DODAG o The node joins a new DODAG
o The node moves within a DODAG o The node moves within a DODAG
o The node receives a modified DIO message from a DODAG parent o The node receives a DIO message from a DODAG parent that updates
the information learned from a prior DIO message for that DODAG
Parent
o A DODAG parent forwards a packet intended to move up, indicating o A DODAG parent forwards a packet intended to move up, indicating
an inconsistency and possible loop. an inconsistency and possible loop.
o A metric communicated in the DIO message is determined to be o A metric communicated in the DIO message is determined to be
inconsistent, as according to a implementation specific path inconsistent, as according to a implementation specific path
metric selection engine. metric selection engine.
o The rank of a DODAG parent has changed. o The rank of a DODAG parent has changed.
skipping to change at page 45, line 48 skipping to change at page 46, line 17
PENDING This entry is active, awaiting validation, and PENDING This entry is active, awaiting validation, and
usable. A Retry Counter is associated with usable. A Retry Counter is associated with
this substate this substate
UNREACHABLE This entry is being cleaned up. This entry may be UNREACHABLE This entry is being cleaned up. This entry may be
suppressed when the cleanup process is complete. suppressed when the cleanup process is complete.
When an attempt is to be made to report the DAO entry to DAO Parents, When an attempt is to be made to report the DAO entry to DAO Parents,
the DAO Entry record is logically marked to indicate that an attempt the DAO Entry record is logically marked to indicate that an attempt
has not yet been made for parent. As the unicast attempts are has not yet been made for each parent. As the unicast attempts are
completed for each parent, this mark may be cleared. This mechanism completed for each parent, this mark may be cleared. This mechanism
may serve to limit DAO entry updates for each parent to a subset that may serve to limit DAO entry updates for each parent to a subset that
needs to be reported. needs to be reported.
6.2.4.1.1. DAO Routing Table Entry Management 6.2.4.1.1. DAO Routing Table Entry Management
+---------------------------------+ +---------------------------------+
| | | |
| REACHABLE | +-------------+ | REACHABLE | +-------------+
| | | | | | | |
skipping to change at page 46, line 38 skipping to change at page 47, line 8
6.2.4.1.1.1. Operation in the CONNECTED state 6.2.4.1.1.1. Operation in the CONNECTED state
1. CONNECTED DAO entries are to be provisioned outside of the 1. CONNECTED DAO entries are to be provisioned outside of the
context of RPL, e.g. through a management API. An implementation context of RPL, e.g. through a management API. An implementation
SHOULD provide a means to provision/manage CONNECTED DAO entries, SHOULD provide a means to provision/manage CONNECTED DAO entries,
including whether they are to be redistributed in RPL. including whether they are to be redistributed in RPL.
6.2.4.1.1.2. Operation in the REACHABLE state 6.2.4.1.1.2. Operation in the REACHABLE state
1. When a REACHABLE(*) entry times out, the entry MUST be placed 1. When a REACHABLE(*) entry times out, i.e. the DAO Lifetime has
into the UNREACHABLE state and no-DAO SHOULD be scheduled to send elapsed, the entry MUST be placed into the UNREACHABLE state and
to the node's DAO Parents. (TBD MUST?) no-DAO SHOULD be scheduled to send to the node's DAO Parents.
2. When a no-DAO for a REACHABLE(*) entry is received with a newer 2. When a no-DAO for a REACHABLE(*) entry is received with a newer
DAO Sequence Number, the entry MUST be placed into the DAO Sequence Number, the entry MUST be placed into the
UNREACHABLE state and no-DAO SHOULD be scheduled to send to the UNREACHABLE state and no-DAO SHOULD be scheduled to send to the
node's DAO Parents. node's DAO Parents.
3. When a REACHABLE(*) entry is to be removed because NUD or 3. When a REACHABLE(*) entry is to be removed because NUD or
equivalent has determined that the next-hop neighbor is no longer equivalent has determined that the next-hop neighbor is no longer
reachable, the entry MUST be placed into the UNREACHABLE state reachable, the entry MUST be placed into the UNREACHABLE state
and no-DAO SHOULD be scheduled to send to the node's DAO Parents. and no-DAO SHOULD be scheduled to send to the node's DAO Parents.
skipping to change at page 47, line 19 skipping to change at page 47, line 36
5. When a DAO (or no-DAO) for a REACHABLE(*) entry is received with 5. When a DAO (or no-DAO) for a REACHABLE(*) entry is received with
an older or unchanged DAO Sequence Number, then the DAO (or no- an older or unchanged DAO Sequence Number, then the DAO (or no-
DAO) SHOULD be ignored and the associated entry MUST NOT be DAO) SHOULD be ignored and the associated entry MUST NOT be
updated with the stale information. updated with the stale information.
6.2.4.1.1.2.1. REACHABLE(Confirmed) 6.2.4.1.1.2.1. REACHABLE(Confirmed)
1. When a DAO for a previously unknown (or UNREACHABLE) destination 1. When a DAO for a previously unknown (or UNREACHABLE) destination
is received and is to be stored, it MUST be entered into the is received and is to be stored, it MUST be entered into the
routing table in the REACHABLE(Confirmed) state. Alternately the routing table in the REACHABLE(Confirmed) state, and a DAO SHOULD
be scheduled to send to the node's DAO Parents. Alternately the
node may behave as a non-storing node with respect to this node may behave as a non-storing node with respect to this
destination. destination.
2. When a DAO for a REACHABLE(Confirmed) entry is received with a 2. When a DAO for a REACHABLE(Confirmed) entry is received with a
newer DAO Sequence Number the entry MUST be updated with the newer DAO Sequence Number, the entry MUST be updated with the
logical equivalent of the DAO contents. logical equivalent of the DAO contents and a DAO SHOULD be
scheduled to send to the node's DAO Parents.
3. When a DAO for a REACHABLE(Confirmed) entry is expected, e.g. 3. When a DAO for a REACHABLE(Confirmed) entry is expected, e.g.
because a DIO to request a DAO refresh is sent, then the DAO because a DIO to request a DAO refresh is sent, then the DAO
entry MUST be placed in the REACHABLE(Pending) state and the entry MUST be placed in the REACHABLE(Pending) state and the
associated Retry Counter MUST be set to 0. associated Retry Counter MUST be set to 0.
6.2.4.1.1.2.2. REACHABLE(Pending) 6.2.4.1.1.2.2. REACHABLE(Pending)
1. When a DAO for a REACHABLE(Pending) entry is received with a 1. When a DAO for a REACHABLE(Pending) entry is received with a
newer DAO Sequence Number, the entry MUST be updated with the newer DAO Sequence Number, the entry MUST be updated with the
logical equivalent of the DAO contents and the entry MUST be logical equivalent of the DAO contents and the entry MUST be
placed in the REACHABLE(Confirmed) state. placed in the REACHABLE(Confirmed) state.
2. When a DAO for a REACHABLE(Pending) entry is expected, e.g. 2. When a DAO for a REACHABLE(Pending) entry is expected, e.g.
because DAO has (again) been triggered with respect to that because DAO has (again) been triggered with respect to that
neighbor, then the associated Retry Counter MUST be incremented. neighbor, then the associated Retry Counter MUST be incremented.
3. When a the associated Retry Counter for a REACHABLE(Pending) 3. When the associated Retry Counter for a REACHABLE(Pending) entry
entry reaches a maximum threshold, the entry MUST be placed into reaches a maximum threshold, the entry MUST be placed into the
the UNREACHABLE state and no-DAO SHOULD be scheduled to send to UNREACHABLE state and no-DAO SHOULD be scheduled to send to the
the node's DAO Parents. node's DAO Parents.
6.2.4.1.1.3. Operation in the UNREACHABLE state 6.2.4.1.1.3. Operation in the UNREACHABLE state
1. An implementation SHOULD bound the time that the entry is 1. An implementation SHOULD bound the time that the entry is
allocated in the UNREACHABLE state. Upon the equivalent expiry allocated in the UNREACHABLE state. Upon the equivalent expiry
of the related timer (RemoveTimer), the entry SHOULD be of the related timer (RemoveTimer), the entry SHOULD be
suppressed. suppressed.
2. While the entry is in the UNREACHABLE state a node SHOULD make a 2. While the entry is in the UNREACHABLE state a node SHOULD make a
reasonable attempt to report a no-DAO to each of the DAO parents. reasonable attempt to report a no-DAO to each of the DAO parents.
skipping to change at page 48, line 39 skipping to change at page 49, line 12
waypoint, then the node MUST append the address of the child waypoint, then the node MUST append the address of the child
to the RRStack, and increment RRCount. to the RRStack, and increment RRCount.
6.2.6. Scheduling to Send DAO (or no-DAO) 6.2.6. Scheduling to Send DAO (or no-DAO)
1. An implementation SHOULD arrange to rate-limit the sending of 1. An implementation SHOULD arrange to rate-limit the sending of
DAOs. DAOs.
2. When scheduling to send a DAO, an implementation SHOULD 2. When scheduling to send a DAO, an implementation SHOULD
equivalently start a timer (DelayDAO) to delay sending the DAO. equivalently start a timer (DelayDAO) to delay sending the DAO.
If the timer has already been armed then the DAO may be If the DelayDAO timer is already running then the DAO may be
considered as already scheduled, and implementation SHOULD leave considered as already scheduled, and implementation SHOULD leave
the timer running at its present duration. the timer running at its present duration.
o In order to increase the effectiveness of aggregation, an o When computing the delay before sending a DAO, in order to
implementation MAY allow time to receive no-DAOs from its sub- increase the effectiveness of aggregation, an implementation MAY
DODAG prior to emitting DAOs to its DAO Parents. allow time to receive DAOs from its sub-DODAG prior to emitting
DAOs to its DAO Parents.
* The scheduled delay in such cases may be, for example, such * The scheduled delay in such cases may be, for example, such
that DAO_LATENCY/f(self_rank) <= delay < DAO_LATENCY/ that DAO_LATENCY/DAGRank(self_rank) <= DelayDAO < DAO_LATENCY/
f(parent_rank), where f(rank) is floor(rank/ DAGRank(parent_rank), where DAGRank() is defined as in
MinHopRankIncrease), such that nodes deeper in the DODAG may Section 3.6.2, such that nodes deeper in the DODAG may tend to
tend to report DAO messages first before their parent nodes report DAO messages first before their parent nodes will report
will report DAO messages. Note that this suggestion is DAO messages. Note that this suggestion is intended as an
intended as an optimization to allow efficient aggregation -- optimization to allow efficient aggregation -- it is not
it is not required for correct operation in the general case. required for correct operation in the general case.
6.2.7. Triggering DAO Message from the Sub-DODAG 6.2.7. Triggering DAO Message from the Sub-DODAG
Note: The DIO is modified to add a 'S' flag, which is used to Triggering DAO messages from the Sub-DODAG occurs by using the
indicate if a non-root ancestor storing routing table entries learned following control fields with the rules described below:
from DAOs. This allows an optimization in the case where ONLY the
root node is storing such routing table entries, then it is not The DTSN field from the DIO is a sequence number that is part of the
necessary for an intermediate node to trigger DAO messages from its mechanism to trigger DAO messages. The motivation to use a sequence
sub-DODAG when it changes its DAO Parent. number is to provide some means of reliable signaling to the sub-
DODAG-- whereas a control flag that is activated for a short time may
be unobserved by the sub-DODAG if the triggering DIO messages are
lost, the DTSN increment may be observed later even if some DIO
messages have been lost since the sequence number increment.
The 'T' flag provides a way to signal the refresh of DAO information
over the entire DODAG iteration. Whereas a DTSN increment may only
trigger a DAO refresh as far as the nearest storing node (because a
storing node will not increment its own DTSN in response, as
described in the rules below), the assertion of the 'T' flag in
conjunction with an incremented DTSN will 'punch through' storing
nodes to elicit a DAO refresh from the entire DODAG Iteration.
The 'S' flag provides a way to signal to a sub-DODAG that there is at
least one non-root node somewhere in the set of DODAG ancestors,
where that non-root node is a storing node. This allows for an
optimization-- when it is clear to a non-storing node that the root
node can be the only storing ancestor, then that node does not
necessarily need to trigger updates from its sub-DODAG when it
modifies its DAO parent set. The motivation here is that the root
node should be able to update its stored source routing information
for the affected sub-DODAG based only on receiving DAO information
concerning the link that changed. In the other case, when the 'S'
flag is set, the non-storing node does not have a means to determine
which DAO information may (or may not) need to be updated in the
intermediate storing node so it must trigger DAO messages in order to
update the intermediate storing node. Please note that some aspects
of the proper use of the 'S' flag remain under investigation.
Further examples of triggering DAO messages are contained in
Appendix B.
The control fields are used to trigger DAO messages as follows:
1. The DODAG root MUST clear the 'S' flag when it emits DIO 1. The DODAG root MUST clear the 'S' flag when it emits DIO
messages. messages.
2. Non-root nodes that store routing table entries learned from 2. Non-root nodes that store routing table entries learned from
DAOs MUST set the 'S' flag when they emit DIO messages. DAOs MUST set the 'S' flag when they emit DIO messages.
3. A node that has any DAO Parent with the 'S' flag set MUST also 3. A node that has any DAO Parent with the 'S' flag set MUST also
set the 'S' flag when it emits DIO messages. set the 'S' flag when it emits DIO messages.
4. A node that has all DAO Parents with cleared 'S' flags MUST 4. A node that has all DAO Parents with cleared 'S' flags, and does
clear the 'S' flag when it emits DIO messages. not store routing table entries learned from DAOs, MUST clear
the 'S' flag when it emits DIO messages.
5. A DAO Trigger Sequence Number (DTSN) MUST be maintained by each 5. A DAO Trigger Sequence Number (DTSN) MUST be maintained by each
node per RPL Instance. The DTSN, in conjunction with the 'T' node per RPL Instance. The DTSN, in conjunction with the 'T'
flag from the DIO message, provides a means by which DAO flag from the DIO message, provides a means by which DAO
messages may be reliably triggered in the event of topology messages may be reliably triggered in the event of topology
change. change.
6. The DTSN MUST be advertised by the node in the DIO message. 6. The DTSN MUST be advertised by the node in the DIO message.
7. A node keeps track of the DTSN that it has heard from the last 7. A node keeps track of the DTSN that it has heard from the last
DIO from each of its DAO Parents. Note that there is one DTSN DIO from each of its DAO Parents. Note that there is one DTSN
maintained per DAO Parent-- each DAO Parent may independently maintained per DAO Parent- each DAO Parent may independently
increment it at will. (TBD A change to DTSN does not indicate increment it at will.
DAG inconsistency?).
8. A node that is not a fully-storing node SHOULD increment its own 8. A node that is not a fully-storing node SHOULD increment its own
DTSN when it adds a new parent, that parent having the 'S' flag DTSN when it adds a new parent, that parent having the 'S' flag
set, to its DAO Parent set. It MAY defer advertising the set, to its DAO Parent set. It MAY defer advertising the
increment as long as it has a DAO parent that already provides increment as long as it has a DAO parent that already provides
adequate connectivity. adequate connectivity.
9. A node that is not a fully-storing node MUST increment its own 9. A node that is not a fully-storing node MUST increment its own
DTSN when it receives a DIO from a DAO Parent that contains a DTSN when it receives a DIO from a DAO Parent that contains a
newly incremented DTSN. (The newly incremented DTSN is detected newly incremented DTSN. (The newly incremented DTSN is detected
skipping to change at page 53, line 40 skipping to change at page 55, line 5
the relative ranks and the direction as indicated in the 'O' the relative ranks and the direction as indicated in the 'O'
bit. A host MUST set the bit to 0. bit. A host MUST set the bit to 0.
Forwarding-Error 'F' bit: 1-bit flag indicating that this node can Forwarding-Error 'F' bit: 1-bit flag indicating that this node can
not forward the packet further towards the destination. The not forward the packet further towards the destination. The
'F' bit might be set by sibling that can not forward to a 'F' bit might be set by sibling that can not forward to a
parent a packet with the Sibling 'S' bit set, or by a child parent a packet with the Sibling 'S' bit set, or by a child
node that does not have a route to destination for a packet node that does not have a route to destination for a packet
with the down 'O' bit set. A host MUST set the bit to 0. with the down 'O' bit set. A host MUST set the bit to 0.
SenderRank: 8-bit field set to zero by the source and to its rank by SenderRank: 8-bit field set to zero by the source and to
a router that forwards inside the RPL network. DAGRank(rank) by a router that forwards inside the RPL network.
(Note that the case where DAGRank(rank) does not fit into 8
bits is under investigation.)
RPLInstanceID: 8-bit field indicating the DODAG instance along which RPLInstanceID: 8-bit field indicating the DODAG instance along which
the packet is sent. the packet is sent.
7.2.1. Source Node Operation 7.2.1. Source Node Operation
A packet that is sourced at a node connected to a RPL network or A packet that is sourced at a node connected to a RPL network or
destined to a node connected to a RPL network MUST be issued with the destined to a node connected to a RPL network MUST be issued with the
flow label zeroed out, but for the RPLInstanceID field. flow label zeroed out, but for the RPLInstanceID field.
skipping to change at page 54, line 38 skipping to change at page 55, line 52
Instance IDs are used to avoid loops between DODAGs from different Instance IDs are used to avoid loops between DODAGs from different
origins. DODAGs that constructed for antagonistic constraints might origins. DODAGs that constructed for antagonistic constraints might
contain paths that, if mixed together, would yield loops. Those contain paths that, if mixed together, would yield loops. Those
loops are avoided by forwarding a packet along the DODAG that is loops are avoided by forwarding a packet along the DODAG that is
associated to a given instance. associated to a given instance.
The RPLInstanceID is placed by the source in the flow label. This The RPLInstanceID is placed by the source in the flow label. This
RPLInstanceID MUST match the RPL Instance onto which the packet is RPLInstanceID MUST match the RPL Instance onto which the packet is
placed by any node, be it a host or router. placed by any node, be it a host or router.
When a router receives a packet that is flagged with a given When a router receives a packet that specifies a given RPLInstanceID
RPLInstanceID and the node can forward the packet along the DODAG and the node can forward the packet along the DODAG associated to
associated to that instance, then the router MUST do so and leave the that instance, then the router MUST do so and leave the RPLInstanceID
RPLInstanceID flag unchanged. flag unchanged.
If any node can not forward a packet along the DODAG associated to If any node can not forward a packet along the DODAG associated to
the RPLInstanceID in the flow label, then the node SHOULD discard the the RPLInstanceID in the flow label, then the node SHOULD discard the
packet. packet.
7.2.2.3. DAG Inconsistency Loop Detection 7.2.2.3. DAG Inconsistency Loop Detection
The DODAG is inconsistent if the direction of a packet does not match The DODAG is inconsistent if the direction of a packet does not match
the rank relationship. A receiver detects an inconsistency if it the rank relationship. A receiver detects an inconsistency if it
receives a packet with either: receives a packet with either:
skipping to change at page 56, line 14 skipping to change at page 57, line 25
7.2.2.5. DAO Inconsistency Loop Detection and Recovery 7.2.2.5. DAO Inconsistency Loop Detection and Recovery
A DAO inconsistency happens when router that has an down DAO route A DAO inconsistency happens when router that has an down DAO route
via a child that is a remnant from an obsolete state that is not via a child that is a remnant from an obsolete state that is not
matched in the child. With DAO inconsistency loop recovery, a packet matched in the child. With DAO inconsistency loop recovery, a packet
can be used to recursively explore and cleanup the obsolete DAO can be used to recursively explore and cleanup the obsolete DAO
states along a sub-DODAG. states along a sub-DODAG.
In a general manner, a packet that goes down should never go up In a general manner, a packet that goes down should never go up
again. So rather than routing up a packet with the down bit set, the again. If DAO inconsistency loop recovery is applied, then the
router MUST discard the packet. If DAO inconsistency loop recovery router SHOULD send the packet to the parent that passed it with the
is applied, then the router SHOULD send the packet to the parent that Forwarding-Error 'F' bit set. Otherwise the router MUST silently
passed it with the Forwarding-Error 'F' bit set. discard the packet.
7.2.2.6. Forward Path Recovery 7.2.2.6. Forward Path Recovery
Upon receiving a packet with a Forwarding-Error bit set, the node Upon receiving a packet with a Forwarding-Error bit set, the node
MUST remove the routing states that caused forwarding to that MUST remove the routing states that caused forwarding to that
neighbor, clear the Forwarding-Error bit and attempt to send the neighbor, clear the Forwarding-Error bit and attempt to send the
packet again. The packet may its way to an alternate neighbor. If packet again. The packet may its way to an alternate neighbor. If
that alternate neighbor still has an inconsistent DAO state via this that alternate neighbor still has an inconsistent DAO state via this
node, the process will recurse, this node will set the Forwarding- node, the process will recurse, this node will set the Forwarding-
Error 'F' bit and the routing state in the alternate neighbor will be Error 'F' bit and the routing state in the alternate neighbor will be
cleaned up as well. cleaned up as well.
8. Multicast Operation 8. Multicast Operation
This section describes further the multicast routing operations over This section describes further the multicast routing operations over
an IPv6 RPL network, and specifically how unicast DAOs can be used to an IPv6 RPL network, and specifically how unicast DAOs can be used to
relay group registrations up. Wherever the following text mentions relay group registrations up. Wherever the following text mentions
MLD, one can read MLDv2 or v3. Multicast Listener Discovery (MLD), one can read MLDv2 ([RFC3810]) or
v3.
As is traditional, a listener uses a protocol such as MLD with a As is traditional, a listener uses a protocol such as MLD with a
router to register to a multicast group. router to register to a multicast group.
Along the path between the router and the DODAG root, MLD requests Along the path between the router and the DODAG root, MLD requests
are mapped and transported as DAO messages within the RPL protocol; are mapped and transported as DAO messages within the RPL protocol;
each hop coalesces the multiple requests for a same group as a single each hop coalesces the multiple requests for a same group as a single
DAO message to the parent(s), in a fashion similar to proxy IGMP, but DAO message to the parent(s), in a fashion similar to proxy IGMP, but
recursively between child router and parent up to the root. recursively between child router and parent up to the root.
skipping to change at page 58, line 28 skipping to change at page 59, line 40
10. Guidelines for Objective Functions 10. Guidelines for Objective Functions
An Objective Function (OF) allows for the selection of a DODAG to An Objective Function (OF) allows for the selection of a DODAG to
join, and a number of peers in that DODAG as parents. The OF is used join, and a number of peers in that DODAG as parents. The OF is used
to compute an ordered list of parents. The OF is also responsible to to compute an ordered list of parents. The OF is also responsible to
compute the rank of the device within the DODAG iteration. compute the rank of the device within the DODAG iteration.
The Objective Function is indicated in the DIO message using an The Objective Function is indicated in the DIO message using an
Objective Code Point (OCP), as specified in Objective Code Point (OCP), as specified in
[I-D.ietf-roll-routing-metrics], and indicates the method that must [I-D.ietf-roll-routing-metrics], and indicates the method that must
be used to compute the DODAG (e.g. "minimize the path cost using the be used to construct the DODAG (e.g. "minimize the path cost using
ETX metric and avoid 'Blue' links"). The Objective Code Points are the ETX metric and avoid 'Blue' links"). The Objective Code Points
specified in [I-D.ietf-roll-routing-metrics], [I-D.ietf-roll-of0], are specified in [I-D.ietf-roll-routing-metrics],
and related companion specifications. [I-D.ietf-roll-of0], and related companion specifications.
Most Objective Functions are expected to follow the same abstract Most Objective Functions are expected to follow the same abstract
behavior: behavior:
o The parent selection is triggered each time an event indicates o The parent selection is triggered each time an event indicates
that a potential next hop information is updated. This might that a potential next hop information is updated. This might
happen upon the reception of a DIO message, a timer elapse, or a happen upon the reception of a DIO message, a timer elapse, or a
trigger indicating that the state of a candidate neighbor has trigger indicating that the state of a candidate neighbor has
changed. changed.
skipping to change at page 59, line 29 skipping to change at page 60, line 41
(This prevents the creation of a path of sibling links (This prevents the creation of a path of sibling links
connecting a child with its parent.) connecting a child with its parent.)
* To keep loop avoidance and metric optimization in alignment, * To keep loop avoidance and metric optimization in alignment,
the increase in rank should reflect any increase in the metric the increase in rank should reflect any increase in the metric
value. For example, with a purely additive metric such as ETX, value. For example, with a purely additive metric such as ETX,
the increase in rank can be made proportional to the increase the increase in rank can be made proportional to the increase
in the metric. in the metric.
* Candidate neighbors that would cause self's rank to increase * Candidate neighbors that would cause self's rank to increase
are ignored are not considered for parent selection
o Candidate neighbors that advertise an OF incompatible with the set o Candidate neighbors that advertise an OF incompatible with the set
of OF specified by the policy functions are ignored. of OF specified by the policy functions are ignored.
o As it scans all the candidate neighbors, the OF keeps the current o As it scans all the candidate neighbors, the OF keeps the current
best parent and compares its capabilities with the current best parent and compares its capabilities with the current
candidate neighbor. The OF defines a number of tests that are candidate neighbor. The OF defines a number of tests that are
critical to reach the objective. A test between the routers critical to reach the objective. A test between the routers
determines an order relation. determines an order relation.
skipping to change at page 60, line 14 skipping to change at page 61, line 27
o Other rounds of scans might be necessary to elect alternate o Other rounds of scans might be necessary to elect alternate
parents and siblings. In the next rounds: parents and siblings. In the next rounds:
* Candidate neighbors that are not in the same DODAG are ignored * Candidate neighbors that are not in the same DODAG are ignored
* Candidate neighbors that are of greater rank than self are * Candidate neighbors that are of greater rank than self are
ignored ignored
* Candidate neighbors of an equal rank to self (siblings) are * Candidate neighbors of an equal rank to self (siblings) are
ignored ignored for parent selection
* Candidate neighbors of a lesser rank than self (non-siblings) * Candidate neighbors of a lesser rank than self (non-siblings)
are preferred are preferred
11. RPL Constants and Variables 11. RPL Constants and Variables
Following is a summary of RPL constants and variables. Some default Following is a summary of RPL constants and variables.
values are to be determined in companion applicability statements.
ZERO_LIFETIME This is the special value of a lifetime that indicates
immediate death and removal. ZERO_LIFETIME has a value of 0.
BASE_RANK This is the rank for a virtual root that might be used to BASE_RANK This is the rank for a virtual root that might be used to
coordinate multiple roots. BASE_RANK has a value of 0. coordinate multiple roots. BASE_RANK has a value of 0.
ROOT_RANK This is the rank for a DODAG root. ROOT_RANK has a value ROOT_RANK This is the rank for a DODAG root. ROOT_RANK has a value
of 1. of 1.
INFINITE_RANK This is the constant maximum for the rank. INFINITE_RANK This is the constant maximum for the rank.
INFINITE_RANK has a value of 0xFF. INFINITE_RANK has a value of 0xFFFF.
RPL_DEFAULT_INSTANCE This is the RPLInstanceID that is used by this RPL_DEFAULT_INSTANCE This is the RPLInstanceID that is used by this
protocol by a node without any overriding policy. protocol by a node without any overriding policy.
RPL_DEFAULT_INSTANCE has a value of 0. RPL_DEFAULT_INSTANCE has a value of 0.
DEFAULT_DIO_INTERVAL_MIN To be determined DEFAULT_DIO_INTERVAL_MIN TBD (To be determined)
DEFAULT_DIO_INTERVAL_DOUBLINGS To be determined
DEFAULT_DIO_REDUNDANCY_CONSTANT To be determined DEFAULT_DIO_INTERVAL_DOUBLINGS TBD (To be determined)
DEF_DAO_LATENCY To be determined DEFAULT_DIO_REDUNDANCY_CONSTANT TBD (To be determined)
MAX_DESTROY_INTERVAL To be determined
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 5.3.5.1 Section 5.3.5.1
DAG Sequence Number Increment Timer Up to one instance per DODAG DAG Sequence Number Increment Timer Up to one instance per DODAG
that the node is acting as DODAG root of. May not be supported that the node is acting as DODAG root of. May not be supported
in all implementations. Expiry triggers revision of in all implementations. Expiry triggers revision of
DODAGSequenceNumber, causing a new series of updated DIO DODAGSequenceNumber, causing a new series of updated DIO
message to be sent. Interval should be chosen appropriate to message to be sent. Interval should be chosen appropriate to
skipping to change at page 66, line 40 skipping to change at page 68, line 4
To be completed. To be completed.
13. Security Considerations 13. Security Considerations
Security Considerations for RPL are to be developed in accordance Security Considerations for RPL are to be developed in accordance
with recommendations laid out in, for example, with recommendations laid out in, for example,
[I-D.tsao-roll-security-framework]. [I-D.tsao-roll-security-framework].
14. IANA Considerations 14. IANA Considerations
14.1. RPL Control Message 14.1. RPL Control Message
The RPL Control Message is an ICMP information message type that is The RPL Control Message is an ICMP information message type that is
to be used carry DAG Information Objects, DAG Information to be used carry DODAG Information Objects, DODAG Information
Solicitations, and Destination Advertisement Objects in support of Solicitations, and Destination Advertisement Objects in support of
RPL operation. RPL operation.
IANA has defined a ICMPv6 Type Number Registry. The suggested type IANA has defined a ICMPv6 Type Number Registry. The suggested type
value for the RPL Control Message is 155, to be confirmed by IANA. value for the RPL Control Message is 155, to be confirmed by IANA.
14.2. New Registry for RPL Control Codes 14.2. New Registry for RPL Control Codes
IANA is requested to create a registry, RPL Control Codes, for the IANA is requested to create a registry, RPL Control Codes, for the
Code field of the ICMPv6 RPL Control Message. Code field of the ICMPv6 RPL Control Message.
skipping to change at page 67, line 24 skipping to change at page 68, line 33
o Description o Description
o Defining RFC o Defining RFC
Three codes are currently defined: Three codes are currently defined:
+------+----------------------------------+---------------+ +------+----------------------------------+---------------+
| Code | Description | Reference | | Code | Description | Reference |
+------+----------------------------------+---------------+ +------+----------------------------------+---------------+
| 0x01 | DAG Information Solicitation | This document | | 0x01 | DODAG Information Solicitation | This document |
| 0x02 | DAG Information Object | This document | | 0x02 | DODAG Information Object | This document |
| 0x04 | Destination Advertisement Object | This document | | 0x04 | Destination Advertisement Object | This document |
+------+----------------------------------+---------------+ +------+----------------------------------+---------------+
RPL Control Codes RPL Control Codes
14.3. New Registry for the Control Field of the DIO Base 14.3. New Registry for the Control Field of the DIO Base
IANA is requested to create a registry for the Control field of the IANA is requested to create a registry for the Control field of the
DIO Base. DIO Base.
skipping to change at page 68, line 17 skipping to change at page 69, line 20
+-------+-----------------------------------------+---------------+ +-------+-----------------------------------------+---------------+
| 0 | Grounded DODAG (G) | This document | | 0 | Grounded DODAG (G) | This document |
| 1 | Destination Advertisement Supported (A) | This document | | 1 | Destination Advertisement Supported (A) | This document |
| 2 | Destination Advertisement Trigger (T) | This document | | 2 | Destination Advertisement Trigger (T) | This document |
| 3 | Destination Advertisements Stored (S) | This document | | 3 | Destination Advertisements Stored (S) | This document |
| 5,6,7 | DODAG Preference (Prf) | This document | | 5,6,7 | DODAG Preference (Prf) | This document |
+-------+-----------------------------------------+---------------+ +-------+-----------------------------------------+---------------+
DIO Base Flags DIO Base Flags
14.4. DAG Information Object (DIO) Suboption 14.4. DODAG Information Object (DIO) Suboption
IANA is requested to create a registry for the DIO Base Suboptions IANA is requested to create a registry for the DIO Base Suboptions
+-------+------------------------------+---------------+ +-------+------------------------------+---------------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+-------+------------------------------+---------------+ +-------+------------------------------+---------------+
| 0 | Pad1 - DIO Padding | This document | | 0 | Pad1 - DIO Padding | This document |
| 1 | PadN - DIO suboption padding | This document | | 1 | PadN - DIO suboption padding | This document |
| 2 | DAG Metric Container | This Document | | 2 | DAG Metric Container | This Document |
| 3 | Destination Prefix | This Document | | 3 | Destination Prefix | This Document |
| 4 | DAG Timer Configuration | This Document | | 4 | DAG Timer Configuration | This Document |
+-------+------------------------------+---------------+ +-------+------------------------------+---------------+
DAG Information Option (DIO) Base Suboptions DODAG Information Option (DIO) Base Suboptions
15. Acknowledgements 15. Acknowledgements
The authors would like to acknowledge the review, feedback, and The authors would like to acknowledge the review, feedback, and
comments from Emmanuel Baccelli, Dominique Barthel, Yusuf Bashir, comments from Emmanuel Baccelli, Dominique Barthel, Yusuf Bashir,
Mathilde Durvy, Manhar Goindi, Mukul Goyal, Anders Jagd, Quentin Phoebus Chen, Mathilde Durvy, Manhar Goindi, Mukul Goyal, Anders
Lampin, Jerry Martocci, Alexandru Petrescu, and Don Sturek. Jagd, Quentin Lampin, Jerry Martocci, Alexandru Petrescu, and Don
Sturek.
The authors would like to acknowledge the guidance and input provided The authors would like to acknowledge the guidance and input provided
by the ROLL Chairs, David Culler and JP Vasseur. by the ROLL Chairs, David Culler and JP Vasseur.
The authors would like to acknowledge prior contributions of Robert The authors would like to acknowledge prior contributions of Robert
Assimiti, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot, Assimiti, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot,
Patrick Wetterwald, Bryan Mclaughlin, Carlos J. Bernardos, Thomas Patrick Wetterwald, Bryan Mclaughlin, Carlos J. Bernardos, Thomas
Watteyne, Zach Shelby, Caroline Bontoux, Marco Molteni, Billy Moon, Watteyne, Zach Shelby, Caroline Bontoux, Marco Molteni, Billy Moon,
and Arsalan Tavakoli, which have provided useful design and Arsalan Tavakoli, which have provided useful design
considerations to RPL. considerations to RPL.
skipping to change at page 71, line 21 skipping to change at page 72, line 31
(work in progress), January 2010. (work in progress), January 2010.
[I-D.ietf-roll-home-routing-reqs] [I-D.ietf-roll-home-routing-reqs]
Brandt, A. and J. Buron, "Home Automation Routing Brandt, A. and J. Buron, "Home Automation Routing
Requirements in Low Power and Lossy Networks", Requirements in Low Power and Lossy Networks",
draft-ietf-roll-home-routing-reqs-11 (work in progress), draft-ietf-roll-home-routing-reqs-11 (work in progress),
January 2010. January 2010.
[I-D.ietf-roll-of0] [I-D.ietf-roll-of0]
Thubert, P., "RPL Objective Function 0", Thubert, P., "RPL Objective Function 0",
draft-ietf-roll-of0-00 (work in progress), December 2009. draft-ietf-roll-of0-01 (work in progress), February 2010.
[I-D.ietf-roll-routing-metrics] [I-D.ietf-roll-routing-metrics]
Vasseur, J. and D. Networks, "Routing Metrics used for Vasseur, J. and D. Networks, "Routing Metrics used for
Path Calculation in Low Power and Lossy Networks", Path Calculation in Low Power and Lossy Networks",
draft-ietf-roll-routing-metrics-04 (work in progress), draft-ietf-roll-routing-metrics-04 (work in progress),
December 2009. December 2009.
[I-D.ietf-roll-terminology] [I-D.ietf-roll-terminology]
Vasseur, J., "Terminology in Low power And Lossy Vasseur, J., "Terminology in Low power And Lossy
Networks", draft-ietf-roll-terminology-02 (work in Networks", draft-ietf-roll-terminology-02 (work in
skipping to change at page 72, line 5 skipping to change at page 73, line 14
Sensor Networks", Communications of the ACM, v.51 n.7, Sensor Networks", Communications of the ACM, v.51 n.7,
July 2008, July 2008,
<http://portal.acm.org/citation.cfm?id=1364804>. <http://portal.acm.org/citation.cfm?id=1364804>.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering, [RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
"IPv6 Flow Label Specification", RFC 3697, March 2004. "IPv6 Flow Label Specification", RFC 3697, March 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004. RFC 3819, July 2004.
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
June 2005. June 2005.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
skipping to change at page 74, line 7 skipping to change at page 75, line 20
path computation algorithm. path computation algorithm.
A.2. Deferred Requirements A.2. Deferred Requirements
NOTE: RPL is still a work in progress. At this time there remain NOTE: RPL is still a work in progress. At this time there remain
several unsatisfied application requirements, but these are to be several unsatisfied application requirements, but these are to be
addressed as RPL is further specified. addressed as RPL is further specified.
Appendix B. Examples Appendix B. Examples
Consider the example LLN physical topology in Figure 13. In this B.1. DAO Operation When Only the Root Node Stores DAO Information
example the links depicted are all usable L2 links. Suppose that all
links are equally usable, and that the implementation specific policy
function is simply to minimize hops. This LLN physical topology then
yields the DODAG depicted in Figure 14, where the links depicted are
the edges toward DODAG parents. This topology includes one DAG,
rooted by an LBR node (LBR) at rank 1. The LBR node will issue DIO
messages, as governed by a trickle timer. Nodes (11), (12), (13),
have selected (LBR) as their only parent, attached to the DODAG at
rank 2, and periodically multicast DIOs. Node (22) has selected (11)
and (12) in its DODAG parent set, and advertises itself at rank 3.
Node (22) thus has a set of DODAG parents {(11), (12)} and siblings
{((21), (23)}.
(LBR)
/ | \
.---' | `----.
/ | \
(11)------(12)------(13)
| \ | \ | \
| `----. | `----. | `----.
| \| \| \
(21)------(22)------(23) (24)
| /| /| |
| .----' | .----' | |
| / | / | |
(31)------(32)------(33)------(34)
| /| \ | \ | \
| .----' | `----. | `----. | `----.
| / | \| \| \
.--------(41) (42) (43)------(44)------(45)
/ / /| \ | \
.----' .----' .----' | `----. | `----.
/ / / | \| \
(51)------(52)------(53)------(54)------(55)------(56)
Note that the links depicted represent the usable L2 connectivity
available in the LLN. For example, Node (31) can communicate
directly with its neighbors, Nodes (21), (22), (32), and (41). Node
(31) cannot communicate directly with any other nodes, e.g. (33),
(23), (42). In this example these links offer bidirectional
communication, and 'bad' links are not depicted.
Figure 13: Example LLN Topology
(LBR)
/ | \
.---' | `----.
/ | \
(11) (12) (13)
| \ | \ | \
| `----. | `----. | `----.
| \| \| \
(21) (22) (23) (24)
| /| /| |
| .----' | .----' | |
| / | / | |
(31) (32) (33) (34)
| /| \ | \ | \
| .----' | `----. | `----. | `----.
| / | \| \| \
.--------(41) (42) (43) (44) (45)
/ / /| \ | \
.----' .----' .----' | `----. | `----.
/ / / | \| \
(51) (52) (53) (54) (55) (56)
Note that the links depicted represent directed links in the DODAG
overlaid on top of the physical topology depicted in Figure 13. As
such, the depicted edges represent the relationship between nodes and
their DODAG parents, wherein all depicted edges are directed and
oriented 'up' on the page toward the DODAG root (LBR). The DODAG may
provide default routes within the LLN, and serves as the foundation
on which RPL builds further routing structure, e.g. through the
destination advertisement mechanism.
Figure 14: Example DAG Consider the example of Figure 13. In this example only the root
node, (LBR*), will store DAO information. This is not known, nor is
it required to be known, to all nodes a priori. Rather, each node is
able to observe from the state of the 'S' flag that no ancestor, with
the exception of the root node, stores DAO information.
B.1. Destination Advertisement (LBR*)
/ \
/ \
/ \
(11) (12)
| |
| |
| |
(21) (22)
\
\
\
(31)
/ \
/ \
/ \
(41) (42)
: :
Consider the example DODAG depicted in Figure 14. Suppose that Nodes Figure 13: Only Root Node Stores DAOs
(22) and (32) are unable to record routing state. Suppose that Node
(42) is able to perform prefix aggregation on behalf of Nodes (53),
(54), and (55).
o Node (53) would send a DAO message to Node (42), indicating the In this example:
availability of destination (53).
o Node (54) and Node (55) would similarly send DAO messages to Node o The 'S' flag is cleared in DIO messages emitted by (LBR*), because
(42) indicating their own destinations. (LBR*) is the DODAG root.
o Node (42) would collect and store the routing state for o The 'S' flag is cleared in all DIO messages emitted by all other
destinations (53), (54), and (55). nodes, because no other node stores DAO information.
o In this example, Node (42) may then be capable of representing o (LBR*) has learned from DAO messages how to reach node (31) with a
destinations (42), (53), (54), and (55) in the aggregation (42'). source route via {(11) (21)}.
o Node (42) sends a DAO message advertising destination (42') to o All source routes to nodes in the sub-DODAG of node (31),
Node 32. including nodes (41), (42), and others will include the prefix
{(11) (21) (31)}
o Node (32) does not want to maintain any routing state, so it adds o Node (31) maintains a DTSN, (31).DTSN, that it will advertise in
onto to the Reverse Route Stack in the DAO message and passes it DIO messages.
on to Node (22) as (42'):[(42)]. It may send a separate DAO
message to indicate destination (32).
o Node (22) does not want to maintain any routing state, so it adds Suppose now that there is a topology change within the same DODAG
on to the Reverse Route Stack in the DAO message and passes it on iteration, causing node (31) to evict node (21) as a DAO parent and
to Node (12) as (42'):[(42), (32)]. It also relays the DAO add node (22) as a DAO parent:
message containing destination (32) to Node 12 as (32):[(32)], and
finally may send a DAO message for itself indicating destination
(22).
o Node (12) is capable to maintain routing state again, and receives 1. Node (31) will schedule a DAO transmission because it has added a
the DAO messages from Node (22). Node (12) then learns: new node (22) to its DAO parent set.
* Destination (22) is available via Node (22)
* Destination (32) is available via Node (22) and the piecewise
source route to (32)
* Destination (42') is available via Node (22) and the piecewise
source route to (32), (42').
o Node (12) sends DAO messages to (LBR), allowing (LBR) to learn 2. Node (31) need not increment (31).DTSN at this event, because in
routes to the destinations (12), (22), (32), and (42'). (42), this example no DAO parents have the 'S' flag set. Specifically
(53), (54), and (55) are available via the aggregation (42'). It this indicates to Node (31) that there are no intermediate
is not necessary for Node (12) to propagate the piecewise source storing nodes that may need to be explicitly updated with DAO
routes to (LBR). information from it's sub-DODAG. Hence nodes (41), (42), and by
extension the sub-DODAG of node (31) will not subsequently
observe an incremented (31).DTSN and the sub-DODAG will not emit
DAOs.
B.2. Example: DODAG Parent Selection 3. A new flow of DAOs for node (31) reaches the (LBR*), updating the
source route information for node (31) to include the new path
{(12) (22)}.
For example, suppose that a node (N) is not attached to any DAG, and 4. (LBR*) may implicitly update all source routes that must transit
that it is in range of nodes (A), (B), (C), (D), and (E). Let all node (31), i.e. the sub-DODAG of node (31), to use the updated
nodes be configured to use an OCP which defines a policy such that source route prefix {(12) (22)} instead of {(11) (21)}.
ETX is to be minimized and paths with the attribute 'Blue' should be
avoided. Let the rank computation indicated by the OCP simply
reflect the ETX aggregated along the path. Let the links between
node (N) and its neighbors (A-E) all have an ETX of 1 (which is
learned by node (N) through some implementation specific method).
Let node (N) be configured to send RPL DIS messages to probe for
nearby DAGs.
o Node (N) transmits a RPL DIS message. Thus the use of the 'S' flag in the case where only the root node
stores DAO information has allowed an optimization whereby only a DAO
update for the node that changed its DAO parent set, (31), needs to
be sent to the DODAG root.
o Node (B) responds. Node (N) investigates the DIO message, and B.2. DAO Operation When All Nodes Fully Store DAO Information
learns that Node (B) is a member of DODAGID 1 at rank 4, and not
'Blue'. Node (N) takes note of this, but is not yet confident.
o Similarly, Node (N) hears from Node (A) at rank 9, Node (C) at Consider the example of Figure 14. In this example all nodes will
rank 5, and Node (E) at rank 4. fully store DAO information.
o Node (D) responds. Node (D) has a DIO message that indicates that (LBR*)
it is a member of DODAGID 1 at rank 2, but it carries the / \
attribute 'Blue'. Node (N)'s policy function rejects Node (D), / \
and no further consideration is given. / \
(11*) (12*)
| |
| |
| |
(21*) (22*)
\
\
\
(31*)
/ \
/ \
/ \
(41*) (42*)
: :
o This process continues until Node (N), based on implementation Figure 14: All Nodes Store DAOs
specific policy, builds enough confidence to trigger a decision to
join DODAGID 1. Let Node (N) determine its most preferred parent
to be Node (E).
o Node (N) adds Node (E) (rank 4) to its set of DODAG parents for In this example:
DODAGID 1. Following the mechanisms specified by the OCP, and
given that the ETX is 1 for the link between (N) and (E), Node (N)
is now at rank 5 in DODAGID 1.
o Node (N) adds Node (B) (rank 4) to its set of DODAG parents for o The 'S' flag is cleared in DIO messages emitted by (LBR*), because
DODAGID 1. (LBR*) is the DODAG root.
o Node (N) is a sibling of Node (C), both are at rank 5. o The 'S' flag is set in DIO messages emitted by all non-root nodes
because each non-root node stores DAO information.
o Node (N) may now forward traffic intended for the default o Source routing state is effectively not provisioned in this
destination upwards along DODAGID 1 via nodes (B) and (E). In example, because each node has been able to store hop-by-hop
some cases, e.g. if nodes (B) and (E) are tried and fail, node (N) routing state for each destination, possibly aggregated, as
may also choose to forward traffic to its sibling node (C), learned from DAOs. For example, node (11*) will have learned and
without making upwards progress but with the intention that node stored information from a DAO to the effect that node (41*) is
(C) or a following successor can make upwards progress. Should routable through a next hop of node (21*). Node (12*) on the
Node (C) not have a viable parent, it should never send the packet other hand does not necessarily have a route provisioned to node
back to Node (N) (to avoid a 2-node loop). (41*).
B.3. Example: DODAG Maintenance Suppose now that there is a topology change within the same DODAG
iteration, causing node (31*) to evict node (21*) as a DAO parent and
add node (22*) as a DAO parent:
: : : 1. Node (31*) will schedule a DAO transmission because it has added
: : : a new node (22*) to its DAO parent set.
(A) (A) (A)
|\ | |
| `-----. | |
| \ | |
(B) (C) (B) (C) (B)
| | \
| | `-----.
| | \
(D) (D) (C)
|
|
|
(D)
-1- -2- -3- 2. Node (31) need not increment (31).DTSN, because it is a fully
storing node and does not need to trigger DAO information from
its sub-DODAG.
Figure 15: DAG Maintenance 3. Node (31) gives a DAO Update to node (22*). Presuming that node
(22*) has received the update, node (22*) will store the new
entries for routes including the sub-DODAG of node (31*),
including nodes (41*) and (42*). Node (22*) will schedule a DAO
transmission for the new entries.
Consider the example depicted in Figure 15-1. In this example, Node 4. Similarly, node (22*) updates node (12*) and node (12*) updates
(A) is attached to a DODAG at some rank d. Node (A) is a DODAG (LBR*). Hop-by-hop routing state for the sub-DODAG of node (31*)
parent of Nodes (B) and (C). Node (C) is a DODAG parent of Node (D). is now provisioned at nodes (12*) and (22*).
There is also an undirected sibling link between Nodes (B) and (C).
In this example, Node (C) may safely forward to Node (A) without Thus the addition to the DAO Parent set at the fully storing node
creating a loop. Node (C) may not safely forward to Node (D), (31*) does not elicit additional DAO-related traffic from its sub-
contained within it's own sub-DODAG, without creating a loop. Node DODAG. The intermediate nodes along the 'new' downward path are
(C) may forward to Node (B) in some cases, e.g. the link (C)->(A) is updated by DAO messages along the new path.
temporarily unavailable, but with some chance of creating a loop
(e.g. if multiple nodes in a set of siblings start forwarding
'sideways' in a cycle) and requiring the intervention of additional
mechanisms to detect and break the loop.
Consider the case where Node (C) hears a DIO message from a Node (Z) Suppose next that the DODAG root triggers a refresh of DAO
at a lesser rank and superior position in the DODAG than node (A). information over the same DODAG Iteration. (Note that the DODAG root
Node (C) may safely undergo the process to evict node (A) from its might also trigger a DAO refresh but allow other topology changes at
DAG parent set and attach directly to Node (Z) without creating a the same time by incrementing the DODAG Sequence Number to cause a
loop, because its rank will decrease. move to the next DODAG Iteration).:
Now consider the case where the link (C)->(A) becomes nonviable, and 1. (LBR*) will increment its DTSN and issue a DIO with the 'T' flag
node (C) must move to a deeper rank within the DAG: set.
o Node (C) must first detach from the DODAG by removing Node (A) 2. Nodes (11*) and (12*) will increment their own DTSNs in response
from its DODAG parent set, leaving an empty DODAG parent set. to observing in the DIO from LBR a new DTSN and the 'T' flag
Node (C) may become the root of its own floating, less preferred, being set. They will reset their trickle timers to cause the
DAG. issue of new DIOs with the 'T' flag set. These nodes will also
schedule a DAO transmission in response to observing a new DTSN
from their DAO Parent, (LBR*). (This DAO transmission may be
scheduled with a sufficient delay computed based on rank to allow
a chance for the sub-DODAGs of the nodes to report DAO messages
prior to the nodes reporting their own DAO information to (LBR*).
This is implementation specific and may allow a chance for DAO
aggregation.).
o Node (D), hearing a modified DIO message from Node (C), follows 3. Node (21*) receives a DIO from node (11*) and observes the new
Node (C) into the floating DAG. This is depicted in Figure 15-2. (11*).DTSN as well as the set 'T' flag. Node (21*) increments
In general, any node with no other options in the sub-DODAG of its own DTSN, resets the trickle timer, and schedules a DAO
Node (C) will follow Node (C) into the floating DAG, maintaining transmission.
the structure of the sub-DODAG.
o Node (C) hears a DIO message with an incremented 4. Similarly, as each node observes the incremented DTSN with the
DODAGSequenceNumber from Node (B) and determines it is able to 'T' flag set from each of its parents, each node will increment
rejoin the grounded DODAG by reattaching at a deeper rank to Node its own DTSN, reset the DIO trickle timer, and schedule a DAO
(B). Node (C) adds Node (B) to its DODAG parent set. Node (C) transmission.
has now safely moved deeper within the grounded DODAG without
creating any loops.
o Node (D), and any other sub-DODAG of Node (C), will hear the Thus the entire DODAG iteration has been re-armed to send DAO
modified DIO message sourced from Node (C) and follow Node (C) in messages based on the (LBR*)'s assertion of the 'T' flag. Note that
a coordinated manner to reattach to the grounded DAG. The final normally a DTSN increment would cause no further action in a sub-
DODAG is depicted in Figure 15-3 DODAG beyond the first fully storing node that is encountered, but
that in this case the 'T' flag effectively provides a means to 'punch
through' all fully storing nodes.
B.4. Example: Greedy Parent Selection and Instability B.3. DAO Operation When Nodes Have Mixed Capabilities
(A) (A) (A) Consider the example of Figure 15. In this example some nodes are
|\ |\ |\ capable of storing DAO information and some are not.
| `-----. | `-----. | `-----.
| \ | \ | \
(B) (C) (B) \ | (C)
\ | | /
`-----. | | .-----'
\| |/
(C) (B)
-1- -2- -3- (LBR*)
/ \
/ \
/ \
(11) (12*)
| |
| |
| |
(21) (22)
\
\
\
(31)
/ \
/ \
/ \
(41) (42*)
: :
Figure 16: Greedy DODAG Parent Selection Figure 15: Mixed Capability DAO Operation
Consider the example depicted in Figure 16. A DODAG is depicted in 3 In this example:
different configurations. A usable link between (B) and (C) exists
in all 3 configurations. In Figure 16-1, Node (A) is a DODAG parent
for Nodes (B) and (C), and (B)--(C) is a sibling link. In
Figure 16-2, Node (A) is a DODAG parent for Nodes (B) and (C), and
Node (B) is also a DODAG parent for Node (C). In Figure 16-3, Node
(A) is a DODAG parent for Nodes (B) and (C), and Node (C) is also a
DODAG parent for Node (B).
If a RPL node is too greedy, in that it attempts to optimize for an o The 'S' flag is cleared in DIO messages emitted by (LBR*), because
additional number of parents beyond its preferred parent, then an (LBR*) is the DODAG root.
instability can result. Consider the DODAG illustrated in
Figure 16-1. In this example, Nodes (B) and (C) may most prefer Node
(A) as a DODAG parent, but are operating under the greedy condition
that will try to optimize for 2 parents.
When the preferred parent selection causes a node to have only one o The 'S' flag is set in DIO messages emitted by (12*), because it
parent and no siblings, the node may decide to insert itself at a is a storing node.
slightly higher rank in order to have at least one sibling and thus
an alternate forwarding solution. This does not deprive other nodes
of a forwarding solution and this is considered acceptable
greediness.
o Let Figure 16-1 be the initial condition. o The 'S' flag will be set in DIO messages emitted by nodes that
contain node (12*) (or more generally any non-root storing node)
as a DAO parent/ancestor. This indicates that somewhere along the
DAO path there is a non-root storing node that may need to have
its state updated (by a DAO refresh) in certain conditions.
o Suppose Node (C) first is able to leave the DODAG and rejoin at a Suppose that there is a topology change within the same DODAG
lower rank, taking both Nodes (A) and (B) as DODAG parents as iteration, causing node (31) to add node (22) as a DAO parent:
depicted in Figure 16-2. Now Node (C) is deeper than both Nodes
(A) and (B), and Node (C) is satisfied to have 2 DODAG parents.
o Suppose Node (B), in its greediness, is willing to receive and 1. Node (31) will schedule a DAO transmission because it has added a
process a DIO message from Node (C) (against the rules of RPL), new node (22) to its DAO parent set. Node (31) will increment
and then Node (B) leaves the DODAG and rejoins at a lower rank, (31).DTSN because node (22) has set the 'S' flag in its DIO
taking both Nodes (A) and (C) as DODAG parents. Now Node (B) is messages. Node (31) will reset its DIO trickle timer.
deeper than both Nodes (A) and (C) and is satisfied with 2 DAG
parents.
o Then Node (C), because it is also greedy, will leave and rejoin 2. Node (31)'s trickle timer will then expire and a DIO is issued
deeper, to again get 2 parents and have a lower rank then both of and received by node's (41) and (42*).
them.
o Next Node (B) will again leave and rejoin deeper, to again get 2 3. Node (41) is a non-storing node. It will increment (41).DTSN in
parents response to observing the increment in (31).DTSN, and reset its
trickle timer. This results finally in the reliable (thanks to
the DTSN) triggering of a DAO update from node (41)'s sub-DODAG.
o And again Node (C) leaves and rejoins deeper... 4. As node (41) receives DAO updates from its sub-DODAG it updates
the DAOs with source routing information as necessary and passes
them on to node (31), along with its own (node (41)) DAO update.
o The process will repeat, and the DODAG will oscillate between 5. Meanwhile, node (42*) is a fully storing node. It observes the
Figure 16-2 and Figure 16-3 until the nodes count to infinity and increment to (31).DTSN and schedules a DAO update. Node (42*)
restart the cycle again. does not need to increment (42*).DTSN, since it is a fully
storing node it does not need to solicit DAO updates from its
sub-DODAG in this case. At the scheduled time Node (42*)
reissues its DAO information to node (31).
o This cycle can be averted through mechanisms in RPL: 6. Node (31) receives the DAO messages from its sub-DODAG, adds
source routing information as necessary, and issues DAO updates
to node (22).
* Nodes (B) and (C) stay at a rank sufficient to attach to their 7. Node (22) similarly receives DAO messages from node (31), updates
most preferred parent (A) and don't go for any deeper (worse) source routing information as necessary, and issues DAO updates
alternate parents (Nodes are not greedy) to node (12*).
* Nodes (B) and (C) do not process DIO messages from nodes deeper 8. The intermediate storing node (12*) has now received from DAO
than themselves (because such nodes are possibly in their own messages the information necessary to provision routing state for
sub-DODAGs) node (31) and its sub-DODAG. As downwards traffic is routed
through node (12*) it is able to consult source routing
information that was learned from the DAO messages as needed to
specify routes down the DAG across the non-storing nodes (22),
(31), ...
Appendix C. Outstanding Issues Appendix C. Outstanding Issues
This section enumerates some outstanding issues that are to be This section enumerates some outstanding issues that are to be
addressed in future revisions of the RPL specification. addressed in future revisions of the RPL specification.
C.1. Additional Support for P2P Routing C.1. Additional Support for P2P Routing
In some situations the baseline mechanism to support arbitrary P2P In some situations the baseline mechanism to support arbitrary P2P
traffic, by flowing upwards along the DODAG until a common ancestor traffic, by flowing upwards along the DODAG until a common ancestor
is reached and then flowing down, may not be suitable for all is reached and then flowing down, may not be suitable for all
application scenarios. A related scenario may occur when the down application scenarios. A related scenario may occur when the down
paths setup along the DODAG by the destination advertisement paths setup along the DODAG by the destination advertisement
mechanism are not be the most desirable downward paths for the mechanism are not the most desirable downward paths for the specific
specific application scenario (in part because the DODAG links may application scenario (in part because the DODAG links may not be
not be symmetric). It may be desired to support within RPL the symmetric). It may be desired to support within RPL the discovery
discovery and installation of more direct routes 'across' the DAG. and installation of more direct routes 'across' the DAG. Such
Such mechanisms need to be investigated. mechanisms need to be investigated.
C.2. Destination Advertisement / DAO Fan-out C.2. Destination Advertisement / DAO Fan-out
When DAO messages are relayed to more than one DODAG parent, in some When DAO messages are relayed to more than one DODAG parent, in some
cases a situation may be created where a large number of DAO messages cases a situation may be created where a large number of DAO messages
conveying information about the same destination flow upwards along conveying information about the same destination flow upwards along
the DAG. It is desirable to bound/limit the multiplication/fan-out the DAG. It is desirable to bound/limit the multiplication/fan-out
of DAO messages in this manner. Some aspects of the Destination of DAO messages in this manner. Some aspects of the Destination
Advertisement mechanism remain under investigation, such as behavior Advertisement mechanism remain under investigation, such as behavior
in the face of links that may not be symmetric. in the face of links that may not be symmetric.
In general, the utility of providing redundancy along downwards In general, the utility of providing redundancy along downwards
routes by sending DAO messages to more than one parent is under routes by sending DAO messages to more than one parent is under
investigation. investigation.
The use of suitable triggers, such as the 'T' flag, to trigger DA
operation within an affected sub-DODAG, is under investigation.
Further, the ability to limit scope of the affected depth within the
sub-DODAG is under investigation (e.g. if a stateful node can proxy
for all nodes 'behind' it, then there may be no need to propagate the
triggered 'T' flag further).
C.3. Source Routing C.3. Source Routing
In support of nodes that maintain minimal routing state, and to make In support of nodes that maintain minimal routing state, and to make
use of the collection of piecewise source routes from the destination use of the collection of piecewise source routes from the destination
advertisement mechanism, there needs to be some investigation of a advertisement mechanism, there needs to be some investigation of a
mechanism to specify, attach, and follow source routes for packets mechanism to specify, attach, and follow source routes for packets
traversing the LLN. traversing the LLN.
C.4. Address / Header Compression C.4. Address / Header Compression
 End of changes. 154 change blocks. 
525 lines changed or deleted 520 lines changed or added

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