< 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/