draft-ietf-roll-efficient-npdao-13.txt | draft-ietf-roll-efficient-npdao-14.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: January 1, 2020 Cisco | Expires: January 4, 2020 Cisco | |||
R. Sahoo | R. Sahoo | |||
Z. Cao | Z. Cao | |||
Huawei | Huawei | |||
June 30, 2019 | July 3, 2019 | |||
Efficient Route Invalidation | Efficient Route Invalidation | |||
draft-ietf-roll-efficient-npdao-13 | draft-ietf-roll-efficient-npdao-14 | |||
Abstract | Abstract | |||
This document explains the problems associated with the current use | This document explains the problems associated with the current use | |||
of NPDAO messaging and also discusses the requirements for an | of NPDAO messaging and also discusses the requirements for an | |||
optimized route invalidation messaging scheme. Further a new | optimized route invalidation messaging scheme. Further a new | |||
proactive route invalidation message called as "Destination Cleanup | proactive route invalidation message called as "Destination Cleanup | |||
Object" (DCO) is specified which fulfills requirements of an | Object" (DCO) is specified which fulfills requirements of an | |||
optimized route invalidation messaging. | optimized route invalidation messaging. | |||
skipping to change at page 1, line 39 ¶ | skipping to change at page 1, line 39 ¶ | |||
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 January 1, 2020. | This Internet-Draft will expire on January 4, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 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 49 ¶ | skipping to change at page 2, line 49 ¶ | |||
4.6.1. Dependent Nodes invalidation . . . . . . . . . . . . 13 | 4.6.1. Dependent Nodes invalidation . . . . . . . . . . . . 13 | |||
4.6.2. NPDAO and DCO in the same network . . . . . . . . . . 13 | 4.6.2. NPDAO and DCO in the same network . . . . . . . . . . 13 | |||
4.6.3. DCO with multiple preferred parents . . . . . . . . . 14 | 4.6.3. DCO with multiple preferred parents . . . . . . . . . 14 | |||
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 | 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | |||
6.1. New Registry for the Destination Cleanup Object (DCO) | 6.1. New Registry for the Destination Cleanup Object (DCO) | |||
Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
6.2. New Registry for the Destination Cleanup Object | 6.2. New Registry for the Destination Cleanup Object | |||
Acknowledgment (DCO-ACK) Status field . . . . . . . . . . 16 | Acknowledgment (DCO-ACK) Status field . . . . . . . . . . 16 | |||
6.3. New Registry for the Destination Cleanup Object (DCO) | 6.3. New Registry for the Destination Cleanup Object (DCO) | |||
Acknowledgment Flags . . . . . . . . . . . . . . . . . . 16 | Acknowledgment Flags . . . . . . . . . . . . . . . . . . 17 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | |||
8. Normative References . . . . . . . . . . . . . . . . . . . . 18 | 8. Normative References . . . . . . . . . . . . . . . . . . . . 18 | |||
Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 18 | Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 19 | |||
A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 19 | A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 19 | |||
A.2. Example DCO Messaging with multiple preferred parents . . 20 | A.2. Example DCO Messaging with multiple preferred parents . . 20 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
1. Introduction | 1. Introduction | |||
RPL [RFC6550] (Routing Protocol for Low power and lossy networks) | RPL [RFC6550] (Routing Protocol for Low power and lossy networks) | |||
specifies a proactive distance-vector based routing scheme. RPL has | specifies a proactive distance-vector based routing scheme. RPL has | |||
optional messaging in the form of DAO (Destination Advertisement | optional messaging in the form of DAO (Destination Advertisement | |||
Object) messages, which the 6LBR (6Lo Border Router) and 6LR (6Lo | Object) messages, which the 6LBR (6Lo Border Router) and 6LR (6Lo | |||
skipping to change at page 14, line 51 ¶ | skipping to change at page 14, line 51 ¶ | |||
i.e., the common ancestor can wait for updated DAOs from all possible | i.e., the common ancestor can wait for updated DAOs from all possible | |||
directions before initiating a DCO for route invalidation. After | directions before initiating a DCO for route invalidation. After | |||
timeout, the DCO needs to be generated for all the next-hops for whom | timeout, the DCO needs to be generated for all the next-hops for whom | |||
the route invalidation needs to be done. | the route invalidation needs to be done. | |||
This document recommends using a DelayDCO timer value of 1sec. This | This document recommends using a DelayDCO timer value of 1sec. This | |||
value is inspired by the default DelayDAO value of 1sec in [RFC6550]. | value is inspired by the default DelayDAO value of 1sec in [RFC6550]. | |||
Here the hypothesis is that the DAOs from all possible parent sets | Here the hypothesis is that the DAOs from all possible parent sets | |||
would be received on the common ancestor within this time period. | would be received on the common ancestor within this time period. | |||
It is still possible that a DCO is generated before all the updated | ||||
DAOs from all the paths are received. In this case, the ancestor | ||||
node would start the invalidation procedure for paths from which the | ||||
updated DAO is not received. The DCO generated in this case would | ||||
start invalidating the segments along these paths on which the | ||||
updated DAOs are not received. But once the DAO reaches these | ||||
segments, the routing state would be updated along these segments and | ||||
should not lead to any inconsistent routing state. | ||||
Note that there is no requirement for synchronization between DCO and | Note that there is no requirement for synchronization between DCO and | |||
DAOs. The DelayDCO timer simply ensures that the DCO control | DAOs. The DelayDCO timer simply ensures that the DCO control | |||
overhead can be reduced and is only needed when the network contains | overhead can be reduced and is only needed when the network contains | |||
nodes using multiple preferred parent. | nodes using multiple preferred parent. | |||
5. Acknowledgments | 5. Acknowledgments | |||
Many thanks to Alvaro Retana, Cenk Gundogan, Simon Duquennoy, | Many thanks to Alvaro Retana, Cenk Gundogan, Simon Duquennoy, | |||
Georgios Papadopoulous, Peter Van Der Stok for their review and | Georgios Papadopoulous, Peter Van Der Stok for their review and | |||
comments. Alvaro Retana helped shape this document's final version | comments. Alvaro Retana helped shape this document's final version | |||
skipping to change at page 16, line 41 ¶ | skipping to change at page 16, line 50 ¶ | |||
+------------+----------------------------------------+-------------+ | +------------+----------------------------------------+-------------+ | |||
| Status | Description | Reference | | | Status | Description | Reference | | |||
| Code | | | | | Code | | | | |||
+------------+----------------------------------------+-------------+ | +------------+----------------------------------------+-------------+ | |||
| 0 | Unqualified acceptance | This | | | 0 | Unqualified acceptance | This | | |||
| | | document | | | | | document | | |||
| 1 | No routing-entry for the indicated | This | | | 1 | No routing-entry for the indicated | This | | |||
| | Target found | document | | | | Target found | document | | |||
+------------+----------------------------------------+-------------+ | +------------+----------------------------------------+-------------+ | |||
DCO Status Codes | DCO-ACK Status Codes | |||
6.3. New Registry for the Destination Cleanup Object (DCO) | 6.3. New Registry for the Destination Cleanup Object (DCO) | |||
Acknowledgment Flags | Acknowledgment Flags | |||
IANA is requested to create a registry for the 8-bit Destination | IANA is requested to create a registry for the 8-bit Destination | |||
Cleanup Object (DCO) Acknowledgment Flags field. This registry | Cleanup Object (DCO) Acknowledgment Flags field. This registry | |||
should be located in existing category of "Routing Protocol for Low | should be located in existing category of "Routing Protocol for Low | |||
Power and Lossy Networks (RPL)". | Power and Lossy Networks (RPL)". | |||
New bit numbers may be allocated only by an IETF Review. Each bit is | New bit numbers may be allocated only by an IETF Review. Each bit is | |||
End of changes. 8 change blocks. | ||||
7 lines changed or deleted | 16 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/ |