draft-ietf-roll-efficient-npdao-00.txt   draft-ietf-roll-efficient-npdao-01.txt 
ROLL R. Jadhav, Ed. ROLL R. Jadhav, Ed.
Internet-Draft R. Sahoo Internet-Draft R. Sahoo
Intended status: Standards Track Z. Cao Intended status: Standards Track Z. Cao
Expires: December 28, 2017 Huawei Tech Expires: April 20, 2018 Huawei Tech
June 26, 2017 October 17, 2017
No-Path DAO modifications No-Path DAO modifications
draft-ietf-roll-efficient-npdao-00 draft-ietf-roll-efficient-npdao-01
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 a 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 http://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 December 28, 2017. This Internet-Draft will expire on April 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (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 . . . . . . . . . . . . . . . . . . . . . . . . 2
skipping to change at page 2, line 25 skipping to change at page 2, line 25
node . . . . . . . . . . . . . . . . . . . . . . . . . . 5 node . . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 the 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 NP-DAO operation in
progress . . . . . . . . . . . . . . . . . . . . . . . . 6 progress . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Proposed changes to NPDAO signaling . . . . . . . . . . . . . 7 4. Proposed changes to RPL signaling . . . . . . . . . . . . . . 7
4.1. Change in NPDAO semantics . . . . . . . . . . . . . . . . 7 4.1. Change in NPDAO semantics . . . . . . . . . . . . . . . . 7
4.2. DAO message format changes . . . . . . . . . . . . . . . 7 4.2. DAO message format changes . . . . . . . . . . . . . . . 7
4.2.1. Path Sequence number in the reverse NPDAO . . . . . . 9 4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 8
4.3. Example messaging . . . . . . . . . . . . . . . . . . . . 9 4.3.1. DCO Options . . . . . . . . . . . . . . . . . . . . . 10
4.4. Other considerations . . . . . . . . . . . . . . . . . . 10 4.3.2. Path Sequence number in the DCO . . . . . . . . . . . 10
4.4.1. Dependent Nodes invalidation . . . . . . . . . . . . 10 4.3.3. Destination Cleanup Option Acknowledgement (DCO-ACK) 10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 4.4. Example messaging . . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4.5. Other considerations . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4.5.1. Dependent Nodes invalidation . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 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.
RPL allows use of No-Path DAO (NPDAO) messaging to invalidate a RPL allows use of No-Path DAO (NPDAO) messaging to invalidate a
routing path corresponding to the given target, thus releasing routing path corresponding to the given target, thus releasing
resources utilized on that path. A No-Path DAO is a DAO message with resources utilized on that path. A No-Path DAO is a DAO message with
route lifetime of zero, signaling route invalidation for the given route lifetime of zero, originates at the target node and always
target. This document explains the problems associated with the flows upstream towards the 6LBR, signaling route invalidation for the
current use of NPDAO messaging and also discusses the requirements given target. This document explains the problems associated with
for an optimized No-Path DAO messaging scheme. The signalling change the current use of NPDAO messaging and also discusses the
specified fulfills all mentioned requirements of an optimized NPDAO requirements for an optimized No-Path DAO messaging scheme. Further
messaging. a new pro-active route invalidation message called as "Destination
Cleanup Object (DCO)" is specified which fulfills all mentioned
requirements of an optimized route invalidation messaging.
6TiSCH architecture [I-D.ietf-6tisch-architecture] leverages RPL and 6TiSCH architecture [I-D.ietf-6tisch-architecture] leverages RPL and
specifies use of non-storing and storing MOP for its routing specifies use of non-storing and storing MOP for its routing
operation. Thus an improvement in NPDAO messaging will help optimize operation. Thus an improvement in route invalidation will help
6TiSCH based networks. optimize 6TiSCH based networks.
1.1. Requirements Language and Terminology 1.1. Requirements Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
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.
Reverse NPDAO: A No-Path DAO message which traverses downstream in DCO: A new RPL control message type defined by this specification and
the network. stands for Destination Cleanup Object.
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
skipping to change at page 6, line 49 skipping to change at page 7, line 4
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 NP-DAO operation in progress
While sending the NP-DAO and DAO messages, it is possible that the While sending the NP-DAO and DAO messages, it is possible that the
NP-DAO successfully invalidates the previous path, while the newly NP-DAO 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 NP-DAO is synchronized with the
DAO to avoid the risk of route downtime. DAO to avoid the risk of route downtime.
4. Proposed changes to NPDAO signaling 4. Proposed changes to RPL signaling
4.1. Change in NPDAO semantics 4.1. Change in NPDAO semantics
As described in Section 1.2, currently the NPDAO originates at the As described in Section 1.2, the NPDAO originates at the node
node switching the parent and traverses upstream towards the root. switching the parent and traverses upstream towards the root. In
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
proposes to change the way NPDAO originates and traverses the proposes to add new pro-active route invalidation message called as
network. The proposed NPDAO originates at a common ancestor node "Destination Cleanup Object" (DCO) that originates at a common
between the new and old path. The trigger for the common ancestor ancestor node between the new and old path. The trigger for the
node to generate this NPDAO is the change in the next hop for the common ancestor node to generate this DCO is the change in the next
node on reception of an update message in the form of regular DAO for hop for the target on reception of an update message in the form of
the target. regular DAO 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
finds however that the next hop information for reaching node D has finds however that the next hop information for reaching node D has
changed i.e. the node D has decided to change the paths. In this changed i.e. the node D has decided to change the paths. In this
case, Node A which is the common ancestor node for node D along the case, Node A which is the common ancestor node for node D along the
two paths (previous and new), may generate an NPDAO which traverses two paths (previous and new), may generate a DCO which traverses
downwards in the network. The document in the subsequent section downwards in the network. The document in the subsequent section
will explain the message format changes to handle this downward flow will explain the message format changes to handle this downward flow
of NPDAO. of NPDAO.
4.2. DAO message format changes 4.2. DAO message format changes
Every RPL message is divided into base message fields and additional Every RPL message is divided into base message fields and additional
Options. The base fields apply to the message as a whole and options Options. The base fields apply to the message as a whole and options
are appended to add message/use-case specific attributes. As an are appended to add message/use-case specific attributes. As an
example, a DAO message may be attributed by one or more "RPL Target" example, a DAO message may be attributed by one or more "RPL Target"
options which specifies the reachability information for the given options which specifies the reachability information for the given
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 downstream message, signals the common ancestor node to generate a DCO on behalf
NPDAO on behalf of the target node. The I-bit is carried in the of the target node. The I-bit is carried in the transit container
transit container option which augments the reachability information option which augments the reachability information for a given set of
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
+ + + +
skipping to change at page 8, line 27 skipping to change at page 8, line 29
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 NPDAO thus generated by the common ancestor node needs to 4.3. Destination Cleanup Object (DCO)
traverse downstream. An additional flag called as "Reverse NPDAO"
(R) is added in the base DAO object to signal this change. A new ICMPv6 RPL control message type is defined by this
specification called as "Destination Cleanup Object" (DCO), which is
used for proactive cleanup of state and routing information held on
behalf of the target node by 6LRs. The DCO message always traverses
downstream and cleans up route information and other state
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|R| Flags | Reserved | DAOSequence | | RPLInstanceID |K|D| Flags | Reserved | DCOSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ DODAGID* + + DODAGID(optional) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3: Updated DAO base object (New R flag added) Figure 3: DCO base object
R (Reverse DAO) bit: 1 bit flag. The 'R' flag is used to signal that RPLInstanceID: 8-bit field indicating the topology instance
the DAO traverses downwards. associated with the DODAG, as learned from the DIO.
4.2.1. Path Sequence number in the reverse NPDAO K: The 'K' flag indicates that the recipient is expected to send a
DCO-ACK back.
Every DAO message may contain a Path Sequence in the transit D: The 'D' flag indicates that the DODAGID field is present. This
information option to identify the freshness of the DAO message. The flag MUST be set when a local RPLInstanceID is used.
Path Sequence in the downward NPDAO generated by common ancestor
should use the same Path Sequence number present in the regular DAO
message.
4.3. Example messaging Flags: The 6 bits remaining unused in the Flags field are reserved
for flags. The field MUST be initialized to zero by the sender and
MUST be ignored by the receiver.
Reserved: 8-bit unused field. The field MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
DCOSequence: Incremented at each unique DCO message from a node and
echoed in the DCO-ACK message.
DODAGID (optional): 128-bit unsigned integer set by a DODAG root that
uniquely identifies a DODAG. This field is only present when the 'D'
flag is set. This field is typically only present when a local
RPLInstanceID is in use, in order to identify the DODAGID that is
associated with the RPLInstanceID. When a global RPLInstanceID is in
use, this field need not be present. Unassigned bits of the DAO Base
are reserved. They MUST be set to zero on transmission and MUST be
ignored on reception.
4.3.1. DCO Options
The DCO message MAY carry valid options. This specification allows
for the DCO message to carry the following options:
0x00 Pad1
0x01 PadN
0x05 RPL Target
0x06 Transit Information
0x09 RPL Target Descriptor
The DCO carries a Target option and an associated Transit Information
option with a lifetime of 0x00000000 to indicate a loss of
reachability to that Target.
4.3.2. Path Sequence number in the DCO
A DCO message may contain a Path Sequence in the transit information
option to identify the freshness of the DCO message. The Path
Sequence in the DCO and should use the same Path Sequence number
present in the regular DAO message when the DCO is generated in
response to DAO message.
4.3.3. Destination Cleanup Option Acknowledgement (DCO-ACK)
The DCO-ACK message is sent as a unicast packet by a DCO recipient in
response to a unicast DCO message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |D| Reserved | DCOSequence | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID(optional) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: DCO-ACK base object
RPLInstanceID: 8-bit field indicating the topology instance
associated with the DODAG, as learned from the DIO.
D: The 'D' flag indicates that the DODAGID field is present. This
flag MUST be set when a local RPLInstanceID is used.
Reserved: 7-bit unused field. The field MUST be initialized to zero
by the sender and MUST be ignored by the receiver.
DCOSequence: Incremented at each unique DCO message from a node and
echoed in the DCO-ACK message.
Status: Indicates the completion. Status 0 is defined as unqualified
acceptance in this specification. The remaining status values are
reserved as rejection codes.
DODAGID (optional): 128-bit unsigned integer set by a DODAG root that
uniquely identifies a DODAG. This field is only present when the 'D'
flag is set. This field is typically only present when a local
RPLInstanceID is in use, in order to identify the DODAGID that is
associated with the RPLInstanceID. When a global RPLInstanceID is in
use, this field need not be present. Unassigned bits of the DAO Base
are reserved. They MUST be set to zero on transmission and MUST be
ignored on reception.
4.4. Example messaging
In Figure 1, node (D) switches its parent from (B) to (C). The In Figure 1, node (D) switches its parent from (B) to (C). The
sequence of actions is as follows: sequence of actions is as follows:
1. Node D switches its parent from node B to node C 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 2. D sends a regular DAO(tgt=D,pathseq=x+1,I_flag=1) in the updated
path to C path to C
3. C checks for routing entry on behalf of D, since it cannot find 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 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 forwards the reachability information of the target D to H in a
DAO. DAO.
4. Similar to C, node H checks for routing entry on behalf of D, 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 cannot find an entry and hence creates a new routing entry and
forwards the reachability information of the target D to H in a forwards the reachability information of the target D to H in a
DAO. DAO.
5. Node A receives the DAO, and checks for routing entry on behalf 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 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 target D is now changed. Node A checks the I_flag and generates
downstream NPDAO(tgt=D,pathseq=x+1,R_flag=1) to previous next hop DCO(tgt=D,pathseq=pathseq(DAO)) to previous next hop for target D
for target D which is G. Subsequently, A updates the routing which is G. Subsequently, A updates the routing entry and
entry and forwards the reachability information of target D forwards the reachability information of target D upstream
upstream DAO(tgt=D,pathseq=x+1,I_flag=x) (the I_flag carries no DAO(tgt=D,pathseq=x+1,I_flag=x) (the I_flag carries no
significance henceforth). significance henceforth).
6. Node G receives the DCO and invalidates routing entry of target D
and forwards the (un)reachability information downstream to B.
6. Node G receives the downstream NPDAO and invalidates routing 7. Similarly, B processes the DCO by invalidating the routing entry
entry of target D and then checks the reverse (R) flag and of target D and forwards the (un)reachability information
forwards the (un)reachability information downstream to B. downstream to D.
8. D ignores the DCO since the target is itself.
7. Similarly, B processes the downstream NPDAO by invalidating the 9. The propagation of the DCO will stop at any node where the node
routing entry of target D and then checks the reverse (R) flag does not have an routing information associated with the target.
and forwards the (un)reachability information downstream to D. If the routing information is present and the pathseq associated
is not older, then still the DCO is dropped.
8. D ignores the downstream NPDAO since the target is itself.
4.4. Other considerations 4.5. Other considerations
4.4.1. Dependent Nodes invalidation 4.5.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 section describes approaches for invalidating routes of This section describes approaches for invalidating routes of
dependent nodes if the implementation chooses to solve this problem. dependent nodes if the implementation chooses to solve this problem.
The common ancestor node realizes that the paths for dependent nodes The common ancestor node realizes that the paths for dependent nodes
have changed (based on next hop change) when it receives a regular have changed (based on next hop change) when it receives a regular
DAO on behalf of the dependent nodes. Thus dependent nodes route DAO on behalf of the dependent nodes. Thus dependent nodes route
invalidation can be handled in the same way as the switching node. invalidation can be handled in the same way as the switching node.
skipping to change at page 10, line 30 skipping to change at page 12, line 39
grand parent node is switching paths. There are two ways to handle grand parent node is switching paths. There are two ways to handle
dependent node route invalidation: dependent node route invalidation:
1. One way to resolve is that the common ancestor does not depend 1. One way to resolve is that the common ancestor does not depend
upon the I_flag to generate the reverse NPDAO. The only factor 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 it makes the decision will be based on next_hop change for an
existing target to generate the NPDAO. Thus when the switching existing target to generate the NPDAO. Thus when the switching
nodes and all the below dependent nodes advertise a regular DAO, nodes and all the below dependent nodes advertise a regular DAO,
the common ancestor node will detect a change in next hop and the common ancestor node will detect a change in next hop and
generate NPDAO for the same target as in the regular DAO. 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 2. Another way is that the nodes always set the I_flag whenever they
send regular DAO. Thus common ancestor will first check whether send regular DAO. Thus common ancestor will first check whether
I_flag is set and then check whether the next_hop has changed and I_flag is set and then check whether the next_hop has changed and
subsequently trigger NPDAO if required. subsequently trigger DCO if required.
This document recommends the approach in point 2. The advantage with This document recommends the approach in point 2. The advantage with
I_flag is that the generation of downstream NPDAO is still controlled I_flag is that the generation of downstream NPDAO is still controlled
by the target node and thus is still in control of its own routing by the target node and thus is still in control of its own routing
state. state.
5. Acknowledgements 5. Acknowledgements
We would like to thank Cenk Gundogan, Simon Duquennoy and Pascal We would like to thank Cenk Gundogan, Simon Duquennoy and Pascal
Thubert for their review and insightful comments. Thubert for their review and comments.
6. IANA Considerations 6. IANA Considerations
IANA is requested to allocate bit 11 in the DAO base object defined IANA is requested to allocate new ICMPv6 RPL control codes in RPL
in RPL [RFC6550] section 6.4 for reverse 'R' NPDAO flag. [RFC6550] for DCO and DCO-ACK messages.
+------+--------------------------------------------+---------------+
| Code | Description | Reference |
+------+--------------------------------------------+---------------+
| 0x85 | Destination Cleanup Object | This document |
| 0x86 | Destination Cleanup Object Acknowledgement | This 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
This draft does not add any new messages but extends existing The secure versions of DCO and DCO-ACK also have to be considered in
messaging. The seucrity considerations applicable to DAO messaging the future. The seucrity considerations applicable to DAO, DAO-ACK
in RPL is also applicable here. messaging in RPL is also applicable here.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-12 (work
in progress), January 2017. in progress), August 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,
<http://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,
<http://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, [CONTIKI] Thingsquare, "Contiki: The Open Source OS for IoT", 2012,
<http://www.contiki-os.org>. <http://www.contiki-os.org>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<http://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
Appendix A. Additional Stuff Appendix A. Additional Stuff
This becomes an Appendix. This becomes an Appendix.
Authors' Addresses Authors' Addresses
Rahul Arvind Jadhav (editor) Rahul Arvind Jadhav (editor)
Huawei Tech Huawei Tech
Kundalahalli Village, Whitefield, Kundalahalli Village, Whitefield,
 End of changes. 41 change blocks. 
91 lines changed or deleted 191 lines changed or added

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