draft-ietf-roll-efficient-npdao-04.txt   draft-ietf-roll-efficient-npdao-05.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 20, 2019 Cisco Expires: February 25, 2019 Cisco
R. Sahoo R. Sahoo
Z. Cao Z. Cao
Huawei Huawei
July 19, 2018 August 24, 2018
Efficient Route Invalidation Efficient Route Invalidation
draft-ietf-roll-efficient-npdao-04 draft-ietf-roll-efficient-npdao-05
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 January 20, 2019. This Internet-Draft will expire on February 25, 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 29 skipping to change at page 2, line 29
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 . . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . 8 4.2. Transit Information Option format change . . . . . . . . 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 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 . . . . . . . . . . . . . . . . . . 12 4.4. Other considerations . . . . . . . . . . . . . . . . . . 12
4.4.1. Dependent Nodes invalidation . . . . . . . . . . . . 12 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
skipping to change at page 7, line 34 skipping to change at page 7, line 34
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 common ancestor node generates a between the new and old path. The common ancestor node generates a
DCO in response to the change in the next-hop on receiving a regular DCO in response to the change in the next-hop on receiving a regular
DAO for the target. DAO for the target.
In the Figure 1, when node D decides to switch the path from B to C, In Figure 1, when node D decides to switch the path from B to C, it
it sends a regular DAO to node C with reachability information 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
finds however that the next hop information for reaching node D has finds however that the next hop information for reaching node D has
changed i.e. the node D has decided to change the paths. In this changed i.e. the node D has decided to change the paths. In this
case, Node A which is the common ancestor node for node D along the case, Node A which is the common ancestor node for node D along the
two paths (previous and new), may generate a DCO which traverses two paths (previous and new), may generate a DCO which traverses
downwards in the network. The document in the subsequent section downwards in the network. The document in the subsequent section
will explain the message format changes to handle this downward flow will explain the message format changes to handle this downward flow
of NPDAO. of NPDAO.
4.2. DAO message format changes 4.2. Transit Information Option format change
Every RPL message is divided into base message fields and additional Every RPL message is divided into base message fields and additional
Options. The base fields apply to the message as a whole and options Options. The base fields apply to the message as a whole and options
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 DAO message to contain "Invalidate The draft proposes a change in Transit Information option to contain
previous route" (I) bit. This I-bit which is carried in regular DAO "Invalidate previous route" (I) bit. This I-bit signals the common
message, signals the common ancestor node to generate a DCO on behalf ancestor node to generate a DCO on behalf of the target node. The
of the target node. The I-bit is carried in the transit container I-bit is carried in the transit information option which augments the
option which augments the reachability information for a given set of reachability information for a given set of RPL Target(s).
RPL 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 12, line 15 skipping to change at page 12, line 15
4.4. Other considerations 4.4. Other considerations
4.4.1. Dependent Nodes invalidation 4.4.1. Dependent Nodes invalidation
Current RPL [RFC6550] does not provide a mechanism for route Current RPL [RFC6550] does not provide a mechanism for route
invalidation for dependent nodes. This document allows the dependent invalidation for dependent nodes. This document allows the dependent
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 container 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. 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
 End of changes. 9 change blocks. 
15 lines changed or deleted 14 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/