draft-ietf-roll-efficient-npdao-14.txt   draft-ietf-roll-efficient-npdao-15.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 4, 2020 Cisco Expires: January 9, 2020 Cisco
R. Sahoo R. Sahoo
Z. Cao Z. Cao
Huawei Huawei
July 3, 2019 July 8, 2019
Efficient Route Invalidation Efficient Route Invalidation
draft-ietf-roll-efficient-npdao-14 draft-ietf-roll-efficient-npdao-15
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 4, 2020. This Internet-Draft will expire on January 9, 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 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language and Terminology . . . . . . . . . . 3 1.1. Requirements Language and Terminology . . . . . . . . . . 3
1.2. Current NPDAO messaging . . . . . . . . . . . . . . . . . 4 1.2. Current NPDAO messaging . . . . . . . . . . . . . . . . . 4
1.3. Why Is NPDAO Important? . . . . . . . . . . . . . . . . . 5 1.3. Why Is NPDAO Important? . . . . . . . . . . . . . . . . . 5
2. Problems with current NPDAO messaging . . . . . . . . . . . . 6 2. Problems with current NPDAO messaging . . . . . . . . . . . . 6
2.1. Lost NPDAO due to link break to the previous parent . . . 6 2.1. Lost NPDAO due to link break to the previous parent . . . 6
2.2. Invalidate Routes of Dependent Nodes . . . . . . . . . . 6 2.2. Invalidate Routes of Dependent Nodes . . . . . . . . . . 6
2.3. Possible route downtime caused by asynchronous operation 2.3. Possible route downtime caused by asynchronous operation
of NPDAO and DAO . . . . . . . . . . . . . . 6 of NPDAO and DAO . . . . . . . . . . . . . . . . . . . . 6
3. Requirements for the NPDAO Optimization . . . . . . . . . . . 6 3. Requirements for the NPDAO Optimization . . . . . . . . . . . 6
3.1. Req#1: Remove messaging dependency on link to the 3.1. Req#1: Remove messaging dependency on link to the
previous parent . . . . . . . . . . . . . . . . . . . . . 6 previous parent . . . . . . . . . . . . . . . . . . . . . 6
3.2. Req#2: Dependent nodes route invalidation on parent 3.2. Req#2: Dependent nodes route invalidation on parent
switching . . . . . . . . . . . . . . . . . . . . . . . . 7 switching . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Req#3: Route invalidation should not impact data traffic 7 3.3. Req#3: Route invalidation should not impact data traffic 7
4. Changes to RPL signaling . . . . . . . . . . . . . . . . . . 7 4. 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. Transit Information Option changes . . . . . . . . . . . 8 4.2. Transit Information Option changes . . . . . . . . . . . 8
4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 9 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 Acknowledgment (DCO-ACK) . 11 4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK) . 11
4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 12 4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 12
4.4. DCO Base Rules . . . . . . . . . . . . . . . . . . . . . 12 4.4. DCO Base Rules . . . . . . . . . . . . . . . . . . . . . 12
4.5. Unsolicited DCO . . . . . . . . . . . . . . . . . . . . . 12 4.5. Unsolicited DCO . . . . . . . . . . . . . . . . . . . . . 12
4.6. Other considerations . . . . . . . . . . . . . . . . . . 13 4.6. Other considerations . . . . . . . . . . . . . . . . . . 13
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. Considerations for DCO retry . . . . . . . . . . . . 14
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 4.6.4. DCO with multiple preferred parents . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. New Registry for the Destination Cleanup Object (DCO) 6.1. New Registry for the Destination Cleanup Object (DCO)
Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . 17
6.3. New Registry for the Destination Cleanup Object (DCO) 6.3. New Registry for the Destination Cleanup Object (DCO)
Acknowledgment Flags . . . . . . . . . . . . . . . . . . 17 Acknowledgment Flags . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Normative References . . . . . . . . . . . . . . . . . . . . 18 8. Normative References . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 19 Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 19
A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 19 A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 20
A.2. Example DCO Messaging with multiple preferred parents . . 20 A.2. Example DCO Messaging with multiple preferred parents . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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
Router) can use to learn a route towards the downstream nodes. In Router) can use to learn a route towards the downstream nodes. In
storing mode, DAO messages would result in routing entries being storing mode, DAO messages would result in routing entries being
created on all intermediate 6LRs from the node's parent all the way created on all intermediate 6LRs from the node's parent all the way
skipping to change at page 9, line 40 skipping to change at page 9, line 40
Figure 3: DCO base object Figure 3: DCO base object
RPLInstanceID: 8-bit field indicating the topology instance RPLInstanceID: 8-bit field indicating the topology instance
associated with the DODAG, as learned from the DIO. associated with the DODAG, as learned from the DIO.
K: The 'K' flag indicates that the recipient of DCO message is K: The 'K' flag indicates that the recipient of DCO message is
expected to send a DCO-ACK back. If the DCO-ACK is not received even expected to send a DCO-ACK back. If the DCO-ACK is not received even
after setting the 'K' flag, an implementation may retry the DCO at a after setting the 'K' flag, an implementation may retry the DCO at a
later time. The number of retries are implementation and deployment later time. The number of retries are implementation and deployment
dependent and are expected to be kept similar with those used in DAO dependent and are expected to be kept similar with those used in DAO
retries in [RFC6550]. A node receiving a DCO message without the 'K' retries in [RFC6550]. Section 4.6.3 specifies the considerations for
flag set MAY respond with a DCO-ACK, especially to report an error DCO retry. A node receiving a DCO message without the 'K' flag set
condition. An example error condition could be that the node sending MAY respond with a DCO-ACK, especially to report an error condition.
the DCO-ACK does not find the routing entry for the indicated target. An example error condition could be that the node sending the DCO-ACK
When the sender does not set the 'K' flag it is an indication that does not find the routing entry for the indicated target. When the
the sender does not expect a response, and the sender SHOULD NOT sender does not set the 'K' flag it is an indication that the sender
retry the DCO. does not expect a response, and the sender SHOULD NOT retry the DCO.
D: The 'D' flag indicates that the DODAGID field is present. This D: The 'D' flag indicates that the DODAGID field is present. This
flag MUST be set when a local RPLInstanceID is used. flag MUST be set when a local RPLInstanceID is used.
Flags: The 6 bits remaining unused in the Flags field are reserved Flags: The 6 bits remaining unused in the Flags field are reserved
for future use. These bits MUST be initialized to zero by the sender for future use. These bits MUST be initialized to zero by the sender
and MUST be ignored by the receiver. and MUST be ignored by the receiver.
Reserved: 8-bit unused field. The field MUST be initialized to zero Reserved: 8-bit unused field. The field MUST be initialized to zero
by the sender and MUST be ignored by the receiver. by the sender and MUST be ignored by the receiver.
skipping to change at page 14, line 23 skipping to change at page 14, line 23
1. Use NPDAO to invalidate the previous route and send regular DAO 1. Use NPDAO to invalidate the previous route and send regular DAO
on the new path. on the new path.
2. Send regular DAO on the new path with the 'I' flag set in the 2. Send regular DAO on the new path with the 'I' flag set in the
Transit Information Option such that the common ancestor node Transit Information Option such that the common ancestor node
initiates the DCO message downstream to invalidate the previous initiates the DCO message downstream to invalidate the previous
route. route.
This document recommends using option 2 for reasons specified in This document recommends using option 2 for reasons specified in
Section 3 in this document. Section 3 in this document.
4.6.3. DCO with multiple preferred parents This document assumes that all the 6LRs in the network support this
specification. If there are 6LRs en-route DCO message path which do
not support this document, then the route invalidation for
corresponding targets may not work or may work partially i.e., only
part of the path supporting DCO may be invalidated. Alternatively, a
node could generate an NPDAO if it does not receive a DCO with itself
as target within specified time limit. The specified time limit is
deployment specific and depends upon the maximum depth of the network
and per hop average latency. Note that sending NPDAO and DCO for the
same operation would not result in unwanted side-effects because the
acceptability of NPDAO or DCO depends upon the Path Sequence
freshness.
4.6.3. Considerations for DCO retry
A DCO message could be retried by a sender if it sets the 'K' flag
and does not receive a DCO-ACK. The DCO retry time could be
dependent on the maximum depth of the network and average per hop
latency. This could range from 2 seconds to 120 seconds depending on
the deployment. In case the latency limits are not known, an
implementation MUST NOT retry more than once in 3 seconds and MUST
NOT retry more than 3 times.
The number of retries could also be set depending on how critical the
route invalidation could be for the deployment and the link layer
retry configuration. For networks supporting only MP2P and P2MP
flows, such as in AMI and telemetry applications, the 6LRs may not be
very keen to invalidate routes, unless they are highly memory-
constrained. For home and building automation networks which may
have substantial P2P traffic, the 6LRs might be keen to invalidate
efficiently because it may additionally impact the forwarding
efficiency.
4.6.4. DCO with multiple preferred parents
[RFC6550] allows a node to select multiple preferred parents for [RFC6550] allows a node to select multiple preferred parents for
route establishment. Section 9.2.1 of [RFC6550] specifies, "All DAOs route establishment. Section 9.2.1 of [RFC6550] specifies, "All DAOs
generated at the same time for the same Target MUST be sent with the generated at the same time for the same Target MUST be sent with the
same Path Sequence in the Transit Information". Subsequently when same Path Sequence in the Transit Information". Subsequently when
route invalidation has to be initiated, RPL mentions use of NPDAO route invalidation has to be initiated, RPL mentions use of NPDAO
which can be initiated with an updated Path Sequence to all the which can be initiated with an updated Path Sequence to all the
parent nodes through which the route is to be invalidated. parent nodes through which the route is to be invalidated.
With DCO, the Target node itself does not initiate the route With DCO, the Target node itself does not initiate the route
skipping to change at page 16, line 8 skipping to change at page 16, line 43
6.1. New Registry for the Destination Cleanup Object (DCO) Flags 6.1. New Registry for the Destination Cleanup Object (DCO) 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) Flags field. This registry should be located in Cleanup Object (DCO) Flags field. This registry should be located in
existing category of "Routing Protocol for Low Power and Lossy existing category of "Routing Protocol for Low Power and Lossy
Networks (RPL)". 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
tracked with the following qualities: tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
The following bits are currently defined: The following bits are currently defined:
+------------+------------------------------+---------------+ +------------+------------------------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+------------------------------+---------------+ +------------+------------------------------+---------------+
| 0 | DCO-ACK request (K) | This document | | 0 | DCO-ACK request (K) | This document |
| 1 | DODAGID field is present (D) | This document | | 1 | DODAGID field is present (D) | This document |
+------------+------------------------------+---------------+ +------------+------------------------------+---------------+
skipping to change at page 16, line 34 skipping to change at page 17, line 25
(DCO-ACK) Status field (DCO-ACK) Status field
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 Acknowledgment (DCO-ACK) Status field. This registry Cleanup Object Acknowledgment (DCO-ACK) Status 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 Status values may be allocated only by an IETF Review. Each New Status values may be allocated only by an IETF Review. Each
value is tracked with the following qualities: value is tracked with the following qualities:
o Status Code o Status Code
o Description o Description
o Defining RFC o Defining RFC
The following values are currently defined: The following values are currently defined:
+------------+----------------------------------------+-------------+ +------------+----------------------------------------+-------------+
| 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 |
skipping to change at page 17, line 16 skipping to change at page 18, line 5
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
tracked with the following qualities: tracked with the following qualities:
o Bit number (counting from bit 0 as the most significant bit) o Bit number (counting from bit 0 as the most significant bit)
o Capability description o Capability description
o Defining RFC o Defining RFC
The following bits are currently defined: The following bits are currently defined:
+------------+------------------------------+---------------+ +------------+------------------------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+------------------------------+---------------+ +------------+------------------------------+---------------+
| 0 | DODAGID field is present (D) | This document | | 0 | DODAGID field is present (D) | This document |
+------------+------------------------------+---------------+ +------------+------------------------------+---------------+
DCO-ACK Base Flags DCO-ACK Base Flags
 End of changes. 15 change blocks. 
32 lines changed or deleted 66 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/