< draft-ietf-roll-efficient-npdao-02.txt   draft-ietf-roll-efficient-npdao-03.txt >
ROLL R. Jadhav, Ed. ROLL R. Jadhav, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track P. Thubert Intended status: Standards Track P. Thubert
Expires: September 22, 2018 Cisco Expires: September 30, 2018 Cisco
R. Sahoo R. Sahoo
Z. Cao Z. Cao
Huawei Huawei
March 21, 2018 March 29, 2018
No-Path DAO modifications Efficient Route Invalidation
draft-ietf-roll-efficient-npdao-02 draft-ietf-roll-efficient-npdao-03
Abstract Abstract
This document describes the problems associated with the use of No- This document describes the problems associated with the use of No-
Path DAO messaging in RPL and a signaling changes to improve route Path DAO messaging in RPL and signaling changes to improve route
invalidation efficiency. invalidation efficiency.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2018. This Internet-Draft will expire on September 30, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language and Terminology . . . . . . . . . . 3 1.1. Requirements Language and Terminology . . . . . . . . . . 3
1.2. Current No-Path DAO messaging . . . . . . . . . . . . . . 3 1.2. Current No-Path DAO messaging . . . . . . . . . . . . . . 4
1.3. Cases when No-Path DAO may be used . . . . . . . . . . . 4 1.3. Cases when No-Path DAO may be used . . . . . . . . . . . 4
1.4. Why No-Path DAO is important? . . . . . . . . . . . . . . 5 1.4. Why No-Path DAO is important? . . . . . . . . . . . . . . 5
2. Problems with current No-Path DAO messaging . . . . . . . . 5 2. Problems with current No-Path DAO messaging . . . . . 5
2.1. Lost NP-DAO due to link break to the previous parent . . 5 2.1. Lost NPDAO due to link break to the previous parent . . . 5
2.2. Invalidate routes to dependent nodes of the switching 2.2. Invalidate routes to dependent nodes of the switching
node . . . . . . . . . . . . . . . . . . . . . . . . . . 5 node . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Route downtime caused by asynchronous operation of 2.3. Route downtime caused by asynchronous operation of
NPDAO and DAO . . . . . . . . . . . . . . . . . . . . . . 6 NPDAO and DAO . . . . . . . . . . . . . . . . . . . . . . 6
3. Requirements for the No-Path DAO Optimization . . . . . . . . 6 3. Requirements for the No-Path DAO Optimization . . . . . . . . 6
3.1. Req#1: Tolerant to the link failures to the previous 3.1. Req#1: Tolerant to link failures to the previous
parents . . . . . . . . . . . . . . . . . . . . . . . . . 6 parents . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Req#2: Dependent nodes route invalidation on parent 3.2. Req#2: Dependent nodes route invalidation on parent
switching . . . . . . . . . . . . . . . . . . . . . . . . 6 switching . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Req#3: No impact on traffic while NP-DAO operation in 3.3. Req#3: No impact on traffic while NPDAO operation in
progress . . . . . . . . . . . . . . . . . . . . . . . . 7 progress . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Proposed changes to RPL signaling . . . . . . . . . . . . . . 7 4. Proposed changes to RPL signaling . . . . . . . . . . . . . . 7
4.1. Change in NPDAO semantics . . . . . . . . . . . . . . . . 7 4.1. Change in RPL route invalidation semantics . . . . . . . 7
4.2. DAO message format changes . . . . . . . . . . . . . . . 7 4.2. DAO message format changes . . . . . . . . . . . . . . . 7
4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 8 4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 8
4.3.1. DCO Options . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. Secure DCO . . . . . . . . . . . . . . . . . . . . . 10
4.3.2. Path Sequence number in the DCO . . . . . . . . . . . 10 4.3.2. DCO Options . . . . . . . . . . . . . . . . . . . . . 10
4.3.3. Destination Cleanup Option Acknowledgement (DCO-ACK) 10 4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 10
4.4. Example messaging . . . . . . . . . . . . . . . . . . . . 11 4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) 10
4.5. Other considerations . . . . . . . . . . . . . . . . . . 12 4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 11
4.5.1. Dependent Nodes invalidation . . . . . . . . . . . . 12 4.4. Other considerations . . . . . . . . . . . . . . . . . . 11
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 4.4.1. Dependent Nodes invalidation . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4.4.2. NPDAO and DCO in the same network . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 14 Appendix A. Example DCO Messaging . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
RPL [RFC6550] specifies a proactive distance-vector based routing RPL [RFC6550] specifies a proactive distance-vector based routing
scheme. The specification has an optional messaging in the form of scheme. The specification has an optional messaging in the form of
DAO messages using which the 6LBR can learn route towards any of the DAO messages using which the 6LBR can learn route towards any of the
nodes. In storing mode, DAO messages would result in routing entries nodes. In storing mode, DAO messages would result in routing entries
been created on all intermediate hops from the node's parent all the been created on all intermediate hops from the node's parent all the
way towards the 6LBR. way towards the 6LBR.
skipping to change at page 3, line 39 skipping to change at page 3, line 46
The document only caters to the RPL's storing mode of operation The document only caters to the RPL's storing mode of operation
(MOP). The non-storing MOP does not require use of NPDAO for route (MOP). The non-storing MOP does not require use of NPDAO for route
invalidation since routing entries are not maintained on 6LRs. invalidation since routing entries are not maintained on 6LRs.
Common Ancestor node: 6LR node which is the first common node on the Common Ancestor node: 6LR node which is the first common node on the
old and new path for the child node. old and new path for the child node.
NPDAO: No-Path DAO. A DAO message which has target with lifetime 0. NPDAO: No-Path DAO. A DAO message which has target with lifetime 0.
DCO: A new RPL control message type defined by this specification and DCO: Destination Cleanup Object, A new RPL control message type
stands for Destination Cleanup Object. defined by this draft.
Regular DAO: A DAO message with non-zero lifetime. Regular DAO: A DAO message with non-zero lifetime.
This document also uses terminology described in [RFC6550]. This document also uses terminology described in [RFC6550].
1.2. Current No-Path DAO messaging 1.2. Current No-Path DAO messaging
RPL introduced No-Path DAO messaging in the storing mode so that the RPL introduced No-Path DAO messaging in the storing mode so that the
node switching its current parent can inform its parents and node switching its current parent can inform its parents and
ancestors to invalidate the existing route. Subsequently parents or ancestors to invalidate the existing route. Subsequently parents or
ancestors would release any resources (such as the routing entry) it ancestors would release any resources (such as the routing entry) it
maintains on behalf of target node. The NPDAO message always maintains on behalf of target node. The NPDAO message always
traverses the RPL tree in upward direction, originating at the target traverses the RPL tree in upward direction, originating at the target
node itself. node itself.
For the rest of this document consider the following topology: For the rest of this document consider the following topology:
(6LBR) (6LBR)
| |
| |
| |
(A) (A)
/ \
/ \
/ \
(G) (H)
| |
| |
| |
(B) (C)
\ ;
\ ;
\ ;
(D)
/ \ / \
/ \ / \
/ \ / \
(G) (H) (E) (F)
| |
| |
| |
(B) (C)
\ ;
\ ;
\ ;
(D)
/ \
/ \
/ \
(E) (F)
Figure 1: Sample topology Figure 1: Sample topology
Node (D) is connected via preferred parent (B). (D) has an alternate Node (D) is connected via preferred parent (B). (D) has an alternate
path via (C) towards the BR. Node (A) is the common ancestor for (D) path via (C) towards the BR. Node (A) is the common ancestor for (D)
for paths through (B)-(G) and (C)-(H). When (D) switches from (B) to for paths through (B)-(G) and (C)-(H). When (D) switches from (B) to
(C), [RFC6550] suggests sending No-Path DAO to (B) and regular DAO to (C), [RFC6550] suggests sending No-Path DAO to (B) and regular DAO to
(C). (C).
1.3. Cases when No-Path DAO may be used 1.3. Cases when No-Path DAO may be used
skipping to change at page 5, line 30 skipping to change at page 5, line 36
necessary to have efficient route invalidation mechanism. Also note necessary to have efficient route invalidation mechanism. Also note
that a single parent switch may result in a "sub-tree" switching from that a single parent switch may result in a "sub-tree" switching from
one parent to another. Thus the route invalidation needs to be done one parent to another. Thus the route invalidation needs to be done
on behalf of the sub-tree and not the switching node alone. In the on behalf of the sub-tree and not the switching node alone. In the
above example, when Node (D) switches parent, the route invalidation above example, when Node (D) switches parent, the route invalidation
needs to be done for (D), (E) and (F). Thus without efficient route needs to be done for (D), (E) and (F). Thus without efficient route
invalidation, a 6LR may have to hold a lot of unwanted route entries. invalidation, a 6LR may have to hold a lot of unwanted route entries.
2. Problems with current No-Path DAO messaging 2. Problems with current No-Path DAO messaging
2.1. Lost NP-DAO due to link break to the previous parent 2.1. Lost NPDAO due to link break to the previous parent
When a node switches its parent, the NPDAO is to be sent via its When a node switches its parent, the NPDAO is to be sent via its
previous parent and a regular DAO via its new parent. In cases where previous parent and a regular DAO via its new parent. In cases where
the node switches its parent because of transient or permanent parent the node switches its parent because of transient or permanent parent
link/node failure then the NPDAO message is bound to fail. RPL link/node failure then the NPDAO message is bound to fail. RPL
assumes communication link with the previous parent for No-Path DAO assumes communication link with the previous parent for No-Path DAO
messaging. messaging.
RPL allows use of route lifetime to remove unwanted routes in case RPL allows use of route lifetime to remove unwanted routes in case
the routes could not be refreshed. But route lifetimes in case of the routes could not be refreshed. But route lifetimes in case of
LLNs could be substantially high and thus the route entries would be LLNs could be substantially high and thus the route entries would be
stuck for long. stuck for longer times.
2.2. Invalidate routes to dependent nodes of the switching node 2.2. Invalidate routes to dependent nodes of the switching node
No-path DAO is sent by the node who has switched the parent but it No-path DAO is sent by the node who has switched the parent but it
does not work for the dependent child nodes below it. The does not work for the dependent child nodes below it. The
specification does not specify how route invalidation will work for specification does not specify how route invalidation will work for
sub-childs, resulting in stale routing entries on behalf of the sub- sub-childs, resulting in stale routing entries on behalf of the sub-
childs on the previous route. The only way for 6LR to invalidate the childs on the previous route. The only way for 6LR to invalidate the
route entries for dependent nodes would be to use route lifetime route entries for dependent nodes would be to use route lifetime
expiry which could be substantially high for LLNs. expiry which could be substantially high for LLNs.
skipping to change at page 6, line 28 skipping to change at page 6, line 38
via the new path gets lost on the way. This may result in route via the new path gets lost on the way. This may result in route
downtime thus impacting downward traffic for the switching node. In downtime thus impacting downward traffic for the switching node. In
the example topology, consider Node (D) switches from parent (B) to the example topology, consider Node (D) switches from parent (B) to
(C) because the metrics of the path via (C) are better. Note that (C) because the metrics of the path via (C) are better. Note that
the previous path via (B) may still be available (albeit at the previous path via (B) may still be available (albeit at
relatively bad metrics). An NPDAO sent from previous route may relatively bad metrics). An NPDAO sent from previous route may
invalidate the existing route whereas there is no way to determine invalidate the existing route whereas there is no way to determine
whether the new DAO has successfully updated the route entries on the whether the new DAO has successfully updated the route entries on the
new path. new path.
An implementation technique to avoid this problem is to further delay
the route invalidation by a fixed time interval after receiving an
NPDAO, considering the time taken for the new path to be established.
Coming up with such a time interval is tricky since the new route may
also not be available and it may subsequently require more parent
switches to establish a new path.
3. Requirements for the No-Path DAO Optimization 3. Requirements for the No-Path DAO Optimization
3.1. Req#1: Tolerant to the link failures to the previous parents 3.1. Req#1: Tolerant to link failures to the previous parents
When the switching node send the NP-DAO message to the previous When the switching node send the NPDAO message to the previous
parent, it is normal that the link to the previous parent is prone to parent, it is normal that the link to the previous parent is prone to
failure. Therefore, it is required that the NP-DAO message MUST be failure. Therefore, it is required that the NPDAO message MUST be
tolerant to the link failure during the switching. tolerant to the link failure during the switching.
3.2. Req#2: Dependent nodes route invalidation on parent switching 3.2. Req#2: Dependent nodes route invalidation on parent switching
While switching the parent node and sending NP-DAO message, it is While switching the parent node and sending NPDAO message, it is
required that the routing entries to the dependent nodes of the required that the routing entries to the dependent nodes of the
switching node will be updated accordingly on the previous parents switching node will be updated accordingly on the previous parents
and other relevant upstream nodes. and other relevant upstream nodes.
3.3. Req#3: No impact on traffic while NP-DAO operation in progress 3.3. Req#3: No impact on traffic while NPDAO operation in progress
While sending the NP-DAO and DAO messages, it is possible that the While sending the NPDAO and DAO messages, it is possible that the
NP-DAO successfully invalidates the previous path, while the newly NPDAO successfully invalidates the previous path, while the newly
sent DAO gets lost (new path not set up successfully). This will sent DAO gets lost (new path not set up successfully). This will
result into downstream unreachability to the current switching node. result into downstream unreachability to the current switching node.
Therefore, it is desirable that the NP-DAO is synchronized with the Therefore, it is desirable that the NPDAO is synchronized with the
DAO to avoid the risk of route downtime. DAO to avoid the risk of route downtime.
4. Proposed changes to RPL signaling 4. Proposed changes to RPL signaling
4.1. Change in NPDAO semantics 4.1. Change in RPL route invalidation semantics
As described in Section 1.2, the NPDAO originates at the node As described in Section 1.2, the NPDAO originates at the node
switching the parent and traverses upstream towards the root. In switching the parent and traverses upstream towards the root. In
order to solve the problems as mentioned in Section 2, the draft order to solve the problems as mentioned in Section 2, the draft adds
proposes to add new pro-active route invalidation message called as new pro-active route invalidation message called as "Destination
"Destination Cleanup Object" (DCO) that originates at a common Cleanup Object" (DCO) that originates at a common ancestor node
ancestor node between the new and old path. The trigger for the between the new and old path. The trigger for the common ancestor
common ancestor node to generate this DCO is the change in the next node to generate this DCO is the change in the next hop for the
hop for the target on reception of an update message in the form of target on reception of an update message in the form of regular DAO
regular DAO for the target. for the target.
In the Figure 1, when node D decides to switch the path from B to C, In the Figure 1, when node D decides to switch the path from B to C,
it sends a regular DAO to node C with reachability information it sends a regular DAO to node C with reachability information
containing target as address of D and a incremented path sequence containing target as address of D and a incremented path sequence
number. Node C will update the routing table based on the number. Node C will update the routing table based on the
reachability information in DAO and in turn generate another DAO with reachability information in DAO and in turn generate another DAO with
the same reachability information and forward it to H. Node H also the same reachability information and forward it to H. Node H also
follows the same procedure as Node C and forwards it to node A. When follows the same procedure as Node C and forwards it to node A. When
node A receives the regular DAO, it finds that it already has a node A receives the regular DAO, it finds that it already has a
routing table entry on behalf of the target address of node D. It routing table entry on behalf of the target address of node D. It
skipping to change at page 8, line 14 skipping to change at page 8, line 14
targets. Similarly, a Transit Information option may be associated targets. Similarly, a Transit Information option may be associated
with a set of RPL Target options. with a set of RPL Target options.
The draft proposes a change in DAO message to contain "Invalidate The draft proposes a change in DAO message to contain "Invalidate
previous route" (I) bit. This I-bit which is carried in regular DAO previous route" (I) bit. This I-bit which is carried in regular DAO
message, signals the common ancestor node to generate a DCO on behalf message, signals the common ancestor node to generate a DCO on behalf
of the target node. The I-bit is carried in the transit container of the target node. The I-bit is carried in the transit container
option which augments the reachability information for a given set of option which augments the reachability information for a given set of
RPL Target(s). RPL Target(s).
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 = 0x06 | Option Length |E|I| Flags | Path Control | | Type = 0x06 | Option Length |E|I| Flags | Path Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Sequence | Path Lifetime | | | Path Sequence | Path Lifetime | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
+ + + +
| | | |
+ Parent Address* + + Parent Address* +
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Updated Transit Information Option (New I flag added) Figure 2: Updated Transit Information Option (New I flag added)
I (Invalidate previous route) bit: 1 bit flag. The 'I' flag is set I (Invalidate previous route) bit: 1 bit flag. The 'I' flag is set
by the target node to indicate that it wishes to invalidate the by the target node to indicate that it wishes to invalidate the
previous route by a common ancestor node between the two paths. previous route by a common ancestor node between the two paths.
The common ancestor node SHOULD generate a DCO message in response to
this I-bit when it sees that the routing adjacencies have changed for
the target. I-bit governs the ownership of the DCO message in a way
that the target node is still in control of its own route
invalidation.
4.3. Destination Cleanup Object (DCO) 4.3. Destination Cleanup Object (DCO)
A new ICMPv6 RPL control message type is defined by this A new ICMPv6 RPL control message type is defined by this
specification called as "Destination Cleanup Object" (DCO), which is specification called as "Destination Cleanup Object" (DCO), which is
used for proactive cleanup of state and routing information held on used for proactive cleanup of state and routing information held on
behalf of the target node by 6LRs. The DCO message always traverses behalf of the target node by 6LRs. The DCO message always traverses
downstream and cleans up route information and other state downstream and cleans up route information and other state
information associated with the given target. information associated with the given target.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |K|D| Flags | Reserved | DCOSequence | | RPLInstanceID |K|D| Flags | Reserved | DCOSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ DODAGID(optional) + + DODAGID(optional) +
| | | |
+ + + +
| | | |
skipping to change at page 9, line 47 skipping to change at page 9, line 47
by the sender and MUST be ignored by the receiver. by the sender and MUST be ignored by the receiver.
DCOSequence: Incremented at each unique DCO message from a node and DCOSequence: Incremented at each unique DCO message from a node and
echoed in the DCO-ACK message. echoed in the DCO-ACK message.
DODAGID (optional): 128-bit unsigned integer set by a DODAG root that DODAGID (optional): 128-bit unsigned integer set by a DODAG root that
uniquely identifies a DODAG. This field is only present when the 'D' uniquely identifies a DODAG. This field is only present when the 'D'
flag is set. This field is typically only present when a local flag is set. This field is typically only present when a local
RPLInstanceID is in use, in order to identify the DODAGID that is RPLInstanceID is in use, in order to identify the DODAGID that is
associated with the RPLInstanceID. When a global RPLInstanceID is in associated with the RPLInstanceID. When a global RPLInstanceID is in
use, this field need not be present. Unassigned bits of the DAO Base use, this field need not be present. Unassigned bits of the DCO Base
are reserved. They MUST be set to zero on transmission and MUST be are reserved. They MUST be set to zero on transmission and MUST be
ignored on reception. ignored on reception.
4.3.1. DCO Options 4.3.1. Secure DCO
A Secure DCO message follows the format in [RFC6550] figure 7, where
the base message format is the DCO message shown in Figure 3.
4.3.2. DCO Options
The DCO message MAY carry valid options. This specification allows The DCO message MAY carry valid options. This specification allows
for the DCO message to carry the following options: for the DCO message to carry the following options:
0x00 Pad1 0x00 Pad1
0x01 PadN 0x01 PadN
0x05 RPL Target 0x05 RPL Target
0x06 Transit Information 0x06 Transit Information
0x09 RPL Target Descriptor 0x09 RPL Target Descriptor
The DCO carries a Target option and an associated Transit Information The DCO carries a Target option and an associated Transit Information
option with a lifetime of 0x00000000 to indicate a loss of option with a lifetime of 0x00000000 to indicate a loss of
reachability to that Target. reachability to that Target.
4.3.2. Path Sequence number in the DCO 4.3.3. Path Sequence number in the DCO
A DCO message may contain a Path Sequence in the transit information A DCO message may contain a Path Sequence in the transit information
option to identify the freshness of the DCO message. The Path option to identify the freshness of the DCO message. The Path
Sequence in the DCO and should use the same Path Sequence number Sequence in the DCO MUST use the same Path Sequence number present in
present in the regular DAO message when the DCO is generated in the regular DAO message when the DCO is generated in response to DAO
response to DAO message. message.
4.3.3. Destination Cleanup Option Acknowledgement (DCO-ACK) 4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK)
The DCO-ACK message is sent as a unicast packet by a DCO recipient in The DCO-ACK message may be sent as a unicast packet by a DCO
response to a unicast DCO message. recipient in response to a unicast DCO message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |D| Reserved | DCOSequence | Status | | RPLInstanceID |D| Reserved | DCOSequence | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ DODAGID(optional) + + DODAGID(optional) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: DCO-ACK base object Figure 4: DCO-ACK base object
RPLInstanceID: 8-bit field indicating the topology instance RPLInstanceID: 8-bit field indicating the topology instance
associated with the DODAG, as learned from the DIO. associated with the DODAG, as learned from the DIO.
D: The 'D' flag indicates that the DODAGID field is present. This D: The 'D' flag indicates that the DODAGID field is present. This
flag MUST be set when a local RPLInstanceID is used. flag MUST be set when a local RPLInstanceID is used.
Reserved: 7-bit unused field. The field MUST be initialized to zero Reserved: 7-bit unused field. The field MUST be initialized to zero
skipping to change at page 11, line 23 skipping to change at page 11, line 26
Status: Indicates the completion. Status 0 is defined as unqualified Status: Indicates the completion. Status 0 is defined as unqualified
acceptance in this specification. The remaining status values are acceptance in this specification. The remaining status values are
reserved as rejection codes. reserved as rejection codes.
DODAGID (optional): 128-bit unsigned integer set by a DODAG root that DODAGID (optional): 128-bit unsigned integer set by a DODAG root that
uniquely identifies a DODAG. This field is only present when the 'D' uniquely identifies a DODAG. This field is only present when the 'D'
flag is set. This field is typically only present when a local flag is set. This field is typically only present when a local
RPLInstanceID is in use, in order to identify the DODAGID that is RPLInstanceID is in use, in order to identify the DODAGID that is
associated with the RPLInstanceID. When a global RPLInstanceID is in associated with the RPLInstanceID. When a global RPLInstanceID is in
use, this field need not be present. Unassigned bits of the DAO Base use, this field need not be present. Unassigned bits of the DCO-Ack
are reserved. They MUST be set to zero on transmission and MUST be Base are reserved. They MUST be set to zero on transmission and MUST
ignored on reception. be ignored on reception.
4.4. Example messaging
In Figure 1, node (D) switches its parent from (B) to (C). The
sequence of actions is as follows:
1. Node D switches its parent from node B to node C 4.3.5. Secure DCO-ACK
2. D sends a regular DAO(tgt=D,pathseq=x+1,I_flag=1) in the updated
path to C
3. C checks for routing entry on behalf of D, since it cannot find
an entry on behalf of D it creates a new routing entry and
forwards the reachability information of the target D to H in a
DAO.
4. Similar to C, node H checks for routing entry on behalf of D,
cannot find an entry and hence creates a new routing entry and
forwards the reachability information of the target D to H in a
DAO.
5. Node A receives the DAO, and checks for routing entry on behalf
of D. It finds a routing entry but checks that the next hop for
target D is now changed. Node A checks the I_flag and generates
DCO(tgt=D,pathseq=pathseq(DAO)) to previous next hop for target D
which is G. Subsequently, A updates the routing entry and
forwards the reachability information of target D upstream
DAO(tgt=D,pathseq=x+1,I_flag=x) (the I_flag carries no
significance henceforth).
6. Node G receives the DCO and invalidates routing entry of target D
and forwards the (un)reachability information downstream to B.
7. Similarly, B processes the DCO by invalidating the routing entry A Secure DCO-ACK message follows the format in [RFC6550] figure 7,
of target D and forwards the (un)reachability information where the base message format is the DCO-ACK message shown in
downstream to D. Figure 4.
8. D ignores the DCO since the target is itself.
9. The propagation of the DCO will stop at any node where the node
does not have an routing information associated with the target.
If the routing information is present and the pathseq associated
is not older, then still the DCO is dropped.
4.5. Other considerations 4.4. Other considerations
4.5.1. Dependent Nodes invalidation 4.4.1. Dependent Nodes invalidation
Current RPL [RFC6550] does not provide a mechanism for route Current RPL [RFC6550] does not provide a mechanism for route
invalidation for dependent nodes. invalidation for dependent nodes. This document allows the dependent
nodes invalidation. Dependent nodes will generate their respective
This section describes approaches for invalidating routes of DAOs to update their paths, and the previous route invalidation for
dependent nodes if the implementation chooses to solve this problem. those nodes should work in the similar manner described for switching
The common ancestor node realizes that the paths for dependent nodes node. The dependent node may set the I-bit in the transit
have changed (based on next hop change) when it receives a regular information container as part of regular DAO so as to request
DAO on behalf of the dependent nodes. Thus dependent nodes route invalidation of previous route from the common ancestor node.
invalidation can be handled in the same way as the switching node.
Note that there is no way that dependent nodes can set the I_flag in
the DAO message selectively since they are unaware that their parent/
grand parent node is switching paths. There are two ways to handle
dependent node route invalidation:
1. One way to resolve is that the common ancestor does not depend 4.4.2. NPDAO and DCO in the same network
upon the I_flag to generate the reverse NPDAO. The only factor
it makes the decision will be based on next_hop change for an
existing target to generate the NPDAO. Thus when the switching
nodes and all the below dependent nodes advertise a regular DAO,
the common ancestor node will detect a change in next hop and
generate NPDAO for the same target as in the regular DAO.
2. Another way is that the nodes always set the I_flag whenever they
send regular DAO. Thus common ancestor will first check whether
I_flag is set and then check whether the next_hop has changed and
subsequently trigger DCO if required.
This document recommends the approach in point 2. The advantage with Even with the changed semantics, the current NPDAO mechanism in
I_flag is that the generation of downstream NPDAO is still controlled [RFC6550] can still be used. There are certain scenarios where
by the target node and thus is still in control of its own routing current NPDAO signalling may still be used, for example, when the
state. route lifetime expiry of the target happens or when the node simply
decides to gracefully terminate the RPL session on graceful node
shutdown. Moreover a deployment can have a mix of nodes supporting
the proposed DCO and the existing NPDAO mechanism.
5. Acknowledgements 5. Acknowledgements
We would like to thank Cenk Gundogan, Simon Duquennoy and Pascal We would like to thank Cenk Gundogan and Simon Duquennoy for their
Thubert for their review and comments. review and comments.
6. IANA Considerations 6. IANA Considerations
IANA is requested to allocate new ICMPv6 RPL control codes in RPL IANA is requested to allocate new ICMPv6 RPL control codes in RPL
[RFC6550] for DCO and DCO-ACK messages. [RFC6550] for DCO and DCO-ACK messages.
+------+--------------------------------------------+---------------+ +------+---------------------------------------------+--------------+
| Code | Description | Reference | | Code | Description | Reference |
+------+--------------------------------------------+---------------+ +------+---------------------------------------------+--------------+
| 0x85 | Destination Cleanup Object | This document | | 0x04 | Destination Cleanup Object | This |
| 0x86 | Destination Cleanup Object Acknowledgement | This document | | | | document |
+------+--------------------------------------------+---------------+ | 0x05 | Destination Cleanup Object Acknowledgement | This |
| | | document |
| 0x84 | Secure Destination Cleanup Object | This |
| | | document |
| 0x85 | Secure Destination Cleanup Object | This |
| | Acknowledgement | document |
+------+---------------------------------------------+--------------+
IANA is requested to allocate bit 18 in the Transit Information IANA is requested to allocate bit 18 in the Transit Information
Option defined in RPL [RFC6550] section 6.7.8 for Invalidate route Option defined in RPL [RFC6550] section 6.7.8 for Invalidate route
'I' flag. 'I' flag.
7. Security Considerations 7. Security Considerations
The secure versions of DCO and DCO-ACK also have to be considered in This document handles security considerations inline to base RPL.
the future. The seucrity considerations applicable to DAO, DAO-ACK Secure versions of DCO and DCO-ACK are added similar to other RPL
messaging in RPL is also applicable here. messages. For general RPL security considerations, see [RFC6550].
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work
in progress), November 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
8.2. Informative References 8.2. Informative References
[CONTIKI] Thingsquare, "Contiki: The Open Source OS for IoT", 2012, [I-D.ietf-6tisch-architecture]
<http://www.contiki-os.org>. Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work
in progress), November 2017.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Appendix A. Example DCO Messaging
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
Appendix A. Additional Stuff In Figure 1, node (D) switches its parent from (B) to (C). The
sequence of actions is as follows:
This becomes an Appendix. 1. Node D switches its parent from node B to node C
2. D sends a regular DAO(tgt=D,pathseq=x+1,I_flag=1) in the updated
path to C
3. C checks for routing entry on behalf of D, since it cannot find
an entry on behalf of D it creates a new routing entry and
forwards the reachability information of the target D to H in a
DAO.
4. Similar to C, node H checks for routing entry on behalf of D,
cannot find an entry and hence creates a new routing entry and
forwards the reachability information of the target D to H in a
DAO.
5. Node A receives the DAO, and checks for routing entry on behalf
of D. It finds a routing entry but checks that the next hop for
target D is now changed. Node A checks the I_flag and generates
DCO(tgt=D,pathseq=pathseq(DAO)) to previous next hop for target D
which is G. Subsequently, A updates the routing entry and
forwards the reachability information of target D upstream
DAO(tgt=D,pathseq=x+1,I_flag=x) (the I_flag carries no
significance henceforth).
6. Node G receives the DCO and invalidates routing entry of target D
and forwards the (un)reachability information downstream to B.
7. Similarly, B processes the DCO by invalidating the routing entry
of target D and forwards the (un)reachability information
downstream to D.
8. D ignores the DCO since the target is itself.
9. The propagation of the DCO will stop at any node where the node
does not have an routing information associated with the target.
If the routing information is present and the pathseq associated
is not older, then still the DCO is dropped.
Authors' Addresses Authors' Addresses
Rahul Arvind Jadhav (editor) Rahul Arvind Jadhav (editor)
Huawei Huawei
Kundalahalli Village, Whitefield, Kundalahalli Village, Whitefield,
Bangalore, Karnataka 560037 Bangalore, Karnataka 560037
India India
Phone: +91-080-49160700 Phone: +91-080-49160700
Email: rahul.ietf@gmail.com Email: rahul.ietf@gmail.com
Pascal Thubert Pascal Thubert
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
MOUGINS - Sophia Antipolis 06254 MOUGINS - Sophia Antipolis 06254
FRANCE France
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
Rabi Narayan Sahoo Rabi Narayan Sahoo
Huawei Huawei
Kundalahalli Village, Whitefield, Kundalahalli Village, Whitefield,
Bangalore, Karnataka 560037 Bangalore, Karnataka 560037
India India
 End of changes. 57 change blocks. 
187 lines changed or deleted 180 lines changed or added

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