< draft-ietf-roll-efficient-npdao-03.txt   draft-ietf-roll-efficient-npdao-04.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 30, 2018 Cisco Expires: January 20, 2019 Cisco
R. Sahoo R. Sahoo
Z. Cao Z. Cao
Huawei Huawei
March 29, 2018 July 19, 2018
Efficient Route Invalidation Efficient Route Invalidation
draft-ietf-roll-efficient-npdao-03 draft-ietf-roll-efficient-npdao-04
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 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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 30, 2018. This Internet-Draft will expire on January 20, 2019.
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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
2. Problems with current No-Path DAO messaging . . . . . 5 2. Problems with current No-Path DAO messaging . . . . . 5
2.1. Lost NPDAO 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 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 . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Req#3: No impact on traffic while NPDAO 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 RPL route invalidation semantics . . . . . . . 7 4.1. Change in RPL route invalidation semantics . . . . . . . 7
4.2. DAO message format changes . . . . . . . . . . . . . . . 7 4.2. DAO message format changes . . . . . . . . . . . . . . . 8
4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 8 4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 9
4.3.1. Secure DCO . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. Secure DCO . . . . . . . . . . . . . . . . . . . . . 10
4.3.2. DCO Options . . . . . . . . . . . . . . . . . . . . . 10 4.3.2. DCO Options . . . . . . . . . . . . . . . . . . . . . 10
4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 10 4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 10
4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) 10 4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) 10
4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 11 4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 11
4.4. Other considerations . . . . . . . . . . . . . . . . . . 11 4.4. Other considerations . . . . . . . . . . . . . . . . . . 12
4.4.1. Dependent Nodes invalidation . . . . . . . . . . . . 11 4.4.1. Dependent Nodes invalidation . . . . . . . . . . . . 12
4.4.2. NPDAO and DCO in the same network . . . . . . . . . . 12 4.4.2. NPDAO and DCO in the same network . . . . . . . . . . 12
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Example DCO Messaging . . . . . . . . . . . . . . . 13 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
skipping to change at page 6, line 42 skipping to change at page 6, line 42
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.
3. Requirements for the No-Path DAO Optimization 3. Requirements for the No-Path DAO Optimization
3.1. Req#1: Tolerant to link failures to the previous parents 3.1. Req#1: Tolerant to link failures to the previous parents
When the switching node send the NPDAO message to the previous When the switching node sends 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 NPDAO 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. The link referred
here represents the link between the node and its previous parent
(from whom the node is now disassociating).
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 NPDAO 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 NPDAO operation in progress 3.3. Req#3: No impact on traffic while NPDAO operation in progress
skipping to change at page 7, line 23 skipping to change at page 7, line 30
4. Proposed changes to RPL signaling 4. Proposed changes to RPL signaling
4.1. Change in RPL route invalidation 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 adds order to solve the problems as mentioned in Section 2, the draft adds
new pro-active route invalidation message called as "Destination new pro-active route invalidation message called as "Destination
Cleanup Object" (DCO) that originates at a common ancestor node Cleanup Object" (DCO) that originates at a common ancestor node
between the new and old path. The trigger for the common ancestor between the new and old path. The common ancestor node generates a
node to generate this DCO is the change in the next hop for the DCO in response to the change in the next-hop on receiving a regular
target on reception of an update message in the form of regular DAO 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 12, line 17 skipping to change at page 12, line 30
Even with the changed semantics, the current NPDAO mechanism in Even with the changed semantics, the current NPDAO mechanism in
[RFC6550] can still be used. There are certain scenarios where [RFC6550] can still be used. There are certain scenarios where
current NPDAO signalling may still be used, for example, when the current NPDAO signalling may still be used, for example, when the
route lifetime expiry of the target happens or when the node simply route lifetime expiry of the target happens or when the node simply
decides to gracefully terminate the RPL session on graceful node decides to gracefully terminate the RPL session on graceful node
shutdown. Moreover a deployment can have a mix of nodes supporting shutdown. Moreover a deployment can have a mix of nodes supporting
the proposed DCO and the existing NPDAO mechanism. the proposed DCO and the existing NPDAO mechanism.
5. Acknowledgements 5. Acknowledgements
We would like to thank Cenk Gundogan and Simon Duquennoy for their Many thanks to Cenk Gundogan, Simon Duquennoy, and Georgios
review and comments. Papadopoulous for their 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 |
+------+---------------------------------------------+--------------+ +------+---------------------------------------------+--------------+
| 0x04 | Destination Cleanup Object | This | | 0x04 | Destination Cleanup Object | This |
skipping to change at page 13, line 4 skipping to change at page 13, line 15
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 document handles security considerations inline to base RPL. This document handles security considerations inline to base RPL.
Secure versions of DCO and DCO-ACK are added similar to other RPL Secure versions of DCO and DCO-ACK are added similar to other RPL
messages. For general RPL security considerations, see [RFC6550]. messages. For general RPL security considerations, see [RFC6550].
8. References 8. References
8.1. Normative References 8.1. Normative References
[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
[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-13 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-14 (work
in progress), November 2017. in progress), April 2018.
Appendix A. Example DCO Messaging Appendix A. Example DCO 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
 End of changes. 14 change blocks. 
21 lines changed or deleted 23 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/