draft-ietf-roll-efficient-npdao-06.txt | draft-ietf-roll-efficient-npdao-07.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: March 30, 2019 Cisco | Expires: March 31, 2019 Cisco | |||
R. Sahoo | R. Sahoo | |||
Z. Cao | Z. Cao | |||
Huawei | Huawei | |||
September 26, 2018 | September 27, 2018 | |||
Efficient Route Invalidation | Efficient Route Invalidation | |||
draft-ietf-roll-efficient-npdao-06 | draft-ietf-roll-efficient-npdao-07 | |||
Abstract | Abstract | |||
This document describes the problems associated with the use of NPDAO | This document describes the problems associated with the use of NPDAO | |||
messaging in RPL and signaling changes to improve route invalidation | messaging in RPL and signaling changes to improve route invalidation | |||
efficiency. | 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 March 30, 2019. | This Internet-Draft will expire on March 31, 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 | |||
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 | |||
1.1. Requirements Language and Terminology . . . . . . . . . . 3 | 1.1. Requirements Language and Terminology . . . . . . . . . . 3 | |||
1.2. Current NPDAO messaging . . . . . . . . . . . . . . . . . 3 | 1.2. Current NPDAO messaging . . . . . . . . . . . . . . . . . 4 | |||
1.3. Why NPDAO is important? . . . . . . . . . . . . . . . . . 4 | 1.3. Why NPDAO is important? . . . . . . . . . . . . . . . . . 4 | |||
2. Problems with current NPDAO messaging . . . . . . . . 5 | 2. Problems with current NPDAO 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 . . . . . . . . . . 5 | 2.2. Invalidate routes to dependent nodes . . . . . . . . . . 5 | |||
2.3. Possible route downtime caused by async operation of | 2.3. Possible route downtime caused by async operation of | |||
NPDAO and DAO . . . . . . . . . . . . . . . . . . . . . . 5 | NPDAO and DAO . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. Requirements for the NPDAO Optimization . . . . . . . . . . . 5 | 3. Requirements for the NPDAO Optimization . . . . . . . . . . . 5 | |||
3.1. Req#1: Tolerant to link failures to the previous | 3.1. Req#1: Tolerant to link failures to the previous | |||
parents . . . . . . . . . . . . . . . . . . . . . . . . . 5 | parents . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.2. Req#2: Dependent nodes route invalidation on parent | 3.2. Req#2: Dependent nodes route invalidation on parent | |||
skipping to change at page 2, line 36 ¶ | skipping to change at page 2, line 36 ¶ | |||
4.2. Transit Information Option changes . . . . . . . . . . . 7 | 4.2. Transit Information Option changes . . . . . . . . . . . 7 | |||
4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 8 | 4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 8 | |||
4.3.1. Secure DCO . . . . . . . . . . . . . . . . . . . . . 9 | 4.3.1. Secure DCO . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.3.2. DCO Options . . . . . . . . . . . . . . . . . . . . . 9 | 4.3.2. DCO Options . . . . . . . . . . . . . . . . . . . . . 9 | |||
4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 9 | 4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 9 | |||
4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) 9 | 4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) 9 | |||
4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 10 | 4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 10 | |||
4.4. Other considerations . . . . . . . . . . . . . . . . . . 11 | 4.4. Other considerations . . . . . . . . . . . . . . . . . . 11 | |||
4.4.1. Dependent Nodes invalidation . . . . . . . . . . . . 11 | 4.4.1. Dependent Nodes invalidation . . . . . . . . . . . . 11 | |||
4.4.2. NPDAO and DCO in the same network . . . . . . . . . . 11 | 4.4.2. NPDAO and DCO in the same network . . . . . . . . . . 11 | |||
4.4.3. DCO with multiple preferred parents . . . . . . . . . 11 | ||||
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 | 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 12 | 8.2. Informative References . . . . . . . . . . . . . . . . . 12 | |||
Appendix A. Example DCO Messaging . . . . . . . . . . . . . . . 12 | Appendix A. Example DCO Messaging . . . . . . . . . . . . . . . 13 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
1. Introduction | 1. Introduction | |||
RPL [RFC6550] specifies a proactive distance-vector based routing | RPL [RFC6550] specifies a proactive distance-vector based routing | |||
scheme. RPL has an optional messaging in the form of DAO messages | scheme. RPL has an optional messaging in the form of DAO | |||
using which the 6LBR can learn route towards the nodes. In storing | (Destination Advertisement Object) messages using which the 6LBR can | |||
mode, DAO messages would result in routing entries been created on | learn route towards the nodes. In storing mode, DAO messages would | |||
all intermediate hops from the node's parent all the way towards the | result in routing entries been created on all intermediate hops from | |||
6LBR. | the node's parent all the 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 NPDAO is a DAO message with route | resources utilized on that path. A NPDAO is a DAO message with route | |||
lifetime of zero, originates at the target node and always flows | lifetime of zero, originates at the target node and always flows | |||
upstream towards the 6LBR. This document explains the problems | upstream towards the 6LBR. This document explains the problems | |||
associated with the current use of NPDAO messaging and also discusses | associated with the current use of NPDAO messaging and also discusses | |||
the requirements for an optimized route invalidation messaging | the requirements for an optimized route invalidation messaging | |||
scheme. Further a new pro-active route invalidation message called | scheme. Further a new pro-active route invalidation message called | |||
as "Destination Cleanup Object (DCO)" is specified which fulfills | as "Destination Cleanup Object (DCO)" is specified which fulfills | |||
requirements of an optimized route invalidation messaging. | requirements of an optimized route invalidation messaging. | |||
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 | ||||
invalidation since routing entries are not maintained on 6LRs. | ||||
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 | DAO: Destination Advertisement Object | |||
(MOP). The non-storing MOP does not require use of NPDAO for route | ||||
invalidation since routing entries are not maintained on 6LRs. | DIO: DODAG Information Object | |||
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: Destination Cleanup Object, A new RPL control message type | DCO: Destination Cleanup Object, A new RPL control message type | |||
defined by this draft. | defined by this draft. | |||
Regular DAO: A DAO message with non-zero lifetime. | Regular DAO: A DAO message with non-zero lifetime. | |||
skipping to change at page 5, line 46 ¶ | skipping to change at page 5, line 52 ¶ | |||
to (C). An NPDAO sent from previous route may invalidate the | to (C). An NPDAO sent from previous route may invalidate the | |||
existing route whereas there is no way to determine whether the new | existing route whereas there is no way to determine whether the new | |||
DAO has successfully updated the route entries on the new path. | DAO has successfully updated the route entries on the new path. | |||
3. Requirements for the NPDAO Optimization | 3. Requirements for the NPDAO 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 sends 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 route invalidation does | |||
tolerant to the link failure. The link referred here represents the | not depend on the previous link which is prone to failure. The | |||
link between the node and its previous parent (from whom the node is | previous link referred here represents the link between the node and | |||
now disassociating). | 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 | |||
It should be possible to do route invalidation for dependent nodes | It should be possible to do route invalidation for dependent nodes | |||
rooted at the switching node. | rooted at the switching node. | |||
3.3. Req#3: Route invalidation should not impact data traffic | 3.3. Req#3: Route invalidation should not impact data traffic | |||
While sending the NPDAO and DAO messages, it is possible that the | While sending the NPDAO and DAO messages, it is possible that the | |||
NPDAO successfully invalidates the previous path, while the newly | NPDAO successfully invalidates the previous path, while the newly | |||
skipping to change at page 7, line 19 ¶ | skipping to change at page 7, line 19 ¶ | |||
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 Transit Information option to contain | The draft proposes a change in Transit Information option to contain | |||
"Invalidate previous route" (I) bit. This I-bit signals the common | "Invalidate previous route" (I) bit. This I-bit signals the common | |||
ancestor node to generate a DCO on behalf of the target node. The | ancestor node to generate a DCO on behalf of the target node. The | |||
I-bit is carried in the transit information option which augments the | I-bit is carried in the transit information option which augments the | |||
reachability information for a given set of RPL Target(s). | reachability information for a given set of RPL Target(s). Transit | |||
information option should be carried in the DAO message with I-bit | ||||
set in case route invalidation is sought for the correspondig | ||||
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 9, line 37 ¶ | skipping to change at page 9, line 37 ¶ | |||
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.3. 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 MUST use the same Path Sequence number present in | Sequence in the DCO MUST use the same Path Sequence number present in | |||
the regular DAO message when the DCO is generated in response to DAO | the regular DAO message when the DCO is generated in response to DAO | |||
message. | message. The DAO and DCO path sequence are picked from the same | |||
sequence number set. Thus if a DCO is received by a 6LR and | ||||
subsequently a DAO is received with old seqeunce number, then the DAO | ||||
should be ignored. | ||||
4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) | 4.3.4. Destination Cleanup Option Acknowledgement (DCO-ACK) | |||
The DCO-ACK message may be sent as a unicast packet by a DCO | The DCO-ACK message may be sent as a unicast packet by a DCO | |||
recipient in 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 | | |||
skipping to change at page 11, line 21 ¶ | skipping to change at page 11, line 21 ¶ | |||
nodes invalidation. Dependent nodes will generate their respective | nodes invalidation. Dependent nodes will generate their respective | |||
DAOs to update their paths, and the previous route invalidation for | DAOs to update their paths, and the previous route invalidation for | |||
those nodes should work in the similar manner described for switching | those nodes should work in the similar manner described for switching | |||
node. The dependent node may set the I-bit in the transit | node. The dependent node may set the I-bit in the transit | |||
information option as part of regular DAO so as to request | information option as part of regular DAO so as to request | |||
invalidation of previous route from the common ancestor node. | invalidation of previous route from the common ancestor node. | |||
4.4.2. NPDAO and DCO in the same network | 4.4.2. NPDAO and DCO in the same network | |||
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, for example, when the route lifetime | |||
current NPDAO signalling may still be used, for example, when the | expiry of the target happens or when the node simply decides to | |||
route lifetime expiry of the target happens or when the node simply | gracefully terminate the RPL session on graceful node shutdown. | |||
decides to gracefully terminate the RPL session on graceful node | Moreover a deployment can have a mix of nodes supporting the proposed | |||
shutdown. Moreover a deployment can have a mix of nodes supporting | DCO and the existing NPDAO mechanism. | |||
the proposed DCO and the existing NPDAO mechanism. | ||||
4.4.3. DCO with multiple preferred parents | ||||
[RFC6550] allows a node to select multiple preferred parents for | ||||
route establishment. DCO can be used for route invalidation in such | ||||
cases as well. There are no changes required in the DCO messaging to | ||||
support multiple preferred parents and DCO should work seemlessly in | ||||
such scenarios. | ||||
5. Acknowledgements | 5. Acknowledgements | |||
Many thanks to Cenk Gundogan, Simon Duquennoy, Georgios | Many thanks to Cenk Gundogan, Simon Duquennoy, Georgios | |||
Papadopoulous, Peter Van Der Stok for their review and comments. | Papadopoulous, Peter Van Der Stok 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. | |||
skipping to change at page 12, line 4 ¶ | skipping to change at page 12, line 17 ¶ | |||
+------+---------------------------------------------+--------------+ | +------+---------------------------------------------+--------------+ | |||
| 0x04 | Destination Cleanup Object | This | | | 0x04 | Destination Cleanup Object | This | | |||
| | | document | | | | | document | | |||
| 0x05 | Destination Cleanup Object Acknowledgement | This | | | 0x05 | Destination Cleanup Object Acknowledgement | This | | |||
| | | document | | | | | document | | |||
| 0x84 | Secure Destination Cleanup Object | This | | | 0x84 | Secure Destination Cleanup Object | This | | |||
| | | document | | | | | document | | |||
| 0x85 | Secure Destination Cleanup Object | This | | | 0x85 | Secure Destination Cleanup Object | This | | |||
| | Acknowledgement | document | | | | 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 | |||
This document handles security considerations inline to base RPL. | The document adds new messages (DCO, DCO-ACK) which are similar to | |||
Secure versions of DCO and DCO-ACK are added similar to other RPL | existing RPL messages such as DAO, DAO-ACK. Secure versions of DCO | |||
messages. For general RPL security considerations, see [RFC6550]. | and DCO-ACK are added similar to other RPL messages (such as DAO, | |||
DAO-ACK). 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>. | |||
End of changes. 16 change blocks. | ||||
29 lines changed or deleted | 49 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |